From owner-mpls@UU.NET Thu Aug 1 01:59: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 BAA29134 for ; Thu, 1 Aug 2002 01:59:31 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzzk00265 for ; Thu, 1 Aug 2002 06: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 QQmzzk29210; Thu, 1 Aug 2002 06:00:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzzj09851 for mpls-outgoing; Thu, 1 Aug 2002 05:59: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 QQmzzj09844 for ; Thu, 1 Aug 2002 05:59:36 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 QQmzzj16028 for ; Thu, 1 Aug 2002 05:59: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 QQmzzj10586 for ; Thu, 1 Aug 2002 05:59:23 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmzzj10571 for ; Thu, 1 Aug 2002 05:59:22 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 01 Aug 2002 11:52:08 +0530 Received: from maheshks (maheshks.future.futsoft.com [10.20.6.83]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id g715w8wl020083 for ; Thu, 1 Aug 2002 11:28:09 +0530 Reply-To: From: "Mahesh kumar S" To: Subject: Downstream on Demand and Downstream Unsolicited - Interoperability Date: Thu, 1 Aug 2002 11:18:08 +0530 Message-Id: <000001c2391f$040e2340$5306140a@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.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, RFC 3215 (LDP State Machine) which is informational gives precise directions on implementing the state machines for DOD Merge,Dod Non Merge and DU. Is it necessary for an implementation to support DOD Merge on one interface and DU on the other interface. If so, is there any informational RFC which specifies things as clearly as RFC 3215 for interoperability. Thanks in Advance. Regards, Maheshkumar *************************************************************************** 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 Thu Aug 1 03:53:57 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09780 for ; Thu, 1 Aug 2002 03:53:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzzr12099 for ; Thu, 1 Aug 2002 07:54: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 QQmzzr10800; Thu, 1 Aug 2002 07:54:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzzr02983 for mpls-outgoing; Thu, 1 Aug 2002 07:53: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 QQmzzr02976 for ; Thu, 1 Aug 2002 07:53: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 QQmzzr14621 for ; Thu, 1 Aug 2002 07: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 QQmzzr23095 for ; Thu, 1 Aug 2002 07:53:08 GMT Received: from djswamp.layer8.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: soggy131.drizzle.com [216.162.199.131]) id QQmzzr23091 for ; Thu, 1 Aug 2002 07:53:08 GMT Received: (qmail 685 invoked by uid 1000); 1 Aug 2002 07:52:51 -0000 Date: Thu, 1 Aug 2002 00:52:51 -0700 From: Ben Black To: "Black, Stephen" Cc: "'Andrew G. Malis'" , Ron Bonica , Tissa Senevirathne , "'mpls@UU.NET'" Subject: Re: Secure MPLS Message-ID: <20020801075251.GB249@layer8.net> References: <9A4B2157EFDBE546BECD68C62AC3B1C805DA26E7@es05snlnt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A4B2157EFDBE546BECD68C62AC3B1C805DA26E7@es05snlnt> User-Agent: Mutt/1.3.99i Sender: owner-mpls@UU.NET Precedence: bulk What do those customers do currently for security of those links? Ben On Wed, Jul 31, 2002 at 02:50:04PM -0600, Black, Stephen wrote: > To a point I agree with Ron also... but there are other considerations to > look at... Such as government/corporate clients who need to have an ISP > guarantee that their links are secure (i.e. a link between FBI and CIA, or a > link from Intel in CA to Intel in NY). There are also military networks that > might want to implement a secure form of MPLS. Granted this is a very small > piece of the pie but it should be worth putting some effort into. As a > client I'd rather have a combination of layers that incorporates security > rather than a higher layer where the lower layers can be compromised without > my knowledge. Just running IPSEC and a firewall is like putting all your > eggs in one basket. Let the politicians worry about the escrow and seizure. > > Steve > > > -----Original Message----- > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Wednesday, July 31, 2002 12:39 PM > To: Ron Bonica > Cc: Tissa Senevirathne; mpls@UU.NET > Subject: RE: Secure MPLS > > > I agree with Ron. From the end user point of view, some problems with > service provider encryption are that the tail circuits from the customer > premise to the service provider are unprotected (which the obvious place to > place a covert wiretap); the encryption keys are the property of the > service provider, not the end user; and the keys could be subject to > government escrow or seizure depending on where you are in the world. This > is certainly the case in the US (see http://www.fcc.gov/calea/ ). > > Cheers, > Andy > > ------ > > At 7/30/2002 02:22 PM -0400, Ron Bonica wrote: > >Tissa, > > > >Given that the upper layers are capable of encryption using mechanisms like > >IPSEC, why would a service provider want to encrypt the contents of an MPLS > >LSP? > > > >Wouldn't you want to push the encryption function higher in the protocol > >stack and closer to the network edges? > > > > Ron > From owner-mpls@UU.NET Thu Aug 1 07:43: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 HAA26132 for ; Thu, 1 Aug 2002 07:43:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaag26748 for ; Thu, 1 Aug 2002 11:44:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnaag24795; Thu, 1 Aug 2002 11:43:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaag18517 for mpls-outgoing; Thu, 1 Aug 2002 11:43:08 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 QQnaag18512 for ; Thu, 1 Aug 2002 11:43: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 QQnaag25983 for ; Thu, 1 Aug 2002 11:43: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 QQnaag10606 for ; Thu, 1 Aug 2002 11:43:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnaag10602 for ; Thu, 1 Aug 2002 11:43:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA10285 for ; Thu, 1 Aug 2002 07:43:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA18130 for mpls@uu.net; Thu, 1 Aug 2002 07:43:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnaag18503 for ; Thu, 1 Aug 2002 11:42:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnaag23943 for ; Thu, 1 Aug 2002 11:40: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 QQnaag21891 for ; Thu, 1 Aug 2002 11:40:55 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 QQnaag21887 for ; Thu, 1 Aug 2002 11:40:55 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25691; Thu, 1 Aug 2002 07:39:44 -0400 (EDT) Message-Id: <200208011139.HAA25691@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-allan-mpls-loadbal-00.txt Date: Thu, 01 Aug 2002 07:39:44 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for MPLS Load Balancing Author(s) : D. Allen Filename : draft-allan-mpls-loadbal-00.txt Pages : 6 Date : 31-Jul-02 RFC 3031 permits MPLS load balancing while making no specific representations as to requirements of implementation. This has subsequently become an issue with respect to the reliability of path test mechanisms. Load balancing algorthms may separate path test probes from the path of interest. This I-D proposes guidelines for implementation of load balancing such that path test mechanisms are not impacted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allan-mpls-loadbal-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allan-mpls-loadbal-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-allan-mpls-loadbal-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020731143852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allan-mpls-loadbal-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-allan-mpls-loadbal-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020731143852.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Aug 1 10:09: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 KAA01363 for ; Thu, 1 Aug 2002 10:09:36 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaaq15115 for ; Thu, 1 Aug 2002 14:10: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 QQnaaq13460; Thu, 1 Aug 2002 14:09:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaaq05688 for mpls-outgoing; Thu, 1 Aug 2002 14:09:12 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 QQnaaq05677 for ; Thu, 1 Aug 2002 14:08:58 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 QQnaaq09498 for ; Thu, 1 Aug 2002 14:08: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 QQnaaq00762 for ; Thu, 1 Aug 2002 14:08: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 QQnaaq00606 for ; Thu, 1 Aug 2002 14:08:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA18048 for ; Thu, 1 Aug 2002 10:08:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02885 for mpls@uu.net; Thu, 1 Aug 2002 10:08:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnaaq05589 for ; Thu, 1 Aug 2002 14:07: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 QQnaaq03553 for ; Thu, 1 Aug 2002 14:06: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 QQnaaq11029 for ; Thu, 1 Aug 2002 14:06:54 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQnaaq11015 for ; Thu, 1 Aug 2002 14:06:54 GMT Received: from AMALIS.vivacenetworks.com ([10.120.0.2] RDNS failed) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 1 Aug 2002 07:05:44 -0700 Message-Id: <5.1.0.14.2.20020801100027.030a04b8@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 01 Aug 2002 10:05:40 -0400 To: neil.2.harrison@bt.com From: "Andrew G. Malis" Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Cc: Andy.Malis@vivacenetworks.com, mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Aug 2002 14:05:44.0515 (UTC) FILETIME=[870E0130:01C23964] Sender: owner-mpls@UU.NET Precedence: bulk Neil, My point was just that it's not only the IETF. The IEEE invented OUIs and makes heavy use of them in their specifications (and a nice business selling them), and the ITU-T also uses them. Cheers, Andy ------- At 8/1/2002 03:43 AM +0100, neil.2.harrison@bt.com wrote: >Andy, > > > >My view on this is that any body who purports to be a 'standards > > >organisation' should not sanction vendor (or other, eg SP) protocol > > >codepoints. > > > > See Q.2931 (02/95 revision is the one I'm looking at) section > > 4.5.8 and > > X.36 (04/95) Annex D for some examples of ITU-T usage of the > > IEEE OUI for > > vendor extensions and private protocol identification. >NH=> And therefore the conclusion is?.........you seem to be saying >something like 'if X commits a crime it now gives everyone the right and >also go and commit the same crime'. I don't care which stds body does >this....it simply is not right in principle IMO. > >regards, Neil From owner-mpls@UU.NET Thu Aug 1 10:09: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 KAA01377 for ; Thu, 1 Aug 2002 10:09:53 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaaq12297 for ; Thu, 1 Aug 2002 14:10: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 QQnaaq10633; Thu, 1 Aug 2002 14:10:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaaq05723 for mpls-outgoing; Thu, 1 Aug 2002 14:09: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 QQnaaq05718 for ; Thu, 1 Aug 2002 14:09:32 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 QQnaaq11902 for ; Thu, 1 Aug 2002 14:09: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 QQnaaq01721 for ; Thu, 1 Aug 2002 14:09:15 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 QQnaaq01716 for ; Thu, 1 Aug 2002 14:09:15 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA18132 for ; Thu, 1 Aug 2002 10:09:15 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02986 for mpls@uu.net; Thu, 1 Aug 2002 10:09:15 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnaam09137 for ; Thu, 1 Aug 2002 13:09:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnaam01104 for ; Thu, 1 Aug 2002 13:09: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 QQnaam22306 for ; Thu, 1 Aug 2002 13:09:30 GMT Received: from webmail30.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: webmail30.rediffmail.com [202.54.124.145] (may be forged)) id QQnaam22278 for ; Thu, 1 Aug 2002 13:09:28 GMT Received: (qmail 24822 invoked by uid 510); 1 Aug 2002 13:09:25 -0000 Date: 1 Aug 2002 13:09:25 -0000 Message-ID: <20020801130925.24821.qmail@webmail30.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 01 Aug 2002 13:09:25 -0000 MIME-Version: 1.0 From: "priyaranjan mohapatra" Reply-To: "priyaranjan mohapatra" To: mpls@UU.NET Subject: Fast Reroute -facility backup- rerouting control traffic after failure Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk This is with reference to the draft "draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt" for Fast ReRoute. To quote from the draft(described in section.6) - "During failure, the PLR reroutes the data packets of each protected LSP onto the bypass tunnel. The control messages of the backed-up LSPs are also sent over the bypass tunnel. The facility backup uses the sender-template-specific approach to identify the backup tunnels." As explained in the above paragraph, the control messages of the backed-up LSPs are sent over the bypass tunnel during failure.Does this means that after failure,the path refresh messages of the backed-up LSPs will sent through the bypass tunnel as labeled packets.If this is the case, then how the path messages can be forced to be sent as labeled packets, as RFC 2205 says that RSVP messages are sent hop-by-hop between RSVP routers as "raw" IP datagrams with protocol number 46. regards, Priyaranjan From owner-mpls@UU.NET Thu Aug 1 13:00: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 NAA07250 for ; Thu, 1 Aug 2002 13:00:40 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnabc07994 for ; Thu, 1 Aug 2002 17:01: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 QQnabb03411; Thu, 1 Aug 2002 16:59:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnabb05249 for mpls-outgoing; Thu, 1 Aug 2002 16:59: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 QQnabb05244 for ; Thu, 1 Aug 2002 16:58: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 QQnabb08054 for ; Thu, 1 Aug 2002 16:58: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 QQnabb04065 for ; Thu, 1 Aug 2002 16:58:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnabb04047 for ; Thu, 1 Aug 2002 16:58:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA04114 for ; Thu, 1 Aug 2002 12:58:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21241 for mpls@uu.net; Thu, 1 Aug 2002 12:58:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnabb05207 for ; Thu, 1 Aug 2002 16:57: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 QQnabb26464 for ; Thu, 1 Aug 2002 16:56: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 QQnabb23642 for ; Thu, 1 Aug 2002 16:56:51 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 QQnabb23629 for ; Thu, 1 Aug 2002 16:56:51 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07026; Thu, 1 Aug 2002 12:55:27 -0400 (EDT) Message-Id: <200208011655.MAA07026@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-allan-mpls-loadbal-00.txt Date: Thu, 01 Aug 2002 12:55:27 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for MPLS Load Balancing Author(s) : D. Allan Filename : draft-allan-mpls-loadbal-00.txt Pages : 6 Date : 31-Jul-02 RFC 3031 permits MPLS load balancing while making no specific representations as to requirements of implementation. This has subsequently become an issue with respect to the reliability of path test mechanisms. Load balancing algorthms may separate path test probes from the path of interest. This I-D proposes guidelines for implementation of load balancing such that path test mechanisms are not impacted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allan-mpls-loadbal-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allan-mpls-loadbal-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-allan-mpls-loadbal-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020801130521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allan-mpls-loadbal-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-allan-mpls-loadbal-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020801130521.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Aug 2 07:51: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 HAA15151 for ; Fri, 2 Aug 2002 07:51:34 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnadz03233 for ; Fri, 2 Aug 2002 11:52: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 QQnadz02247; Fri, 2 Aug 2002 11:52:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnadz02305 for mpls-outgoing; Fri, 2 Aug 2002 11:51: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 QQnadz02300 for ; Fri, 2 Aug 2002 11:51:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnadz02486 for ; Fri, 2 Aug 2002 11:51: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 QQnadz02027 for ; Fri, 2 Aug 2002 11:51:44 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnadz02013 for ; Fri, 2 Aug 2002 11:51:43 GMT Received: from utfors.se ([195.58.105.98]) by blooper.utfors.se (Utfors AB) with ESMTP id g72BpR5F003048 for ; Fri, 2 Aug 2002 13:51:27 +0200 (MEST) Message-ID: <3D4A723B.1070102@utfors.se> Date: Fri, 02 Aug 2002 13:51:23 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: MPLS wg Subject: draft minutes from Yokohama mpls meeting Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Included are the drafts minutes from the MPLS wg meeting in Yokohama. Thanks to Dave and Eric who helped taking notes, but have not repsonsibility for the delay in getting them out to the list. Please comment. /Loa IETF 54 MPLS WG Preliminary Notes Thursday July 12. 9 - 11.30 AM Chair - Loa Andersson (George Swallow not in attendance). Note Takers - David Allan, Eric Gray Loa: Agenda bashing -------------- - process reminders/blue sheets - LDP MTU draft off the agenda - No further comments on the agenda Loa: LDP (RFC 3036) to draft standard (status) --------------------------------------------------- Loa talked about the need to collect implementation information on LDP for taking it to Draft Standard. It is still not clear how many other rfc's that will be affected, encap and LDP draft, maybe also architecture. This is because of normative references. A survey form is developed and will be published on the list in a few weeks, together with instructions on how to respond. Asked to include an anonymity option. Scot Bradner will act as anynomizer". Results will be published as an I-D. One intention will be to simplify LDP, so unimplemented stuff will be removed when LDP is moved to draft standard. Scott Bradner AD: Current state of the issues in the mpls oam discussion and the ITU-T liaison. ----------------------------------------------------------------------------- The background is that we have an I-D, by Hiroshi Otha, requesting a reserved label to be used by ITU-T, for OAM. At the last meeting the discussion concerned changes to IETF protocols that would result. As a result a liaison was sent for clarification, asking if they were operating under the assumption that they would be requesting changes. Liaison response: Hiroshi Ohta (SG13 Rapporteur, slides included) Hiroshi Ohta presented a report on ITU-T's response to IETF's liaison on MPLS OAM. He stated that they do not expect to impact IETF protocols and minimal impact on implementations. Y.1711 cannot work without the reserved label - therefore, they request that IANA assign a reserved label. Discussion ---------- Rahul Aggarwal: The statement of no impact on forwarding plane is inaccurate, on egress LSRs there will be an impact. Kireeti: If we allocate this label, will the ITU use this label 'efficiently', in other words, will there be other requests. Scott: The ITU is finding that IETF protocols are popular, so they want to use them. He gave an example of the process using SIP. The IETF decides that protocols developed by IETF need to be reviewed by IETF when extensions are being proposed. Kireeti: there are two concerns, one is the IETF process (which is good) and the other is how far does this go? Do they need to go through the RFC process. Scott: This may be dealt with in many ways, however we hope that the cooperative approach will work. Scott asked the sense of the room: We have an I-D seeking assignment, we've interacted to find out answers to questions we've asked. I think this is a good thing, both cooperatively and for the good of the protocol. MPLS is being used in a number of environments, and the usage assumptions are different depending on the carrier. We need to support the IP carrier, but that is not all of them. In that context we should be open to the use of our protocols in other environments. For MPLS to be seen as useful in trad telco environments it needs this stuff. Hummm (a few raised hands :)) showed a consensus for RFC publishing the draft and issuing the label. Scott Bradner: rsvp-te vs. cr-ldp, initiating a discussion ----------------------------------------------- In the implementation survey for GMPLS, there was lots of RSVP and little CR-LDP. Concern in ISEG on multiple standards track ways of doing something is confusing to the market place. Don't need to visit the history. Don't think we need to stop publishing CR-LDP, but should they be informational or standards track. Discussion: ---------- Loa: The intent of having this agenda item is to initiate the discussion, not arrive at a conclusion at this meeting. Bilel Jamoussi: Comment on the survey. Did not state the objective or indicate how it was going to be used. Not scientific by any means. More importantly GMPLS is a new thing, carriers are still debating the architectures. Think the discussion is premature. There are today several networks running CR-LDP in a packet environment. Bert: Purpose of survey was to seek an implementation report before approving GMPLS. This was an artifact of the survey not the intent. I don't think discussion is premature, a decision may be. Folks can still implement informational. Within one org you would normally try to go for one standard. Kireeti: I wear several hats. CCAMP chair, twice as many protocol extensions because of two protocols. Have to write two sets of drafts as an author. Have to read twice as many. As a vendor I do not care, and do not implement it. Impact on IETF is twice as much material. Luca Martini: as a service provider, we found RSVP predominantly deployed and implemented. Pushed by a particular vendor for an obscure reason. We should shift CR-LDP to informational. Ron Bonica: Like to second what Luca said. IETF produces too much technology to do a good job. Lets prune. Chris Liljenstolpe: Third what Luca said. Osama Aboul-Magd: From transport POV, the market is really slow so deployment is pretty much nonexistent. This is not an indicator. Joel Halpern: Helped work on CR-LDP, technically prefer it. That's irrelevant, its not about what is technically better, RSVP won the fight. Bilel: Agree on one application. Not necessarily so for optical transport. For packet TE, RSVP has one the fight. In optical it is premature. So Packet TE it is overwhelmingly RSVP, but GMPLS it is premature. Folks are building on the CR-LDP. There are other examples of multiple protocols. Bert: Past potential mistakes are not necessarily an indication of what we should do in the future. In this case one far outweighs the other. Chippy: We don't support it because we have no customer demand. Ludo Practico: We support both and get interest in both. Discussion to move to the mailing list. Loa: Confine it to the MPLS list, but we'll send mail to the other sub-ip list informing them about the discussion. Bert Wijnen Status and issues with the mpls mibs ----------------------------------------------- We have lots of MPLS MIBs. Although separately they looks OK, there was a lot of overlaps (TCs and the like, some conflicting). Shows authors not working together, and no cross review of how they play together. No discontinuity timers for counters, or how MIBs relate to each other. etc. etc. Several issues, including inconsistencies and duplicated uses. Also, there are uses defined that are not consistent with common usage elsewhere. Some MIBs have already become RFCs and others have been held up in queue for corrections. There is a draft that attempt to capture the relationships between various MIBs, but this does not do quite enough. Also, there are some MIBs that are fairly 'all-inclusive' and it is not clear that this is always a good thing. Also, there are differences in the 'tolerance' levels for various MIB compilers and this results in MIBs that do not compile using some MIB compilers. We would also like to see better communications between various MIB development efforts. We would also like to see who is implementing which MIBs. Finally, people should get help for MIBs at mibs@ops.ietf.org or by asking SNMP/MIB advisor for the working group. If there is no SNMP/MIB advisor, get one. Marcus: We have actually implemented some MIBs only partially. Bert: The correct way to work through this is to talk about these issues on the public mailing list so that everyone can benefit from understanding the issues and answers. Kireeti: Asked if Marcus had tried the TE-WG MIB. Marcus Brunner: I were actually referring to the LSR MIB. Vach Kompella: I've had issues with the LDP MIB and we've also implemented a proprietary MIB that supports a subset of the MIB. Bert: The LSR MIB is in IESG review at this time. We had reports that people are implementing the LDP MIB. Loa: My impression is that the MIBs have become complicated and uncoordinated. My feeling that we still need to think about what to do next. It is at least clear that enough changes have occurred since the last set of last calls that another set will be required. Andy Malis Status of LDP restart and LDP fault tolerance drafts Fault Tolerance for LDP and CR-LDP Graceful Restart Mechanism for LDP ------------------------------------------------------------------------- Andy: The latest status is that the LDP FT draft was successfully merged with the Smith (check-pointing) draft. The LDP Restart draft actually has a different applicability with very little overlap. The last call has been completed, George Swallow has proposed some changes, some minor editing has to be done and then the draft should go to the IESG. Sven van den Bosch Further considerations for Forwarding Adjacency LSPs -------------------------------------------------------------- Sven van den Bosch : This is version one of the document, related to LSP hierarchy 07 WG draft. The issues addressed is complex resources classes and a new sub-class of TLVs is proposed Alternatively it could be possible to approach the IS-IS and OSPF wg's and suggest that they define extensions to the protocols. Amir Hermilage: Is it the the goal of this draft is to be merged into other work. Sven: The intent is for this to be a separate draft. Kireeti: Not sure that all cases of complex resource classes can be represented. Sven: I'm aware that there is at least one case that his proposal does not cover, but also feels that there is a real need to solve a subset of the problem space that his proposal does address. Loa: Take this back to the list and make a decision once all the implications are clear. B Jensen:(University of Wisconsin) General Summary of Interoperability Testing Results and Experiences -------------------------------------------- There are interoperability efforts from several organizatios e.g. UNH, AIL, MPLS Forum etc. There has been private tests in April, NI in May, and then Supercom. White paper will available from MPLS forum. The Draft is key findings from April, test configuration are shown in the slides. IP transport, plus L2 and L3 VPN apps (2547/Martini Ethernet), POS and GigE plus some ATM. Has been tested. Issues found: OSPF TE is not universally supported even though required for TE LSPs Vendor implementations only support a single distribution mode (DU/DoD) Not all RSVP-TE implementations support both FF and SE reservation styles Inconsistent use of IP addresses in ERO RESV_CONFIRM is not universally supported Explicit NULL label is not universally supported Discussion: Amir said that he was surprised that the presentation was being given before there was a white paper presented and said that the issue with explicit NULL labels is essentially because of a misunderstanding of the standard. Satoru Matsoshima asked about DU implementations that do not respond to requests for Labels. Rahul said that there implementation simply supports all of the possible ERO IP address usages. Amir commented on the ERO issue, saying this is critical. Loa said that the discussion should be continued on the list, thanked him for the report. J-P Vasseur MPLS Traffic Engineering Fast reroute: backup tunnel path computation for bandwidth protection ------------------------------------------------------------ P Vasseur: The draft addresses the charter item dealing with recovery mechanisms and focus on bandwidth protection issues. The draft proposes two basic approaches - centralized and distributed. It was pointed out that a Naive approach - using CSPF to setup backup paths - has two key problems: it cannot protect the bandwidth and it is possible that no solution can be found even though it can be shown that one must exist (as a result of timing). Examples of real life scenarios were given, in which bandwidth protection is needed. Bandwidth protection is needed for some traffic in some networks and input on the draft is solicited. Sven said that he is interested in this work. Loa suggested that comments on this work should be taken to the list. Seisho Yasukawa Extended RSVP-TE for Multicast LSP Tunnels -------------------------------------------------------- Seisho Yasukawa: The draft is about potential extensions for RSVP-TE for multicast LSPs. One of the things we propose in the draft is a grafting mechanism. A mechanism like this is needed e.g. for a VPLS service. It is appropriate that the multicast specifications should be discussed in the working group because the charter already includes work on the framework for multicast. Proposes that the WG should accept this draft as a WG draft. Saha asked if the draft required a multicast routing protocol, answer was that no multicast protocol is needed, but a function needed to determine the the multicast tree. Loa: This should be taken to the list. We are currently not prepared to take on new wg documents for multicast, we need a discussion to scope the multicast work within the mpls wg before we do that. That discussion should also be taken on the list. H.Hummel: "Hierarchical LSP" "O(n**2) investigations". ---------------------------------- Heinrich: The motivation for this work is to eliminate the n**2 problem via partial mesh of elementary tunnels. We have done tests and simulations to determine precise values for scalability associated with the use of hierarchical LSPs. Hierarchal LSPs is in scope for the charter by implication because of the existence of the label stack. Discussion deferred to list due to time constraints. Loa: WG and document status, Questions --------------------------------------------- 19 RFCs, latest is RFC 3270 on diff-serv. Multicast framework on the RFC-ED queue. 19 WG docs. 18 individual submissions. The issue here is that the individual submission are so numerous and diverge so much. This is a mature WG, and should be more focused. The wg documents: 5 under MIB doctor treatment. 6 documents under chair/AD (pre-IESG) review before going to IESG. 4 in WG last call. (FT completed just before meeting). 4 work in progress (incomplete). Meeting ended 11.30 AM. -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Fri Aug 2 08:48: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 IAA17191 for ; Fri, 2 Aug 2002 08:48:55 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaed15336 for ; Fri, 2 Aug 2002 12:50: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 QQnaed13876; Fri, 2 Aug 2002 12:49:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaed29059 for mpls-outgoing; Fri, 2 Aug 2002 12:48: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 QQnaed29055 for ; Fri, 2 Aug 2002 12:48:48 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 QQnaed10920 for ; Fri, 2 Aug 2002 12:48:16 GMT From: sven.van_den_bosch@alcatel.be Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaed13638 for ; Fri, 2 Aug 2002 12:48:15 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 QQnaed13634 for ; Fri, 2 Aug 2002 12:48:14 GMT Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g72Cfx319460; Fri, 2 Aug 2002 14:41:59 +0200 Subject: Re: draft minutes from Yokohama mpls meeting To: Loa Andersson Cc: MPLS wg X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 2 Aug 2002 14:46:27 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/02/2002 14:46:32 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA17191 Hi all, I would like to expand a little bit on the minutes because I feel some of the remarks may have gotten a little bit condensed. - On the question whether or not this work was intended to be separate or merged I replied that I felt it was useful to keep the draft as an overview of outstanding issues but that any eventual resolution of any of the issues could be merged with other work - On the question about complex resource class affinity specifications I also mentioned that the although the solution does not work in one particular case, an operator will always know (by virtue of its resource class specification policy) whether or not it is safe to use the proposed solution. I also recall some support for a partial solution - My remark on the fast reroute presentation was actually a question about the impact of the use of backup LSPs without bandwidth reservation on the performance of constraint-based routing algorithm (based on unreserved bandwidth advertisements) I hope this will provide some clarification. Best regards, Sven. Loa Andersson @UU.NET on 02/08/2002 13:51:23 Sent by: owner-mpls@UU.NET To: MPLS wg cc: Subject: draft minutes from Yokohama mpls meeting Included are the drafts minutes from the MPLS wg meeting in Yokohama. Thanks to Dave and Eric who helped taking notes, but have not repsonsibility for the delay in getting them out to the list. Please comment. /Loa IETF 54 MPLS WG Preliminary Notes Thursday July 12. 9 - 11.30 AM Chair - Loa Andersson (George Swallow not in attendance). Note Takers - David Allan, Eric Gray Loa: Agenda bashing -------------- - process reminders/blue sheets - LDP MTU draft off the agenda - No further comments on the agenda Loa: LDP (RFC 3036) to draft standard (status) --------------------------------------------------- Loa talked about the need to collect implementation information on LDP for taking it to Draft Standard. It is still not clear how many other rfc's that will be affected, encap and LDP draft, maybe also architecture. This is because of normative references. A survey form is developed and will be published on the list in a few weeks, together with instructions on how to respond. Asked to include an anonymity option. Scot Bradner will act as anynomizer". Results will be published as an I-D. One intention will be to simplify LDP, so unimplemented stuff will be removed when LDP is moved to draft standard. Scott Bradner AD: Current state of the issues in the mpls oam discussion and the ITU-T liaison. ----------------------------------------------------------------------------- The background is that we have an I-D, by Hiroshi Otha, requesting a reserved label to be used by ITU-T, for OAM. At the last meeting the discussion concerned changes to IETF protocols that would result. As a result a liaison was sent for clarification, asking if they were operating under the assumption that they would be requesting changes. Liaison response: Hiroshi Ohta (SG13 Rapporteur, slides included) Hiroshi Ohta presented a report on ITU-T's response to IETF's liaison on MPLS OAM. He stated that they do not expect to impact IETF protocols and minimal impact on implementations. Y.1711 cannot work without the reserved label - therefore, they request that IANA assign a reserved label. Discussion ---------- Rahul Aggarwal: The statement of no impact on forwarding plane is inaccurate, on egress LSRs there will be an impact. Kireeti: If we allocate this label, will the ITU use this label 'efficiently', in other words, will there be other requests. Scott: The ITU is finding that IETF protocols are popular, so they want to use them. He gave an example of the process using SIP. The IETF decides that protocols developed by IETF need to be reviewed by IETF when extensions are being proposed. Kireeti: there are two concerns, one is the IETF process (which is good) and the other is how far does this go? Do they need to go through the RFC process. Scott: This may be dealt with in many ways, however we hope that the cooperative approach will work. Scott asked the sense of the room: We have an I-D seeking assignment, we've interacted to find out answers to questions we've asked. I think this is a good thing, both cooperatively and for the good of the protocol. MPLS is being used in a number of environments, and the usage assumptions are different depending on the carrier. We need to support the IP carrier, but that is not all of them. In that context we should be open to the use of our protocols in other environments. For MPLS to be seen as useful in trad telco environments it needs this stuff. Hummm (a few raised hands :)) showed a consensus for RFC publishing the draft and issuing the label. Scott Bradner: rsvp-te vs. cr-ldp, initiating a discussion ----------------------------------------------- In the implementation survey for GMPLS, there was lots of RSVP and little CR-LDP. Concern in ISEG on multiple standards track ways of doing something is confusing to the market place. Don't need to visit the history. Don't think we need to stop publishing CR-LDP, but should they be informational or standards track. Discussion: ---------- Loa: The intent of having this agenda item is to initiate the discussion, not arrive at a conclusion at this meeting. Bilel Jamoussi: Comment on the survey. Did not state the objective or indicate how it was going to be used. Not scientific by any means. More importantly GMPLS is a new thing, carriers are still debating the architectures. Think the discussion is premature. There are today several networks running CR-LDP in a packet environment. Bert: Purpose of survey was to seek an implementation report before approving GMPLS. This was an artifact of the survey not the intent. I don't think discussion is premature, a decision may be. Folks can still implement informational. Within one org you would normally try to go for one standard. Kireeti: I wear several hats. CCAMP chair, twice as many protocol extensions because of two protocols. Have to write two sets of drafts as an author. Have to read twice as many. As a vendor I do not care, and do not implement it. Impact on IETF is twice as much material. Luca Martini: as a service provider, we found RSVP predominantly deployed and implemented. Pushed by a particular vendor for an obscure reason. We should shift CR-LDP to informational. Ron Bonica: Like to second what Luca said. IETF produces too much technology to do a good job. Lets prune. Chris Liljenstolpe: Third what Luca said. Osama Aboul-Magd: From transport POV, the market is really slow so deployment is pretty much nonexistent. This is not an indicator. Joel Halpern: Helped work on CR-LDP, technically prefer it. That's irrelevant, its not about what is technically better, RSVP won the fight. Bilel: Agree on one application. Not necessarily so for optical transport. For packet TE, RSVP has one the fight. In optical it is premature. So Packet TE it is overwhelmingly RSVP, but GMPLS it is premature. Folks are building on the CR-LDP. There are other examples of multiple protocols. Bert: Past potential mistakes are not necessarily an indication of what we should do in the future. In this case one far outweighs the other. Chippy: We don't support it because we have no customer demand. Ludo Practico: We support both and get interest in both. Discussion to move to the mailing list. Loa: Confine it to the MPLS list, but we'll send mail to the other sub-ip list informing them about the discussion. Bert Wijnen Status and issues with the mpls mibs ----------------------------------------------- We have lots of MPLS MIBs. Although separately they looks OK, there was a lot of overlaps (TCs and the like, some conflicting). Shows authors not working together, and no cross review of how they play together. No discontinuity timers for counters, or how MIBs relate to each other. etc. etc. Several issues, including inconsistencies and duplicated uses. Also, there are uses defined that are not consistent with common usage elsewhere. Some MIBs have already become RFCs and others have been held up in queue for corrections. There is a draft that attempt to capture the relationships between various MIBs, but this does not do quite enough. Also, there are some MIBs that are fairly 'all-inclusive' and it is not clear that this is always a good thing. Also, there are differences in the 'tolerance' levels for various MIB compilers and this results in MIBs that do not compile using some MIB compilers. We would also like to see better communications between various MIB development efforts. We would also like to see who is implementing which MIBs. Finally, people should get help for MIBs at mibs@ops.ietf.org or by asking SNMP/MIB advisor for the working group. If there is no SNMP/MIB advisor, get one. Marcus: We have actually implemented some MIBs only partially. Bert: The correct way to work through this is to talk about these issues on the public mailing list so that everyone can benefit from understanding the issues and answers. Kireeti: Asked if Marcus had tried the TE-WG MIB. Marcus Brunner: I were actually referring to the LSR MIB. Vach Kompella: I've had issues with the LDP MIB and we've also implemented a proprietary MIB that supports a subset of the MIB. Bert: The LSR MIB is in IESG review at this time. We had reports that people are implementing the LDP MIB. Loa: My impression is that the MIBs have become complicated and uncoordinated. My feeling that we still need to think about what to do next. It is at least clear that enough changes have occurred since the last set of last calls that another set will be required. Andy Malis Status of LDP restart and LDP fault tolerance drafts Fault Tolerance for LDP and CR-LDP Graceful Restart Mechanism for LDP ------------------------------------------------------------------------- Andy: The latest status is that the LDP FT draft was successfully merged with the Smith (check-pointing) draft. The LDP Restart draft actually has a different applicability with very little overlap. The last call has been completed, George Swallow has proposed some changes, some minor editing has to be done and then the draft should go to the IESG. Sven van den Bosch Further considerations for Forwarding Adjacency LSPs -------------------------------------------------------------- Sven van den Bosch : This is version one of the document, related to LSP hierarchy 07 WG draft. The issues addressed is complex resources classes and a new sub-class of TLVs is proposed Alternatively it could be possible to approach the IS-IS and OSPF wg's and suggest that they define extensions to the protocols. Amir Hermilage: Is it the the goal of this draft is to be merged into other work. Sven: The intent is for this to be a separate draft. Kireeti: Not sure that all cases of complex resource classes can be represented. Sven: I'm aware that there is at least one case that his proposal does not cover, but also feels that there is a real need to solve a subset of the problem space that his proposal does address. Loa: Take this back to the list and make a decision once all the implications are clear. B Jensen:(University of Wisconsin) General Summary of Interoperability Testing Results and Experiences -------------------------------------------- There are interoperability efforts from several organizatios e.g. UNH, AIL, MPLS Forum etc. There has been private tests in April, NI in May, and then Supercom. White paper will available from MPLS forum. The Draft is key findings from April, test configuration are shown in the slides. IP transport, plus L2 and L3 VPN apps (2547/Martini Ethernet), POS and GigE plus some ATM. Has been tested. Issues found: OSPF TE is not universally supported even though required for TE LSPs Vendor implementations only support a single distribution mode (DU/DoD) Not all RSVP-TE implementations support both FF and SE reservation styles Inconsistent use of IP addresses in ERO RESV_CONFIRM is not universally supported Explicit NULL label is not universally supported Discussion: Amir said that he was surprised that the presentation was being given before there was a white paper presented and said that the issue with explicit NULL labels is essentially because of a misunderstanding of the standard. Satoru Matsoshima asked about DU implementations that do not respond to requests for Labels. Rahul said that there implementation simply supports all of the possible ERO IP address usages. Amir commented on the ERO issue, saying this is critical. Loa said that the discussion should be continued on the list, thanked him for the report. J-P Vasseur MPLS Traffic Engineering Fast reroute: backup tunnel path computation for bandwidth protection ------------------------------------------------------------ P Vasseur: The draft addresses the charter item dealing with recovery mechanisms and focus on bandwidth protection issues. The draft proposes two basic approaches - centralized and distributed. It was pointed out that a Naive approach - using CSPF to setup backup paths - has two key problems: it cannot protect the bandwidth and it is possible that no solution can be found even though it can be shown that one must exist (as a result of timing). Examples of real life scenarios were given, in which bandwidth protection is needed. Bandwidth protection is needed for some traffic in some networks and input on the draft is solicited. Sven said that he is interested in this work. Loa suggested that comments on this work should be taken to the list. Seisho Yasukawa Extended RSVP-TE for Multicast LSP Tunnels -------------------------------------------------------- Seisho Yasukawa: The draft is about potential extensions for RSVP-TE for multicast LSPs. One of the things we propose in the draft is a grafting mechanism. A mechanism like this is needed e.g. for a VPLS service. It is appropriate that the multicast specifications should be discussed in the working group because the charter already includes work on the framework for multicast. Proposes that the WG should accept this draft as a WG draft. Saha asked if the draft required a multicast routing protocol, answer was that no multicast protocol is needed, but a function needed to determine the the multicast tree. Loa: This should be taken to the list. We are currently not prepared to take on new wg documents for multicast, we need a discussion to scope the multicast work within the mpls wg before we do that. That discussion should also be taken on the list. H.Hummel: "Hierarchical LSP" "O(n**2) investigations". ---------------------------------- Heinrich: The motivation for this work is to eliminate the n**2 problem via partial mesh of elementary tunnels. We have done tests and simulations to determine precise values for scalability associated with the use of hierarchical LSPs. Hierarchal LSPs is in scope for the charter by implication because of the existence of the label stack. Discussion deferred to list due to time constraints. Loa: WG and document status, Questions --------------------------------------------- 19 RFCs, latest is RFC 3270 on diff-serv. Multicast framework on the RFC-ED queue. 19 WG docs. 18 individual submissions. The issue here is that the individual submission are so numerous and diverge so much. This is a mature WG, and should be more focused. The wg documents: 5 under MIB doctor treatment. 6 documents under chair/AD (pre-IESG) review before going to IESG. 4 in WG last call. (FT completed just before meeting). 4 work in progress (incomplete). Meeting ended 11.30 AM. -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Fri Aug 2 10:46: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 KAA22325 for ; Fri, 2 Aug 2002 10:46:16 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnael01596 for ; Fri, 2 Aug 2002 14:47: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 QQnael00285; Fri, 2 Aug 2002 14:46:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnael22529 for mpls-outgoing; Fri, 2 Aug 2002 14:45: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 QQnael22516 for ; Fri, 2 Aug 2002 14:45:46 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 QQnael11811 for ; Fri, 2 Aug 2002 14:45: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 QQnael22927 for ; Fri, 2 Aug 2002 14:45:04 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQnael22909 for ; Fri, 2 Aug 2002 14:45:02 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 02 Aug 2002 18:34:24 +0530 Received: from maheshks (maheshks.future.futsoft.com [10.20.6.83]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id g72Cdtwl016338 for ; Fri, 2 Aug 2002 18:09:57 +0530 Reply-To: From: "Mahesh kumar S" To: Subject: RE: Downstream on Demand and Downstream Unsolicited - Interoperability Date: Fri, 2 Aug 2002 17:57:35 +0530 Message-Id: <001101c23a1f$fb6e4420$5306140a@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.2615.200 Importance: Normal In-Reply-To: <000001c2391f$040e2340$5306140a@future.futsoft.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, If any information can be provided for the following query, it will very much appreciated. Thanks and Regards, MK -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Mahesh kumar S Sent: Thursday, August 01, 2002 11:18 AM To: mpls@uu.net Subject: Downstream on Demand and Downstream Unsolicited - Interoperability Hi, RFC 3215 (LDP State Machine) which is informational gives precise directions on implementing the state machines for DOD Merge,Dod Non Merge and DU. Is it necessary for an implementation to support DOD Merge on one interface and DU on the other interface. If so, is there any informational RFC which specifies things as clearly as RFC 3215 for interoperability. Thanks in Advance. Regards, Maheshkumar *************************************************************************** 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. *************************************************************************** *************************************************************************** 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 Fri Aug 2 11:00: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 LAA22870 for ; Fri, 2 Aug 2002 11:00:32 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaem03665 for ; Fri, 2 Aug 2002 15:01: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 QQnaem02391; Fri, 2 Aug 2002 15:01:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaem26091 for mpls-outgoing; Fri, 2 Aug 2002 15:00: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 QQnaem25016 for ; Fri, 2 Aug 2002 15:00:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnael29119 for ; Fri, 2 Aug 2002 14:58: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 QQnael22961 for ; Fri, 2 Aug 2002 14:58:17 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 QQnael22957 for ; Fri, 2 Aug 2002 14:58:17 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 2 Aug 2002 10:58:16 -0400 Message-ID: <04b101c23a35$0868d180$681810ac@movaz.com> From: "Adrian Farrel" To: "'mpls@uu.net'" Cc: , "Paul Brittain" , "Eric Gray" , "Philip Matthews" , "Jack Shaio" , "Toby Smith" , "George Swallow" , "Loa Andersson" , "Adrian Farrel" References: <5.1.0.14.2.20020717215052.064a3e08@po1.vivacenetworks.com> <006a01c2310d$cbcc60a0$9b13588a@movaz.com> <3D3BE883.6010906@utfors.se> Subject: draft-ietf-mpls-ldp-ft-04.txt Date: Fri, 2 Aug 2002 10:58:16 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 02 Aug 2002 14:58:16.0989 (UTC) FILETIME=[087D1CD0:01C23A35] Sender: owner-mpls@UU.NET Precedence: bulk draft-ietf-mpls-ldp-ft-04.txt has been submitted and published. The only changes are minor and editorial after WG last call. Thanks to all who commented on and off the list. In summary the changes are: - add text and definitions to clarify when a label is a full FT label, when it is available for checkpointing and when it is not FT at all. - remove "changes from last edition" - simplify IANA section and be specific about intended values - renumber references and put them into a single section with two subsections. The authors would like to ask that the draft now moves forward to the IESG. Thanks, Adrian From owner-mpls@UU.NET Fri Aug 2 14:36: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 OAA00289 for ; Fri, 2 Aug 2002 14:36:56 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnafa03372 for ; Fri, 2 Aug 2002 18:38: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 QQnafa01967; Fri, 2 Aug 2002 18:37:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnafa09437 for mpls-outgoing; Fri, 2 Aug 2002 18:37: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 QQnafa09432 for ; Fri, 2 Aug 2002 18:37:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnafa21118 for ; Fri, 2 Aug 2002 18:37: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 QQnafa10743 for ; Fri, 2 Aug 2002 18:37:09 GMT Received: from zcars04e.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnafa10739 for ; Fri, 2 Aug 2002 18:37:08 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72Ib6Q27576 for ; Fri, 2 Aug 2002 14:37:07 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 14:37:06 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04D2A6AA@zcard031.ca.nortel.com> From: "David Allan" To: mpls@UU.NET Subject: MIB Question Date: Fri, 2 Aug 2002 14:37:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A53.98D17C7C" 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_01C23A53.98D17C7C Content-Type: text/plain; charset="iso-8859-1" I've been rummaging through MTU related stuff and not that there is no-where that record MTU discards (either MPLS MIBs or Interfaces group MIB). Agree that for IP, it's a big yawn and probably means someone is doing MTU discovery and is a non-problem. Issues is PWs where there is no payload fragmentation and VPNs where the packet payload has no provider routable addresses in it (no ICMP reply possible). IMHO the "use a big MTU" stipulation won't hold up forever, and some token effort to prepare for the future may be in order. Seems to me that it would be useful to have a counter in the LSR MIB for non-IP MTU discards (maybe with a threshold trap although I'll let my betters comment further) so that at least some indication of a problem was possible as currently packets simply "black hole". I'd suggest that the non-IP category would also include stack depth > 1 (e.g. 2547) as ideally path MTU handling for a VPN should be a PE problem. comments? Dave ------_=_NextPart_001_01C23A53.98D17C7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIB Question

I've been rummaging through MTU related stuff and not = that there is no-where that record MTU discards (either MPLS MIBs or = Interfaces group MIB). Agree that for IP, it's a big yawn and probably = means someone is doing MTU discovery and is a non-problem.

Issues is PWs where there is no payload fragmentation = and VPNs where the packet payload has no provider routable addresses in = it (no ICMP reply possible). IMHO the "use a big MTU" = stipulation won't hold up forever, and some token effort to prepare for = the future may be in order.   

Seems to me that it would be useful to have a counter = in the LSR MIB for non-IP MTU discards (maybe with a threshold trap = although I'll let my betters comment further) so that at least some = indication of a problem was possible as currently packets simply = "black hole". I'd suggest that the non-IP category would also = include stack depth > 1 (e.g. 2547) as ideally path MTU handling for = a VPN should be a PE problem.

comments?
Dave



------_=_NextPart_001_01C23A53.98D17C7C-- From owner-mpls@UU.NET Fri Aug 2 16:41: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 QAA05621 for ; Fri, 2 Aug 2002 16:41:55 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnafi04571 for ; Fri, 2 Aug 2002 20:43:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnafi03217; Fri, 2 Aug 2002 20:42:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnafi03251 for mpls-outgoing; Fri, 2 Aug 2002 20:42: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 QQnafi03246 for ; Fri, 2 Aug 2002 20:41: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 QQnafi14109 for ; Fri, 2 Aug 2002 20:41: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 QQnafi15544 for ; Fri, 2 Aug 2002 20:41:50 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 QQnafi15475 for ; Fri, 2 Aug 2002 20:41:49 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 g72Kflb21348 for ; Fri, 2 Aug 2002 16:41:47 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 22:41:46 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Loa Andersson , MPLS wg Subject: RE: draft minutes from Yokohama mpls meeting Date: Fri, 2 Aug 2002 22:41:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think I am missing two important pieces w.r.t. the MIBS and that is the main concerns and the status and next steps. They can be copied from my slides as I saw them. I think Loa added that we need at least another WG Last Call (once we see new revs) and that discussion is needed if things have become too complex and which pieces people have (or intend to) impement(ed). My slides showed: - Main concerns/worries: o How do Label Distribution Protocols, SNMP, Manual config, GSMP interact and make sure they do not step on each others toes?? o How are assignments under mplsMIB controlled? o Who is implementing all these Mibs? o How is the impact on follow up (G)MPLS MIBs? - Status/Action plan o Authors have answered a lot of comments and supposedly know what needs to be fixed. o Authors revising MIBs to address comments. Sofar I have received a new TC MIB, need revisions of all otehr MIBs o Then will need to re-review (MIB-Doctor) o I want the WG to re-review as well and make sure that you all agree, before it gets approved o Means another WG Last Call (or so I think) Thanks, Bert From owner-mpls@UU.NET Sun Aug 4 08:22: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 IAA03268 for ; Sun, 4 Aug 2002 08:22:47 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnall12745 for ; Sun, 4 Aug 2002 12:23: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 QQnall09055; Sun, 4 Aug 2002 12:21:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnall18315 for mpls-outgoing; Sun, 4 Aug 2002 12:21: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 QQnall18244 for ; Sun, 4 Aug 2002 12:21:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnall10011 for ; Sun, 4 Aug 2002 12:20: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 QQnall08310 for ; Sun, 4 Aug 2002 12:20:16 GMT Received: from smtp.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.cwnt.com [192.116.246.129]) id QQnall08294 for ; Sun, 4 Aug 2002 12:20:14 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft minutes from Yokohama mpls meeting X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Sun, 4 Aug 2002 15:20:13 +0300 Message-ID: Thread-Topic: draft minutes from Yokohama mpls meeting Thread-Index: AcI6G35JQYa+m8aCQ6GNGTxqSCUOsABlb1AQ From: "Amir Hermelin" To: "Loa Andersson" , "MPLS wg" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03268 Loa, my name is Amir Hermelin, and not Amir Hermilage ;-). If there's a non-draft edition, please correct. Thanks. -- Amir Hermelin < mailto:amir@cwnt.com> Charlotte's Web Networks Inc. < http://www.cwnt.com> >-----Original Message----- >From: Loa Andersson [mailto:loa.andersson@utfors.se] >Sent: Friday, August 02, 2002 2:51 PM >To: MPLS wg >Subject: draft minutes from Yokohama mpls meeting > > > >Included are the drafts minutes from the MPLS wg meeting in >Yokohama. Thanks to Dave and Eric who helped taking notes, >but have not repsonsibility for the delay in getting them >out to the list. > >Please comment. > >/Loa > > >IETF 54 MPLS WG Preliminary Notes > >Thursday July 12. 9 - 11.30 AM > >Chair - Loa Andersson (George Swallow not in attendance). >Note Takers - David Allan, Eric Gray > >Loa: >Agenda bashing >-------------- >- process reminders/blue sheets >- LDP MTU draft off the agenda >- No further comments on the agenda > > >Loa: >LDP (RFC 3036) to draft standard (status) >--------------------------------------------------- >Loa talked about the need to collect implementation information on >LDP for taking it to Draft Standard. >It is still not clear how many other rfc's that will be >affected, encap >and LDP draft, maybe also architecture. This is because of normative >references. >A survey form is developed and will be published on the list in a few >weeks, together with instructions on how to respond. Asked to include >an anonymity option. Scot Bradner will act as anynomizer". >Results will be published as an I-D. >One intention will be to simplify LDP, so unimplemented stuff will be >removed when LDP is moved to draft standard. > >Scott Bradner AD: >Current state of the issues in the mpls oam discussion and the ITU-T >liaison. >--------------------------------------------------------------- >-------------- >The background is that we have an I-D, by Hiroshi Otha, requesting a >reserved label to be used by ITU-T, for OAM. At the last meeting the >discussion concerned changes to IETF protocols that would result. As a >result a liaison was sent for clarification, asking if they >were operating >under the assumption that they would be requesting changes. > >Liaison response: Hiroshi Ohta (SG13 Rapporteur, slides included) > >Hiroshi Ohta presented a report on ITU-T's response to IETF's >liaison on >MPLS OAM. >He stated that they do not expect to impact IETF protocols and minimal >impact >on implementations. Y.1711 cannot work without the reserved label - >therefore, >they request that IANA assign a reserved label. > >Discussion >---------- >Rahul Aggarwal: The statement of no impact on forwarding plane is >inaccurate, >on egress LSRs there will be an impact. > > >Kireeti: If we allocate this label, will the ITU use this label >'efficiently', > in other words, will there be other requests. > >Scott: The ITU is finding that IETF protocols are popular, so >they want to >use them. He gave an example of the process using SIP. The >IETF decides >that protocols developed by IETF need to be reviewed by IETF when >extensions >are being proposed. > >Kireeti: there are two concerns, one is the IETF process >(which is good) >and the other is how far does this go? Do they need to go >through the RFC >process. > >Scott: This may be dealt with in many ways, however we hope that the >cooperative approach will work. > >Scott asked the sense of the room: >We have an I-D seeking assignment, we've interacted to find >out answers to >questions we've asked. I think this is a good thing, both >cooperatively and >for the good of the protocol. MPLS is being used in a number of >environments, >and the usage assumptions are different depending on the carrier. We >need to >support the IP carrier, but that is not all of them. In that >context we >should >be open to the use of our protocols in other environments. For MPLS to >be seen >as useful in trad telco environments it needs this stuff. > >Hummm (a few raised hands :)) showed a consensus for RFC >publishing the >draft >and issuing the label. > > >Scott Bradner: >rsvp-te vs. cr-ldp, initiating a discussion >----------------------------------------------- >In the implementation survey for GMPLS, there was lots of RSVP and >little CR-LDP. >Concern in ISEG on multiple standards track ways of doing something is >confusing to >the market place. Don't need to visit the history. Don't think we need >to stop >publishing CR-LDP, but should they be informational or standards track. > >Discussion: >---------- > >Loa: The intent of having this agenda item is to initiate the >discussion, not >arrive at a conclusion at this meeting. > >Bilel Jamoussi: Comment on the survey. Did not state the objective or >indicate >how it was going to be used. Not scientific by any means. More >importantly GMPLS >is a new thing, carriers are still debating the architectures. >Think the >discussion >is premature. There are today several networks running CR-LDP >in a packet >environment. > >Bert: Purpose of survey was to seek an implementation report before >approving >GMPLS. This was an artifact of the survey not the intent. I >don't think >discussion >is premature, a decision may be. Folks can still implement >informational. Within >one org you would normally try to go for one standard. > >Kireeti: I wear several hats. CCAMP chair, twice as many protocol >extensions >because of two protocols. Have to write two sets of drafts as an >author. Have to >read twice as many. As a vendor I do not care, and do not >implement it. >Impact on >IETF is twice as much material. > >Luca Martini: as a service provider, we found RSVP predominantly >deployed and >implemented. Pushed by a particular vendor for an obscure reason. We >should shift >CR-LDP to informational. > >Ron Bonica: Like to second what Luca said. IETF produces too much >technology to >do a good job. Lets prune. > >Chris Liljenstolpe: Third what Luca said. > >Osama Aboul-Magd: From transport POV, the market is really slow so >deployment is >pretty much nonexistent. This is not an indicator. > >Joel Halpern: Helped work on CR-LDP, technically prefer it. That's >irrelevant, >its not about what is technically better, RSVP won the fight. > >Bilel: Agree on one application. Not necessarily so for optical >transport. For >packet TE, RSVP has one the fight. In optical it is premature. >So Packet >TE it >is overwhelmingly RSVP, but GMPLS it is premature. Folks are >building on >the CR-LDP. >There are other examples of multiple protocols. > >Bert: Past potential mistakes are not necessarily an indication of what >we should do in the future. In this case one far outweighs the other. > >Chippy: We don't support it because we have no customer demand. > >Ludo Practico: We support both and get interest in both. > >Discussion to move to the mailing list. > >Loa: Confine it to the MPLS list, but we'll send mail to the other >sub-ip list >informing them about the discussion. > > >Bert Wijnen >Status and issues with the mpls mibs >----------------------------------------------- >We have lots of MPLS MIBs. Although separately they looks OK, >there was >a lot of >overlaps (TCs and the like, some conflicting). Shows authors >not working >together, >and no cross review of how they play together. No discontinuity timers >for counters, >or how MIBs relate to each other. etc. etc. >Several issues, including inconsistencies and duplicated uses. >Also, there are uses defined that are not consistent with common usage >elsewhere. Some MIBs have already become RFCs and others have >been held >up in >queue for corrections. There is a draft that attempt to capture the >relationships >between various MIBs, but this does not do quite enough. Also, there >are some >MIBs that are fairly 'all-inclusive' and it is not clear that this is >always a >good thing. Also, there are differences in the 'tolerance' levels for >various >MIB compilers and this results in MIBs that do not compile >using some MIB >compilers. >We would also like to see better communications between various MIB >development >efforts. We would also like to see who is implementing which MIBs. >Finally, people should get help for MIBs at mibs@ops.ietf.org >or by asking >SNMP/MIB advisor for the working group. If there is no >SNMP/MIB advisor, >get one. > >Marcus: We have actually implemented some MIBs only partially. > >Bert: The correct way to work through this is to talk about >these issues >on the public mailing list so that everyone can benefit from >understanding the >issues and answers. > >Kireeti: Asked if Marcus had tried the TE-WG MIB. > >Marcus Brunner: I were actually referring to the LSR MIB. > >Vach Kompella: I've had issues with the LDP MIB and we've also >implemented >a proprietary MIB that supports a subset of the MIB. > >Bert: The LSR MIB is in IESG review at this time. We had reports >that people are implementing the LDP MIB. > > >Loa: My impression is that the MIBs have become complicated and >uncoordinated. My feeling that we still need to think about what to do >next. It is at least clear that enough changes have occurred >since the >last >set of last calls that another set will be required. > > > >Andy Malis >Status of LDP restart and LDP fault tolerance drafts >Fault Tolerance for LDP and CR-LDP >Graceful Restart Mechanism for LDP >--------------------------------------------------------------- >---------- >Andy: The latest status is that the LDP FT draft was >successfully merged >with the Smith (check-pointing) draft. >The LDP Restart draft actually has a different applicability with very >little overlap. The last call has been completed, George Swallow has >proposed some changes, some minor editing has to be done and >then the draft >should go to the IESG. > > >Sven van den Bosch >Further considerations for Forwarding Adjacency LSPs > >-------------------------------------------------------------- >Sven van den Bosch : This is version one of the document, >related to LSP >hierarchy 07 WG draft. > >The issues addressed is complex resources classes and a new >sub-class of >TLVs >is proposed >Alternatively it could be possible to approach the IS-IS and >OSPF wg's and >suggest that they define extensions to the protocols. > >Amir Hermilage: Is it the the goal of this draft is to be merged into >other work. > >Sven: The intent is for this to be a separate draft. > >Kireeti: Not sure that all cases of complex resource classes can be >represented. >Sven: I'm aware that there is at least one case that his >proposal does >not cover, >but also feels that there is a real need to solve a subset of the >problem space >that his proposal does address. > > >Loa: Take this back to the list and make a decision once all the >implications >are clear. > > >B Jensen:(University of Wisconsin) >General Summary of Interoperability Testing Results and Experiences > >-------------------------------------------- >There are interoperability efforts from several organizatios >e.g. UNH, AIL, >MPLS Forum etc. There has been private tests in April, NI in >May, and then >Supercom. White paper will available from MPLS forum. >The Draft is key findings from April, test configuration are >shown in the >slides. >IP transport, plus L2 and L3 VPN apps (2547/Martini Ethernet), POS and >GigE plus >some ATM. Has been tested. >Issues found: > OSPF TE is not universally supported even though required for TE LSPs > Vendor implementations only support a single distribution >mode (DU/DoD) > Not all RSVP-TE implementations support both FF and SE >reservation styles > Inconsistent use of IP addresses in ERO > RESV_CONFIRM is not universally supported > Explicit NULL label is not universally supported > >Discussion: >Amir said that he was surprised that the presentation was >being given before >there was a white paper presented and said that the issue with >explicit NULL >labels is essentially because of a misunderstanding of the standard. > >Satoru Matsoshima asked about DU implementations that do not respond to >requests for Labels. > >Rahul said that there implementation simply supports all of >the possible >ERO IP address usages. > >Amir commented on the ERO issue, saying this is critical. > >Loa said that the discussion should be continued on the list, thanked >him for the report. > > >J-P Vasseur >MPLS Traffic Engineering Fast reroute: backup tunnel path >computation for >bandwidth protection > >------------------------------------------------------------ >P Vasseur: The draft addresses the charter item dealing with recovery >mechanisms and focus on bandwidth protection issues. The >draft proposes >two basic approaches - centralized and distributed. It was >pointed out that >a Naive approach - using CSPF to setup backup paths - has two >key problems: >it cannot protect the bandwidth and it is possible that no >solution can >be found >even though it can be shown that one must exist (as a result >of timing). >Examples >of real life scenarios were given, in which bandwidth >protection is needed. >Bandwidth protection is needed for some traffic in some networks and >input on the >draft is solicited. > >Sven said that he is interested in this work. > >Loa suggested that comments on this work should be taken to the list. > > >Seisho Yasukawa >Extended RSVP-TE for Multicast LSP Tunnels > >-------------------------------------------------------- >Seisho Yasukawa: The draft is about potential extensions for >RSVP-TE for >multicast >LSPs. One of the things we propose in the draft is a grafting >mechanism. A >mechanism like this is needed e.g. for a VPLS service. It is >appropriate that the multicast specifications should be discussed in >the working >group because the charter already includes work on the framework for >multicast. >Proposes that the WG should accept this draft as a WG draft. > >Saha asked if the draft required a multicast routing protocol, answer >was that >no multicast protocol is needed, but a function needed to determine the >the multicast tree. > >Loa: This should be taken to the list. We are currently not >prepared to take >on new wg documents for multicast, we need a discussion to scope the >multicast >work within the mpls wg before we do that. That discussion should also >be taken >on the list. > > >H.Hummel: >"Hierarchical LSP" > >"O(n**2) investigations". > >---------------------------------- >Heinrich: The motivation for this work is to eliminate the >n**2 problem >via >partial mesh of elementary tunnels. We have done tests and >simulations to >determine precise values for scalability associated with the >use of hierarchical LSPs. Hierarchal LSPs is in scope for the >charter by >implication because of the existence of the label stack. >Discussion deferred to list due to time constraints. > >Loa: >WG and document status, Questions >--------------------------------------------- >19 RFCs, latest is RFC 3270 on diff-serv. Multicast framework on the >RFC-ED queue. >19 WG docs. 18 individual submissions. >The issue here is that the individual submission are so >numerous and diverge >so much. This is a mature WG, and should be more focused. > >The wg documents: > >5 under MIB doctor treatment. >6 documents under chair/AD (pre-IESG) review before going to IESG. >4 in WG last call. (FT completed just before meeting). >4 work in progress (incomplete). > >Meeting ended 11.30 AM. >-- > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > Råsundavägen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se > > > From owner-mpls@UU.NET Mon Aug 5 03:20: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 DAA03824 for ; Mon, 5 Aug 2002 03:20:18 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaoj10953 for ; Mon, 5 Aug 2002 07: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 QQnaoj09309; Mon, 5 Aug 2002 07:20:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaoj14951 for mpls-outgoing; Mon, 5 Aug 2002 07:20: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 QQnaoj14946 for ; Mon, 5 Aug 2002 07:20: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 QQnaoj10109 for ; Mon, 5 Aug 2002 07:20: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 QQnaoj14714 for ; Mon, 5 Aug 2002 07:20:10 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQnaoj14670 for ; Mon, 5 Aug 2002 07:20:08 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 05 Aug 2002 13:13:04 +0530 Received: from arumugamr (arumugamr.future.futsoft.com [10.20.6.33]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id g757Jjli019005; Mon, 5 Aug 2002 12:49:46 +0530 Message-Id: <00fd01c23c51$7dfc4ee0$2106140a@future.futsoft.com> Reply-To: "Arumugamr" From: "Arumugamr" To: "David Charlap" , Subject: Questions in RSVP-TE refresh reduction. Date: Mon, 5 Aug 2002 12:56:55 +0530 Organization: Future Software Ltd MIME-Version: 1.0 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 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am not sure, whether this is the right forum to ask the question, but since the RR feature is very much needed for the MPLS-RSVPTE I am posting this question. 1. RFC 2961 states two methods of refresh overhead reductions namely the Bundle and SRefresh mechanism. If an implementation supports RR, then it has to support the both extensions. SRefresh has an advantage over Bundling in terms conserving bandwidth and processing overhead. Is there any specific scenario, wherein the Bundle message is advantageous over SRefresh message. 2. RFC 3209 section 5 Hello extn states that the Hello message can be included in the Bundle message. The usage of hello is for rapid node failure detection, wherein the Bundle message is for reducing the refresh overhead. Eventhough thousands of refreshes are sent to the neighbour there will be only one hello message sent to the neighbour. Also the delay in hello being sent can result in the other node to assume the peer has reset. Is there any specific reason behind the hello messages being bundled. 3. In RFC 2961 section 4.5 states that "If a Path or Resv message contains the same Message_Identifier value that was used in the most recently received message for the same session and, for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat the message as a state refresh. " With respect to the above statement, I have the following questions. a) In Accordance to RFC 3209, assume Refreshes with MsgIds (SRefresh probably) are going between Ingress/Egress and its immediate neighbour. Also the refresh messages carry RRO's. When RRO too large for MTU error message is received, the Ingress(In case of PATH msg)/Egress(In case of Resv message) should have to stop sending RRO's. Now the question being the Refresh message without RRO will be send with the same MsgId, which was used for the previous session (or) will be a new one. Since an implementation on receiving a message with the same MsgId, Session and SenderTemplate, if it treats it as the refresh and fails to updates the RRO removal indication, the node that generated the error will still retransmit the error msg. Which MsgId should be transmitted Old/New. b) Also in the RRO's flags may toggle because of some local failure detection & recovery process. In these cases the MsgId Should be a Newly generated/Old one being retransmitted.. I welcome your comments Thanks and Regards Arumugam R *************************************************************************** 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 Aug 5 09:52: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 JAA13169 for ; Mon, 5 Aug 2002 09:52:15 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnapj12441 for ; Mon, 5 Aug 2002 13:53: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 QQnapj11189; Mon, 5 Aug 2002 13:52:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnapj27367 for mpls-outgoing; Mon, 5 Aug 2002 13:52: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 QQnapj27362 for ; Mon, 5 Aug 2002 13:52: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 QQnapj04211 for ; Mon, 5 Aug 2002 13:52: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 QQnapj10747 for ; Mon, 5 Aug 2002 13:52:03 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 QQnapj10728 for ; Mon, 5 Aug 2002 13:52:02 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 JAA22126 for ; Mon, 5 Aug 2002 09:52:01 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20335 for ; Mon, 5 Aug 2002 09:52:02 -0400 (EDT) Message-ID: <3D4E830E.4070408@marconi.com> Date: Mon, 05 Aug 2002 09:52:14 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Questions in RSVP-TE refresh reduction. References: <00fd01c23c51$7dfc4ee0$2106140a@future.futsoft.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 Arumugamr wrote: > > 1. RFC 2961 states two methods of refresh overhead reductions namely the > Bundle and SRefresh mechanism. If an implementation supports RR, then it has > to support the both extensions. SRefresh has an advantage over Bundling in > terms conserving bandwidth and processing overhead. Is there any specific > scenario, wherein the Bundle message is advantageous over SRefresh message. The two message types serve different purposes. Bundle messages reduce IP packet processing overhead in the stack. On some platforms, the act of looking in the IP header to determine whether it is to be processed locally or not (by comparing destination address and looking for the router alert option) can consume significant CPU resources. Bundling messages together reduces this overhead by reducing the number of packets sent/received. SRefresh, on the other hand, has to do with the CPU and bandwidth overhead of having to retransmit all Path and Resv state messages. IMO, this factor contributes much more to the RSVP's scalability issues than Bundle messages do. If you set the "RR capable" bit in your common header, then you must be prepared to support both types of incoming messages. You do not have to generate both as outgoing messages, however. > 2. RFC 3209 section 5 Hello extn states that the Hello message can be > included in the Bundle message. The usage of hello is for rapid node failure > detection, wherein the Bundle message is for reducing the refresh overhead. > Eventhough thousands of refreshes are sent to the neighbour there will be > only one hello message sent to the neighbour. Also the delay in hello being > sent can result in the other node to assume the peer has reset. Is there > any specific reason behind the hello messages being bundled. Just generality. Any message, other than another Bundle, may be bundled. It doesn't say you have to do this, though. Personally, I agree with you - that you would not be able to get the rapid response necessary if Hello messages are bundled. A router receiving RSVP messages may choose to prioritize messages in the IP stack, in order to allow Hellos to be processed ahead of other messages. It may also choose to implement Hello in a line-card's firmware, in order to improve response time. Including Hello in Bundle breaks both of these optimizations. > 3. In RFC 2961 section 4.5 states that > > "If a Path > or Resv message contains the same Message_Identifier value that was > used in the most recently received message for the same session and, > for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat the > message as a state refresh. " > > With respect to the above statement, I have the following questions. > > a) In Accordance to RFC 3209, assume Refreshes with MsgIds (SRefresh > probably) are going between Ingress/Egress and its immediate neighbour. Also > the refresh messages carry RRO's. When RRO too large for MTU error message > is received, the Ingress(In case of PATH msg)/Egress(In case of Resv > message) should have to stop sending RRO's. Now the question being the > Refresh message without RRO will be send with the same MsgId, which was used > for the previous session (or) will be a new one. If the message changes, then you must generate a new message ID. Otherwise the neighbor may ignore your changes. It doesn't matter if this is something really significant like a TSpec or something less important, like an RRO. > Since an implementation on receiving a message with the same MsgId, > Session and SenderTemplate, if it treats it as the refresh and fails to > updates the RRO removal indication, the node that generated the error will > still retransmit the error msg. Which MsgId should be transmitted Old/New. No. An SRefresh does not force the neighbor to re-transmit any errors that the original message caused. If the error message was something serious (like bad TSpec or something), then corresponding state was never installed - meaning an SRefresh of it will result in a NACK (since the message ID doesn't match any installed state), and a normal refresh will result in a re-attempt to install that state, since there's no way of knowing that the message ID was previously used. If the error message was something that doesn't prevent state installation (like an RRO growing too large), then either kind of refresh will simply have no effect. Which is as it should be - why should you be continuously spewing out Notify messages? > b) Also in the RRO's flags may toggle because of some local failure > detection & recovery process. In these cases the MsgId Should be a Newly > generated/Old one being retransmitted.. Again, if you are changing any part of the message, then you must generate a new message ID. If you don't then your changes may be ignored by the router that receives the message. -- David From owner-mpls@UU.NET Mon Aug 5 13:28: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 NAA23419 for ; Mon, 5 Aug 2002 13:28:46 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnapx00875 for ; Mon, 5 Aug 2002 17:29: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 QQnapx29496; Mon, 5 Aug 2002 17:29:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnapx13298 for mpls-outgoing; Mon, 5 Aug 2002 17: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 QQnapx13293 for ; Mon, 5 Aug 2002 17:28:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnapx28770 for ; Mon, 5 Aug 2002 17:28: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 QQnapx16067 for ; Mon, 5 Aug 2002 17:28:40 GMT Received: from dharti.aplion.stpn.soft.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQnapx16039 for ; Mon, 5 Aug 2002 17:28:36 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g75HUBJ12340 for ; Mon, 5 Aug 2002 23:00:11 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Subject: Layer 3 Lookup in ATM LSR's Date: Mon, 5 Aug 2002 23:02:29 +0530 Message-ID: <014a01c23ca6$132d5190$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 i have a query which , you all might be able to answer:- it is said that atm switches in the core atm networks do not have layer 3 lookup capability. Now the standards say that when atm lsr's do not have a layer 3 lookup capability then they operate in Ordered control with down stream on demand mode of label distribution. lets say that i have the following mpls domain :- a--------b---------c-------d | |-------k 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are operating in Ordered Control with DownStream on Demand Label Distribution method. Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a label request for a particular fec , sees that it has no downstream mapping for that fec. Since 'b' is operating in ordered control , it further sends a label request to c (and not to k) since it cannot allocate a label for the requested fec . 'c' would also further send the label request to 'd' and then 'd' would reply with a label mapping message. I hope that it's correct till this point. My question is, how does 'b' know , that in order to send a label request for a particular fec, what is the next hop for that fec when it does not have a layer 3 capability. why would 'b' send a label request to 'c' and not to 'k' ???? i hope i have made my point clear Please tell me where am i wrong thanks and regards mayank From owner-mpls@UU.NET Mon Aug 5 14:00: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 OAA24846 for ; Mon, 5 Aug 2002 14:00:22 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqa13914 for ; Mon, 5 Aug 2002 18:01: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 QQnaqa12825; Mon, 5 Aug 2002 18:01:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqa18282 for mpls-outgoing; Mon, 5 Aug 2002 18:00: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 QQnaqa17926 for ; Mon, 5 Aug 2002 18:00: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 QQnapz23471 for ; Mon, 5 Aug 2002 17:59: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 QQnapz03627 for ; Mon, 5 Aug 2002 17:59:13 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 QQnapz03618 for ; Mon, 5 Aug 2002 17:59:13 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFLRV>; Mon, 5 Aug 2002 13:59:13 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671F4@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'mkumar@aplion.stpn.soft.net'" Cc: "Mpls (E-mail)" Subject: RE: Layer 3 Lookup in ATM LSR's Date: Mon, 5 Aug 2002 13:59:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Mayank, The standards say that an ATM LSR does have L3 lookup capability. Specifically, RFC 3035 says about ATM LSRs: " ... ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers)." I am not sure what standards you were referring to. If an ATM Switch is to participate in label switching, it must be able to unambiguously determine how to forward labeled packets. It is possible to implement ATM switches that participates in label switching without themselves participating in routing by ensuring that the determination on how to forward labeled packets is made for them. As an example, this might be done by always using strict explicit routing relative to the ATM switch in question and immediate downstream neighbors. Such ATM switches are not ATM LSRs. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Monday, August 05, 2002 1:32 PM To: Mpls (E-mail) Subject: Layer 3 Lookup in ATM LSR's hi i have a query which , you all might be able to answer:- it is said that atm switches in the core atm networks do not have layer 3 lookup capability. Now the standards say that when atm lsr's do not have a layer 3 lookup capability then they operate in Ordered control with down stream on demand mode of label distribution. lets say that i have the following mpls domain :- a--------b---------c-------d | |-------k 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are operating in Ordered Control with DownStream on Demand Label Distribution method. Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a label request for a particular fec , sees that it has no downstream mapping for that fec. Since 'b' is operating in ordered control , it further sends a label request to c (and not to k) since it cannot allocate a label for the requested fec . 'c' would also further send the label request to 'd' and then 'd' would reply with a label mapping message. I hope that it's correct till this point. My question is, how does 'b' know , that in order to send a label request for a particular fec, what is the next hop for that fec when it does not have a layer 3 capability. why would 'b' send a label request to 'c' and not to 'k' ???? i hope i have made my point clear Please tell me where am i wrong thanks and regards mayank From owner-mpls@UU.NET Mon Aug 5 14:23: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 OAA25647 for ; Mon, 5 Aug 2002 14:23:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqb06516 for ; Mon, 5 Aug 2002 18:24: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 QQnaqb04199; Mon, 5 Aug 2002 18:22:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqb09791 for mpls-outgoing; Mon, 5 Aug 2002 18:22:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnaqb09784 for ; Mon, 5 Aug 2002 18:22: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 QQnaqb08506 for ; Mon, 5 Aug 2002 18:21:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqb01946 for ; Mon, 5 Aug 2002 18:21:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnaqb01929 for ; Mon, 5 Aug 2002 18:21:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA10932 for ; Mon, 5 Aug 2002 14:21:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA14054 for mpls@uu.net; Mon, 5 Aug 2002 14:21:01 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnaqb09591 for ; Mon, 5 Aug 2002 18:20: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 QQnaqb28359 for ; Mon, 5 Aug 2002 18:19:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqb00841 for ; Mon, 5 Aug 2002 18:19:24 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnaqb00837 for ; Mon, 5 Aug 2002 18:19:24 GMT 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 OAA10832; Mon, 5 Aug 2002 14:19:23 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA10123; Mon, 5 Aug 2002 14:19:23 -0400 (EDT) Date: Mon, 5 Aug 2002 14:19:23 -0400 From: Eric Osborne To: "Gray, Eric" Cc: "'mkumar@aplion.stpn.soft.net'" , "Mpls (E-mail)" Subject: Re: Layer 3 Lookup in ATM LSR's Message-ID: <20020805181923.GL8579@eosborne-u10.cisco.com> References: <1117F7D44159934FB116E36F4ABF221B022671F4@celox-ma1-ems1.celoxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117F7D44159934FB116E36F4ABF221B022671F4@celox-ma1-ems1.celoxnetworks.com> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Aug 05, 2002 at 01:59:06PM -0400, Gray, Eric wrote: > Mayank, > > The standards say that an ATM LSR does have L3 > lookup capability. Specifically, RFC 3035 says about > ATM LSRs: > > " ... ATM switches run network layer routing algorithms > (such as Open Shortest Path First (OSPF), Intermediate > System to Intermediate System (IS-IS), etc.), and their > data forwarding is based on the results of these routing > algorithms. No ATM-specific routing or addressing is > needed. ATM switches used in this way are known as > ATM-LSRs (Label Switching Routers)." To me, that doesn't say L3 lookup capability. I could certainly see an ATM LSR implementation that used L3 for two things: - maintaining IGP adjacencies - deciding which interfaces to signal on-demand labels ...but none of that implies that an ATM LSR should be prepared to forward received data packets. > > I am not sure what standards you were referring to. > > If an ATM Switch is to participate in label switching, it > must be able to unambiguously determine how to forward > labeled packets. It is possible to implement ATM switches > that participates in label switching without themselves > participating in routing by ensuring that the determination > on how to forward labeled packets is made for them. As an > example, this might be done by always using strict explicit > routing relative to the ATM switch in question and immediate > downstream neighbors. Such ATM switches are not ATM LSRs. I disagree; I think there's a difference between "L3 lookup" (which to me implies forwarding) and simply running a local IP stack for things which originate/terminate on that router. eric > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] > Sent: Monday, August 05, 2002 1:32 PM > To: Mpls (E-mail) > Subject: Layer 3 Lookup in ATM LSR's > > hi > i have a query which , you all might be able to answer:- > > it is said that atm switches in the core atm networks do not have layer 3 > lookup capability. > Now the standards say that when atm lsr's do not have a layer 3 lookup > capability then they operate in Ordered control with down stream on demand > mode of label distribution. > > lets say that i have the following mpls domain :- > > a--------b---------c-------d > | > |-------k > > 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are > operating in Ordered Control with DownStream on Demand Label Distribution > method. > Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' > > 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a > label request for a particular fec , sees that it has no downstream mapping > for that fec. Since 'b' is operating in ordered control , it further sends a > label request to c (and not to k) since it cannot allocate a label for the > requested fec . 'c' would also further send the label request to 'd' and > then 'd' would reply with a label mapping message. > > I hope that it's correct till this point. > > My question is, how does 'b' know , that in order to send a label request > for a particular fec, what is the next hop for that fec when it does not > have a layer 3 capability. > why would 'b' send a label request to 'c' and not to 'k' ???? > > > i hope i have made my point clear > > > Please tell me where am i wrong > > thanks and regards > mayank > > > From owner-mpls@UU.NET Mon Aug 5 14:37: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 OAA26429 for ; Mon, 5 Aug 2002 14:37:10 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqc13292 for ; Mon, 5 Aug 2002 18:38: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 QQnaqc11595; Mon, 5 Aug 2002 18:37:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqc10554 for mpls-outgoing; Mon, 5 Aug 2002 18:37: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 QQnaqc10549 for ; Mon, 5 Aug 2002 18:36: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 QQnaqc22471 for ; Mon, 5 Aug 2002 18:36: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 QQnaqc10759 for ; Mon, 5 Aug 2002 18:36:04 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 QQnaqc10741 for ; Mon, 5 Aug 2002 18:36:04 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFLV5>; Mon, 5 Aug 2002 14:36:04 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671F5@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Eric Osborne'" , "Gray, Eric" Cc: "'mkumar@aplion.stpn.soft.net'" , "Mpls (E-mail)" Subject: RE: Layer 3 Lookup in ATM LSR's Date: Mon, 5 Aug 2002 14:35:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric O. You're interpreting confusion into existence. :-) L3 lookup should mean the ability to make a determination on how to forward packets _without_ necessarily implying capability to forward packets with any particular capacity. L3 forwarding, on the other hand, might encompass what you refer to, but not necessarily. Lookup and forwarding functions are distinct, even if clearly not orthogonal. The ability to look something up in no way implies the ability to do anything in particular with the results. However, Mayank's question implies that - by L3 lookup - Mayank meant the ability to determine how to forward packets. Otherwise, the question of how to determine which downstream to request a label of would have been unnecessary since the ability to determine how to forward packets would be used in determining how to forward requests. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Eric Osborne [mailto:eosborne@cisco.com] Sent: Monday, August 05, 2002 2:19 PM To: Gray, Eric Cc: 'mkumar@aplion.stpn.soft.net'; Mpls (E-mail) Subject: Re: Layer 3 Lookup in ATM LSR's On Mon, Aug 05, 2002 at 01:59:06PM -0400, Gray, Eric wrote: > Mayank, > > The standards say that an ATM LSR does have L3 > lookup capability. Specifically, RFC 3035 says about > ATM LSRs: > > " ... ATM switches run network layer routing algorithms > (such as Open Shortest Path First (OSPF), Intermediate > System to Intermediate System (IS-IS), etc.), and their > data forwarding is based on the results of these routing > algorithms. No ATM-specific routing or addressing is > needed. ATM switches used in this way are known as > ATM-LSRs (Label Switching Routers)." To me, that doesn't say L3 lookup capability. I could certainly see an ATM LSR implementation that used L3 for two things: - maintaining IGP adjacencies - deciding which interfaces to signal on-demand labels ...but none of that implies that an ATM LSR should be prepared to forward received data packets. > > I am not sure what standards you were referring to. > > If an ATM Switch is to participate in label switching, it > must be able to unambiguously determine how to forward > labeled packets. It is possible to implement ATM switches > that participates in label switching without themselves > participating in routing by ensuring that the determination > on how to forward labeled packets is made for them. As an > example, this might be done by always using strict explicit > routing relative to the ATM switch in question and immediate > downstream neighbors. Such ATM switches are not ATM LSRs. I disagree; I think there's a difference between "L3 lookup" (which to me implies forwarding) and simply running a local IP stack for things which originate/terminate on that router. eric > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] > Sent: Monday, August 05, 2002 1:32 PM > To: Mpls (E-mail) > Subject: Layer 3 Lookup in ATM LSR's > > hi > i have a query which , you all might be able to answer:- > > it is said that atm switches in the core atm networks do not have layer 3 > lookup capability. > Now the standards say that when atm lsr's do not have a layer 3 lookup > capability then they operate in Ordered control with down stream on demand > mode of label distribution. > > lets say that i have the following mpls domain :- > > a--------b---------c-------d > | > |-------k > > 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are > operating in Ordered Control with DownStream on Demand Label Distribution > method. > Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' > > 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a > label request for a particular fec , sees that it has no downstream mapping > for that fec. Since 'b' is operating in ordered control , it further sends a > label request to c (and not to k) since it cannot allocate a label for the > requested fec . 'c' would also further send the label request to 'd' and > then 'd' would reply with a label mapping message. > > I hope that it's correct till this point. > > My question is, how does 'b' know , that in order to send a label request > for a particular fec, what is the next hop for that fec when it does not > have a layer 3 capability. > why would 'b' send a label request to 'c' and not to 'k' ???? > > > i hope i have made my point clear > > > Please tell me where am i wrong > > thanks and regards > mayank > > > From owner-mpls@UU.NET Mon Aug 5 14:41: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 OAA26729 for ; Mon, 5 Aug 2002 14:41:38 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqc01029 for ; Mon, 5 Aug 2002 18:42: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 QQnaqc29909; Mon, 5 Aug 2002 18:42:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqc10719 for mpls-outgoing; Mon, 5 Aug 2002 18:41: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 QQnaqc10713 for ; Mon, 5 Aug 2002 18:41: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 QQnaqc10173 for ; Mon, 5 Aug 2002 18:41: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 QQnaqc20455 for ; Mon, 5 Aug 2002 18:41:40 GMT Received: from dharti.aplion.stpn.soft.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQnaqc20328 for ; Mon, 5 Aug 2002 18:41:37 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g75IgxN14101; Tue, 6 Aug 2002 00:12:59 +0530 Reply-To: From: "Mayank Kumar" To: "'Gray, Eric'" Cc: "Mpls \(E-mail\)" Subject: RE: Layer 3 Lookup in ATM LSR's Date: Tue, 6 Aug 2002 00:15:18 +0530 Message-ID: <014f01c23cb0$3fa53ee0$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 In-Reply-To: <1117F7D44159934FB116E36F4ABF221B022671F4@celox-ma1-ems1.celoxnetworks.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi Eric, then why is it recommended that in atm backbones running mpls,we should use Downstream on Demand with Ordered LSP Control. What advantages does it provide ??? My doubt arose because i have been reading a book from cisco press named "MPLS And VPN architectures" by Ivan Pepelnjak and Jim Guichard. the book on pg 57 says that "the label allocation and distribution process accross the atm-lsr domain has the following characteristics:- --Label allocation in devices with layer 3 lookup capabilites (routers ) is done regardless of whether the router has already received a label for the same prefix from its next hop router . Label allocation in routers is thus called independent control. --label allocation in devices with no layer 3 lookup capabilites (atm switches) is performed only if a corresponding downstream label has already been allocated . Label allocation in atm swicthes is thus Ordered control." the book further says that "the downstream lsr could simply allocate a label and respond to the request from the upstream lsr with a corresponding reply message. Under some circumstances , this action would require the downstream lsr to have layer 3 lookup capability (such as if the downstream lsr would have no further downstream label for the requested destination). Therefore , the atm swicthes never respond to a label allocation request unless they already have a corresponding downstream label allocated" What does that mean ??? And do u want to say that an LSR always has a layer 3 lookup capabilites irrespective of whether it is an atm lsr or frame based lsr. I think Eric is right in his reply ??? I think that Layer 3 Lookup implies , being able to process the IP header while forwarding packets and thus being able to make a forwarding decision based on the destination ip address. Atm swicthes do form routing adjacencies on the control vc but they dont have layer 3 lookup capability. Why does the Book say then , that label allocation in atm swicthes is Ordered. What advantage does that provide ??? thanks and reagards Mayank -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: Monday, August 05, 2002 11:29 PM To: 'mkumar@aplion.stpn.soft.net' Cc: Mpls (E-mail) Subject: RE: Layer 3 Lookup in ATM LSR's Mayank, The standards say that an ATM LSR does have L3 lookup capability. Specifically, RFC 3035 says about ATM LSRs: " ... ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers)." I am not sure what standards you were referring to. If an ATM Switch is to participate in label switching, it must be able to unambiguously determine how to forward labeled packets. It is possible to implement ATM switches that participates in label switching without themselves participating in routing by ensuring that the determination on how to forward labeled packets is made for them. As an example, this might be done by always using strict explicit routing relative to the ATM switch in question and immediate downstream neighbors. Such ATM switches are not ATM LSRs. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Monday, August 05, 2002 1:32 PM To: Mpls (E-mail) Subject: Layer 3 Lookup in ATM LSR's hi i have a query which , you all might be able to answer:- it is said that atm switches in the core atm networks do not have layer 3 lookup capability. Now the standards say that when atm lsr's do not have a layer 3 lookup capability then they operate in Ordered control with down stream on demand mode of label distribution. lets say that i have the following mpls domain :- a--------b---------c-------d | |-------k 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are operating in Ordered Control with DownStream on Demand Label Distribution method. Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a label request for a particular fec , sees that it has no downstream mapping for that fec. Since 'b' is operating in ordered control , it further sends a label request to c (and not to k) since it cannot allocate a label for the requested fec . 'c' would also further send the label request to 'd' and then 'd' would reply with a label mapping message. I hope that it's correct till this point. My question is, how does 'b' know , that in order to send a label request for a particular fec, what is the next hop for that fec when it does not have a layer 3 capability. why would 'b' send a label request to 'c' and not to 'k' ???? i hope i have made my point clear Please tell me where am i wrong thanks and regards mayank From owner-mpls@UU.NET Mon Aug 5 14:55: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 OAA27266 for ; Mon, 5 Aug 2002 14:55:11 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqd16501 for ; Mon, 5 Aug 2002 18:56: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 QQnaqd14127; Mon, 5 Aug 2002 18:54:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqd11807 for mpls-outgoing; Mon, 5 Aug 2002 18:54:29 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 QQnaqd11801 for ; Mon, 5 Aug 2002 18:54: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 QQnaqd05288 for ; Mon, 5 Aug 2002 18:54: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 QQnaqd03782 for ; Mon, 5 Aug 2002 18:54:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnaqd03778 for ; Mon, 5 Aug 2002 18:54:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA13781 for ; Mon, 5 Aug 2002 14:54:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA19082 for mpls@uu.net; Mon, 5 Aug 2002 14:54:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnaqd11738 for ; Mon, 5 Aug 2002 18:52:38 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 QQnaqd00005 for ; Mon, 5 Aug 2002 18:51: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 QQnaqd02829 for ; Mon, 5 Aug 2002 18:51:57 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnaqd02825 for ; Mon, 5 Aug 2002 18:51:57 GMT 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 OAA13632; Mon, 5 Aug 2002 14:51:56 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA10179; Mon, 5 Aug 2002 14:51:56 -0400 (EDT) Date: Mon, 5 Aug 2002 14:51:56 -0400 From: Eric Osborne To: "Gray, Eric" Cc: "'Eric Osborne'" , "'mkumar@aplion.stpn.soft.net'" , "Mpls (E-mail)" Subject: Re: Layer 3 Lookup in ATM LSR's Message-ID: <20020805185156.GP8579@eosborne-u10.cisco.com> References: <1117F7D44159934FB116E36F4ABF221B022671F5@celox-ma1-ems1.celoxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117F7D44159934FB116E36F4ABF221B022671F5@celox-ma1-ems1.celoxnetworks.com> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Aug 05, 2002 at 02:35:53PM -0400, Gray, Eric wrote: > Eric O. > > You're interpreting confusion into existence. :-) > > L3 lookup should mean the ability to make a > determination on how to forward packets _without_ > necessarily implying capability to forward packets > with any particular capacity. But L3 lookup doesn't have to have anything to do with *forwarding* packets. It is entirely possible that a device may have a L3 forwarding table used _only_ for locally originated packets (incl. RSVP), and no such thing even at the software level at the receiving side of 0/32. However, this is semantics, and moreover, it's semantics I'm not particularly opinionated about one way or the other, so it's not like I'm looking to get into a big argument here. :) > L3 forwarding, on > the other hand, might encompass what you refer to, > but not necessarily. Lookup and forwarding functions > are distinct, even if clearly not orthogonal. > > The ability to look something up in no way > implies the ability to do anything in particular > with the results. > > However, Mayank's question implies that - by > L3 lookup - Mayank meant the ability to determine how > to forward packets. Otherwise, the question of how > to determine which downstream to request a label of > would have been unnecessary since the ability to > determine how to forward packets would be used in > determining how to forward requests. An ATM LSR combines 2 control plane protocols (LDP/RSVP + ISIS/OSPF/etc) to build both a routing topology (via IGP) and a forwarding path (via LDP/RSVP). Having either one is not good enough, and I think that an ATM LSR is under no obligation to have to forward *anything* as an IP packet, except control traffic. And the only control traffic I can think of that works like this is RSVP. eric > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Monday, August 05, 2002 2:19 PM > To: Gray, Eric > Cc: 'mkumar@aplion.stpn.soft.net'; Mpls (E-mail) > Subject: Re: Layer 3 Lookup in ATM LSR's > > On Mon, Aug 05, 2002 at 01:59:06PM -0400, Gray, Eric wrote: > > Mayank, > > > > The standards say that an ATM LSR does have L3 > > lookup capability. Specifically, RFC 3035 says about > > ATM LSRs: > > > > " ... ATM switches run network layer routing algorithms > > (such as Open Shortest Path First (OSPF), Intermediate > > System to Intermediate System (IS-IS), etc.), and their > > data forwarding is based on the results of these routing > > algorithms. No ATM-specific routing or addressing is > > needed. ATM switches used in this way are known as > > ATM-LSRs (Label Switching Routers)." > > To me, that doesn't say L3 lookup capability. I could certainly see > an ATM LSR implementation that used L3 for two things: > - maintaining IGP adjacencies > - deciding which interfaces to signal on-demand labels > > ...but none of that implies that an ATM LSR should be prepared to > forward received data packets. > > > > > I am not sure what standards you were referring to. > > > > If an ATM Switch is to participate in label switching, it > > must be able to unambiguously determine how to forward > > labeled packets. It is possible to implement ATM switches > > that participates in label switching without themselves > > participating in routing by ensuring that the determination > > on how to forward labeled packets is made for them. As an > > example, this might be done by always using strict explicit > > routing relative to the ATM switch in question and immediate > > downstream neighbors. Such ATM switches are not ATM LSRs. > > I disagree; I think there's a difference between "L3 lookup" (which to > me implies forwarding) and simply running a local IP stack for things > which originate/terminate on that router. > > > > eric > > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] > > Sent: Monday, August 05, 2002 1:32 PM > > To: Mpls (E-mail) > > Subject: Layer 3 Lookup in ATM LSR's > > > > hi > > i have a query which , you all might be able to answer:- > > > > it is said that atm switches in the core atm networks do not have layer 3 > > lookup capability. > > Now the standards say that when atm lsr's do not have a layer 3 lookup > > capability then they operate in Ordered control with down stream on demand > > mode of label distribution. > > > > lets say that i have the following mpls domain :- > > > > a--------b---------c-------d > > | > > |-------k > > > > 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are > > operating in Ordered Control with DownStream on Demand Label Distribution > > method. > > Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' > > > > 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a > > label request for a particular fec , sees that it has no downstream > mapping > > for that fec. Since 'b' is operating in ordered control , it further sends > a > > label request to c (and not to k) since it cannot allocate a label for the > > requested fec . 'c' would also further send the label request to 'd' and > > then 'd' would reply with a label mapping message. > > > > I hope that it's correct till this point. > > > > My question is, how does 'b' know , that in order to send a label request > > for a particular fec, what is the next hop for that fec when it does not > > have a layer 3 capability. > > why would 'b' send a label request to 'c' and not to 'k' ???? > > > > > > i hope i have made my point clear > > > > > > Please tell me where am i wrong > > > > thanks and regards > > mayank > > > > > > From owner-mpls@UU.NET Mon Aug 5 15:02: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 PAA27675 for ; Mon, 5 Aug 2002 15:02:18 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqe12113 for ; Mon, 5 Aug 2002 19:03: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 QQnaqe09936; Mon, 5 Aug 2002 19:02:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqe22553 for mpls-outgoing; Mon, 5 Aug 2002 19:01: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 QQnaqe21294 for ; Mon, 5 Aug 2002 19:01: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 QQnaqe18150 for ; Mon, 5 Aug 2002 19:01: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 QQnaqe08831 for ; Mon, 5 Aug 2002 19:01:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnaqe08819 for ; Mon, 5 Aug 2002 19:01:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA14416 for ; Mon, 5 Aug 2002 15:01:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA20274 for mpls@uu.net; Mon, 5 Aug 2002 15:01:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnaqd12205 for ; Mon, 5 Aug 2002 18:58:32 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 QQnaqd01808 for ; Mon, 5 Aug 2002 18:57: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 QQnaqd06134 for ; Mon, 5 Aug 2002 18:57:48 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnaqd06128 for ; Mon, 5 Aug 2002 18:57:48 GMT 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 OAA14126; Mon, 5 Aug 2002 14:57:47 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA10193; Mon, 5 Aug 2002 14:57:47 -0400 (EDT) Date: Mon, 5 Aug 2002 14:57:47 -0400 From: Eric Osborne To: Mayank Kumar Cc: "'Gray, Eric'" , "Mpls (E-mail)" Subject: Re: Layer 3 Lookup in ATM LSR's Message-ID: <20020805185747.GQ8579@eosborne-u10.cisco.com> References: <1117F7D44159934FB116E36F4ABF221B022671F4@celox-ma1-ems1.celoxnetworks.com> <014f01c23cb0$3fa53ee0$fe04a8c0@cyborg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014f01c23cb0$3fa53ee0$fe04a8c0@cyborg> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Tue, Aug 06, 2002 at 12:15:18AM +0530, Mayank Kumar wrote: > hi Eric, > then why is it recommended that in atm backbones running mpls,we should use > Downstream on Demand with Ordered LSP Control. > What advantages does it provide ??? DoD ordered means - you only get a label (VPI/VCI) when you need one - you know that when you get one, things are all set to go downstream of you > My doubt arose because i have been reading a book from cisco press named > "MPLS And VPN architectures" by Ivan Pepelnjak and Jim Guichard. ...which isn't a book that pretends to be particularly authoritative on ATM LSR stuff, IIRC..:) > the book on pg 57 says that > "the label allocation and distribution process accross the atm-lsr domain > has the following characteristics:- > --Label allocation in devices with layer 3 lookup capabilites (routers ) is > done regardless of whether the router has already received a label for the > same prefix from its next hop router . Label allocation in routers is thus > called independent control. > --label allocation in devices with no layer 3 lookup capabilites (atm > switches) is performed only if a corresponding downstream label has already > been allocated . Label allocation in atm swicthes is thus Ordered control." > This is really explaining how things are done, not why they're done that way. I recommend you read the RFCs that are out there (rfc3031) to get another perspective on the different modes. > the book further says that "the downstream lsr could simply allocate a label > and respond to the request from the upstream lsr with a corresponding reply > message. Under some circumstances , this action would require the downstream > lsr to have layer 3 lookup capability (such as if the downstream lsr would > have no further downstream label for the requested destination). Therefore , > the atm swicthes never respond to a label allocation request unless they > already have a corresponding downstream label allocated" > > What does that mean ??? > Not sure; I think it means "go away, this is a frame-mode book"...:) > And do u want to say that an LSR always has a layer 3 lookup capabilites > irrespective of whether it is an atm lsr or frame based lsr. > > I think Eric is right in his reply ??? > I think that Layer 3 Lookup implies , being able to process the IP header > while forwarding packets and thus being able to make a forwarding decision > based on the destination ip address. Atm swicthes do form routing > adjacencies on the control vc but they dont have layer 3 lookup capability. > > Why does the Book say then , that label allocation in atm swicthes is > Ordered. What advantage does that provide ??? > The advantage of Ordered is that if you receive a label binding upstream, you are 100% certain that the downstream forwarding topology is set up, and that if you forward packets down that LSP, they will arrive at their destination (modulo congestion, etc), and that you don't have to worry about needing to do a route lookup in an ATM cloud. But I think you might be reading too much into it. eric > thanks and reagards > Mayank > > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Monday, August 05, 2002 11:29 PM > To: 'mkumar@aplion.stpn.soft.net' > Cc: Mpls (E-mail) > Subject: RE: Layer 3 Lookup in ATM LSR's > > > Mayank, > > The standards say that an ATM LSR does have L3 > lookup capability. Specifically, RFC 3035 says about > ATM LSRs: > > " ... ATM switches run network layer routing algorithms > (such as Open Shortest Path First (OSPF), Intermediate > System to Intermediate System (IS-IS), etc.), and their > data forwarding is based on the results of these routing > algorithms. No ATM-specific routing or addressing is > needed. ATM switches used in this way are known as > ATM-LSRs (Label Switching Routers)." > > I am not sure what standards you were referring to. > > If an ATM Switch is to participate in label switching, it > must be able to unambiguously determine how to forward > labeled packets. It is possible to implement ATM switches > that participates in label switching without themselves > participating in routing by ensuring that the determination > on how to forward labeled packets is made for them. As an > example, this might be done by always using strict explicit > routing relative to the ATM switch in question and immediate > downstream neighbors. Such ATM switches are not ATM LSRs. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] > Sent: Monday, August 05, 2002 1:32 PM > To: Mpls (E-mail) > Subject: Layer 3 Lookup in ATM LSR's > > hi > i have a query which , you all might be able to answer:- > > it is said that atm switches in the core atm networks do not have layer 3 > lookup capability. > Now the standards say that when atm lsr's do not have a layer 3 lookup > capability then they operate in Ordered control with down stream on demand > mode of label distribution. > > lets say that i have the following mpls domain :- > > a--------b---------c-------d > | > |-------k > > 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are > operating in Ordered Control with DownStream on Demand Label Distribution > method. > Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' > > 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a > label request for a particular fec , sees that it has no downstream mapping > for that fec. Since 'b' is operating in ordered control , it further sends a > label request to c (and not to k) since it cannot allocate a label for the > requested fec . 'c' would also further send the label request to 'd' and > then 'd' would reply with a label mapping message. > > I hope that it's correct till this point. > > My question is, how does 'b' know , that in order to send a label request > for a particular fec, what is the next hop for that fec when it does not > have a layer 3 capability. > why would 'b' send a label request to 'c' and not to 'k' ???? > > > i hope i have made my point clear > > > Please tell me where am i wrong > > thanks and regards > mayank > > > > From owner-mpls@UU.NET Mon Aug 5 15:06: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 PAA27827 for ; Mon, 5 Aug 2002 15:06:11 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqe19272 for ; Mon, 5 Aug 2002 19:07: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 QQnaqe13829; Mon, 5 Aug 2002 19:04:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqe24699 for mpls-outgoing; Mon, 5 Aug 2002 19:03: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 QQnaqe24684 for ; Mon, 5 Aug 2002 19:03:18 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 QQnaqe26894 for ; Mon, 5 Aug 2002 19:02: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 QQnaqe10805 for ; Mon, 5 Aug 2002 19:02:40 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnaqe10555 for ; Mon, 5 Aug 2002 19:02:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13452 for ; Mon, 5 Aug 2002 15:02:28 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17781 for ; Mon, 5 Aug 2002 15:02:30 -0400 (EDT) Message-ID: <3D4ECBD3.9060902@marconi.com> Date: Mon, 05 Aug 2002 15:02:43 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Layer 3 Lookup in ATM LSR's References: <014f01c23cb0$3fa53ee0$fe04a8c0@cyborg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mayank Kumar wrote: > > then why is it recommended that in atm backbones running mpls,we should use > Downstream on Demand with Ordered LSP Control. > What advantages does it provide ??? ATM switches don't have a concept of the "per platform" label space. ATM forwarding hardware is designed around ATM capabilities, which only allocated VCIDs on a per-interface basis. multipoint-to-point connections may not be possible either. This can quickly lead to resource exhaustion on the line cards and switching fabric, since each interface would need to allocate a label for evey IGP prefix, and you'd need to create fabric connections for every interface/prefix combination - which can be tremendous. > My doubt arose because i have been reading a book from cisco press named > "MPLS And VPN architectures" by Ivan Pepelnjak and Jim Guichard. > the book on pg 57 says that > "the label allocation and distribution process accross the atm-lsr domain > has the following characteristics:- > --Label allocation in devices with layer 3 lookup capabilites (routers ) is > done regardless of whether the router has already received a label for the > same prefix from its next hop router . Label allocation in routers is thus > called independent control. This description is assuming connectionless hardware. A connection- oriented layer-3 router that doesn't support per-platform label spaces and multipoint-to-point connections can hit the same resource exhaustion problems that an ATM switch is likely to hit. > --label allocation in devices with no layer 3 lookup capabilites (atm > switches) is performed only if a corresponding downstream label has already > been allocated . Label allocation in atm swicthes is thus Ordered control." See above. They're talking about layer-3 hardware-forwarding capabilities, not a lack of ability to receive an IP packet. On-demand/ordered operation is better for these kind of switches because you only create connections that are explicitly requested, which will usually be less than the product of all prefixes and all interfaces. This behavior comes at the cost of longer convergence times. > the book further says that "the downstream lsr could simply allocate a label > and respond to the request from the upstream lsr with a corresponding reply > message. Under some circumstances , this action would require the downstream > lsr to have layer 3 lookup capability (such as if the downstream lsr would > have no further downstream label for the requested destination). Therefore , > the atm swicthes never respond to a label allocation request unless they > already have a corresponding downstream label allocated" > > What does that mean ??? > > And do u want to say that an LSR always has a layer 3 lookup capabilites > irrespective of whether it is an atm lsr or frame based lsr. No. You're confusing what "lookup capable" means. A lookup capable router (or interface) is one that can receive an unlabeled packet, determine the next-hop (which may be into an LSP), push an appropriate label, and forward the packet to that next-hop. With modern equipment, this mean that this is done in hardware, since no processor is fast enough to do this when there are a lot of high-speed interfaces. Lookup capability is also needed for a router (or interface) that must pop the label stack. It must do a label-lookup (which all switches can do), but it must then pop the stack and then do an IP lookup on the result before forwarding. This is beyond the capability of most ATM forwarding hardware. > I think Eric is right in his reply ??? > I think that Layer 3 Lookup implies , being able to process the IP header > while forwarding packets and thus being able to make a forwarding decision > based on the destination ip address. Atm swicthes do form routing > adjacencies on the control vc but they dont have layer 3 lookup capability. > > Why does the Book say then , that label allocation in atm swicthes is > Ordered. What advantage does that provide ??? See above. It helps to prevent the resource exhaustion that will happen if you have a lot of prefixes and a lot of interfaces, wihtout a per-platform label space or mp2p connection. -- David From owner-mpls@UU.NET Mon Aug 5 15:21: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 PAA28326 for ; Mon, 5 Aug 2002 15:21:21 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqf10200 for ; Mon, 5 Aug 2002 19:22: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 QQnaqf07673; Mon, 5 Aug 2002 19:21:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqf06968 for mpls-outgoing; Mon, 5 Aug 2002 19:20:45 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 QQnaqf06956 for ; Mon, 5 Aug 2002 19:20:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnaqf06680 for ; Mon, 5 Aug 2002 19:20: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 QQnaqf06547 for ; Mon, 5 Aug 2002 19:20:06 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 QQnaqf06531 for ; Mon, 5 Aug 2002 19:20:05 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFL6T>; Mon, 5 Aug 2002 15:20:05 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671F6@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Eric Osborne'" Cc: "Mpls (E-mail)" Subject: RE: Layer 3 Lookup in ATM LSR's Date: Mon, 5 Aug 2002 15:19:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric O. While none of the things said in this discussion so far imply that an ATM LSR should be prepared to forward unlabeled packets, there have been separate discussions on this topic before. It has been repeatedly asserted that the term 'LSR' strictly implies the ability to forward plain old IP packets as well as labeled packets. There was an attempt in the MPLS Framework ID several years ago to define an 'MPLS node' as a device that is not capable of forwarding unlabeled packets. Note the definition of LSR from RFC 3031: label switching router an MPLS node which is capable of forwarding native L3 packets There is a boot-strap problem with the MPLS node idea, however - particularly WRT Downstream on Demand, ordered control. It is technically wrong to advertise reachability in a routing protocol for network destinations you are unable to forward packets to. If an LSR needs to get a label from a downstream neighbor before advertising a route corresponding to the FEC for that label, then its upstream neighbor might well be unaware that it should request a label from the local LSR for that FEC (not having received a corresponding route advertisement itself). In DoD, ordered control, this would mean the local LSR could end up never asking for a label from a downstream LSR and never advertising a route to an upstream LSR. An implementation can fudge this by advertising routes based on anticipation of LSP setup. But this means that packets will be directed to use defective forwarding paths during the time it takes to establish the anticipated LSPs - unless the routing protocol is setup to change the cost associated with routes it has advertised . Depending on the dynamics of the network, this could be very bad. Note that this problem isn't an issue with DV or PV routing protocols if using DU label advertisement. I believe the problem exists, however, for LS routing protocols regardless of the label advertisement mode. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Eric Osborne [mailto:eosborne@cisco.com] Sent: Monday, August 05, 2002 2:19 PM To: Gray, Eric Cc: 'mkumar@aplion.stpn.soft.net'; Mpls (E-mail) Subject: Re: Layer 3 Lookup in ATM LSR's On Mon, Aug 05, 2002 at 01:59:06PM -0400, Gray, Eric wrote: > Mayank, > > The standards say that an ATM LSR does have L3 > lookup capability. Specifically, RFC 3035 says about > ATM LSRs: > > " ... ATM switches run network layer routing algorithms > (such as Open Shortest Path First (OSPF), Intermediate > System to Intermediate System (IS-IS), etc.), and their > data forwarding is based on the results of these routing > algorithms. No ATM-specific routing or addressing is > needed. ATM switches used in this way are known as > ATM-LSRs (Label Switching Routers)." To me, that doesn't say L3 lookup capability. I could certainly see an ATM LSR implementation that used L3 for two things: - maintaining IGP adjacencies - deciding which interfaces to signal on-demand labels ...but none of that implies that an ATM LSR should be prepared to forward received data packets. > > I am not sure what standards you were referring to. > > If an ATM Switch is to participate in label switching, it > must be able to unambiguously determine how to forward > labeled packets. It is possible to implement ATM switches > that participates in label switching without themselves > participating in routing by ensuring that the determination > on how to forward labeled packets is made for them. As an > example, this might be done by always using strict explicit > routing relative to the ATM switch in question and immediate > downstream neighbors. Such ATM switches are not ATM LSRs. I disagree; I think there's a difference between "L3 lookup" (which to me implies forwarding) and simply running a local IP stack for things which originate/terminate on that router. eric > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] > Sent: Monday, August 05, 2002 1:32 PM > To: Mpls (E-mail) > Subject: Layer 3 Lookup in ATM LSR's > > hi > i have a query which , you all might be able to answer:- > > it is said that atm switches in the core atm networks do not have layer 3 > lookup capability. > Now the standards say that when atm lsr's do not have a layer 3 lookup > capability then they operate in Ordered control with down stream on demand > mode of label distribution. > > lets say that i have the following mpls domain :- > > a--------b---------c-------d > | > |-------k > > 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are > operating in Ordered Control with DownStream on Demand Label Distribution > method. > Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' > > 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a > label request for a particular fec , sees that it has no downstream mapping > for that fec. Since 'b' is operating in ordered control , it further sends a > label request to c (and not to k) since it cannot allocate a label for the > requested fec . 'c' would also further send the label request to 'd' and > then 'd' would reply with a label mapping message. > > I hope that it's correct till this point. > > My question is, how does 'b' know , that in order to send a label request > for a particular fec, what is the next hop for that fec when it does not > have a layer 3 capability. > why would 'b' send a label request to 'c' and not to 'k' ???? > > > i hope i have made my point clear > > > Please tell me where am i wrong > > thanks and regards > mayank > > > From owner-mpls@UU.NET Mon Aug 5 15:29: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 PAA28581 for ; Mon, 5 Aug 2002 15:29:21 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnaqc20399; Mon, 5 Aug 2002 18:41:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqc10675 for mpls-outgoing; Mon, 5 Aug 2002 18:40:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnaqc10668 for ; Mon, 5 Aug 2002 18:40: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 QQnaqc07445 for ; Mon, 5 Aug 2002 18:40: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 QQnaqc17082 for ; Mon, 5 Aug 2002 18:40:07 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 QQnaqc16782 for ; Mon, 5 Aug 2002 18:39:59 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 OAA11912 for ; Mon, 5 Aug 2002 14:39:57 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08714 for ; Mon, 5 Aug 2002 14:39:57 -0400 (EDT) Message-ID: <3D4EC68A.9080506@marconi.com> Date: Mon, 05 Aug 2002 14:40:10 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Layer 3 Lookup in ATM LSR's References: <014a01c23ca6$132d5190$fe04a8c0@cyborg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mayank Kumar wrote: > > it is said that atm switches in the core atm networks do not have layer 3 > lookup capability. Their line cards can not typically use information other than what's in the cell header for forwarding purposes. If they are to be used with MPLS, their control processors will still have to run an IP stack. A PVC (typically 0:32) is usually configured on each interface for the purpose of sending unlabeled IP traffic to a switch's processor. Software forwarding of IP (via the control processor) may even exist, in order to facilitate control-plane routing protocols and signaling protocols that may require it. This forwarding will typically be orders of magnitude slower than ATM cell switching, so you can't use it in the data plane for anything, but it should still exist in the control plane. Keeping this in mind, the answer to your quetion should now be obvious. > Now the standards say that when atm lsr's do not have a layer 3 lookup > capability then they operate in Ordered control with down stream on demand > mode of label distribution. > > lets say that i have the following mpls domain :- > > a--------b---------c-------d > | > |-------k > > 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are > operating in Ordered Control with DownStream on Demand Label Distribution > method. > Suppose a lsp has to travel the path 'a'----'b'---'c'---'d' > > 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a > label request for a particular fec , sees that it has no downstream mapping > for that fec. Since 'b' is operating in ordered control , it further sends a > label request to c (and not to k) since it cannot allocate a label for the > requested fec . 'c' would also further send the label request to 'd' and > then 'd' would reply with a label mapping message. > > I hope that it's correct till this point. > > My question is, how does 'b' know , that in order to send a label request > for a particular fec, what is the next hop for that fec when it does not > have a layer 3 capability. > why would 'b' send a label request to 'c' and not to 'k' ???? This next-hop determination comes from the routing table. An ATM switch that is participating in an MPLS network will probably be running an IP-based routing protocol, like OSPF or IS-IS. If it isn't then it will at least have static routes. Either way, the routing table will be populated with the necessary data. If the data's not there, of course, then the LSP can't propagate to the egress. -- David From owner-mpls@UU.NET Mon Aug 5 15:54: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 PAA29362 for ; Mon, 5 Aug 2002 15:54:57 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqh06314 for ; Mon, 5 Aug 2002 19:56: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 QQnaqh04302; Mon, 5 Aug 2002 19:54:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqh09457 for mpls-outgoing; Mon, 5 Aug 2002 19:54: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 QQnaqh09452 for ; Mon, 5 Aug 2002 19:54: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 QQnaqh02285 for ; Mon, 5 Aug 2002 19:54: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 QQnaqh03761 for ; Mon, 5 Aug 2002 19:54:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnaqh03757 for ; Mon, 5 Aug 2002 19:54:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA18526 for ; Mon, 5 Aug 2002 15:54:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA27120 for mpls@uu.net; Mon, 5 Aug 2002 15:54:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnaqh09382 for ; Mon, 5 Aug 2002 19:52: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 QQnaqh25993 for ; Mon, 5 Aug 2002 19:51: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 QQnaqh16492 for ; Mon, 5 Aug 2002 19:51:33 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 QQnaqh16482 for ; Mon, 5 Aug 2002 19:51:32 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 g75JouJf002860; Mon, 5 Aug 2002 15:50:57 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (che-vpn2-62.cisco.com [10.86.244.62]) by bucket.cisco.com (Mirapoint) with ESMTP id ABJ85148; Mon, 5 Aug 2002 15:50:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20020805154329.01ce69e0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Aug 2002 15:50:50 -0400 To: "David Allan" From: "Thomas D. Nadeau" Subject: Re: MIB Question Cc: mpls@UU.NET, , pwe3@ietf.org In-Reply-To: <9FBD322B7824D511B36900508BF93C9C04D2A6AA@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk [Cross-posting as this discussion has applicability to all three WGs.] At 02:37 PM 8/2/2002 -0400, David Allan wrote: >I've been rummaging through MTU related stuff and not that there is >no-where that record MTU discards (either MPLS MIBs or Interfaces group >MIB). Agree that for IP, it's a big yawn and probably means someone is >doing MTU discovery and is a non-problem. > >Issues is PWs where there is no payload fragmentation and VPNs where the >packet payload has no provider routable addresses in it (no ICMP reply >possible). IMHO the "use a big MTU" stipulation won't hold up forever, and >some token effort to prepare for the future may be in order. > >Seems to me that it would be useful to have a counter in the LSR MIB for >non-IP MTU discards (maybe with a threshold trap although I'll let my >betters comment further) so that at least some indication of a problem was >possible as currently packets simply "black hole". I'd suggest that the >non-IP category would also include stack depth > 1 (e.g. 2547) as ideally >path MTU handling for a VPN should be a PE problem. Dave, The MPLS-LSR MIB does contain counters that an implementation may count MTU errors: mplsInSegmentErrors, mplsInSegmentDiscards, mplsOutSegmentErrors, and mplsOutSegmentDiscards. However, I do agree that MTU discards are not explicitly counted. In the non-PW and non-VPN cases, I have not seen any requirements to-date to add such counters from providers, thus we have not added any. One question, you mention this within the context of PW/VPN. In the case of PWE3, wouldn't it be more appropriate to include MTU discards in the generic PW VC counters into the PW-MIB? For VPN, we could certainly add them into the PPVPN-MPLS-VPN MIB explicitly as well. The only hesitation I have for adding these to the PPVPN MIB is that to-date have not had such a requirement from any providers, so I would like to get some more input from that group first. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Mon Aug 5 16:07: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 QAA29976 for ; Mon, 5 Aug 2002 16:07:05 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqi27202 for ; Mon, 5 Aug 2002 20:08: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 QQnaqi25731; Mon, 5 Aug 2002 20:07:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqi02432 for mpls-outgoing; Mon, 5 Aug 2002 20:07: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 QQnaqi02425 for ; Mon, 5 Aug 2002 20:07:00 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 QQnaqi13834 for ; Mon, 5 Aug 2002 20:06: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 QQnaqi18227 for ; Mon, 5 Aug 2002 20:06:57 GMT Received: from dharti.aplion.stpn.soft.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQnaqi18169 for ; Mon, 5 Aug 2002 20:06:52 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g75K8Ii19354; Tue, 6 Aug 2002 01:38:18 +0530 Reply-To: From: "Mayank Kumar" To: "'David Charlap'" Cc: "Mpls \(E-mail\)" Subject: RE: Layer 3 Lookup in ATM LSR's Date: Tue, 6 Aug 2002 01:40:38 +0530 Message-ID: <015301c23cbc$2b6913a0$fe04a8c0@cyborg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3D4ECBD3.9060902@marconi.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi david u have been repeatedly talking about the resource exhaustion problem. I think that is taken care off by the Down stream on demand mode. What does the Ordered control do here. Do u agree with the author of the Book when he says " this action would require the downstream lsr to have layer 3 lookup capability (such as if the downstream lsr would have no further downstream label for the requested destination). Therefore , the atm swicthes never respond to a label allocation request unless they already have a corresponding downstream label allocated" the author says that in a certain scenario, the atm lsr might require layer 3 lookup capability (probably in the data plane) , therefore it never responds to a label allocation request unless it already has a corresponding downstream mapping, and therefore is able to avoid layer 3 lookup. I think , that all these discussions conclude to the following:- --all lsr 's whether atm lsr's or frame lsr's , have layer 3 lookup capability , which means to be able to determine the reachability of a particular destination prefix by looking into a routing table (to determine the next hop and output interface) . This also means that all lsr's have a routing table too. --all lsr's are able to orginate ip packets in the control plane (routing protocol packets and Signalling protocol packets) --all lsr's are able to receive ip packets in the control plane (routing protocol packets and Signalling protocol packets) --some lsr's might be able to forward ip packets in the control plane (for eg an atm lsr might forward ip packets using its control vc by reassembling an ip packet doing a routing table lookup and then determining the outgoing interface and then further segmenting the cells again back when sending out the outgoing interface determined using the routing table.) --only edge lsr's are able to receive ip packets in the data plane. --only frame based lsr 's are able to forward ip packets in the data plane is it correct ??? i think that the author of the cisco book when saying layer 3 lookup capability means having a layer 3 lookup capability in the Data plane which most swicthes dont have as they forward based on the cell header. If a atm lsr responded to a label request without it having a corresponding downstream label binding , then it might start receiving labelled packets for the said fec and because by that time if it does not have a downstream label assigned, it may need to do a ip lookup of the received labelled packet (after popping its label) in order to forward that packet (layer 3 lookup and forwarding in the data plane required) or it may choose to drop it. please tell me if i am correct ?? thanks and regards mayank -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Charlap Sent: Tuesday, August 06, 2002 12:33 AM To: IETF MPLS List Subject: Re: Layer 3 Lookup in ATM LSR's Mayank Kumar wrote: > > then why is it recommended that in atm backbones running mpls,we should use > Downstream on Demand with Ordered LSP Control. > What advantages does it provide ??? ATM switches don't have a concept of the "per platform" label space. ATM forwarding hardware is designed around ATM capabilities, which only allocated VCIDs on a per-interface basis. multipoint-to-point connections may not be possible either. This can quickly lead to resource exhaustion on the line cards and switching fabric, since each interface would need to allocate a label for evey IGP prefix, and you'd need to create fabric connections for every interface/prefix combination - which can be tremendous. > My doubt arose because i have been reading a book from cisco press named > "MPLS And VPN architectures" by Ivan Pepelnjak and Jim Guichard. > the book on pg 57 says that > "the label allocation and distribution process accross the atm-lsr domain > has the following characteristics:- > --Label allocation in devices with layer 3 lookup capabilites (routers ) is > done regardless of whether the router has already received a label for the > same prefix from its next hop router . Label allocation in routers is thus > called independent control. This description is assuming connectionless hardware. A connection- oriented layer-3 router that doesn't support per-platform label spaces and multipoint-to-point connections can hit the same resource exhaustion problems that an ATM switch is likely to hit. > --label allocation in devices with no layer 3 lookup capabilites (atm > switches) is performed only if a corresponding downstream label has already > been allocated . Label allocation in atm swicthes is thus Ordered control." See above. They're talking about layer-3 hardware-forwarding capabilities, not a lack of ability to receive an IP packet. On-demand/ordered operation is better for these kind of switches because you only create connections that are explicitly requested, which will usually be less than the product of all prefixes and all interfaces. This behavior comes at the cost of longer convergence times. > the book further says that "the downstream lsr could simply allocate a label > and respond to the request from the upstream lsr with a corresponding reply > message. Under some circumstances , this action would require the downstream > lsr to have layer 3 lookup capability (such as if the downstream lsr would > have no further downstream label for the requested destination). Therefore , > the atm swicthes never respond to a label allocation request unless they > already have a corresponding downstream label allocated" > > What does that mean ??? > > And do u want to say that an LSR always has a layer 3 lookup capabilites > irrespective of whether it is an atm lsr or frame based lsr. No. You're confusing what "lookup capable" means. A lookup capable router (or interface) is one that can receive an unlabeled packet, determine the next-hop (which may be into an LSP), push an appropriate label, and forward the packet to that next-hop. With modern equipment, this mean that this is done in hardware, since no processor is fast enough to do this when there are a lot of high-speed interfaces. Lookup capability is also needed for a router (or interface) that must pop the label stack. It must do a label-lookup (which all switches can do), but it must then pop the stack and then do an IP lookup on the result before forwarding. This is beyond the capability of most ATM forwarding hardware. > I think Eric is right in his reply ??? > I think that Layer 3 Lookup implies , being able to process the IP header > while forwarding packets and thus being able to make a forwarding decision > based on the destination ip address. Atm swicthes do form routing > adjacencies on the control vc but they dont have layer 3 lookup capability. > > Why does the Book say then , that label allocation in atm swicthes is > Ordered. What advantage does that provide ??? See above. It helps to prevent the resource exhaustion that will happen if you have a lot of prefixes and a lot of interfaces, wihtout a per-platform label space or mp2p connection. -- David From owner-mpls@UU.NET Mon Aug 5 16:19: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 QAA00505 for ; Mon, 5 Aug 2002 16:19:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqj24859 for ; Mon, 5 Aug 2002 20:20: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 QQnaqj23723; Mon, 5 Aug 2002 20:19:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqj04500 for mpls-outgoing; Mon, 5 Aug 2002 20:19: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 QQnaqj04495 for ; Mon, 5 Aug 2002 20:19: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 QQnaqj19842 for ; Mon, 5 Aug 2002 20:18: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 QQnaqj08338 for ; Mon, 5 Aug 2002 20:18:31 GMT Received: from mail1.paramanet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.paramanet.com [65.211.83.162]) id QQnaqj08334 for ; Mon, 5 Aug 2002 20:18:31 GMT content-class: urn:content-classes:message Subject: RE: draft-nadeau-mpls-lc-if-mib-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 5 Aug 2002 16:18:28 -0400 Message-ID: <9791A828507D5A418741095C3FD0DDE35EB77A@indus> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: draft-nadeau-mpls-lc-if-mib-00.txt Thread-Index: AcIbuhrnuYdbPcASQ4yChjpu3CtGeghAwhHQ From: "Cheenu Srinivasan" To: "Thomas D. Nadeau" Cc: , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA00505 Hi Tom, A few comments: - TOC is that of the LSR MIB! - Abstract - how about: This memo defines MIB modules to realize label switching controlled Frame Relay and ATM interfaces given the interface stacking defined in MPLS-LSR-MIB and MPLS-TE-MIB. - Section 6 starts of talking about LC-ATM interfaces and then starts referring to both ATM and FR interfaces. You should probably have seperate sections for the two or rename the section and describe the two in seperate paras. - Update the date(s) in the MODULE-IDENTITY. - In the description of the tables you say that entries in the table are created by the LSR (automatically, as opposed to creation by the operator). Then, why do you need the RowStatus object? The LSR presumably creates the entry indicating whatever default capability and (optionally) allows the operator to change ranges etc. Am I missing something? - Sec. 12 - you say: "This module does not define any management objects. Instead, it defines two new ifTypes which may be used by other MPLS MIB modules to define management objects." Rewrite this as this doc contains two modules which definitely define management objects! Since these are writeable you will have some security considerations - section 11 of the LSR would be a decent template. Also I didn't see any new ifType defined - you have instead added augments to the interface conf table. Hope this helps. Cheenu > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, June 24, 2002 4:03 PM > Subject: draft-nadeau-mpls-lc-if-mib-00.txt > > > > FYI, the new draft draft-nadeau-mpls-lc-if-mib-00.txt > has been published in the I-D repository. I would appreciate > it if you could give it a look-see when you had a chance. > > --Tom > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > > From owner-mpls@UU.NET Mon Aug 5 16:29: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 QAA00706 for ; Mon, 5 Aug 2002 16:29:20 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaqk09851 for ; Mon, 5 Aug 2002 20:30: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 QQnaqj07769; Mon, 5 Aug 2002 20:29:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaqj05074 for mpls-outgoing; Mon, 5 Aug 2002 20:29: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 QQnaqj05069 for ; Mon, 5 Aug 2002 20:29: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 QQnaqj00664 for ; Mon, 5 Aug 2002 20:28: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 QQnaqj01455 for ; Mon, 5 Aug 2002 20:28:54 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 QQnaqj01448 for ; Mon, 5 Aug 2002 20:28:53 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 QAA18977 for ; Mon, 5 Aug 2002 16:28:46 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22862 for ; Mon, 5 Aug 2002 16:28:46 -0400 (EDT) Message-ID: <3D4EE00C.7010904@marconi.com> Date: Mon, 05 Aug 2002 16:29:00 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Layer 3 Lookup in ATM LSR's References: <015301c23cbc$2b6913a0$fe04a8c0@cyborg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mayank Kumar wrote: > hi david > u have been repeatedly talking about the resource exhaustion problem. I > think that is taken care off by the Down stream on demand mode. What does > the Ordered control do here. I think Eric put it best. You don't want to advertise a label mapping if you can't forward traffic arriving on that label. If you don't have a downstream label yet, then you can't forward it as labeled traffic. If you're lookup capable, you can pop the label and forward based on the IP header. If you're not, then you have no choice but to drop traffic until the downstream label arrives. It isn't nice to your ingress nodes to give them labels that will result in dropped traffic. Those nodes would probably prefer to forward the packet through some other means until the LSP is completely up. > Do u agree with the author of the Book when he says > " this action would require the downstream > lsr to have layer 3 lookup capability (such as if the downstream lsr would > have no further downstream label for the requested destination). Therefore, > the atm swicthes never respond to a label allocation request unless they > already have a corresponding downstream label allocated" I think that's a roundabout way of saying what I (and Eric) just said. > I think , that all these discussions conclude to the following:- > > --all lsr 's whether atm lsr's or frame lsr's , have layer 3 lookup > capability , which means to be able to determine the reachability of a > particular destination prefix by looking into a routing table (to determine > the next hop and output interface) . This also means that all lsr's have a > routing table too. > --all lsr's are able to orginate ip packets in the control plane (routing > protocol packets and Signalling protocol packets) > --all lsr's are able to receive ip packets in the control plane (routing > protocol packets and Signalling protocol packets) Absolutely. You couldn't run a signaling protocol without these three capabilities (a routing table of some form, and the ability to transmit and receive unlabeled packets.) > --some lsr's might be able to forward ip packets in the control plane (for > eg an atm lsr might forward ip packets using its control vc by reassembling > an ip packet doing a routing table lookup and then determining the outgoing > interface and then further segmenting the cells again back when sending out > the outgoing interface determined using the routing table.) That would be correct. But it would be unreasonable to expect such forwarding capability to be robust enough to use for the data plane. Especially when people are selling switches with dozens of high-speed (like OC-12 and higher) interfaces. No software-based forwarder could keep up with a load like that. > --only edge lsr's are able to receive ip packets in the data plane. Yes. But "edge" can be a fuzzy term. If a transit router should pop a label (perhaps an LDP-signaled LSP ends in the middle of the cloud), the next router will receive an unlabeld packet. It may choose to encapsulate that packet in another label header and forward it through a second LSP. From the standpoint of those two routers where this happened, they are edges. > --only frame based lsr 's are able to forward ip packets in the data plane I wouldn't go that far. There are hop-by-hop routers with ATM interfaces. And there are intelligent lookup-capable interfaces for some ATM switches. Don't blur the lines between legacy implementations, current implementations, future implementations, and theoretical possibility. It is true that legacy ATM switches can't do the kind of IP lookup necessary for data-plane forwarding. But it is also true that there are modern switches with cell-based backplanes that can do IP lookup and forwarding. Your use of the word "only" sounds like you're trying to draw a line in the sand somewhere, when in reality, that line is always in motion. -- David From owner-mpls@UU.NET Tue Aug 6 01:13: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 BAA16122 for ; Tue, 6 Aug 2002 01:13:13 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnars15814 for ; Tue, 6 Aug 2002 05:14: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 QQnars14274; Tue, 6 Aug 2002 05:13:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnars05236 for mpls-outgoing; Tue, 6 Aug 2002 05:13: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 QQnars05231 for ; Tue, 6 Aug 2002 05:13:10 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 QQnars29647 for ; Tue, 6 Aug 2002 05:13: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 QQnars14061 for ; Tue, 6 Aug 2002 05:13:05 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 QQnars14043 for ; Tue, 6 Aug 2002 05:12:57 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g765DoK31988; Tue, 6 Aug 2002 10:43:50 +0530 Reply-To: From: "Mayank Kumar" To: "'David Charlap'" Cc: , "Mpls \(E-mail\)" Subject: RE: Layer 3 Lookup in ATM LSR's Date: Tue, 6 Aug 2002 10:46:09 +0530 Message-ID: <015d01c23d08$606b1b60$fe04a8c0@cyborg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3D4EE00C.7010904@marconi.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Thanks David for ur comments. They seem correct. About my last line that only frame based lsr's are capable of ip forwarding in the data plane, when u are talking about atm interfaces capable of doing ip packet forwarding , then they are actually not operating in the cell mode but in frame mode. Thus frame based lsr's include atm swicthes operating in frame mode (ie receiving an ip packet as cells , reassembling it into a ip packet, doing a routing table lookup and then forwarding it as cells ). Also please see inline with prefix MAY for more :- -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Charlap Sent: Tuesday, August 06, 2002 1:59 AM To: IETF MPLS List Subject: Re: Layer 3 Lookup in ATM LSR's Mayank Kumar wrote: > hi david > u have been repeatedly talking about the resource exhaustion problem. I > think that is taken care off by the Down stream on demand mode. What does > the Ordered control do here. I think Eric put it best. You don't want to advertise a label mapping if you can't forward traffic arriving on that label. If you don't have a downstream label yet, then you can't forward it as labeled traffic. If you're lookup capable, you can pop the label and forward based on the IP header. If you're not, then you have no choice but to drop traffic until the downstream label arrives. It isn't nice to your ingress nodes to give them labels that will result in dropped traffic. Those nodes would probably prefer to forward the packet through some other means until the LSP is completely up. MAY:does all the above amount to a good reason that why Atm lsr's shouldnt respond to a label allocation request unless they have a corresponding downstream mapping ???? > Do u agree with the author of the Book when he says > " this action would require the downstream > lsr to have layer 3 lookup capability (such as if the downstream lsr would > have no further downstream label for the requested destination). Therefore, > the atm swicthes never respond to a label allocation request unless they > already have a corresponding downstream label allocated" I think that's a roundabout way of saying what I (and Eric) just said. > I think , that all these discussions conclude to the following:- > > --all lsr 's whether atm lsr's or frame lsr's , have layer 3 lookup > capability , which means to be able to determine the reachability of a > particular destination prefix by looking into a routing table (to determine > the next hop and output interface) . This also means that all lsr's have a > routing table too. > --all lsr's are able to orginate ip packets in the control plane (routing > protocol packets and Signalling protocol packets) > --all lsr's are able to receive ip packets in the control plane (routing > protocol packets and Signalling protocol packets) Absolutely. You couldn't run a signaling protocol without these three capabilities (a routing table of some form, and the ability to transmit and receive unlabeled packets.) MAY: can we differentiate between the following . I mean are these three capabilities different:- -- ability to orginate ip packets -- ability to receive ip packets -- ability to forward ip packets can an implementation only have the first two and not the second one.I think that if its possible then we can say that atm swicthes do not have layer 3 forwarding capability in either the control plane or the data plane. Because in the data plane they do cell swicthing and in the control plane they either receive routing protocols packets destined locally or signalling protocol packets destined locally., or they orginate one but never forward any. But then i doubt how do targetted hellos would get forwarded ??? cisco routers allow u to configure an atm interface as either operating in cell mode or frame mode. however cisco switches do not allow an atm interface to operate in frame mode and cisco routers any way have layer 3 lookup and forwarding capability in the data plane. What i want to say that atm swicthes do not have layer 3 forwarding capability in the data plane because they alsways swicth cells and never operate in frame mode > --some lsr's might be able to forward ip packets in the control plane (for > eg an atm lsr might forward ip packets using its control vc by reassembling > an ip packet doing a routing table lookup and then determining the outgoing > interface and then further segmenting the cells again back when sending out > the outgoing interface determined using the routing table.) That would be correct. But it would be unreasonable to expect such forwarding capability to be robust enough to use for the data plane. Especially when people are selling switches with dozens of high-speed (like OC-12 and higher) interfaces. No software-based forwarder could keep up with a load like that. > --only edge lsr's are able to receive ip packets in the data plane. Yes. But "edge" can be a fuzzy term. If a transit router should pop a label (perhaps an LDP-signaled LSP ends in the middle of the cloud), the next router will receive an unlabeld packet. It may choose to encapsulate that packet in another label header and forward it through a second LSP. From the standpoint of those two routers where this happened, they are edges. > --only frame based lsr 's are able to forward ip packets in the data plane I wouldn't go that far. There are hop-by-hop routers with ATM interfaces. And there are intelligent lookup-capable interfaces for some ATM switches. Don't blur the lines between legacy implementations, current implementations, future implementations, and theoretical possibility. It is true that legacy ATM switches can't do the kind of IP lookup necessary for data-plane forwarding. But it is also true that there are modern switches with cell-based backplanes that can do IP lookup and forwarding. Your use of the word "only" sounds like you're trying to draw a line in the sand somewhere, when in reality, that line is always in motion. MAY: u are write . Ok i agree that's true ;-) thanks -- David From owner-mpls@UU.NET Tue Aug 6 01:15: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 BAA16168 for ; Tue, 6 Aug 2002 01:15:35 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnart20576 for ; Tue, 6 Aug 2002 05:16: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 QQnart19363; Tue, 6 Aug 2002 05:16:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnart05754 for mpls-outgoing; Tue, 6 Aug 2002 05:15: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 QQnars05473 for ; Tue, 6 Aug 2002 05:14:59 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 QQnars09336 for ; Tue, 6 Aug 2002 05:14: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 QQnars17697 for ; Tue, 6 Aug 2002 05:14:04 GMT Received: from dharti.aplion.stpn.soft.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQnars17510 for ; Tue, 6 Aug 2002 05:13:58 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g765FTS32043 for ; Tue, 6 Aug 2002 10:45:29 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Subject: can lsp's be terminated within an atm core ???? Date: Tue, 6 Aug 2002 10:47:51 +0530 Message-ID: <015e01c23d08$9d3e3e50$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 following my previous question?? i wanted to know that can lsp's be originated and terminated within an atm backbone or is the concept itself totally wrong. thanks and regards Mayank From owner-mpls@UU.NET Tue Aug 6 02:38: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 CAA26779 for ; Tue, 6 Aug 2002 02:38:39 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnary25493 for ; Tue, 6 Aug 2002 06:39: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 QQnary23873; Tue, 6 Aug 2002 06:39:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnary03634 for mpls-outgoing; Tue, 6 Aug 2002 06:38:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnary03629 for ; Tue, 6 Aug 2002 06:38: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 QQnary16247 for ; Tue, 6 Aug 2002 06:37:24 GMT From: suchauhan@hss.hns.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 QQnary23093 for ; Tue, 6 Aug 2002 06:37:23 GMT Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQnary23083 for ; Tue, 6 Aug 2002 06:37:22 GMT Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g766bcY14263; Tue, 6 Aug 2002 12:07:38 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g766cOU17093; Tue, 6 Aug 2002 12:08:24 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C0D.0023F694 ; Tue, 6 Aug 2002 12:02:48 +0530 X-Lotus-FromDomain: HSS To: mkumar@aplion.stpn.soft.net cc: mpls@UU.NET Message-ID: <65256C0D.0023F3BE.00@sandesh.hss.hns.com> Date: Tue, 6 Aug 2002 12:04:13 +0530 Subject: Re: can lsp's be terminated within an atm core ???? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hmmmm I guess you saved the best for last! ;o) If all the assumptions that were clarified and confirmed in David's earlier mail regarding MPLS enabled ATM routers are accepted by you then the answer to your question is "yes" else its "no" cos' without those assumptions the ATM nodes are not in the MPLS cloud at all. sumit PS - ofcourse you could still configure a static ATM tunnel to tranparently carry labeled packets between two MPLS clouds. "Mayank Kumar" on 08/06/2002 10:47:51 AM Please respond to mkumar@aplion.stpn.soft.net To: "Mpls \(E-mail\)" cc: (bcc: Sumit Chauhan/HSS) Subject: can lsp's be terminated within an atm core ???? hi following my previous question?? i wanted to know that can lsp's be originated and terminated within an atm backbone or is the concept itself totally wrong. thanks and regards Mayank From owner-mpls@UU.NET Tue Aug 6 09:18: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 JAA10467 for ; Tue, 6 Aug 2002 09:18:58 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnasz19737 for ; Tue, 6 Aug 2002 13:20: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 QQnasz18257; Tue, 6 Aug 2002 13:19:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnasz12152 for mpls-outgoing; Tue, 6 Aug 2002 13:19: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 QQnasz12147 for ; Tue, 6 Aug 2002 13:19: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 QQnasz04377 for ; Tue, 6 Aug 2002 13:17: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 QQnasz12669 for ; Tue, 6 Aug 2002 13:17:09 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 QQnasz12665 for ; Tue, 6 Aug 2002 13:17:09 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFNYP>; Tue, 6 Aug 2002 09:17:09 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671FB@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'mkumar@aplion.stpn.soft.net'" Cc: "Mpls (E-mail)" Subject: RE: Layer 3 Lookup in ATM LSR's Date: Tue, 6 Aug 2002 09:17:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Mayank, Please see below. My comments are prefixed with "EG >"... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Tuesday, August 06, 2002 1:16 AM To: 'David Charlap' Cc: egray@celoxnetworks.com; Mpls (E-mail) Subject: RE: Layer 3 Lookup in ATM LSR's Hi Thanks David for ur comments. They seem correct. About my last line that only frame based lsr's are capable of ip forwarding in the data plane, when u are talking about atm interfaces capable of doing ip packet forwarding , then they are actually not operating in the cell mode but in frame mode. Thus frame based lsr's include atm swicthes operating in frame mode (ie receiving an ip packet as cells , reassembling it into a ip packet, doing a routing table lookup and then forwarding it as cells ). EG > Assembly, and subsequent re-segmentation, is not absolutely EG > needed however likely it is that it will be done in practice. Also please see inline with prefix MAY for more :- -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Charlap Sent: Tuesday, August 06, 2002 1:59 AM To: IETF MPLS List Subject: Re: Layer 3 Lookup in ATM LSR's Mayank Kumar wrote: > hi david > u have been repeatedly talking about the resource exhaustion problem. I > think that is taken care off by the Down stream on demand mode. What does > the Ordered control do here. I think Eric put it best. You don't want to advertise a label mapping if you can't forward traffic arriving on that label. If you don't have a downstream label yet, then you can't forward it as labeled traffic. If you're lookup capable, you can pop the label and forward based on the IP header. If you're not, then you have no choice but to drop traffic until the downstream label arrives. It isn't nice to your ingress nodes to give them labels that will result in dropped traffic. Those nodes would probably prefer to forward the packet through some other means until the LSP is completely up. MAY:does all the above amount to a good reason that why Atm lsr's shouldnt respond to a label allocation request unless they have a corresponding downstream mapping ???? EG > Only in a practical sense and then only for some ATM LSRs. EG > That may seem to be enough, but the facts do not support EG > such a sweeping statement. EG > EG > What you say is true for ATM LSRs which cannot forward IP EG > packets, either because they are not prepared to forward EG > them or because their downstream neighbor is not prepared EG > to receive them. EG > EG > There is nothing in the world to prevent a box which is a EG > purely ATM switch for all external appearances from being EG > essentially frame-based internally - particularly if it is EG > built to provide a limited set of AAL services. Such a EG > box can forward IP packets at the same rate that it can EG > forward the corresponding ATM Cells. Even if not actually EG > frame based, an ATM switch that is VC-Merge capable (with EG > out necessarily requiring assembly and re-segmentation) EG > may easily be capable of forwarding IP packets to its EG > downstream neighbor - provided it has an IP-in-ATM VC to EG > that neighbor. > Do u agree with the author of the Book when he says > " this action would require the downstream > lsr to have layer 3 lookup capability (such as if the downstream lsr would > have no further downstream label for the requested destination). Therefore, > the atm swicthes never respond to a label allocation request unless they > already have a corresponding downstream label allocated" I think that's a roundabout way of saying what I (and Eric) just said. > I think , that all these discussions conclude to the following:- > > --all lsr 's whether atm lsr's or frame lsr's , have layer 3 lookup > capability , which means to be able to determine the reachability of a > particular destination prefix by looking into a routing table (to determine > the next hop and output interface) . This also means that all lsr's have a > routing table too. > --all lsr's are able to orginate ip packets in the control plane (routing > protocol packets and Signalling protocol packets) > --all lsr's are able to receive ip packets in the control plane (routing > protocol packets and Signalling protocol packets) Absolutely. You couldn't run a signaling protocol without these three capabilities (a routing table of some form, and the ability to transmit and receive unlabeled packets.) MAY: can we differentiate between the following . I mean are these three capabilities different:- -- ability to orginate ip packets -- ability to receive ip packets -- ability to forward ip packets can an implementation only have the first two and not the second one.I EG > I think you meant "first two and not the third one." think that if its possible then we can say that atm swicthes do not have layer 3 forwarding capability in either the control plane or the data plane. Because in the data plane they do cell swicthing and in the control plane they either receive routing protocols packets destined locally or signalling protocol packets destined locally., or they orginate one but never forward any. But then i doubt how do targetted hellos would get forwarded ??? cisco routers allow u to configure an atm interface as either operating in cell mode or frame mode. however cisco switches do not allow an atm interface to operate in frame mode and cisco routers any way have layer 3 lookup and forwarding capability in the data plane. What i want to say that atm swicthes do not have layer 3 forwarding capability in the data plane because they alsways swicth cells and never operate in frame mode EG > You cannot generalize this to apply to all ATM switches. EG > We also need to stop trying to blur distinctions between EG > ATM switches and ATM LSRs. There are certain requirements EG > that apply to ATM LSRs and - if the only way you can see EG > to satisfy those requirements is to make the ATM LSR frame EG > based, then that is what you have to do. > --some lsr's might be able to forward ip packets in the control plane (for > eg an atm lsr might forward ip packets using its control vc by reassembling > an ip packet doing a routing table lookup and then determining the outgoing > interface and then further segmenting the cells again back when sending out > the outgoing interface determined using the routing table.) That would be correct. But it would be unreasonable to expect such forwarding capability to be robust enough to use for the data plane. Especially when people are selling switches with dozens of high-speed (like OC-12 and higher) interfaces. No software-based forwarder could keep up with a load like that. > --only edge lsr's are able to receive ip packets in the data plane. Yes. But "edge" can be a fuzzy term. If a transit router should pop a label (perhaps an LDP-signaled LSP ends in the middle of the cloud), the next router will receive an unlabeld packet. It may choose to encapsulate that packet in another label header and forward it through a second LSP. From the standpoint of those two routers where this happened, they are edges. > --only frame based lsr 's are able to forward ip packets in the data plane I wouldn't go that far. There are hop-by-hop routers with ATM interfaces. And there are intelligent lookup-capable interfaces for some ATM switches. Don't blur the lines between legacy implementations, current implementations, future implementations, and theoretical possibility. It is true that legacy ATM switches can't do the kind of IP lookup necessary for data-plane forwarding. But it is also true that there are modern switches with cell-based backplanes that can do IP lookup and forwarding. Your use of the word "only" sounds like you're trying to draw a line in the sand somewhere, when in reality, that line is always in motion. MAY: u are write . Ok i agree that's true ;-) thanks -- David From owner-mpls@UU.NET Tue Aug 6 09:48: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 JAA11744 for ; Tue, 6 Aug 2002 09:48:42 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnatb12994 for ; Tue, 6 Aug 2002 13:49: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 QQnatb11035; Tue, 6 Aug 2002 13:49:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnatb13344 for mpls-outgoing; Tue, 6 Aug 2002 13:48: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 QQnatb13335 for ; Tue, 6 Aug 2002 13:48:39 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 QQnatb19212 for ; Tue, 6 Aug 2002 13:47: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 QQnatb09822 for ; Tue, 6 Aug 2002 13:47:07 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 QQnatb09818 for ; Tue, 6 Aug 2002 13:47:07 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFN58>; Tue, 6 Aug 2002 09:47:07 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671FC@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'mkumar@aplion.stpn.soft.net'" Cc: "Mpls (E-mail)" Subject: RE: can lsp's be terminated within an atm core ???? Date: Tue, 6 Aug 2002 09:47:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Mayank, The concept itself is _not_ wrong. For example, if management traffic is carried to a core ATM LSR, the LSP on which it arrives must terminate at the ATM LSR. This is one reason for David's comment to the effect that the term 'edge' may be somewhat fuzzy. Also, a core-ward ATM LSR (or any LSR) may be at a place where the aggregate of IP destinations changes. In this case, an LSP carrying IP traffic to which this applies would terminate at that LSR (ATM or otherwise) and the IP traffic may be injected into another LSP for forwarding further toward the destination network. If you map out a few likely topologies, you will likely find that this is going to be the case for a significant amount of IP traffic on many LSPs at nearly every LSR. Core-ward ATM switches will only be an exception if they are not LSRs. This is another reason why edges are fuzzy. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Tuesday, August 06, 2002 1:18 AM To: Mpls (E-mail) Subject: can lsp's be terminated within an atm core ???? hi following my previous question?? i wanted to know that can lsp's be originated and terminated within an atm backbone or is the concept itself totally wrong. thanks and regards Mayank From owner-mpls@UU.NET Tue Aug 6 09:51: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 JAA11814 for ; Tue, 6 Aug 2002 09:51:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnatb25192 for ; Tue, 6 Aug 2002 13:52: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 QQnatb23767; Tue, 6 Aug 2002 13:51:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnatb13415 for mpls-outgoing; Tue, 6 Aug 2002 13:51: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 QQnatb13408 for ; Tue, 6 Aug 2002 13:51: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 QQnatb29501 for ; Tue, 6 Aug 2002 13:50: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 QQnatb01912 for ; Tue, 6 Aug 2002 13:50:27 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQnatb01873 for ; Tue, 6 Aug 2002 13:50:25 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17c4ix-0007Ld-00; Tue, 06 Aug 2002 14:50:11 +0100 Subject: Re: Layer 3 Lookup in ATM LSR's From: Giles Heron To: David Charlap Cc: IETF MPLS List In-Reply-To: <3D4ECBD3.9060902@marconi.com> References: <014f01c23cb0$3fa53ee0$fe04a8c0@cyborg> <3D4ECBD3.9060902@marconi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c+VPdj65v31PQGj5E2Mp" X-Mailer: Ximian Evolution 1.0.8 Date: 06 Aug 2002 14:49:55 +0000 Message-Id: <1028645396.1498.144.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk --=-c+VPdj65v31PQGj5E2Mp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable just one nit... On Mon, 2002-08-05 at 19:02, David Charlap wrote: [snip] > Lookup capability is also needed for a router (or interface) that must=20 > pop the label stack. It must do a label-lookup (which all switches can=20 > do), but it must then pop the stack and then do an IP lookup on the=20 > result before forwarding. This is beyond the capability of most ATM=20 > forwarding hardware. [rest snipped] this isn't strictly, true - is it? in some cases you may pop the stack but then forward the IP payload without actually performing an IP lookup (e.g. PHP). Giles --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=-c+VPdj65v31PQGj5E2Mp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9T+ITCDRkz2foctcRAgxQAJ4oHJ6QTQVzH+jFaJOY8uwhGGFoUQCeMBfE JKBJmtz2miMbeMnx0djbIpA= =HFYm -----END PGP SIGNATURE----- --=-c+VPdj65v31PQGj5E2Mp-- From owner-mpls@UU.NET Tue Aug 6 10:07:50 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12305 for ; Tue, 6 Aug 2002 10:07:50 -0400 (EDT) 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 QQnatc12122; Tue, 6 Aug 2002 14:03:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnatc26465 for mpls-outgoing; Tue, 6 Aug 2002 14:03: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 QQnatc26453 for ; Tue, 6 Aug 2002 14:03: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 QQnatc27409 for ; Tue, 6 Aug 2002 14:01: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 QQnatc15544 for ; Tue, 6 Aug 2002 14:01:53 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 QQnatc15534 for ; Tue, 6 Aug 2002 14:01:52 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFN8L>; Tue, 6 Aug 2002 10:01:52 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671FD@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Giles Heron'" Cc: David Charlap , "Mpls (E-mail)" Subject: RE: Layer 3 Lookup in ATM LSR's Date: Tue, 6 Aug 2002 10:01:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Giles, I think your point is valid, however, I also think David was making a reasonable simplification - logically, if the ingress interface 'pops' the label it would do so so that it can perform a new lookup on either the next label, or the IP header (if the popped label was the last label). Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Giles Heron [mailto:giles@packetexchange.net] Sent: Tuesday, August 06, 2002 10:50 AM To: David Charlap Cc: IETF MPLS List Subject: Re: Layer 3 Lookup in ATM LSR's just one nit... On Mon, 2002-08-05 at 19:02, David Charlap wrote: [snip] > Lookup capability is also needed for a router (or interface) that must > pop the label stack. It must do a label-lookup (which all switches can > do), but it must then pop the stack and then do an IP lookup on the > result before forwarding. This is beyond the capability of most ATM > forwarding hardware. [rest snipped] this isn't strictly, true - is it? in some cases you may pop the stack but then forward the IP payload without actually performing an IP lookup (e.g. PHP). Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Tue Aug 6 11:46: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 LAA15664 for ; Tue, 6 Aug 2002 11:46:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnatj23458 for ; Tue, 6 Aug 2002 15:47: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 QQnatj22284; Tue, 6 Aug 2002 15:47:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnatj07372 for mpls-outgoing; Tue, 6 Aug 2002 15:46: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 QQnatj07365 for ; Tue, 6 Aug 2002 15:46: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 QQnatj23626 for ; Tue, 6 Aug 2002 15:46: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 QQnatj21873 for ; Tue, 6 Aug 2002 15:46:23 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 QQnatj21864 for ; Tue, 6 Aug 2002 15:46:23 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 LAA01195; Tue, 6 Aug 2002 11:46:21 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA01637; Tue, 6 Aug 2002 11:46:22 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W993C5H>; Tue, 6 Aug 2002 11:46:21 -0400 Message-ID: <313680C9A886D511A06000204840E1CF3EDA4D@whq-msgusr-02.pit.comms.marconi.com> From: "Sathappan, Senthilkumar" To: "Thomas D. Nadeau" Cc: mpls@UU.NET Subject: Question on MPLS-TE and MPLS-LSR MIB Date: Tue, 6 Aug 2002 11:46:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk If a Tunnel Instance is created in MPLS-TE mib with Owner set to admin and SignallingProto set to rsvp. Please let me know what should be MPLS-LSR mib's XCOwner Thanks, Senthil. From owner-mpls@UU.NET Tue Aug 6 14:55: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 OAA24167 for ; Tue, 6 Aug 2002 14:55:04 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnatv25068 for ; Tue, 6 Aug 2002 18:56: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 QQnatv23966; Tue, 6 Aug 2002 18:55:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnatv26773 for mpls-outgoing; Tue, 6 Aug 2002 18:55: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 QQnatv26753 for ; Tue, 6 Aug 2002 18:55:09 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 QQnatv09104 for ; Tue, 6 Aug 2002 18:54: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 QQnatv26977 for ; Tue, 6 Aug 2002 18:54:33 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 QQnatv26972 for ; Tue, 6 Aug 2002 18:54:33 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 6 Aug 2002 14:54:18 -0400 Message-ID: <015d01c23d7a$aaee65d0$681810ac@movaz.com> From: "Adrian Farrel" To: "Sathappan, Senthilkumar" , "Thomas D. Nadeau" Cc: References: <313680C9A886D511A06000204840E1CF3EDA4D@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: Question on MPLS-TE and MPLS-LSR MIB Date: Tue, 6 Aug 2002 14:54:17 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 06 Aug 2002 18:54:18.0206 (UTC) FILETIME=[AAE257E0:01C23D7A] Sender: owner-mpls@UU.NET Precedence: bulk Slight feeling that this may be a trick question! > If a Tunnel Instance is created in MPLS-TE mib with Owner set to admin and > SignallingProto set to rsvp. > Please let me know what should be MPLS-LSR mib's XCOwner Answer: rsvp or unknown depending on your implementation. mplsXCOwner OBJECT-TYPE SYNTAX MplsInitialCreationSource MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes the entity that created and is responsible for managing this cross-connect. This object cannot be modified if mplsXCRowStatus is active(1)." ::= { mplsXCEntry 5 } MplsInitialCreationSource ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The entity that originally created the object in question. The values of this enumeration are defined as follows: other(1) - This is used when an entity which has not been enumerated in this textual convention but which is known by the agent. snmp(2) - The Simple Network Management Protocol was used to configure this object initially. ldp(3 - The Label Distribution Protocol was used to configure this object initially. rsvp(4) - The Resource Reservation Protocol was used to configure this object initially. crldp(5) - The Constraint-Based Label Distribution Protocol was used to configure this object initially. policyAgent(6) - A policy agent (perhaps in combination with one of the above protocols) was used to configure this object initially. unknown(7) - the agent cannot discern which component created the object." SYNTAX INTEGER { other(1), snmp(2), ldp(3), rsvp(4), crldp(5), policyAgent(6), unknown (7) } Adrian From owner-mpls@UU.NET Tue Aug 6 15:12: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 PAA24720 for ; Tue, 6 Aug 2002 15:11:59 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnatw09464 for ; Tue, 6 Aug 2002 19:13: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 QQnatw07441; Tue, 6 Aug 2002 19:11:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnatw20517 for mpls-outgoing; Tue, 6 Aug 2002 19:11: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 QQnatw20490 for ; Tue, 6 Aug 2002 19:11:25 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 QQnatw08674 for ; Tue, 6 Aug 2002 19:11: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 QQnatw06994 for ; Tue, 6 Aug 2002 19:11: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 QQnatw06977 for ; Tue, 6 Aug 2002 19:11: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 PAA03775 for ; Tue, 6 Aug 2002 15:11:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA16761 for mpls@uu.net; Tue, 6 Aug 2002 15:11:06 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnatw19742 for ; Tue, 6 Aug 2002 19: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 QQnatw27744 for ; Tue, 6 Aug 2002 19:09: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 QQnatw05840 for ; Tue, 6 Aug 2002 19:09: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 QQnatw05831 for ; Tue, 6 Aug 2002 19:09: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 g76J995d009865; Tue, 6 Aug 2002 15:09:10 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-155.cisco.com [161.44.134.155]) by bucket.cisco.com (Mirapoint) with ESMTP id ABK00163; Tue, 6 Aug 2002 15:09:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20020806150843.01c616f0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Aug 2002 15:09:07 -0400 To: "Cheenu Srinivasan" From: "Thomas D. Nadeau" Subject: RE: draft-nadeau-mpls-lc-if-mib-00.txt Cc: , In-Reply-To: <9791A828507D5A418741095C3FD0DDE35EB77A@indus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, Thanks for the comments. We will incorporate and re-post. --Tom >A few comments: > >- TOC is that of the LSR MIB! > >- Abstract - how about: > > This memo defines MIB modules to realize label switching controlled > Frame Relay and ATM interfaces given the interface stacking defined > in MPLS-LSR-MIB and MPLS-TE-MIB. > >- Section 6 starts of talking about LC-ATM interfaces and then starts > referring to both ATM and FR interfaces. You should probably have > seperate sections for the two or rename the section and describe > the two in seperate paras. > >- Update the date(s) in the MODULE-IDENTITY. > >- In the description of the tables you say that entries in the table > are created by the LSR (automatically, as opposed to creation by the > operator). Then, why do you need the RowStatus object? The LSR presumably > creates the entry indicating whatever default capability and (optionally) > allows the operator to change ranges etc. Am I missing something? > >- Sec. 12 - you say: "This module does not define any management objects. >Instead, it > defines two new ifTypes which may be used by other MPLS MIB > modules to define management objects." > > Rewrite this as this doc contains two modules which definitely define > management objects! Since these are writeable you will have some > security considerations - section 11 of the LSR would be a decent > template. Also I didn't see any new ifType defined - you > have instead added augments to the interface conf table. > >Hope this helps. > >Cheenu > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Monday, June 24, 2002 4:03 PM > > Subject: draft-nadeau-mpls-lc-if-mib-00.txt > > > > > > > > FYI, the new draft draft-nadeau-mpls-lc-if-mib-00.txt > > has been published in the I-D repository. I would appreciate > > it if you could give it a look-see when you had a chance. > > > > --Tom > > > > > > -------------------------------------------------------------- > > ---------- > > Mathematics is the supreme nostalgia of our time. > > > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Tue Aug 6 15:30: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 PAA25464 for ; Tue, 6 Aug 2002 15:30:19 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaty19607 for ; Tue, 6 Aug 2002 19:31: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 QQnaty17231; Tue, 6 Aug 2002 19:30:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnatx22230 for mpls-outgoing; Tue, 6 Aug 2002 19:29:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnatx22224 for ; Tue, 6 Aug 2002 19:29: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 QQnatx17506 for ; Tue, 6 Aug 2002 19:29: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 QQnatx24849 for ; Tue, 6 Aug 2002 19:29:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnatx24840 for ; Tue, 6 Aug 2002 19:29:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA05102 for ; Tue, 6 Aug 2002 15:29:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA19293 for mpls@uu.net; Tue, 6 Aug 2002 15:29:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnatx22192 for ; Tue, 6 Aug 2002 19:28:27 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 QQnatx23300 for ; Tue, 6 Aug 2002 19:27: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 QQnatx24087 for ; Tue, 6 Aug 2002 19:27:55 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 QQnatx24072 for ; Tue, 6 Aug 2002 19:27: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 g76JRr1L012092; Tue, 6 Aug 2002 15:27:54 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-155.cisco.com [161.44.134.155]) by bucket.cisco.com (Mirapoint) with ESMTP id ABK00628; Tue, 6 Aug 2002 15:27:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20020806152626.05b99850@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Aug 2002 15:27:50 -0400 To: "Adrian Farrel" From: "Thomas D. Nadeau" Subject: Re: Question on MPLS-TE and MPLS-LSR MIB Cc: "Sathappan, Senthilkumar" , In-Reply-To: <015d01c23d7a$aaee65d0$681810ac@movaz.com> References: <313680C9A886D511A06000204840E1CF3EDA4D@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I agree with Adrian's assertion that the value should be set to 'rsvp' or 'unknown'. The entity that created the tunnel head actually did not create its underlying LSP, which is what is represented in the MPSL-LSR MIB's XCEntry. --Tom >Slight feeling that this may be a trick question! > > > If a Tunnel Instance is created in MPLS-TE mib with Owner set to admin and > > SignallingProto set to rsvp. > > Please let me know what should be MPLS-LSR mib's XCOwner > >Answer: rsvp or unknown depending on your implementation. > >mplsXCOwner OBJECT-TYPE > SYNTAX MplsInitialCreationSource > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Denotes the entity that created and is responsible > for managing this cross-connect. This object cannot > be modified if mplsXCRowStatus is active(1)." > ::= { mplsXCEntry 5 } > >MplsInitialCreationSource ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The entity that originally created the object in > question. The values of this enumeration are > defined as follows: > > other(1) - This is used when an entity which has not > been enumerated in this textual convention but > which is known by the agent. > > snmp(2) - The Simple Network Management Protocol was > used to configure this object initially. > > ldp(3 - The Label Distribution Protocol was used to > configure this object initially. > > rsvp(4) - The Resource Reservation Protocol was used > to configure this object initially. > > crldp(5) - The Constraint-Based Label Distribution > Protocol was used to configure this object > initially. > > policyAgent(6) - A policy agent (perhaps in > combination with one of the above protocols) was > used to configure this object initially. > > unknown(7) - the agent cannot discern which > component created the object." > SYNTAX INTEGER { > other(1), > snmp(2), > ldp(3), > rsvp(4), > crldp(5), > policyAgent(6), > unknown (7) > } > >Adrian ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Wed Aug 7 00:33: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 AAA12019 for ; Wed, 7 Aug 2002 00:33:47 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnavi25551 for ; Wed, 7 Aug 2002 04:34: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 QQnavi24327; Wed, 7 Aug 2002 04:34:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnavi23844 for mpls-outgoing; Wed, 7 Aug 2002 04:33:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnavi23838 for ; Wed, 7 Aug 2002 04:33:38 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 QQnavi24855 for ; Wed, 7 Aug 2002 04:33: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 QQnavi17182 for ; Wed, 7 Aug 2002 04:33:09 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 QQnavi17162 for ; Wed, 7 Aug 2002 04:33:04 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g774XTX12125; Wed, 7 Aug 2002 10:03:29 +0530 Reply-To: From: "Mayank Kumar" To: "'Gray, Eric'" Cc: "Mpls \(E-mail\)" Subject: RE: can lsp's be terminated within an atm core ???? Date: Wed, 7 Aug 2002 10:05:33 +0530 Message-ID: <018101c23dcb$ded76a30$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 In-Reply-To: <1117F7D44159934FB116E36F4ABF221B022671FC@celox-ma1-ems1.celoxnetworks.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi eric thanks for the comments ! ur point regarding the termination of lsp's in the atm core does not seem valid in a few scenarios. Lets say the aggregation point for some summary route is x which is an atm core lsr or an atm swicth supporting mpls. in that case if an lsp using a summary route terminates at this lsr , then either this lsr has to perform a second level label lookup to decide the next lsp tunnnel it should enter or do a ip lookup and forward traffic accordingly on the destination field . So this means that the aggregation point should never be an atm switch as they are not capable for ip forwarding in the data plane. What do u say regarding this??? if i am correct then please give another example of lsp's terminating in the atm core. thanks and regards mayank -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: Tuesday, August 06, 2002 7:17 PM To: 'mkumar@aplion.stpn.soft.net' Cc: Mpls (E-mail) Subject: RE: can lsp's be terminated within an atm core ???? Mayank, The concept itself is _not_ wrong. For example, if management traffic is carried to a core ATM LSR, the LSP on which it arrives must terminate at the ATM LSR. This is one reason for David's comment to the effect that the term 'edge' may be somewhat fuzzy. Also, a core-ward ATM LSR (or any LSR) may be at a place where the aggregate of IP destinations changes. In this case, an LSP carrying IP traffic to which this applies would terminate at that LSR (ATM or otherwise) and the IP traffic may be injected into another LSP for forwarding further toward the destination network. If you map out a few likely topologies, you will likely find that this is going to be the case for a significant amount of IP traffic on many LSPs at nearly every LSR. Core-ward ATM switches will only be an exception if they are not LSRs. This is another reason why edges are fuzzy. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Tuesday, August 06, 2002 1:18 AM To: Mpls (E-mail) Subject: can lsp's be terminated within an atm core ???? hi following my previous question?? i wanted to know that can lsp's be originated and terminated within an atm backbone or is the concept itself totally wrong. thanks and regards Mayank From owner-mpls@UU.NET Wed Aug 7 08: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 IAA15636 for ; Wed, 7 Aug 2002 08:50:20 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnawp07009 for ; Wed, 7 Aug 2002 12:51: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 QQnawp05492; Wed, 7 Aug 2002 12:50:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnawp28868 for mpls-outgoing; Wed, 7 Aug 2002 12:50: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 QQnawp28853 for ; Wed, 7 Aug 2002 12:50:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnawp12864 for ; Wed, 7 Aug 2002 12:49: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 QQnawp04257 for ; Wed, 7 Aug 2002 12:49:06 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 QQnawp04253 for ; Wed, 7 Aug 2002 12:49:06 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFQ6K>; Wed, 7 Aug 2002 08:49:05 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267212@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'mkumar@aplion.stpn.soft.net'" , "Gray, Eric" Cc: "Mpls (E-mail)" Subject: RE: can lsp's be terminated within an atm core ???? Date: Wed, 7 Aug 2002 08:49:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Mayank, :-) It looks as if you are still blurring the distinction between ATM Switch and ATM LSR. You seem to be using the terms interchangeably in your comment below. An ATM switch might be used to provide L2 forwarding between ATM routers (or LSRs). In this capacity, that ATM switch is part of a link in a routing topology, but otherwise is not relevant in discussing behavior of ATM routers and LSRs. As I said earlier, an LSR is by definition an MPLS node that is able to do L3 forwarding. An ATM LSR is not an exception. So, while you are correct in saying that an ATM switch that has no IP forwarding capability cannot be a point where aggregates change, this is not a surprise. Such an ATM switch cannot be a router and should not actively participate in routing protocol exchanges. Such an ATM switch would be transparent to routing and thus could not be a point where aggregates change. Since such an ATM switch cannot be a router, it cannot be an ATM LSR. For network resource efficiency reasons, ATM LSRs may be part of an ATM core. In fact, it is likely that many ATM switches in an ATM core will be ATM LSRs (if MPLS is being used at all, that is). Since each LSR is a router, route aggregates may change at each LSR. Hence, each ATM LSR in an ATM core may need to terminate and originate LSPs. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Wednesday, August 07, 2002 12:36 AM To: 'Gray, Eric' Cc: Mpls (E-mail) Subject: RE: can lsp's be terminated within an atm core ???? hi eric thanks for the comments ! ur point regarding the termination of lsp's in the atm core does not seem valid in a few scenarios. Lets say the aggregation point for some summary route is x which is an atm core lsr or an atm swicth supporting mpls. in that case if an lsp using a summary route terminates at this lsr , then either this lsr has to perform a second level label lookup to decide the next lsp tunnnel it should enter or do a ip lookup and forward traffic accordingly on the destination field . So this means that the aggregation point should never be an atm switch as they are not capable for ip forwarding in the data plane. What do u say regarding this??? if i am correct then please give another example of lsp's terminating in the atm core. thanks and regards mayank -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: Tuesday, August 06, 2002 7:17 PM To: 'mkumar@aplion.stpn.soft.net' Cc: Mpls (E-mail) Subject: RE: can lsp's be terminated within an atm core ???? Mayank, The concept itself is _not_ wrong. For example, if management traffic is carried to a core ATM LSR, the LSP on which it arrives must terminate at the ATM LSR. This is one reason for David's comment to the effect that the term 'edge' may be somewhat fuzzy. Also, a core-ward ATM LSR (or any LSR) may be at a place where the aggregate of IP destinations changes. In this case, an LSP carrying IP traffic to which this applies would terminate at that LSR (ATM or otherwise) and the IP traffic may be injected into another LSP for forwarding further toward the destination network. If you map out a few likely topologies, you will likely find that this is going to be the case for a significant amount of IP traffic on many LSPs at nearly every LSR. Core-ward ATM switches will only be an exception if they are not LSRs. This is another reason why edges are fuzzy. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Tuesday, August 06, 2002 1:18 AM To: Mpls (E-mail) Subject: can lsp's be terminated within an atm core ???? hi following my previous question?? i wanted to know that can lsp's be originated and terminated within an atm backbone or is the concept itself totally wrong. thanks and regards Mayank From owner-mpls@UU.NET Wed Aug 7 18:13: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 SAA11518 for ; Wed, 7 Aug 2002 18:13:02 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaya06016 for ; Wed, 7 Aug 2002 22:14: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 QQnaya04358; Wed, 7 Aug 2002 22:13:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnaya23809 for mpls-outgoing; Wed, 7 Aug 2002 22:13:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnaya23804 for ; Wed, 7 Aug 2002 22:13:00 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 QQnaya29826 for ; Wed, 7 Aug 2002 22:11:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnaya29895 for ; Wed, 7 Aug 2002 22:11:51 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnaya29891 for ; Wed, 7 Aug 2002 22:11:51 GMT Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g77MBdr27337 for ; Wed, 7 Aug 2002 18:11:39 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NGKKZVYH; Wed, 7 Aug 2002 18:11:38 -0400 Received: from nortelnetworks.com (potti.engeast.baynetworks.com [47.17.140.52]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NSA92J8R; Wed, 7 Aug 2002 18:11:38 -0400 Message-ID: <3D519B1A.33B0DB46@nortelnetworks.com> Date: Wed, 07 Aug 2002 18:11:38 -0400 From: Rajesh Potti Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Carrying Label mapping Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id SAA11518 Hi, The RFC 3107 (Carrying Label Information in BGP-4) says that in the BGP updates carrying multiprotocol extensions attribute, the fact that the NLRI contains a label is indicated by using SAFI value 4. But most implementations seem to be using the SAFI value 128. Under what circumstances is the SAFI value 4 used? Thanks, Rajesh From owner-mpls@UU.NET Wed Aug 7 22:59:12 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18682 for ; Wed, 7 Aug 2002 22:59:11 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnayu22354 for ; Thu, 8 Aug 2002 03:00: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 QQnayt20744; Thu, 8 Aug 2002 02:59:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnayt14317 for mpls-outgoing; Thu, 8 Aug 2002 02:59: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 QQnayt14312 for ; Thu, 8 Aug 2002 02:59: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 QQnayt13296 for ; Thu, 8 Aug 2002 02:59: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 QQnayt20392 for ; Thu, 8 Aug 2002 02:59:05 GMT Received: from india.mercurykr.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQnayt20356 for ; Thu, 8 Aug 2002 02:58:58 GMT Received: from Anuj (mercury-206-143-del.mercurykr.com [203.196.143.206] (may be forged)) by india.mercurykr.com (8.11.2/8.11.2) with SMTP id g782Ysc02095; Thu, 8 Aug 2002 08:04:56 +0530 MIME-Version: 1.0 Message-Id: <3D51DC9F.00000D.78993@Anuj.dti.daewoo.co.kr> Date: Thu, 8 Aug 2002 08:21:11 +0530 (India Standard Time) Content-Type: Text/Plain X-Mailer: IncrediMail 2001 (1500245) From: "Anuj Kumar Garg" References: <3D519B1A.33B0DB46@nortelnetworks.com> X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 To: , Subject: Re: Carrying Label mapping Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA18682 Hi Rajesh , SAFI value 128 is used when you want to carry VPNV4 routes in BGP-4 MP_REACH_NLRI attribute. This implementation use the label encoding scheme used in RFC 3107 but use the SAFI value as 128 only. However when you wish to use BGP to carry the label information for label distribution purposes for MPLS then you should use SAFI value as 4 . Anuj Subject: Carrying Label mapping Hi, The RFC 3107 (Carrying Label Information in BGP-4) says that in the BGP updates carrying multiprotocol extensions attribute, the fact that the NLRI contains a label is indicated by using SAFI value 4. But most implementations seem to be using the SAFI value 128. Under what circumstances is the SAFI value 4 used? Thanks, Rajesh From owner-mpls@UU.NET Wed Aug 7 23:41:37 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19674 for ; Wed, 7 Aug 2002 23:41:37 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnayw15630 for ; Thu, 8 Aug 2002 03:42: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 QQnayw14280; Thu, 8 Aug 2002 03:42:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnayw09868 for mpls-outgoing; Thu, 8 Aug 2002 03:41:45 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 QQnayw09863 for ; Thu, 8 Aug 2002 03:41: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 QQnayw19589 for ; Thu, 8 Aug 2002 03:40: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 QQnayw13754 for ; Thu, 8 Aug 2002 03:40:48 GMT Received: from mail.site.uottawa.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailn.site.uottawa.ca [137.122.89.142]) id QQnayw13747 for ; Thu, 8 Aug 2002 03:40:48 GMT Received: from site.uottawa.ca (bwwil28.site.uottawa.ca [137.122.91.149]) by mail.site.uottawa.ca (8.9.3/8.9.3) with ESMTP id XAA81406 for ; Wed, 7 Aug 2002 23:40:32 -0400 (EDT) Message-ID: <3D51E837.5AC37E9D@site.uottawa.ca> Date: Wed, 07 Aug 2002 23:40:39 -0400 From: bin X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 CC: mpls@UU.NET Subject: Difference in processing Error code 24 (routing problem) and 25 (notify Error) References: <3D519B1A.33B0DB46@nortelnetworks.com> <3D51DC9F.00000D.78993@Anuj.dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am wondering the difference in processing Error code 24 (routing problem) and 25 (notify Error). I want to define a error value for explicit route update under the error code. Regards, Bin From owner-mpls@UU.NET Thu Aug 8 08:09: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 IAA08879 for ; Thu, 8 Aug 2002 08:09:10 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbae27753 for ; Thu, 8 Aug 2002 12:10: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 QQnbae26705; Thu, 8 Aug 2002 12:09:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbae07055 for mpls-outgoing; Thu, 8 Aug 2002 12:09: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 QQnbae07039 for ; Thu, 8 Aug 2002 12:09:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnbae19872 for ; Thu, 8 Aug 2002 12:08: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 QQnbae08596 for ; Thu, 8 Aug 2002 12:08:48 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnbae08573 for ; Thu, 8 Aug 2002 12:08:47 GMT Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by blooper.utfors.se (Utfors AB) with ESMTP id g78C8Q5F007028; Thu, 8 Aug 2002 14:08:26 +0200 (MEST) Message-ID: <3D525F3B.2020402@utfors.se> Date: Thu, 08 Aug 2002 14:08:27 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: MPLS wg CC: George Swallow , Scott Bradner Subject: final notes from the mpls meeting in Yokohama Content-Type: multipart/mixed; boundary="------------010701010704020909040805" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------010701010704020909040805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit All, included are the final notes from the mpls meeting in Yokohama. "Final" - unless there are further comments ;) Again thanks to Eric G and Dave for taking notes! I've also complemented the agenda from meeting to include all slides that were used. Will be found at: http://62.119.0.68/~loa/mpls_agenda_for_yokohama.htm /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se --------------010701010704020909040805 Content-Type: text/plain; name="final-mpls-minutes.txt" Content-Disposition: inline; filename="final-mpls-minutes.txt" Content-Transfer-Encoding: 7bit IETF 54 MPLS WG Notes Thursday July 12. 9 - 11.30 AM Chair - Loa Andersson (George Swallow not in attendance). Note Takers - David Allan, Eric Gray Loa: Agenda bashing -------------- - process reminders/blue sheets - LDP MTU draft off the agenda - No further comments on the agenda Loa: LDP (RFC 3036) to draft standard (status) ---------------------------------------------------------------------- Loa talked about the need to collect implementation information on LDP for taking it to Draft Standard. It is still not clear how many other RFCs will be affected, encap and LDP draft, maybe also architecture. This is because of normative references. A survey form is developed and will be published on the list in a few weeks, together with instructions on how to respond. Asked to include an anonymity option. Scot Bradner will act as anonymizer. Results will be published as an I-D. One intention will be to simplify LDP, so unimplemented stuff will be removed when LDP is moved to draft standard. Scott Bradner AD: Current state of the issues in the mpls oam discussion and the ITU-T liaison. ---------------------------------------------------------------------- The background is that we have an I-D, by Hiroshi Ohta, requesting a reserved label to be used by ITU-T, for OAM. At the last meeting the discussion concerned changes to IETF protocols that would result. As a result a liaison was sent for clarification, asking if they were operatingunder the assumption that they would be requesting changes. The draft is called: "Use of a reserved label value defined in RFC 3032 for MPLS OAM functions" Liaison response: Hiroshi Ohta (SG13 Rapporteur, slides included) Hiroshi Ohta presented a report on ITU-T's response to IETF's liaison on MPLS OAM. He stated that they do not expect to impact IETF protocols and minimal impact on implementations. Y.1711 cannot work without the reserved label - therefore, they request that IANA assign a reserved label. Discussion ---------- Rahul Aggarwal: The statement of no impact on forwarding plane is inaccurate, on egress LSRs there will be an impact. Kireeti: If we allocate this label, will the ITU use this label 'efficiently', in other words, will there be other requests. Scott: The ITU is finding that IETF protocols are popular, so they want to use them. He gave an example of the process using SIP. The IETF decides that protocols developed by IETF need to be reviewed by IETF when extensions are being proposed. Kireeti: there are two concerns, one is the IETF process (which is good) band the other is how far does this go? Do they need to go through the RFC process. Scott: This may be dealt with in many ways, however we hope that the cooperative approach will work. Scott asked the sense of the room: We have an I-D seeking assignment, we've interacted to find out answers to questions we've asked. I think this is a good thing, both cooperatively and for the good of the protocol. MPLS is being used in a number of environments, and the usage assumptions are different depending on the carrier. We need to support the IP carrier, but that is not all of them. In that context we should be open to the use of our protocols in other environments. For MPLS to be seen as useful in trad telco environments it needs this stuff. Hummm (a few raised hands :)) showed a consensus for RFC publishing the draft and issuing the label. Scott Bradner: rsvp-te vs. cr-ldp, initiating a discussion ---------------------------------------------------------------------- In the implementation survey for GMPLS, there was lots of RSVP and little CR-LDP. Concern in ISEG on multiple standards track ways of doing something is confusing to the market place. Don't need to visit the history. Don't think we need to stop publishing CR-LDP, but should they be informational or standards track. Discussion: ---------- Loa: The intent of having this agenda item is to initiate the discussion, not arrive at a conclusion at this meeting. Bilel Jamoussi: Comment on the survey. Did not state the objective or indicate how it was going to be used. Not scientific by any means. More importantly GMPLS is a new thing, carriers are still debating the architectures. Think the discussion is premature. There are today several networks running CR-LDP in a packet environment. Bert: Purpose of survey was to seek an implementation report before approving GMPLS. This was an artifact of the survey not the intent. I don't think discussion is premature, a decision may be. Folks can still implement informational. Within one org you would normally try to go for one standard. Kireeti: I wear several hats. CCAMP chair, twice as many protocol extensions because of two protocols. Have to write two sets of drafts as an author. Have to read twice as many. As a vendor I do not care, and do not implement it. Impact on IETF is twice as much material. Luca Martini: as a service provider, we found RSVP predominantly deployed and implemented. Pushed by a particular vendor for an obscure reason. We should shift CR-LDP to informational. Ron Bonica: Like to second what Luca said. IETF produces too much technology to do a good job. Lets prune. Chris Liljenstolpe: Third what Luca said. Osama Aboul-Magd: From transport POV, the market is really slow so deployment is pretty much nonexistent. This is not an indicator. Joel Halpern: Helped work on CR-LDP, technically prefer it. That's irrelevant, its not about what is technically better, RSVP won the fight. Bilel: Agree on one application. Not necessarily so for optical transport. For packet TE, RSVP has one the fight. In optical it is premature. So Packet TE it is overwhelmingly RSVP, but GMPLS it is premature. Folks are building on the CR-LDP. There are other examples of multiple protocols. Bert: Past potential mistakes are not necessarily an indication of what we should do in the future. In this case one far outweighs the other. Chippy: We don't support it because we have no customer demand. Ludo Practico: We support both and get interest in both. Discussion to move to the mailing list. Loa: Confine it to the MPLS list, but we'll send mail to the other sub-ip list informing them about the discussion. Bert Wijnen Status and issues with the mpls mibs ---------------------------------------------------------------------- We have lots of MPLS MIBs. Although separately they looks OK, there was a lot of overlaps (TCs and the like, some conflicting). Shows authors not working together, and no cross review of how they play together. No discontinuity timers for counters, or how MIBs relate to each other. etc. etc. Several issues, including inconsistencies and duplicated uses. Also, there are uses defined that are not consistent with common usage elsewhere. Some MIBs have already become RFCs and others have been held up in queue for corrections. There is a draft that attempt to capture the relationships between various MIBs, but this does not do quite enough. Also, there are some MIBs that are fairly 'all- inclusive' and it is not clear that this is always a good thing. Also, there are differences in the 'tolerance' levels for various MIB compilers and this results in MIBs that do not compile using some MIB compilers. We would also like to see better communications between various MIB development efforts. We would also like to see who is implementing which MIBs. Finally, people should get help for MIBs at mibs@ops.ietf.org or by asking the SNMP/MIB advisor for the working group. If there is no SNMP/MIB advisor, get one. Summary: - Main concerns/worries: o How do Label Distribution Protocols, SNMP, Manual config, GSMP interact and make sure they do not step on each others toes?? o How are assignments under mplsMIB controlled? o Who is implementing all these Mibs? o How is the impact on follow up (G)MPLS MIBs? - Status/Action plan o Authors have answered a lot of comments and supposedly know what needs to be fixed. o Authors revising MIBs to address comments. Sofar I have received a new TC MIB, need revisions of all otehr MIBs o Then will need to re-review (MIB-Doctor) o I want the WG to re-review as well and make sure that you all agree, before it gets approved Marcus: We have actually implemented some MIBs only partially. Bert: The correct way to work through this is to talk about these issues on the public mailing list so that everyone can benefit from understanding the issues and answers. Kireeti: Asked if Marcus had tried the TE-WG MIB. Marcus Brunner: I was actually referring to the LSR MIB. Vach Kompella: I've had issues with the LDP MIB and we've also implemented a proprietary MIB that supports a subset of the MIB. Bert: The LSR MIB is in IESG review at this time. We had reports that people are implementing the LDP MIB. Loa: My impression is that the MIBs have become complicated and uncoordinated. My feeling that we still need to think about what to do next. It is at least clear that enough changes have occurred since the last set of last calls that once we see the updated MIBs we will need another round of last calls. Andy Malis Status of LDP restart and LDP fault tolerance drafts Fault Tolerance for LDP and CR-LDP Graceful Restart Mechanism for LDP ---------------------------------------------------------------------- Andy: The latest status is that the LDP FT draft was successfully merged with the Smith (check-pointing) draft. The LDP Restart draft actually has a different applicability with very little overlap. The last call has been completed, George Swallow has proposed some changes, some minor editing has to be done and then the draft should go to the IESG. Sven van den Bosch Further considerations for Forwarding Adjacency LSPs ---------------------------------------------------------------------- Sven van den Bosch : This is version one of the document, related to LSP hierarchy 07 WG draft, since there might be some interdepencies betseen the resource classes and the use of backup LSPs without any assigned bandwidth, The issues addressed is complex resources classes and a new sub-class of TLVs proposed. Alternatively it could be possible to approach the IS-IS and OSPF wg's and suggest that they define extensions to the protocols. Amir Hermelin: Is it the the goal of this draft is to be merged into other work. Sven: I feel it is useful to keep the draft as an overview of outstanding issues but that any eventual resolution of any of the issues could be merged with other work. Kireeti: Not sure that all cases of complex resource classes can be represented. Sven: I'm aware that there is at least one case that his proposal does not cover, but also feels that there is a real need to solve a subset of the problem space that his proposal does address. Although the solution does not work in this particular case, an operator will always know (by virtue of its resource class specification policy) whether or not it is safe to use the proposed solution. Loa: Take this back to the list and make a decision once all the implications are clear. B Jensen:(University of Wisconsin) General Summary of Interoperability Testing Results and Experiences ---------------------------------------------------------------------- There are interoperability efforts from several organizatios e.g. UNH, AIL, MPLS Forum etc. There has been private tests in April, NI in May, and then Supercom. White paper will available from MPLS forum. The Draft is key findings from April, test configuration are shown in the slides. IP transport, plus L2 and L3 VPN apps (2547/Martini Ethernet), POS and GigE plus some ATM. Has been tested. Issues found: OSPF TE is not universally supported even though required for TE LSPs Vendor implementations only support a single distribution mode (DU/DoD) Not all RSVP-TE implementations support both FF and SE reservation styles Inconsistent use of IP addresses in ERO RESV_CONFIRM is not universally supported Explicit NULL label is not universally supported Discussion: Amir said that he was surprised that the presentation was being given before there was a white paper presented and said that the issue with explicit NULL labels is essentially because of a misunderstanding of the standard. Satoru Matsoshima asked about DU implementations that do not respond to requests for Labels. Rahul said that their implementation simply supports all of the possible ERO IP address usages. Amir commented on the ERO issue, saying this is critical. Loa said that the discussion should be continued on the list, thanked him for the report. J-P Vasseur MPLS Traffic Engineering Fast reroute: backup tunnel path computation for bandwidth protection ---------------------------------------------------------------------- P Vasseur: The draft addresses the charter item dealing with recovery mechanisms and focus on bandwidth protection issues. The draft proposes two basic approaches - centralized and distributed. It was pointed out that a Naive approach - using CSPF to setup backup paths - has two key problems: it cannot protect the bandwidth and it is possible that no solution can be found even though it can be shown that one must exist (as a result of timing). Examples of real life scenarios were given, in which bandwidth protection is needed. Bandwidth protection is needed for some traffic in some networks and input on the draft is solicited. Sven said that he is interested in this work. Loa suggested that comments on this work should be taken to the list. Seisho Yasukawa Extended RSVP-TE for Multicast LSP Tunnels ---------------------------------------------------------------------- Seisho Yasukawa: The draft is about potential extensions for RSVP-TE for multicast LSPs. One of the things we propose in the draft is a grafting mechanism. A mechanism like this is needed e.g. for a VPLS service. It is appropriate that the multicast specifications should be discussed in the working group because the charter already includes work on the framework for multicast. Proposes that the WG should accept this draft as a WG draft. Saha asked if the draft required a multicast routing protocol, answer was that no multicast protocol is needed, but a function needed to determine the the multicast tree. Loa: This should be taken to the list. We are currently not prepared to take on new wg documents for multicast, we need a discussion to scope the multicast work within the mpls wg before we do that. That discussion should also be taken onto the list. H.Hummel: "Hierarchical LSP" "O(n**2) investigations". ---------------------------------------------------------------------- Heinrich: The motivation for this work is to eliminate the n**2 problem via partial mesh of elementary tunnels. We have done tests and simulations to determine precise values for scalability associated with the use of hierarchical LSPs. Hierarchal LSPs is in scope for the charter by implication because of the existence of the label stack. Discussion deferred to list due to time constraints. Loa: WG and document status, Questions ---------------------------------------------------------------------- 19 RFCs, latest is RFC 3270 on diff-serv. Multicast framework on the RFC-ed queue. 19 WG docs. 18 individual submissions. The issue here is that the individual submission are so numerous and diverge so much. This is a mature WG, and should be more focused. The wg documents: 5 under MIB doctor treatment. 6 documents under chair/AD (pre-IESG) review before going to IESG. 4 in WG last call. (FT completed just before meeting). 4 work in progress (incomplete). Meeting ended 11.30 AM. --------------010701010704020909040805-- From owner-mpls@UU.NET Thu Aug 8 09:11: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 JAA10392 for ; Thu, 8 Aug 2002 09:11:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbai05956 for ; Thu, 8 Aug 2002 13:12: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 QQnbai04679; Thu, 8 Aug 2002 13:11:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbai05093 for mpls-outgoing; Thu, 8 Aug 2002 13:11:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbai05088 for ; Thu, 8 Aug 2002 13:11:38 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 QQnbai06788 for ; Thu, 8 Aug 2002 13:11:30 GMT From: sven.van_den_bosch@alcatel.be Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbai04505 for ; Thu, 8 Aug 2002 13:11:29 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 QQnbai04488 for ; Thu, 8 Aug 2002 13:11:28 GMT Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g78D6U722633; Thu, 8 Aug 2002 15:06:30 +0200 Subject: Re: final notes from the mpls meeting in Yokohama To: Loa Andersson Cc: MPLS wg , George Swallow , Scott Bradner X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 8 Aug 2002 15:11:11 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 08/08/2002 15:11:15 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA10392 Hi Loa, all, One of my comments on the minutes was not updated. I have repeated it for reference: - My remark on the fast reroute presentation was actually a question about the impact of the use of backup LSPs without bandwidth reservation on the performance of constraint-based routing algorithm (based on unreserved bandwidth advertisements) I hope it can still be updated. Thanks, Sven. Loa Andersson @UU.NET on 08/08/2002 14:08:27 Sent by: owner-mpls@UU.NET To: MPLS wg cc: George Swallow , Scott Bradner Subject: final notes from the mpls meeting in Yokohama All, included are the final notes from the mpls meeting in Yokohama. "Final" - unless there are further comments ;) Again thanks to Eric G and Dave for taking notes! I've also complemented the agenda from meeting to include all slides that were used. Will be found at: http://62.119.0.68/~loa/mpls_agenda_for_yokohama.htm /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se IETF 54 MPLS WG Notes Thursday July 12. 9 - 11.30 AM Chair - Loa Andersson (George Swallow not in attendance). Note Takers - David Allan, Eric Gray Loa: Agenda bashing -------------- - process reminders/blue sheets - LDP MTU draft off the agenda - No further comments on the agenda Loa: LDP (RFC 3036) to draft standard (status) ---------------------------------------------------------------------- Loa talked about the need to collect implementation information on LDP for taking it to Draft Standard. It is still not clear how many other RFCs will be affected, encap and LDP draft, maybe also architecture. This is because of normative references. A survey form is developed and will be published on the list in a few weeks, together with instructions on how to respond. Asked to include an anonymity option. Scot Bradner will act as anonymizer. Results will be published as an I-D. One intention will be to simplify LDP, so unimplemented stuff will be removed when LDP is moved to draft standard. Scott Bradner AD: Current state of the issues in the mpls oam discussion and the ITU-T liaison. ---------------------------------------------------------------------- The background is that we have an I-D, by Hiroshi Ohta, requesting a reserved label to be used by ITU-T, for OAM. At the last meeting the discussion concerned changes to IETF protocols that would result. As a result a liaison was sent for clarification, asking if they were operatingunder the assumption that they would be requesting changes. The draft is called: "Use of a reserved label value defined in RFC 3032 for MPLS OAM functions" Liaison response: Hiroshi Ohta (SG13 Rapporteur, slides included) Hiroshi Ohta presented a report on ITU-T's response to IETF's liaison on MPLS OAM. He stated that they do not expect to impact IETF protocols and minimal impact on implementations. Y.1711 cannot work without the reserved label - therefore, they request that IANA assign a reserved label. Discussion ---------- Rahul Aggarwal: The statement of no impact on forwarding plane is inaccurate, on egress LSRs there will be an impact. Kireeti: If we allocate this label, will the ITU use this label 'efficiently', in other words, will there be other requests. Scott: The ITU is finding that IETF protocols are popular, so they want to use them. He gave an example of the process using SIP. The IETF decides that protocols developed by IETF need to be reviewed by IETF when extensions are being proposed. Kireeti: there are two concerns, one is the IETF process (which is good) band the other is how far does this go? Do they need to go through the RFC process. Scott: This may be dealt with in many ways, however we hope that the cooperative approach will work. Scott asked the sense of the room: We have an I-D seeking assignment, we've interacted to find out answers to questions we've asked. I think this is a good thing, both cooperatively and for the good of the protocol. MPLS is being used in a number of environments, and the usage assumptions are different depending on the carrier. We need to support the IP carrier, but that is not all of them. In that context we should be open to the use of our protocols in other environments. For MPLS to be seen as useful in trad telco environments it needs this stuff. Hummm (a few raised hands :)) showed a consensus for RFC publishing the draft and issuing the label. Scott Bradner: rsvp-te vs. cr-ldp, initiating a discussion ---------------------------------------------------------------------- In the implementation survey for GMPLS, there was lots of RSVP and little CR-LDP. Concern in ISEG on multiple standards track ways of doing something is confusing to the market place. Don't need to visit the history. Don't think we need to stop publishing CR-LDP, but should they be informational or standards track. Discussion: ---------- Loa: The intent of having this agenda item is to initiate the discussion, not arrive at a conclusion at this meeting. Bilel Jamoussi: Comment on the survey. Did not state the objective or indicate how it was going to be used. Not scientific by any means. More importantly GMPLS is a new thing, carriers are still debating the architectures. Think the discussion is premature. There are today several networks running CR-LDP in a packet environment. Bert: Purpose of survey was to seek an implementation report before approving GMPLS. This was an artifact of the survey not the intent. I don't think discussion is premature, a decision may be. Folks can still implement informational. Within one org you would normally try to go for one standard. Kireeti: I wear several hats. CCAMP chair, twice as many protocol extensions because of two protocols. Have to write two sets of drafts as an author. Have to read twice as many. As a vendor I do not care, and do not implement it. Impact on IETF is twice as much material. Luca Martini: as a service provider, we found RSVP predominantly deployed and implemented. Pushed by a particular vendor for an obscure reason. We should shift CR-LDP to informational. Ron Bonica: Like to second what Luca said. IETF produces too much technology to do a good job. Lets prune. Chris Liljenstolpe: Third what Luca said. Osama Aboul-Magd: From transport POV, the market is really slow so deployment is pretty much nonexistent. This is not an indicator. Joel Halpern: Helped work on CR-LDP, technically prefer it. That's irrelevant, its not about what is technically better, RSVP won the fight. Bilel: Agree on one application. Not necessarily so for optical transport. For packet TE, RSVP has one the fight. In optical it is premature. So Packet TE it is overwhelmingly RSVP, but GMPLS it is premature. Folks are building on the CR-LDP. There are other examples of multiple protocols. Bert: Past potential mistakes are not necessarily an indication of what we should do in the future. In this case one far outweighs the other. Chippy: We don't support it because we have no customer demand. Ludo Practico: We support both and get interest in both. Discussion to move to the mailing list. Loa: Confine it to the MPLS list, but we'll send mail to the other sub-ip list informing them about the discussion. Bert Wijnen Status and issues with the mpls mibs ---------------------------------------------------------------------- We have lots of MPLS MIBs. Although separately they looks OK, there was a lot of overlaps (TCs and the like, some conflicting). Shows authors not working together, and no cross review of how they play together. No discontinuity timers for counters, or how MIBs relate to each other. etc. etc. Several issues, including inconsistencies and duplicated uses. Also, there are uses defined that are not consistent with common usage elsewhere. Some MIBs have already become RFCs and others have been held up in queue for corrections. There is a draft that attempt to capture the relationships between various MIBs, but this does not do quite enough. Also, there are some MIBs that are fairly 'all- inclusive' and it is not clear that this is always a good thing. Also, there are differences in the 'tolerance' levels for various MIB compilers and this results in MIBs that do not compile using some MIB compilers. We would also like to see better communications between various MIB development efforts. We would also like to see who is implementing which MIBs. Finally, people should get help for MIBs at mibs@ops.ietf.org or by asking the SNMP/MIB advisor for the working group. If there is no SNMP/MIB advisor, get one. Summary: - Main concerns/worries: o How do Label Distribution Protocols, SNMP, Manual config, GSMP interact and make sure they do not step on each others toes?? o How are assignments under mplsMIB controlled? o Who is implementing all these Mibs? o How is the impact on follow up (G)MPLS MIBs? - Status/Action plan o Authors have answered a lot of comments and supposedly know what needs to be fixed. o Authors revising MIBs to address comments. Sofar I have received a new TC MIB, need revisions of all otehr MIBs o Then will need to re-review (MIB-Doctor) o I want the WG to re-review as well and make sure that you all agree, before it gets approved Marcus: We have actually implemented some MIBs only partially. Bert: The correct way to work through this is to talk about these issues on the public mailing list so that everyone can benefit from understanding the issues and answers. Kireeti: Asked if Marcus had tried the TE-WG MIB. Marcus Brunner: I was actually referring to the LSR MIB. Vach Kompella: I've had issues with the LDP MIB and we've also implemented a proprietary MIB that supports a subset of the MIB. Bert: The LSR MIB is in IESG review at this time. We had reports that people are implementing the LDP MIB. Loa: My impression is that the MIBs have become complicated and uncoordinated. My feeling that we still need to think about what to do next. It is at least clear that enough changes have occurred since the last set of last calls that once we see the updated MIBs we will need another round of last calls. Andy Malis Status of LDP restart and LDP fault tolerance drafts Fault Tolerance for LDP and CR-LDP Graceful Restart Mechanism for LDP ---------------------------------------------------------------------- Andy: The latest status is that the LDP FT draft was successfully merged with the Smith (check-pointing) draft. The LDP Restart draft actually has a different applicability with very little overlap. The last call has been completed, George Swallow has proposed some changes, some minor editing has to be done and then the draft should go to the IESG. Sven van den Bosch Further considerations for Forwarding Adjacency LSPs ---------------------------------------------------------------------- Sven van den Bosch : This is version one of the document, related to LSP hierarchy 07 WG draft, since there might be some interdepencies betseen the resource classes and the use of backup LSPs without any assigned bandwidth, The issues addressed is complex resources classes and a new sub-class of TLVs proposed. Alternatively it could be possible to approach the IS-IS and OSPF wg's and suggest that they define extensions to the protocols. Amir Hermelin: Is it the the goal of this draft is to be merged into other work. Sven: I feel it is useful to keep the draft as an overview of outstanding issues but that any eventual resolution of any of the issues could be merged with other work. Kireeti: Not sure that all cases of complex resource classes can be represented. Sven: I'm aware that there is at least one case that his proposal does not cover, but also feels that there is a real need to solve a subset of the problem space that his proposal does address. Although the solution does not work in this particular case, an operator will always know (by virtue of its resource class specification policy) whether or not it is safe to use the proposed solution. Loa: Take this back to the list and make a decision once all the implications are clear. B Jensen:(University of Wisconsin) General Summary of Interoperability Testing Results and Experiences ---------------------------------------------------------------------- There are interoperability efforts from several organizatios e.g. UNH, AIL, MPLS Forum etc. There has been private tests in April, NI in May, and then Supercom. White paper will available from MPLS forum. The Draft is key findings from April, test configuration are shown in the slides. IP transport, plus L2 and L3 VPN apps (2547/Martini Ethernet), POS and GigE plus some ATM. Has been tested. Issues found: OSPF TE is not universally supported even though required for TE LSPs Vendor implementations only support a single distribution mode (DU/DoD) Not all RSVP-TE implementations support both FF and SE reservation styles Inconsistent use of IP addresses in ERO RESV_CONFIRM is not universally supported Explicit NULL label is not universally supported Discussion: Amir said that he was surprised that the presentation was being given before there was a white paper presented and said that the issue with explicit NULL labels is essentially because of a misunderstanding of the standard. Satoru Matsoshima asked about DU implementations that do not respond to requests for Labels. Rahul said that their implementation simply supports all of the possible ERO IP address usages. Amir commented on the ERO issue, saying this is critical. Loa said that the discussion should be continued on the list, thanked him for the report. J-P Vasseur MPLS Traffic Engineering Fast reroute: backup tunnel path computation for bandwidth protection ---------------------------------------------------------------------- P Vasseur: The draft addresses the charter item dealing with recovery mechanisms and focus on bandwidth protection issues. The draft proposes two basic approaches - centralized and distributed. It was pointed out that a Naive approach - using CSPF to setup backup paths - has two key problems: it cannot protect the bandwidth and it is possible that no solution can be found even though it can be shown that one must exist (as a result of timing). Examples of real life scenarios were given, in which bandwidth protection is needed. Bandwidth protection is needed for some traffic in some networks and input on the draft is solicited. Sven said that he is interested in this work. Loa suggested that comments on this work should be taken to the list. Seisho Yasukawa Extended RSVP-TE for Multicast LSP Tunnels ---------------------------------------------------------------------- Seisho Yasukawa: The draft is about potential extensions for RSVP-TE for multicast LSPs. One of the things we propose in the draft is a grafting mechanism. A mechanism like this is needed e.g. for a VPLS service. It is appropriate that the multicast specifications should be discussed in the working group because the charter already includes work on the framework for multicast. Proposes that the WG should accept this draft as a WG draft. Saha asked if the draft required a multicast routing protocol, answer was that no multicast protocol is needed, but a function needed to determine the the multicast tree. Loa: This should be taken to the list. We are currently not prepared to take on new wg documents for multicast, we need a discussion to scope the multicast work within the mpls wg before we do that. That discussion should also be taken onto the list. H.Hummel: "Hierarchical LSP" "O(n**2) investigations". ---------------------------------------------------------------------- Heinrich: The motivation for this work is to eliminate the n**2 problem via partial mesh of elementary tunnels. We have done tests and simulations to determine precise values for scalability associated with the use of hierarchical LSPs. Hierarchal LSPs is in scope for the charter by implication because of the existence of the label stack. Discussion deferred to list due to time constraints. Loa: WG and document status, Questions ---------------------------------------------------------------------- 19 RFCs, latest is RFC 3270 on diff-serv. Multicast framework on the RFC-ed queue. 19 WG docs. 18 individual submissions. The issue here is that the individual submission are so numerous and diverge so much. This is a mature WG, and should be more focused. The wg documents: 5 under MIB doctor treatment. 6 documents under chair/AD (pre-IESG) review before going to IESG. 4 in WG last call. (FT completed just before meeting). 4 work in progress (incomplete). Meeting ended 11.30 AM. From owner-mpls@UU.NET Thu Aug 8 09:37: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 JAA11143 for ; Thu, 8 Aug 2002 09:37:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbak25668 for ; Thu, 8 Aug 2002 13:38: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 QQnbak24276; Thu, 8 Aug 2002 13:38:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbak06937 for mpls-outgoing; Thu, 8 Aug 2002 13:37: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 QQnbak06931 for ; Thu, 8 Aug 2002 13:37: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 QQnbak11802 for ; Thu, 8 Aug 2002 13:36: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 QQnbak23405 for ; Thu, 8 Aug 2002 13:36:58 GMT Received: from zcars04e.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnbak23399 for ; Thu, 8 Aug 2002 13:36:58 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g78DaVJ03331; Thu, 8 Aug 2002 09:36:32 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 09:36:32 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04E16844@zcard031.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" Cc: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com, pwe3@ietf.org Subject: RE: MIB Question Date: Thu, 8 Aug 2002 09:36:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23EE0.9A3F390A" 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_01C23EE0.9A3F390A Content-Type: text/plain; charset="iso-8859-1" Hi Tom: > The MPLS-LSR MIB does contain counters that an implementation > may count MTU errors: mplsInSegmentErrors, mplsInSegmentDiscards, > mplsOutSegmentErrors, and mplsOutSegmentDiscards. However, I do > agree that MTU discards are not explicitly counted. Yep, and IMHO MTU is a different thing than either true errors or congestion. Lumping it into another category may not be useful as path MTU discovery is really not an error. > In the non-PW and > non-VPN cases, I have not seen any requirements to-date to add such > counters from providers, thus we have not added any. Agreed and not surprising, although in the VPN case I think you do have a problem or anytime stack depth > 1. For TE, RSVP advertises the MTU to the ingress, so you would expect infrequent issues if ever (perhaps FRR when running MTU on the edge). For LDP there is the MTU draft coming up, so the error may fall into the category of S/W bug if happening in a fully converged network although I'd presume configuration errors can creep in as well. > One question, you mention this within the context of > PW/VPN. In the case of PWE3, wouldn't it be more appropriate to include MTU > discards in the generic PW VC counters into the PW-MIB? What do non-PEs do? PEs in theory can fragment. > For VPN, we could certainly add them into the > PPVPN-MPLS-VPN MIB explicitly as well. IMHO this is a transport problem, and may happen with the PEs never knowing about it. So I don't think a VPN MIB is the right spot to fix this. > The only hesitation I > have for adding these to the PPVPN MIB is that to-date have not had such a > requirement from any providers, so I would like to get some more input from that > group first. Fine cheers Dave ------_=_NextPart_001_01C23EE0.9A3F390A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MIB Question

Hi Tom:

<snipped>
>          The = MPLS-LSR MIB does contain counters that an implementation
> may count MTU errors:  = mplsInSegmentErrors,  mplsInSegmentDiscards,
>   mplsOutSegmentErrors, and = mplsOutSegmentDiscards.  However, I do
> agree that MTU discards are not explicitly = counted.  

Yep, and IMHO MTU is a different thing than either = true errors or congestion. Lumping it into another category may not be = useful as path MTU discovery is really not an error.

> In the non-PW and
> non-VPN cases, I have not seen any requirements = to-date to add such
> counters from providers, thus we have not added = any.

Agreed and not surprising, although in the VPN case I = think you do have a problem or anytime stack depth > 1. For TE, RSVP = advertises the MTU to the ingress, so you would expect infrequent = issues if ever (perhaps FRR when running MTU on the edge). For LDP = there is the MTU draft coming up, so the error may fall into the = category of S/W bug if happening in a fully converged network although = I'd presume configuration errors can creep in as well.

> One question, you mention this within the = context of
> PW/VPN. In the case of PWE3, wouldn't it = be  more appropriate to include MTU
> discards in the generic PW VC counters into the = PW-MIB? 

What do non-PEs do? PEs in theory can = fragment.

> For VPN, we could certainly add them into = the
> PPVPN-MPLS-VPN MIB explicitly as well.

IMHO this is a transport problem, and may happen with = the PEs never knowing about it. So I don't think a VPN MIB is the right = spot to fix this.

> The only hesitation I
> have for adding these to the PPVPN MIB is that = to-date have not had such a
> requirement from any providers, so I would like = to get some more input from that
> group first.

Fine


cheers
Dave

------_=_NextPart_001_01C23EE0.9A3F390A-- From owner-mpls@UU.NET Thu Aug 8 10:17: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 KAA13090 for ; Thu, 8 Aug 2002 10:17:06 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnban14236 for ; Thu, 8 Aug 2002 14:18: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 QQnban12235; Thu, 8 Aug 2002 14:17:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnban02703 for mpls-outgoing; Thu, 8 Aug 2002 14:16: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 QQnban02696 for ; Thu, 8 Aug 2002 14:16: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 QQnban26442 for ; Thu, 8 Aug 2002 14: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 QQnban24010 for ; Thu, 8 Aug 2002 14:16:10 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnban24005 for ; Thu, 8 Aug 2002 14:16:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA16964 for ; Thu, 8 Aug 2002 10:16:09 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02209 for mpls@uu.net; Thu, 8 Aug 2002 10:16:08 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbal07898 for ; Thu, 8 Aug 2002 13:49:57 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 QQnbal07351 for ; Thu, 8 Aug 2002 13:49:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbal05683 for ; Thu, 8 Aug 2002 13:49:17 GMT Received: from prue.eim.surrey.ac.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQnbal05679 for ; Thu, 8 Aug 2002 13:49:16 GMT Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17cnef-0001d3-00; Thu, 08 Aug 2002 14:48:45 +0100 Date: Thu, 8 Aug 2002 14:48:36 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: David Allan cc: "Thomas D. Nadeau" , , , Subject: Re: [PWE3] RE: MIB Question In-Reply-To: <9FBD322B7824D511B36900508BF93C9C04E16844@zcard031.ca.nortel.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-103.4 required=7.0 tests=IN_REP_TO,USER_IN_WHITELIST version=2.31 X-Scanner: exiscan *17cnef-0001d3-00*sGBW7qqgk5I* (SECM, UniS) Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 8 Aug 2002, David Allan wrote: > > > The MPLS-LSR MIB does contain counters that an implementation > > may count MTU errors: mplsInSegmentErrors, mplsInSegmentDiscards, > > mplsOutSegmentErrors, and mplsOutSegmentDiscards. However, I do > > agree that MTU discards are not explicitly counted. > > Yep, and IMHO MTU is a different thing than either true errors or > congestion. Lumping it into another category may not be useful as path MTU > discovery is really not an error. no, Path MTU discovery is a broken hack depending on the reporting of an error. L. From owner-mpls@UU.NET Thu Aug 8 10:17:15 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13107 for ; Thu, 8 Aug 2002 10:17:15 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnban26607 for ; Thu, 8 Aug 2002 14:18: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 QQnban23905; Thu, 8 Aug 2002 14:17:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnban02706 for mpls-outgoing; Thu, 8 Aug 2002 14:16:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnban02697 for ; Thu, 8 Aug 2002 14:16:42 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 QQnbam23561 for ; Thu, 8 Aug 2002 14:14: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 QQnbam22407 for ; Thu, 8 Aug 2002 14:14:58 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe74.law9.hotmail.com [64.4.8.209]) id QQnbam22403 for ; Thu, 8 Aug 2002 14:14:57 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Aug 2002 07:14:57 -0700 X-Originating-IP: [212.199.233.65] From: "Doug Degan" To: Subject: fast-reroute scenario Date: Thu, 8 Aug 2002 17:14:15 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C23EFF.05C515A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 08 Aug 2002 14:14:57.0116 (UTC) FILETIME=[F95279C0:01C23EE5] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C23EFF.05C515A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi.=20 Id like to get clarification about the regular FRR scenario: [I]---[PLR]----[T1]---...-[Tn]--[MP]--------[E] \ / \------------------------/ BYPASS/DETOUR Assume one of the links inside the segment PLR-T1...-Tn-MP fails. What = are the messages that should be sent upstream and downstream? If = PATH-TEAR is sent downstream, how does one distinguish between this = PATH-TEAR and LSP shutdown originated by the ingress (user)? In other = case, assume Ti sends RESV-ERR downstream, but how does MP know to stop = the proparation of this message? Also, in this case MP should know = whether RESV-ERR was originated by T1-...-Tn or from outside the = "protected section".=20 =20 The same argument applies for the upstream with RESV-TEAR/PATH-ERR. ------=_NextPart_000_0023_01C23EFF.05C515A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi.
Id like to get clarification about the = regular FRR=20 scenario:
 

[I]---[PLR]----[T1]---...-[Tn]--[MP]--------[E]
 &nb= sp;       =20 \            =             &= nbsp; =20 /
          =20 \------------------------/
       &= nbsp;     =20 BYPASS/DETOUR

Assume one of the links inside the = segment=20 PLR-T1...-Tn-MP fails. What are the messages that should be sent = upstream and=20 downstream? If PATH-TEAR is sent downstream, how does one distinguish = between=20 this PATH-TEAR and LSP shutdown originated by the ingress (user)?  = In other=20 case, assume Ti sends RESV-ERR downstream, but how does MP know to stop = the=20 proparation of this message? Also, in this case MP should know whether = RESV-ERR=20 was originated by T1-...-Tn or from outside the "protected section".=20
 
The same argument applies for the = upstream with=20 RESV-TEAR/PATH-ERR.
 
 
------=_NextPart_000_0023_01C23EFF.05C515A0-- From owner-mpls@UU.NET Fri Aug 9 02:54: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 CAA18274 for ; Fri, 9 Aug 2002 02:54:43 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbdb02843 for ; Fri, 9 Aug 2002 06:55: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 QQnbdb01640; Fri, 9 Aug 2002 06:55:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbdb19672 for mpls-outgoing; Fri, 9 Aug 2002 06: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 QQnbdb19667 for ; Fri, 9 Aug 2002 06:54: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 QQnbdb00144 for ; Fri, 9 Aug 2002 06:53: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 QQnbdb19273 for ; Fri, 9 Aug 2002 06:53:07 GMT Received: from mail.site.uottawa.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailn.site.uottawa.ca [137.122.89.142]) id QQnbdb19259 for ; Fri, 9 Aug 2002 06:53:06 GMT Received: from site.uottawa.ca (bwwil28.site.uottawa.ca [137.122.91.149]) by mail.site.uottawa.ca (8.9.3/8.9.3) with ESMTP id CAA36595; Fri, 9 Aug 2002 02:52:50 -0400 (EDT) Message-ID: <3D5366CA.2691A296@site.uottawa.ca> Date: Fri, 09 Aug 2002 02:52:58 -0400 From: bin X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: RSVP-TE PathErr: Bad Explicit Route Object Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Question: What the exact ERO in PathErr is? In RFC3209, "If there is no first subobject, the message is also in error and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error." "A node which encounters an unrecognized subobject during its normal ERO processing sends a PathErr with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. The EXPLICIT_ROUTE object is included, truncated (on the left) to the offending subobject. The presence of an unrecognized subobject which is not encountered in a node's ERO processing SHOULD be ignored. It is passed forward along with the rest of the remaining ERO stack." I don't understand "truncated (on the left) to the offending subobject". Which subobject is the offending subject? What's the meaning of on the left? In my understanding, explicit route object in Path State is not the original ERO sent by Sender, and the nodes along the route to this node are all removed from the ERO. The node should return only the unrecognized first subobject to the sender. Right? Regards, Bin From owner-mpls@UU.NET Fri Aug 9 10:11: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 KAA27799 for ; Fri, 9 Aug 2002 10:11:18 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbee08352 for ; Fri, 9 Aug 2002 14:12: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 QQnbee06709; Fri, 9 Aug 2002 14:11:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbee24987 for mpls-outgoing; Fri, 9 Aug 2002 14:11: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 QQnbee24910 for ; Fri, 9 Aug 2002 14:11: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 QQnbee04938 for ; Fri, 9 Aug 2002 14:10: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 QQnbee23507 for ; Fri, 9 Aug 2002 14:10:45 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 QQnbee23503 for ; Fri, 9 Aug 2002 14:10:44 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12124 for ; Fri, 9 Aug 2002 10:10:43 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27012 for ; Fri, 9 Aug 2002 10:10:43 -0400 (EDT) Message-ID: <3D53CD58.2020908@marconi.com> Date: Fri, 09 Aug 2002 10:10:32 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP-TE PathErr: Bad Explicit Route Object References: <3D5366CA.2691A296@site.uottawa.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit bin wrote: > > Question: What the exact ERO in PathErr is? > > In RFC3209, > "If there is no first subobject, the message is also in error and > the system SHOULD return a "Bad EXPLICIT_ROUTE object" error." > > "A node which encounters an unrecognized subobject during its normal > ERO processing sends a PathErr with the error code "Routing Error" and > error value of "Bad Explicit Route Object" toward the sender. The > EXPLICIT_ROUTE object is included, truncated (on the left) to the > offending subobject. The presence of an unrecognized subobject which > is not encountered in a node's ERO processing SHOULD be ignored. It > is passed forward along with the rest of the remaining ERO stack." > > I don't understand "truncated (on the left) to the offending subobject". > Which subobject is the offending subject? What's the meaning of on the > left? The offending subobject is the one that is unrecognized. "on the left" means everything prior to that object. > In my understanding, explicit route object in Path State is not the > original ERO sent by Sender, and the nodes along the route to this node > are all removed from the ERO. The node should return only the > unrecognized first subobject to the sender. Right? It should return the entire ERO, starting from the unrecognized object. -- David From owner-mpls@UU.NET Fri Aug 9 11:05: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 LAA29195 for ; Fri, 9 Aug 2002 11:05:13 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbei16548 for ; Fri, 9 Aug 2002 15:06: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 QQnbei13511; Fri, 9 Aug 2002 15:04:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbei12071 for mpls-outgoing; Fri, 9 Aug 2002 15:04: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 QQnbei12064 for ; Fri, 9 Aug 2002 15:04:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnbei15217 for ; Fri, 9 Aug 2002 15:04: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 QQnbei13167 for ; Fri, 9 Aug 2002 15:04:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbei13162 for ; Fri, 9 Aug 2002 15:04:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA07717 for ; Fri, 9 Aug 2002 11:04:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00089 for mpls@uu.net; Fri, 9 Aug 2002 11:04:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbei12028 for ; Fri, 9 Aug 2002 15:03:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnbei19904 for ; Fri, 9 Aug 2002 15:02: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 QQnbei24581 for ; Fri, 9 Aug 2002 15:02:43 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 QQnbei24576 for ; Fri, 9 Aug 2002 15:02:42 GMT Received: (qmail 4126 invoked by uid 104); 9 Aug 2002 15:02:41 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 1.033361 secs); 09 Aug 2002 15:02:41 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Aug 2002 15:02: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 g79F2dw00126 for ; Fri, 9 Aug 2002 08:02:39 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 08:02:48 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037D8@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'mpls@UU.net'" Subject: Comments on Fast Reroute draft Date: Fri, 9 Aug 2002 08:02:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Please find below some comments on the fast-reroute draft: 1) Why do we need to specify the BW in the FAST_REROUTE object, while it is already signaled in the RSVP? 2) Is the meaning of the following flags combinations in session_attribute as indicated: (Local protection desired =0) & (Node protection desired =0)-> No protection (Local protection desired =0) & (Node protection desired =1)-> Node protection (Local protection desired =1) & (Node protection desired =0)-> Link protection (Local protection desired =1) & (Node protection desired =1)-> Node protection (Local protection desired =1) & (no Session_Attribute object)-> Local policy Please clarify the correct meaning in the text. 3) Section 3.5 defines the BW protection ration as: "The BW of all the protected LSPs having selected T as their bypass tunnel / BW of the bypass tunnel" but it mentions that: "the minimum value for the protected ratio is 1" As mentioned in the backup-computation draft, it is possible to backup an LSP without reserving BW for it in the bypass tunnel. So Min =1 seems not to be correct. 4) Section 4.1: (identification of backup paths) The Sender_template specific identification, does not have any specific text to show how it is used by an LSR to identify the backup path. Is it done by comparing the Extended tunnel ID with the sender IPV4 address? Please provide accurate text. 5) Section 5.1 says: " A one-to-one backup for a protected LSP may also be created based upon a PLR's local policy if either the "local protection desired" flag is set in the SESSION_ATTRIBUTE object or a FAST_REROUTE object is included or both. " Do you mean a FAST_REROUTE object with Node protection desired =1. If so please clarify. 6) Section 5.3 repeatedly says selecting final LSP from a number of path messages. I think mentioning of LSP is not accurate, rather "selecting final PATH message" is the more accurate term. 7) Section 5.3 : Since bullet 4 eliminates all LSPs with Detour object, how is bullet 4 possible? Since as stated in section 7, each PLR has option to apply its own constraints, then each PLR may reach to a different backup-path ERO for the same flow. Assuming that the EROs have a single link (the downstream link of an MP LSP) in common, isn't it wrong for an MP LSR to merge those Path messages? 8) Section 6.1: Global-to-node label is not a defined IETF term. Suggest changing it to Per-platform. 9) Section 7 states that : "When setting up one-to-one protection using the path-specific approach, a detour MUST not traverse the upstream links of the protected LSP in the same direction. This prevents the possibility of early merging of the detour into the protected LSP." I think instead the rules of merging should be defined so that this can't happen. 10) Section 7.1 talks about path-protection. Where is this defined in context of fast reroute? 11) Section 8.1 talks about sending Path Error to notify the ingress LSR of the fast protection event. For how long and with what intervals is this Path_ERROR transmitted? 12) Section 9.2 permits having both types of protection (1-to-1 and facility) for the same PLR. In that case how can it inform the ingress LSR that both protections are available? Yours, Shahram From owner-mpls@UU.NET Fri Aug 9 11:12: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 LAA29417 for ; Fri, 9 Aug 2002 11:12:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbei02692 for ; Fri, 9 Aug 2002 15:13: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 QQnbei00524; Fri, 9 Aug 2002 15:12:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbei23327 for mpls-outgoing; Fri, 9 Aug 2002 15:11: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 QQnbei23320 for ; Fri, 9 Aug 2002 15:11:32 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 QQnbei21511 for ; Fri, 9 Aug 2002 15:11: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 QQnbei24256 for ; Fri, 9 Aug 2002 15:11:23 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 QQnbei24251 for ; Fri, 9 Aug 2002 15:11:22 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08183 for ; Fri, 9 Aug 2002 11:11:22 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA01789 for mpls@uu.net; Fri, 9 Aug 2002 11:11:22 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnbei22833 for ; Fri, 9 Aug 2002 15:10: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 QQnbei08786 for ; Fri, 9 Aug 2002 15:10: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 QQnbei23061 for ; Fri, 9 Aug 2002 15:10:09 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 QQnbei22994 for ; Fri, 9 Aug 2002 15:10:07 GMT Received: (qmail 6884 invoked by uid 104); 9 Aug 2002 15:09:55 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.456881 secs); 09 Aug 2002 15:09:55 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 9 Aug 2002 15:09:54 -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 g79F9sw10815 for ; Fri, 9 Aug 2002 08:09:54 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 08:10:03 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037D9@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: Shahram Davari , "'mpls@UU.net'" Subject: RE: Comments on Fast Reroute draft Date: Fri, 9 Aug 2002 08:09:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk A typo correction below: > 7) Section 5.3 : > > Since bullet 4 eliminates all LSPs with Detour object, how is > bullet 4 possible? > I meant how is bullet 6 possible? -Shahram From owner-mpls@UU.NET Fri Aug 9 11:51: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 LAA00911 for ; Fri, 9 Aug 2002 11:51:02 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbel28563 for ; Fri, 9 Aug 2002 15:52: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 QQnbel26135; Fri, 9 Aug 2002 15:51:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbel26984 for mpls-outgoing; Fri, 9 Aug 2002 15:50: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 QQnbel26979 for ; Fri, 9 Aug 2002 15:50: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 QQnbel20970 for ; Fri, 9 Aug 2002 15:50: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 QQnbel25664 for ; Fri, 9 Aug 2002 15:50:20 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnbel25660 for ; Fri, 9 Aug 2002 15:50:19 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 LAA20153 for ; Fri, 9 Aug 2002 11:50:17 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03576 for ; Fri, 9 Aug 2002 11:50:18 -0400 (EDT) Message-ID: <3D53E4B0.6010200@marconi.com> Date: Fri, 09 Aug 2002 11:50:08 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: RSVP-TE PathErr: Bad Explicit Route Object References: <3D5366CA.2691A296@site.uottawa.ca> <3D53CD58.2020908@marconi.com> <001c01c23fba$1d10c360$955b7a89@bwwil28> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bin Zhou wrote: > > How does the Sender deal with the unrecognized subobject when it receive > PathErr of "Bad Explicit Route"? Is it application specific? If it is, I can > define the function for the unrecognized subobject in Sender. The unrecognized object will be the first one. We presume that the sender will understand what this object is, since the sender generated this object in the first place. The sender has only two choices here. It must either tear down the LSP and give up, ot it must re-signal the LSP with a different ERO object - one that does not contain the offending object. > If the Sender request the route via R1 (only one subobject), the node on the > left of R1 and R2 reply with a PathErr with a new route via R2. The error > code is 24 (routing problem), the value is 1 (Bad Explicit Route), and new > ERO (via ERO, only one subobject) is included. What's the behavior of > Sender? If the sender sends out a one-subobject ERO, then that subobject must identify the sender's immediate downstream neighbor. That neighbor will recognize himself as the last node in the ERO and will proces the Path message as if there was no ERO. I'm not sure I understand the scenario you're describing. -- David > > Regards, > Bin > > ----- Original Message ----- > From: "David Charlap" > To: > Sent: Friday, August 09, 2002 10:10 AM > Subject: Re: RSVP-TE PathErr: Bad Explicit Route Object > > > >>bin wrote: >> >>>Question: What the exact ERO in PathErr is? >>> >>>In RFC3209, >>> "If there is no first subobject, the message is also in error and >>> the system SHOULD return a "Bad EXPLICIT_ROUTE object" error." >>> >>> "A node which encounters an unrecognized subobject during its normal >>> ERO processing sends a PathErr with the error code "Routing Error" >> > and > >>> error value of "Bad Explicit Route Object" toward the sender. The >>> EXPLICIT_ROUTE object is included, truncated (on the left) to the >>> offending subobject. The presence of an unrecognized subobject which >>> is not encountered in a node's ERO processing SHOULD be ignored. It >>> is passed forward along with the rest of the remaining ERO stack." >>> >>>I don't understand "truncated (on the left) to the offending subobject". >>>Which subobject is the offending subject? What's the meaning of on the >>>left? >> >>The offending subobject is the one that is unrecognized. >> >>"on the left" means everything prior to that object. >> >> >>>In my understanding, explicit route object in Path State is not the >>>original ERO sent by Sender, and the nodes along the route to this node >>>are all removed from the ERO. The node should return only the >>>unrecognized first subobject to the sender. Right? >> >>It should return the entire ERO, starting from the unrecognized object. >> >>-- David >> >> > From owner-mpls@UU.NET Fri Aug 9 11:52:43 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 LAA00976 for ; Fri, 9 Aug 2002 11:52:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbel04257 for ; Fri, 9 Aug 2002 15:53:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnbel01987; Fri, 9 Aug 2002 15:52:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbel27054 for mpls-outgoing; Fri, 9 Aug 2002 15:52: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 QQnbel27019 for ; Fri, 9 Aug 2002 15:52: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 QQnbel25450 for ; Fri, 9 Aug 2002 15:51: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 QQnbel18902 for ; Fri, 9 Aug 2002 15:51:43 GMT Received: from pimout3-int.prodigy.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout3-ext.prodigy.net [207.115.63.102]) id QQnbel18889 for ; Fri, 9 Aug 2002 15:51:42 GMT Received: from cs.columbia.edu (adsl-66-127-241-207.dsl.sntc01.pacbell.net [66.127.241.207]) by pimout3-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g79Fpda56306; Fri, 9 Aug 2002 11:51:39 -0400 Message-ID: <3D53E50B.5030100@cs.columbia.edu> Date: Fri, 09 Aug 2002 08:51:39 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Shahram Davari CC: "'mpls@UU.net'" Subject: Re: Comments on Fast Reroute draft References: <4B6D09F3B826D411A67300D0B706EFDEB037D9@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > A typo correction below: > > > >>7) Section 5.3 : >> >>Since bullet 4 eliminates all LSPs with Detour object, how is >>bullet 4 possible? >> >> > I meant how is bullet 6 possible? > > -Shahram > > Section 5.3, bullet 4 has a typo. Thanks. The condition is where a node receives multiple detours for a LSP, but the LSP itself does not pass through the node. The merging rule here is such that the node needs to select one of the detours. The selection algorithm is a local one. - Ping From owner-mpls@UU.NET Fri Aug 9 12:58: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 MAA03252 for ; Fri, 9 Aug 2002 12:58:32 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbep09903 for ; Fri, 9 Aug 2002 16:59: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 QQnbep08357; Fri, 9 Aug 2002 16:59:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbep25155 for mpls-outgoing; Fri, 9 Aug 2002 16:58: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 QQnbep25141 for ; Fri, 9 Aug 2002 16:58: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 QQnbep21407 for ; Fri, 9 Aug 2002 16:56: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 QQnbep20053 for ; Fri, 9 Aug 2002 16:56:16 GMT Received: from pimout2-int.prodigy.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout2-ext.prodigy.net [207.115.63.101]) id QQnbep20042 for ; Fri, 9 Aug 2002 16:56:16 GMT Received: from cs.columbia.edu (adsl-66-127-241-207.dsl.sntc01.pacbell.net [66.127.241.207]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g79Gu64218350; Fri, 9 Aug 2002 12:56:07 -0400 Message-ID: <3D53F426.6000107@cs.columbia.edu> Date: Fri, 09 Aug 2002 09:56:06 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Shahram Davari CC: "'mpls@UU.net'" Subject: Re: Comments on Fast Reroute draft References: <4B6D09F3B826D411A67300D0B706EFDEB037D8@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > Hi, > > Please find below some comments on the fast-reroute draft: > > 1) Why do we need to specify the BW in the FAST_REROUTE object, while > it is already signaled in the RSVP? > The resources that are needed for fast reroute may not be the same as the regular LSP. For example, all backup traffic could have zero bandwidth requirement, but EXP bit on. > 2) Is the meaning of the following flags combinations in session_attribute as indicated: > > (Local protection desired =0) & (Node protection desired =0)-> No protection > (Local protection desired =0) & (Node protection desired =1)-> Node protection > (Local protection desired =1) & (Node protection desired =0)-> Link protection > (Local protection desired =1) & (Node protection desired =1)-> Node protection > (Local protection desired =1) & (no Session_Attribute object)-> Local policy > > Please clarify the correct meaning in the text. > What's been described in SAO is a user's desire. The routers may not be able to support it. For example, when a user asks for local-protection-desired and node-protection-desried, if a backup LSP cannot be established to skip the node, well, tough! ;-) Depending on the implementation, link protection may be used only instead. > 4) Section 4.1: (identification of backup paths) > The Sender_template specific identification, does not have any specific text to > show how it is used by an LSR to identify the backup path. Is it done by comparing > the Extended tunnel ID with the sender IPV4 address? > > Please provide accurate text. > Yes. OK. > 5) Section 5.1 says: > > " A one-to-one > backup for a protected LSP may also be created based upon a PLR's > local policy if either the "local protection desired" flag is set in > the SESSION_ATTRIBUTE object or a FAST_REROUTE object is included or > both. > " > Do you mean a FAST_REROUTE object with Node protection desired =1. If so > please clarify. > No. One-to-one can do link protection as well. I will add more text on this. Thanks! > 6) Section 5.3 repeatedly says selecting final LSP from a number of path messages. > I think mentioning of LSP is not accurate, rather "selecting final PATH message" is the more > accurate term. > Yep. > > 9) Section 7 states that : > > "When setting up one-to-one protection using the path-specific > approach, a detour MUST not traverse the upstream links of > the protected LSP in the same direction. This prevents the > possibility of early merging of the detour into the protected > LSP." > > I think instead the rules of merging should be defined so that this can't happen. > OK. > 10) Section 7.1 talks about path-protection. Where is this defined in context of fast reroute? > It's in the context of co-authors were thinking and talking about different things during our merging. At the end, we just forgot about it. ;-) Will fix it asap. > 11) Section 8.1 talks about sending Path Error to notify the ingress LSR > of the fast protection event. For how long and with what intervals is this > Path_ERROR transmitted? > Path_Error messages are reference messages to the ingress. In other words, they are not that important. So a router can take its time to send the error messages. BTW, when a link/node goes down, it is possible that a router shoots out multiple error messages. One is to inform the ingress that the link/node is found to be dead. After the local repair, the node will tell the ingress "the LSP has been locally repaired". > 12) Section 9.2 permits having both types of protection (1-to-1 and facility) for the same PLR. > In that case how can it inform the ingress LSR that both > protections are available? > RRO tells the ingress that the traffic has been protected. Is it enough? If not, there is a MIB draft on fast-reroute. ;-) Thanks! - Ping From owner-mpls@UU.NET Fri Aug 9 13:33: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 NAA04464 for ; Fri, 9 Aug 2002 13:33:01 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbes08297 for ; Fri, 9 Aug 2002 17:34: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 QQnbes05534; Fri, 9 Aug 2002 17:33:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbes20925 for mpls-outgoing; Fri, 9 Aug 2002 17:32:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnbes20920 for ; Fri, 9 Aug 2002 17:32: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 QQnbes08326 for ; Fri, 9 Aug 2002 17:32: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 QQnbes27585 for ; Fri, 9 Aug 2002 17:32:25 GMT Received: from nsmail1.netscout.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.159.61.31]) id QQnbes27576 for ; Fri, 9 Aug 2002 17:32:25 GMT Subject: How Egress ATM-LSR/FR-LSR distinguishes IPv4 and IPv6 packets? To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Narendra Byrapuram" Date: Fri, 9 Aug 2002 13:21:18 -0400 X-MIMETrack: Serialize by Router on NSMail1/NetScout(Release 5.0.8 |June 18, 2001) at 08/09/2002 01:21:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello, How Egress ATM-LSR/FR-LSR distinguishes IPv4 and IPv6 packets? In the case of Generic Label, RFC 3032 "MPLS Label Stack Encoding" specifies IPv4 Explicit NULL (0) and IPv6 Explicit NULL (2). RFC3034 (MPLS on FR) and RFC 3035 (MPLS using ATM VC Switching) doesn't talk about the similarly to identify Network Layer. When Egress ATM-LSR receives an MPLS packet, how it can identify the packet is IPv4 packet or IPv6? Could some one point me to the document/rfc where I can find the answer? Excuse me if this is a repeated question. I checked in the archive, couldn't find the answer to the following question. Thanks in Advance Naren --------------------~~~~~----------------------- Narendra Reddy Byrapuram Mail: ByrapuramN@netscout.com From owner-mpls@UU.NET Fri Aug 9 13:49:41 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05040 for ; Fri, 9 Aug 2002 13:49:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbet29095 for ; Fri, 9 Aug 2002 17:50: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 QQnbet26843; Fri, 9 Aug 2002 17:49:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbet22109 for mpls-outgoing; Fri, 9 Aug 2002 17:49: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 QQnbet22104 for ; Fri, 9 Aug 2002 17:49:11 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 QQnbet19522 for ; Fri, 9 Aug 2002 17:48:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbet25668 for ; Fri, 9 Aug 2002 17:48:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbet25655 for ; Fri, 9 Aug 2002 17:48:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA19847 for ; Fri, 9 Aug 2002 13:48:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA20327 for mpls@uu.net; Fri, 9 Aug 2002 13:48:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnbet22062 for ; Fri, 9 Aug 2002 17:46:58 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 QQnbet13892 for ; Fri, 9 Aug 2002 17:45:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbet24540 for ; Fri, 9 Aug 2002 17:45:52 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 QQnbet24530 for ; Fri, 9 Aug 2002 17:45:51 GMT Received: (qmail 19629 invoked by uid 104); 9 Aug 2002 17:45:51 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.667281 secs); 09 Aug 2002 17:45:51 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 9 Aug 2002 17:45: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 g79Hjnw26768; Fri, 9 Aug 2002 10:45:49 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 10:45:58 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037DD@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ping Pan'" Cc: "'mpls@UU.net'" Subject: RE: Comments on Fast Reroute draft Date: Fri, 9 Aug 2002 10:45:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Ping, Thanks for your reply. Please see some further remarks: -Shahram > > > 2) Is the meaning of the following flags combinations in > session_attribute as indicated: > > > > (Local protection desired =0) & (Node protection desired > =0)-> No protection > > (Local protection desired =0) & (Node protection desired > =1)-> Node protection > > (Local protection desired =1) & (Node protection desired > =0)-> Link protection > > (Local protection desired =1) & (Node protection desired > =1)-> Node protection > > (Local protection desired =1) & (no Session_Attribute > object)-> Local policy > > > > Please clarify the correct meaning in the text. > > > > > What's been described in SAO is a user's desire. The routers > may not be > able to support it. For example, when a user asks for > local-protection-desired and node-protection-desried, if a backup LSP > cannot be established to skip the node, well, tough! ;-) Depending on > the implementation, link protection may be used only instead. Sure, but what I meant was, which one is desired by the user. Therefore I think it needs to be clarified. > > > 11) Section 8.1 talks about sending Path Error to notify > the ingress LSR > > of the fast protection event. For how long and with what > intervals is this > > Path_ERROR transmitted? > > > > > Path_Error messages are reference messages to the ingress. In other > words, they are not that important. So a router can take its time to > send the error messages. BTW, when a link/node goes down, it > is possible > that a router shoots out multiple error messages. One is to > inform the > ingress that the link/node is found to be dead. After the > local repair, > the node will tell the ingress "the LSP has been locally repaired". My question was, does the PLR send the Error message periodically or only once? > > > > 12) Section 9.2 permits having both types of protection > (1-to-1 and facility) for the same PLR. > > > In that case how can it inform the ingress LSR that both > > protections are available? > > > > > RRO tells the ingress that the traffic has been protected. Is > it enough? > If not, there is a MIB draft on fast-reroute. ;-) I think it depends on which procedure is used to compute the Bypass tunnels. If the ingress computes the bypass tunnel, then it may need this info. And BTW, what is the relevance of MIB here? From owner-mpls@UU.NET Fri Aug 9 13:56: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 NAA05239 for ; Fri, 9 Aug 2002 13:56:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbet10440 for ; Fri, 9 Aug 2002 17:57: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 QQnbet07182; Fri, 9 Aug 2002 17:55:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbet22503 for mpls-outgoing; Fri, 9 Aug 2002 17:54: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 QQnbet22473 for ; Fri, 9 Aug 2002 17:54:46 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 QQnbet21690 for ; Fri, 9 Aug 2002 17:53: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 QQnbet04441 for ; Fri, 9 Aug 2002 17:53:50 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 QQnbet03484 for ; Fri, 9 Aug 2002 17:53: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 NAA20241 for ; Fri, 9 Aug 2002 13:53:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA21033 for mpls@uu.net; Fri, 9 Aug 2002 13:53:04 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnbet22113 for ; Fri, 9 Aug 2002 17:49: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 QQnbet11098 for ; Fri, 9 Aug 2002 17:48: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 QQnbet17999 for ; Fri, 9 Aug 2002 17:48:59 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 QQnbet17995 for ; Fri, 9 Aug 2002 17:48:58 GMT Received: (qmail 21095 invoked by uid 104); 9 Aug 2002 17:48:58 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.501146 secs); 09 Aug 2002 17:48:58 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 9 Aug 2002 17:48: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 g79Hmvw02385 for ; Fri, 9 Aug 2002 10:48:57 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 10:49:06 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037DE@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'mpls@UU.net'" Subject: Comments on Backup-Computation draft Date: Fri, 9 Aug 2002 10:48:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a few comments regarding this draft: 1) Section 3, does not seem to indicate that it is possible to request local protection and BW protection by only using the Session_Attribute. Why is that? 2) Many parts of the draft says PLR SHOULD send path_Error to the ingress LSR. While the fast-reroute draft says MAY. Which one is correct? 3) The term "backup tunnel" is used in this draft to mean "Bypass tunnel". Please follow the terms as defined in the fast-reroute draft. 4) Section 5.1 says: "Note also that the single failure assumption needed for such bandwidth sharing is a pre-requisite to any protection approach which uses pre- computed backup tunnels -" Do you mean it is pre-requisite for this draft? Otherwise it can't be pre-requisite for any protection approach. 5) Section 5.1 says: "However, achieving such sharing using explicit bandwidth reservations for the backup tunnels requires extensive signaling and routing extensions: - routing extensions propagating the set of backup LSPs as well as their bandwidth and the element(s) they protect [BP- PLACEMENT]. In [lakshman]it was proposed to substantially reduce the amount of state that needs to be propagated in the routing updates at the price of sacrificing the amount of achievable sharing. " This is not accurate. If you use the configuration method advised in this draft or use the extension you propose to IGP in this draft, there is no need for any more extensions to routing. Also Fast_reroute draft already proposes extensions to the signaling. So extension to signaling should not be an issue. And I even think the same extensions could be used here by the head-end for signaling. 6) Appendix A gives an example which is easily solvable using the text from other parts of this draft. The solution is using 2 Bypass tunnel for the R2-R3 link as following: R2-R6-R7-R4 = 5M R2-R8-R9-R4 = 5M So it is possible to use independent CSPF at PLRs. 7) Section 6.1.1 criticizes that if a PLR is computing the Backup tunnel, then it needs signaling to enable an LSR distinguish between primary and Backup LSP. But the Fast_Reroute draft ha already defined these extensions and making use of them. So there is no need for any extra signaling. 8) Section 6.2.1 suggests finding the backup pool, by subtracting the global reservable BW from the link BW. How does a node know the link BW to do this computation? 9) Section 6.2.4: What happens if all NNHOPs are part of the SRLG? 10) Section 7: Can't the L1 detect the L1 defects? In that case the node and link failures could be distinguished. 11) Finally, let me provide you with an alternative, simpler proposal: Let only the Ingress LSRs (head-end) do the TE and Bypass tunnel computation. Here is how: If a Bypass tunnel is required at a PLR node, the ingress LSR can check the RRO object in the RESV message to see whether, the node or link that it wants has bypass tunnel or not. If a Bypass tunnel exists, fine, otherwise it will compute a bypass tunnel ( or more) and indicate that, in its PATH message. The appropriate PLR will then use the received PATH message to generate the Bypass tunnel(s). The advantage of this method is that it is distributed, and doesn't need intermediate LSRs to do CSPF. Also as I mentioned the issue of Appendix A is easily solvable using more than 1 Bypass tunnels. Yours, Shahram From owner-mpls@UU.NET Fri Aug 9 14:08: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 OAA05631 for ; Fri, 9 Aug 2002 14:08:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbeu26541 for ; Fri, 9 Aug 2002 18: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 QQnbeu23293; Fri, 9 Aug 2002 18:07:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbeu16169 for mpls-outgoing; Fri, 9 Aug 2002 18:07: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 QQnbeu16012 for ; Fri, 9 Aug 2002 18:07: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 QQnbeu05934 for ; Fri, 9 Aug 2002 18:07: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 QQnbeu22969 for ; Fri, 9 Aug 2002 18:07:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbeu22963 for ; Fri, 9 Aug 2002 18:07:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA21437 for ; Fri, 9 Aug 2002 14:07:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA24773 for mpls@uu.net; Fri, 9 Aug 2002 14:07:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnbeu15376 for ; Fri, 9 Aug 2002 18:06:03 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 QQnbeu03995 for ; Fri, 9 Aug 2002 18:04: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 QQnbeu02705 for ; Fri, 9 Aug 2002 18:04:18 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 QQnbeu02159 for ; Fri, 9 Aug 2002 18:04:04 GMT Received: (qmail 27848 invoked by uid 104); 9 Aug 2002 18:04:01 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.490285 secs); 09 Aug 2002 18:04:01 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 9 Aug 2002 18:04:00 -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 g79I40w14596; Fri, 9 Aug 2002 11:04:00 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 11:04:09 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037DF@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ping Pan'" Cc: "'mpls@UU.net'" Subject: RE: Comments on Fast Reroute draft Date: Fri, 9 Aug 2002 11:03:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Ping, > -----Original Message----- > From: Ping Pan [mailto:pingpan@cs.columbia.edu] > Sent: Friday, August 09, 2002 2:00 PM > To: Shahram Davari > Cc: 'mpls@UU.net' > Subject: Re: Comments on Fast Reroute draft > > > Shahram Davari wrote: > > >>What's been described in SAO is a user's desire. The routers > >>may not be > >>able to support it. For example, when a user asks for > >>local-protection-desired and node-protection-desried, if a > backup LSP > >>cannot be established to skip the node, well, tough! ;-) > Depending on > >>the implementation, link protection may be used only instead. > >> > > > > > > Sure, but what I meant was, which one is desired by the user. > > Therefore I think it needs to be clarified. > > > > > OK. > > > >>Path_Error messages are reference messages to the ingress. In other > >>words, they are not that important. So a router can take > its time to > >>send the error messages. BTW, when a link/node goes down, it > >>is possible > >>that a router shoots out multiple error messages. One is to > >>inform the > >>ingress that the link/node is found to be dead. After the > >>local repair, > >>the node will tell the ingress "the LSP has been locally repaired". > >> > > > > > > My question was, does the PLR send the Error message > periodically or only once? > > > > > Hmmmm.... I see what you mean. The RSVP RFC didn't say how many error > messages to be sent per error condition. In case of node/link > failure, > if the code was written in such a way to check the link/node > status at > every Path refresh cycle, an Path error may be generated every time. > However, I don't think this is harmful. Of course you can coded it > differently. OK. > > > > > > > >> > >>>12) Section 9.2 permits having both types of protection > >>> > >>(1-to-1 and facility) for the same PLR. > >> > >> > >>>In that case how can it inform the ingress LSR that both > >>>protections are available? > >>> > >>> > >> > >>RRO tells the ingress that the traffic has been protected. Is > >>it enough? > >> If not, there is a MIB draft on fast-reroute. ;-) > >> > > > > I think it depends on which procedure is used to compute the > > Bypass tunnels. If the ingress computes the bypass tunnel, then > > it may need this info. And BTW, what is the relevance of MIB here? > > > > > The ingress does not need to compute the bypass tunnel. Bypass tunnel > computation could be a local decision. > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastrerout e-mib-00.txt But it may also be a non-local decision. -Shahram From owner-mpls@UU.NET Fri Aug 9 14:16: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 OAA06065 for ; Fri, 9 Aug 2002 14:16:38 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbev08319 for ; Fri, 9 Aug 2002 18:17: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 QQnbev06698; Fri, 9 Aug 2002 18:17:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbev18380 for mpls-outgoing; Fri, 9 Aug 2002 18:16: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 QQnbev18367 for ; Fri, 9 Aug 2002 18:16:40 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 QQnbeu25273 for ; Fri, 9 Aug 2002 18:12: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 QQnbeu11377 for ; Fri, 9 Aug 2002 18:12:21 GMT Received: from pimout3-int.prodigy.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout3-ext.prodigy.net [207.115.63.102]) id QQnbeu11371 for ; Fri, 9 Aug 2002 18:12:21 GMT Received: from cs.columbia.edu (adsl-66-127-241-207.dsl.sntc01.pacbell.net [66.127.241.207]) by pimout3-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g79ICIa166162; Fri, 9 Aug 2002 14:12:18 -0400 Message-ID: <3D540602.7070806@cs.columbia.edu> Date: Fri, 09 Aug 2002 11:12:18 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Shahram Davari CC: "'mpls@UU.net'" Subject: Re: Comments on Fast Reroute draft References: <4B6D09F3B826D411A67300D0B706EFDEB037DF@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > Ping, > >>The ingress does not need to compute the bypass tunnel. Bypass tunnel >>computation could be a local decision. >> >>http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastrerout >> > e-mib-00.txt > > > But it may also be a non-local decision. > > -Shahram > I think MPLS WG had gone through this argument before (there was a draft on this). I recall nobody wanted it. The question was why. Also are we going to design a RSVP fragmentation extension to support large messages? ;-) - Ping From owner-mpls@UU.NET Fri Aug 9 14:22: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 OAA06221 for ; Fri, 9 Aug 2002 14:22:43 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbev19556 for ; Fri, 9 Aug 2002 18:23: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 QQnbev13925; Fri, 9 Aug 2002 18:20:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbev18648 for mpls-outgoing; Fri, 9 Aug 2002 18:19:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbev18626 for ; Fri, 9 Aug 2002 18:19:33 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 QQnbev06064 for ; Fri, 9 Aug 2002 18:18: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 QQnbev00487 for ; Fri, 9 Aug 2002 18:18:10 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbev00465 for ; Fri, 9 Aug 2002 18:18:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA22480 for ; Fri, 9 Aug 2002 14:18:09 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA27367 for mpls@uu.net; Fri, 9 Aug 2002 14:18:09 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbev18398 for ; Fri, 9 Aug 2002 18:17:18 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 QQnbev01545 for ; Fri, 9 Aug 2002 18:16: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 QQnbev14077 for ; Fri, 9 Aug 2002 18:16:11 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 QQnbev14068 for ; Fri, 9 Aug 2002 18:16:11 GMT Received: (qmail 3502 invoked by uid 104); 9 Aug 2002 18:16:10 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.469929 secs); 09 Aug 2002 18:16:10 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 9 Aug 2002 18:16:09 -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 g79IG9w22438; Fri, 9 Aug 2002 11:16:09 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 11:16:18 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037E0@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ping Pan'" Cc: "'mpls@UU.net'" Subject: RE: Comments on Fast Reroute draft Date: Fri, 9 Aug 2002 11:16:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Ping, draft-vasseur-mpls-backup-computation-00.txt is also proposing non-local bypass tunnel computation. Has this draft also been rejected? -Shahram > -----Original Message----- > From: Ping Pan [mailto:pingpan@cs.columbia.edu] > Sent: Friday, August 09, 2002 2:12 PM > To: Shahram Davari > Cc: 'mpls@UU.net' > Subject: Re: Comments on Fast Reroute draft > > > Shahram Davari wrote: > > > Ping, > > > >>The ingress does not need to compute the bypass tunnel. > Bypass tunnel > >>computation could be a local decision. > >> > >>http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastrerout > >> > > e-mib-00.txt > > > > > > But it may also be a non-local decision. > > > > -Shahram > > > > > I think MPLS WG had gone through this argument before (there > was a draft > on this). I recall nobody wanted it. The question was why. > Also are we > going to design a RSVP fragmentation extension to support large > messages? ;-) > > - Ping > > > > From owner-mpls@UU.NET Fri Aug 9 14:43: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 OAA06863 for ; Fri, 9 Aug 2002 14:43:51 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbex02665 for ; Fri, 9 Aug 2002 18:45: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 QQnbew00933; Fri, 9 Aug 2002 18:44:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbew23047 for mpls-outgoing; Fri, 9 Aug 2002 18:43:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbew23038 for ; Fri, 9 Aug 2002 18:43:44 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 QQnbew11709 for ; Fri, 9 Aug 2002 18:42: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 QQnbew09058 for ; Fri, 9 Aug 2002 18:42:57 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 QQnbew09046 for ; Fri, 9 Aug 2002 18:42:56 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 OAA00660 for ; Fri, 9 Aug 2002 14:42:54 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28471 for ; Fri, 9 Aug 2002 14:42:55 -0400 (EDT) Message-ID: <3D540D25.2090306@marconi.com> Date: Fri, 09 Aug 2002 14:42:45 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: How Egress ATM-LSR/FR-LSR distinguishes IPv4 and IPv6 packets? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Narendra Byrapuram wrote: > > How Egress ATM-LSR/FR-LSR distinguishes IPv4 and IPv6 packets? > > In the case of Generic Label, RFC 3032 "MPLS Label Stack Encoding" > specifies IPv4 Explicit NULL (0) and IPv6 Explicit NULL (2). > > RFC3034 (MPLS on FR) and RFC 3035 (MPLS using ATM VC Switching) doesn't > talk about the similarly to identify Network Layer. > > When Egress ATM-LSR receives an MPLS packet, how it can identify the packet > is IPv4 packet or IPv6? > > Could some one point me to the document/rfc where I can find the answer? I don't think you can tell, just by looking at the data-plane packets. But you can tell from signaling. If RSVP-TE is used to set up the LSP, the L3PID field in the LABEL_REQUEST object should contan the ethertype for IPv4 (0x0800) or IPv6 (0x86dd) For LDP, I'm not certain, but I would assume that labels that correspond to an IPv4 FEC would contain IPv4 payload, and labels correspoding to an IPv6 FEC would contain IPv6 payload. -- David From owner-mpls@UU.NET Fri Aug 9 14:56: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 OAA07209 for ; Fri, 9 Aug 2002 14:56:06 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbex29757 for ; Fri, 9 Aug 2002 18:57: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 QQnbex28187; Fri, 9 Aug 2002 18:56:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbex25273 for mpls-outgoing; Fri, 9 Aug 2002 18:56:08 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 QQnbex25174 for ; Fri, 9 Aug 2002 18:55: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 QQnbex07590 for ; Fri, 9 Aug 2002 18:55: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 QQnbex17203 for ; Fri, 9 Aug 2002 18:55: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 QQnbex17196 for ; Fri, 9 Aug 2002 18:55:24 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6KFZGJ>; Fri, 9 Aug 2002 14:55:23 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B0226722C@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'David Charlap'" Cc: mpls@UU.NET Subject: RE: How Egress ATM-LSR/FR-LSR distinguishes IPv4 and IPv6 packets ? Date: Fri, 9 Aug 2002 14:55:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk David, It is as you describe for LDP. Generally, one key advantage to downstream allocation of labels is that the LSR doing the label allocation gets decides what labels to give out. Naturally, it makes sense to only give out labels for traffic the LSR knows how to forward... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: David Charlap [mailto:David.Charlap@marconi.com] Sent: Friday, August 09, 2002 2:43 PM To: mpls@UU.NET Subject: Re: How Egress ATM-LSR/FR-LSR distinguishes IPv4 and IPv6 packets? Narendra Byrapuram wrote: > > How Egress ATM-LSR/FR-LSR distinguishes IPv4 and IPv6 packets? > > In the case of Generic Label, RFC 3032 "MPLS Label Stack Encoding" > specifies IPv4 Explicit NULL (0) and IPv6 Explicit NULL (2). > > RFC3034 (MPLS on FR) and RFC 3035 (MPLS using ATM VC Switching) doesn't > talk about the similarly to identify Network Layer. > > When Egress ATM-LSR receives an MPLS packet, how it can identify the packet > is IPv4 packet or IPv6? > > Could some one point me to the document/rfc where I can find the answer? I don't think you can tell, just by looking at the data-plane packets. But you can tell from signaling. If RSVP-TE is used to set up the LSP, the L3PID field in the LABEL_REQUEST object should contan the ethertype for IPv4 (0x0800) or IPv6 (0x86dd) For LDP, I'm not certain, but I would assume that labels that correspond to an IPv4 FEC would contain IPv4 payload, and labels correspoding to an IPv6 FEC would contain IPv6 payload. -- David From owner-mpls@UU.NET Fri Aug 9 15:07: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 PAA07634 for ; Fri, 9 Aug 2002 15:07:50 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbeu29272 for ; Fri, 9 Aug 2002 18:02: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 QQnbeu27458; Fri, 9 Aug 2002 18:02:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbeu02144 for mpls-outgoing; Fri, 9 Aug 2002 18:01:45 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 QQnbeu00768 for ; Fri, 9 Aug 2002 18:01:33 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 QQnbet16914 for ; Fri, 9 Aug 2002 17:59: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 QQnbet16555 for ; Fri, 9 Aug 2002 17:59:47 GMT Received: from pimout4-ext.prodigy.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout4-ext.prodigy.net [207.115.63.103]) id QQnbet16549 for ; Fri, 9 Aug 2002 17:59:46 GMT Received: from cs.columbia.edu (adsl-66-127-241-207.dsl.sntc01.pacbell.net [66.127.241.207]) by pimout4-ext.prodigy.net (8.11.0/8.11.0) with ESMTP id g79Hxiv41326; Fri, 9 Aug 2002 13:59:44 -0400 Message-ID: <3D54030F.4060303@cs.columbia.edu> Date: Fri, 09 Aug 2002 10:59:43 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Shahram Davari CC: "'mpls@UU.net'" Subject: Re: Comments on Fast Reroute draft References: <4B6D09F3B826D411A67300D0B706EFDEB037DD@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: >>What's been described in SAO is a user's desire. The routers >>may not be >>able to support it. For example, when a user asks for >>local-protection-desired and node-protection-desried, if a backup LSP >>cannot be established to skip the node, well, tough! ;-) Depending on >>the implementation, link protection may be used only instead. >> > > > Sure, but what I meant was, which one is desired by the user. > Therefore I think it needs to be clarified. > OK. >>Path_Error messages are reference messages to the ingress. In other >>words, they are not that important. So a router can take its time to >>send the error messages. BTW, when a link/node goes down, it >>is possible >>that a router shoots out multiple error messages. One is to >>inform the >>ingress that the link/node is found to be dead. After the >>local repair, >>the node will tell the ingress "the LSP has been locally repaired". >> > > > My question was, does the PLR send the Error message periodically or only once? > Hmmmm.... I see what you mean. The RSVP RFC didn't say how many error messages to be sent per error condition. In case of node/link failure, if the code was written in such a way to check the link/node status at every Path refresh cycle, an Path error may be generated every time. However, I don't think this is harmful. Of course you can coded it differently. > > >> >>>12) Section 9.2 permits having both types of protection >>> >>(1-to-1 and facility) for the same PLR. >> >> >>>In that case how can it inform the ingress LSR that both >>>protections are available? >>> >>> >> >>RRO tells the ingress that the traffic has been protected. Is >>it enough? >> If not, there is a MIB draft on fast-reroute. ;-) >> > > I think it depends on which procedure is used to compute the > Bypass tunnels. If the ingress computes the bypass tunnel, then > it may need this info. And BTW, what is the relevance of MIB here? > The ingress does not need to compute the bypass tunnel. Bypass tunnel computation could be a local decision. http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-00.txt - Ping From owner-mpls@UU.NET Mon Aug 12 13:36: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 NAA01804 for ; Mon, 12 Aug 2002 13:36:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbpu23184 for ; Mon, 12 Aug 2002 17:37: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 QQnbpu21564; Mon, 12 Aug 2002 17:37:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbpu25347 for mpls-outgoing; Mon, 12 Aug 2002 17:36: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 QQnbpu25341 for ; Mon, 12 Aug 2002 17:36: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 QQnbpu07346 for ; Mon, 12 Aug 2002 17:36: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 QQnbpu21035 for ; Mon, 12 Aug 2002 17:36:06 GMT Received: from RS-SC-EXC6.rs.riverstonenet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host60.riverstonenet.com [64.95.122.60] (may be forged)) id QQnbpu21027 for ; Mon, 12 Aug 2002 17:36:05 GMT content-class: urn:content-classes:message Subject: fast-reroute merging MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 12 Aug 2002 10:36:00 -0700 Message-ID: Thread-Topic: fast-reroute merging Thread-Index: AcJCJrlh0uvoue0WSc+iwcrI4XcRzg== From: "Sundara Murugan" To: "mpls@UU.net" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA01804 Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt explains merging procedure. In the fig below if there is a link between I and F then D will have a detour D-I-F. In this case how router I (the MP) handles detour LSPs from B, C and D? -sundara ------ 5.3.1. An Example on Path Message Merging Consider the following example: G----H----I--\ | | | \ A----B----C----D----E---F The protected LSP is A-B-C-D-E-F. After running CSPF, let the detour ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be C-H-I-E-F. H will receive Path messages that have the same SESSION and From owner-mpls@UU.NET Mon Aug 12 14:03: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 OAA03290 for ; Mon, 12 Aug 2002 14:03:16 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbpw15042 for ; Mon, 12 Aug 2002 18:03: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 QQnbpw11988; Mon, 12 Aug 2002 18:01:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbpw02125 for mpls-outgoing; Mon, 12 Aug 2002 18:00:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnbpw01413 for ; Mon, 12 Aug 2002 18:00: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 QQnbpv25444 for ; Mon, 12 Aug 2002 17:59: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 QQnbpv18515 for ; Mon, 12 Aug 2002 17:59:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbpv18511 for ; Mon, 12 Aug 2002 17:59:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA02147 for ; Mon, 12 Aug 2002 13:59:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA14686 for mpls@uu.net; Mon, 12 Aug 2002 13:59:01 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnbpv26999 for ; Mon, 12 Aug 2002 17:58:14 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 QQnbpv23818 for ; Mon, 12 Aug 2002 17: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 QQnbpv11177 for ; Mon, 12 Aug 2002 17:57:47 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 QQnbpv11170 for ; Mon, 12 Aug 2002 17:57:47 GMT Received: (qmail 22542 invoked by uid 104); 12 Aug 2002 17:57:41 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.543241 secs); 12 Aug 2002 17:57:41 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 12 Aug 2002 17:57: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 g7CHvew05552; Mon, 12 Aug 2002 10:57:40 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 10:58:00 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037F0@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Sundara Murugan'" , "mpls@UU.net" Subject: RE: fast-reroute merging Date: Mon, 12 Aug 2002 10:57:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Sundara, This is exactly the same question that I asked in another email: "Since as stated in section 7, each PLR has option to apply its own constraints, then each PLR may reach to a different backup-path ERO for the same flow. Assuming that the EROs have a single link (the downstream link of an MP LSP) in common, isn't it wrong for an MP LSR to merge those Path messages?" I think the solution is to require the same ERO for merging. Yours, -Shahram > -----Original Message----- > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > Sent: Monday, August 12, 2002 1:36 PM > To: mpls@UU.net > Subject: fast-reroute merging > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > explains merging procedure. In the fig below if there is a > link between I and F then D will have a detour D-I-F. In this > case how router I (the MP) handles detour LSPs from B, C and D? > > -sundara > > ------ > > 5.3.1. An Example on Path Message Merging > > Consider the following example: > > > G----H----I--\ > | | | \ > A----B----C----D----E---F > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > the detour > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > C-H-I-E-F. > > H will receive Path messages that have the same SESSION and > > > From owner-mpls@UU.NET Mon Aug 12 14:22: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 OAA04470 for ; Mon, 12 Aug 2002 14:22:38 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbpx09659 for ; Mon, 12 Aug 2002 18:23: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 QQnbpx07261; Mon, 12 Aug 2002 18:22:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbpx22451 for mpls-outgoing; Mon, 12 Aug 2002 18:22: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 QQnbpx22438 for ; Mon, 12 Aug 2002 18:22:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnbpx21126 for ; Mon, 12 Aug 2002 18:21: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 QQnbpx00254 for ; Mon, 12 Aug 2002 18:21:38 GMT Received: from RS-SC-EXC6.rs.riverstonenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host60.riverstonenet.com [64.95.122.60] (may be forged)) id QQnbpx00233 for ; Mon, 12 Aug 2002 18:21:37 GMT content-class: urn:content-classes:message Subject: RE: fast-reroute merging MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 12 Aug 2002 11:21:37 -0700 Message-ID: Thread-Topic: fast-reroute merging Thread-Index: AcJCKceYKLKXdtEbT0ygVCqG7+EsrQAABX4Q From: "Sundara Murugan" To: "Shahram Davari" , "mpls@UU.net" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA04470 Shahram, Section 5.3.1 says that the MP selects the shorter ERO path length. This may not be correct. If there are other routers between I and E, then the ERO lenght of the detour from C could be more than the ERO lenght of the detour from B. If you go by the rule, then H will merge the detours from B & C and establish a detour to D. Then the detour from C will not avoid its next-hop D. So there won't be a detour from C. So the MP has to select the detour which merges with the main LSP that is closer to the egress router. -sundara -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, August 12, 2002 10:57 AM To: Sundara Murugan; mpls@UU.net Subject: RE: fast-reroute merging Sundara, This is exactly the same question that I asked in another email: "Since as stated in section 7, each PLR has option to apply its own constraints, then each PLR may reach to a different backup-path ERO for the same flow. Assuming that the EROs have a single link (the downstream link of an MP LSP) in common, isn't it wrong for an MP LSR to merge those Path messages?" I think the solution is to require the same ERO for merging. Yours, -Shahram > -----Original Message----- > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > Sent: Monday, August 12, 2002 1:36 PM > To: mpls@UU.net > Subject: fast-reroute merging > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > explains merging procedure. In the fig below if there is a > link between I and F then D will have a detour D-I-F. In this > case how router I (the MP) handles detour LSPs from B, C and D? > > -sundara > > ------ > > 5.3.1. An Example on Path Message Merging > > Consider the following example: > > > G----H----I--\ > | | | \ > A----B----C----D----E---F > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > the detour > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > C-H-I-E-F. > > H will receive Path messages that have the same SESSION and > > > From owner-mpls@UU.NET Mon Aug 12 14:47: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 OAA05569 for ; Mon, 12 Aug 2002 14:47:15 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbpz21081 for ; Mon, 12 Aug 2002 18:48: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 QQnbpz18652; Mon, 12 Aug 2002 18:47:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbpz24402 for mpls-outgoing; Mon, 12 Aug 2002 18:46: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 QQnbpz24380 for ; Mon, 12 Aug 2002 18:46:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnbpz10210 for ; Mon, 12 Aug 2002 18:46: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 QQnbpz00537 for ; Mon, 12 Aug 2002 18:46:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbpz00522 for ; Mon, 12 Aug 2002 18:46:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA06433 for ; Mon, 12 Aug 2002 14:46:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA20997 for mpls@uu.net; Mon, 12 Aug 2002 14:46:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbpz24139 for ; Mon, 12 Aug 2002 18:45: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 QQnbpz18510 for ; Mon, 12 Aug 2002 18:45: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 QQnbpz16902 for ; Mon, 12 Aug 2002 18:45:12 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 QQnbpz16888 for ; Mon, 12 Aug 2002 18:45:11 GMT Received: (qmail 16881 invoked by uid 104); 12 Aug 2002 18:45:10 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.616988 secs); 12 Aug 2002 18:45:10 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 12 Aug 2002 18:45:09 -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 g7CIj9w07575; Mon, 12 Aug 2002 11:45:09 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 11:45:29 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037F2@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Sundara Murugan'" , "mpls@UU.net" Subject: RE: fast-reroute merging Date: Mon, 12 Aug 2002 11:44:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Sundara, I think the shortest ERO is only a suggested example. and not a standard rule. G----H----I--\ | | | \ A----B----C----D----E---F I think no merging should happen in the G, H and I LSRs. The reason is that may be B has calculated the route B-G-H-I-D-E-F assuming some BW restrictions, etc. We don't want H to change that to B-G-H-I-E-F. Also since each PLR does an independent ERO calculation, it is quite possible for C to compute computes the path as being C-H-I-D-J-K-M-N-... Clearly C's detour should not be merged with B's detour here. If we have rule changed to "for merging the path messages should have the same ERO", then we won't have such a problem. -Shahram > -----Original Message----- > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > Sent: Monday, August 12, 2002 2:22 PM > To: Shahram Davari; mpls@UU.net > Subject: RE: fast-reroute merging > > > Shahram, > > Section 5.3.1 says that the MP selects the shorter ERO path > length. This may not be correct. > > If there are other routers between I and E, then the ERO > lenght of the detour from C could be more than the ERO lenght > of the detour from B. If you go by the rule, then H will > merge the detours from B & C and establish a detour to D. > Then the detour from C will not avoid its next-hop D. So > there won't be a detour from C. > > So the MP has to select the detour which merges with the main > LSP that is closer to the egress router. > > -sundara > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, August 12, 2002 10:57 AM > To: Sundara Murugan; mpls@UU.net > Subject: RE: fast-reroute merging > > > Sundara, > > This is exactly the same question that I asked in another email: > > "Since as stated in section 7, each PLR has option to apply > its own constraints, then each PLR may reach to a different > backup-path ERO for the same flow. Assuming that the EROs > have a single link (the downstream link of an MP LSP) in > common, isn't it wrong for an MP LSR to merge those Path messages?" > > > I think the solution is to require the same ERO for merging. > > Yours, > -Shahram > > > > > > -----Original Message----- > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > Sent: Monday, August 12, 2002 1:36 PM > > To: mpls@UU.net > > Subject: fast-reroute merging > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > explains merging procedure. In the fig below if there is a > > link between I and F then D will have a detour D-I-F. In this > > case how router I (the MP) handles detour LSPs from B, C and D? > > > > -sundara > > > > ------ > > > > 5.3.1. An Example on Path Message Merging > > > > Consider the following example: > > > > > > G----H----I--\ > > | | | \ > > A----B----C----D----E---F > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > the detour > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > C-H-I-E-F. > > > > H will receive Path messages that have the same SESSION and > > > > > > > From owner-mpls@UU.NET Mon Aug 12 15:02: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 PAA06466 for ; Mon, 12 Aug 2002 15:02:58 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbqa08554 for ; Mon, 12 Aug 2002 19:04: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 QQnbqa07212; Mon, 12 Aug 2002 19:03:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbqa08086 for mpls-outgoing; Mon, 12 Aug 2002 19:03: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 QQnbqa08074 for ; Mon, 12 Aug 2002 19:03: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 QQnbqa13230 for ; Mon, 12 Aug 2002 19:02: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 QQnbqa02719 for ; Mon, 12 Aug 2002 19:02:06 GMT Received: from RS-SC-EXC6.rs.riverstonenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host60.riverstonenet.com [64.95.122.60] (may be forged)) id QQnbqa02710 for ; Mon, 12 Aug 2002 19:02:05 GMT content-class: urn:content-classes:message Subject: RE: fast-reroute merging MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 12 Aug 2002 12:02:05 -0700 Message-ID: Thread-Topic: fast-reroute merging Thread-Index: AcJCMGX14Ua9IBbVTySGe+R6xQlO/gAAOMEw From: "Sundara Murugan" To: "Shahram Davari" , "mpls@UU.net" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA06466 Shahram, Let us assume that detours from B and C don't merge at H. But these two LSPs share the same link between H-I. The at I there will be 2 detour LSP (B to D and another from C to E). If the detour LSPs use SE filter, then the RESV message from I to H can specify only one filter (Session + sender of all the detours will be the same) and only one Label. Which label does I select? -sundara -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, August 12, 2002 11:45 AM To: Sundara Murugan; mpls@UU.net Subject: RE: fast-reroute merging Sundara, I think the shortest ERO is only a suggested example. and not a standard rule. G----H----I--\ | | | \ A----B----C----D----E---F I think no merging should happen in the G, H and I LSRs. The reason is that may be B has calculated the route B-G-H-I-D-E-F assuming some BW restrictions, etc. We don't want H to change that to B-G-H-I-E-F. Also since each PLR does an independent ERO calculation, it is quite possible for C to compute computes the path as being C-H-I-D-J-K-M-N-... Clearly C's detour should not be merged with B's detour here. If we have rule changed to "for merging the path messages should have the same ERO", then we won't have such a problem. -Shahram > -----Original Message----- > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > Sent: Monday, August 12, 2002 2:22 PM > To: Shahram Davari; mpls@UU.net > Subject: RE: fast-reroute merging > > > Shahram, > > Section 5.3.1 says that the MP selects the shorter ERO path > length. This may not be correct. > > If there are other routers between I and E, then the ERO > lenght of the detour from C could be more than the ERO lenght > of the detour from B. If you go by the rule, then H will > merge the detours from B & C and establish a detour to D. > Then the detour from C will not avoid its next-hop D. So > there won't be a detour from C. > > So the MP has to select the detour which merges with the main > LSP that is closer to the egress router. > > -sundara > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, August 12, 2002 10:57 AM > To: Sundara Murugan; mpls@UU.net > Subject: RE: fast-reroute merging > > > Sundara, > > This is exactly the same question that I asked in another email: > > "Since as stated in section 7, each PLR has option to apply > its own constraints, then each PLR may reach to a different > backup-path ERO for the same flow. Assuming that the EROs > have a single link (the downstream link of an MP LSP) in > common, isn't it wrong for an MP LSR to merge those Path messages?" > > > I think the solution is to require the same ERO for merging. > > Yours, > -Shahram > > > > > > -----Original Message----- > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > Sent: Monday, August 12, 2002 1:36 PM > > To: mpls@UU.net > > Subject: fast-reroute merging > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > explains merging procedure. In the fig below if there is a > > link between I and F then D will have a detour D-I-F. In this > > case how router I (the MP) handles detour LSPs from B, C and D? > > > > -sundara > > > > ------ > > > > 5.3.1. An Example on Path Message Merging > > > > Consider the following example: > > > > > > G----H----I--\ > > | | | \ > > A----B----C----D----E---F > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > the detour > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > C-H-I-E-F. > > > > H will receive Path messages that have the same SESSION and > > > > > > > From owner-mpls@UU.NET Mon Aug 12 15:04:43 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 PAA06561 for ; Mon, 12 Aug 2002 15:04:43 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbqa19638 for ; Mon, 12 Aug 2002 19:05: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 QQnbqa17846; Mon, 12 Aug 2002 19:05:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbqa09014 for mpls-outgoing; Mon, 12 Aug 2002 19:04: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 QQnbqa08656 for ; Mon, 12 Aug 2002 19:04:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnbqa14079 for ; Mon, 12 Aug 2002 19:04: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 QQnbqa04242 for ; Mon, 12 Aug 2002 19:04:06 GMT Received: from e2.ny.us.ibm.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: e2.ny.us.ibm.com [32.97.182.102]) id QQnbqa04235 for ; Mon, 12 Aug 2002 19:04:06 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7CJ42ha131314 for ; Mon, 12 Aug 2002 15:04:03 -0400 Received: from d03nm046.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7CJ40Zj125842 for ; Mon, 12 Aug 2002 15:04:01 -0400 Subject: draft-ietf-mpls-ftn-mib-04.txt To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Nicholas Williamson" Date: Mon, 12 Aug 2002 15:03:57 -0400 X-MIMETrack: Serialize by Router on D03NM046/03/M/IBM(Release 5.0.10 |March 22, 2002) at 08/12/2002 01:04:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk draft-ietf-mpls-ftn-mib-04.txt expired in July. Is another version forth coming? Nick From owner-mpls@UU.NET Mon Aug 12 15:15: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 PAA07014 for ; Mon, 12 Aug 2002 15:15:22 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbqb04677 for ; Mon, 12 Aug 2002 19:16: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 QQnbqb02793; Mon, 12 Aug 2002 19:15:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbqb20077 for mpls-outgoing; Mon, 12 Aug 2002 19:15: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 QQnbqa19724 for ; Mon, 12 Aug 2002 19:14: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 QQnbqa02498 for ; Mon, 12 Aug 2002 19:14: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 QQnbqa01587 for ; Mon, 12 Aug 2002 19:14:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbqa01581 for ; Mon, 12 Aug 2002 19:14:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA08815 for ; Mon, 12 Aug 2002 15:14:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA25744 for mpls@uu.net; Mon, 12 Aug 2002 15:14:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnbqa19686 for ; Mon, 12 Aug 2002 19:13:19 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 QQnbqa29203 for ; Mon, 12 Aug 2002 19:13: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 QQnbqa01091 for ; Mon, 12 Aug 2002 19:13: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 QQnbqa01087 for ; Mon, 12 Aug 2002 19:13: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 g7CJDBZE027546; Mon, 12 Aug 2002 15:13:12 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (che-vpn1-61.cisco.com [10.86.240.61]) by bucket.cisco.com (Mirapoint) with ESMTP id ABK71693; Mon, 12 Aug 2002 15:13:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20020812151243.061e7c00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Aug 2002 15:13:06 -0400 To: "Nicholas Williamson" From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-ftn-mib-04.txt Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk The MIB is in MIB Doctor review. We have comments, and need to update. Once finished, we will republish. --Tom >draft-ietf-mpls-ftn-mib-04.txt expired in July. Is another version forth >coming? > >Nick ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Mon Aug 12 15:25: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 PAA07444 for ; Mon, 12 Aug 2002 15:25:09 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbqb24343 for ; Mon, 12 Aug 2002 19:26: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 QQnbqb22054; Mon, 12 Aug 2002 19:24:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbqb20862 for mpls-outgoing; Mon, 12 Aug 2002 19:24: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 QQnbqb20852 for ; Mon, 12 Aug 2002 19:24:04 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 QQnbqb19959 for ; Mon, 12 Aug 2002 19:23: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 QQnbqb14370 for ; Mon, 12 Aug 2002 19:23:10 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbqb14355 for ; Mon, 12 Aug 2002 19:23:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09488 for ; Mon, 12 Aug 2002 15:23:09 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA27740 for mpls@uu.net; Mon, 12 Aug 2002 15:23:09 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnbqb20793 for ; Mon, 12 Aug 2002 19:22: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 QQnbqb22271 for ; Mon, 12 Aug 2002 19:22: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 QQnbqb13636 for ; Mon, 12 Aug 2002 19:22:11 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 QQnbqb13621 for ; Mon, 12 Aug 2002 19:22:10 GMT Received: (qmail 232 invoked by uid 104); 12 Aug 2002 19:22:10 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.508244 secs); 12 Aug 2002 19:22:10 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 12 Aug 2002 19:22:09 -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 g7CJM8w05421; Mon, 12 Aug 2002 12:22:08 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 12:22:28 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037F5@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Sundara Murugan'" , "mpls@UU.net" Subject: RE: fast-reroute merging Date: Mon, 12 Aug 2002 12:21:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk SE is for BW sharing. I could send 2 labels to H in SE mode. -Shahram > -----Original Message----- > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > Sent: Monday, August 12, 2002 3:02 PM > To: Shahram Davari; mpls@UU.net > Subject: RE: fast-reroute merging > > > Shahram, > > Let us assume that detours from B and C don't merge at H. But > these two LSPs share the same link between H-I. The at I > there will be 2 detour LSP (B to D and another from C to E). > > If the detour LSPs use SE filter, then the RESV message from > I to H can specify only one filter (Session + sender of all > the detours will be the same) and only one Label. Which label > does I select? > > -sundara > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, August 12, 2002 11:45 AM > To: Sundara Murugan; mpls@UU.net > Subject: RE: fast-reroute merging > > > Sundara, > > I think the shortest ERO is only a suggested example. and not > a standard rule. > > > > G----H----I--\ > | | | \ > A----B----C----D----E---F > > > I think no merging should happen in the G, H and I LSRs. The > reason is that > may be B has calculated the route B-G-H-I-D-E-F assuming some > BW restrictions, etc. > We don't want H to change that to B-G-H-I-E-F. > > Also since each PLR does an independent ERO calculation, it > is quite possible > for C to compute computes the path as being > C-H-I-D-J-K-M-N-... Clearly C's detour should > not be merged with B's detour here. > > If we have rule changed to "for merging the path messages > should have the same ERO", > then we won't have such a problem. > > > -Shahram > > > -----Original Message----- > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > Sent: Monday, August 12, 2002 2:22 PM > > To: Shahram Davari; mpls@UU.net > > Subject: RE: fast-reroute merging > > > > > > Shahram, > > > > Section 5.3.1 says that the MP selects the shorter ERO path > > length. This may not be correct. > > > > If there are other routers between I and E, then the ERO > > lenght of the detour from C could be more than the ERO lenght > > of the detour from B. If you go by the rule, then H will > > merge the detours from B & C and establish a detour to D. > > Then the detour from C will not avoid its next-hop D. So > > there won't be a detour from C. > > > > So the MP has to select the detour which merges with the main > > LSP that is closer to the egress router. > > > > -sundara > > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, August 12, 2002 10:57 AM > > To: Sundara Murugan; mpls@UU.net > > Subject: RE: fast-reroute merging > > > > > > Sundara, > > > > This is exactly the same question that I asked in another email: > > > > "Since as stated in section 7, each PLR has option to apply > > its own constraints, then each PLR may reach to a different > > backup-path ERO for the same flow. Assuming that the EROs > > have a single link (the downstream link of an MP LSP) in > > common, isn't it wrong for an MP LSR to merge those Path messages?" > > > > > > I think the solution is to require the same ERO for merging. > > > > Yours, > > -Shahram > > > > > > > > > > > -----Original Message----- > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > Sent: Monday, August 12, 2002 1:36 PM > > > To: mpls@UU.net > > > Subject: fast-reroute merging > > > > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > explains merging procedure. In the fig below if there is a > > > link between I and F then D will have a detour D-I-F. In this > > > case how router I (the MP) handles detour LSPs from B, C and D? > > > > > > -sundara > > > > > > ------ > > > > > > 5.3.1. An Example on Path Message Merging > > > > > > Consider the following example: > > > > > > > > > G----H----I--\ > > > | | | \ > > > A----B----C----D----E---F > > > > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > > the detour > > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > > C-H-I-E-F. > > > > > > H will receive Path messages that have the same SESSION and > > > > > > > > > > > > From owner-mpls@UU.NET Mon Aug 12 16:24: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 QAA10097 for ; Mon, 12 Aug 2002 16:24:14 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbqf12508 for ; Mon, 12 Aug 2002 20:25: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 QQnbqf10680; Mon, 12 Aug 2002 20:24:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbqf18316 for mpls-outgoing; Mon, 12 Aug 2002 20:24: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 QQnbqf18311 for ; Mon, 12 Aug 2002 20:24:24 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 QQnbqf28506 for ; Mon, 12 Aug 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 QQnbqf29505 for ; Mon, 12 Aug 2002 20:23:39 GMT Received: from mlsrv1.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQnbqf29495 for ; Mon, 12 Aug 2002 20:23:38 GMT Received: from aatlas-lt.avici.com (b2-pc58.avici.com [10.2.100.78]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g7CKNW011866; Mon, 12 Aug 2002 16:23:32 -0400 (EDT) Message-Id: <5.1.0.14.2.20020812161755.01f16880@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Aug 2002 16:23:37 -0400 To: "Sundara Murugan" From: Alia Atlas Subject: RE: fast-reroute merging Cc: "Shahram Davari" , "mpls@UU.net" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk The idea of merging detour Path messages with different EROs but the same egress interface is based upon the "path-specific method". With that method, it is required because there is no way to determine from the RESV which of the two (or more) detour Path messages the RESV belonged to. This is because both detour Path messages have the same SENDER_TEMPLATE; the Path messages can be distinguished by the Detour object and the EROs. However, doing such merging has very bad consequences. First, there are cases where a detour LSP which was up is temporarily unavailable. Second, it is not possible to guarantee protection against an SRLG failure. The solution is to use the "sender-template-specific" method, where the sender address in the SENDER_TEMPLATE is set to an address belonging to the PLR instead of being left as an address belonging to the ingress. I presented about the problems of merging Path messages with different EROs in Salt Lake City. The draft I did then, draft-atlas-rsvp-local-protect-interop-02.txt, describes the issues in detail; it has expired, because the solution was incorporated into the merged fast-reroute draft. Alia At 12:02 PM 8/12/2002 -0700, Sundara Murugan wrote: >Shahram, > >Let us assume that detours from B and C don't merge at H. But these two >LSPs share the same link between H-I. The at I there will be 2 detour LSP >(B to D and another from C to E). > >If the detour LSPs use SE filter, then the RESV message from I to H can >specify only one filter (Session + sender of all the detours will be the >same) and only one Label. Which label does I select? > >-sundara > >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Monday, August 12, 2002 11:45 AM >To: Sundara Murugan; mpls@UU.net >Subject: RE: fast-reroute merging > > >Sundara, > >I think the shortest ERO is only a suggested example. and not a standard rule. > > > > G----H----I--\ > | | | \ > A----B----C----D----E---F > > >I think no merging should happen in the G, H and I LSRs. The reason is that >may be B has calculated the route B-G-H-I-D-E-F assuming some BW >restrictions, etc. >We don't want H to change that to B-G-H-I-E-F. > >Also since each PLR does an independent ERO calculation, it is quite possible >for C to compute computes the path as being C-H-I-D-J-K-M-N-... Clearly >C's detour should >not be merged with B's detour here. > >If we have rule changed to "for merging the path messages should have the >same ERO", >then we won't have such a problem. > > >-Shahram > > > -----Original Message----- > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > Sent: Monday, August 12, 2002 2:22 PM > > To: Shahram Davari; mpls@UU.net > > Subject: RE: fast-reroute merging > > > > > > Shahram, > > > > Section 5.3.1 says that the MP selects the shorter ERO path > > length. This may not be correct. > > > > If there are other routers between I and E, then the ERO > > lenght of the detour from C could be more than the ERO lenght > > of the detour from B. If you go by the rule, then H will > > merge the detours from B & C and establish a detour to D. > > Then the detour from C will not avoid its next-hop D. So > > there won't be a detour from C. > > > > So the MP has to select the detour which merges with the main > > LSP that is closer to the egress router. > > > > -sundara > > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, August 12, 2002 10:57 AM > > To: Sundara Murugan; mpls@UU.net > > Subject: RE: fast-reroute merging > > > > > > Sundara, > > > > This is exactly the same question that I asked in another email: > > > > "Since as stated in section 7, each PLR has option to apply > > its own constraints, then each PLR may reach to a different > > backup-path ERO for the same flow. Assuming that the EROs > > have a single link (the downstream link of an MP LSP) in > > common, isn't it wrong for an MP LSR to merge those Path messages?" > > > > > > I think the solution is to require the same ERO for merging. > > > > Yours, > > -Shahram > > > > > > > > > > > -----Original Message----- > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > Sent: Monday, August 12, 2002 1:36 PM > > > To: mpls@UU.net > > > Subject: fast-reroute merging > > > > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > explains merging procedure. In the fig below if there is a > > > link between I and F then D will have a detour D-I-F. In this > > > case how router I (the MP) handles detour LSPs from B, C and D? > > > > > > -sundara > > > > > > ------ > > > > > > 5.3.1. An Example on Path Message Merging > > > > > > Consider the following example: > > > > > > > > > G----H----I--\ > > > | | | \ > > > A----B----C----D----E---F > > > > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > > the detour > > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > > C-H-I-E-F. > > > > > > H will receive Path messages that have the same SESSION and > > > > > > > > > > > From owner-mpls@UU.NET Mon Aug 12 17:36: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 RAA12191 for ; Mon, 12 Aug 2002 17:36:55 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbqk09994 for ; Mon, 12 Aug 2002 21:38: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 QQnbqk08108; Mon, 12 Aug 2002 21:37:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbqk16926 for mpls-outgoing; Mon, 12 Aug 2002 21:36: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 QQnbqk16921 for ; Mon, 12 Aug 2002 21:36:32 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 QQnbqk00862 for ; Mon, 12 Aug 2002 21:36: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 QQnbqk21570 for ; Mon, 12 Aug 2002 21:36:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbqk21561 for ; Mon, 12 Aug 2002 21:36:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20421 for ; Mon, 12 Aug 2002 17:36:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA13243 for mpls@uu.net; Mon, 12 Aug 2002 17:36:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbqk16666 for ; Mon, 12 Aug 2002 21:35: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 QQnbqk18153 for ; Mon, 12 Aug 2002 21:34:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbqk06414 for ; Mon, 12 Aug 2002 21:34: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 QQnbqk06402 for ; Mon, 12 Aug 2002 21:34:10 GMT Received: (qmail 16874 invoked by uid 104); 12 Aug 2002 21:34:09 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.656438 secs); 12 Aug 2002 21:34:09 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 12 Aug 2002 21:34:08 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g7CLY3w01990; Mon, 12 Aug 2002 14:34:03 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 14:34:23 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037F7@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Alia Atlas'" , Sundara Murugan Cc: "mpls@UU.net" Subject: RE: fast-reroute merging Date: Mon, 12 Aug 2002 14:33:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Alia, Sundara and I also presented a number of other problems with "path-specific method". Having so many problems, I am wondering why do we have it in the first place? Why not have the Sender_template only? -Shahram > -----Original Message----- > From: Alia Atlas [mailto:aatlas@avici.com] > Sent: Monday, August 12, 2002 4:24 PM > To: Sundara Murugan > Cc: Shahram Davari; mpls@UU.net > Subject: RE: fast-reroute merging > > > The idea of merging detour Path messages with different EROs > but the same > egress interface is based upon the "path-specific method". With that > method, it is required because there is no way to determine > from the RESV > which of the two (or more) detour Path messages the RESV > belonged to. This > is because both detour Path messages have the same > SENDER_TEMPLATE; the > Path messages can be distinguished by the Detour object and the EROs. > > However, doing such merging has very bad consequences. > First, there are > cases where a detour LSP which was up is temporarily > unavailable. Second, > it is not possible to guarantee protection against an SRLG failure. > > The solution is to use the "sender-template-specific" method, > where the > sender address in the SENDER_TEMPLATE is set to an address > belonging to the > PLR instead of being left as an address belonging to the ingress. > > I presented about the problems of merging Path messages with > different EROs > in Salt Lake City. The draft I did then, > draft-atlas-rsvp-local-protect-interop-02.txt, describes the > issues in > detail; it has expired, because the solution was incorporated > into the > merged fast-reroute draft. > > Alia > > > At 12:02 PM 8/12/2002 -0700, Sundara Murugan wrote: > >Shahram, > > > >Let us assume that detours from B and C don't merge at H. > But these two > >LSPs share the same link between H-I. The at I there will be > 2 detour LSP > >(B to D and another from C to E). > > > >If the detour LSPs use SE filter, then the RESV message from > I to H can > >specify only one filter (Session + sender of all the detours > will be the > >same) and only one Label. Which label does I select? > > > >-sundara > > > >-----Original Message----- > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >Sent: Monday, August 12, 2002 11:45 AM > >To: Sundara Murugan; mpls@UU.net > >Subject: RE: fast-reroute merging > > > > > >Sundara, > > > >I think the shortest ERO is only a suggested example. and > not a standard rule. > > > > > > > > G----H----I--\ > > | | | \ > > A----B----C----D----E---F > > > > > >I think no merging should happen in the G, H and I LSRs. The > reason is that > >may be B has calculated the route B-G-H-I-D-E-F assuming some BW > >restrictions, etc. > >We don't want H to change that to B-G-H-I-E-F. > > > >Also since each PLR does an independent ERO calculation, it > is quite possible > >for C to compute computes the path as being > C-H-I-D-J-K-M-N-... Clearly > >C's detour should > >not be merged with B's detour here. > > > >If we have rule changed to "for merging the path messages > should have the > >same ERO", > >then we won't have such a problem. > > > > > >-Shahram > > > > > -----Original Message----- > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > Sent: Monday, August 12, 2002 2:22 PM > > > To: Shahram Davari; mpls@UU.net > > > Subject: RE: fast-reroute merging > > > > > > > > > Shahram, > > > > > > Section 5.3.1 says that the MP selects the shorter ERO path > > > length. This may not be correct. > > > > > > If there are other routers between I and E, then the ERO > > > lenght of the detour from C could be more than the ERO lenght > > > of the detour from B. If you go by the rule, then H will > > > merge the detours from B & C and establish a detour to D. > > > Then the detour from C will not avoid its next-hop D. So > > > there won't be a detour from C. > > > > > > So the MP has to select the detour which merges with the main > > > LSP that is closer to the egress router. > > > > > > -sundara > > > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Monday, August 12, 2002 10:57 AM > > > To: Sundara Murugan; mpls@UU.net > > > Subject: RE: fast-reroute merging > > > > > > > > > Sundara, > > > > > > This is exactly the same question that I asked in another email: > > > > > > "Since as stated in section 7, each PLR has option to apply > > > its own constraints, then each PLR may reach to a different > > > backup-path ERO for the same flow. Assuming that the EROs > > > have a single link (the downstream link of an MP LSP) in > > > common, isn't it wrong for an MP LSR to merge those Path > messages?" > > > > > > > > > I think the solution is to require the same ERO for merging. > > > > > > Yours, > > > -Shahram > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > Sent: Monday, August 12, 2002 1:36 PM > > > > To: mpls@UU.net > > > > Subject: fast-reroute merging > > > > > > > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > > explains merging procedure. In the fig below if there is a > > > > link between I and F then D will have a detour D-I-F. In this > > > > case how router I (the MP) handles detour LSPs from B, C and D? > > > > > > > > -sundara > > > > > > > > ------ > > > > > > > > 5.3.1. An Example on Path Message Merging > > > > > > > > Consider the following example: > > > > > > > > > > > > G----H----I--\ > > > > | | | \ > > > > A----B----C----D----E---F > > > > > > > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > > > the detour > > > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > > > C-H-I-E-F. > > > > > > > > H will receive Path messages that have the same SESSION and > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Aug 13 10:15: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 KAA13188 for ; Tue, 13 Aug 2002 10:15:43 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbsz03161 for ; Tue, 13 Aug 2002 14:16: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 QQnbsz01424; Tue, 13 Aug 2002 14:16:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbsz01026 for mpls-outgoing; Tue, 13 Aug 2002 14:15: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 QQnbsz01018 for ; Tue, 13 Aug 2002 14:15:37 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 QQnbsy10422 for ; Tue, 13 Aug 2002 14:14: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 QQnbsy09736 for ; Tue, 13 Aug 2002 14:14:06 GMT Received: from mlsrv1.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQnbsy09732 for ; Tue, 13 Aug 2002 14:14:06 GMT Received: from aatlas-lt.avici.com (b2-pc58.avici.com [10.2.100.78]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g7DEDv005770; Tue, 13 Aug 2002 10:13:57 -0400 (EDT) Message-Id: <5.1.0.14.2.20020813101218.01f7f458@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 Aug 2002 10:14:12 -0400 To: Shahram Davari From: Alia Atlas Subject: RE: fast-reroute merging Cc: Sundara Murugan , "mpls@UU.net" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB037F7@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 Shahram, I do not believe that the "path-specific method" is a good solution. Unfortunately, it is one of the methods which is currently available. Alia At 02:33 PM 8/12/2002 -0700, Shahram Davari wrote: >Alia, > >Sundara and I also presented a number of other problems with >"path-specific method". >Having so many problems, I am wondering why do we have it in the first place? >Why not have the Sender_template only? > >-Shahram > > > > > > -----Original Message----- > > From: Alia Atlas [mailto:aatlas@avici.com] > > Sent: Monday, August 12, 2002 4:24 PM > > To: Sundara Murugan > > Cc: Shahram Davari; mpls@UU.net > > Subject: RE: fast-reroute merging > > > > > > The idea of merging detour Path messages with different EROs > > but the same > > egress interface is based upon the "path-specific method". With that > > method, it is required because there is no way to determine > > from the RESV > > which of the two (or more) detour Path messages the RESV > > belonged to. This > > is because both detour Path messages have the same > > SENDER_TEMPLATE; the > > Path messages can be distinguished by the Detour object and the EROs. > > > > However, doing such merging has very bad consequences. > > First, there are > > cases where a detour LSP which was up is temporarily > > unavailable. Second, > > it is not possible to guarantee protection against an SRLG failure. > > > > The solution is to use the "sender-template-specific" method, > > where the > > sender address in the SENDER_TEMPLATE is set to an address > > belonging to the > > PLR instead of being left as an address belonging to the ingress. > > > > I presented about the problems of merging Path messages with > > different EROs > > in Salt Lake City. The draft I did then, > > draft-atlas-rsvp-local-protect-interop-02.txt, describes the > > issues in > > detail; it has expired, because the solution was incorporated > > into the > > merged fast-reroute draft. > > > > Alia > > > > > > At 12:02 PM 8/12/2002 -0700, Sundara Murugan wrote: > > >Shahram, > > > > > >Let us assume that detours from B and C don't merge at H. > > But these two > > >LSPs share the same link between H-I. The at I there will be > > 2 detour LSP > > >(B to D and another from C to E). > > > > > >If the detour LSPs use SE filter, then the RESV message from > > I to H can > > >specify only one filter (Session + sender of all the detours > > will be the > > >same) and only one Label. Which label does I select? > > > > > >-sundara > > > > > >-----Original Message----- > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > >Sent: Monday, August 12, 2002 11:45 AM > > >To: Sundara Murugan; mpls@UU.net > > >Subject: RE: fast-reroute merging > > > > > > > > >Sundara, > > > > > >I think the shortest ERO is only a suggested example. and > > not a standard rule. > > > > > > > > > > > > G----H----I--\ > > > | | | \ > > > A----B----C----D----E---F > > > > > > > > >I think no merging should happen in the G, H and I LSRs. The > > reason is that > > >may be B has calculated the route B-G-H-I-D-E-F assuming some BW > > >restrictions, etc. > > >We don't want H to change that to B-G-H-I-E-F. > > > > > >Also since each PLR does an independent ERO calculation, it > > is quite possible > > >for C to compute computes the path as being > > C-H-I-D-J-K-M-N-... Clearly > > >C's detour should > > >not be merged with B's detour here. > > > > > >If we have rule changed to "for merging the path messages > > should have the > > >same ERO", > > >then we won't have such a problem. > > > > > > > > >-Shahram > > > > > > > -----Original Message----- > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > Sent: Monday, August 12, 2002 2:22 PM > > > > To: Shahram Davari; mpls@UU.net > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > Shahram, > > > > > > > > Section 5.3.1 says that the MP selects the shorter ERO path > > > > length. This may not be correct. > > > > > > > > If there are other routers between I and E, then the ERO > > > > lenght of the detour from C could be more than the ERO lenght > > > > of the detour from B. If you go by the rule, then H will > > > > merge the detours from B & C and establish a detour to D. > > > > Then the detour from C will not avoid its next-hop D. So > > > > there won't be a detour from C. > > > > > > > > So the MP has to select the detour which merges with the main > > > > LSP that is closer to the egress router. > > > > > > > > -sundara > > > > > > > > > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Monday, August 12, 2002 10:57 AM > > > > To: Sundara Murugan; mpls@UU.net > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > Sundara, > > > > > > > > This is exactly the same question that I asked in another email: > > > > > > > > "Since as stated in section 7, each PLR has option to apply > > > > its own constraints, then each PLR may reach to a different > > > > backup-path ERO for the same flow. Assuming that the EROs > > > > have a single link (the downstream link of an MP LSP) in > > > > common, isn't it wrong for an MP LSR to merge those Path > > messages?" > > > > > > > > > > > > I think the solution is to require the same ERO for merging. > > > > > > > > Yours, > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > > Sent: Monday, August 12, 2002 1:36 PM > > > > > To: mpls@UU.net > > > > > Subject: fast-reroute merging > > > > > > > > > > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > > > explains merging procedure. In the fig below if there is a > > > > > link between I and F then D will have a detour D-I-F. In this > > > > > case how router I (the MP) handles detour LSPs from B, C and D? > > > > > > > > > > -sundara > > > > > > > > > > ------ > > > > > > > > > > 5.3.1. An Example on Path Message Merging > > > > > > > > > > Consider the following example: > > > > > > > > > > > > > > > G----H----I--\ > > > > > | | | \ > > > > > A----B----C----D----E---F > > > > > > > > > > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > > > > the detour > > > > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > > > > C-H-I-E-F. > > > > > > > > > > H will receive Path messages that have the same SESSION and > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Aug 13 10:23: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 KAA13490 for ; Tue, 13 Aug 2002 10:23:40 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbsz16014 for ; Tue, 13 Aug 2002 14:24: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 QQnbsz14745; Tue, 13 Aug 2002 14:24:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbsz01494 for mpls-outgoing; Tue, 13 Aug 2002 14:23: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 QQnbsz01489 for ; Tue, 13 Aug 2002 14:23:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnbsz09297 for ; Tue, 13 Aug 2002 14:23: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 QQnbsz14293 for ; Tue, 13 Aug 2002 14:23:27 GMT Received: from mlsrv1.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQnbsz14283 for ; Tue, 13 Aug 2002 14:23:27 GMT Received: from aatlas-lt.avici.com (b2-pc58.avici.com [10.2.100.78]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g7DENL006759; Tue, 13 Aug 2002 10:23:21 -0400 (EDT) Message-Id: <5.1.0.14.2.20020813101911.01f7a5a0@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 Aug 2002 10:23:36 -0400 To: Shahram Davari From: Alia Atlas Subject: RE: fast-reroute merging Cc: Sundara Murugan , "mpls@UU.net" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB037F8@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 Shahram, It has been implemented. Certainly, I am not an advocate of this method. The draft was done to merge the existing methods into something which could inter-operate; this is one of those methods. I think it is more critical to clean up the draft and clarify the behavior than to, at this point, try to remove options which have been implemented. Alia At 07:16 AM 8/13/2002 -0700, Shahram Davari wrote: >Alia, > >What do you mean by "is currently available" ? >Why can't the WG remove it from the draft? > >-Shahram > > > -----Original Message----- > > From: Alia Atlas [mailto:aatlas@avici.com] > > Sent: Tuesday, August 13, 2002 10:14 AM > > To: Shahram Davari > > Cc: Sundara Murugan; mpls@UU.net > > Subject: RE: fast-reroute merging > > > > > > Shahram, > > > > I do not believe that the "path-specific method" is a good > > solution. Unfortunately, it is one of the methods which is currently > > available. > > > > Alia > > > > At 02:33 PM 8/12/2002 -0700, Shahram Davari wrote: > > >Alia, > > > > > >Sundara and I also presented a number of other problems with > > >"path-specific method". > > >Having so many problems, I am wondering why do we have it in > > the first place? > > >Why not have the Sender_template only? > > > > > >-Shahram > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Alia Atlas [mailto:aatlas@avici.com] > > > > Sent: Monday, August 12, 2002 4:24 PM > > > > To: Sundara Murugan > > > > Cc: Shahram Davari; mpls@UU.net > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > The idea of merging detour Path messages with different EROs > > > > but the same > > > > egress interface is based upon the "path-specific > > method". With that > > > > method, it is required because there is no way to determine > > > > from the RESV > > > > which of the two (or more) detour Path messages the RESV > > > > belonged to. This > > > > is because both detour Path messages have the same > > > > SENDER_TEMPLATE; the > > > > Path messages can be distinguished by the Detour object > > and the EROs. > > > > > > > > However, doing such merging has very bad consequences. > > > > First, there are > > > > cases where a detour LSP which was up is temporarily > > > > unavailable. Second, > > > > it is not possible to guarantee protection against an > > SRLG failure. > > > > > > > > The solution is to use the "sender-template-specific" method, > > > > where the > > > > sender address in the SENDER_TEMPLATE is set to an address > > > > belonging to the > > > > PLR instead of being left as an address belonging to the ingress. > > > > > > > > I presented about the problems of merging Path messages with > > > > different EROs > > > > in Salt Lake City. The draft I did then, > > > > draft-atlas-rsvp-local-protect-interop-02.txt, describes the > > > > issues in > > > > detail; it has expired, because the solution was incorporated > > > > into the > > > > merged fast-reroute draft. > > > > > > > > Alia > > > > > > > > > > > > At 12:02 PM 8/12/2002 -0700, Sundara Murugan wrote: > > > > >Shahram, > > > > > > > > > >Let us assume that detours from B and C don't merge at H. > > > > But these two > > > > >LSPs share the same link between H-I. The at I there will be > > > > 2 detour LSP > > > > >(B to D and another from C to E). > > > > > > > > > >If the detour LSPs use SE filter, then the RESV message from > > > > I to H can > > > > >specify only one filter (Session + sender of all the detours > > > > will be the > > > > >same) and only one Label. Which label does I select? > > > > > > > > > >-sundara > > > > > > > > > >-----Original Message----- > > > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > >Sent: Monday, August 12, 2002 11:45 AM > > > > >To: Sundara Murugan; mpls@UU.net > > > > >Subject: RE: fast-reroute merging > > > > > > > > > > > > > > >Sundara, > > > > > > > > > >I think the shortest ERO is only a suggested example. and > > > > not a standard rule. > > > > > > > > > > > > > > > > > > > > G----H----I--\ > > > > > | | | \ > > > > > A----B----C----D----E---F > > > > > > > > > > > > > > >I think no merging should happen in the G, H and I LSRs. The > > > > reason is that > > > > >may be B has calculated the route B-G-H-I-D-E-F assuming some BW > > > > >restrictions, etc. > > > > >We don't want H to change that to B-G-H-I-E-F. > > > > > > > > > >Also since each PLR does an independent ERO calculation, it > > > > is quite possible > > > > >for C to compute computes the path as being > > > > C-H-I-D-J-K-M-N-... Clearly > > > > >C's detour should > > > > >not be merged with B's detour here. > > > > > > > > > >If we have rule changed to "for merging the path messages > > > > should have the > > > > >same ERO", > > > > >then we won't have such a problem. > > > > > > > > > > > > > > >-Shahram > > > > > > > > > > > -----Original Message----- > > > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > > > Sent: Monday, August 12, 2002 2:22 PM > > > > > > To: Shahram Davari; mpls@UU.net > > > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > > > Section 5.3.1 says that the MP selects the shorter ERO path > > > > > > length. This may not be correct. > > > > > > > > > > > > If there are other routers between I and E, then the ERO > > > > > > lenght of the detour from C could be more than the ERO lenght > > > > > > of the detour from B. If you go by the rule, then H will > > > > > > merge the detours from B & C and establish a detour to D. > > > > > > Then the detour from C will not avoid its next-hop D. So > > > > > > there won't be a detour from C. > > > > > > > > > > > > So the MP has to select the detour which merges with the main > > > > > > LSP that is closer to the egress router. > > > > > > > > > > > > -sundara > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > Sent: Monday, August 12, 2002 10:57 AM > > > > > > To: Sundara Murugan; mpls@UU.net > > > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > > > > > > > Sundara, > > > > > > > > > > > > This is exactly the same question that I asked in > > another email: > > > > > > > > > > > > "Since as stated in section 7, each PLR has option to apply > > > > > > its own constraints, then each PLR may reach to a different > > > > > > backup-path ERO for the same flow. Assuming that the EROs > > > > > > have a single link (the downstream link of an MP LSP) in > > > > > > common, isn't it wrong for an MP LSR to merge those Path > > > > messages?" > > > > > > > > > > > > > > > > > > I think the solution is to require the same ERO for merging. > > > > > > > > > > > > Yours, > > > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > > > > Sent: Monday, August 12, 2002 1:36 PM > > > > > > > To: mpls@UU.net > > > > > > > Subject: fast-reroute merging > > > > > > > > > > > > > > > > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > > > > > explains merging procedure. In the fig below if there is a > > > > > > > link between I and F then D will have a detour > > D-I-F. In this > > > > > > > case how router I (the MP) handles detour LSPs from > > B, C and D? > > > > > > > > > > > > > > -sundara > > > > > > > > > > > > > > ------ > > > > > > > > > > > > > > 5.3.1. An Example on Path Message Merging > > > > > > > > > > > > > > Consider the following example: > > > > > > > > > > > > > > > > > > > > > G----H----I--\ > > > > > > > | | | \ > > > > > > > A----B----C----D----E---F > > > > > > > > > > > > > > > > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > > > > > > the detour > > > > > > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > > > > > > C-H-I-E-F. > > > > > > > > > > > > > > H will receive Path messages that have the same > > SESSION and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Aug 13 10:48: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 KAA14620 for ; Tue, 13 Aug 2002 10:48:27 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbtb28275 for ; Tue, 13 Aug 2002 14:49: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 QQnbtb25633; Tue, 13 Aug 2002 14:48:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbtb03287 for mpls-outgoing; Tue, 13 Aug 2002 14:47:30 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 QQnbtb03282 for ; Tue, 13 Aug 2002 14:47: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 QQnbtb09153 for ; Tue, 13 Aug 2002 14:47: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 QQnbtb03918 for ; Tue, 13 Aug 2002 14:47:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbtb03914 for ; Tue, 13 Aug 2002 14:47:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA09944 for ; Tue, 13 Aug 2002 10:47:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA25103 for mpls@uu.net; Tue, 13 Aug 2002 10:47:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnbtb03107 for ; Tue, 13 Aug 2002 14:46:02 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 QQnbta21854 for ; Tue, 13 Aug 2002 14:44: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 QQnbta11961 for ; Tue, 13 Aug 2002 14:44:29 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 QQnbta11957 for ; Tue, 13 Aug 2002 14:44:28 GMT Received: (qmail 8993 invoked by uid 104); 13 Aug 2002 14:44:28 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.634201 secs); 13 Aug 2002 14:44:28 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 13 Aug 2002 14:44: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 g7DEiRw29313; Tue, 13 Aug 2002 07:44:27 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 07:44:49 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037F9@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Alia Atlas'" Cc: Sundara Murugan , "mpls@UU.net" Subject: RE: fast-reroute merging Date: Tue, 13 Aug 2002 07:44:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Alia, Why should the WG standardize a broken implemented behavior? Being implemented is important, but when it has problems .... -Shahram > -----Original Message----- > From: Alia Atlas [mailto:aatlas@avici.com] > Sent: Tuesday, August 13, 2002 10:24 AM > To: Shahram Davari > Cc: Sundara Murugan; mpls@UU.net > Subject: RE: fast-reroute merging > > > Shahram, > > It has been implemented. Certainly, I am not an advocate of this > method. The draft was done to merge the existing methods > into something > which could inter-operate; this is one of those methods. I > think it is > more critical to clean up the draft and clarify the behavior > than to, at > this point, try to remove options which have been implemented. > > Alia > > At 07:16 AM 8/13/2002 -0700, Shahram Davari wrote: > >Alia, > > > >What do you mean by "is currently available" ? > >Why can't the WG remove it from the draft? > > > >-Shahram > > > > > -----Original Message----- > > > From: Alia Atlas [mailto:aatlas@avici.com] > > > Sent: Tuesday, August 13, 2002 10:14 AM > > > To: Shahram Davari > > > Cc: Sundara Murugan; mpls@UU.net > > > Subject: RE: fast-reroute merging > > > > > > > > > Shahram, > > > > > > I do not believe that the "path-specific method" is a good > > > solution. Unfortunately, it is one of the methods which > is currently > > > available. > > > > > > Alia > > > > > > At 02:33 PM 8/12/2002 -0700, Shahram Davari wrote: > > > >Alia, > > > > > > > >Sundara and I also presented a number of other problems with > > > >"path-specific method". > > > >Having so many problems, I am wondering why do we have it in > > > the first place? > > > >Why not have the Sender_template only? > > > > > > > >-Shahram > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alia Atlas [mailto:aatlas@avici.com] > > > > > Sent: Monday, August 12, 2002 4:24 PM > > > > > To: Sundara Murugan > > > > > Cc: Shahram Davari; mpls@UU.net > > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > > > > The idea of merging detour Path messages with different EROs > > > > > but the same > > > > > egress interface is based upon the "path-specific > > > method". With that > > > > > method, it is required because there is no way to determine > > > > > from the RESV > > > > > which of the two (or more) detour Path messages the RESV > > > > > belonged to. This > > > > > is because both detour Path messages have the same > > > > > SENDER_TEMPLATE; the > > > > > Path messages can be distinguished by the Detour object > > > and the EROs. > > > > > > > > > > However, doing such merging has very bad consequences. > > > > > First, there are > > > > > cases where a detour LSP which was up is temporarily > > > > > unavailable. Second, > > > > > it is not possible to guarantee protection against an > > > SRLG failure. > > > > > > > > > > The solution is to use the "sender-template-specific" method, > > > > > where the > > > > > sender address in the SENDER_TEMPLATE is set to an address > > > > > belonging to the > > > > > PLR instead of being left as an address belonging to > the ingress. > > > > > > > > > > I presented about the problems of merging Path messages with > > > > > different EROs > > > > > in Salt Lake City. The draft I did then, > > > > > draft-atlas-rsvp-local-protect-interop-02.txt, describes the > > > > > issues in > > > > > detail; it has expired, because the solution was incorporated > > > > > into the > > > > > merged fast-reroute draft. > > > > > > > > > > Alia > > > > > > > > > > > > > > > At 12:02 PM 8/12/2002 -0700, Sundara Murugan wrote: > > > > > >Shahram, > > > > > > > > > > > >Let us assume that detours from B and C don't merge at H. > > > > > But these two > > > > > >LSPs share the same link between H-I. The at I there will be > > > > > 2 detour LSP > > > > > >(B to D and another from C to E). > > > > > > > > > > > >If the detour LSPs use SE filter, then the RESV message from > > > > > I to H can > > > > > >specify only one filter (Session + sender of all the detours > > > > > will be the > > > > > >same) and only one Label. Which label does I select? > > > > > > > > > > > >-sundara > > > > > > > > > > > >-----Original Message----- > > > > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > >Sent: Monday, August 12, 2002 11:45 AM > > > > > >To: Sundara Murugan; mpls@UU.net > > > > > >Subject: RE: fast-reroute merging > > > > > > > > > > > > > > > > > >Sundara, > > > > > > > > > > > >I think the shortest ERO is only a suggested example. and > > > > > not a standard rule. > > > > > > > > > > > > > > > > > > > > > > > > G----H----I--\ > > > > > > | | | \ > > > > > > A----B----C----D----E---F > > > > > > > > > > > > > > > > > >I think no merging should happen in the G, H and I LSRs. The > > > > > reason is that > > > > > >may be B has calculated the route B-G-H-I-D-E-F > assuming some BW > > > > > >restrictions, etc. > > > > > >We don't want H to change that to B-G-H-I-E-F. > > > > > > > > > > > >Also since each PLR does an independent ERO calculation, it > > > > > is quite possible > > > > > >for C to compute computes the path as being > > > > > C-H-I-D-J-K-M-N-... Clearly > > > > > >C's detour should > > > > > >not be merged with B's detour here. > > > > > > > > > > > >If we have rule changed to "for merging the path messages > > > > > should have the > > > > > >same ERO", > > > > > >then we won't have such a problem. > > > > > > > > > > > > > > > > > >-Shahram > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > > > > Sent: Monday, August 12, 2002 2:22 PM > > > > > > > To: Shahram Davari; mpls@UU.net > > > > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > > > > > Section 5.3.1 says that the MP selects the > shorter ERO path > > > > > > > length. This may not be correct. > > > > > > > > > > > > > > If there are other routers between I and E, then the ERO > > > > > > > lenght of the detour from C could be more than > the ERO lenght > > > > > > > of the detour from B. If you go by the rule, then H will > > > > > > > merge the detours from B & C and establish a detour to D. > > > > > > > Then the detour from C will not avoid its next-hop D. So > > > > > > > there won't be a detour from C. > > > > > > > > > > > > > > So the MP has to select the detour which merges > with the main > > > > > > > LSP that is closer to the egress router. > > > > > > > > > > > > > > -sundara > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Shahram Davari > [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > > Sent: Monday, August 12, 2002 10:57 AM > > > > > > > To: Sundara Murugan; mpls@UU.net > > > > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > > > > > > > > > > Sundara, > > > > > > > > > > > > > > This is exactly the same question that I asked in > > > another email: > > > > > > > > > > > > > > "Since as stated in section 7, each PLR has > option to apply > > > > > > > its own constraints, then each PLR may reach to > a different > > > > > > > backup-path ERO for the same flow. Assuming that the EROs > > > > > > > have a single link (the downstream link of an MP LSP) in > > > > > > > common, isn't it wrong for an MP LSR to merge those Path > > > > > messages?" > > > > > > > > > > > > > > > > > > > > > I think the solution is to require the same ERO > for merging. > > > > > > > > > > > > > > Yours, > > > > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > > > > Sent: Monday, August 12, 2002 1:36 PM > > > > > > > To: mpls@UU.net > > > > > > > Subject: fast-reroute merging > > > > > > > > > > > > > > > > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > > > > > explains merging procedure. In the fig below if there is a > > > > > > > link between I and F then D will have a detour > > D-I-F. In this > > > > > > > case how router I (the MP) handles detour LSPs from > > B, C and D? > > > > > > > > > > > > > > -sundara > > > > > > > > > > > > > > ------ > > > > > > > > > > > > > > 5.3.1. An Example on Path Message Merging > > > > > > > > > > > > > > Consider the following example: > > > > > > > > > > > > > > > > > > > > > G----H----I--\ > > > > > > > | | | \ > > > > > > > A----B----C----D----E---F > > > > > > > > > > > > > > > > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > > > > > > the detour > > > > > > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > > > > > > C-H-I-E-F. > > > > > > > > > > > > > > H will receive Path messages that have the same > > SESSION and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Aug 13 11:21: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 LAA15968 for ; Tue, 13 Aug 2002 11:21:46 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbtd23540 for ; Tue, 13 Aug 2002 15:22: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 QQnbtd21337; Tue, 13 Aug 2002 15:21:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbtd29476 for mpls-outgoing; Tue, 13 Aug 2002 15:21:30 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 QQnbtd29465 for ; Tue, 13 Aug 2002 15:21: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 QQnbtd29988 for ; Tue, 13 Aug 2002 15:18: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 QQnbtd28327 for ; Tue, 13 Aug 2002 15:18:53 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnbtd28273 for ; Tue, 13 Aug 2002 15:18:52 GMT Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by blooper.utfors.se (Utfors AB) with ESMTP id g7DFIR5F006647; Tue, 13 Aug 2002 17:18:27 +0200 (MEST) Message-ID: <3D592341.4010409@utfors.se> Date: Tue, 13 Aug 2002 17:18:25 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: MPLS wg CC: George Swallow , Loa Andersson , Bob Thomas , Scott Bradner Subject: LDP to Draft Standard - implementation survey Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit LDP to Draft Standard As protocols gets implemented and deployed, there is an IETF process to take them further on the standrads track. LDP is a protocol that has been both widely implemented and deployed, we will therefore start the process to progress LDP to Draft Standard. Included is an "LDP Implemenation Survey Form", it specifies in some detail the information needed to take this step. We ask companies and other organizations that have implemented LDP to take the time and answer the questions. The result of the survey will be made available as an Internet Draft, the time schedule depends very much on that we have the responses in a timely fashion. Send the response to the Bob Thomas, who will act as Internet Draft editor for the resulting summary document: rhthomas@cisco.com with a Cc to the wg chairs and the mpls list: loa.andersson@utfors.se swallow@cisco.com mpls@uu.net Earlier experiences with this kind of survey indicates that there are always a few that likes to respond anonymously, if you want to do that send the response to our AD, Scott Bradner: sob@harvard.edu We want to stress the importance of getting the highest possible number of responses, since it is important to create a protocol specification of highest possible quality. If there are further questions contact the wg chairs. Loa and George ===================================================================== LDP Implementation Survey Form [V 1.0] The purpose of this form is to gather information about implementations of LDP as defined by RFC3036. The information is being requested as part of the process of advancing LDP from Proposed to Draft Standard. The form is patterned after the implementation report form used for HTTP/1.1; see: http://www.ietf.org/IESG/Implementations/http1.1-implementations.txt ======================================================================= A. General information. Please provide the following information. ---------------------------------------------------------------- Organization: Organization url(s): ---------------------------------------------------------------- Product title(s): Brief description(s): ---------------------------------------------------------------- Contact for LDP information Name: Title: E-mail: Organization/department: Postal address: Phone: Fax: ======================================================================= B. LDP Implementation Status, Availability, Origin Please check [x] the boxes that apply. ---------------------------------------------------------------- Status: [ ] Development [ ] Alpha [ ] Beta [ ] Product [ ] Other (describe): Availability [ ] Public and free [ ] Only to selected organizations/companies but free [ ] On sale. [ ] For internal company use only [ ] Other: Implementation based on: (check all that apply) [ ] Purchased code (please list source if possible) [ ] Free code (please list source if possible) [ ] Internal implementation (no outside code, just from specs) [ ] Internal implementation on top of purchased or free code List portions from external source: List portions developed internally: ======================================================================= C. LDP Feature Survey. For each features listed, please indicate the Status of the implementation using one of the following: 't' tested against another independent implementation 'y' implemented but not tested against independent implementation 'n' not implemented '-' not applicable to this type of implementation Optional: For 'n' status, indicate reason not implemented using one of the following: 's' RFC specification inadequate, unclear, or confusing 'u' utility of feature unclear 'r' feature not required for feature set implemented ------------------+-----------------------------+------------------------- | | Status (one of t, y, n - | | If n, optionally one of Feature | RFC3036 Section(s) | s, u, r) ==================+=============================+========================= Interface types | 2.2.1, 2.5.3, 2.8.2, 3,4,2 ----------------+-----------------------------+------------------------- Packet | | ----------------+-----------------------------+------------------------- Frame Relay | | ----------------+-----------------------------+------------------------- ATM | | ==================+=============================+========================= Label Spaces | 2.2.1, 2.2.2 ----------------+-----------------------------+------------------------- Per platform | | ----------------+-----------------------------+------------------------- Per interface | | ==================+=============================+========================= LDP Discovery | 2.4 ----------------+-----------------------------+------------------------- Basic | 2.4.1 | ----------------+-----------------------------+------------------------- Targeted | 2.4.2 | ------------------+-----------------------------+------------------------- LDP Sessions | 2.2.3 ----------------+-----------------------------+------------------------- Directly | -- | Connected | | ----------------+-----------------------------+------------------------- Targeted | 2.3 | ==================+=============================+========================= LDP Modes | 2.6 ----------------+-----------------------------+------------------------- DU, Ind cntl, | 2.6 | Lib retention | | ----------------+-----------------------------+------------------------- DU, Ord cntl, | 2.6 | Lib retention | | ----------------+-----------------------------+------------------------- DU, Ind cntl, | 2.6 | Cons retention | | ----------------+-----------------------------+------------------------- DU, Ord cntl, | 2.6 | Cons retention | | ----------------+-----------------------------+------------------------- DoD, Ind cntl, | 2.6 | Lib retention | | ----------------+-----------------------------+------------------------- DoD, Ord cntl, | 2.6 | Lib retention | | ----------------+-----------------------------+------------------------- DoD, Ind cntl, | 2.6 | Cons retention | | ----------------+-----------------------------+------------------------- DoD, Ord cntl, | 2.6 | Cons retention | | ==================+=============================+========================= Loop Detection | 2.8 | ==================+=============================+========================= TCP MD5 Option | 2.9 | ==================+=============================+========================= LDP TLVs | 3.3, 3.4, throughout ----------------+-----------------------------+------------------------- U-bit | 3.3 | ----------------+-----------------------------+------------------------- F-bit | 3.3 | ------------------+-----------------------------+------------------------- FEC | 1., 2.1, 3.4.1 | ----------------+-----------------------------+------------------------- Wildcard | 3.4.1 | ----------------+-----------------------------+------------------------- Prefix | 2.1, 3.4.1 | ----------------+-----------------------------+------------------------- Host | 2.1, 3.4.1 | ------------------+-----------------------------+------------------------- Address List | 3.4.3 | ------------------+-----------------------------+------------------------- Hop Count | 3.4.4 | ------------------+-----------------------------+------------------------- Path Vector | 3.4.5 | ------------------+-----------------------------+------------------------- Generic Label | 3.4.2.1 | ------------------+-----------------------------+------------------------- ATM Label | 3.4.2.2 | ------------------+-----------------------------+------------------------- Frame Relay | 3.4.2.3 | Label | | ------------------+-----------------------------+------------------------- Status | 3.4.6 | ------------------+-----------------------------+------------------------- Extended Status | 3.5.1 | ------------------+-----------------------------+------------------------- Returned PDU | 3.5.1 | ------------------+-----------------------------+------------------------- Returned Message| 3.5.1 | ------------------+-----------------------------+------------------------- Common Hello | 3.5.2 | Parameters | | ----------------+-----------------------------+------------------------- T-bit | 3.5.2 | ----------------+-----------------------------+------------------------- R-bit | 3.5.2 | ----------------+-----------------------------+------------------------- Hold Time | 3.5.2 | ------------------+-----------------------------+------------------------- IPv4 Transport | 3.5.2 | Address | | ------------------+-----------------------------+------------------------- Configuration | 3.5.2 | Sequence Number | | ------------------+-----------------------------+------------------------- IPv6 Transport | 3.5.2 | Address | | ------------------+-----------------------------+------------------------- Common Session | 3.5.3 | Parameters | | ----------------+-----------------------------+------------------------- KeepAlive Time| 3.5.3 | ----------------+-----------------------------+------------------------- PVLim | 3.5.3 | ----------------+-----------------------------+------------------------- Max PDU Length| 3.5.3 | ------------------+-----------------------------+------------------------- ATM Session | 3.5.3 | Parameters | | ----------------+-----------------------------+------------------------- M values | | 0 No Merge | 3.5.3 | ------------+-----------------------------+------------------------- 1 VP Merge | 3.5.3 | ------------+-----------------------------+------------------------- 2 VC Merge | 3.5.3 | ------------+-----------------------------+------------------------- 3 VP & | 3.5.3 | VC Merge | | ----------------+-----------------------------+------------------------- D-bit | 3.5.3 | ----------------+-----------------------------+------------------------- ATM Label | 3.5.3 | Range | | Component | | ------------------+-----------------------------+------------------------- Frame Relay | 3.5.3 | Session | | Parameters | | ------------------+-----------------------------+------------------------- M values | | 0 No Merge | 3.5.3 | ------------+-----------------------------+------------------------- 1 Merge | 3.5.3 | ----------------+-----------------------------+------------------------- D-bit | 3.5.3 | ----------------+-----------------------------+------------------------- Frame Relay | 3.5.3 | Label Range | | Component | | ----------------+-----------------------------+------------------------- Label Request | 3.5.7 | Message ID | | ------------------+-----------------------------+------------------------- Vendor-Private | 3.6.1.1 | ------------------+-----------------------------+------------------------- Experimental | 3.6.2 | ==================+=============================+========================= LDP Messages | 3.5, throughout ------------------+-----------------------------+------------------------- Notification | 3.5.1 | ------------------+-----------------------------+------------------------- Hello | 3.5.2 | ------------------+-----------------------------+------------------------- Initialization | 3.5.3 | ------------------+-----------------------------+------------------------- KeepAlive | 3.5.4 | ------------------+-----------------------------+------------------------- Address | 3.5.5 | ------------------+-----------------------------+------------------------- Address Withdraw| 3.5.6 | ------------------+-----------------------------+------------------------- Label Mapping | 3.5.7 | ----------------+-----------------------------+------------------------- Label Request | 3.5.7 | Message ID TLV| | ----------------+-----------------------------+------------------------- Hop Count TLV | 3.5.7 | ----------------+-----------------------------+------------------------- Path Vect TLV | 3.5.7 | ------------------+-----------------------------+------------------------- Label Request | 3.5.8 | ----------------+-----------------------------+------------------------- Hop Count TLV | 3.5.8 | ----------------+-----------------------------+------------------------- Path Vect TLV | 3.5.8 | ------------------+-----------------------------+------------------------- Label Withdraw | 3.5.10 | ----------------+-----------------------------+------------------------- Label TLV | 3.5.10 | ------------------+-----------------------------+------------------------- Label Release | 3.5.11 | ----------------+-----------------------------+------------------------- Label TLV | 3.5.11 | ------------------+-----------------------------+------------------------- Label Abort Req | 3.5.9 | ------------------+-----------------------------+------------------------- Vendor-Private | 3.6.1.2 | ------------------+-----------------------------+------------------------- Experimental | 3.6.2 | ==================+=============================+========================= LDP Status Codes | 3.4.6 ------------------+-----------------------------+------------------------- Success | 3.4.6, 3.9 | ------------------+-----------------------------+------------------------- Bad LDP Id | 3.5.1.2.1 | ------------------+-----------------------------+------------------------- Bad Ptcl Version| 3.5.1.2.1 | ------------------+-----------------------------+------------------------- Bad PDU Length | 3.5.1.2.1 | ------------------+-----------------------------+------------------------- Unknown Message | 3.5.1.2.1 | Type | | ------------------+-----------------------------+------------------------- Bad Message | 3.5.1.2.1 | Length | | ------------------+-----------------------------+------------------------- Unknown TLV | 3.5.1.2.2 | ------------------+-----------------------------+------------------------- Bad TLV length | 3.5.1.2.2 | ------------------+-----------------------------+------------------------- Malformed TLV | 3.5.1.2.2 | Value | | ------------------+-----------------------------+------------------------- Hold Timer | 3.5.1.2.3 | Expired | | ------------------+-----------------------------+------------------------- Shutdown | 3.5.1.2.4 | ------------------+-----------------------------+------------------------- Loop Detected | 3.4.5.1.2, 3.5.8.1 | ------------------+-----------------------------+------------------------- Unknown FEC | 3.4.1.1 | ------------------+-----------------------------+------------------------- No Route | 3.5.8.1 | ------------------+-----------------------------+------------------------- No Label | 3.5.8.1 | Resources | | ------------------+-----------------------------+------------------------- Label Resources | 3.5.8.1 | Available | | ------------------+-----------------------------+------------------------- Session Rejected| 2.5.3, 3.5.3 | No Hello | | ------------------+-----------------------------+------------------------- Session Rejected| 2.5.3, 3.5.3 | Parameters | | Advert Mode | | ------------------+-----------------------------+------------------------- Session Rejected| 2.5.3, 3.5.3 | Parameters | | Max PDU Length | | ------------------+-----------------------------+------------------------- Session Rejected| 2.5.3, 3.5.3 | Parameters | | Label Range | | ------------------+-----------------------------+------------------------- KeepAlive Timer | 2.5.6, 3.5.1.2.3 | Expired | | ------------------+-----------------------------+------------------------- Label Request | 3.5.9.1 | Aborted | | ------------------+-----------------------------+------------------------- Missing Message | 3.5.1.2.1 | Parameters | | ------------------+-----------------------------+------------------------- Unsupported | 3.4.1.1, 3.5.5.1 | Address Family | | ------------------+-----------------------------+------------------------- Session Rejected| 3.5.1.2.5, 3.5.3 | Bad KeepAlive | | Time | | ------------------+-----------------------------+------------------------- Internal Error | 3.5.1.2.7 | ==================+=============================+========================= -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Tue Aug 13 13:30: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 NAA06669 for ; Tue, 13 Aug 2002 13:30:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbtm09753 for ; Tue, 13 Aug 2002 17:32: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 QQnbtm07802; Tue, 13 Aug 2002 17:30:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbtm25057 for mpls-outgoing; Tue, 13 Aug 2002 17:30: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 QQnbtm25051 for ; Tue, 13 Aug 2002 17:30: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 QQnbtm26728 for ; Tue, 13 Aug 2002 17:30: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 QQnbtm08742 for ; Tue, 13 Aug 2002 17:30: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 QQnbtm08737 for ; Tue, 13 Aug 2002 17:30: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 NAA24690 for ; Tue, 13 Aug 2002 13:30:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA13237 for mpls@uu.net; Tue, 13 Aug 2002 13:30:07 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnbsz01272 for ; Tue, 13 Aug 2002 14:18: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 QQnbsz26428 for ; Tue, 13 Aug 2002 14:16: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 QQnbsz10801 for ; Tue, 13 Aug 2002 14:16:45 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 QQnbsz10797 for ; Tue, 13 Aug 2002 14:16:45 GMT Received: (qmail 28535 invoked by uid 104); 13 Aug 2002 14:16:44 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.534871 secs); 13 Aug 2002 14:16:44 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 13 Aug 2002 14:16:43 -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 g7DEGhw13292; Tue, 13 Aug 2002 07:16:43 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 07:17:06 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037F8@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Alia Atlas'" Cc: Sundara Murugan , "mpls@UU.net" Subject: RE: fast-reroute merging Date: Tue, 13 Aug 2002 07:16:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Alia, What do you mean by "is currently available" ? Why can't the WG remove it from the draft? -Shahram > -----Original Message----- > From: Alia Atlas [mailto:aatlas@avici.com] > Sent: Tuesday, August 13, 2002 10:14 AM > To: Shahram Davari > Cc: Sundara Murugan; mpls@UU.net > Subject: RE: fast-reroute merging > > > Shahram, > > I do not believe that the "path-specific method" is a good > solution. Unfortunately, it is one of the methods which is currently > available. > > Alia > > At 02:33 PM 8/12/2002 -0700, Shahram Davari wrote: > >Alia, > > > >Sundara and I also presented a number of other problems with > >"path-specific method". > >Having so many problems, I am wondering why do we have it in > the first place? > >Why not have the Sender_template only? > > > >-Shahram > > > > > > > > > > > -----Original Message----- > > > From: Alia Atlas [mailto:aatlas@avici.com] > > > Sent: Monday, August 12, 2002 4:24 PM > > > To: Sundara Murugan > > > Cc: Shahram Davari; mpls@UU.net > > > Subject: RE: fast-reroute merging > > > > > > > > > The idea of merging detour Path messages with different EROs > > > but the same > > > egress interface is based upon the "path-specific > method". With that > > > method, it is required because there is no way to determine > > > from the RESV > > > which of the two (or more) detour Path messages the RESV > > > belonged to. This > > > is because both detour Path messages have the same > > > SENDER_TEMPLATE; the > > > Path messages can be distinguished by the Detour object > and the EROs. > > > > > > However, doing such merging has very bad consequences. > > > First, there are > > > cases where a detour LSP which was up is temporarily > > > unavailable. Second, > > > it is not possible to guarantee protection against an > SRLG failure. > > > > > > The solution is to use the "sender-template-specific" method, > > > where the > > > sender address in the SENDER_TEMPLATE is set to an address > > > belonging to the > > > PLR instead of being left as an address belonging to the ingress. > > > > > > I presented about the problems of merging Path messages with > > > different EROs > > > in Salt Lake City. The draft I did then, > > > draft-atlas-rsvp-local-protect-interop-02.txt, describes the > > > issues in > > > detail; it has expired, because the solution was incorporated > > > into the > > > merged fast-reroute draft. > > > > > > Alia > > > > > > > > > At 12:02 PM 8/12/2002 -0700, Sundara Murugan wrote: > > > >Shahram, > > > > > > > >Let us assume that detours from B and C don't merge at H. > > > But these two > > > >LSPs share the same link between H-I. The at I there will be > > > 2 detour LSP > > > >(B to D and another from C to E). > > > > > > > >If the detour LSPs use SE filter, then the RESV message from > > > I to H can > > > >specify only one filter (Session + sender of all the detours > > > will be the > > > >same) and only one Label. Which label does I select? > > > > > > > >-sundara > > > > > > > >-----Original Message----- > > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > >Sent: Monday, August 12, 2002 11:45 AM > > > >To: Sundara Murugan; mpls@UU.net > > > >Subject: RE: fast-reroute merging > > > > > > > > > > > >Sundara, > > > > > > > >I think the shortest ERO is only a suggested example. and > > > not a standard rule. > > > > > > > > > > > > > > > > G----H----I--\ > > > > | | | \ > > > > A----B----C----D----E---F > > > > > > > > > > > >I think no merging should happen in the G, H and I LSRs. The > > > reason is that > > > >may be B has calculated the route B-G-H-I-D-E-F assuming some BW > > > >restrictions, etc. > > > >We don't want H to change that to B-G-H-I-E-F. > > > > > > > >Also since each PLR does an independent ERO calculation, it > > > is quite possible > > > >for C to compute computes the path as being > > > C-H-I-D-J-K-M-N-... Clearly > > > >C's detour should > > > >not be merged with B's detour here. > > > > > > > >If we have rule changed to "for merging the path messages > > > should have the > > > >same ERO", > > > >then we won't have such a problem. > > > > > > > > > > > >-Shahram > > > > > > > > > -----Original Message----- > > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > > Sent: Monday, August 12, 2002 2:22 PM > > > > > To: Shahram Davari; mpls@UU.net > > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > Section 5.3.1 says that the MP selects the shorter ERO path > > > > > length. This may not be correct. > > > > > > > > > > If there are other routers between I and E, then the ERO > > > > > lenght of the detour from C could be more than the ERO lenght > > > > > of the detour from B. If you go by the rule, then H will > > > > > merge the detours from B & C and establish a detour to D. > > > > > Then the detour from C will not avoid its next-hop D. So > > > > > there won't be a detour from C. > > > > > > > > > > So the MP has to select the detour which merges with the main > > > > > LSP that is closer to the egress router. > > > > > > > > > > -sundara > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Monday, August 12, 2002 10:57 AM > > > > > To: Sundara Murugan; mpls@UU.net > > > > > Subject: RE: fast-reroute merging > > > > > > > > > > > > > > > Sundara, > > > > > > > > > > This is exactly the same question that I asked in > another email: > > > > > > > > > > "Since as stated in section 7, each PLR has option to apply > > > > > its own constraints, then each PLR may reach to a different > > > > > backup-path ERO for the same flow. Assuming that the EROs > > > > > have a single link (the downstream link of an MP LSP) in > > > > > common, isn't it wrong for an MP LSR to merge those Path > > > messages?" > > > > > > > > > > > > > > > I think the solution is to require the same ERO for merging. > > > > > > > > > > Yours, > > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Sundara Murugan [mailto:smurugan@riverstonenet.com] > > > > > > Sent: Monday, August 12, 2002 1:36 PM > > > > > > To: mpls@UU.net > > > > > > Subject: fast-reroute merging > > > > > > > > > > > > > > > > > > Section 5.3.1 in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt > > > > > > explains merging procedure. In the fig below if there is a > > > > > > link between I and F then D will have a detour > D-I-F. In this > > > > > > case how router I (the MP) handles detour LSPs from > B, C and D? > > > > > > > > > > > > -sundara > > > > > > > > > > > > ------ > > > > > > > > > > > > 5.3.1. An Example on Path Message Merging > > > > > > > > > > > > Consider the following example: > > > > > > > > > > > > > > > > > > G----H----I--\ > > > > > > | | | \ > > > > > > A----B----C----D----E---F > > > > > > > > > > > > > > > > > > The protected LSP is A-B-C-D-E-F. After running CSPF, let > > > > > > the detour > > > > > > ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be > > > > > > C-H-I-E-F. > > > > > > > > > > > > H will receive Path messages that have the same > SESSION and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Aug 13 16:11:12 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16901 for ; Tue, 13 Aug 2002 16:11:12 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbtw21881 for ; Tue, 13 Aug 2002 20:12: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 QQnbtw20105; Tue, 13 Aug 2002 20:11:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbtw15591 for mpls-outgoing; Tue, 13 Aug 2002 20:11: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 QQnbtw15383 for ; Tue, 13 Aug 2002 20:10: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 QQnbtw05690 for ; Tue, 13 Aug 2002 20:10: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 QQnbtw03481 for ; Tue, 13 Aug 2002 20:10:33 GMT Received: from pimout3-ext.prodigy.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout3-ext.prodigy.net [207.115.63.102]) id QQnbtw03477 for ; Tue, 13 Aug 2002 20:10:32 GMT Received: from cs.columbia.edu (adsl-66-127-241-207.dsl.sntc01.pacbell.net [66.127.241.207]) by pimout3-ext.prodigy.net (8.11.0/8.11.0) with ESMTP id g7DKAQj284934; Tue, 13 Aug 2002 16:10:26 -0400 Message-ID: <3D5967B5.8080806@cs.columbia.edu> Date: Tue, 13 Aug 2002 13:10:29 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Shahram Davari CC: Der-Hwa Gan , "mpls@UU.net" Subject: Re: fast-reroute merging References: <4B6D09F3B826D411A67300D0B706EFDEB037F9@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, An approach that requires careful coding does not make it broken. The idea of standardization is to allow others to know what's going on, not a popularity contest. - Ping Shahram Davari wrote: > Alia, > > Why should the WG standardize a broken implemented behavior? > Being implemented is important, but when it has problems .... > > -Shahram > > From owner-mpls@UU.NET Tue Aug 13 16:21: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 QAA17305 for ; Tue, 13 Aug 2002 16:21:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbtx18145 for ; Tue, 13 Aug 2002 20:22: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 QQnbtx16063; Tue, 13 Aug 2002 20:21:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbtx16912 for mpls-outgoing; Tue, 13 Aug 2002 20:21:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnbtx16907 for ; Tue, 13 Aug 2002 20:21: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 QQnbtx21094 for ; Tue, 13 Aug 2002 20:21: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 QQnbtx07929 for ; Tue, 13 Aug 2002 20:21:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbtx07925 for ; Tue, 13 Aug 2002 20:21:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA09744 for ; Tue, 13 Aug 2002 16:21:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA02196 for mpls@uu.net; Tue, 13 Aug 2002 16:21:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnbtx16872 for ; Tue, 13 Aug 2002 20:19: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 QQnbtx29232 for ; Tue, 13 Aug 2002 20:19: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 QQnbtx15080 for ; Tue, 13 Aug 2002 20:19:55 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 QQnbtx15076 for ; Tue, 13 Aug 2002 20:19:54 GMT Received: (qmail 28823 invoked by uid 104); 13 Aug 2002 20:19:48 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.471906 secs); 13 Aug 2002 20:19:48 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 13 Aug 2002 20:19: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 g7DKJlw19376; Tue, 13 Aug 2002 13:19:47 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 13:20:10 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03806@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ping Pan'" Cc: Der-Hwa Gan , "mpls@UU.net" Subject: RE: fast-reroute merging Date: Tue, 13 Aug 2002 13:19:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Ping, 1) It is not a matter of careful coding. Please refer to my, Alia's and Sundara's emails, for the problems that can't be mended with careful coding. 2) Is this the new definition of Standardization process: "Implement whatever you want and by just letting other's know what you have done, expect it to be standardized". -Shahram > -----Original Message----- > From: Ping Pan [mailto:pingpan@cs.columbia.edu] > Sent: Tuesday, August 13, 2002 4:10 PM > To: Shahram Davari > Cc: Der-Hwa Gan; mpls@UU.net > Subject: Re: fast-reroute merging > > > Shahram, > > An approach that requires careful coding does not make it broken. The > idea of standardization is to allow others to know what's > going on, not > a popularity contest. > > - Ping > > Shahram Davari wrote: > > > Alia, > > > > Why should the WG standardize a broken implemented behavior? > > Being implemented is important, but when it has problems .... > > > > -Shahram > > > > > > From owner-mpls@UU.NET Wed Aug 14 10:16: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 KAA10171 for ; Wed, 14 Aug 2002 10:16:06 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbwr26720 for ; Wed, 14 Aug 2002 14:17: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 QQnbwr24414; Wed, 14 Aug 2002 14:15:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbwr29027 for mpls-outgoing; Wed, 14 Aug 2002 14:15: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 QQnbwr29018 for ; Wed, 14 Aug 2002 14:15: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 QQnbwr29710 for ; Wed, 14 Aug 2002 14: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 QQnbwr24013 for ; Wed, 14 Aug 2002 14:15:19 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbwr24007 for ; Wed, 14 Aug 2002 14:15:19 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01830 for ; Wed, 14 Aug 2002 10:15:18 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA19135 for mpls@uu.net; Wed, 14 Aug 2002 10:15:18 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnbuh14633 for ; Tue, 13 Aug 2002 22:57:10 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 QQnbuh26623 for ; Tue, 13 Aug 2002 22:57: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 QQnbuh05537 for ; Tue, 13 Aug 2002 22:57:03 GMT Received: from caduceus.jf.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr06.intel.com [134.134.136.7]) id QQnbuh05528 for ; Tue, 13 Aug 2002 22:57:02 GMT Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g7DMtG621485 for ; Tue, 13 Aug 2002 22:55:16 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g7DMsc007616 for ; Tue, 13 Aug 2002 22:54:38 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2002081315581531874 for ; Tue, 13 Aug 2002 15:58:16 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 15:56:29 -0700 Message-ID: From: "Sharma, Prem" To: "'mpls@uu.net'" Subject: MPLS:VP Merge/Switching Draft Date: Tue, 13 Aug 2002 15:56:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Does the following draft exist anymore? Is any work in progress on VP switching? N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T Worster, "MPLS using ATM VP Switching", Thanks. Prem From owner-mpls@UU.NET Wed Aug 14 12:48: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 MAA16524 for ; Wed, 14 Aug 2002 12:48:19 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbxb03283 for ; Wed, 14 Aug 2002 16:49: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 QQnbxb02030; Wed, 14 Aug 2002 16:49:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbxb26581 for mpls-outgoing; Wed, 14 Aug 2002 16:48: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 QQnbxb26569 for ; Wed, 14 Aug 2002 16:48:20 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 QQnbxb07989 for ; Wed, 14 Aug 2002 16:47: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 QQnbxb03391 for ; Wed, 14 Aug 2002 16:47:51 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbxb03387 for ; Wed, 14 Aug 2002 16:47: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 MAA16597; Wed, 14 Aug 2002 12:47:49 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA05836; Wed, 14 Aug 2002 12:47:49 -0400 (EDT) Message-Id: <200208141647.MAA05836@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: mpls@UU.NET, Loa Andersson , George Swallow Subject: Encapsulating MPLS in IP or GRE 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.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Wed_Aug_14_12:47:49_2002-1" Date: Wed, 14 Aug 2002 12:47:49 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk --Multipart_Wed_Aug_14_12:47:49_2002-1 Content-Type: text/plain; charset=US-ASCII In support of work going on in PPVPN and PWE3, it is desirable to have some standards for encapsulating MPLS packets inside IP packets. The draft whose announcement I attach below is the result of merging two previous (but expired) documents, draft-worster-mpls-in-ip, and draft-rekhter-mpls-over- gre. I would like to present this for the consideration of the MPLS WG as a standards track document. --Multipart_Wed_Aug_14_12:47:49_2002-1 Content-Type: message/rfc822 Return-Path: ietf-123-owner@loki.ietf.org Message-Id: <200208141127.HAA04404@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rosen-mpls-in-ip-or-gre-00.txt Date: Wed, 14 Aug 2002 07:27:26 -0400 Sender: nsyracus@cnri.reston.va.us Content-Length: 2766 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Encapsulating MPLS in IP or GRE Author(s) : T. Worster, Y. Rekhter, E. Rosen Filename : draft-rosen-mpls-in-ip-or-gre-00.txt Pages : 7 Date : 13-Aug-02 In various applications of MPLS, 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-mpls-in-ip-or-gre-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosen-mpls-in-ip-or-gre-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosen-mpls-in-ip-or-gre-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020813141619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-mpls-in-ip-or-gre-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosen-mpls-in-ip-or-gre-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020813141619.I-D@ietf.org> --OtherAccess-- --NextPart-- --Multipart_Wed_Aug_14_12:47:49_2002-1-- From owner-mpls@UU.NET Wed Aug 14 13:41: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 NAA18687 for ; Wed, 14 Aug 2002 13:41:35 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbxe12859 for ; Wed, 14 Aug 2002 17:42: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 QQnbxe09960; Wed, 14 Aug 2002 17:41:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbxe23214 for mpls-outgoing; Wed, 14 Aug 2002 17:41:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbxe23200 for ; Wed, 14 Aug 2002 17: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 QQnbxe26977 for ; Wed, 14 Aug 2002 17:40: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 QQnbxe04311 for ; Wed, 14 Aug 2002 17:40:11 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnbxe04307 for ; Wed, 14 Aug 2002 17:40:10 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 NAA21338 for ; Wed, 14 Aug 2002 13:40:10 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12020 for mpls@uu.net; Wed, 14 Aug 2002 13:40:10 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnbxe23170 for ; Wed, 14 Aug 2002 17:39: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 QQnbxe23554 for ; Wed, 14 Aug 2002 17:39: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 QQnbxe23896 for ; Wed, 14 Aug 2002 17:39:09 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 QQnbxe23874 for ; Wed, 14 Aug 2002 17:39:08 GMT Received: (qmail 11042 invoked by uid 104); 14 Aug 2002 17:39:03 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.471916 secs); 14 Aug 2002 17:39:03 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 14 Aug 2002 17:39: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 g7EHd1w03816; Wed, 14 Aug 2002 10:39:01 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Aug 2002 10:39:28 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0380C@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" , mpls@UU.NET, Loa Andersson , George Swallow Subject: RE: Encapsulating MPLS in IP or GRE Date: Wed, 14 Aug 2002 10:38:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric, It is odd to do MPLS-in-GRE over IP, because in this case you are already assuming that there is IP connectivity between the PEs. So why bother to have an extra GRE header, which does nothing, just do MPLS-in-IP. In other words how can you have a GRE-IP tunnel and not be able to have IP tunnel? Yours, -Shahram > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, August 14, 2002 12:48 PM > To: mpls@UU.NET; Loa Andersson; George Swallow > Subject: Encapsulating MPLS in IP or GRE > > > In support of work going on in PPVPN and PWE3, it is > desirable to have some > standards for encapsulating MPLS packets inside IP packets. > The draft whose > announcement I attach below is the result of merging two > previous (but > expired) documents, draft-worster-mpls-in-ip, and > draft-rekhter-mpls-over- > gre. I would like to present this for the consideration of > the MPLS WG as a > standards track document. > > From owner-mpls@UU.NET Wed Aug 14 14:27: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 OAA20267 for ; Wed, 14 Aug 2002 14:27:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbxh24046 for ; Wed, 14 Aug 2002 18:29: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 QQnbxh22402; Wed, 14 Aug 2002 18:28:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbxh20032 for mpls-outgoing; Wed, 14 Aug 2002 18:28:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnbxh20024 for ; Wed, 14 Aug 2002 18:27: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 QQnbxh06261 for ; Wed, 14 Aug 2002 18:27: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 QQnbxh14926 for ; Wed, 14 Aug 2002 18:27:44 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 QQnbxh14917 for ; Wed, 14 Aug 2002 18:27:43 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 OAA25702; Wed, 14 Aug 2002 14:27:36 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA23662; Wed, 14 Aug 2002 14:27:36 -0400 (EDT) Message-Id: <200208141827.OAA23662@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: mpls@UU.NET, Loa Andersson , George Swallow Subject: Re: Encapsulating MPLS in IP or GRE In-reply-to: Your message of Wed, 14 Aug 2002 10:38:43 -0700. <4B6D09F3B826D411A67300D0B706EFDEB0380C@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.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Aug 2002 14:27:36 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk In some cases you might already have a GRE tunnel through which you are supporting a routing adjacency. It should be possible to send MPLS packets, as well as IP packets, through such tunnels, and this requires an MPLS-in-GRE encapsulation. There are also other cases in which GRE tunnels (as opposed to IP tunnels) are commonly used, and you should be able to send MPLS packets through them. From owner-mpls@UU.NET Wed Aug 14 15:19:57 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22039 for ; Wed, 14 Aug 2002 15:19:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnbxl00250 for ; Wed, 14 Aug 2002 19:21: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 QQnbxl28501; Wed, 14 Aug 2002 19:20:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnbxl17431 for mpls-outgoing; Wed, 14 Aug 2002 19:20: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 QQnbxl17406 for ; Wed, 14 Aug 2002 19:19: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 QQnbxl21709 for ; Wed, 14 Aug 2002 19:19: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 QQnbxl09493 for ; Wed, 14 Aug 2002 19:19:15 GMT Received: from mailcity.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: fes.mail.lycos.com [209.185.123.154]) id QQnbxl09489 for ; Wed, 14 Aug 2002 19:19:15 GMT Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed, 14 Aug 2002 19:18:59 -0000 To: mpls@UU.NET Date: Wed, 14 Aug 2002 15:18:59 -0400 From: "Arthur Liew" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: arthur_liew@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Flow assignment - optical context X-Sender-Ip: 203.106.78.127 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I would appreciate if someone can point me to any recommended resources on flow assignment for IP over wdm. Thanks. Arthur. __________________________________________________________ Outgrown your current e-mail service? Get a 25MB Inbox, POP3 Access, No Ads and No Taglines with LYCOS MAIL PLUS. http://login.mail.lycos.com/brandPage.shtml?pageId=plus From owner-mpls@UU.NET Thu Aug 15 17:13: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 RAA16238 for ; Thu, 15 Aug 2002 17:13:23 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbk29272 for ; Thu, 15 Aug 2002 21:14: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 QQncbk27876; Thu, 15 Aug 2002 21:14:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQncbk08331 for mpls-outgoing; Thu, 15 Aug 2002 21:13: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 QQncbk08312 for ; Thu, 15 Aug 2002 21:13: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 QQncbk28008 for ; Thu, 15 Aug 2002 21:11: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 QQncbk20156 for ; Thu, 15 Aug 2002 21:11:44 GMT Received: from dnsmx1rrc.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQncbk20151 for ; Thu, 15 Aug 2002 21:11:44 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA11973 for ; Thu, 15 Aug 2002 17:10:51 -0400 (EDT) Subject: badloose / no route available error To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Thu, 15 Aug 2002 17:10:31 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 08/15/2002 05:10:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have question for the difference between the generation of error 'Bad loose node' and 'no route available toward destination'. For ex. A -------IUT------B 1) A sends a Path msg with the ERO as IUT connected to A interface address, and unrecognized address and TesterB address, and set the L bits for second unrecognized address as loose node, since there is no path between unrecognized node and testerb, the iut should send out the path error msg with error code 'routing problem' and error value 'bad loose node'. 2) A sends a path msg with ERO as IUT connected to A interface address, unrecognized address, but in the session object, put the end nodes as testerB, then the iut should send the path error msg with error code 'routing problem' and error value 'no route available towards the destination'. or I have to test the three tests mentioned in the section 4.7.4. If that is the case, is there any vender such as cisco or juniper, which can configure the Exclude-any, include-any, include-all parameters on the router? Thanks in advance. Julia From owner-mpls@UU.NET Thu Aug 15 17:32: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 RAA16910 for ; Thu, 15 Aug 2002 17:32:37 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbm16928 for ; Thu, 15 Aug 2002 21:33: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 QQncbm14330; Thu, 15 Aug 2002 21:32:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQncbm09879 for mpls-outgoing; Thu, 15 Aug 2002 21:32: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 QQncbm09874 for ; Thu, 15 Aug 2002 21:32: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 QQncbm01736 for ; Thu, 15 Aug 2002 21:31: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 QQncbm26357 for ; Thu, 15 Aug 2002 21:31:37 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 QQncbm26353 for ; Thu, 15 Aug 2002 21:31:36 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 RAA16137 for ; Thu, 15 Aug 2002 17:31:34 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20906 for ; Thu, 15 Aug 2002 17:31:35 -0400 (EDT) Message-ID: <3D5C1DC4.8070402@marconi.com> Date: Thu, 15 Aug 2002 17:31:48 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: badloose / no route available error References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > I have question for the difference between the generation of error 'Bad > loose node' and 'no route available toward destination'. It is my understanding that you generate "no route" only under these conditions: - There is no ERO object present - There is a route, but the requested resource affinities are incompatible with it. Under all other circumstances, you should generate "bad strict node" or "bad loose node", depending on whether the subobject in question is strict or loose. > For ex. > > A -------IUT------B > > 1) A sends a Path msg with the ERO as IUT connected to A interface > address, and unrecognized address and TesterB address, and set the L bits > for second unrecognized address as loose node, since there is no path > between unrecognized node and testerb, the iut should send out the path > error msg with error code 'routing problem' and error value 'bad loose > node'. Correct. > 2) A sends a path msg with ERO as IUT connected to A interface address, > unrecognized address, but in the session object, put the end nodes as > testerB, then the iut should send the path error msg with error code > 'routing problem' and error value 'no route available towards the > destination'. > or I have to test the three tests mentioned in the section 4.7.4. No. In this case, you still have an ERO where the first non-local subobject is not found in the routing table, so this would still be "bad loose node". If you have an ERO consisting of IUT connected to A's nterface address, followed by B's address (in other words, a valid ERO), along with a SESSION_ATTRIBUTES object that excludes the only link connecting IUT with B, then you would generate a "no route" PathErr message. > If that is the case, is there any vender such as cisco or juniper, which > can configure the Exclude-any, include-any, include-all parameters on the > router? The colors associated with specific links are part of interface configuration and are distributed via routing protocols. The three masks (exclude-any, include-any, include-all) that RSVP compares these against are generated by ingress nodes on a per-LSP basis. -- David From owner-mpls@UU.NET Thu Aug 15 18:00: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 SAA17685 for ; Thu, 15 Aug 2002 18:00:58 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbo19387 for ; Thu, 15 Aug 2002 22:02: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 QQncbo18064; Thu, 15 Aug 2002 22:01:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQncbo16852 for mpls-outgoing; Thu, 15 Aug 2002 22:01: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 QQncbo16642 for ; Thu, 15 Aug 2002 22:00: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 QQncbo20801 for ; Thu, 15 Aug 2002 22:00: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 QQncbo13809 for ; Thu, 15 Aug 2002 22:00:35 GMT Received: from mgw.cosinecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.88.104.199]) id QQncbo13798 for ; Thu, 15 Aug 2002 22:00:35 GMT Received: from imchub1.cosinecom.com (imchub1.cosinecom.com [172.21.8.23]) by mgw.cosinecom.com (Mirapoint) with ESMTP id ABS83829; Thu, 15 Aug 2002 14:55:57 -0700 (PDT) Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2655.55) id ; Thu, 15 Aug 2002 14:55:58 -0700 Received: from akingw2k (AKING-W2K [172.21.60.143]) by imchub1.cosinecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id P2BC2D0J; Thu, 15 Aug 2002 14:55:43 -0700 From: Art King Reply-To: Art King To: erosen@cisco.com, Shahram Davari Cc: mpls@UU.NET, Loa Andersson , George Swallow Message-ID: <000201c244a6$413b4b20$6701015a@akingw2k> References: <200208141827.OAA23662@erosen-u10.cisco.com> Subject: Re: Encapsulating MPLS in IP or GRE Date: Thu, 15 Aug 2002 13:32:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Connecting MPLS VPN PE's over non-MPLS core in a Carrier is a good example case for GRE usage. ----- Original Message ----- From: "Eric Rosen" To: "Shahram Davari" Cc: ; "Loa Andersson" ; "George Swallow" Sent: Wednesday, August 14, 2002 11:27 AM Subject: Re: Encapsulating MPLS in IP or GRE > > In some cases you might already have a GRE tunnel through which you are > supporting a routing adjacency. It should be possible to send MPLS packets, > as well as IP packets, through such tunnels, and this requires an > MPLS-in-GRE encapsulation. > > There are also other cases in which GRE tunnels (as opposed to IP tunnels) > are commonly used, and you should be able to send MPLS packets through > them. > From owner-mpls@UU.NET Thu Aug 15 18:18: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 SAA18101 for ; Thu, 15 Aug 2002 18:18:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbp21862 for ; Thu, 15 Aug 2002 22:20: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 QQncbp19674; Thu, 15 Aug 2002 22:19:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQncbp06572 for mpls-outgoing; Thu, 15 Aug 2002 22:18:53 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 QQncbp06567 for ; Thu, 15 Aug 2002 22:18: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 QQncbp25117 for ; Thu, 15 Aug 2002 22:16:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbp18354 for ; Thu, 15 Aug 2002 22:16:52 GMT Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQncbp18349 for ; Thu, 15 Aug 2002 22:16:51 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA25309; Thu, 15 Aug 2002 18:14:57 -0400 (EDT) Subject: Re: badloose / no route available error To: David Charlap Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Thu, 15 Aug 2002 18:14:35 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 08/15/2002 06:14:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk >>>>>It is my understanding that you generate "no route" only under these conditions: - There is no ERO object present - There is a route, but the requested resource affinities are incompatible with it. [Julia] The ERO object is optional, it does not have to be there. Then we can not use this one to generate this error msg. I basically agree with your other comments. Thanks, Julia David Charlap cc: (bcc: Hong Liao/Telcordia) Subject: Re: badloose / no route available error 08/15/02 05:31 PM Hong Liao wrote: > > I have question for the difference between the generation of error 'Bad > loose node' and 'no route available toward destination'. It is my understanding that you generate "no route" only under these conditions: - There is no ERO object present - There is a route, but the requested resource affinities are incompatible with it. Under all other circumstances, you should generate "bad strict node" or "bad loose node", depending on whether the subobject in question is strict or loose. > For ex. > > A -------IUT------B > > 1) A sends a Path msg with the ERO as IUT connected to A interface > address, and unrecognized address and TesterB address, and set the L bits > for second unrecognized address as loose node, since there is no path > between unrecognized node and testerb, the iut should send out the path > error msg with error code 'routing problem' and error value 'bad loose > node'. Correct. > 2) A sends a path msg with ERO as IUT connected to A interface address, > unrecognized address, but in the session object, put the end nodes as > testerB, then the iut should send the path error msg with error code > 'routing problem' and error value 'no route available towards the > destination'. > or I have to test the three tests mentioned in the section 4.7.4. No. In this case, you still have an ERO where the first non-local subobject is not found in the routing table, so this would still be "bad loose node". If you have an ERO consisting of IUT connected to A's nterface address, followed by B's address (in other words, a valid ERO), along with a SESSION_ATTRIBUTES object that excludes the only link connecting IUT with B, then you would generate a "no route" PathErr message. > If that is the case, is there any vender such as cisco or juniper, which > can configure the Exclude-any, include-any, include-all parameters on the > router? The colors associated with specific links are part of interface configuration and are distributed via routing protocols. The three masks (exclude-any, include-any, include-all) that RSVP compares these against are generated by ingress nodes on a per-LSP basis. -- David From owner-mpls@UU.NET Thu Aug 15 18:51: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 SAA19084 for ; Thu, 15 Aug 2002 18:51:09 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbr05016 for ; Thu, 15 Aug 2002 22:52: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 QQncbr02418; Thu, 15 Aug 2002 22:51:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQncbr08735 for mpls-outgoing; Thu, 15 Aug 2002 22:50: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 QQncbr08730 for ; Thu, 15 Aug 2002 22:50:39 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 QQncbr14187 for ; Thu, 15 Aug 2002 22:49:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbr15364 for ; Thu, 15 Aug 2002 22:49:36 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 QQncbr15360 for ; Thu, 15 Aug 2002 22:49:36 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 SAA07221 for ; Thu, 15 Aug 2002 18:49:36 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7FMna002750 for mpls@uu.net; Thu, 15 Aug 2002 18:49:36 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQncbm09988 for ; Thu, 15 Aug 2002 21:35:45 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 QQncbm15368 for ; Thu, 15 Aug 2002 21:35:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbm20248 for ; Thu, 15 Aug 2002 21:35:27 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [161.44.168.94]) id QQncbm20193 for ; Thu, 15 Aug 2002 21:35:26 GMT Received: from ACHARNY-W2K1.cisco.com (acharny-frame1.cisco.com [10.84.14.34]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA14812; Thu, 15 Aug 2002 17:35:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20020814221708.0402fc18@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Aug 2002 17:35:04 -0400 To: Shahram Davari From: Anna Charny Subject: Re: Comments on Backup-Computation draft Cc: "'mpls@UU.net'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB037DE@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 Hi Shahram, First, thanks for all your comments! Please see in-line: At 10:48 AM 8/9/2002 -0700, Shahram Davari wrote: >Hi, > >I have a few comments regarding this draft: > >1) Section 3, does not seem to indicate that it is possible to request >local protection and BW protection by only using the Session_Attribute. >Why is that? We did not mean to say that it is not possible to do so. Both modes (using the SESSIONJ-ATTRIBUTE object or the FAST REROUTE object) are supported in the FRR draft. We will try to clarify the text to make sure it is clear. >2) Many parts of the draft says PLR SHOULD send path_Error to the ingress LSR. >While the fast-reroute draft says MAY. Which one is correct? You are right, we will change the SHOULD to MAY to be compliant with the fast-reroute draft >3) The term "backup tunnel" is used in this draft to mean "Bypass tunnel". >Please follow the terms as defined in the fast-reroute draft. Yes, you are quite right - we will make sure we use the proper term. Thanks. >4) Section 5.1 says: > >"Note also that the single failure assumption needed for such bandwidth >sharing is a pre-requisite to any protection approach which uses pre- >computed backup tunnels -" > >Do you mean it is pre-requisite for this draft? Otherwise it can't be >pre-requisite for any protection approach. What we meant to say really is something very simple. If you want to protect, say, against *any* N failures with N>1, then pre-computed backup paths simply cannot do the job (in the worst case at least), as you can always have one failure in the primary and another failure in the backup even if they are completely link and node disjoint. We will try to modify the text to make it more clear. >5) Section 5.1 says: > >"However, achieving such sharing using explicit bandwidth reservations >for the backup tunnels requires extensive signaling and routing >extensions: > - routing extensions propagating the set of backup LSPs as > well as their bandwidth and the element(s) they protect [BP- > PLACEMENT]. In [lakshman]it was proposed to substantially > reduce the amount of state that needs to be propagated in the > routing updates at the price of sacrificing the amount of > achievable sharing. " > >This is not accurate. If you use the configuration method advised in this >draft or use the extension you propose to IGP in this draft, there is >no need for any more extensions to routing. We did not mean a general statement here - we were just pointing out the properties of the two *other* schemes currently proposed for bandwidth sharing. You are right that our draft does not need any more routing extensions than we defined (and that was one of the reasons we thought it may be useful), and those extensions are needed just for a distributed case. >Also Fast_reroute draft already proposes extensions to the signaling. So >extension to signaling should not be an issue. And I even think the same >extensions could be used here by the head-end for signaling. we were talking about signaling extensions in the first of the references in our text that you quote. These are extensions that are necessary to convey the information pertaining specifically to bandwidth sharing. Such extensions are not defined in the fast-reroute draft. >6) Appendix A gives an example which is easily solvable using the text from >other parts of this draft. The solution is using 2 Bypass tunnel for the R2-R3 >link as following: > >R2-R6-R7-R4 = 5M >R2-R8-R9-R4 = 5M > >So it is possible to use independent CSPF at PLRs. First let me point out that the issue of independent CSPF computation, although we believe correct, is really a secondary point in the draft, the primary point being the ability to provide bandwidth sharing between backup tunnels protecting against independent failures. Regarding the independent CSPF issue, you are right that if you allow load-balancing, then this particular example can be solved. However, in the context of facility backup (which is the context of our draft), it will be undesirable to have a large number of such load-balanced tunnels protecting a single facility. We were assuming that in practice one would want to limit the number of such "splits" of a single backup tunnel into several smaller ones would be limited by some fixed number. In fact, if you upper bound the number of splits by some N, then for each N it is possible to give an example when independent CSPF will not find a solution, when the solution actually exists. We gave an example for N=1. Of course examples for larger N will be more complicated. But again, this really is not the key issue in our draft. I guess one can view the ability to find better solutions than in the case of independent CSPF as a pleasant side benefit of our approach rather that its motivation. >7) Section 6.1.1 criticizes that if a PLR is computing the Backup tunnel, then >it needs signaling to enable an LSR distinguish between primary and Backup >LSP. >But the Fast_Reroute draft ha already defined these extensions and making >use of them. So there is no need for any extra signaling. I was under the impression that fast-reroute defines such extensions for the detour case but not for the bypass case (which is the one our draft discusses). For the BYPASS case, one cannot make the distinction between a primary and a bypass LSP that's why signalling non 0 bw bypass tunnel would require some additions in signalling. Also the CAC should be modified. >8) Section 6.2.1 suggests finding the backup pool, by subtracting the >global reservable BW from the link BW. How does a node know the link BW to >do this computation? Here is an example with OSPF (link TLV of the TE opaque LSA): Sub-TLV 6 - Maximum Bandwidth The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. Sub-TLV 7 - Maximum Reservable Bandwidth The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link in this direction, in IEEE floating point format Maximum bandwidth - Maximum Reservable Bandwidth = Backup bandwidth pool. > >9) Section 6.2.4: What happens if all NNHOPs are part of the SRLG? Could you please clarify your example and your question? >10) Section 7: Can't the L1 detect the L1 defects? In that case the node >and link failures could be distinguished. I do not see how L1 can tell whether it is just the link that failed, or whether it was really the node on the other end that failed AND brought the link down with it? >11) Finally, let me provide you with an alternative, simpler proposal: > >Let only the Ingress LSRs (head-end) do the TE and Bypass tunnel >computation. Here is how: > >If a Bypass tunnel is required at a PLR node, the ingress LSR can check >the RRO object in the RESV message to see whether, the node or link that >it wants has bypass tunnel or not. If a Bypass tunnel exists, fine, >otherwise it will compute a bypass tunnel ( or more) and indicate that, in >its PATH message. The appropriate PLR will then use the received PATH >message to generate the Bypass tunnel(s). > >The advantage of this method is that it is distributed, and doesn't need >intermediate LSRs to do CSPF. Also as I mentioned the issue of Appendix A >is easily solvable using more than 1 Bypass tunnels. It seems to me that you describe a method to off-load the bypass tunnel path computation on the HE. But I do not understand how this proposal addresses the key goal of our draft - namely the ability to share the bandwidth between backup tunnels protecting independent failures. Can you please clarify? Thanks, Anna >Yours, >Shahram From owner-mpls@UU.NET Thu Aug 15 18:54: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 SAA19132 for ; Thu, 15 Aug 2002 18:54:03 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbr26569 for ; Thu, 15 Aug 2002 22:55: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 QQncbr19771; Thu, 15 Aug 2002 22:52:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQncbr08932 for mpls-outgoing; Thu, 15 Aug 2002 22:52: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 QQncbr08915 for ; Thu, 15 Aug 2002 22:52:12 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 QQncbr24681 for ; Thu, 15 Aug 2002 22:51: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 QQncbr17540 for ; Thu, 15 Aug 2002 22:51:41 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 QQncbr17528 for ; Thu, 15 Aug 2002 22:51: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 SAA07369 for ; Thu, 15 Aug 2002 18:51:40 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7FMpeQ04066 for mpls@uu.net; Thu, 15 Aug 2002 18:51:40 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQncbp06534 for ; Thu, 15 Aug 2002 22:17: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 QQncbp02084 for ; Thu, 15 Aug 2002 22:16: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 QQncbp22487 for ; Thu, 15 Aug 2002 22:16:16 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQncbp22362 for ; Thu, 15 Aug 2002 22:16:08 GMT Received: from AMALIS.vivacenetworks.com ([10.5.25.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 15 Aug 2002 15:15:49 -0700 Message-Id: <5.1.0.14.2.20020815181347.06101770@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 Aug 2002 18:15:43 -0400 To: mpls@UU.NET From: "Andrew G. Malis" Subject: Re: Encapsulating MPLS in IP or GRE Cc: "Loa Andersson" , "George Swallow" In-Reply-To: <200208141647.MAA05836@erosen-u10.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_203623505==_.ALT" X-OriginalArrivalTime: 15 Aug 2002 22:15:49.0343 (UTC) FILETIME=[4F7B2EF0:01C244A9] Sender: owner-mpls@UU.NET Precedence: bulk --=====================_203623505==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I agree that this should be a standards track document. Cheers, Andy ------ At 8/14/2002 09:47 AM -0700, Eric Rosen wrote: >In support of work going on in PPVPN and PWE3, it is desirable to have some >standards for encapsulating MPLS packets inside IP packets. The draft whose >announcement I attach below is the result of merging two previous (but >expired) documents, draft-worster-mpls-in-ip, and draft-rekhter-mpls-over- >gre. I would like to present this for the consideration of the MPLS WG as a >standards track document. > > Title : Encapsulating MPLS in IP or GRE > Author(s) : T. Worster, Y. Rekhter, E. Rosen > Filename : draft-rosen-mpls-in-ip-or-gre-00.txt > Pages : 7 > Date : 13-Aug-02 --=====================_203623505==_.ALT Content-Type: text/html; charset="us-ascii" I agree that this should be a standards track document.

Cheers,
Andy

------

At 8/14/2002 09:47 AM -0700, Eric Rosen wrote:

In support of work going on in  PPVPN and PWE3, it is desirable to have some
standards for encapsulating MPLS packets inside IP packets.  The draft whose
announcement  I attach  below is  the result  of merging  two  previous (but
expired)  documents, draft-worster-mpls-in-ip,  and draft-rekhter-mpls-over-
gre.  I would like to present this for the consideration of the MPLS WG as a
standards track document.

        Title           : Encapsulating MPLS in IP or GRE
        Author(s)       : T. Worster, Y. Rekhter, E. Rosen
        Filename        : draft-rosen-mpls-in-ip-or-gre-00.txt
        Pages           : 7
        Date            : 13-Aug-02
--=====================_203623505==_.ALT-- From owner-mpls@UU.NET Thu Aug 15 19:07: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 TAA19503 for ; Thu, 15 Aug 2002 19:07:41 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbs07933 for ; Thu, 15 Aug 2002 23:08: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 QQncbs05432; Thu, 15 Aug 2002 23:07:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQncbs02436 for mpls-outgoing; Thu, 15 Aug 2002 23:07: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 QQncbs02430 for ; Thu, 15 Aug 2002 23:07:18 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 QQncbs22499 for ; Thu, 15 Aug 2002 23:05: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 QQncbs20503 for ; Thu, 15 Aug 2002 23:05:26 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQncbs20493 for ; Thu, 15 Aug 2002 23:05:26 GMT Received: from MDUFFY ([10.1.3.119]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q0RYPKQN; Thu, 15 Aug 2002 19:05:25 -0400 Message-Id: <3.0.5.32.20020815190130.0087b620@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Aug 2002 19:01:30 -0400 To: Art King From: Mark Duffy Subject: Re: Encapsulating MPLS in IP or GRE Cc: mpls@UU.NET In-Reply-To: <000201c244a6$413b4b20$6701015a@akingw2k> References: <200208141827.OAA23662@erosen-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Art, are you suggesting that there is something about the MPLS VPN case in particular that favors mpls-in-gre over mpls-in-ip? If so would you explain that? Thanks, Mark At 01:32 PM 8/15/02 -0700, Art King wrote: >Connecting MPLS VPN PE's over non-MPLS core in a Carrier is a >good example case for GRE usage. > >----- Original Message ----- >From: "Eric Rosen" >To: "Shahram Davari" >Cc: ; "Loa Andersson" ; "George >Swallow" >Sent: Wednesday, August 14, 2002 11:27 AM >Subject: Re: Encapsulating MPLS in IP or GRE > > >> >> In some cases you might already have a GRE tunnel through which you >are >> supporting a routing adjacency. It should be possible to send MPLS >packets, >> as well as IP packets, through such tunnels, and this requires >an >> MPLS-in-GRE encapsulation. >> >> There are also other cases in which GRE tunnels (as opposed to IP >tunnels) >> are commonly used, and you should be able to send MPLS packets >through >> them. >> > From owner-mpls@UU.NET Thu Aug 15 19:08: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 TAA19535 for ; Thu, 15 Aug 2002 19:08:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncbs09604 for ; Thu, 15 Aug 2002 23:09: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 QQncbs06175; Thu, 15 Aug 2002 23:08:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQncbs02448 for mpls-outgoing; Thu, 15 Aug 2002 23:07: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 QQncbs02431 for ; Thu, 15 Aug 2002 23:07:19 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 QQncbs22507 for ; Thu, 15 Aug 2002 23:05: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 QQncbs20504 for ; Thu, 15 Aug 2002 23:05:26 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQncbs20492 for ; Thu, 15 Aug 2002 23:05:26 GMT Received: from MDUFFY ([10.1.3.119]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q0RYPKQL; Thu, 15 Aug 2002 19:05:25 -0400 Message-Id: <3.0.5.32.20020815190056.0087b330@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Aug 2002 19:00:56 -0400 To: "Andrew G. Malis" , mpls@UU.NET From: Mark Duffy Subject: Re: Encapsulating MPLS in IP or GRE Cc: "Loa Andersson" , "George Swallow" In-Reply-To: <5.1.0.14.2.20020815181347.06101770@po1.vivacenetworks.com> References: <200208141647.MAA05836@erosen-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk ditto. --Mark P.S. Is it reasonable to expect that an IP protocol number (or two, including multicast) will be allocated for this purpose? Just how popular does a protocol need to be to merit one of these? At 06:15 PM 8/15/02 -0400, Andrew G. Malis wrote: >>>> I agree that this should be a standards track document. Cheers, Andy ------ At 8/14/2002 09:47 AM -0700, Eric Rosen wrote: In support of work going on in PPVPN and PWE3, it is desirable to have some standards for encapsulating MPLS packets inside IP packets. The draft whose announcement I attach below is the result of merging two previous (but expired) documents, draft-worster-mpls-in-ip, and draft-rekhter-mpls-over- gre. I would like to present this for the consideration of the MPLS WG as a standards track document. Title : Encapsulating MPLS in IP or GRE Author(s) : T. Worster, Y. Rekhter, E. Rosen Filename : draft-rosen-mpls-in-ip-or-gre-00.txt Pages : 7 Date : 13-Aug-02 <<<<<<<< From owner-mpls@UU.NET Thu Aug 15 20:38: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 UAA21374 for ; Thu, 15 Aug 2002 20:38:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncby28122 for ; Fri, 16 Aug 2002 00:39: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 QQncby26572; Fri, 16 Aug 2002 00:38:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQncby02665 for mpls-outgoing; Fri, 16 Aug 2002 00:38: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 QQncby02660 for ; Fri, 16 Aug 2002 00:38: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 QQncby09800 for ; Fri, 16 Aug 2002 00:37: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 QQncby07103 for ; Fri, 16 Aug 2002 00:37:55 GMT Received: from squirehome.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu57-89-018.nc.rr.com [66.57.89.18]) id QQncby07099 for ; Fri, 16 Aug 2002 00:37:54 GMT Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squirehome.org (8.11.6/8.11.0) with ESMTP id g7G0bUP23332; Thu, 15 Aug 2002 20:37:34 -0400 Message-ID: <3D5C494A.882E2589@acm.org> Date: Thu, 15 Aug 2002 20:37:30 -0400 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: "Andrew G. Malis" CC: mpls@UU.NET Subject: Re: Encapsulating MPLS in IP or GRE References: <5.1.0.14.2.20020815181347.06101770@po1.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit More agreement that this draft should be moved to the standards track. Its a good, sound draft with real application. - Matt "Andrew G. Malis" wrote: > > I agree that this should be a standards track document. > > Cheers, > Andy > > ------ > > At 8/14/2002 09:47 AM -0700, Eric Rosen wrote: > > > In support of work going on in PPVPN and PWE3, it is desirable to > > have some > > standards for encapsulating MPLS packets inside IP packets. The > > draft whose > > announcement I attach below is the result of merging two > > previous (but > > expired) documents, draft-worster-mpls-in-ip, and > > draft-rekhter-mpls-over- > > gre. I would like to present this for the consideration of the MPLS > > WG as a > > standards track document. > > > > Title : Encapsulating MPLS in IP or GRE > > Author(s) : T. Worster, Y. Rekhter, E. Rosen > > Filename : draft-rosen-mpls-in-ip-or-gre-00.txt > > Pages : 7 > > Date : 13-Aug-02 From owner-mpls@UU.NET Fri Aug 16 04:45: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 EAA09113 for ; Fri, 16 Aug 2002 04:45:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncdf17044 for ; Fri, 16 Aug 2002 08:47: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 QQncdf15467; Fri, 16 Aug 2002 08:46:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQncdf12222 for mpls-outgoing; Fri, 16 Aug 2002 08:45: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 QQncdf12215 for ; Fri, 16 Aug 2002 08:45: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 QQncdf04878 for ; Fri, 16 Aug 2002 08:45: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 QQncdf17013 for ; Fri, 16 Aug 2002 08:45:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQncdf17005 for ; Fri, 16 Aug 2002 08:45: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 EAA03797 for ; Fri, 16 Aug 2002 04:45:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7G8j5G06536 for mpls@uu.net; Fri, 16 Aug 2002 04:45:05 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQncde11912 for ; Fri, 16 Aug 2002 08:44:33 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 QQncde00901 for ; Fri, 16 Aug 2002 08:43:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncde14568 for ; Fri, 16 Aug 2002 08:43:47 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 QQncde14564 for ; Fri, 16 Aug 2002 08:43:46 GMT Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7G8hjf16562 for ; Fri, 16 Aug 2002 04:43:45 -0400 (EDT) Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 09:43:44 +0100 Message-ID: <17BA7A412C4FD311A4B700508B0291AE09F05A84@uk0006exch004u.uk.lucent.com> From: "Mannerstam, David (David)" To: mpls@UU.NET Date: Fri, 16 Aug 2002 09:43:42 +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 ********************************* David Mannerstam Senior Account Manager, Lucent Technologies Odenplan Norrtullsgatan 6 S-113 29 STOCKHOLM, SWEDEN Mobile: +46(0) 701 801 604 Telephone: +46(0) 8 54541 604 E-mail: dmanners@Lucent.com ********************************* From owner-mpls@UU.NET Fri Aug 16 09:59: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 JAA15928 for ; Fri, 16 Aug 2002 09:59:35 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncea04024 for ; Fri, 16 Aug 2002 14:00: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 QQncea02596; Fri, 16 Aug 2002 14:00:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQncdz00232 for mpls-outgoing; Fri, 16 Aug 2002 13:59: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 QQncdz00227 for ; Fri, 16 Aug 2002 13:59: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 QQncdz00196 for ; Fri, 16 Aug 2002 13:59: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 QQncdz05271 for ; Fri, 16 Aug 2002 13:59:03 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 QQncdz05267 for ; Fri, 16 Aug 2002 13:59:02 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 JAA14448; Fri, 16 Aug 2002 09:59:01 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07098; Fri, 16 Aug 2002 09:59:01 -0400 (EDT) Message-ID: <3D5D0534.8060405@marconi.com> Date: Fri, 16 Aug 2002 09:59:16 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Hong Liao CC: mpls@UU.NET Subject: Re: badloose / no route available error References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: >> It is my understanding that you generate "no route" only under these >> conditions: >> - There is no ERO object present >> - There is a route, but the requested resource affinities >> are incompatible with it. > > > [Julia] The ERO object is optional, it does not have to be there. Then we > can not use this one to generate this error msg. You misunderstand me. I am not saying that you generate this error whenever you get a Path without an ERO. I mean a route-table lookup failure will produce this error when there is no ERO. But a route-table lookup failure will produce bad-strict-route or bad-loose-route when there is an ERO. -- David From owner-mpls@UU.NET Fri Aug 16 11: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 LAA19265 for ; Fri, 16 Aug 2002 11:33:04 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnceg25822 for ; Fri, 16 Aug 2002 15:34: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 QQnceg24063; Fri, 16 Aug 2002 15:33:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnceg23444 for mpls-outgoing; Fri, 16 Aug 2002 15:32: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 QQnceg23427 for ; Fri, 16 Aug 2002 15:32:32 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 QQnceg21640 for ; Fri, 16 Aug 2002 15:32: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 QQnceg14515 for ; Fri, 16 Aug 2002 15:32:06 GMT Received: from mgw.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.88.104.199]) id QQnceg14509 for ; Fri, 16 Aug 2002 15:32:05 GMT Received: from imchub1.cosinecom.com (imchub1.cosinecom.com [172.21.8.23]) by mgw.cosinecom.com (Mirapoint) with ESMTP id ABS87479; Fri, 16 Aug 2002 08:30:09 -0700 (PDT) Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2655.55) id ; Fri, 16 Aug 2002 08:30:09 -0700 Received: from akingw2k (172.21.60.135 [172.21.60.135]) by imchub1.cosinecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id P2BC22N1; Fri, 16 Aug 2002 08:30:04 -0700 From: Art King Reply-To: Art King To: Mark Duffy Cc: mpls@UU.NET Message-ID: <000201c24539$8c8e8cc0$fe9faad8@akingw2k> References: <200208141827.OAA23662@erosen-u10.cisco.com> <3.0.5.32.20020815190130.0087b620@email.quarrytech.com> Subject: Re: Encapsulating MPLS in IP or GRE Date: Thu, 15 Aug 2002 22:03:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mark, I've seen a number of configurations where ISP's have merged and have broken AS's because pieces of the original backbone have been removed in order to reduce duplicate costs on same route and no one has time/skill to go back and rebuild/renumber the original network(s). This required BGP to be tunneled via GRE between dis-contiguous chunks of the same AS. For this provider topology, tunneling MPLS traffic and MP-BGP over same GRE tunnel achieves some level of transparency. It's kind of a corner case. Thanks, Art ----- Original Message ----- From: "Mark Duffy" To: "Art King" Cc: Sent: Thursday, August 15, 2002 4:01 PM Subject: Re: Encapsulating MPLS in IP or GRE > Hi Art, are you suggesting that there is something about the MPLS VPN case > in particular that favors mpls-in-gre over mpls-in-ip? If so would you > explain that? > > Thanks, Mark > > > At 01:32 PM 8/15/02 -0700, Art King wrote: > >Connecting MPLS VPN PE's over non-MPLS core in a Carrier is a > >good example case for GRE usage. > > > >----- Original Message ----- > >From: "Eric Rosen" > >To: "Shahram Davari" > >Cc: ; "Loa Andersson" ; "George > >Swallow" > >Sent: Wednesday, August 14, 2002 11:27 AM > >Subject: Re: Encapsulating MPLS in IP or GRE > > > > > >> > >> In some cases you might already have a GRE tunnel through which you > >are > >> supporting a routing adjacency. It should be possible to send MPLS > >packets, > >> as well as IP packets, through such tunnels, and this requires > >an > >> MPLS-in-GRE encapsulation. > >> > >> There are also other cases in which GRE tunnels (as opposed to IP > >tunnels) > >> are commonly used, and you should be able to send MPLS packets > >through > >> them. > >> > > From owner-mpls@UU.NET Fri Aug 16 18:05: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 SAA02296 for ; Fri, 16 Aug 2002 18:05:08 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncfg25396 for ; Fri, 16 Aug 2002 22:06: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 QQncfg23735; Fri, 16 Aug 2002 22:05:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQncfg29663 for mpls-outgoing; Fri, 16 Aug 2002 22:05: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 QQncfg29356 for ; Fri, 16 Aug 2002 22:05: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 QQncfg08152 for ; Fri, 16 Aug 2002 22: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 QQncfg06748 for ; Fri, 16 Aug 2002 22:04:16 GMT Received: from dnsmx1pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQncfg06744 for ; Fri, 16 Aug 2002 22:04:15 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA07039 for ; Fri, 16 Aug 2002 17:58:01 -0400 (EDT) Subject: Value for include-any, include-all, ... To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Fri, 16 Aug 2002 17:57:46 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 08/16/2002 05:58:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have question for RSVP RFC 3209 section 4.7.4. What value I should put in the field include-any, include-all etc fields? How the 32 bit vector in these fields is related to attribute filters? Or if there is a spec to explain this? Since it is not described anywhere in the spec of 3209. Thanks in an advance. Julia From owner-mpls@UU.NET Fri Aug 16 18:46: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 SAA03213 for ; Fri, 16 Aug 2002 18:46:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncfj25167 for ; Fri, 16 Aug 2002 22:47: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 QQncfj23441; Fri, 16 Aug 2002 22:46:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQncfj05820 for mpls-outgoing; Fri, 16 Aug 2002 22:46: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 QQncfj05742 for ; Fri, 16 Aug 2002 22:46:01 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 QQncfj17660 for ; Fri, 16 Aug 2002 22: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 QQncfj25520 for ; Fri, 16 Aug 2002 22:45:58 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQncfj25511 for ; Fri, 16 Aug 2002 22:45:58 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 SAA10892 for ; Fri, 16 Aug 2002 18:45:55 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA19707 for ; Fri, 16 Aug 2002 18:45:55 -0400 (EDT) Message-ID: <3D5D80B3.1050500@marconi.com> Date: Fri, 16 Aug 2002 18:46:11 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Value for include-any, include-all, ... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > I have question for RSVP RFC 3209 section 4.7.4. > > What value I should put in the field include-any, include-all etc fields? > How the 32 bit vector in these fields is related to attribute filters? > Or if there is a spec to explain this? Since it is not described anywhere > in the spec of 3209. If you need to restrict the choice of links to those that match a particular pattern of administrative link colors, then you specify the pattern with those fields. The pattern you want to use all depend on local administrative policy, and will depend on what colors are assigned to the links in your network and what restrictions/requirements you want to make using those colors as criteria. If you have no such requirements, then the fields may be left set to zero. You may also choose to use the non-affinities C-Type for SESSION_ATTRIBUTES in this situation. -- David From owner-mpls@UU.NET Mon Aug 19 14:18: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 OAA11683 for ; Mon, 19 Aug 2002 14:18:23 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQncph01171; Mon, 19 Aug 2002 15:23:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQncph09582 for mpls-outgoing; Mon, 19 Aug 2002 15:22: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 QQncph09564 for ; Mon, 19 Aug 2002 15:22: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 QQncph02714 for ; Mon, 19 Aug 2002 15:20: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 QQncph25840 for ; Mon, 19 Aug 2002 15:20:44 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 QQncph25828 for ; Mon, 19 Aug 2002 15:20:43 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 LAA13862 for ; Mon, 19 Aug 2002 11:20:43 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7JFKhF26117 for mpls@uu.net; Mon, 19 Aug 2002 11:20:43 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQncpg08087 for ; Mon, 19 Aug 2002 15:11:08 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 QQncpg17798 for ; Mon, 19 Aug 2002 15:11:00 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncpg03699 for ; Mon, 19 Aug 2002 15:11:00 GMT Received: from sith.maoz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sith.maoz.com [205.167.76.10]) id QQncpg03682 for ; Mon, 19 Aug 2002 15:10:59 GMT Received: (from dmm@localhost) by sith.maoz.com (8.12.2/8.12.2) id g7JFAv4w025826; Mon, 19 Aug 2002 08:10:57 -0700 Date: Mon, 19 Aug 2002 08:10:57 -0700 From: David Meyer To: Mark Duffy Cc: "Andrew G. Malis" , mpls@UU.NET, Loa Andersson , George Swallow Subject: Re: Encapsulating MPLS in IP or GRE Message-ID: <20020819081057.E25741@sprint.net> References: <200208141647.MAA05836@erosen-u10.cisco.com> <5.1.0.14.2.20020815181347.06101770@po1.vivacenetworks.com> <3.0.5.32.20020815190056.0087b330@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3.0.5.32.20020815190056.0087b330@email.quarrytech.com>; from mduffy@quarrytech.com on Thu, Aug 15, 2002 at 07:00:56PM -0400 Sender: owner-mpls@UU.NET Precedence: bulk >> P.S. Is it reasonable to expect that an IP protocol number (or two, >> including multicast) will be allocated for this purpose? Just how >> popular does a protocol need to be to merit one of these? If anything, it should be allocated out of the IANA block (possibly from the IANA SNAP Protocol IDs). Dave From owner-mpls@UU.NET Tue Aug 20 11:44: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 LAA17769 for ; Tue, 20 Aug 2002 11:44:10 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnctb14456 for ; Tue, 20 Aug 2002 15:45: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 QQncta12635; Tue, 20 Aug 2002 15:44:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQncta23862 for mpls-outgoing; Tue, 20 Aug 2002 15:44: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 QQncta23847 for ; Tue, 20 Aug 2002 15:44: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 QQncta19411 for ; Tue, 20 Aug 2002 15:42: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 QQncta11392 for ; Tue, 20 Aug 2002 15:42:40 GMT Received: from mail.san.yahoo.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQncta11381 for ; Tue, 20 Aug 2002 15:42:40 GMT Received: from [65.213.193.24] by mail.san.yahoo.com with HTTP; Tue, 20 Aug 2002 08:41:19 -0700 Date: Tue, 20 Aug 2002 11:41:19 -0400 Message-ID: <3D52BAF30000A603@mta07.san.yahoo.com> In-Reply-To: <3D52BB800000A06F@mta06.san.yahoo.com> From: "Kavita Khanna" Subject: MPLS 2002: Washington D.C., October 27-29, 2002 To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17769 MPLS 2002: 5th International Conference on MPLS October 27-29, 2002 Omni Shoreham Hotel, Washington, D.C. Hosted by: Worldcom, Cable and Wireless, France Telecom, NTT, and Isocore MPLS 2002, the fifth in the series of International Annual Conferences on Multiprotocol Label Switching, is open for registration. Please visit www.mpls2002.com and click on the "Registration" button to register. The designated hotel for MPLS2002 is the Omni Shoreham Hotel, Washington D.C. We have a limited number of rooms blocked at an exceptional rate and since Fall is a busy season in the city, we urge you to make your reservations immediately. You may visit our website and click on "Hotels and Travel" button for more information. Thanks to our conference sponsors and other efforts of volunteers, we have tried to keep the registration cost to a nominal fee. The early registation fees are extremely attractive and we hope you can benefit from the opportunity and pre-register for MPLS2002 soon. The program for MPLS 2002 includes highly original technical content presented by leading Service Providers, Vendors and recognized technical experts. There are six excellent tutorials to begin the program. The exhibitors will also be showcasing their latest MPLS-enabled and optical products in the Exhibit hall. We have also planned a public interoperability demo following the conference on October 30. For additional information, please send an email to info@mpls2002.com or visit the official website for MPLS 2002 International Conference at: http://www.mpls2002.com Looking forward to seeing you at MPLS 2002, Washington D.C. From owner-mpls@UU.NET Wed Aug 21 09:08: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 JAA08468 for ; Wed, 21 Aug 2002 09:08:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncwi15359 for ; Wed, 21 Aug 2002 13:10: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 QQncwi13997; Wed, 21 Aug 2002 13:09:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQncwi29190 for mpls-outgoing; Wed, 21 Aug 2002 13:09: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 QQncwi28903 for ; Wed, 21 Aug 2002 13:08:57 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 QQncwi18533 for ; Wed, 21 Aug 2002 13:07: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 QQncwi13093 for ; Wed, 21 Aug 2002 13:07:45 GMT Received: from mail.san.yahoo.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQncwi13088 for ; Wed, 21 Aug 2002 13:07:44 GMT Received: from [65.213.193.24] by mail.san.yahoo.com with HTTP; Wed, 21 Aug 2002 06:06:19 -0700 Date: Wed, 21 Aug 2002 09:06:19 -0400 Message-ID: <3D52BAF30000B67A@mta07.san.yahoo.com> From: "Kavita Khanna" Subject: MPLS 2002: Public Inter-Op Demo, October 30, 2002 To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA08468 Please note that registration for the MPLS 2002 International Conference includes Tutorials, Technical Sessions, and Exhibits held on October 27-29, 2002. Attendance to the Public Inter-Op Demo on October 30th is by invitation only. Invitations will be issued by Isocore and its Sponsors. For details please contact an Isocore Sponsor, or visit http://www.mpls2002.com/interop.htm, or send an email to iodemo@isocore.com. From owner-mpls@UU.NET Wed Aug 21 18: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 SAA27929 for ; Wed, 21 Aug 2002 18:33:28 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncxu24698 for ; Wed, 21 Aug 2002 22:34: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 QQncxu22972; Wed, 21 Aug 2002 22:34:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQncxu20133 for mpls-outgoing; Wed, 21 Aug 2002 22:33: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 QQncxu20126 for ; Wed, 21 Aug 2002 22:33: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 QQncxu22749 for ; Wed, 21 Aug 2002 22:33: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 QQncxu02545 for ; Wed, 21 Aug 2002 22:33:08 GMT Received: from mail.softplan.com.br by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [200.247.107.133]) id QQncxu02535 for ; Wed, 21 Aug 2002 22:33:07 GMT Received: from soft086 ([200.247.107.254]) by mail.softplan.com.br with Microsoft SMTPSVC(5.0.2195.4905); Wed, 21 Aug 2002 19:32:18 -0300 Message-Id: <3.0.3.32.20020821193445.009996c0@200.247.107.133> X-Sender: morvan@200.247.107.133 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 21 Aug 2002 19:34:45 -0300 To: mpls@UU.NET From: Morvan Daniel =?iso-8859-1?Q?M=FCller?= Subject: LDP TCP/MD5 Option implementation understanding! In-Reply-To: <3D592341.4010409@utfors.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 21 Aug 2002 22:32:19.0076 (UTC) FILETIME=[9BE2F440:01C24962] Sender: owner-mpls@UU.NET Precedence: bulk Hello! Excuse me about erros, my english is poor :)!. At 17:18 13/08/2002 +0200, you wrote: >LDP Implementation Survey Form [V 1.0] >... >================+=============================+======================== >TCP MD5 Option | 2.9 | >================+=============================+======================== ... > About "TCP MD5 Option" into LDP I have some doubts about inform locally, in each LSR, all possible peers and respective keys, like: LSR A local confuguration: LDP Authentication Option = enabled lsr-peer-idC : md5-keyC lsr-peer-idB : md5-keyB ... Considering that "TCP MD5 Option" is a global option on the LSR, i.e., if the authentication=ON this LSR only talk with peers who could authenticate (know the md5-key), OK? Consider a mpls domain: C | | A--- B ------- E | | | | D F If you configure A with auth=ON. You need configure B, C and D with auth=ON and inform the md5-key, to permit talking between they. If B have auth=ON it only could speack with E if it have too auth=ON and know the Md5-key, on so on ... How is the MD5 Auth OPtion implemented in the LSR police: 1) you could inform that any peer can speak without authenticate and only especific peers need authenticate. I think No, is no meaning! 2) you could identify local domain sessions and permit it, and supply authentication for external domain sessions, or indirect (non adjacent) sessions? if so, how its possible identify such session? (I think in stack-bit, but local domains LSRs can too use label stacking for especial situations like traffic eng., etc..) 3) Ldp authentication is based on the LSR physical interface? So you can suplly authentication for specific LSR interfaces (like LERs ingress interfaces) and for internal domain interfaces don't supply authentication. 4) Its necessary configure manually all LSRs in the mpls domain to talk with each other, by inform all possible ldp_peers and respective md5-key. It will be a problem for scale? I may miss-understood something in this environment, please coul'd someone clarify me? Thanks, Morvan. From owner-mpls@UU.NET Wed Aug 21 18:54: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 SAA28548 for ; Wed, 21 Aug 2002 18:54:54 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncxv28202 for ; Wed, 21 Aug 2002 22:56: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 QQncxv26607; Wed, 21 Aug 2002 22:55:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQncxv21778 for mpls-outgoing; Wed, 21 Aug 2002 22:54:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQncxv21771 for ; Wed, 21 Aug 2002 22:54:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQncxv00249 for ; Wed, 21 Aug 2002 22:53: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 QQncxv16043 for ; Wed, 21 Aug 2002 22:53: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 QQncxv16033 for ; Wed, 21 Aug 2002 22:53:56 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 18:53:56 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267291@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: =?iso-8859-1?Q?=27Morvan_Daniel_M=FCller=27?= Cc: mpls@UU.NET Subject: RE: LDP TCP/MD5 Option implementation understanding! Date: Wed, 21 Aug 2002 18:53:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA28548 Morvan, The TCP MD5 Signature option works at a level below TCP. In many cases, the option is enabled by providing a "secret" to the TCP stack (possibly via ioctl, for example). The extent to which this will apply - i.e. to interfaces or to the entire LSR - depends on your implementation (in particular how TCP is bound to specific interfaces). It is not a good idea to have a single "secret" apply to every interface in an LSR. If this were done generally, or even often, the secret would be quite out in the open since many LSRs would end up using the same "secret" for all of their interfaces - forcing the same "secret" to be shared by a lot of LSRs. If you can configure a different "secret" for each interface, then you probably could configure no secret for some interfaces, thus disabling the TCP MD5 Signature option for those interfaces. Does this help? Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Morvan Daniel Müller [mailto:morvan@softplan.com.br] Sent: Wednesday, August 21, 2002 6:35 PM To: mpls@UU.NET Subject: LDP TCP/MD5 Option implementation understanding! Hello! Excuse me about erros, my english is poor :)!. At 17:18 13/08/2002 +0200, you wrote: >LDP Implementation Survey Form [V 1.0] >... >================+=============================+======================== >TCP MD5 Option | 2.9 | >================+=============================+======================== ... > About "TCP MD5 Option" into LDP I have some doubts about inform locally, in each LSR, all possible peers and respective keys, like: LSR A local confuguration: LDP Authentication Option = enabled lsr-peer-idC : md5-keyC lsr-peer-idB : md5-keyB ... Considering that "TCP MD5 Option" is a global option on the LSR, i.e., if the authentication=ON this LSR only talk with peers who could authenticate (know the md5-key), OK? Consider a mpls domain: C | | A--- B ------- E | | | | D F If you configure A with auth=ON. You need configure B, C and D with auth=ON and inform the md5-key, to permit talking between they. If B have auth=ON it only could speack with E if it have too auth=ON and know the Md5-key, on so on ... How is the MD5 Auth OPtion implemented in the LSR police: 1) you could inform that any peer can speak without authenticate and only especific peers need authenticate. I think No, is no meaning! 2) you could identify local domain sessions and permit it, and supply authentication for external domain sessions, or indirect (non adjacent) sessions? if so, how its possible identify such session? (I think in stack-bit, but local domains LSRs can too use label stacking for especial situations like traffic eng., etc..) 3) Ldp authentication is based on the LSR physical interface? So you can suplly authentication for specific LSR interfaces (like LERs ingress interfaces) and for internal domain interfaces don't supply authentication. 4) Its necessary configure manually all LSRs in the mpls domain to talk with each other, by inform all possible ldp_peers and respective md5-key. It will be a problem for scale? I may miss-understood something in this environment, please coul'd someone clarify me? Thanks, Morvan. From owner-mpls@UU.NET Wed Aug 21 19:32: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 TAA29462 for ; Wed, 21 Aug 2002 19:32:02 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncxy22176 for ; Wed, 21 Aug 2002 23:33: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 QQncxy20274; Wed, 21 Aug 2002 23:32:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQncxy18286 for mpls-outgoing; Wed, 21 Aug 2002 23:31: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 QQncxy18279 for ; Wed, 21 Aug 2002 23:31:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQncxy04567 for ; Wed, 21 Aug 2002 23:31: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 QQncxy19544 for ; Wed, 21 Aug 2002 23:31:00 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 QQncxy19538 for ; Wed, 21 Aug 2002 23:30:59 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7LNUpm05918; Wed, 21 Aug 2002 16:30:53 -0700 (PDT) (envelope-from ina@juniper.net) Date: Wed, 21 Aug 2002 16:30:51 -0700 (PDT) From: Ina Minei To: Morvan Daniel =?iso-8859-1?Q?M=FCller?= cc: Subject: Re: LDP TCP/MD5 Option implementation understanding! In-Reply-To: <3.0.3.32.20020821193445.009996c0@200.247.107.133> Message-ID: <20020821160255.R57907-100000@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id TAA29462 Section 2.9.2 of RFC3036 requires that md5 authentication be turned on through configuration, on a per/peer basis. "An LSR that uses the MD5 Signature Option is configured with a password (shared secret) for each potential LDP peer." If you look at existing implementations, you will notice one way to implement this is to identify the peer by its address. As you mentioned in your mail, this requires configuration. However, usually one would use authentication on the untrusted peerings only, so there wouldn't be a need for a full mesh. Ina Minei On Wed, 21 Aug 2002, Morvan Daniel [iso-8859-1] Müller wrote: > Hello! > > Excuse me about erros, my english is poor :)!. > > At 17:18 13/08/2002 +0200, you wrote: > >LDP Implementation Survey Form [V 1.0] > >... > >================+=============================+======================== > >TCP MD5 Option | 2.9 | > >================+=============================+======================== > ... > > > > About "TCP MD5 Option" into LDP I have some doubts about inform locally, in > each LSR, all possible peers and respective keys, like: > LSR A local confuguration: > LDP Authentication Option = enabled > lsr-peer-idC : md5-keyC > lsr-peer-idB : md5-keyB > ... > > Considering that "TCP MD5 Option" is a global option on the LSR, i.e., if > the authentication=ON this LSR only talk with peers who could authenticate > (know the md5-key), OK? > > Consider a mpls domain: > C > | > | > A--- B ------- E > | | > | | > D F > > If you configure A with auth=ON. You need configure B, C and D with auth=ON > and inform the md5-key, to permit talking between they. > If B have auth=ON it only could speack with E if it have too auth=ON and > know the Md5-key, on so on ... > > How is the MD5 Auth OPtion implemented in the LSR police: > > 1) you could inform that any peer can speak without authenticate and only > especific peers need authenticate. I think No, is no meaning! > > 2) you could identify local domain sessions and permit it, and supply > authentication for external domain sessions, or indirect (non adjacent) > sessions? if so, how its possible identify such session? (I think in > stack-bit, but local domains LSRs can too use label stacking for especial > situations like traffic eng., etc..) > > 3) Ldp authentication is based on the LSR physical interface? So you can > suplly authentication for specific LSR interfaces (like LERs ingress > interfaces) and for internal domain interfaces don't supply authentication. > > 4) Its necessary configure manually all LSRs in the mpls domain to talk > with each other, by inform all possible ldp_peers and respective md5-key. > It will be a problem for scale? > > I may miss-understood something in this environment, please coul'd someone > clarify me? > > Thanks, > > Morvan. > From owner-mpls@UU.NET Wed Aug 21 23:50: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 XAA04320 for ; Wed, 21 Aug 2002 23:50:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncyp08540 for ; Thu, 22 Aug 2002 03:51: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 QQncyp06602; Thu, 22 Aug 2002 03:50:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQncyp11694 for mpls-outgoing; Thu, 22 Aug 2002 03:50: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 QQncyp11688 for ; Thu, 22 Aug 2002 03:50: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 QQncyp11917 for ; Thu, 22 Aug 2002 03:49: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 QQncyp07805 for ; Thu, 22 Aug 2002 03:49:13 GMT Received: from mail.softplan.com.br by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: server04.softplan.com.br [200.247.107.133]) id QQncyp07799 for ; Thu, 22 Aug 2002 03:49:11 GMT Received: from soft086 ([200.247.107.254]) by mail.softplan.com.br with Microsoft SMTPSVC(5.0.2195.4905); Thu, 22 Aug 2002 00:48:19 -0300 Message-Id: <3.0.3.32.20020822005048.00950048@200.247.107.133> X-Sender: morvan@200.247.107.133 (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 22 Aug 2002 00:50:48 -0300 To: "Gray, Eric" From: Morvan Daniel =?iso-8859-1?Q?M=FCller?= Subject: RE: LDP TCP/MD5 Option implementation understanding! Cc: mpls@UU.NET In-Reply-To: <1117F7D44159934FB116E36F4ABF221B02267291@celox-ma1-ems1.ce loxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Aug 2002 03:48:19.0589 (UTC) FILETIME=[C13BA350:01C2498E] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA04320 Hi Eric! > If you can configure a different "secret" for >each interface, then you probably could configure >no secret for some interfaces, thus disabling the >TCP MD5 Signature option for those interfaces. > > Does this help? Ok, it clarified! Thank you very much! At 18:53 21/08/2002 -0400, you wrote: >Morvan, > > The TCP MD5 Signature option works at a level >below TCP. In many cases, the option is enabled by >providing a "secret" to the TCP stack (possibly via >ioctl, for example). The extent to which this will >apply - i.e. to interfaces or to the entire LSR - >depends on your implementation (in particular how >TCP is bound to specific interfaces). It is not a >good idea to have a single "secret" apply to every >interface in an LSR. If this were done generally, >or even often, the secret would be quite out in the >open since many LSRs would end up using the same >"secret" for all of their interfaces - forcing the >same "secret" to be shared by a lot of LSRs. > > If you can configure a different "secret" for >each interface, then you probably could configure >no secret for some interfaces, thus disabling the >TCP MD5 Signature option for those interfaces. > > Does this help? > >Eric W. Gray >Systems Architect >Celox Networks, Inc. >egray@celoxnetworks.com >508 305 7214 > > >-----Original Message----- >From: Morvan Daniel Müller [mailto:morvan@softplan.com.br] >Sent: Wednesday, August 21, 2002 6:35 PM >To: mpls@UU.NET >Subject: LDP TCP/MD5 Option implementation understanding! > >Hello! > >Excuse me about erros, my english is poor :)!. > >At 17:18 13/08/2002 +0200, you wrote: >>LDP Implementation Survey Form [V 1.0] >>... >>================+=============================+======================== >>TCP MD5 Option | 2.9 | >>================+=============================+======================== >... >> > >About "TCP MD5 Option" into LDP I have some doubts about inform locally, in >each LSR, all possible peers and respective keys, like: >LSR A local confuguration: >LDP Authentication Option = enabled >lsr-peer-idC : md5-keyC >lsr-peer-idB : md5-keyB >... > >Considering that "TCP MD5 Option" is a global option on the LSR, i.e., if >the authentication=ON this LSR only talk with peers who could authenticate >(know the md5-key), OK? > >Consider a mpls domain: >C >| >| >A--- B ------- E >| | >| | >D F > >If you configure A with auth=ON. You need configure B, C and D with auth=ON >and inform the md5-key, to permit talking between they. >If B have auth=ON it only could speack with E if it have too auth=ON and >know the Md5-key, on so on ... > >How is the MD5 Auth OPtion implemented in the LSR police: > >1) you could inform that any peer can speak without authenticate and only >especific peers need authenticate. I think No, is no meaning! > >2) you could identify local domain sessions and permit it, and supply >authentication for external domain sessions, or indirect (non adjacent) >sessions? if so, how its possible identify such session? (I think in >stack-bit, but local domains LSRs can too use label stacking for especial >situations like traffic eng., etc..) > >3) Ldp authentication is based on the LSR physical interface? So you can >suplly authentication for specific LSR interfaces (like LERs ingress >interfaces) and for internal domain interfaces don't supply authentication. > >4) Its necessary configure manually all LSRs in the mpls domain to talk >with each other, by inform all possible ldp_peers and respective md5-key. >It will be a problem for scale? > >I may miss-understood something in this environment, please coul'd someone >clarify me? > >Thanks, > >Morvan. > From owner-mpls@UU.NET Thu Aug 22 01:01:59 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06193 for ; Thu, 22 Aug 2002 01:01:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncyu15399 for ; Thu, 22 Aug 2002 05:03: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 QQncyu13279; Thu, 22 Aug 2002 05:02:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQncyu15973 for mpls-outgoing; Thu, 22 Aug 2002 05:01:36 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 QQncyu15864 for ; Thu, 22 Aug 2002 05: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 QQncyu05633 for ; Thu, 22 Aug 2002 05:01: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 QQncyu19124 for ; Thu, 22 Aug 2002 05:01:10 GMT Received: from mail.softplan.com.br by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [200.247.107.133]) id QQncyu19097 for ; Thu, 22 Aug 2002 05:01:08 GMT Received: from soft086 ([200.247.107.254]) by mail.softplan.com.br with Microsoft SMTPSVC(5.0.2195.4905); Thu, 22 Aug 2002 02:00:12 -0300 Message-Id: <3.0.3.32.20020822020241.00950048@200.247.107.133> X-Sender: morvan@200.247.107.133 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 22 Aug 2002 02:02:41 -0300 To: Ina Minei From: Morvan Daniel =?iso-8859-1?Q?M=FCller?= Subject: Re: LDP TCP/MD5 Option implementation understanding! Cc: mpls@UU.NET In-Reply-To: <20020821160255.R57907-100000@garnet.juniper.net> References: <3.0.3.32.20020821193445.009996c0@200.247.107.133> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Aug 2002 05:00:12.0922 (UTC) FILETIME=[CC2E05A0:01C24998] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA06193 Hi Ina! At 16:30 21/08/2002 -0700, you wrote: > Section 2.9.2 of RFC3036 requires that md5 authentication be >turned on through configuration, on a per/peer basis. >"An LSR that uses the MD5 Signature Option is configured with a >password (shared secret) for each potential LDP peer." ok. > If you look at existing implementations, you will notice one way >to implement this is to identify the peer by its address. As you >mentioned in your mail, this requires configuration. ok. >However, usually one >would use authentication on the untrusted peerings only, so there wouldn't >be a need for a full mesh. rigth, is a valid and a simple solution. (Police = allow all and deny especific cases). One problem is address spoofing! Thank you very much, Morvan. > > Ina Minei > >On Wed, 21 Aug 2002, Morvan Daniel [iso-8859-1] Müller wrote: > >> Hello! >> >> Excuse me about erros, my english is poor :)!. >> >> At 17:18 13/08/2002 +0200, you wrote: >> >LDP Implementation Survey Form [V 1.0] >> >... >> >================+=============================+======================== >> >TCP MD5 Option | 2.9 | >> >================+=============================+======================== >> ... >> > >> >> About "TCP MD5 Option" into LDP I have some doubts about inform locally, in >> each LSR, all possible peers and respective keys, like: >> LSR A local confuguration: >> LDP Authentication Option = enabled >> lsr-peer-idC : md5-keyC >> lsr-peer-idB : md5-keyB >> ... >> >> Considering that "TCP MD5 Option" is a global option on the LSR, i.e., if >> the authentication=ON this LSR only talk with peers who could authenticate >> (know the md5-key), OK? >> >> Consider a mpls domain: >> C >> | >> | >> A--- B ------- E >> | | >> | | >> D F >> >> If you configure A with auth=ON. You need configure B, C and D with auth=ON >> and inform the md5-key, to permit talking between they. >> If B have auth=ON it only could speack with E if it have too auth=ON and >> know the Md5-key, on so on ... >> >> How is the MD5 Auth OPtion implemented in the LSR police: >> >> 1) you could inform that any peer can speak without authenticate and only >> especific peers need authenticate. I think No, is no meaning! >> >> 2) you could identify local domain sessions and permit it, and supply >> authentication for external domain sessions, or indirect (non adjacent) >> sessions? if so, how its possible identify such session? (I think in >> stack-bit, but local domains LSRs can too use label stacking for especial >> situations like traffic eng., etc..) >> >> 3) Ldp authentication is based on the LSR physical interface? So you can >> suplly authentication for specific LSR interfaces (like LERs ingress >> interfaces) and for internal domain interfaces don't supply authentication. >> >> 4) Its necessary configure manually all LSRs in the mpls domain to talk >> with each other, by inform all possible ldp_peers and respective md5-key. >> It will be a problem for scale? >> >> I may miss-understood something in this environment, please coul'd someone >> clarify me? >> >> Thanks, >> >> Morvan. >> > > > From owner-mpls@UU.NET Thu Aug 22 15:55: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 PAA08460 for ; Thu, 22 Aug 2002 15:55:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndbb17226 for ; Thu, 22 Aug 2002 19:55: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 QQndbb15276; Thu, 22 Aug 2002 19:54:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQndbb11622 for mpls-outgoing; Thu, 22 Aug 2002 19:54: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 QQndbb11600 for ; Thu, 22 Aug 2002 19:54: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 QQndbb05456 for ; Thu, 22 Aug 2002 19:53: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 QQndbb14890 for ; Thu, 22 Aug 2002 19:53:57 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQndbb14882 for ; Thu, 22 Aug 2002 19:53:57 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 PAA16822 for ; Thu, 22 Aug 2002 15:53:56 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7MJruq29315 for mpls@uu.net; Thu, 22 Aug 2002 15:53:56 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQndaz07534 for ; Thu, 22 Aug 2002 19:26:59 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 QQndaz24609 for ; Thu, 22 Aug 2002 19:26: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 QQndaz23305 for ; Thu, 22 Aug 2002 19:26:07 GMT Received: from xover.netplane.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cnxt10002.conexant.com [198.62.10.2]) id QQndaz23277 for ; Thu, 22 Aug 2002 19:26:05 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Aug 2002 15:26:04 -0400 Message-ID: <076236BAE727D611943F00508BA0F9591AE969@XOVER.dedham.mindspeed.com> From: "Fryer, John" To: "'rhthomas@cisco.com'" Cc: "'loa.andersson@utfors.se'" , "'swallow@cisco.com'" , "'mpls@uu.net'" Subject: FW: LDP to Draft Standard - implementation survey Date: Thu, 22 Aug 2002 15:26:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C24A11.C0688550" 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_01C24A11.C0688550 Content-Type: text/plain; charset="iso-8859-1" Bob, Please find below NetPlane Systems response to the LDP draft standard implementation survey. Please contact me if you have any questions, Sincerely, John Fryer mailto:jfryer@netplane.com Vice President, Marketing NetPlane Systems, http://www.netplane.com A Mindspeed Company Westwood Executive Center 200 Lowder Brook Drive Westwood, MA 02090 tel: (781) 251-5310 fax: (781) 251-5388 cel: (781) 929-2443 -----Original Message----- From: Miller, Seth Sent: Tuesday, August 13, 2002 12:55 PM To: Fryer, John Subject: FW: LDP to Draft Standard - implementation survey -----Original Message----- From: Loa Andersson [mailto:loa.andersson@utfors.se] Sent: Tuesday, August 13, 2002 11:18 AM To: MPLS wg Cc: George Swallow; Loa Andersson; Bob Thomas; Scott Bradner Subject: LDP to Draft Standard - implementation survey LDP to Draft Standard As protocols gets implemented and deployed, there is an IETF process to take them further on the standrads track. LDP is a protocol that has been both widely implemented and deployed, we will therefore start the process to progress LDP to Draft Standard. Included is an "LDP Implemenation Survey Form", it specifies in some detail the information needed to take this step. We ask companies and other organizations that have implemented LDP to take the time and answer the questions. The result of the survey will be made available as an Internet Draft, the time schedule depends very much on that we have the responses in a timely fashion. Send the response to the Bob Thomas, who will act as Internet Draft editor for the resulting summary document: rhthomas@cisco.com with a Cc to the wg chairs and the mpls list: loa.andersson@utfors.se swallow@cisco.com mpls@uu.net Earlier experiences with this kind of survey indicates that there are always a few that likes to respond anonymously, if you want to do that send the response to our AD, Scott Bradner: sob@harvard.edu We want to stress the importance of getting the highest possible number of responses, since it is important to create a protocol specification of highest possible quality. If there are further questions contact the wg chairs. Loa and George ===================================================================== LDP Implementation Survey Form [V 1.0] The purpose of this form is to gather information about implementations of LDP as defined by RFC3036. The information is being requested as part of the process of advancing LDP from Proposed to Draft Standard. The form is patterned after the implementation report form used for HTTP/1.1; see: http://www.ietf.org/IESG/Implementations/http1.1-implementations.txt ======================================================================= A. General information. Please provide the following information. ---------------------------------------------------------------- Organization: NetPlane Systems, Inc Organization url(s): www.netplane.com ---------------------------------------------------------------- Product title(s): Label Traffic Control System (LTCS) Brief description(s): LTCS is a complete implementation of all MPLS/GMPLS protocols, targetted for carrier-class and enterprise applications. It is offered as source code to OEM manufacturers, who may purchase specific protocol options according to their needs. ---------------------------------------------------------------- Contact for LDP information Name: John Fryer Title: Vice President of Marketing E-mail: mailto:jfryer@netplane.com Organization/department: NetPlane Systems, Inc Postal address: 8 Technology Drive, Westborough, MA 01581 Phone: (508) 621-0688 Fax: (781) 251-5388 ======================================================================= B. LDP Implementation Status, Availability, Origin Please check [x] the boxes that apply. ---------------------------------------------------------------- Status: [ ] Development [ ] Alpha [ ] Beta [x] Product [ ] Other (describe): Availability [ ] Public and free [ ] Only to selected organizations/companies but free [x] On sale. [ ] For internal company use only [ ] Other: Implementation based on: (check all that apply) [ ] Purchased code (please list source if possible) [ ] Free code (please list source if possible) [x] Internal implementation (no outside code, just from specs) [ ] Internal implementation on top of purchased or free code List portions from external source: List portions developed internally: ======================================================================= C. LDP Feature Survey. For each features listed, please indicate the Status of the implementation using one of the following: 't' tested against another independent implementation 'y' implemented but not tested against independent implementation 'n' not implemented '-' not applicable to this type of implementation Optional: For 'n' status, indicate reason not implemented using one of the following: 's' RFC specification inadequate, unclear, or confusing 'u' utility of feature unclear 'r' feature not required for feature set implemented ------------------+-----------------------------+------------------------- | | Status (one of t, y, n - | | If n, optionally one of Feature | RFC3036 Section(s) | s, u, r) ==================+=============================+========================= Interface types | 2.2.1, 2.5.3, 2.8.2, 3,4,2 ----------------+-----------------------------+------------------------- Packet | t | ----------------+-----------------------------+------------------------- Frame Relay | t | ----------------+-----------------------------+------------------------- ATM | t | ==================+=============================+========================= Label Spaces | 2.2.1, 2.2.2 ----------------+-----------------------------+------------------------- Per platform | t | ----------------+-----------------------------+------------------------- Per interface | t | ==================+=============================+========================= LDP Discovery | 2.4 t ----------------+-----------------------------+------------------------- Basic | 2.4.1 t | ----------------+-----------------------------+------------------------- Targeted | 2.4.2 t | ------------------+-----------------------------+------------------------- LDP Sessions | 2.2.3 t ----------------+-----------------------------+------------------------- Directly | -- (t) | Connected | | ----------------+-----------------------------+------------------------- Targeted | 2.3 t | ==================+=============================+========================= LDP Modes | 2.6 ----------------+-----------------------------+------------------------- DU, Ind cntl, | 2.6 n | u Lib retention | | ----------------+-----------------------------+------------------------- DU, Ord cntl, | 2.6 t | Lib retention | | ----------------+-----------------------------+------------------------- DU, Ind cntl, | 2.6 n | u Cons retention | | ----------------+-----------------------------+------------------------- DU, Ord cntl, | 2.6 t | Cons retention | | ----------------+-----------------------------+------------------------- DoD, Ind cntl, | 2.6 n | u Lib retention | | ----------------+-----------------------------+------------------------- DoD, Ord cntl, | 2.6 t | Lib retention | | ----------------+-----------------------------+------------------------- DoD, Ind cntl, | 2.6 n | u Cons retention | | ----------------+-----------------------------+------------------------- DoD, Ord cntl, | 2.6 t | Cons retention | | ==================+=============================+========================= Loop Detection | 2.8 t | ==================+=============================+========================= TCP MD5 Option | 2.9 n | ==================+=============================+========================= LDP TLVs | 3.3, 3.4, throughout t ----------------+-----------------------------+------------------------- U-bit | 3.3 t | ----------------+-----------------------------+------------------------- F-bit | 3.3 t | ------------------+-----------------------------+------------------------- FEC | 1., 2.1, 3.4.1 t | ----------------+-----------------------------+------------------------- Wildcard | 3.4.1 t | ----------------+-----------------------------+------------------------- Prefix | 2.1, 3.4.1 t | ----------------+-----------------------------+------------------------- Host | 2.1, 3.4.1 t | ------------------+-----------------------------+------------------------- Address List | 3.4.3 t | ------------------+-----------------------------+------------------------- Hop Count | 3.4.4 t | ------------------+-----------------------------+------------------------- Path Vector | 3.4.5 t | ------------------+-----------------------------+------------------------- Generic Label | 3.4.2.1 t | ------------------+-----------------------------+------------------------- ATM Label | 3.4.2.2 t | ------------------+-----------------------------+------------------------- Frame Relay | 3.4.2.3 t | Label | | ------------------+-----------------------------+------------------------- Status | 3.4.6 t | ------------------+-----------------------------+------------------------- Extended Status | 3.5.1 t | ------------------+-----------------------------+------------------------- Returned PDU | 3.5.1 t | ------------------+-----------------------------+------------------------- Returned Message| 3.5.1 t | ------------------+-----------------------------+------------------------- Common Hello | 3.5.2 t | Parameters | | ----------------+-----------------------------+------------------------- T-bit | 3.5.2 t | ----------------+-----------------------------+------------------------- R-bit | 3.5.2 t | ----------------+-----------------------------+------------------------- Hold Time | 3.5.2 t | ------------------+-----------------------------+------------------------- IPv4 Transport | 3.5.2 t | Address | | ------------------+-----------------------------+------------------------- Configuration | 3.5.2 t | Sequence Number | | ------------------+-----------------------------+------------------------- IPv6 Transport | 3.5.2 t | Address | | ------------------+-----------------------------+------------------------- Common Session | 3.5.3 t | Parameters | | ----------------+-----------------------------+------------------------- KeepAlive Time| 3.5.3 t | ----------------+-----------------------------+------------------------- PVLim | 3.5.3 t | ----------------+-----------------------------+------------------------- Max PDU Length| 3.5.3 t | ------------------+-----------------------------+------------------------- ATM Session | 3.5.3 t | Parameters | | ----------------+-----------------------------+------------------------- M values | t | 0 No Merge | 3.5.3 | ------------+-----------------------------+------------------------- 1 VP Merge | 3.5.3 t | ------------+-----------------------------+------------------------- 2 VC Merge | 3.5.3 t | ------------+-----------------------------+------------------------- 3 VP & | 3.5.3 t | VC Merge | | ----------------+-----------------------------+------------------------- D-bit | 3.5.3 t | ----------------+-----------------------------+------------------------- ATM Label | 3.5.3 t | Range | | Component | | ------------------+-----------------------------+------------------------- Frame Relay | 3.5.3 t | Session | | Parameters | | ------------------+-----------------------------+------------------------- M values | | 0 No Merge | 3.5.3 t | ------------+-----------------------------+------------------------- 1 Merge | 3.5.3 t | ----------------+-----------------------------+------------------------- D-bit | 3.5.3 t | ----------------+-----------------------------+------------------------- Frame Relay | 3.5.3 t | Label Range | | Component | | ----------------+-----------------------------+------------------------- Label Request | 3.5.7 t | Message ID | | ------------------+-----------------------------+------------------------- Vendor-Private | 3.6.1.1 t | ------------------+-----------------------------+------------------------- Experimental | 3.6.2 t | ==================+=============================+========================= LDP Messages | 3.5, throughout t ------------------+-----------------------------+------------------------- Notification | 3.5.1 t | ------------------+-----------------------------+------------------------- Hello | 3.5.2 t | ------------------+-----------------------------+------------------------- Initialization | 3.5.3 t | ------------------+-----------------------------+------------------------- KeepAlive | 3.5.4 t | ------------------+-----------------------------+------------------------- Address | 3.5.5 t | ------------------+-----------------------------+------------------------- Address Withdraw| 3.5.6 t | ------------------+-----------------------------+------------------------- Label Mapping | 3.5.7 t | ----------------+-----------------------------+------------------------- Label Request | 3.5.7 t | Message ID TLV| | ----------------+-----------------------------+------------------------- Hop Count TLV | 3.5.7 t | ----------------+-----------------------------+------------------------- Path Vect TLV | 3.5.7 t | ------------------+-----------------------------+------------------------- Label Request | 3.5.8 t | ----------------+-----------------------------+------------------------- Hop Count TLV | 3.5.8 t | ----------------+-----------------------------+------------------------- Path Vect TLV | 3.5.8 t | ------------------+-----------------------------+------------------------- Label Withdraw | 3.5.10 t | ----------------+-----------------------------+------------------------- Label TLV | 3.5.10 t | ------------------+-----------------------------+------------------------- Label Release | 3.5.11 t | ----------------+-----------------------------+------------------------- Label TLV | 3.5.11 t | ------------------+-----------------------------+------------------------- Label Abort Req | 3.5.9 t | ------------------+-----------------------------+------------------------- Vendor-Private | 3.6.1.2 t | ------------------+-----------------------------+------------------------- Experimental | 3.6.2 t | ==================+=============================+========================= LDP Status Codes | 3.4.6 t ------------------+-----------------------------+------------------------- Success | 3.4.6, 3.9 t | ------------------+-----------------------------+------------------------- Bad LDP Id | 3.5.1.2.1 t | ------------------+-----------------------------+------------------------- Bad Ptcl Version| 3.5.1.2.1 t | ------------------+-----------------------------+------------------------- Bad PDU Length | 3.5.1.2.1 t | ------------------+-----------------------------+------------------------- Unknown Message | 3.5.1.2.1 t | Type | | ------------------+-----------------------------+------------------------- Bad Message | 3.5.1.2.1 t | Length | | ------------------+-----------------------------+------------------------- Unknown TLV | 3.5.1.2.2 t | ------------------+-----------------------------+------------------------- Bad TLV length | 3.5.1.2.2 t | ------------------+-----------------------------+------------------------- Malformed TLV | 3.5.1.2.2 t | Value | | ------------------+-----------------------------+------------------------- Hold Timer | 3.5.1.2.3 t | Expired | | ------------------+-----------------------------+------------------------- Shutdown | 3.5.1.2.4 t | ------------------+-----------------------------+------------------------- Loop Detected | 3.4.5.1.2, 3.5.8.1 t | ------------------+-----------------------------+------------------------- Unknown FEC | 3.4.1.1 t | ------------------+-----------------------------+------------------------- No Route | 3.5.8.1 t | ------------------+-----------------------------+------------------------- No Label | 3.5.8.1 t | Resources | | ------------------+-----------------------------+------------------------- Label Resources | 3.5.8.1 t | Available | | ------------------+-----------------------------+------------------------- Session Rejected| 2.5.3, 3.5.3 t | No Hello | | ------------------+-----------------------------+------------------------- Session Rejected| 2.5.3, 3.5.3 t | Parameters | | Advert Mode | | ------------------+-----------------------------+------------------------- Session Rejected| 2.5.3, 3.5.3 t | Parameters | | Max PDU Length | | ------------------+-----------------------------+------------------------- Session Rejected| 2.5.3, 3.5.3 t | Parameters | | Label Range | | ------------------+-----------------------------+------------------------- KeepAlive Timer | 2.5.6, 3.5.1.2.3 t | Expired | | ------------------+-----------------------------+------------------------- Label Request | 3.5.9.1 t | Aborted | | ------------------+-----------------------------+------------------------- Missing Message | 3.5.1.2.1 t | Parameters | | ------------------+-----------------------------+------------------------- Unsupported | 3.4.1.1, 3.5.5.1 t | Address Family | | ------------------+-----------------------------+------------------------- Session Rejected| 3.5.1.2.5, 3.5.3 t | Bad KeepAlive | | Time | | ------------------+-----------------------------+------------------------- Internal Error | 3.5.1.2.7 t | ==================+=============================+========================= -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se ------_=_NextPart_000_01C24A11.C0688550 Content-Type: application/octet-stream; name="Fryer, John.vcf" Content-Disposition: attachment; filename="Fryer, John.vcf" BEGIN:VCARD VERSION:2.1 N:Fryer;John FN:Fryer, John ORG:NetPlane Systems;Marketing TITLE:VP Marketing TEL;WORK;VOICE:781-251-5310 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Westwood Executive Center=0D=0A200 Lowder Brook Drive=0D=0A2nd Floor ;West= wood;MA;02090;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Westwood Executive Center=0D=0A200 Lowder Brook Drive=0D=0A2nd Floor =0D=0AW= estwood, MA 02090=0D=0AUSA EMAIL;PREF;INTERNET:john.fryer@netplane.com REV:20010727T193605Z END:VCARD ------_=_NextPart_000_01C24A11.C0688550-- From owner-mpls@UU.NET Thu Aug 22 16:18: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 QAA09264 for ; Thu, 22 Aug 2002 16:18:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndbd10959 for ; Thu, 22 Aug 2002 20:19:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQndbd09765; Thu, 22 Aug 2002 20:18:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQndbd07400 for mpls-outgoing; Thu, 22 Aug 2002 20:18: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 QQndbd07393 for ; Thu, 22 Aug 2002 20:18:09 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 QQndbd15257 for ; Thu, 22 Aug 2002 20:16: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 QQndbd26943 for ; Thu, 22 Aug 2002 20:16:07 GMT Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQndbd26932 for ; Thu, 22 Aug 2002 20:16:07 GMT Received: from utfors.se ([195.58.105.118]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id H19HVT00.LD6; Thu, 22 Aug 2002 22:21:29 +0200 Message-ID: <3D654672.1030005@utfors.se> Date: Thu, 22 Aug 2002 22:15:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mpls wg CC: Scott Bradner , George Swallow , Bert Wijnen Subject: a step towards consensus on mpls signaling protocol Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, George and I as the chairs would like to offer our view of where we see consensus forming on the recent discussion of signaling protocols. We do this to allow further comments before making a final decision on the matter. Please make any comments to the list prior to September 7. The current discussion on MPLS signaling protocols shows that: - There is a clear consensus on that the MPLS WG needs to focus its efforts on RSVP-TE as protocol for traffic engineering signaling and that the WG charter should be updated accordingly. - There is a clear majority for discontinuing work on CR-LDP. However, there is no IETF process to "de-standardize" an existing proposed standard that would apply in this situation. Thus CR-LDP will remain a proposed standard. To this end: - Existing WG drafts related to or updating/changing CR-LDP will be progressed according to normal procedures. - the Working Group will take on no new WG documents related to CR-LDP. - A message will be sent to the relevant standards organizations notifying them of this change of focus on MPLS signaling protocols. Loa and George -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Thu Aug 22 16:35:15 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09688 for ; Thu, 22 Aug 2002 16:35:15 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndbe11731 for ; Thu, 22 Aug 2002 20:36: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 QQndbe09715; Thu, 22 Aug 2002 20:35:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQndbe08241 for mpls-outgoing; Thu, 22 Aug 2002 20:34: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 QQndbe08236 for ; Thu, 22 Aug 2002 20:34:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQndbe06584 for ; Thu, 22 Aug 2002 20:33: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 QQndbe09989 for ; Thu, 22 Aug 2002 20:33:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQndbe09984 for ; Thu, 22 Aug 2002 20:33: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 QAA19528 for ; Thu, 22 Aug 2002 16:33:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7MKX4704366 for mpls@uu.net; Thu, 22 Aug 2002 16:33:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQndbd07628 for ; Thu, 22 Aug 2002 20:24:05 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 QQndbd09081 for ; Thu, 22 Aug 2002 20:24: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 QQndbd06144 for ; Thu, 22 Aug 2002 20:24:00 GMT Received: from sith.maoz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sith.maoz.com [205.167.76.10]) id QQndbd06137 for ; Thu, 22 Aug 2002 20:23:59 GMT Received: (from dmm@localhost) by sith.maoz.com (8.12.2/8.12.2) id g7MKNrDx020425; Thu, 22 Aug 2002 13:23:53 -0700 Date: Thu, 22 Aug 2002 13:23:53 -0700 From: David Meyer To: Loa Andersson Cc: mpls wg , Scott Bradner , George Swallow , Bert Wijnen Subject: Re: a step towards consensus on mpls signaling protocol Message-ID: <20020822132353.B20378@sprint.net> References: <3D654672.1030005@utfors.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D654672.1030005@utfors.se>; from loa.andersson@utfors.se on Thu, Aug 22, 2002 at 10:15:46PM +0200 Sender: owner-mpls@UU.NET Precedence: bulk >> - There is a clear majority for discontinuing work on CR-LDP. >> However, there is no IETF process to "de-standardize" an existing >> proposed standard that would apply in this situation. Thus >> CR-LDP will remain a proposed standard. Send it to historic, a la RFC 3166/3167, or someone will make me implement it. >> To this end: >> >> - Existing WG drafts related to or updating/changing CR-LDP will >> be progressed according to normal procedures. >> >> - the Working Group will take on no new WG documents related to >> CR-LDP. >> >> - A message will be sent to the relevant standards organizations >> notifying them of this change of focus on MPLS signaling protocols. Again, can we send it to historic or is there some procedural (or other reason) not to do this? Dave From owner-mpls@UU.NET Thu Aug 22 22:18: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 WAA16304 for ; Thu, 22 Aug 2002 22:18:00 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndcb10240 for ; Fri, 23 Aug 2002 02:19: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 QQndcb08512; Fri, 23 Aug 2002 02:18:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQndcb25252 for mpls-outgoing; Fri, 23 Aug 2002 02:18: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 QQndcb25247 for ; Fri, 23 Aug 2002 02:18:07 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 QQndcb15057 for ; Fri, 23 Aug 2002 02:17: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 QQndcb08059 for ; Fri, 23 Aug 2002 02:17:51 GMT Received: from squirehome.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu57-89-018.nc.rr.com [66.57.89.18]) id QQndcb08054 for ; Fri, 23 Aug 2002 02:17:51 GMT Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squirehome.org (8.11.6/8.11.0) with ESMTP id g7N2HgP12701; Thu, 22 Aug 2002 22:17:43 -0400 Message-ID: <3D659B46.B614067B@acm.org> Date: Thu, 22 Aug 2002 22:17:42 -0400 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Loa Andersson CC: mpls wg , Scott Bradner , George Swallow , Bert Wijnen Subject: Re: a step towards consensus on mpls signaling protocol References: <3D654672.1030005@utfors.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Loa - I think you're doing the right thing going with only RSVP-TE. But as for continuing the CR-LDP work...why? It can certainly be continued as individual contributions, but why put the burden on the group to manage/review additions to something we as a group have decided isn't in our future? Personal opinion is that current CR-LDP work be moved to individual contributions outside of the WG activities. - Matt Loa Andersson wrote: > > All, > > George and I as the chairs would like to offer our view of where we > see consensus forming on the recent discussion of signaling protocols. > We do this to allow further comments before making a final decision on > the matter. Please make any comments to the list prior to September 7. > > The current discussion on MPLS signaling protocols shows that: > > - There is a clear consensus on that the MPLS WG needs to focus > its efforts on RSVP-TE as protocol for traffic engineering > signaling and that the WG charter should be updated accordingly. > > - There is a clear majority for discontinuing work on CR-LDP. > However, there is no IETF process to "de-standardize" an existing > proposed standard that would apply in this situation. Thus > CR-LDP will remain a proposed standard. > > To this end: > > - Existing WG drafts related to or updating/changing CR-LDP will > be progressed according to normal procedures. > > - the Working Group will take on no new WG documents related to > CR-LDP. > > - A message will be sent to the relevant standards organizations > notifying them of this change of focus on MPLS signaling protocols. > > Loa and George > > -- From owner-mpls@UU.NET Fri Aug 23 02: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 CAA24500 for ; Fri, 23 Aug 2002 02:07:30 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndcq25304 for ; Fri, 23 Aug 2002 06:08: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 QQndcq23595; Fri, 23 Aug 2002 06:08:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQndcq15603 for mpls-outgoing; Fri, 23 Aug 2002 06:07: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 QQndcq15588 for ; Fri, 23 Aug 2002 06:07:39 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 QQndcq12761 for ; Fri, 23 Aug 2002 06:07: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 QQndcq03829 for ; Fri, 23 Aug 2002 06:07:25 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQndcq03819 for ; Fri, 23 Aug 2002 06:07:24 GMT Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by blooper.utfors.se (Utfors AB) with ESMTP id g7N66qHa022232; Fri, 23 Aug 2002 08:06:52 +0200 (MEST) Message-ID: <3D65D0FC.3040107@utfors.se> Date: Fri, 23 Aug 2002 08:06:52 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mattsquire@acm.org CC: mpls wg , Scott Bradner , George Swallow , Bert Wijnen Subject: Re: a step towards consensus on mpls signaling protocol References: <3D654672.1030005@utfors.se> <3D659B46.B614067B@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Matt, here are the mpls wg list of documents that we are talking about, all are through wg last call and has been reviewed by wg chairs. Signalling Unnumbered Links in CR-LDP draft-ietf-mpls-crldp-unnum-07.txt Improving Topology Data Base Accuracy with LSP Feedback in CR-LDP draft-ietf-mpls-te-feed-04.txt Fault Tolerance for LDP and CR-LDP draft-ietf-mpls-ldp-ft-04.txt Multi Protocol Label Switching Label Distribution Protocol Query Message Description draft-ietf-mpls-lsp-query-04.txt All of them are in or about to be sent to the IESG for review. Point here is that most of them has parts that address ldp (i.e. non cr-ldp issues) that we want to progress. My take on this is that there are much less work for the wg to follow "normal procedures" for those documents, and that this would not put us in a situation that is different from what we have for the existing rfcs (proposed) that is based on cr-ldp. Of course there are lots of thing that may happen down the road. If one of those documents gets sent back to the wg (authors) by the IESG because a new revision is needed, it is up to the authors or wg to take a decision on how to handle this. There are also some possible impact on the mibs, that I don't have a clear picture of - any of the mib-authors that has a view on the impact of this decision. Then there are documents that is owned by other working groups, those working groups needs to make their own decisions. Of course this my opinion, if there is support for "individualize" the existing cr-ldp, first thing we've to do is to make sure that we have a defined procedure to do so. /Loa Matt Squire wrote: > Loa - > > I think you're doing the right thing going with only RSVP-TE. But as > for continuing the CR-LDP work...why? It can certainly be continued as > individual contributions, but why put the burden on the group to > manage/review additions to something we as a group have decided isn't in > our future? Personal opinion is that current CR-LDP work be moved to > individual contributions outside of the WG activities. > > - Matt > -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Fri Aug 23 02:14: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 CAA28951 for ; Fri, 23 Aug 2002 02:14:41 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndcr14336 for ; Fri, 23 Aug 2002 06:16: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 QQndcq11946; Fri, 23 Aug 2002 06:14:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQndcq16834 for mpls-outgoing; Fri, 23 Aug 2002 06:14: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 QQndcq16829 for ; Fri, 23 Aug 2002 06:14: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 QQndcq00525 for ; Fri, 23 Aug 2002 06:14: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 QQndcq06417 for ; Fri, 23 Aug 2002 06:14:36 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQndcq06404 for ; Fri, 23 Aug 2002 06:14:35 GMT Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by blooper.utfors.se (Utfors AB) with ESMTP id g7N6EGHa022367; Fri, 23 Aug 2002 08:14:16 +0200 (MEST) Message-ID: <3D65D2B8.1080409@utfors.se> Date: Fri, 23 Aug 2002 08:14:16 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: David Meyer CC: mpls wg , Scott Bradner , George Swallow , Bert Wijnen Subject: Re: a step towards consensus on mpls signaling protocol References: <3D654672.1030005@utfors.se> <20020822132353.B20378@sprint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit David, the main argument not to make historic has been that there are organizations outside the IETF that reference the cr-ldp spec. Re-classifying it would cause problems for those organizations. By telling them that it is our intention not to further progress the cr-ldp, we given them time to revisit this issue and take the actions they need. /Loa David Meyer wrote: >>> - There is a clear majority for discontinuing work on CR-LDP. >>> However, there is no IETF process to "de-standardize" an existing >>> proposed standard that would apply in this situation. Thus >>> CR-LDP will remain a proposed standard. >>> > > Send it to historic, a la RFC 3166/3167, or someone will make me > implement it. > > >>>To this end: >>> >>> - Existing WG drafts related to or updating/changing CR-LDP will >>> be progressed according to normal procedures. >>> >>> - the Working Group will take on no new WG documents related to >>> CR-LDP. >>> >>> - A message will be sent to the relevant standards organizations >>> notifying them of this change of focus on MPLS signaling protocols. >>> > > Again, can we send it to historic or is there some procedural > (or other reason) not to do this? > > Dave > > -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Fri Aug 23 09:46: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 JAA06690 for ; Fri, 23 Aug 2002 09:46:06 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnddv06678 for ; Fri, 23 Aug 2002 13:47: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 QQnddu29181; Fri, 23 Aug 2002 13:43:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnddu04726 for mpls-outgoing; Fri, 23 Aug 2002 13:42: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 QQnddu04721 for ; Fri, 23 Aug 2002 13:42: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 QQnddu22389 for ; Fri, 23 Aug 2002 13:42: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 QQnddu23982 for ; Fri, 23 Aug 2002 13:42:35 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnddu23978 for ; Fri, 23 Aug 2002 13:42:34 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA03814 for ; Fri, 23 Aug 2002 09:42:34 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7NDgYD12789 for mpls@uu.net; Fri, 23 Aug 2002 09:42:34 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQndbf09269 for ; Thu, 22 Aug 2002 20:45: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 QQndbe13407 for ; Thu, 22 Aug 2002 20:44: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 QQndbe20676 for ; Thu, 22 Aug 2002 20:44:48 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f47.law4.hotmail.com [216.33.149.47]) id QQndbe20666 for ; Thu, 22 Aug 2002 20:44:48 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Aug 2002 13:44:47 -0700 Received: from 47.248.0.42 by lw4fd.law4.hotmail.msn.com with HTTP; Thu, 22 Aug 2002 20:44:46 GMT X-Originating-IP: [47.248.0.42] From: "Ye Ding" To: mpls@UU.NET Subject: Any vendor support for LLC/SNAP+shim header for MPLS over ATM Date: Thu, 22 Aug 2002 16:44:46 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Aug 2002 20:44:47.0573 (UTC) FILETIME=[C0E77850:01C24A1C] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a question and think that most of you out there could help me. Just wondering if any vendor currently supports LLC/SNAP encapsulation+shim header for MPLS over ATM. In this case, label is not placed in Vpi/Vci field of ATM Cell, but only in the shim header. LLC/SNAP could be used to identify that the MPLS is carried inside. Then what is the number allocated for MPLS? Thanks for any help. Ye _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Fri Aug 23 10:12: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 KAA07296 for ; Fri, 23 Aug 2002 10:12:19 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnddw09666 for ; Fri, 23 Aug 2002 14:13: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 QQnddw07005; Fri, 23 Aug 2002 14:11:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnddw00606 for mpls-outgoing; Fri, 23 Aug 2002 14:11:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnddw00531 for ; Fri, 23 Aug 2002 14:11: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 QQnddw02444 for ; Fri, 23 Aug 2002 14:11:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnddw06447 for ; Fri, 23 Aug 2002 14:11:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnddw06438 for ; Fri, 23 Aug 2002 14:11:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA05929 for ; Fri, 23 Aug 2002 10:11:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7NEB3n16723 for mpls@uu.net; Fri, 23 Aug 2002 10:11:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnddw29804 for ; Fri, 23 Aug 2002 14:10:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnddw14016 for ; Fri, 23 Aug 2002 14:09: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 QQnddw17619 for ; Fri, 23 Aug 2002 14:09:39 GMT Received: from hawk.CrescentNetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144]) id QQnddw17612 for ; Fri, 23 Aug 2002 14:09:39 GMT Received: from CrescentNetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id KAA17529; Fri, 23 Aug 2002 10:09:28 -0400 (EDT) Message-ID: <3D66424C.F9F9B66F@CrescentNetworks.com> Date: Fri, 23 Aug 2002 10:10:20 -0400 From: Joan Cucchiara X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Loa Andersson CC: mattsquire@acm.org, mpls wg , Scott Bradner , George Swallow , Bert Wijnen Subject: Re: a step towards consensus on mpls signaling protocol References: <3D654672.1030005@utfors.se> <3D659B46.B614067B@acm.org> <3D65D0FC.3040107@utfors.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Loa, I believe that both draft-ietf-mpls-tc-mib-03.txt and draft-ietf-mpls-te-mib-08.txt fall into this same category. These MIBs have gone through working group last call(s) and IESG review process. They are being updated by mib co-authors. -Thanks, Joan Loa Andersson wrote: > > Matt, > > here are the mpls wg list of documents that we are talking about, > all are through wg last call and has been reviewed by wg chairs. > > Signalling Unnumbered Links in CR-LDP > draft-ietf-mpls-crldp-unnum-07.txt > > Improving Topology Data Base Accuracy with > LSP Feedback in CR-LDP > draft-ietf-mpls-te-feed-04.txt > > Fault Tolerance for LDP and CR-LDP > draft-ietf-mpls-ldp-ft-04.txt > > Multi Protocol Label Switching Label Distribution Protocol > Query Message Description > draft-ietf-mpls-lsp-query-04.txt > > All of them are in or about to be sent to the IESG for review. > Point here is that most of them has parts that address ldp (i.e. > non cr-ldp issues) that we want to progress. My take on this is > that there are much less work for the wg to follow "normal > procedures" for those documents, and that this would not put > us in a situation that is different from what we have for the > existing rfcs (proposed) that is based on cr-ldp. > > Of course there are lots of thing that may happen down the road. > If one of those documents gets sent back to the wg (authors) by > the IESG because a new revision is needed, it is up to the authors > or wg to take a decision on how to handle this. > > There are also some possible impact on the mibs, that I don't > have a clear picture of - any of the mib-authors that has a view > on the impact of this decision. > > Then there are documents that is owned by other working groups, > those working groups needs to make their own decisions. > > Of course this my opinion, if there is support for "individualize" > the existing cr-ldp, first thing we've to do is to make sure that > we have a defined procedure to do so. > > /Loa > > Matt Squire wrote: > > > Loa - > > > > I think you're doing the right thing going with only RSVP-TE. But as > > for continuing the CR-LDP work...why? It can certainly be continued as > > individual contributions, but why put the burden on the group to > > manage/review additions to something we as a group have decided isn't in > > our future? Personal opinion is that current CR-LDP work be moved to > > individual contributions outside of the WG activities. > > > > - Matt > > > > -- > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > Råsundavägen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se From owner-mpls@UU.NET Fri Aug 23 11:03: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 LAA08921 for ; Fri, 23 Aug 2002 11:03:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndea12579 for ; Fri, 23 Aug 2002 15:05: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 QQndea10299; Fri, 23 Aug 2002 15:03:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQndea16791 for mpls-outgoing; Fri, 23 Aug 2002 15:03:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQndea16772 for ; Fri, 23 Aug 2002 15:03: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 QQndea23459 for ; Fri, 23 Aug 2002 15:03: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 QQndea05179 for ; Fri, 23 Aug 2002 15:03:09 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQndea05165 for ; Fri, 23 Aug 2002 15:03:08 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 LAA09637 for ; Fri, 23 Aug 2002 11:03:08 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7NF38k22907 for mpls@uu.net; Fri, 23 Aug 2002 11:03:08 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQndea08452 for ; Fri, 23 Aug 2002 15:02: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 QQndea24943 for ; Fri, 23 Aug 2002 15:01: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 QQndea04744 for ; Fri, 23 Aug 2002 15:01:40 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQndea04739 for ; Fri, 23 Aug 2002 15:01:39 GMT Received: from JVASSEUR-W2K.cisco.com (ch2-dhcp134-177.cisco.com [161.44.134.177]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA04494; Fri, 23 Aug 2002 17:01:28 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020823105753.03db4ea0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Aug 2002 11:01:26 -0400 To: Shahram Davari From: Jean Philippe Vasseur Subject: RE: Comments on Fast Reroute draft Cc: "'Ping Pan'" , "'mpls@UU.net'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB0383F@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 Hi Shahram, At 06:21 23/08/2002 -0700, Shahram Davari wrote: >Jean, > >I meant central. right, the bypass LSP paths could be calculated: - in a distributed manner by the PLRs o without bw protection (just easy, as the only constraint is to be diversely routed from the protected section), o with bandwidth protection (one method being described in draft-vasseur-mpls-backup-computation-00.txt) - by a central PCS (one method being described in draft-vasseur-mpls-backup-computation-00.txt) Thanks for your comments on both drafts. JP. >-Shahram > > > -----Original Message----- > > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > > Sent: Thursday, August 22, 2002 6:16 PM > > To: Shahram Davari > > Cc: 'Ping Pan'; 'mpls@UU.net' > > Subject: RE: Comments on Fast Reroute draft > > > > > > Hi Sharam, > > > > Sorry for the late reply .... > > > > At 11:16 09/08/2002 -0700, Shahram Davari wrote: > > >Ping, > > > > > >draft-vasseur-mpls-backup-computation-00.txt is also proposing > > >non-local bypass tunnel computation. Has this draft also > > been rejected? > > > > could you clarify what was your original point regarding non > > local bypass > > tunnel path computation ? > > JP. > > > > >-Shahram > > > > > > > > > > > > > -----Original Message----- > > > > From: Ping Pan [mailto:pingpan@cs.columbia.edu] > > > > Sent: Friday, August 09, 2002 2:12 PM > > > > To: Shahram Davari > > > > Cc: 'mpls@UU.net' > > > > Subject: Re: Comments on Fast Reroute draft > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > Ping, > > > > > > > > > >>The ingress does not need to compute the bypass tunnel. > > > > Bypass tunnel > > > > >>computation could be a local decision. > > > > >> > > > > >>http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastrerout > > > > >> > > > > > e-mib-00.txt > > > > > > > > > > > > > > > But it may also be a non-local decision. > > > > > > > > > > -Shahram > > > > > > > > > > > > > > > > > I think MPLS WG had gone through this argument before (there > > > > was a draft > > > > on this). I recall nobody wanted it. The question was why. > > > > Also are we > > > > going to design a RSVP fragmentation extension to support large > > > > messages? ;-) > > > > > > > > - Ping > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Aug 23 11:10: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 LAA09032 for ; Fri, 23 Aug 2002 11:10:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndea22854 for ; Fri, 23 Aug 2002 15:11: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 QQndea18960; Fri, 23 Aug 2002 15:09:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQndea22459 for mpls-outgoing; Fri, 23 Aug 2002 15:08:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQndea21764 for ; Fri, 23 Aug 2002 15:08: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 QQndea20578 for ; Fri, 23 Aug 2002 15:08: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 QQndea07655 for ; Fri, 23 Aug 2002 15:08:11 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQndea07651 for ; Fri, 23 Aug 2002 15:08:11 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA10063 for ; Fri, 23 Aug 2002 11:08:11 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7NF8B223697 for mpls@uu.net; Fri, 23 Aug 2002 11:08:11 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQndea18722 for ; Fri, 23 Aug 2002 15:07: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 QQndea02687 for ; Fri, 23 Aug 2002 15:06: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 QQndea18377 for ; Fri, 23 Aug 2002 15:06:45 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 QQndea18352 for ; Fri, 23 Aug 2002 15:06:44 GMT Received: (qmail 5651 invoked by uid 104); 23 Aug 2002 15:06:43 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4218. . Clean. Processed in 1.086411 secs); 23 Aug 2002 15:06:43 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 23 Aug 2002 15:06:41 -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 g7NF6fw05563; Fri, 23 Aug 2002 08:06:41 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 08:07:39 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03841@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Jean Philippe Vasseur'" Cc: "'Ping Pan'" , "'mpls@UU.net'" Subject: RE: Comments on Fast Reroute draft Date: Fri, 23 Aug 2002 08:06:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Jean, My question was basically why not compute the bypass LSPs at the ingress LSRs? Yours, -Shahram > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Friday, August 23, 2002 11:01 AM > To: Shahram Davari > Cc: 'Ping Pan'; 'mpls@UU.net' > Subject: RE: Comments on Fast Reroute draft > > > Hi Shahram, > > At 06:21 23/08/2002 -0700, Shahram Davari wrote: > >Jean, > > > >I meant central. > > right, the bypass LSP paths could be calculated: > - in a distributed manner by the PLRs > o without bw protection (just easy, as the only > constraint is to > be diversely routed from the protected section), > o with bandwidth protection (one method being described in > draft-vasseur-mpls-backup-computation-00.txt) > - by a central PCS (one method being described in > draft-vasseur-mpls-backup-computation-00.txt) > > Thanks for your comments on both drafts. > > JP. > > >-Shahram > > > > > -----Original Message----- > > > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > > > Sent: Thursday, August 22, 2002 6:16 PM > > > To: Shahram Davari > > > Cc: 'Ping Pan'; 'mpls@UU.net' > > > Subject: RE: Comments on Fast Reroute draft > > > > > > > > > Hi Sharam, > > > > > > Sorry for the late reply .... > > > > > > At 11:16 09/08/2002 -0700, Shahram Davari wrote: > > > >Ping, > > > > > > > >draft-vasseur-mpls-backup-computation-00.txt is also proposing > > > >non-local bypass tunnel computation. Has this draft also > > > been rejected? > > > > > > could you clarify what was your original point regarding non > > > local bypass > > > tunnel path computation ? > > > JP. > > > > > > >-Shahram > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ping Pan [mailto:pingpan@cs.columbia.edu] > > > > > Sent: Friday, August 09, 2002 2:12 PM > > > > > To: Shahram Davari > > > > > Cc: 'mpls@UU.net' > > > > > Subject: Re: Comments on Fast Reroute draft > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > Ping, > > > > > > > > > > > >>The ingress does not need to compute the bypass tunnel. > > > > > Bypass tunnel > > > > > >>computation could be a local decision. > > > > > >> > > > > > > >>http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastrerout > > > > > >> > > > > > > e-mib-00.txt > > > > > > > > > > > > > > > > > > But it may also be a non-local decision. > > > > > > > > > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > I think MPLS WG had gone through this argument before (there > > > > > was a draft > > > > > on this). I recall nobody wanted it. The question was why. > > > > > Also are we > > > > > going to design a RSVP fragmentation extension to > support large > > > > > messages? ;-) > > > > > > > > > > - Ping > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Aug 23 12:38: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 MAA11397 for ; Fri, 23 Aug 2002 12:38:38 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndeg20212 for ; Fri, 23 Aug 2002 16:40: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 QQndeg17730; Fri, 23 Aug 2002 16:38:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQndeg28044 for mpls-outgoing; Fri, 23 Aug 2002 16:38:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQndeg28029 for ; Fri, 23 Aug 2002 16:37:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQndeg18227 for ; Fri, 23 Aug 2002 16:37: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 QQndeg04940 for ; Fri, 23 Aug 2002 16:37:31 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 QQndeg04934 for ; Fri, 23 Aug 2002 16:37:31 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 MAA16995 for ; Fri, 23 Aug 2002 12:37:31 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7NGbV704534 for mpls@uu.net; Fri, 23 Aug 2002 12:37:31 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQndef26816 for ; Fri, 23 Aug 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 QQndef20951 for ; Fri, 23 Aug 2002 16:16: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 QQndef07746 for ; Fri, 23 Aug 2002 16:16:44 GMT Received: from sith.maoz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sith.maoz.com [205.167.76.10]) id QQndef07738 for ; Fri, 23 Aug 2002 16:16:44 GMT Received: (from dmm@localhost) by sith.maoz.com (8.12.2/8.12.2) id g7NGGmI9024131; Fri, 23 Aug 2002 09:16:48 -0700 Date: Fri, 23 Aug 2002 09:16:48 -0700 From: David Meyer To: Loa Andersson Cc: mpls wg , Scott Bradner , George Swallow , Bert Wijnen Subject: Re: a step towards consensus on mpls signaling protocol Message-ID: <20020823091648.A24124@sprint.net> References: <3D654672.1030005@utfors.se> <20020822132353.B20378@sprint.net> <3D65D2B8.1080409@utfors.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D65D2B8.1080409@utfors.se>; from loa.andersson@utfors.se on Fri, Aug 23, 2002 at 08:14:16AM +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Again, my concern is that is if it is left as proposed it will wind up on an RFP somewhere, and folks will be forced to implement it in order to respond. It's already happened. Dave On Fri, Aug 23, 2002 at 08:14:16AM +0200, Loa Andersson wrote: >> David, >> >> the main argument not to make historic has been that there are >> organizations outside the IETF that reference the cr-ldp spec. >> Re-classifying it would cause problems for those organizations. >> By telling them that it is our intention not to further progress >> the cr-ldp, we given them time to revisit this issue and take the >> actions they need. >> >> /Loa >> >> David Meyer wrote: >> >> >>> - There is a clear majority for discontinuing work on CR-LDP. >> >>> However, there is no IETF process to "de-standardize" an existing >> >>> proposed standard that would apply in this situation. Thus >> >>> CR-LDP will remain a proposed standard. >> >>> >> > >> > Send it to historic, a la RFC 3166/3167, or someone will make me >> > implement it. >> > >> > >> >>>To this end: >> >>> >> >>> - Existing WG drafts related to or updating/changing CR-LDP will >> >>> be progressed according to normal procedures. >> >>> >> >>> - the Working Group will take on no new WG documents related to >> >>> CR-LDP. >> >>> >> >>> - A message will be sent to the relevant standards organizations >> >>> notifying them of this change of focus on MPLS signaling protocols. >> >>> >> > >> > Again, can we send it to historic or is there some procedural >> > (or other reason) not to do this? >> > >> > Dave >> > >> > >> >> >> -- >> Loa Andersson >> Chief Architect, >> Utfors Research, Architecture and Future Lab (URAX) >> Utfors AB >> Råsundavägen 12 >> Box 525, 169 29 Solna >> Office +46 8 5270 2000 >> Office direct +46 8 5270 5038 >> Mobile +46 70 848 5038 >> Email loa.andersson@utfors.se >> WWW www.utfors.se >> From owner-mpls@UU.NET Fri Aug 23 12:59:57 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11880 for ; Fri, 23 Aug 2002 12:59:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndei18395 for ; Fri, 23 Aug 2002 17:01: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 QQndeh15746; Fri, 23 Aug 2002 16:59:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQndeh29854 for mpls-outgoing; Fri, 23 Aug 2002 16:59: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 QQndeh29849 for ; Fri, 23 Aug 2002 16:59:35 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 QQndeh17334 for ; Fri, 23 Aug 2002 16:59: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 QQndeh15265 for ; Fri, 23 Aug 2002 16:59:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQndeh15241 for ; Fri, 23 Aug 2002 16:59:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA18473 for ; Fri, 23 Aug 2002 12:59:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7NGx2I07920 for mpls@uu.net; Fri, 23 Aug 2002 12:59:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQndef26816 for ; Fri, 23 Aug 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 QQndef20951 for ; Fri, 23 Aug 2002 16:16: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 QQndef07746 for ; Fri, 23 Aug 2002 16:16:44 GMT Received: from sith.maoz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sith.maoz.com [205.167.76.10]) id QQndef07738 for ; Fri, 23 Aug 2002 16:16:44 GMT Received: (from dmm@localhost) by sith.maoz.com (8.12.2/8.12.2) id g7NGGmI9024131; Fri, 23 Aug 2002 09:16:48 -0700 Date: Fri, 23 Aug 2002 09:16:48 -0700 From: David Meyer To: Loa Andersson Cc: mpls wg , Scott Bradner , George Swallow , Bert Wijnen Subject: Re: a step towards consensus on mpls signaling protocol Message-ID: <20020823091648.A24124@sprint.net> References: <3D654672.1030005@utfors.se> <20020822132353.B20378@sprint.net> <3D65D2B8.1080409@utfors.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D65D2B8.1080409@utfors.se>; from loa.andersson@utfors.se on Fri, Aug 23, 2002 at 08:14:16AM +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Again, my concern is that is if it is left as proposed it will wind up on an RFP somewhere, and folks will be forced to implement it in order to respond. It's already happened. Dave On Fri, Aug 23, 2002 at 08:14:16AM +0200, Loa Andersson wrote: >> David, >> >> the main argument not to make historic has been that there are >> organizations outside the IETF that reference the cr-ldp spec. >> Re-classifying it would cause problems for those organizations. >> By telling them that it is our intention not to further progress >> the cr-ldp, we given them time to revisit this issue and take the >> actions they need. >> >> /Loa >> >> David Meyer wrote: >> >> >>> - There is a clear majority for discontinuing work on CR-LDP. >> >>> However, there is no IETF process to "de-standardize" an existing >> >>> proposed standard that would apply in this situation. Thus >> >>> CR-LDP will remain a proposed standard. >> >>> >> > >> > Send it to historic, a la RFC 3166/3167, or someone will make me >> > implement it. >> > >> > >> >>>To this end: >> >>> >> >>> - Existing WG drafts related to or updating/changing CR-LDP will >> >>> be progressed according to normal procedures. >> >>> >> >>> - the Working Group will take on no new WG documents related to >> >>> CR-LDP. >> >>> >> >>> - A message will be sent to the relevant standards organizations >> >>> notifying them of this change of focus on MPLS signaling protocols. >> >>> >> > >> > Again, can we send it to historic or is there some procedural >> > (or other reason) not to do this? >> > >> > Dave >> > >> > >> >> >> -- >> Loa Andersson >> Chief Architect, >> Utfors Research, Architecture and Future Lab (URAX) >> Utfors AB >> Råsundavägen 12 >> Box 525, 169 29 Solna >> Office +46 8 5270 2000 >> Office direct +46 8 5270 5038 >> Mobile +46 70 848 5038 >> Email loa.andersson@utfors.se >> WWW www.utfors.se >> From owner-mpls@UU.NET Fri Aug 23 13:42: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 NAA12813 for ; Fri, 23 Aug 2002 13:42:39 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndek28456 for ; Fri, 23 Aug 2002 17:44: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 QQndek25829; Fri, 23 Aug 2002 17:42:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQndek27483 for mpls-outgoing; Fri, 23 Aug 2002 17:42: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 QQndek27478 for ; Fri, 23 Aug 2002 17:42: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 QQndek29084 for ; Fri, 23 Aug 2002 17:41: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 QQndek11654 for ; Fri, 23 Aug 2002 17:41:55 GMT Received: from emerson.torrentnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: emerson.torrentnet.com [198.78.51.110]) id QQndek11648 for ; Fri, 23 Aug 2002 17:41:55 GMT Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g7NHfn064776; Fri, 23 Aug 2002 13:41:49 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g7NHfmj15366; Fri, 23 Aug 2002 13:41:48 -0400 (EDT) Received: from oldmonk (oldmonk.torrentnet.com [4.18.161.44]) by castillo.torrentnet.com (8.9.3/8.9.3) with SMTP id NAA24794; Fri, 23 Aug 2002 13:41:47 -0400 (EDT) From: "Sumit Garg" To: "'Ye Ding'" , Subject: RE: Any vendor support for LLC/SNAP+shim header for MPLS over ATM Date: Fri, 23 Aug 2002 13:41:46 -0400 Message-ID: <000701c24acc$5ae02ce0$2ca11204@torrentnet.com> 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.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ye, Ericsson and Juniper support this. If I recall correctly the number is 0x8847 /Sumit > Hi, > > I have a question and think that most of you out there could help me. > > Just wondering if any vendor currently supports LLC/SNAP > encapsulation+shim > header for MPLS over ATM. In this case, label is not placed > in Vpi/Vci field > of ATM Cell, but only in the shim header. > > LLC/SNAP could be used to identify that the MPLS is carried > inside. Then > what is the number allocated for MPLS? > > Thanks for any help. > > Ye > From owner-mpls@UU.NET Fri Aug 23 14:12: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 OAA13455 for ; Fri, 23 Aug 2002 14:12:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndem28171 for ; Fri, 23 Aug 2002 18:13: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 QQndem25388; Fri, 23 Aug 2002 18:11:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQndem23213 for mpls-outgoing; Fri, 23 Aug 2002 18:11: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 QQndem23127 for ; Fri, 23 Aug 2002 18:11:13 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 QQndem24863 for ; Fri, 23 Aug 2002 18:11:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndem14243 for ; Fri, 23 Aug 2002 18:11:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQndem14239 for ; Fri, 23 Aug 2002 18:11:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24206 for ; Fri, 23 Aug 2002 14:11:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7NIB3q16273 for mpls@uu.net; Fri, 23 Aug 2002 14:11:03 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQndem22429 for ; Fri, 23 Aug 2002 18:09:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQndem22229 for ; Fri, 23 Aug 2002 18:08: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 QQndem23748 for ; Fri, 23 Aug 2002 18:08:46 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 QQndem23736 for ; Fri, 23 Aug 2002 18:08:45 GMT Received: (qmail 22181 invoked by uid 104); 23 Aug 2002 18:08:44 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4218. . Clean. Processed in 0.896586 secs); 23 Aug 2002 18:08:44 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 23 Aug 2002 18:08:43 -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 g7NI8gw05446; Fri, 23 Aug 2002 11:08:42 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 11:09:41 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03842@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Anna Charny'" Cc: "'mpls@UU.net'" Subject: RE: Comments on Backup-Computation draft Date: Fri, 23 Aug 2002 11:08:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Anna, Sorry for delay in response. Please see my comments in-line. -Shahram > -----Original Message----- > From: Anna Charny [mailto:acharny@cisco.com] > Sent: Thursday, August 15, 2002 5:35 PM > To: Shahram Davari > Cc: 'mpls@UU.net' > Subject: Re: Comments on Backup-Computation draft > > > Hi Shahram, > > First, thanks for all your comments! Please see in-line: > > At 10:48 AM 8/9/2002 -0700, Shahram Davari wrote: > >Hi, > > > >I have a few comments regarding this draft: > > > >1) Section 3, does not seem to indicate that it is possible > to request > >local protection and BW protection by only using the > Session_Attribute. > >Why is that? > > We did not mean to say that it is not possible to do so. > Both modes (using > the SESSIONJ-ATTRIBUTE object or the FAST REROUTE object) are > supported in > the FRR draft. We will try to clarify the text to make sure > it is clear. OK. > > >2) Many parts of the draft says PLR SHOULD send path_Error > to the ingress LSR. > >While the fast-reroute draft says MAY. Which one is correct? > > You are right, we will change the SHOULD to MAY to be > compliant with the > fast-reroute draft OK. > > >3) The term "backup tunnel" is used in this draft to mean > "Bypass tunnel". > >Please follow the terms as defined in the fast-reroute draft. > > Yes, you are quite right - we will make sure we use the > proper term. Thanks. OK. > > >4) Section 5.1 says: > > > >"Note also that the single failure assumption needed for > such bandwidth > >sharing is a pre-requisite to any protection approach which uses pre- > >computed backup tunnels -" > > > >Do you mean it is pre-requisite for this draft? Otherwise it > can't be > >pre-requisite for any protection approach. > > What we meant to say really is something very simple. If you want to > protect, say, against *any* N failures with N>1, then > pre-computed backup > paths simply cannot do the job (in the worst case at least), > as you can > always have one failure in the primary and another failure in > the backup > even if they are completely link and node disjoint. We will > try to modify > the text to make it more clear. OK. > > >5) Section 5.1 says: > > > >"However, achieving such sharing using explicit bandwidth > reservations > >for the backup tunnels requires extensive signaling and routing > >extensions: > > - routing extensions propagating the set of backup LSPs as > > well as their bandwidth and the element(s) they protect [BP- > > PLACEMENT]. In [lakshman]it was proposed to substantially > > reduce the amount of state that needs to be > propagated in the > > routing updates at the price of sacrificing the amount of > > achievable sharing. " > > > >This is not accurate. If you use the configuration method > advised in this > >draft or use the extension you propose to IGP in this draft, there is > >no need for any more extensions to routing. > > We did not mean a general statement here - we were just > pointing out the > properties of the two *other* schemes currently proposed for > bandwidth sharing. > You are right that our draft does not need any more routing > extensions than > we defined (and that was one of the reasons we thought it may > be useful), > and those extensions are needed just for a distributed case. So I suggest changing the first sentence to: However, achieving such sharing using explicit bandwidth reservations as defined in draft X and draft Y for the backup tunnels requires extensive signaling and routing extensions. > > >Also Fast_reroute draft already proposes extensions to the > signaling. So > >extension to signaling should not be an issue. And I even > think the same > >extensions could be used here by the head-end for signaling. > > we were talking about signaling extensions in the first of > the references > in our text that you quote. These are extensions that are > necessary to > convey the information pertaining specifically to bandwidth > sharing. Such > extensions are not defined in the fast-reroute draft. My point was that you are criticizing the other methods because you say they requires extensions to signaling for admission control, but yet you are introducing similar extensions in your draft. > > >6) Appendix A gives an example which is easily solvable > using the text from > >other parts of this draft. The solution is using 2 Bypass > tunnel for the R2-R3 > >link as following: > > > >R2-R6-R7-R4 = 5M > >R2-R8-R9-R4 = 5M > > > >So it is possible to use independent CSPF at PLRs. > > First let me point out that the issue of independent CSPF > computation, > although we believe correct, is really a secondary point in > the draft, the > primary point being the ability to provide bandwidth sharing > between backup > tunnels protecting against independent failures. > > Regarding the independent CSPF issue, you are right that if > you allow > load-balancing, then this particular example can be solved. > However, in > the context of facility backup (which is the context of our > draft), it will > be undesirable to have a large number of such load-balanced tunnels > protecting a single facility. We were assuming that in > practice one would > want to limit the number of such "splits" of a single backup > tunnel into > several smaller ones would be limited by some fixed number. > In fact, if > you upper bound the number of splits by some N, then for each N it is > possible to give an example when independent CSPF will not > find a solution, > when the solution actually exists. > We gave an example for N=1. Of course examples for larger N > will be more > complicated. 1) N=2 or 3 is very practical and in fact will probably cover most cases. 2) Even in your proposal (in which you limit N=1) it is possible not to find a solution, even if one exists. So I don't think 100% possibility of finding a solution should be a criteria, since no method exists to do that. > > But again, this really is not the key issue in our draft. I > guess one can > view the ability to find better solutions than in the case of > independent > CSPF as a pleasant side benefit of our approach rather that > its motivation. May be, but again you are comparing and criticizing other methods for the very same reason. > > >7) Section 6.1.1 criticizes that if a PLR is computing the > Backup tunnel, then > >it needs signaling to enable an LSR distinguish between > primary and Backup > >LSP. > >But the Fast_Reroute draft ha already defined these > extensions and making > >use of them. So there is no need for any extra signaling. > > I was under the impression that fast-reroute defines such > extensions for > the detour case but not for the bypass case (which is the one > our draft > discusses). For the BYPASS case, one cannot make the > distinction between a > primary and a bypass LSP that's why signalling non 0 bw > bypass tunnel would > require some additions in signalling. Also the CAC should be modified. Since you used the term backup tunnel instead of bypass tunnel, I thought you are talking about backup tunnels. The FRR draft only distinguishes between backup and primary, but not bypass and primary. But another question is, if zero BW signaling is done, then how can the ingress LSRs know how much BW is used for bypass tunnel in those links so that they don't use it for any primary LSPs? By a fixed backup pool? > > >8) Section 6.2.1 suggests finding the backup pool, by > subtracting the > >global reservable BW from the link BW. How does a node know > the link BW to > >do this computation? > > Here is an example with OSPF (link TLV of the TE opaque LSA): > > Sub-TLV 6 - Maximum Bandwidth > > The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that > can be used on this link in this direction (from the system > originating the LSA to its neighbor), in IEEE floating > point format. > This is the true link capacity. > > Sub-TLV 7 - Maximum Reservable Bandwidth > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link in this direction, in > IEEE floating point format > > Maximum bandwidth - Maximum Reservable Bandwidth = Backup > bandwidth pool. OK. > > > > >9) Section 6.2.4: What happens if all NNHOPs are part of the SRLG? > > Could you please clarify your example and your question? A-----B-----C-----D-----E | | | | -----F-----G-----H Assume B wants to compute bypass tunnel for itself and the A-B link. It will compute: AFB for AB link faliure and AFGC for itself's failure. But what if C is part of the same SRLG as B? Seems that B can't compute for example AFGHD in that case. Right? > > > >10) Section 7: Can't the L1 detect the L1 defects? In that > case the node > >and link failures could be distinguished. > > I do not see how L1 can tell whether it is just the link that > failed, or > whether it was really the node on the other end that failed > AND brought the > link down with it? If you loose the light, it means the link has failed. > > >11) Finally, let me provide you with an alternative, simpler > proposal: > > > >Let only the Ingress LSRs (head-end) do the TE and Bypass tunnel > >computation. Here is how: > > > >If a Bypass tunnel is required at a PLR node, the ingress > LSR can check > >the RRO object in the RESV message to see whether, the node > or link that > >it wants has bypass tunnel or not. If a Bypass tunnel exists, fine, > >otherwise it will compute a bypass tunnel ( or more) and > indicate that, in > >its PATH message. The appropriate PLR will then use the > received PATH > >message to generate the Bypass tunnel(s). > > > >The advantage of this method is that it is distributed, and > doesn't need > >intermediate LSRs to do CSPF. Also as I mentioned the issue > of Appendix A > >is easily solvable using more than 1 Bypass tunnels. > > It seems to me that you describe a method to off-load the > bypass tunnel > path computation on the HE. But I do not understand how this proposal > addresses the key goal of our draft - namely the ability to share the > bandwidth between backup tunnels protecting independent > failures. Can you > please clarify? Let's assume a HE wants to have a backup tunnel to protect some link or node. and assume no bypass tunnel exist at that point. It can compute that based on the BW pool assigned to bypass tunnel and signal that backup tunnel in its PATH message. The PLR node will use that info to create a bypass tunnel (and backup tunnel). The PLR can signal zero BW for creation of bypass/backup tunnels. Yours, -Shahram > > Thanks, > Anna > > >Yours, > >Shahram > From owner-mpls@UU.NET Fri Aug 23 22:09: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 WAA22981 for ; Fri, 23 Aug 2002 22:09:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndfs14871 for ; Sat, 24 Aug 2002 02:11:05 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 QQndfs12323; Sat, 24 Aug 2002 02:09:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQndfs06066 for mpls-outgoing; Sat, 24 Aug 2002 02:09: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 QQndfs06059 for ; Sat, 24 Aug 2002 02:09: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 QQndfs28034 for ; Sat, 24 Aug 2002 02:09: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 QQndfs07421 for ; Sat, 24 Aug 2002 02:09:06 GMT Received: from im2.sec.tds.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: im2.mail.tds.net [216.170.230.92]) id QQndfs07417 for ; Sat, 24 Aug 2002 02:09:06 GMT Received: from akingw2k (lawa1pool0-a116.lacenter.tds.net [216.170.159.245]) by im2.sec.tds.net (8.12.3/8.12.3) with SMTP id g7O28kxQ008254; Fri, 23 Aug 2002 21:08:49 -0500 (CDT) Message-ID: <000f01c24b12$ed293330$f59faad8@akingw2k> Reply-To: "Art King" From: "Art King" To: "David Meyer" , "Loa Andersson" Cc: "mpls wg" , "Scott Bradner" , "George Swallow" , "Bert Wijnen" References: <3D654672.1030005@utfors.se> <20020822132353.B20378@sprint.net> <3D65D2B8.1080409@utfors.se> <20020823091648.A24124@sprint.net> Subject: Re: a step towards consensus on mpls signaling protocol Date: Fri, 23 Aug 2002 19:06:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Greetings, I hope this is the right group to address this inquiry to. I like the idea that two competing (approximately) signaling protocols are being reduced to one. Does this imply or is there a move to eliminate one or the other of the route distribution protocols (OSPF-TE and ISIS-TE) to further simply implementation and interop? Regards, Art ----- Original Message ----- From: "David Meyer" To: "Loa Andersson" Cc: "mpls wg" ; "Scott Bradner" ; "George Swallow" ; "Bert Wijnen" Sent: Friday, August 23, 2002 9:16 AM Subject: Re: a step towards consensus on mpls signaling protocol > Again, my concern is that is if it is left as proposed it will > wind up on an RFP somewhere, and folks will be forced to > implement it in order to respond. It's already happened. > > Dave > > On Fri, Aug 23, 2002 at 08:14:16AM +0200, Loa Andersson wrote: > >> David, > >> > >> the main argument not to make historic has been that there are > >> organizations outside the IETF that reference the cr-ldp spec. > >> Re-classifying it would cause problems for those organizations. > >> By telling them that it is our intention not to further progress > >> the cr-ldp, we given them time to revisit this issue and take the > >> actions they need. > >> > >> /Loa > >> > >> David Meyer wrote: > >> > >> >>> - There is a clear majority for discontinuing work on CR-LDP. > >> >>> However, there is no IETF process to "de-standardize" an existing > >> >>> proposed standard that would apply in this situation. Thus > >> >>> CR-LDP will remain a proposed standard. > >> >>> > >> > > >> > Send it to historic, a la RFC 3166/3167, or someone will make me > >> > implement it. > >> > > >> > > >> >>>To this end: > >> >>> > >> >>> - Existing WG drafts related to or updating/changing CR-LDP will > >> >>> be progressed according to normal procedures. > >> >>> > >> >>> - the Working Group will take on no new WG documents related to > >> >>> CR-LDP. > >> >>> > >> >>> - A message will be sent to the relevant standards organizations > >> >>> notifying them of this change of focus on MPLS signaling protocols. > >> >>> > >> > > >> > Again, can we send it to historic or is there some procedural > >> > (or other reason) not to do this? > >> > > >> > Dave > >> > > >> > > >> > >> > >> -- > >> Loa Andersson > >> Chief Architect, > >> Utfors Research, Architecture and Future Lab (URAX) > >> Utfors AB > >> Råsundavägen 12 > >> Box 525, 169 29 Solna > >> Office +46 8 5270 2000 > >> Office direct +46 8 5270 5038 > >> Mobile +46 70 848 5038 > >> Email loa.andersson@utfors.se > >> WWW www.utfors.se > >> > From owner-mpls@UU.NET Fri Aug 23 22:38: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 WAA23637 for ; Fri, 23 Aug 2002 22:38:19 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndfu11164 for ; Sat, 24 Aug 2002 02:39: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 QQndfu09581; Sat, 24 Aug 2002 02:38:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQndfu08447 for mpls-outgoing; Sat, 24 Aug 2002 02:38: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 QQndfu08440 for ; Sat, 24 Aug 2002 02:38:22 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 QQndfu03981 for ; Sat, 24 Aug 2002 02:37: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 QQndfu01431 for ; Sat, 24 Aug 2002 02:37:31 GMT Received: from web20608.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20608.mail.yahoo.com [216.136.226.166]) id QQndfu01427 for ; Sat, 24 Aug 2002 02:37:31 GMT Message-ID: <20020824023730.82472.qmail@web20608.mail.yahoo.com> Received: from [207.135.89.75] by web20608.mail.yahoo.com via HTTP; Fri, 23 Aug 2002 19:37:30 PDT Date: Fri, 23 Aug 2002 19:37:30 -0700 (PDT) From: satish dattatri Subject: Re: a step towards consensus on mpls signaling protocol To: Art King Cc: mpls wg In-Reply-To: <000f01c24b12$ed293330$f59faad8@akingw2k> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Art, Both ISIS-TE and OSPF-TE are deployed today. I don't think the same reduction magic works for the IGPs ;-) Satish --- Art King wrote: > Greetings, > > I hope this is the right group to address this inquiry to. > > I like the idea that two competing (approximately) > signaling protocols are being reduced to one. > > Does this imply or is there a move to eliminate one or the > other of the route distribution protocols (OSPF-TE and > ISIS-TE) to further simply implementation and interop? > > Regards, > > Art > > > ----- Original Message ----- > From: "David Meyer" > To: "Loa Andersson" > Cc: "mpls wg" ; "Scott Bradner" > ; "George > Swallow" ; "Bert Wijnen" > > Sent: Friday, August 23, 2002 9:16 AM > Subject: Re: a step towards consensus on mpls signaling > protocol > > > > Again, my concern is that is if it is left as proposed it > will > > wind up on an RFP somewhere, and folks will be forced to > > implement it in order to respond. It's already happened. > > > > Dave > > > > On Fri, Aug 23, 2002 at 08:14:16AM +0200, Loa Andersson > wrote: > > >> David, > > >> > > >> the main argument not to make historic has been that > there are > > >> organizations outside the IETF that reference the > cr-ldp spec. > > >> Re-classifying it would cause problems for those > organizations. > > >> By telling them that it is our intention not to > further progress > > >> the cr-ldp, we given them time to revisit this issue > and take the > > >> actions they need. > > >> > > >> /Loa > > >> > > >> David Meyer wrote: > > >> > > >> >>> - There is a clear majority for discontinuing > work on CR-LDP. > > >> >>> However, there is no IETF process to > "de-standardize" an > existing > > >> >>> proposed standard that would apply in this > situation. Thus > > >> >>> CR-LDP will remain a proposed standard. > > >> >>> > > >> > > > >> > Send it to historic, a la RFC 3166/3167, or someone > will make me > > >> > implement it. > > >> > > > >> > > > >> >>>To this end: > > >> >>> > > >> >>> - Existing WG drafts related to or > updating/changing CR-LDP will > > >> >>> be progressed according to normal procedures. > > >> >>> > > >> >>> - the Working Group will take on no new WG > documents related to > > >> >>> CR-LDP. > > >> >>> > > >> >>> - A message will be sent to the relevant > standards organizations > > >> >>> notifying them of this change of focus on MPLS > signaling > protocols. > > >> >>> > > >> > > > >> > Again, can we send it to historic or is there some > procedural > > >> > (or other reason) not to do this? > > >> > > > >> > Dave > > >> > > > >> > > > >> > > >> > > >> -- > > >> Loa Andersson > > >> Chief Architect, > > >> Utfors Research, Architecture and Future Lab > (URAX) > > >> Utfors AB > > >> Råsundavägen 12 > > >> Box 525, 169 29 Solna > > >> Office +46 8 5270 2000 > > >> Office direct +46 8 5270 5038 > > >> Mobile +46 70 848 5038 > > >> Email loa.andersson@utfors.se > > >> WWW www.utfors.se > > >> > > > __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From owner-mpls@UU.NET Fri Aug 23 22:44: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 WAA23760 for ; Fri, 23 Aug 2002 22:44:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndfv05338 for ; Sat, 24 Aug 2002 02:46: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 QQndfv02903; Sat, 24 Aug 2002 02:45:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQndfu08682 for mpls-outgoing; Sat, 24 Aug 2002 02:44: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 QQndfu08677 for ; Sat, 24 Aug 2002 02:44:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQndfu20609 for ; Sat, 24 Aug 2002 02:44: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 QQndfu06215 for ; Sat, 24 Aug 2002 02:44:00 GMT Received: from im2.sec.tds.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: im2.mail.tds.net [216.170.230.92]) id QQndfu06210 for ; Sat, 24 Aug 2002 02:44:00 GMT Received: from akingw2k (lawa1pool0-a116.lacenter.tds.net [216.170.159.245]) by im2.sec.tds.net (8.12.3/8.12.3) with SMTP id g7O2hkxO014811; Fri, 23 Aug 2002 21:43:47 -0500 (CDT) Message-ID: <001601c24b17$ce5e9030$f59faad8@akingw2k> Reply-To: "Art King" From: "Art King" To: "satish dattatri" Cc: "mpls wg" References: <20020824023730.82472.qmail@web20608.mail.yahoo.com> Subject: Re: a step towards consensus on mpls signaling protocol Date: Fri, 23 Aug 2002 19:41:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Satish, OK, wasn't sure with the extension work coming up for multi-area TE would force a choice on all of us due to depth of telecom winter we're in... Thanks, Art ----- Original Message ----- From: "satish dattatri" To: "Art King" Cc: "mpls wg" Sent: Friday, August 23, 2002 7:37 PM Subject: Re: a step towards consensus on mpls signaling protocol > Art, > Both ISIS-TE and OSPF-TE are deployed today. > I don't think the same reduction magic works for the > IGPs ;-) > Satish > > --- Art King wrote: > > Greetings, > > > > I hope this is the right group to address this inquiry to. > > > > I like the idea that two competing (approximately) > > signaling protocols are being reduced to one. > > > > Does this imply or is there a move to eliminate one or the > > other of the route distribution protocols (OSPF-TE and > > ISIS-TE) to further simply implementation and interop? > > > > Regards, > > > > Art > > > > > > ----- Original Message ----- > > From: "David Meyer" > > To: "Loa Andersson" > > Cc: "mpls wg" ; "Scott Bradner" > > ; "George > > Swallow" ; "Bert Wijnen" > > > > Sent: Friday, August 23, 2002 9:16 AM > > Subject: Re: a step towards consensus on mpls signaling > > protocol > > > > > > > Again, my concern is that is if it is left as proposed it > > will > > > wind up on an RFP somewhere, and folks will be forced to > > > implement it in order to respond. It's already happened. > > > > > > Dave > > > > > > On Fri, Aug 23, 2002 at 08:14:16AM +0200, Loa Andersson > > wrote: > > > >> David, > > > >> > > > >> the main argument not to make historic has been that > > there are > > > >> organizations outside the IETF that reference the > > cr-ldp spec. > > > >> Re-classifying it would cause problems for those > > organizations. > > > >> By telling them that it is our intention not to > > further progress > > > >> the cr-ldp, we given them time to revisit this issue > > and take the > > > >> actions they need. > > > >> > > > >> /Loa > > > >> > > > >> David Meyer wrote: > > > >> > > > >> >>> - There is a clear majority for discontinuing > > work on CR-LDP. > > > >> >>> However, there is no IETF process to > > "de-standardize" an > > existing > > > >> >>> proposed standard that would apply in this > > situation. Thus > > > >> >>> CR-LDP will remain a proposed standard. > > > >> >>> > > > >> > > > > >> > Send it to historic, a la RFC 3166/3167, or someone > > will make me > > > >> > implement it. > > > >> > > > > >> > > > > >> >>>To this end: > > > >> >>> > > > >> >>> - Existing WG drafts related to or > > updating/changing CR-LDP will > > > >> >>> be progressed according to normal procedures. > > > >> >>> > > > >> >>> - the Working Group will take on no new WG > > documents related to > > > >> >>> CR-LDP. > > > >> >>> > > > >> >>> - A message will be sent to the relevant > > standards organizations > > > >> >>> notifying them of this change of focus on MPLS > > signaling > > protocols. > > > >> >>> > > > >> > > > > >> > Again, can we send it to historic or is there some > > procedural > > > >> > (or other reason) not to do this? > > > >> > > > > >> > Dave > > > >> > > > > >> > > > > >> > > > >> > > > >> -- > > > >> Loa Andersson > > > >> Chief Architect, > > > >> Utfors Research, Architecture and Future Lab > > (URAX) > > > >> Utfors AB > > > >> Råsundavägen 12 > > > >> Box 525, 169 29 Solna > > > >> Office +46 8 5270 2000 > > > >> Office direct +46 8 5270 5038 > > > >> Mobile +46 70 848 5038 > > > >> Email loa.andersson@utfors.se > > > >> WWW www.utfors.se > > > >> > > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com From owner-mpls@UU.NET Mon Aug 26 14:55: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 OAA18755 for ; Mon, 26 Aug 2002 14:55:38 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndpr22437 for ; Mon, 26 Aug 2002 18:57: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 QQndpr19781; Mon, 26 Aug 2002 18:55:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQndpr29753 for mpls-outgoing; Mon, 26 Aug 2002 18:55: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 QQndpr29742 for ; Mon, 26 Aug 2002 18:55: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 QQndpr11498 for ; Mon, 26 Aug 2002 18:54: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 QQndpr19306 for ; Mon, 26 Aug 2002 18:54:49 GMT Received: from tomp.smb.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQndpr19297 for ; Mon, 26 Aug 2002 18:54:48 GMT Received: from utfors.se ([195.58.105.104]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id H1GSSB00.L6Z; Mon, 26 Aug 2002 21:00:11 +0200 Message-ID: <3D6A7978.5010200@utfors.se> Date: Mon, 26 Aug 2002 20:54:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mpls wg CC: George Swallow , Fiffi Hellstrand , Vishal Sharma , Scott Bradner Subject: iesg comments on the revovery framework Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, we've received the comments from the IESG on the draft-ietf-mpls-recovery-frmwrk. Since the comments to a certain extent addresses issues that are - related to the workings of the sub-ip area - what and how things should be done within the mpls group - what is need as input from other the requirment specifying wgs to start any work within wgs that do protocol specification in the sub-ip area I've chosen to send the comments to the wg mailing list. While it is clear that we often take requirments from e.g. ccamp and te-wg iyt is not clear that this is the only requirment source. I've de-personalized the comments somewhat, since it is normally easier to discuss the issues that way. Question is if the wg group feels that there always need to that requirment traceability from te-wg via ccamp to mpls, or whether there are work that is started because it is within the mpls charter or comes out of other wgs, e.g. the ppvpn group? If the latter is the case, does the requirment traceability requirment apply to this particular draft anyhow? /Loa AD wrote: > the IESG talked about draft-ietf-mpls-recovery-frmwrk on the call today > > two issues came up: > > (from nn) > 2/ how does this document relate to the requirements expressed in > draft-ietf-tewg-restore-hierarchy-01.txt? in what ways does > it not meet requirements? in what ways does it exceed them, > and if any, why? > > and, the sub-ip area architecture would seem to require a > requirements/protocol path from the tewg requirements, through > a common control and management plane, and then to the low- > level path mechanisms. i was unable to follow this logical > path. without it, how can one judge this work? > > > AD > -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Tue Aug 27 22:03: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 WAA20269 for ; Tue, 27 Aug 2002 22:03:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndum18444 for ; Wed, 28 Aug 2002 02:04: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 QQndum16478; Wed, 28 Aug 2002 02:03:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQndum16438 for mpls-outgoing; Wed, 28 Aug 2002 02:03:08 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 QQndum16431 for ; Wed, 28 Aug 2002 02:02: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 QQndum05352 for ; Wed, 28 Aug 2002 02:02: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 QQndum16063 for ; Wed, 28 Aug 2002 02:02:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQndum16054 for ; Wed, 28 Aug 2002 02:02:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA29950 for ; Tue, 27 Aug 2002 22:02:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7S222Q16394 for mpls@uu.net; Tue, 27 Aug 2002 22:02:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQndum10807 for ; Wed, 28 Aug 2002 02:01: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 QQndum03145 for ; Wed, 28 Aug 2002 02:00: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 QQndum08780 for ; Wed, 28 Aug 2002 02:00:42 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [161.44.168.94]) id QQndum08768 for ; Wed, 28 Aug 2002 02:00:41 GMT Received: from ACHARNY-W2K1.cisco.com (acharny-frame1.cisco.com [10.84.14.34]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA13865; Tue, 27 Aug 2002 22:00:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20020827160808.023b83a8@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Aug 2002 22:00:35 -0400 To: Shahram Davari From: Anna Charny Subject: RE: Comments on Backup-Computation draft Cc: "'mpls@UU.net'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03842@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 Hi Shahram, cutting out some text irrelevant to the remaining issues under the discussion: > > > > >5) Section 5.1 says: > > > > > >"However, achieving such sharing using explicit bandwidth > > reservations > > >for the backup tunnels requires extensive signaling and routing > > >extensions: > > > - routing extensions propagating the set of backup LSPs as > > > well as their bandwidth and the element(s) they protect [BP- > > > PLACEMENT]. In [lakshman]it was proposed to substantially > > > reduce the amount of state that needs to be > > propagated in the > > > routing updates at the price of sacrificing the amount of > > > achievable sharing. " > > > > > >This is not accurate. If you use the configuration method > > advised in this > > >draft or use the extension you propose to IGP in this draft, there is > > >no need for any more extensions to routing. > > > > We did not mean a general statement here - we were just > > pointing out the > > properties of the two *other* schemes currently proposed for > > bandwidth sharing. > > You are right that our draft does not need any more routing > > extensions than > > we defined (and that was one of the reasons we thought it may > > be useful), > > and those extensions are needed just for a distributed case. > >So I suggest changing the first sentence to: > >However, achieving such sharing using explicit bandwidth >reservations as defined in draft X and draft Y for the backup tunnels >requires extensive signaling and routing extensions. We will clarify the text, thanks. > > > > >Also Fast_reroute draft already proposes extensions to the > > signaling. So > > >extension to signaling should not be an issue. And I even > > think the same > > >extensions could be used here by the head-end for signaling. > > > > we were talking about signaling extensions in the first of > > the references > > in our text that you quote. These are extensions that are > > necessary to > > convey the information pertaining specifically to bandwidth > > sharing. Such > > extensions are not defined in the fast-reroute draft. > > >My point was that you are criticizing the other methods because >you say they requires extensions to signaling for admission >control, but yet you are introducing similar extensions in >your draft. Well, maybe we did not make it clear enough, so let me try to explain. draft-leroux-mpls-bypass-placement-00.txt that achieves complete bandwidth sharing introduces MANY more routing extensions than we do. On the other hand, draft-kini-restoration-shared-backup-01.txt does indeed offer much fewer extensions (comparable to what our drafts suggests), but it does not result in complete sharing. What we propose therefore differs from the former in the amount of extensions, and it differs from the latter in the ability to share all sharable bandwidth. > > > > >6) Appendix A gives an example which is easily solvable > > using the text from > > >other parts of this draft. The solution is using 2 Bypass > > tunnel for the R2-R3 > > >link as following: > > > > > >R2-R6-R7-R4 = 5M > > >R2-R8-R9-R4 = 5M > > > > > >So it is possible to use independent CSPF at PLRs. > > > > First let me point out that the issue of independent CSPF > > computation, > > although we believe correct, is really a secondary point in > > the draft, the > > primary point being the ability to provide bandwidth sharing > > between backup > > tunnels protecting against independent failures. > > > > Regarding the independent CSPF issue, you are right that if > > you allow > > load-balancing, then this particular example can be solved. > > However, in > > the context of facility backup (which is the context of our > > draft), it will > > be undesirable to have a large number of such load-balanced tunnels > > protecting a single facility. We were assuming that in > > practice one would > > want to limit the number of such "splits" of a single backup > > tunnel into > > several smaller ones would be limited by some fixed number. > > In fact, if > > you upper bound the number of splits by some N, then for each N it is > > possible to give an example when independent CSPF will not > > find a solution, > > when the solution actually exists. > > We gave an example for N=1. Of course examples for larger N > > will be more > > complicated. > >1) N=2 or 3 is very practical and in fact will probably cover >most cases. >2) Even in your proposal (in which you limit N=1) it is possible > not to find a solution, even if one exists. > >So I don't think 100% possibility of finding a solution should be >a criteria, since no method exists to do that. You are quite right - since the problem of is NP complete noone can claim the ability to find solutions in 100% of all cases. But it is the matter of relative success of different approaches. All we are saying is that since there is more information available in our approach, it is capable of finding a solution in many more cases. Note that we do not discuss any particular algorithm for the computation - clearly the relative success of finding a solution depends on exactly what algorithm is used. But again, this is a secondary point in our draft... > > > > But again, this really is not the key issue in our draft. I > > guess one can > > view the ability to find better solutions than in the case of > > independent > > CSPF as a pleasant side benefit of our approach rather that > > its motivation. > >May be, but again you are comparing and criticizing other methods for >the very same reason. well, strictly speaking all we are saying is that in our approach you can find a solution more frequently than with distributed CSPF. And that is a fact that our example intended to demonstrate. > > > > >7) Section 6.1.1 criticizes that if a PLR is computing the > > Backup tunnel, then > > >it needs signaling to enable an LSR distinguish between > > primary and Backup > > >LSP. > > >But the Fast_Reroute draft ha already defined these > > extensions and making > > >use of them. So there is no need for any extra signaling. > > > > I was under the impression that fast-reroute defines such > > extensions for > > the detour case but not for the bypass case (which is the one > > our draft > > discusses). For the BYPASS case, one cannot make the > > distinction between a > > primary and a bypass LSP that's why signalling non 0 bw > > bypass tunnel would > > require some additions in signalling. Also the CAC should be modified. > >Since you used the term backup tunnel instead of bypass tunnel, I thought >you are talking about backup tunnels. The FRR draft only distinguishes between >backup and primary, but not bypass and primary. > >But another question is, if zero BW signaling is done, then how can the >ingress LSRs >know how much BW is used for bypass tunnel in those links so that they >don't use >it for any primary LSPs? By a fixed backup pool? Well, in our approach the ingress LSR does not need to know about bandwidth requirements of any bypass tunnels other than those for which it itself is responsible or for which it is the headend. All the intelligence about the bandwidth usage and requirements is concentrated locally on each LSR that is responsible for the computation of the backup tunnels for itself and/or a set of links. To give an example for node protection only, each LSR knows how much bandwidth that goes *through itself* it needs to protect, and it also has a global view of the fixed backup bandwidth pool on all links to know how much bandwidth is available to place the bypass tunnels protecting against its own failure. Does this answer your question? > > > > > > > >9) Section 6.2.4: What happens if all NNHOPs are part of the SRLG? > > > > Could you please clarify your example and your question? > > > A-----B-----C-----D-----E > | | | | > -----F-----G-----H > > >Assume B wants to compute bypass tunnel for itself and the A-B link. It >will compute: > >AFB for AB link faliure and AFGC for itself's failure. But what if C is >part of the same SRLG as B? Seems that B can't compute for example AFGHD >in that case. Right? Right. In the current version of the draft we only consider nhop and nnhop tunnels. We also were assuming that SRLGs contain links but not nodes. In principle, our approach can be generalized to deal with these issues, but we have not done it yet. > > > > > > >10) Section 7: Can't the L1 detect the L1 defects? In that > > case the node > > >and link failures could be distinguished. > > > > I do not see how L1 can tell whether it is just the link that > > failed, or > > whether it was really the node on the other end that failed > > AND brought the > > link down with it? > >If you loose the light, it means the link has failed. No, I do not think that is right. If you do not see light on the link, you surely know that the link failed, but what you do not know is whether the node on the other end has ALSO failed. And we do need to know whether that node is alive or not. > > > > > >11) Finally, let me provide you with an alternative, simpler > > proposal: > > > > > >Let only the Ingress LSRs (head-end) do the TE and Bypass tunnel > > >computation. Here is how: > > > > > >If a Bypass tunnel is required at a PLR node, the ingress > > LSR can check > > >the RRO object in the RESV message to see whether, the node > > or link that > > >it wants has bypass tunnel or not. If a Bypass tunnel exists, fine, > > >otherwise it will compute a bypass tunnel ( or more) and > > indicate that, in > > >its PATH message. The appropriate PLR will then use the > > received PATH > > >message to generate the Bypass tunnel(s). > > > > > >The advantage of this method is that it is distributed, and > > doesn't need > > >intermediate LSRs to do CSPF. Also as I mentioned the issue > > of Appendix A > > >is easily solvable using more than 1 Bypass tunnels. > > > > It seems to me that you describe a method to off-load the > > bypass tunnel > > path computation on the HE. But I do not understand how this proposal > > addresses the key goal of our draft - namely the ability to share the > > bandwidth between backup tunnels protecting independent > > failures. Can you > > please clarify? > >Let's assume a HE wants to have a backup tunnel to protect some link or node. >and assume no bypass tunnel exist at that point. It can compute that based >on the BW pool >assigned to bypass tunnel and signal that backup tunnel in its PATH >message. The PLR node will use that info to create a bypass tunnel (and >backup tunnel). The PLR can signal zero BW for creation of bypass/backup >tunnels. You have explained how a bypass tunnel of zero bandwidth can be created. But I do not think you have explained how the bandwidth of the bypass tunnel created this way can be shared with other bypass tunnels traversing the same links but protecting against failures of other elements, while simultaneously ensuring a bandwidth guarantee in the case of any single failure. Could you please elaborate on exactly how bandwidth sharing with bandwidth guarantees are achieved in your approach? Thanks, Anna >Yours, >-Shahram > > > > > Thanks, > > Anna > > > > >Yours, > > >Shahram > > From owner-mpls@UU.NET Wed Aug 28 10:45: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 KAA02444 for ; Wed, 28 Aug 2002 10:45:18 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndwl21951 for ; Wed, 28 Aug 2002 14:46:39 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 QQndwk16946; Wed, 28 Aug 2002 14:43:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQndwk13960 for mpls-outgoing; Wed, 28 Aug 2002 14:43:12 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 QQndwk13953 for ; Wed, 28 Aug 2002 14:42: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 QQndwk09697 for ; Wed, 28 Aug 2002 14:42: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 QQndwk23855 for ; Wed, 28 Aug 2002 14:42:04 GMT Received: from mail.softplan.com.br by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [200.247.107.133]) id QQndwk23780 for ; Wed, 28 Aug 2002 14:42:00 GMT Received: from soft086 ([200.247.107.254]) by mail.softplan.com.br with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 11:40:54 -0300 Message-Id: <3.0.3.32.20020828114357.0099a7c0@200.247.107.133> X-Sender: morvan@200.247.107.133 (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 28 Aug 2002 11:43:57 -0300 To: mpls@UU.NET From: Morvan Daniel =?iso-8859-1?Q?M=FCller?= Subject: (draft) end-2-end auth proposal for LDP (design) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1030556637==_" X-OriginalArrivalTime: 28 Aug 2002 14:40:54.0444 (UTC) FILETIME=[E9D2DEC0:01C24EA0] Sender: owner-mpls@UU.NET Precedence: bulk --=====================_1030556637==_ Content-Type: text/plain; charset="us-ascii" Hi all! I'm brasiliam, excuse about english erros :)! I' implementing a draft proposal discuted in dec/2001 by this wkg. - I attached it. I try contact authors without success in the last weeks. (They know about my implementation and give me very important help when I start this project in a few months ago). The implementation is very closed (I'm changing source forge linux ldp-portable implementation). (I have a doubt for a long time) but now at implementation level I conclude that its impossible implement the proposal like its explained. It need probably some estructural changes. Please I need help from experts on LDP operation, so this list is the best place :)! Basically this is the proposal scenario: LER A LSR 1 LSR n LER B | | | | | auth LDP Request | | auth LDP Request | |------->-------------|------->---------|------->-------------| | auth LDP MAP | | auth LDP MAP | |--------<------------|-------<---------|----------<----------| | | | | I firts list my doubts and after I explain the proposal, OK: I have 2 doubts. Doubt (1) is critical (2) only to confirm: 1) when LERA send the Request for some FEC: It don't know that LERB will be the egress OK?. But the proposal consider that LERA know the remote peer LERB when send the label request, and use it to choose the correspondent mac-function-secretkey shared by LERA-LERB, it is not possible in my vision? On alternative solution would be create some tlv with meaning to return the egress LSRid for some FEC (a new feature into LDP). I'm not sure if it justifiable. Someone have ideas? 2) the proposal list as requirement ONLY ordered-control, but is considering one request for every map, so "on-demand-distribution" is implicit, so it would be a requirement, OK? I try to explain as clean possible how the proposal works: Application Scenario: authenticate the FIRST LSP between Ingress and Egress end-to-end; - destinated for non-adjacent LSRs (LERA-LERB) (without e2e TCP/LDP session), so TCP Md5 signature option not apply. - it requires LDP ordered control - define 2 new TLVs: Mac-Tlv and Nonce-Tlv - macTlv = srcLSRID + macdigest of (labelrequest/labelmap fields) - MAC function (Mac-TLV) provide authentication and Integrity protection - defined MAC fuction is Hmac-sha1 - NonceTLV: a every increase nonce value provide anti-replay protection. - no confidenciality its provided - intermediary LSRs only bypass (authentication Tlvs) end-to-end cause, f-bit=1 and u-bit=1 into the new TLVs. - Each LSR need to have locally a list with possible peers as follow: PEER-LSR-ID1 : key_identifierA : mac_keyA PEER-LSR-ID1 : key_identifierB : mac_keyB PEER-LSR-ID2 : key_identifier : mac_key Obs: with "key Identifier" peers could use one key for reqw and other for map, for example. - LDP msgs used to transport authentication tlvs: Label_Request Label_Mapping Ldp_notification ( status_code="authentication failed" ) - The use of authentication is a local police matter of the LSR (mutual agreement between the 2 LSRs who want setup the LSP). The Process: ============= 1)LERA encode a label_request, insert a "nonce tlv" and a "mac tlv" and sent it to LERB. a) The MAC Tlv need to be the last tlv of the pdu. b) LERA can determine which mac-key to use cause it knows the remote LSR entity with wich it is setting up the LSP. HERE MY DOUBT???????????????????? (HOW LERA KNOW IT, Request is based on FECs not destLSR-ID) - LSR1..LSRn bypass the authentication tlvs cause f-bit=1 and u-bit=1. This intermediary LSRs can't change the tlvs oder into the LDP_PDU; - LERB receive the PDU and verify the authentication tlvs: - determine the originator LSR, - thanks the "key Identifier" can determine the respective local mac-key - apply the same MAC function and match against received mac value: * if match successfull: a authenticated "label_mapping" is returned to LERA * if match fail: a authenticated "label_notify" with status "authentication failed" is returned to LERA. - If LERA could successfull authenticate the label_mapping, the LSP is established. ============================= complementar information ================ - New defined TLVs for LDP: 1) MAC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| MAC (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key Identifier | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | LSR Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC authentication value | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit: the Unknown-bit must be set to '1' because intermediate LSRs that do not know this new TLV should ignore it and process the rest of the message. F-bit: the Forward-bit must be set to '1' because intermediate LSRs that do not know this new TLV should transparently relay this TLV to the next LSR. Length: this field indicates the total length in bytes of the following fields. Key Identifier: this field identifies the shared secret key used by the MAC generator so that the receiver can determine which shared secret key to use to verify the MAC value, in case both entities share more than one such secret key. LSR Identifier: this field contains an identifier of the authenticating entity to be used by the LSR receiver in the MAC verification process. MAC authentication value: this field contains the MAC value generated as described in "MAC generation", bellow. The MAC TLV must be the last TLV of the LDP message. 2) NONCE 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Nonce (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Nonce value | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit and F-bit: must be set to '1', same as in MAC TLV. Length: this field indicates the length in bytes of the nonce value field. Nonce value: this field contains a unique value that must increase for every message exchanged between two LSRs. A timestamp value is an example of such an increasing counter. Both sides must keep track of the last value used by the partner to be able to verify the increasing nature of the nonce value received. The Nonce TLV must appear prior to the MAC TLV in any place of the LDP PDU. MAC generation 3) MAC generation/Verify procedures The input into the MAC generation algorithm depends on the type of message. For LDP Label Request and Label Mapping messages, the input is the byte stream built as described in the following figure (the Adapted Length represents the actual length of this byte stream, not the length of the real LDP Request message). 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 +-+-----------------------------+-------------------------------+ |0| Message type | Adapted Length | +-+-----------------------------+-------------------------------+ | key Identifier | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | LSR Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce TLV | | | +---------------------------------------------------------------+ | | | FEC TLV | +---------------------------------------------------------------+ For LDP Notification messages, the input is the byte stream built as described in the following figure. 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 +-+-----------------------------+-------------------------------+ |0| Notification | Adapted Length | +-+-----------------------------+-------------------------------+ | key Identifier | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | LSR Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce TLV | | | +---------------------------------------------------------------+ | | | Status TLV | +---------------------------------------------------------------+ 4) New Notification message "Authentication Failed" Status Code A new Status Code value is required in the LDP Notification message Status TLV. This code is used by an LSR to announce that a previously received LDP message has failed authentication. The U-bit and F-bit in the Status TLV must be set to '1' so as to enable transparent relay of the Status TLV by LSRs. The E-bit in the Status Code field of the Status TLV can be set to '0' or '1' depending on the local policy of the LSR. The F-bit in the Status Code field of the Status TLV MUST be set to '1', in alignment with the F-bit at the Status TLV level. Thanks, Morvan. --=====================_1030556637==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-schrijvp-mpls-ldp-end-to-end-auth-03-mar2001.txt" INTERNET DRAFT Jeremy De Clercq Olivier Paridaens Yves T'Joens Peter De Schrijver Alcatel February, 2001 Expires August, 2001 End to end authentication for LDP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Label Distribution Protocol (LDP), as currently defined, makes use of the TCP MD5 Signature option to protect (authentication and integrity) the LDP traffic between two adjacent LSRs. This document specifies extensions to LDP to enable end-to-end authentication between non-adjacent LSR's (ie not directly connected via a TCP connection) that are setting up an LSP. Two mechanisms are defined that also provide integrity protection of the information carried within LDP messages and protect against the malicious replay of LDP messages. Both proposed mechanisms require ordered control LDP and can also be applied to CR-LDP. 1. Introduction De Schrijver, et al Expires May 2001 [Page 1] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 In its current state, LDP specifies the use of the TCP MD5 Signature option in order to provide integrity and authentication of LDP messages (in addition to protecting the TCP dialog itself). This mechanism, apart from being considered rather weak because it makes use of a simple keyed MD5 function, can only be used between two adjacent LSRs exchanging LDP messages over a TCP connection. It does not cover situations where LSRs exchange LDP messages via other intermediate LSRs for setting up an LSP. It can be noted that other technologies such as IPsec or TLS could adequately be used in place of the TCP MD5 Signature option in order to provide LSR hop-by-hop security. This document proposes two mechanisms to enable such non-adjacent LSRs to authenticate LDP messages mutually exchanged. The first solution makes use of a digital signature attached to each LDP message. This mechanism enables not only the receiving LER to authenticate the LDP message but also intermediate LSR's to do so. In addition, the proposed solution also provides integrity protection of the information carried within LDP messages and anti-replay of previous messages. The second proposed solution makes use of a Message Authentication Code (MAC) attached to each LDP message. It enables the receiving LER to authenticate the LDP message but not intermediaries. It also provides integrity protection and anti- replay. As described more precisely below, both the digital signature-based and MAC-based solutions provide data integrity and can be used to protect LDP messages in broadcast contexts (basic discovery mechanism). Finally, they also protect against replay attacks by inserting a sequence number in each LDP message. The mechanism described herein does not provide end-to-end confidentiality, as Labelling information is not considered of a confidential nature. It requires ordered control LDP and can be applied to CR-LDP. An example scenario is when LER A wants to set up a LSP with LER B. Both LERs A and B make use of a MPLS backbone (illustrated by LSR 1 and LSR n in the figure below). LER A and LER B individually trust the MPLS backbone provider but yet require mutual authentication between both of them to set up the LSP. LER A uses ordered control LDP and sends a LDP request message to the first LSR on the path towards LER B. LER A adds authentication information to the LDP request message so that LER B can verify the identity of LER A requesting a LSP. When LER B receives this new LDP request message, it can verify the signature or MAC and hence authenticate LER A. If authentication succeeds, LER B will generate a LDP Map message (which De Schrijver, et al Expires May 2001 [Page 2] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 could itself also be signed or MAC'ed by LER B). If authentication fails, a LDP Notification message will be sent to report this authentication failure (notification which can itself be signed or MAC'ed by LER B). The schema below illustrates this scenario, where LER B positively authenticates the LDP Request message and returns an authenticated LDP Map message. LER A LSR 1 LSR n LER B | | | | | | | | | signed LDP Request | | signed LDP Request | |------->-------------|------->---------|------->-------------| | | | | | | | | | | | | | | | | | signed LDP MAP | | signed LDP MAP | |--------<------------|-------<---------|----------<----------| | | | | 2. Conventions The keywords "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 [RFC2119]. 3. Digital Signature authentication method This authentication method is based on the use of a digital signature that is attached to each LDP message exchanged between both LERs. This method is bi-directional as each LER can append a signature to each LDP message it sends. The input into the signature algorithm is basically made of parts of the LDP message that are not subject to change end-to-end, as further described in section 3.2. Anti-replay is provided through the use of a sequence number. This sequence number is added by the message originator to the LDP message within a (new) Nonce TLV. The nonce value should take the form of an ever increasing value such as a timestamp. Because this Nonce TLV is covered by the signature value (see section 3.2.1 for details), it cannot be changed "en route" and its increasing nature prohibits replaying the same or another message with that same Nonce TLV. 3.1. Digital signature-based authentication TLV's De Schrijver, et al Expires May 2001 [Page 3] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 3.1.1. Signature TLV A new TLV is defined to carry the digital signature value. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Signature (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | ID length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AlgID Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Algorithm Identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Signature value | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit: the Unknown-bit must be set to '1' because intermediate LSR's that do not know this new TLV should ignore it and process the rest of the message. F-bit: the Forward-bit must be set to '1' because intermediate LSR's that do not know this new TLV should transparently relay this TLV to the next LSR. Length: this field indicates the total length in bytes of the following fields. ID type: this field indicates the type of identifier carried in the Identifier field. Possible types are defined in 9.2. ID Length: this field indicates the length in bytes of the Identifier value. Identifier: this field contains an identifier of the signing entity to be used by the LSR receiver in the signature verification process (to obtain the corresponding certificate if not present in the LDP message). AlgID Length: this field indicates the length in bytes of the De Schrijver, et al Expires May 2001 [Page 4] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 Algorithm Identifier field. Algorithm Identifier: this field contains the signature algorithm identifier. Possible algorihtms are presented in section 9.1. Signature value: this field contains the signature value generated as described in section 3.2.1. Its length can be deduced from the TLV Length field and other fields lengths. 3.1.2. Certificate TLV A new TLV is defined to carry a certificate. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Certificate (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Type | | +-+-+-+-+-+-+-+-+ | | | | Certificate Value | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit: the Unknown-bit must be set to '1' because intermediate LSR's that do not know this new TLV should ignore it and process the rest of the message. F-bit: the Forward-bit must be set to '1' because intermediate LSR's that do not know this new TLV should transparently relay this TLV to the next LSR. Length: this field indicates the length in bytes of the Cert Type and Certificate Value fields. Cert Type: this field indicates the type of certificate carried in this TLV. Possible values are defined in RFC 2408 [RFC2408] section 3.9. Certificate Value: this field contains the certificate value. The Certificate TLV must appear anywhere in the LDP message prior to the Signature TLV. Several Certificate TLV's may be inserted into the LDP message if felt necessary for the LSR receiver to be able to verify the signature. Such a list of Certificate TLV's SHOULD be inserted in a continuous sequence of TLV's (ie no other TLV type De Schrijver, et al Expires May 2001 [Page 5] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 should appear in between). 3.1.3. Nonce TLV A new TLV is defined to carry a nonce value. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Nonce (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Nonce value | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit: the Unknown-bit must be set to '1' because intermediate LSR's that do not know this new TLV should ignore it and process the rest of the message. F-bit: the Forward-bit must be set to '1' because intermediate LSR's that do not know this new TLV should transparently relay this TLV to the next LSR. Length: this field indicates the length in bytes of the nonce value field. Nonce value: this field contains a unique value that must increase for every message exchanged between two LSRs. A timestamp value is an example of such an increasing counter. Both sides must keep track of the last value used by the partner to be able to verify the increasing nature of the nonce value received. The Nonce TLV must appear prior to the Signature TLV but not necessarily next to. 3.2. Digital signature-based authentication procedure 3.2.1. Sender When sending a LDP message, the originating LER creates and inserts a Nonce TLV. Certificate TLV's are also inserted if felt adequate to ease the receiving LER's signature verification. The Signature TLV is finally appended to the LDP message after having calculated the signature value. The Identifier field in the Signature TLV is used to carry the signer's identity so that the receiving LSR can match the certificate used for signature verification with the signer's De Schrijver, et al Expires May 2001 [Page 6] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 identity. The input into the signature algorithm depends on the type of message. For LDP Request and Label Mapping messages, the input is the byte stream built as described in the following figure (the Adapted Length represents the actual length of this byte stream, not the length of the real LDP Request message). The Nonce TLV prevents re-using the signature value for another LDP message. 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 +-+-----------------------------+-------------------------------+ |0| Message type | Adapted Length | +-+-----------------------------+-------------------------------+ | Nonce TLV | | | +---------------------------------------------------------------+ | | | FEC TLV | +---------------------------------------------------------------+ For LDP Notification messages, the input is the byte stream built as described in the following figure. 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 +-+-----------------------------+-------------------------------+ |0| Notification | Adapted Length | +-+-----------------------------+-------------------------------+ | Nonce TLV | | | +---------------------------------------------------------------+ | | | Status TLV | +---------------------------------------------------------------+ 3.2.2. Receiver Upon receiving a LDP message, the destination LER verifies the signature value present in the Signature TLV. Verification of the signature can be made easier thanks to the use of certificates in Certificate TLVs if present. The LSR should take care of ensuring that any certificate taken from a Certificate TLV is still valid by consulting some up-to-date CRL (Certificate Revocation List). The input into the signature verification algorithm is built De Schrijver, et al Expires May 2001 [Page 7] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 similarly to what is described in section 3.2.1 above. 3.2.3. Intermediary This mechanism enables intermediate LSR's to authenticate LDP messages being relayed. The intermediate LSR can indeed easily verify the digital signature attached to the LDP message as long as it has a copy of the sender's public key or can find it in a repository or LDP message itself. 3.3. Discussion This mechanism relies on the use of asymmetric public-key signature algorithms such as RSA and DSA. Each LSR must therefore possess its own key pair. Some form of Public Key Infrastructure (PKI) is also necessary to create certificates for LSRs public keys and distribute those certificates. Depending on the scenarios, a minimal form of PKI may be to distribute the certificates within the LDP messages themselves, as the Certificate TLV allows it. LSR's must also be preconfigured with the (possibly several) certification Authority (CA) root key(s). This mechanism does not require a prior shared knowledge between both LSRs (apart from having a common CA or being able to find a certification path between their two CAs). From the sender's perspective, the anti-replay mechanism will work if the sender can ensure that the nonce it is using increases over time (at least during the lifetime of the public key certificate currently in use). If the nonce is based on an increasing sequence number, this requires the sender to store the sequence number value last used in non volatile memory so that a correct sequence number is used after a reboot. If the nonce is based on a timestamp value, there is normally an internal time clock in the sender system that should work over reboot phases. If the internal clock system is volatile, a mechanism such as NTP can be used by the sender to reset a valid time after reboot. This will enable to maintain an increasing timestamp after a reboot. If it cannot be ensured that the nonce value increases over a reboot of the sender, the receiver will reject all messages received that have a nonce value less than the last one it itself had received before the sender reboots. From the receiver's perspective, the anti-replay mechanism will work if it is able to realize that the nonce value increases with each LDP message received. In case of receiver system failure so that the last nonce value received is forgotten, there is a potential for replay attacks. An attacker can indeed send replayed messages without the receiver detecting it. The replay opportunity will end when the De Schrijver, et al Expires May 2001 [Page 8] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 receiver has received the next message from the genuine sender, as this will set the nonce to the correct value (higher than any previously used). If both the sender and the receiver fail at the same time and both forget the current nonce value, it is possible for an attacker to replay old messages without being detected. It is a matter of local policy for a LSR (and implicitly mutual agreement between both LSRs) to decide whether to use end-to-end authentication when sending/receiving LDP messages with a particular partner. 4. Message Authentication Code authentication method This authentication method is based on the use of a MAC which is attached to each LDP message sent by a LSR entity. This method is bi-directional (both LSR entities can attach a MAC to their LDP messages). Both LSR entities must obviously share a secret value that is used to generate and verify the MAC attached to each message. The same or different shared secrets can be used for both directions. The input into the MAC function is basically made of the LDP message contents itself and the shared secret value. This therefore provides both message integrity and authentication. Anti-replay is provided through the use of a sequence number. This sequence number is added by the message sender to the LDP message within a (new) Nonce TLV. The nonce value should take the form of an ever increasing value such as a timestamp. Because this Nonce TLV is covered by the MAC authentication value (see section 4.2.1 for details), it cannot be changed "en route" and its increasing nature prohibits replaying the same or another message with that same Nonce TLV. Both LSR entities must be pre-configured with the shared secret value(s) and the name of the MAC algorithm to be used. This document makes provision for the use of HMAC-derived functions. 4.1. MAC-based authentication TLVs 4.1.1. MAC TLV A new TLV is defined to carry the MAC value. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| MAC (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ De Schrijver, et al Expires May 2001 [Page 9] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | ID length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC authentication value | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit: the Unknown-bit must be set to '1' because intermediate LSRs that do not know this new TLV should ignore it and process the rest of the message. F-bit: the Forward-bit must be set to '1' because intermediate LSRs that do not know this new TLV should transparently relay this TLV to the next LSR. Length: this field indicates the total length in bytes of the following fields. Key Identifier: this 4-bytes field identifies the shared secret key used by the MAC generator so that the receiver can determine which shared secret key to use to verify the MAC value, in case both entities share more than one such secret key. ID type: this field indicates the type of identifier carried in the Identifier field. Possible types are defined in 9.2. ID Length: this field indicates the length in bytes of the Identifier value. Identifier: this field contains an identifier of the authenticating entity to be used by the LSR receiver in the MAC verification process. MAC authentication value: this field contains the MAC value generated as described in section 4.2.1. The MAC TLV must be appended to the tail of the LDP message by the sender. 4.1.2. Nonce TLV A nonce TLV, as described in section 3.1.3, is used to carry a nonce De Schrijver, et al Expires May 2001 [Page 10] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 value. The Nonce TLV must appear prior to the MAC TLV but not necessarily next to. 4.2. MAC-based authentication procedure 4.2.1. Sender Before sending a LDP message, the sender creates a Nonce TLV which can be inserted at any place in the LDP message and a MAC TLV which will be appended at the tail of the message (as the last TLV). The sender can determine which shared secret and MAC algorithm to use as it knows with which remote LSR entity it is setting up an LSP. There is consequently no need to carry a selector of the MAC algorithm within the MAC TLV. A list of possible MAC algorithms is provided in section 9.2. As a general rule, lifetime of the shared secret key used between the two LSRs must be smaller than the time required for the Nonce field value to cycle; otherwise, an old message can be replayed. A nonce field of 8 bytes length should be sufficient. The input into the MAC generation algorithm depends on the type of message. For LDP Request and Label Mapping messages, the input is the byte stream built as described in the following figure (the Adapted Length represents the actual length of this byte stream, not the length of the real LDP Request message). 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 +-+-----------------------------+-------------------------------+ |0| Message type | Adapted Length | +-+-----------------------------+-------------------------------+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | ID length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce TLV | | | +---------------------------------------------------------------+ | | | FEC TLV | De Schrijver, et al Expires May 2001 [Page 11] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 +---------------------------------------------------------------+ For LDP Notification messages, the input is the byte stream built as described in the following figure. 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 +-+-----------------------------+-------------------------------+ |0| Notification | Adapted Length | +-+-----------------------------+-------------------------------+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | ID length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce TLV | | | +---------------------------------------------------------------+ | | | Status TLV | +---------------------------------------------------------------+ 4.2.2. Receiver When receiving a LDP message, the receiver can determine the actual message originator by looking at the Identifier field in the MAC TLV. The receiving LSR entity can then determine which shared secret and MAC function to use for verifying the MAC value thanks to the combination of the Identifier and the Key Identifier fields. The LDP message contents to be used as input into the MAC function is built in the same way as in 4.2.1. If verification of the MAC value fails, a LDP Notification message is returned with a code "authentication failed". 4.3. Discussion This method enables to provide integrity and authentication of every message exchanged between both non-adjacent LSR entities. It also provides an anti-replay mechanism. Both entities must be pre-configured with the shared secret value(s) and the MAC algorithm to be used for generating/verifying the MAC in both directions. De Schrijver, et al Expires May 2001 [Page 12] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 This mechanism requires that the order of TLV's within the LDP message is not changed by intermediate LSR entities. From the sender's perspective, the anti-replay mechanism will work if the sender can ensure that the nonce it is using increases over time (at least during the lifetime of the shared secret currently in use). If the nonce is based on an increasing sequence number, this requires the sender to store the sequence number value last used in non volatile memory so that a correct sequence number is used after a reboot. If the nonce is based on a timestamp value, there is normally an internal time clock in the sender system that should work over reboot phases. If the internal clock system is volatile, a mechanism such as NTP can be used by the sender to reset a valid time after reboot. This will enable to maintain an increasing timestamp after a reboot. If it cannot be ensured that the nonce value increases over a reboot of the sender, the receiver will reject all messages received that have a nonce value less than the last one it itself had received before the sender reboots. To avoid such a situation when the sender cannot guarantee that the nonce has increased after a reboot, the sender can start a process of changing the shared key in use (which may be a burden if manual key management is used). From the receiver's perspective, the anti-replay mechanism will work if it is able to realize that the nonce value increases with each LDP message received. In case of receiver system failure so that the last nonce value received is forgotten, there is a potential for replay attacks. An attacker can indeed send replayed messages without the receiver detecting it. The replay opportunity will end when the receiver has received the next message from the genuine sender, as this will set the nonce to the correct value (higher than any previously used). If both the sender and the receiver fail at the same time and both forget the current nonce value, it is possible for an attacker to replay old messages without being detected. It is a matter of local policy for a LSR (and implicitly mutual agreement between both LSRs) to decide whether to use end-to-end authentication when sending/receiving LDP messages with a particular partner. 5. New Notification message "Authentication Failed" Status Code A new Status Code value is required in the LDP Notification message Status TLV. This code is used by an LSR to announce that a previously received LDP message has failed authentication. The U-bit and F-bit in the Status TLV must be set to '1' so as to enable transparent relay of the Status TLV by LSRs. De Schrijver, et al Expires May 2001 [Page 13] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 The E-bit in the Status Code field of the Status TLV can be set to '0' or '1' depending on the local policy of the LSR. The F-bit in the Status Code field of the Status TLV MUST be set to '1', in alignment with the F-bit at the Status TLV level. 6. Editor's notes - the signature algorithm identifier could be defined as a simple integer, but it then requires some IANA registration. 7. IANA considerations This document defines the following new TLVs for which a type value is to be allocated : - Signature TLV (section 3.1.1) - Certificate TLV (section 3.1.2) - Nonce TLV (section 3.1.3) - MAC TLV (section 4.1.1) Further, a new Status Code value ("Authentication Failed") is required in the LDP Notification message Status TLV (section 5). Within the newly defined Signature TLV (section 3.1.1), two namespaces are to be administered by the IANA. -- The "ID Type" is a 8 bit identifier for which the following values have been reserved ID Type Value 0 IPv4 address 1 IPv6 address 2 FQDN Option numbers 0-127 can be assigned by the IANA under the condition "Specification Required". Option numbers 128-254 are site specific, while 255 is reserved. -- The "Algorithm Identifier" follows the definition and registration as within [RFC2459] section 7.2.2 8. Security considerations This specification entirely deals with security issues. 9. Algorithms and identifiers 9.1. Signature algorithms Implementations MUST support the use of DSA-with-SHA1 algorithm. The exact encoding of the resulting signature and the algorithm identifier (id-dsa-with-sha1) can be found in [RFC2459] section De Schrijver, et al Expires May 2001 [Page 14] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 7.2.2. 9.2. MAC algorithms Implementations MUST support the use of HMAC-MD5-96 and HMAC-SHA-1-96 algorithms. 9.3. Identifiers types The following types of signer's identifiers are defined. Value Type IPv4 address 0 IPv6 address 1 FQDN 2 References [LDP] Andersson et al., "LDP Specification", RFC 3031, January 2001. [RFC2119]Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2408]Maughan et al., "Internet Security Association and Key Manage- ment Protocol", RFC 2408, November 1998. [RFC2459]Housley et al., "Internet X.509 Public Key Infrastructure Cer- tificate and CRL Profile", RFC 2459, January 1999. Acknowledgments The authors would like to thank Peter De Schrijver for having produced an original version of this document. Authors' Addresses Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: jeremy.de_clercq@alcatel.be Olivier Paridaens Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: olivier.paridaens@alcatel.be De Schrijver, et al Expires May 2001 [Page 15] I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001 Yves T'joens Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: yves.tjoens@alcatel.be Peter De Schrijver Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." De Schrijver, et al Expires May 2001 [Page 16] --=====================_1030556637==_-- From owner-mpls@UU.NET Wed Aug 28 11:31: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 LAA04302 for ; Wed, 28 Aug 2002 11:31:40 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndwo24349 for ; Wed, 28 Aug 2002 15:32: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 QQndwo20161; Wed, 28 Aug 2002 15:30:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQndwo12548 for mpls-outgoing; Wed, 28 Aug 2002 15:30: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 QQndwo12540 for ; Wed, 28 Aug 2002 15:30:32 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 QQndwo17431 for ; Wed, 28 Aug 2002 15:30: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 QQndwo01804 for ; Wed, 28 Aug 2002 15:30:17 GMT Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQndwo01800 for ; Wed, 28 Aug 2002 15:30:17 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 428404CE3C; Wed, 28 Aug 2002 11:30:13 -0400 (EDT) Received: from research.att.com (CHASE.mt.att.com [135.21.202.89]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id LAA19742; Wed, 28 Aug 2002 11:30:12 -0400 (EDT) Message-ID: <3D6CEC83.4080909@research.att.com> Date: Wed, 28 Aug 2002 11:30:11 -0400 From: Chris Chase User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy Cc: Art King , mpls@UU.NET Subject: Re: Encapsulating MPLS in IP or GRE References: <200208141827.OAA23662@erosen-u10.cisco.com> <3.0.5.32.20020815190130.0087b620@email.quarrytech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This is the usage I find the most attractive. Actually, we had a customer who wanted to do carrier's carrier to create their own VPNs for their tenants. The approach taken was to use GRE tunnels. The customer did not like having to create numerous tunnel interfaces. Mark Duffy wrote: >Hi Art, are you suggesting that there is something about the MPLS VPN case >in particular that favors mpls-in-gre over mpls-in-ip? If so would you >explain that? > >Thanks, Mark > > >At 01:32 PM 8/15/02 -0700, Art King wrote: > > >>Connecting MPLS VPN PE's over non-MPLS core in a Carrier is a >>good example case for GRE usage. >> >>----- Original Message ----- >>From: "Eric Rosen" >>To: "Shahram Davari" >>Cc: ; "Loa Andersson" ; "George >>Swallow" >>Sent: Wednesday, August 14, 2002 11:27 AM >>Subject: Re: Encapsulating MPLS in IP or GRE >> >> >> >> >>>In some cases you might already have a GRE tunnel through which you >>> >>> >>are >> >> >>>supporting a routing adjacency. It should be possible to send MPLS >>> >>> >>packets, >> >> >>>as well as IP packets, through such tunnels, and this requires >>> >>> >>an >> >> >>>MPLS-in-GRE encapsulation. >>> >>>There are also other cases in which GRE tunnels (as opposed to IP >>> >>> >>tunnels) >> >> >>>are commonly used, and you should be able to send MPLS packets >>> >>> >>through >> >> >>>them. >>> >>> >>> From owner-mpls@UU.NET Wed Aug 28 12:55: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 MAA08974 for ; Wed, 28 Aug 2002 12:55:43 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndwt09196 for ; Wed, 28 Aug 2002 16:57: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 QQndwt00042; Wed, 28 Aug 2002 16:52:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQndwt13313 for mpls-outgoing; Wed, 28 Aug 2002 16:52: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 QQndwt13292 for ; Wed, 28 Aug 2002 16:52: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 QQndwt20717 for ; Wed, 28 Aug 2002 16:51: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 QQndwt09968 for ; Wed, 28 Aug 2002 16:51:38 GMT Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQndwt09962 for ; Wed, 28 Aug 2002 16:51:38 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 8894C4CE2C; Wed, 28 Aug 2002 12:51:37 -0400 (EDT) Received: from research.att.com (CHASE.mt.att.com [135.21.202.89]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id MAA28889; Wed, 28 Aug 2002 12:51:37 -0400 (EDT) Message-ID: <3D6CFF98.9080309@research.att.com> Date: Wed, 28 Aug 2002 12:51:36 -0400 From: Chris Chase User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: Mark Duffy , Art King , mpls@UU.NET Subject: Re: Encapsulating MPLS in IP or GRE References: <200208141827.OAA23662@erosen-u10.cisco.com> <3.0.5.32.20020815190130.0087b620@email.quarrytech.com> <3D6CEC83.4080909@research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Oops. Sent before I was done. In the approach described in http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip-2547-01.txt the tunnels between PE pairs are dynamic. No tunnel configuration required. In fact an implementation might chose to not even need to create a "tunnel" inteface if the tunnel header is viewed as an outbound encapsulation for a given BGP next hop. Much like there is no "interface" created for downstream label switching when using MPLS as the tunneling method between PEs. One descrepancy I see between the the dynamic approach of the above draft and draft-rosen-mpls-in-ip-or-gre-00.txt is the latter requires MTU path discovery for each "tunnel" destination. A static configured MTU or min MTU learned over the history of dynamic tunnels used would be prefered. In the customer's case mentioned below, by using the GRE tunnels made the customers creation of hierarchical VPNs (carrier's carrier) completely transparent to our service offer. They could use the existing service as defined without ordering or configuring anything special in our service network. Specifically, we did not have to certify, deploy, provision and support MPLS CE-to-PE. Instead it looks just like our standard IP service interface definition. Another application, perhaps less important, in the VPLS context when using BGP discovery and MAC address learning is that you do not need a label that is upstream PE specific (the label block method). You know which upstream PE sent the packet from the source address of the tunnel. Chris Chris Chase wrote: > This is the usage I find the most attractive. > Actually, we had a customer who wanted to do carrier's carrier to > create their own VPNs for their tenants. The approach taken was to > use GRE tunnels. The customer did not like having to create numerous > tunnel interfaces. > > > Mark Duffy wrote: > >> Hi Art, are you suggesting that there is something about the MPLS VPN >> case >> in particular that favors mpls-in-gre over mpls-in-ip? If so would you >> explain that? >> >> Thanks, Mark >> >> >> At 01:32 PM 8/15/02 -0700, Art King wrote: >> >> >>> Connecting MPLS VPN PE's over non-MPLS core in a Carrier is a >>> good example case for GRE usage. >>> >>> ----- Original Message ----- >>> From: "Eric Rosen" >>> To: "Shahram Davari" >>> Cc: ; "Loa Andersson" ; "George >>> Swallow" >>> Sent: Wednesday, August 14, 2002 11:27 AM >>> Subject: Re: Encapsulating MPLS in IP or GRE >>> >>> >>> >>> >>>> In some cases you might already have a GRE tunnel through >>>> which you >>>> >>> >>> are >>> >>> >>>> supporting a routing adjacency. It should be possible to send MPLS >>>> >>> >>> packets, >>> >>> >>>> as well as IP packets, through such tunnels, and this >>>> requires >>>> >>> >>> an >>> >>> >>>> MPLS-in-GRE encapsulation. >>>> >>>> There are also other cases in which GRE tunnels (as opposed to IP >>>> >>> >>> tunnels) >>> >>> >>>> are commonly used, and you should be able to send MPLS packets >>>> >>> >>> through >>> >>> >>>> them. >>>> >>>> >>> > From owner-mpls@UU.NET Wed Aug 28 17:41: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 RAA20653 for ; Wed, 28 Aug 2002 17:41:36 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndxm02404 for ; Wed, 28 Aug 2002 21:43: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 QQndxm00745; Wed, 28 Aug 2002 21:42:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQndxm08471 for mpls-outgoing; Wed, 28 Aug 2002 21:42: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 QQndxm08466 for ; Wed, 28 Aug 2002 21:41:52 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 QQndxm20973 for ; Wed, 28 Aug 2002 21:41: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 QQndxm00120 for ; Wed, 28 Aug 2002 21:41:45 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQndxm00110 for ; Wed, 28 Aug 2002 21:41:45 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7SLffA04304 for ; Wed, 28 Aug 2002 17:41:41 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 17:41:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05198DFC@zcard031.ca.nortel.com> From: "David Allan" To: "'mpls@UU.net'" Subject: Inconsistency in RFC 3031 Date: Wed, 28 Aug 2002 17:41:43 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk As folks are discussing progressing stuff to draft, I'll raise this as a nit with definitions in 3031. Section 2.2 states: ------------------- forwarding equivalence class a group of IP packets which are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment) This has become confused as it is used in two senses: 1) The forwarding capabilities of an LSP. 2) The forwarding requirements of a packet. An LSP can implement a set of forwarding treatments (E-LSP), a group of IP packets of common FEC can get different treatment (e.g. ECMP) and different paths....and forwarding treatment seems to now simply mean common prefix. Is it perchance time to revisit and clean up the definition? comments? Dave From owner-mpls@UU.NET Wed Aug 28 18:35: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 SAA22805 for ; Wed, 28 Aug 2002 18:35:55 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndxq08669 for ; Wed, 28 Aug 2002 22:37: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 QQndxq06367; Wed, 28 Aug 2002 22:35:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQndxq06650 for mpls-outgoing; Wed, 28 Aug 2002 22:35: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 QQndxq06645 for ; Wed, 28 Aug 2002 22:35: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 QQndxq23569 for ; Wed, 28 Aug 2002 22:35: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 QQndxq05813 for ; Wed, 28 Aug 2002 22:35: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 QQndxq05785 for ; Wed, 28 Aug 2002 22:35:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA15661 for ; Wed, 28 Aug 2002 18:35:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7SMZ3W19338 for mpls@uu.net; Wed, 28 Aug 2002 18:35:03 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQndxq06596 for ; Wed, 28 Aug 2002 22:34: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 QQndxq08658 for ; Wed, 28 Aug 2002 22:32: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 QQndxq29542 for ; Wed, 28 Aug 2002 22:32:49 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQndxq29503 for ; Wed, 28 Aug 2002 22:32:41 GMT Received: from AMALIS.vivacenetworks.com ([10.122.19.102]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 28 Aug 2002 15:32:35 -0700 Message-Id: <5.1.0.14.2.20020828182316.04d813a0@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Aug 2002 18:32:28 -0400 To: "David Allan" From: "Andrew G. Malis" Subject: Re: Inconsistency in RFC 3031 Cc: "mpls@UU.net" In-Reply-To: <9FBD322B7824D511B36900508BF93C9C05198DFC@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Aug 2002 22:32:35.0232 (UTC) FILETIME=[CE686A00:01C24EE2] Sender: owner-mpls@UU.NET Precedence: bulk Dave, Now that we're into layer 2 VPNs over MPLS, the FEC concept has certainly been generalized. I now take it to be a filter that is applied to the PDU of the protocol being carried by MPLS (not necessarily just IP) in order to determine the label that should be imposed by the LER. Is that any more precise? BTW, you're absolutely right, thanks to E-LSPs and MP, it is possible that MPLS packets with the same label imposed by a particular LER may not receive the same forwarding treatment by the network. But they WILL at least all end up at the same destination. Cheers, Andy -------- At 8/28/2002 02:41 PM -0700, David Allan wrote: >As folks are discussing progressing stuff to draft, I'll raise this as a nit >with definitions in 3031. > >Section 2.2 states: >------------------- >forwarding equivalence class a group of IP packets which are > forwarded in the same manner (e.g., > over the same path, with the same > forwarding treatment) > >This has become confused as it is used in two senses: > >1) The forwarding capabilities of an LSP. > >2) The forwarding requirements of a packet. > >An LSP can implement a set of forwarding treatments (E-LSP), a group of IP >packets of common FEC can get different treatment (e.g. ECMP) and different >paths....and forwarding treatment seems to now simply mean common prefix. > >Is it perchance time to revisit and clean up the definition? > >comments? >Dave From owner-mpls@UU.NET Wed Aug 28 19:18: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 TAA24089 for ; Wed, 28 Aug 2002 19:18:09 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndxt29642 for ; Wed, 28 Aug 2002 23:19: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 QQndxt26016; Wed, 28 Aug 2002 23:18:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQndxt04696 for mpls-outgoing; Wed, 28 Aug 2002 23:17: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 QQndxt04691 for ; Wed, 28 Aug 2002 23:17: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 QQndxt10612 for ; Wed, 28 Aug 2002 23:16: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 QQndxt06297 for ; Wed, 28 Aug 2002 23:16:54 GMT Received: from morpheus.lanterncom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: morpheus.lanterncom.com [64.161.157.68]) id QQndxt06287 for ; Wed, 28 Aug 2002 23:16:54 GMT Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19) id <36GK373Q>; Wed, 28 Aug 2002 16:02:31 -0700 Message-ID: <58BE468BAC66D511AFE6000347251A2D01A16206@morpheus.lanterncom.com> From: Anoop Ghanwani To: "'David Allan'" , "'mpls@UU.net'" Subject: RE: Inconsistency in RFC 3031 Date: Wed, 28 Aug 2002 16:02:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Since someone has brought up this subject, I might as well add my $0.02. Several IETF meetings ago, after a presentation on Diffserv support using MPLS, I pointed out the following inconsistency: - all packets that match a FEC are supposed to map to one LSP; - the well-defined FECs used by LDP are only prefixes; - when we add diffserv support into LDP, then a FEC no longer maps on to a single LSP because the DSCP in the packet comes into play as well. What should probably have been done was to define FECs for LDP that comprised prefix and DSCP. Instead, I think the definition of FEC was loosened to make the existing model work without having to incorporate the DSCP within the FEC (which is what should have been done, IMHO). Anyway, we are where we are, and I haven't been able to justify trying to fix it. -Anoop > -----Original Message----- > From: David Allan [mailto:dallan@nortelnetworks.com] > Sent: Wednesday, August 28, 2002 2:42 PM > To: 'mpls@UU.net' > Subject: Inconsistency in RFC 3031 > > > > > As folks are discussing progressing stuff to draft, I'll > raise this as a nit > with definitions in 3031. > > Section 2.2 states: > ------------------- > forwarding equivalence class a group of IP packets which are > forwarded in the same > manner (e.g., > over the same path, with the same > forwarding treatment) > > This has become confused as it is used in two senses: > > 1) The forwarding capabilities of an LSP. > > 2) The forwarding requirements of a packet. > > An LSP can implement a set of forwarding treatments (E-LSP), > a group of IP > packets of common FEC can get different treatment (e.g. ECMP) > and different > paths....and forwarding treatment seems to now simply mean > common prefix. > > Is it perchance time to revisit and clean up the definition? > > > comments? > Dave > From owner-mpls@UU.NET Wed Aug 28 23:26: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 XAA29576 for ; Wed, 28 Aug 2002 23:26:46 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndyj16243 for ; Thu, 29 Aug 2002 03:28: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 QQndyj08460; Thu, 29 Aug 2002 03:24:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQndyj29619 for mpls-outgoing; Thu, 29 Aug 2002 03:24: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 QQndyj29614 for ; Thu, 29 Aug 2002 03:24: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 QQndyj14628 for ; Thu, 29 Aug 2002 03:23: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 QQndyj15449 for ; Thu, 29 Aug 2002 03:23:58 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 QQndyj15445 for ; Thu, 29 Aug 2002 03:23:57 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 XAA28698 for ; Wed, 28 Aug 2002 23:23:57 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7T3NvS18909 for mpls@uu.net; Wed, 28 Aug 2002 23:23:57 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQndty06207 for ; Tue, 27 Aug 2002 22:38: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 QQndty13677 for ; Tue, 27 Aug 2002 22:38: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 QQndty28505 for ; Tue, 27 Aug 2002 22:38:11 GMT Received: from gamma.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gamma.isi.edu [128.9.144.145]) id QQndty28495 for ; Tue, 27 Aug 2002 22:38:11 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g7RMc2d25773; Tue, 27 Aug 2002 15:38:03 -0700 (PDT) Message-Id: <200208272238.g7RMc2d25773@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3353 on Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment Cc: rfc-editor@rfc-editor.org, mpls@UU.NET From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 27 Aug 2002 15:38:02 -0700 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3353 Title: Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment Author(s): D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari Status: Informational Date: August 2002 Mailbox: Dirk.Ooms@alcatel.be, Bernard.Sales@alcatel.be, WLivens@colt-telecom.be, arup@us.ibm.com, griffoul@ulticom.com, furquan@dnrc.bell-labs.com Pages: 30 Characters: 65860 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-multicast-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3353.txt This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020827153623.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3353 --OtherAccess Content-Type: Message/External-body; name="rfc3353.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020827153623.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Aug 28 23:26: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 XAA29585 for ; Wed, 28 Aug 2002 23:26:47 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndyj19713 for ; Thu, 29 Aug 2002 03:28: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 QQndyj16648; Thu, 29 Aug 2002 03:26:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQndyj29663 for mpls-outgoing; Thu, 29 Aug 2002 03:25: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 QQndyj29649 for ; Thu, 29 Aug 2002 03:25: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 QQndyj16952 for ; Thu, 29 Aug 2002 03:24: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 QQndyj15858 for ; Thu, 29 Aug 2002 03:24:57 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 QQndyj15854 for ; Thu, 29 Aug 2002 03:24:56 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 XAA28730 for ; Wed, 28 Aug 2002 23:24:56 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7T3OuQ19009 for mpls@uu.net; Wed, 28 Aug 2002 23:24:56 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQndwg15075 for ; Wed, 28 Aug 2002 13:39:04 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 QQndwg21668 for ; Wed, 28 Aug 2002 13:38: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 QQndwg05489 for ; Wed, 28 Aug 2002 13:38:41 GMT Received: from gorilla.mchh.siemens.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQndwg05477 for ; Wed, 28 Aug 2002 13:38:40 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA24572; Wed, 28 Aug 2002 15:38:13 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA13183; Wed, 28 Aug 2002 15:38:12 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2656.59) id ; Wed, 28 Aug 2002 15:37:31 +0200 Message-ID: From: Hummel Heinrich To: "'erosen@cisco.com'" , mpls@UU.NET, Loa Andersson , George Swallow Subject: AW: Encapsulating MPLS in IP or GRE Date: Wed, 28 Aug 2002 15:37:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29585 I like to refer to my presentation in Yokohama about building hierarchical LSPs (H-LSPs) by concatenating i.e. label-switching elementary LSP tunnels. I pointed out that elementary LSPs may be MPLS-LSPs as we know today or also Non-MPLS tunnels. Consequently the use of hierarchical LSP may a) eliminate the O(n**2)-problem, b)enable MPLS-VPNs spanning MPLS networks as well as non-MPLS networks. E.g. a single MPLS-tunnel between two PEs might require the employment of a p2p-H-LSP because it needs to be built by concatenating an mPLS-LSP and an IPSEC or GRE tunnel. IMO, we should discuss hierarchical LSPs at all. Maybe at first p2p-H-LSPs prior to mp2p resp. p2mp resp. mp2mp H-LSPs. Maybe at first H-LSPs which do label-switch MPLS-LSPs prior to those which do label-switch non-MPLS LSPs like IPSEC,GRE,IP-in-IP tunnels. But I don't mind either to discuss both concurrently. After all, a particular p2p H-LSP should be able to concatenate an MPLS-LSP followed by a non-MPLS-LSP followed by an MPLS-LSP again, followed by.... Heinrich -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Mittwoch, 14. August 2002 18:48 An: mpls@UU.NET; Loa Andersson; George Swallow Betreff: Encapsulating MPLS in IP or GRE In support of work going on in PPVPN and PWE3, it is desirable to have some standards for encapsulating MPLS packets inside IP packets. The draft whose announcement I attach below is the result of merging two previous (but expired) documents, draft-worster-mpls-in-ip, and draft-rekhter-mpls-over- gre. I would like to present this for the consideration of the MPLS WG as a standards track document. From owner-mpls@UU.NET Thu Aug 29 02:32: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 CAA11736 for ; Thu, 29 Aug 2002 02:32:12 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndyw18734 for ; Thu, 29 Aug 2002 06:33: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 QQndyw16900; Thu, 29 Aug 2002 06:32:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQndyw25979 for mpls-outgoing; Thu, 29 Aug 2002 06:32: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 QQndyw25974 for ; Thu, 29 Aug 2002 06:32: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 QQndyw22122 for ; Thu, 29 Aug 2002 06:32: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 QQndyw03691 for ; Thu, 29 Aug 2002 06:32:01 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQndyw03680 for ; Thu, 29 Aug 2002 06:32:00 GMT Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id g7T6VQtA018469; Thu, 29 Aug 2002 08:31:26 +0200 (MEST) Message-ID: <3D6DBFBE.4050603@utfors.se> Date: Thu, 29 Aug 2002 08:31:26 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: ospf wg , isis-wg CC: MPLS wg Subject: LAst Call: draft-ietf-mpls-bundle-04.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit OSPF and IS-IS working groups, (mpls wg for info) the iesg has started the review of the mpls working group draft draft-ietf-mpls-bundle-04.txt. The immediate response from the iesg is that the draft contains OSPF and ISIS related details (see the included mail). After discussing with the wg chairs for ospf and is-is working groups, there is a feeling that the two weeks the iesg allocated for this last call might not be enough, since the draft has not been widely circulated in the routing working groups. Therefore: This is to initiate a last call for the by the ospf and is-is working groups. The last call ends September 22nd at 12PM CET Please include the mpls mailing list (mpls@uu.net) in your responses. /Loa (co-chair of the mpls wg) -------- Original Message -------- Subject: draft-ietf-mpls-bundle-04.txt Date: Tue, 27 Aug 2002 15:06:48 -0400 (EDT) From: Scott Bradner To: loa.andersson@utfors.se, swallow@cisco.com The IESG discussed this ID last week during its teleconference one issue was raised during the discussion "the draft contains OSPF & ISIS related details and I don't remember it being LC'ed or reviewed in the corresponding WGs." can you start a 2 week last call on the IS-IS and OSPF mailing lists for this document? Scott -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Thu Aug 29 05:04: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 FAA13840 for ; Thu, 29 Aug 2002 05:04:05 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndzg23589 for ; Thu, 29 Aug 2002 09:05: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 QQndzg21313; Thu, 29 Aug 2002 09:04:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQndzg08409 for mpls-outgoing; Thu, 29 Aug 2002 09:04: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 QQndzg08403 for ; Thu, 29 Aug 2002 09:04: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 QQndzg18523 for ; Thu, 29 Aug 2002 09:03: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 QQndzg01685 for ; Thu, 29 Aug 2002 09:03:34 GMT Received: from zctfs063.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zctfs063.nortelnetworks.com [47.164.128.120]) id QQndzg01681 for ; Thu, 29 Aug 2002 09:03:33 GMT Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7T93I409235; Thu, 29 Aug 2002 11:03:18 +0200 (MEST) Received: from zctfc002.europe.nortel.com ([47.164.129.43]) by zctfc040.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RL852JJ6; Thu, 29 Aug 2002 11:03:17 +0200 Received: from nortelnetworks.com (FIFFI-1 [47.167.132.200]) by zctfc002.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 350Q4XBM; Thu, 29 Aug 2002 11:03:18 +0200 Message-ID: <3D6DE38C.4E709281@nortelnetworks.com> Date: Thu, 29 Aug 2002 11:04:12 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: Fiffi Hellstrand Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Loa Andersson CC: mpls wg , George Swallow , "Fiffi Hellstrand" , Vishal Sharma , Scott Bradner Subject: Re: iesg comments on the revovery framework References: <3D6A7978.5010200@utfors.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, The recovery framework draft talks solely about mpls recovery and should therefore be kept within the working group. However, It is related to other work in the sub-ip area that also deals with recovery techniques. IMHO they do not need to fullfill eachothers requirement or we else would have a complex mix of cross dependences. So for this particular draft I find it self consistent and to be kept within mpls wg (as agreed upon before). The AD's are talking about traceability between the groups and I'm in favour of such work. But exactly how it should be performed hasn't been settled yet. If I missed it pleased let me know the status. /Fiffi Loa Andersson wrote: > All, > > we've received the comments from the IESG on the > draft-ietf-mpls-recovery-frmwrk. Since the comments to a certain > extent addresses issues that are > - related to the workings of the sub-ip area > - what and how things should be done within the mpls group > - what is need as input from other the requirment specifying wgs > to start any work within wgs that do protocol specification > in the sub-ip area > > I've chosen to send the comments to the wg mailing list. While it > is clear that we often take requirments from e.g. ccamp and te-wg > iyt is not clear that this is the only requirment source. > I've de-personalized the comments somewhat, since it is normally > easier to discuss the issues that way. > > Question is if the wg group feels that there always need to that > requirment traceability from te-wg via ccamp to mpls, or whether > there are work that is started because it is within the mpls charter > or comes out of other wgs, e.g. the ppvpn group? > > If the latter is the case, does the requirment traceability requirment > apply to this particular draft anyhow? > > /Loa > > AD wrote: > > > the IESG talked about draft-ietf-mpls-recovery-frmwrk on the call today > > > > two issues came up: > > > > > (from nn) > > 2/ how does this document relate to the requirements expressed in > > draft-ietf-tewg-restore-hierarchy-01.txt? in what ways does > > it not meet requirements? in what ways does it exceed them, > > and if any, why? > > > > and, the sub-ip area architecture would seem to require a > > requirements/protocol path from the tewg requirements, through > > a common control and management plane, and then to the low- > > level path mechanisms. i was unable to follow this logical > > path. without it, how can one judge this work? > > > > > > AD > > > > -- > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > Råsundavägen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se -- Fiffi Hellstrand MSc ---------------------------------------------------------------- Senior Manager - Routing Architecture Lab Nortel Networks ATI Strategic Protocols St. Eriksgatan 115A ESN : 521-3687 Stockholm Sweden phone : +46 (0)8-5088-3687 mobile: +46 (0)70-559-3687 e-mail: fiffi@nortelnetworks.com ---------------------------------------------------------------- From owner-mpls@UU.NET Thu Aug 29 11:26: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 LAA26794 for ; Thu, 29 Aug 2002 11:26:26 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQneaf09225 for ; Thu, 29 Aug 2002 15:27:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQneaf07196; Thu, 29 Aug 2002 15:26:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQneaf14544 for mpls-outgoing; Thu, 29 Aug 2002 15:26: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 QQneaf14447 for ; Thu, 29 Aug 2002 15:26: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 QQneaf23770 for ; Thu, 29 Aug 2002 15:25: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 QQneaf08593 for ; Thu, 29 Aug 2002 15:25:03 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQneaf08577 for ; Thu, 29 Aug 2002 15:25:02 GMT Received: from MDUFFY ([10.1.3.119]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RQDDYTLH; Thu, 29 Aug 2002 11:25:01 -0400 Message-Id: <3.0.5.32.20020829112029.009c6ca0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Aug 2002 11:20:29 -0400 To: Chris Chase From: Mark Duffy Subject: Re: Encapsulating MPLS in IP or GRE Cc: Mark Duffy , Art King , mpls@UU.NET In-Reply-To: <3D6CFF98.9080309@research.att.com> References: <200208141827.OAA23662@erosen-u10.cisco.com> <3.0.5.32.20020815190130.0087b620@email.quarrytech.com> <3D6CEC83.4080909@research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Chris, If I understand you correctly, you are talking about providing IP connectivity (only) to a reseller who places their own PE boxes outside your network and then sells 2547-type VPN services to their customers. Is that right? If so I don't see why it should matter if they use mpls-in-ip or mpls-in-gre. Either way achieves the ability to run over a non-mpls IP backbone. --Mark At 12:51 PM 8/28/02 -0400, Chris Chase wrote: >Oops. Sent before I was done. > >In the approach described in > >http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip-2547-01.txt > >the tunnels between PE pairs are dynamic. No tunnel configuration >required. In fact an implementation might chose to not even need to >create a "tunnel" inteface if the tunnel header is viewed as an outbound >encapsulation for a given BGP next hop. Much like there is no >"interface" created for downstream label switching when using MPLS as >the tunneling method between PEs. > >One descrepancy I see between the the dynamic approach of the above >draft and >draft-rosen-mpls-in-ip-or-gre-00.txt is the latter requires MTU path >discovery for each "tunnel" destination. A static configured MTU or min >MTU learned over the history of dynamic tunnels used would be prefered. > >In the customer's case mentioned below, by using the GRE tunnels made >the customers creation of hierarchical VPNs (carrier's carrier) >completely transparent to our service offer. They could use the >existing service as defined without ordering or configuring anything >special in our service network. Specifically, we did not have to >certify, deploy, provision and support MPLS CE-to-PE. Instead it looks >just like our standard IP service interface definition. > > > >Another application, perhaps less important, in the VPLS context when >using BGP discovery and MAC address learning is that you do not need a >label that is upstream PE specific (the label block method). You know >which upstream PE sent the packet from the source address of the tunnel. > >Chris > > >Chris Chase wrote: > >> This is the usage I find the most attractive. >> Actually, we had a customer who wanted to do carrier's carrier to >> create their own VPNs for their tenants. The approach taken was to >> use GRE tunnels. The customer did not like having to create numerous >> tunnel interfaces. >> >> >> Mark Duffy wrote: >> >>> Hi Art, are you suggesting that there is something about the MPLS VPN >>> case >>> in particular that favors mpls-in-gre over mpls-in-ip? If so would you >>> explain that? >>> >>> Thanks, Mark >>> >>> >>> At 01:32 PM 8/15/02 -0700, Art King wrote: >>> >>> >>>> Connecting MPLS VPN PE's over non-MPLS core in a Carrier is a >>>> good example case for GRE usage. >>>> >>>> ----- Original Message ----- >>>> From: "Eric Rosen" >>>> To: "Shahram Davari" >>>> Cc: ; "Loa Andersson" ; "George >>>> Swallow" >>>> Sent: Wednesday, August 14, 2002 11:27 AM >>>> Subject: Re: Encapsulating MPLS in IP or GRE >>>> >>>> >>>> >>>> >>>>> In some cases you might already have a GRE tunnel through >>>>> which you >>>>> >>>> >>>> are >>>> >>>> >>>>> supporting a routing adjacency. It should be possible to send MPLS >>>>> >>>> >>>> packets, >>>> >>>> >>>>> as well as IP packets, through such tunnels, and this >>>>> requires >>>>> >>>> >>>> an >>>> >>>> >>>>> MPLS-in-GRE encapsulation. >>>>> >>>>> There are also other cases in which GRE tunnels (as opposed to IP >>>>> >>>> >>>> tunnels) >>>> >>>> >>>>> are commonly used, and you should be able to send MPLS packets >>>>> >>>> >>>> through >>>> >>>> >>>>> them. >>>>> >>>>> >>>> >> > From owner-mpls@UU.NET Thu Aug 29 17:48: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 RAA12386 for ; Thu, 29 Aug 2002 17:48:00 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnebf28998 for ; Thu, 29 Aug 2002 21:49: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 QQnebf26629; Thu, 29 Aug 2002 21:48:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnebf08619 for mpls-outgoing; Thu, 29 Aug 2002 21:47: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 QQnebf08614 for ; Thu, 29 Aug 2002 21:47: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 QQnebf16244 for ; Thu, 29 Aug 2002 21:47: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 QQnebf15808 for ; Thu, 29 Aug 2002 21:47:34 GMT Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQnebf15804 for ; Thu, 29 Aug 2002 21:47:33 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 7C4184CE18; Thu, 29 Aug 2002 17:47:33 -0400 (EDT) Received: from research.att.com ([135.91.77.11]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id RAA02792; Thu, 29 Aug 2002 17:47:32 -0400 (EDT) Message-ID: <3D6E96B2.1070904@research.att.com> Date: Thu, 29 Aug 2002 17:48:34 -0400 From: Chris Chase User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020805 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy Cc: Art King , mpls@UU.NET Subject: Re: Encapsulating MPLS in IP or GRE References: <200208141827.OAA23662@erosen-u10.cisco.com> <3.0.5.32.20020815190130.0087b620@email.quarrytech.com> <3D6CEC83.4080909@research.att.com> <3.0.5.32.20020829112029.009c6ca0@email.quarrytech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes that is what the customer was trying to do. I didn't mean to imply that IP versus GRE encap mattered. It didn't matter. The difficulty for the customer is that their router implementation required explicit configuration of an interface for every tunnel. They found that having to create a full mesh of tunnel interfaces was not acceptable. They were ideally suited to the dynamic tunneling mentioned in draft-ietf-ppvpn-gre-ip-2547-01.txt Chris Mark Duffy wrote: >Hi Chris, > >If I understand you correctly, you are talking about providing IP >connectivity (only) to a reseller who places their own PE boxes outside >your network and then sells 2547-type VPN services to their customers. Is >that right? If so I don't see why it should matter if they use mpls-in-ip >or mpls-in-gre. Either way achieves the ability to run over a non-mpls IP >backbone. > >--Mark > > >At 12:51 PM 8/28/02 -0400, Chris Chase wrote: > > >>Oops. Sent before I was done. >> >>In the approach described in >> >>http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip-2547-01.txt >> >>the tunnels between PE pairs are dynamic. No tunnel configuration >>required. In fact an implementation might chose to not even need to >>create a "tunnel" inteface if the tunnel header is viewed as an outbound >>encapsulation for a given BGP next hop. Much like there is no >>"interface" created for downstream label switching when using MPLS as >>the tunneling method between PEs. >> >>One descrepancy I see between the the dynamic approach of the above >>draft and >>draft-rosen-mpls-in-ip-or-gre-00.txt is the latter requires MTU path >>discovery for each "tunnel" destination. A static configured MTU or min >>MTU learned over the history of dynamic tunnels used would be prefered. >> >>In the customer's case mentioned below, by using the GRE tunnels made >>the customers creation of hierarchical VPNs (carrier's carrier) >>completely transparent to our service offer. They could use the >>existing service as defined without ordering or configuring anything >>special in our service network. Specifically, we did not have to >>certify, deploy, provision and support MPLS CE-to-PE. Instead it looks >>just like our standard IP service interface definition. >> >> >> >>Another application, perhaps less important, in the VPLS context when >>using BGP discovery and MAC address learning is that you do not need a >>label that is upstream PE specific (the label block method). You know >>which upstream PE sent the packet from the source address of the tunnel. >> >>Chris >> >> >>Chris Chase wrote: >> >> >> >>>This is the usage I find the most attractive. >>>Actually, we had a customer who wanted to do carrier's carrier to >>>create their own VPNs for their tenants. The approach taken was to >>>use GRE tunnels. The customer did not like having to create numerous >>>tunnel interfaces. >>> >>> >>>Mark Duffy wrote: >>> >>> >>> >>>>Hi Art, are you suggesting that there is something about the MPLS VPN >>>>case >>>>in particular that favors mpls-in-gre over mpls-in-ip? If so would you >>>>explain that? >>>> >>>>Thanks, Mark >>>> >>>> >>>>At 01:32 PM 8/15/02 -0700, Art King wrote: >>>> >>>> >>>> >>>> >>>>>Connecting MPLS VPN PE's over non-MPLS core in a Carrier is a >>>>>good example case for GRE usage. >>>>> >>>>>----- Original Message ----- >>>>>From: "Eric Rosen" >>>>>To: "Shahram Davari" >>>>>Cc: ; "Loa Andersson" ; "George >>>>>Swallow" >>>>>Sent: Wednesday, August 14, 2002 11:27 AM >>>>>Subject: Re: Encapsulating MPLS in IP or GRE >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>In some cases you might already have a GRE tunnel through >>>>>>which you >>>>>> >>>>>> >>>>>> >>>>>are >>>>> >>>>> >>>>> >>>>> >>>>>>supporting a routing adjacency. It should be possible to send MPLS >>>>>> >>>>>> >>>>>> >>>>>packets, >>>>> >>>>> >>>>> >>>>> >>>>>>as well as IP packets, through such tunnels, and this >>>>>>requires >>>>>> >>>>>> >>>>>> >>>>>an >>>>> >>>>> >>>>> >>>>> >>>>>>MPLS-in-GRE encapsulation. >>>>>> >>>>>>There are also other cases in which GRE tunnels (as opposed to IP >>>>>> >>>>>> >>>>>> >>>>>tunnels) >>>>> >>>>> >>>>> >>>>> >>>>>>are commonly used, and you should be able to send MPLS packets >>>>>> >>>>>> >>>>>> >>>>>through >>>>> >>>>> >>>>> >>>>> >>>>>>them. >>>>>> >>>>>> >>>>>> >>>>>> From owner-mpls@UU.NET Thu Aug 29 19:00: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 TAA14466 for ; Thu, 29 Aug 2002 19:00:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnebk21327 for ; Thu, 29 Aug 2002 23: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 QQnebk18727; Thu, 29 Aug 2002 23:00:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnebk10389 for mpls-outgoing; Thu, 29 Aug 2002 23:00: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 QQnebk10341 for ; Thu, 29 Aug 2002 23:00:30 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 QQnebk07215 for ; Thu, 29 Aug 2002 23:00: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 QQnebk16207 for ; Thu, 29 Aug 2002 23:00:03 GMT Received: from gateway.ipinfusion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnebk16189 for ; Thu, 29 Aug 2002 23:00:03 GMT Received: from ipinfusion.com ([10.10.0.225]) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id g7TMvbq07237 for ; Thu, 29 Aug 2002 15:57:37 -0700 Message-ID: <3D6EA701.4D89441A@ipinfusion.com> Date: Thu, 29 Aug 2002 15:58:09 -0700 From: Yuan Gu Organization: IP Infusion Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "mpls@UU.NET" Subject: support mpls-te-mib in transit and tail points. Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: In mpls-te-mib mplsTunnelTable, the object mplsTunnelRole has three values -- head, transit and tail. Does that mean beside ingress node, TE mib can also be supported in transit and egress node? If yes, mean while this table allows creating new tunnel, updating and remove existing tunnel. Is that to say a tunnel can be updated or removed from transit/egress node (even created)? And one more thing is in the transit case, how do you provide some TE parameters such as mplsTunnelPrimaryInstance because transit node might not know it? Thanks for your clearify. Regards! Yuan From owner-mpls@UU.NET Thu Aug 29 19:10: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 TAA14781 for ; Thu, 29 Aug 2002 19:10:55 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnebk25152 for ; Thu, 29 Aug 2002 23:12: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 QQnebk23096; Thu, 29 Aug 2002 23:11:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnebk02285 for mpls-outgoing; Thu, 29 Aug 2002 23:10: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 QQnebk02212 for ; Thu, 29 Aug 2002 23:10: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 QQnebk11786 for ; Thu, 29 Aug 2002 23:10: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 QQnebk19402 for ; Thu, 29 Aug 2002 23:10:30 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQnebk19398 for ; Thu, 29 Aug 2002 23:10:30 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 TAA04117; Thu, 29 Aug 2002 19:10:27 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA18561; Thu, 29 Aug 2002 19:10:21 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Aug 2002 19:10:21 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55763306@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Loa Andersson'" , ospf wg , isis-wg Cc: MPLS wg Subject: RE: LAst Call: draft-ietf-mpls-bundle-04.txt Date: Thu, 29 Aug 2002 19:10:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Link Bundling comments: -> This is to initiate a last call for the -> -> All component links in a bundle must begin and end on the same pair of LSRs, have the same Link Type (i.e., point-to-point or multi- access), the same Traffic Engineering metric, and the same set of resource classes at each end of the links. A Forwarding Adjacency may be a component link; in fact, a bundle can consist of a mix of point-to-point links and FAs. Link Types Restriction ---------------------- *** Only beginning & ending of the link types are restricted or *** all the links along the path (from beginning router to end router) *** are restricted to the same link type? *** I didn't not understand why we need same link type at the *** beginning and at the end of the link? Link Type TLV will cover *** whatever link type at the advertising router side of the link. *** I didn't see any issue if we have different link types at each *** side of the link. *** I request to elaborate these restriction a little bit with *** a single appropriate diagram (if possible). *** The use of bundling has very large scope. For example, one can *** bundle all the VCs in a VP (where each VC is viewed as a different *** link with its own resources). All such VPs can be bundled/unbundled *** (depending on the requirements). Still all those VPs will have *** a same risk-factor (i.e. SRLG). I think, it will be *** better to mention few example of such uses of link bundling. Metric Restriction ------------------ *** Why is the same metric restriction? Can a router have *** the flexibility to decide a different metric for the bundled *** link (may be independent of all the component links)? *** For example, a router chooses the largest metric of all *** component links (just like OSPF area aggregation). Just a *** a matter of flexibility. If the metrics are different and *** if we bundle those links did you see any problem? *** Let is explain an example scenario, where router starts *** advertising the largest of all links metric as bundled *** link metric. One the largest component link resources (bw) *** are completely consumed (crossed some threshold ) then *** bundled link metric will become the next highest component *** link metric. Link Protection consideration ----------------------------- *** There is no mention about link protection type of the bundled *** link when component links are of different type? SRLG consideration ------------------ *** There is no mention about SRLGs of bundled link w.r.t component *** links. In some situations, failure of one component link may or *** may not affect other component links. I think, it will be better *** to mention something about SRLG - that is, all component links *** in bundled link must have same SRLG (in order to benefit most *** from bundling). Even if the component links risk factor is independent *** from each other (ie. different SRLGs) still we can use bundling. *** Please mention something like that... Switching Capability consideration ---------------------------------- *** I think the switching capability should be same for all component *** links in order to use bundling?! Please mention. DiffServ consideration ---------------------- *** There is no mention about BCs and TE Classes applicability *** to Link bundling? Do you see any issues w.r.t to the recent *** diffserv draft (esp interpretation of unserverved bws etc)? Thank You. -- Venkata. From owner-mpls@UU.NET Thu Aug 29 19:19: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 TAA14959 for ; Thu, 29 Aug 2002 19:19:20 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnebl25924 for ; Thu, 29 Aug 2002 23: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 QQnebl23514; Thu, 29 Aug 2002 23:19:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnebl04367 for mpls-outgoing; Thu, 29 Aug 2002 23:19: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 QQnebl04360 for ; Thu, 29 Aug 2002 23:19:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnebl01031 for ; Thu, 29 Aug 2002 23:18: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 QQnebl03116 for ; Thu, 29 Aug 2002 23:18:16 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 QQnebl03112 for ; Thu, 29 Aug 2002 23:18:15 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 19:18:15 -0400 Message-ID: <03a301c24fb2$5a02c860$681810ac@movaz.com> From: "Adrian Farrel" To: "Yuan Gu" , References: <3D6EA701.4D89441A@ipinfusion.com> Subject: Re: support mpls-te-mib in transit and tail points. Date: Thu, 29 Aug 2002 19:18:14 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 29 Aug 2002 23:18:15.0287 (UTC) FILETIME=[5A056070:01C24FB2] Sender: owner-mpls@UU.NET Precedence: bulk Hi, You can certainly implement the TE MIB at transit nodes. It makes very good sense for reading about tunnels that transit an LSR. It might make sense in some implementations to allow deletion of tunnels from non-ingress nodes. It makes no sense for attempting to create tunnels from non-ingress nodes (in today's signaling protocols). You are correct that some parameters shown at the ingress are not signaled and so cannot be known at non-ingress nodes. On the whole, these parameters are concerned with selecting which of a set of tunnels configured at the ingress should be signaled, so it follows that at non-ingress nodes you only know about those that were actually signaled. Regards, Adrian ----- Original Message ----- From: "Yuan Gu" To: Sent: Thursday, August 29, 2002 6:58 PM Subject: support mpls-te-mib in transit and tail points. > Hi: > > In mpls-te-mib mplsTunnelTable, the object mplsTunnelRole has three > values -- head, transit and tail. Does that mean beside ingress node, TE > mib can also be supported in transit and egress node? If yes, mean while > this table allows creating new tunnel, updating and remove existing > tunnel. Is that to say a tunnel can be updated or removed from > transit/egress node (even created)? And one more thing is in the transit > case, how do you provide some TE parameters such as > mplsTunnelPrimaryInstance because transit node might not know it? > > Thanks for your clearify. > > Regards! > Yuan > From owner-mpls@UU.NET Fri Aug 30 05:39:59 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09077 for ; Fri, 30 Aug 2002 05:39:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQneda21311 for ; Fri, 30 Aug 2002 09:41: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 QQneda19099; Fri, 30 Aug 2002 09:40:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQneda21255 for mpls-outgoing; Fri, 30 Aug 2002 09:40:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQneda21246 for ; Fri, 30 Aug 2002 09:39: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 QQneda16893 for ; Fri, 30 Aug 2002 09:39: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 QQneda08668 for ; Fri, 30 Aug 2002 09:39:39 GMT Received: from xover.netplane.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fwout.maker.com [12.27.183.253] (may be forged)) id QQneda08664 for ; Fri, 30 Aug 2002 09:39:39 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 05:39:39 -0400 Message-ID: From: "Reddy, Vikram" To: "'Naidu, Venkata'" Cc: MPLS wg Subject: RE: LAst Call: draft-ietf-mpls-bundle-04.txt Date: Fri, 30 Aug 2002 05:41:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Please see inline. Vikram. -----Original Message----- From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] Sent: Friday, August 30, 2002 4:40 AM To: 'Loa Andersson'; ospf wg; isis-wg Cc: MPLS wg Subject: RE: LAst Call: draft-ietf-mpls-bundle-04.txt Link Bundling comments: -> This is to initiate a last call for the -> -> All component links in a bundle must begin and end on the same pair of LSRs, have the same Link Type (i.e., point-to-point or multi- access), the same Traffic Engineering metric, and the same set of resource classes at each end of the links. A Forwarding Adjacency may be a component link; in fact, a bundle can consist of a mix of point-to-point links and FAs. Link Types Restriction ---------------------- *** Only beginning & ending of the link types are restricted or *** all the links along the path (from beginning router to end router) *** are restricted to the same link type? I think the section above talks of the property of the component link itself. When you say "all the links along the path", you are probably referring to FA LSPs advertised as component links. In this case, the draft says that all the component links bundled must have the same link type, i.e All the FA LSPs bundled must be point-to-point LSPs (with same LERs) or all of them must be point to multipoint LSPs (with same LERs). It should not matter if the individual links in the LSP are all the same type. *** I didn't not understand why we need same link type at the *** beginning and at the end of the link? Link Type TLV will cover *** whatever link type at the advertising router side of the link. *** I didn't see any issue if we have different link types at each *** side of the link. The Link Type restriction is not because of the ability or lack thereof of to advertise in a particular TLV. It has more to do with the practical applicability and in the realization in the physical layer of multiplexing and demultiplexing. For example, It is not possible to multiplex as SONET/SDH and demultiplex it as packets or wavelenghts. Therefore there is the requirement that both ends of the link must be of the same type. *** I request to elaborate these restriction a little bit with *** a single appropriate diagram (if possible). *** The use of bundling has very large scope. For example, one can *** bundle all the VCs in a VP (where each VC is viewed as a different *** link with its own resources). All such VPs can be bundled/unbundled *** (depending on the requirements). Still all those VPs will have *** a same risk-factor (i.e. SRLG). I think, it will be *** better to mention few example of such uses of link bundling. Metric Restriction ------------------ *** Why is the same metric restriction? Can a router have *** the flexibility to decide a different metric for the bundled *** link (may be independent of all the component links)? *** For example, a router chooses the largest metric of all *** component links (just like OSPF area aggregation). Just a *** a matter of flexibility. If the metrics are different and *** if we bundle those links did you see any problem? IMO, there is no need for a router to do this. The reason for Link Bundling is to reduce redundant information getting into and flooding the TE database. But we have to aggregate only to such a level that the properties of the individual links are not lost in the aggregation. In the example you gave above, the router should not aggregate component links having different TE metrics in the same bundle. *** Let is explain an example scenario, where router starts *** advertising the largest of all links metric as bundled *** link metric. One the largest component link resources (bw) *** are completely consumed (crossed some threshold ) then *** bundled link metric will become the next highest component *** link metric. Link Protection consideration ----------------------------- *** There is no mention about link protection type of the bundled *** link when component links are of different type? Again, same reason as above. We should not aggregate component links having different protection types into a single Bundled Link. SRLG consideration ------------------ *** There is no mention about SRLGs of bundled link w.r.t component *** links. In some situations, failure of one component link may or *** may not affect other component links. I think, it will be better *** to mention something about SRLG - that is, all component links *** in bundled link must have same SRLG (in order to benefit most *** from bundling). Even if the component links risk factor is independent *** from each other (ie. different SRLGs) still we can use bundling. *** Please mention something like that... Switching Capability consideration ---------------------------------- *** I think the switching capability should be same for all component *** links in order to use bundling?! Please mention. DiffServ consideration ---------------------- *** There is no mention about BCs and TE Classes applicability *** to Link bundling? Do you see any issues w.r.t to the recent *** diffserv draft (esp interpretation of unserverved bws etc)? Thank You. -- Venkata. From owner-mpls@UU.NET Fri Aug 30 17:36: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 RAA06537 for ; Fri, 30 Aug 2002 17:36:16 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQneew28553 for ; Fri, 30 Aug 2002 21:37: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 QQneew25907; Fri, 30 Aug 2002 21:35:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQneew04994 for mpls-outgoing; Fri, 30 Aug 2002 21:35: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 QQneew04989 for ; Fri, 30 Aug 2002 21:35:39 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 QQneew14687 for ; Fri, 30 Aug 2002 21:35: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 QQneew25661 for ; Fri, 30 Aug 2002 21:35:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQneew25655 for ; Fri, 30 Aug 2002 21:35:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA28397 for ; Fri, 30 Aug 2002 17:35:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7ULZ2702408 for mpls@uu.net; Fri, 30 Aug 2002 17:35:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQneew04958 for ; Fri, 30 Aug 2002 21:34:29 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 QQneew11670 for ; Fri, 30 Aug 2002 21: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 QQneew15404 for ; Fri, 30 Aug 2002 21:33: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 QQneew15396 for ; Fri, 30 Aug 2002 21:33:37 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 g7ULXc74014861; Fri, 30 Aug 2002 17:33:38 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (rtp-vpn2-155.cisco.com [10.82.240.155]) by bucket.cisco.com (Mirapoint) with ESMTP id ABN20248; Fri, 30 Aug 2002 17:33:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20020830172914.01fde620@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Aug 2002 17:33:26 -0400 To: Yuan Gu From: "Thomas D. Nadeau" Subject: Re: support mpls-te-mib in transit and tail points. Cc: "mpls@UU.NET" In-Reply-To: <3D6EA701.4D89441A@ipinfusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 03:58 PM 8/29/2002 -0700, Yuan Gu wrote: >Hi: > >In mpls-te-mib mplsTunnelTable, the object mplsTunnelRole has three >values -- head, transit and tail. Does that mean beside ingress node, TE >mib can also be supported in transit and egress node? Yes, the intent was for implementations to support the MIB (at least the parts that make sense) at mid-points and tails. Also letting the NMS about which hop type (mid/head/tail) an LSR contains is useful for a variety of management tasks. >If yes, mean while >this table allows creating new tunnel, updating and remove existing >tunnel. Is that to say a tunnel can be updated or removed from >transit/egress node (even created)? In general, no. Most implementations only allow modification to a tunnel at its head. In general, the information shown at the mid-points and tail are informational only. >And one more thing is in the transit >case, how do you provide some TE parameters such as >mplsTunnelPrimaryInstance because transit node might not know it? Some objects do not make sense to show at mid-points/tails (i.e.: the tunnelHead instance -- generally instance=0). We are trying to clarify when it makes sense to support certain objects and when it does not at mid-points/tails/heads in the DESCRIPTION clauses in the updated MPLS-TE MIB that is being edited along with MIB Doctor comments now (really, ask Arun :) ). --Tom >Thanks for your clearify. > >Regards! >Yuan ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Fri Aug 30 17: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 RAA07003 for ; Fri, 30 Aug 2002 17:51:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQneex05524 for ; Fri, 30 Aug 2002 21:52: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 QQneex03307; Fri, 30 Aug 2002 21:51:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQneex06359 for mpls-outgoing; Fri, 30 Aug 2002 21:51: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 QQneex06354 for ; Fri, 30 Aug 2002 21:51: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 QQneex21165 for ; Fri, 30 Aug 2002 21:50: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 QQneex02507 for ; Fri, 30 Aug 2002 21:50:14 GMT Received: from gateway.ipinfusion.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQneex02499 for ; Fri, 30 Aug 2002 21:50:14 GMT Received: from ipinfusion.com ([10.10.0.225]) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id g7ULlmq25277; Fri, 30 Aug 2002 14:47:48 -0700 Message-ID: <3D6FE824.333598AD@ipinfusion.com> Date: Fri, 30 Aug 2002 14:48:20 -0700 From: Yuan Gu Organization: IP Infusion Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: "mpls@UU.NET" Subject: Re: support mpls-te-mib in transit and tail points. References: <4.3.2.7.2.20020830172914.01fde620@bucket.cisco.com> Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > >If yes, mean while > >this table allows creating new tunnel, updating and remove existing > >tunnel. Is that to say a tunnel can be updated or removed from > >transit/egress node (even created)? > > In general, no. Most implementations only allow modification > to a tunnel at its head. In general, the information shown at the mid-points > and tail are informational only. > > Then how do you inform SNMP that for same table, some rows can be modified while some other rows can't( most of the objects in TunnelTable are "read-create")? Or you just send error message back to SNMP when you receive a SNMP "set" request but you don't want to change your value? From owner-mpls@UU.NET Fri Aug 30 17:59: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 RAA07158 for ; Fri, 30 Aug 2002 17:59:17 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQneey14632 for ; Fri, 30 Aug 2002 22:00: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 QQneex11042; Fri, 30 Aug 2002 21:58:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQneex06731 for mpls-outgoing; Fri, 30 Aug 2002 21:58: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 QQneex06724 for ; Fri, 30 Aug 2002 21:58: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 QQneex09950 for ; Fri, 30 Aug 2002 21:58: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 QQneex12373 for ; Fri, 30 Aug 2002 21:58:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQneex12369 for ; Fri, 30 Aug 2002 21:58:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA29652 for ; Fri, 30 Aug 2002 17:58:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id g7ULw4006128 for mpls@uu.net; Fri, 30 Aug 2002 17:58:04 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQneex06698 for ; Fri, 30 Aug 2002 21:57: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 QQneex02435 for ; Fri, 30 Aug 2002 21:56: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 QQneex27190 for ; Fri, 30 Aug 2002 21:56: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 QQneex27186 for ; Fri, 30 Aug 2002 21:56: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 g7ULuNG3016440; Fri, 30 Aug 2002 17:56:23 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (rtp-vpn2-155.cisco.com [10.82.240.155]) by bucket.cisco.com (Mirapoint) with ESMTP id ABN20528; Fri, 30 Aug 2002 17:56:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20020830175116.022f34a8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Aug 2002 17:56:11 -0400 To: Yuan Gu From: "Thomas D. Nadeau" Subject: Re: support mpls-te-mib in transit and tail points. Cc: "mpls@UU.NET" In-Reply-To: <3D6FE824.333598AD@ipinfusion.com> References: <4.3.2.7.2.20020830172914.01fde620@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 02:48 PM 8/30/2002 -0700, Yuan Gu wrote: > > >If yes, mean while > > >this table allows creating new tunnel, updating and remove existing > > >tunnel. Is that to say a tunnel can be updated or removed from > > >transit/egress node (even created)? > > > > In general, no. Most implementations only allow modification > > to a tunnel at its head. In general, the information shown at the > mid-points > > and tail are informational only. > > > > > >Then how do you inform SNMP that for same table, some rows can be modified >while some other rows can't( most of the objects in TunnelTable are >"read-create")? The creation of particular rows in the table is always governed by the agent, regardless of where the MIB is running along the tunnel's path. If an implementation allows read-write access to head-end entries while not allowing them to others, this is fine but should be spelled out in the agent capability statement for that implementation (assuming that it is inline with the conformance statement in the MIB). Since the MPLS-TE MIB defines most of its objects as read-create, this means that by default, and agent allows write access to them after they are created, but a variation on this can be spelled out by the implementation to restrict write access either altogether, or at mid-points or tails. --Tom >Or you just send error message back to SNMP when you receive a >SNMP "set" request but you don't want to change your value? ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Sat Aug 31 07:24: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 HAA00838 for ; Sat, 31 Aug 2002 07:24:53 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnegz25327 for ; Sat, 31 Aug 2002 11:26:21 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 QQnegz21033; Sat, 31 Aug 2002 11:24:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnegz14163 for mpls-outgoing; Sat, 31 Aug 2002 11:23:46 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 QQnegz14141 for ; Sat, 31 Aug 2002 11:23: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 QQnegz29561 for ; Sat, 31 Aug 2002 11:23: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 QQnegz03712 for ; Sat, 31 Aug 2002 11:23:13 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f176.law12.hotmail.com [64.4.19.176]) id QQnegz03705 for ; Sat, 31 Aug 2002 11:23:12 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 31 Aug 2002 04:23:11 -0700 Received: from 212.87.114.121 by lw12fd.law12.hotmail.msn.com with HTTP; Sat, 31 Aug 2002 11:23:11 GMT X-Originating-IP: [212.87.114.121] Reply-To: rzappa@ieee.org From: "Rolando Zappacosta" To: rzappa@ieee.org Cc: mpls@UU.NET Subject: Test mail 2 of 2 - Please ignore it Date: Sat, 31 Aug 2002 13:23:11 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Aug 2002 11:23:11.0940 (UTC) FILETIME=[CA75A840:01C250E0] Sender: owner-mpls@UU.NET Precedence: bulk Test _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Sat Aug 31 08:12: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 IAA01495 for ; Sat, 31 Aug 2002 08:12:51 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnegz15697 for ; Sat, 31 Aug 2002 11:21: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 QQnegz13441; Sat, 31 Aug 2002 11:20:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnegz13918 for mpls-outgoing; Sat, 31 Aug 2002 11:20: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 QQnegz13913 for ; Sat, 31 Aug 2002 11:20:22 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 QQnegz24014 for ; Sat, 31 Aug 2002 11:19: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 QQnegz01653 for ; Sat, 31 Aug 2002 11:19:25 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f159.law12.hotmail.com [64.4.19.159]) id QQnegz01649 for ; Sat, 31 Aug 2002 11:19:25 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 31 Aug 2002 04:19:24 -0700 Received: from 212.87.114.121 by lw12fd.law12.hotmail.msn.com with HTTP; Sat, 31 Aug 2002 11:19:24 GMT X-Originating-IP: [212.87.114.121] Reply-To: rzappa@ieee.org From: "Rolando Zappacosta" To: mpls@UU.NET Subject: Test mail 1 of 2 - Please ignore it. Date: Sat, 31 Aug 2002 13:19:24 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Aug 2002 11:19:24.0816 (UTC) FILETIME=[43154900:01C250E0] Sender: owner-mpls@UU.NET Precedence: bulk Test _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com