From owner-mpls@UU.NET Fri Sep 1 06:53:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07937 for ; Fri, 1 Sep 2000 06:53:28 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjetf22788; Fri, 1 Sep 2000 10:51:29 GMT Received: by mail-control.mail.uu.net id QQjetf12971 for mpls-outgoing; Fri, 1 Sep 2000 10:51:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjetf12943 for ; Fri, 1 Sep 2000 10:51:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjetf19612 for ; Fri, 1 Sep 2000 06:50:58 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjetf27316 for ; Fri, 1 Sep 2000 10:50:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA01148 for mpls@uu.net; Fri, 1 Sep 2000 06:50:42 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjetf12891 for ; Fri, 1 Sep 2000 10:50:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjetf19523 for ; Fri, 1 Sep 2000 06:50:09 -0400 (EDT) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjetf26855 for ; Fri, 1 Sep 2000 10:49:54 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07898; Fri, 1 Sep 2000 06:49:52 -0400 (EDT) Message-Id: <200009011049.GAA07898@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-mib-07.txt Date: Fri, 01 Sep 2000 06:49:52 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani Filename : draft-ietf-mpls-ldp-mib-07.txt Pages : 84 Date : 30-Aug-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000831122346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000831122346.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Sep 1 15:01:38 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18435 for ; Fri, 1 Sep 2000 15:01:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjeum16207; Fri, 1 Sep 2000 19:00:48 GMT Received: by mail-control.mail.uu.net id QQjeum23672 for mpls-outgoing; Fri, 1 Sep 2000 19:00:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjeum22300 for ; Fri, 1 Sep 2000 19:00:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjeul21336 for ; Fri, 1 Sep 2000 14:59:58 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQjeul21828 for ; Fri, 1 Sep 2000 18:59:57 GMT Received: by LUX with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 11:59:56 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CEA7F@LUX> From: Jonathan Lang To: "'Sudhanshu Jain'" , mpls@UU.NET Cc: jplang@calient.com Subject: RE: Query on LMP document? Date: Fri, 1 Sep 2000 11:59:52 -0700 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 Sudhanshu, Sorry for the delay in response, I have been out of town. Comments in-line. -Jonathan >-----Original Message----- >From: Sudhanshu Jain [mailto:sjain@maplenetworks.com] >Sent: Tuesday, August 29, 2000 4:58 PM >To: mpls@UU.NET >Cc: jplang@calient.com >Subject: Query on LMP document? > > >Hi All, > >I have following query on draft-lang-mpls-lmp. > >1) If both control channel(s) (primary as well as backup) are not available, link goes > into DEG state. In DEG state, how does the data channel LSP (e.g RSVP refresh) are going > to be maintained? Soft state cannot be maintaned indefinately when a communication fails, however, if the refresh timer is sufficiently large, the problem may be addressed before a refresh is needed. > >2) As per the draft, for verification of the link, data (test message) is need to be read >over the optical component link. Why do we need this kind of capability? This is required to verify the physical connectivity of the component link. The reason a test message is used (as opposed to just pulses of light, for example) is that there may be opaque (terminating) devices between the boxes running LMP which would not pass such pulses. > >Is information gathered from power measurement and Optical Spectrum Analyzer (OSA) is not >sufficient to declare link connectivity? see above. Such light may not be passed through to the adjacent box if an opaque device is between boxes. > >Is the Link verification capability in LMP is optional? no > > >-Sudhanshu From owner-mpls@UU.NET Mon Sep 4 06:12:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01743 for ; Mon, 4 Sep 2000 06:12:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfee14236; Mon, 4 Sep 2000 10:11:05 GMT Received: by mail-control.mail.uu.net id QQjfee02322 for mpls-outgoing; Mon, 4 Sep 2000 10:10:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfee02176 for ; Mon, 4 Sep 2000 10:10:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfee22384 for ; Mon, 4 Sep 2000 06:10:10 -0400 (EDT) Received: from xaloc.upc.es by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQjfee13505 for ; Mon, 4 Sep 2000 10:10:00 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id MAA21935 for ; Mon, 4 Sep 2000 12:07:57 +0200 (METDST) Message-ID: <39B381B1.F64579D3@estos.upc.es> Date: Mon, 04 Sep 2000 12:04:17 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MPLS WG Subject: ISPs offering VPN service Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi,

I would like to know if there is any ISP currently
offering (or if it is planning to do it)
a VPN service based on MPLS.

Thanks a lot

Diego Otero From owner-mpls@UU.NET Mon Sep 4 06:16:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01765 for ; Mon, 4 Sep 2000 06:16:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfef11277; Mon, 4 Sep 2000 10:15:32 GMT Received: by mail-control.mail.uu.net id QQjfee02806 for mpls-outgoing; Mon, 4 Sep 2000 10:14:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfee02801 for ; Mon, 4 Sep 2000 10:14:41 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfee22863 for ; Mon, 4 Sep 2000 06:14:29 -0400 (EDT) Received: from neo.it.comsat.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neo.it.comsat.com [134.133.200.200]) id QQjfee16096 for ; Mon, 4 Sep 2000 10:14:13 GMT Received: (from smadmin@localhost) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) id e84A90H23556; Mon, 4 Sep 2000 06:09:00 -0400 (EDT) Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e84A8vo23552 for ; Mon, 4 Sep 2000 06:08:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfee14173; Mon, 4 Sep 2000 10:11:01 GMT Received: by mail-control.mail.uu.net id QQjfee02322 for mpls-outgoing; Mon, 4 Sep 2000 10:10:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfee02176 for ; Mon, 4 Sep 2000 10:10:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfee22384 for ; Mon, 4 Sep 2000 06:10:10 -0400 (EDT) Received: from xaloc.upc.es by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQjfee13505 for ; Mon, 4 Sep 2000 10:10:00 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id MAA21935 for ; Mon, 4 Sep 2000 12:07:57 +0200 (METDST) Message-ID: <39B381B1.F64579D3@estos.upc.es> Date: Mon, 04 Sep 2000 12:04:17 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MPLS WG Subject: ISPs offering VPN service Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mail-Filter: omnivore ver 1.0.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi,

I would like to know if there is any ISP currently
offering (or if it is planning to do it)
a VPN service based on MPLS.

Thanks a lot

Diego Otero From owner-mpls@UU.NET Mon Sep 4 06:25:40 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01813 for ; Mon, 4 Sep 2000 06:25:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfef22160; Mon, 4 Sep 2000 10:24:37 GMT Received: by mail-control.mail.uu.net id QQjfef03574 for mpls-outgoing; Mon, 4 Sep 2000 10:24:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfef03569 for ; Mon, 4 Sep 2000 10:24:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfef23824 for ; Mon, 4 Sep 2000 06:24:03 -0400 (EDT) Received: from ams_exch_dmz.versatel.nl by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.versatel.nl [212.48.37.11]) id QQjfef21658 for ; Mon, 4 Sep 2000 10:23:46 GMT Received: by AMS_EXCH_DMZ with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Sep 2000 12:08:41 +0200 Message-ID: <10A66F7F29FBD3118C310008C7249D124DD810@AMS_EXCHANGE> From: Cor van Rij To: "'Juan Diego Otero'" , MPLS WG Subject: RE: ISPs offering VPN service Date: Mon, 4 Sep 2000 12:25:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi VersaTel will offer it within the next 6 months regards cor > -----Original Message----- > From: Juan Diego Otero [SMTP:diego@estos.upc.es] > Sent: maandag 4 september 2000 13:04 > To: MPLS WG > Subject: ISPs offering VPN service > > Hi, > > I would like to know if there is any ISP currently > offering (or if it is planning to do it) > a VPN service based on MPLS. > > Thanks a lot > > Diego Otero From owner-mpls@UU.NET Mon Sep 4 06:28:52 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01829 for ; Mon, 4 Sep 2000 06:28:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfef24430; Mon, 4 Sep 2000 10:28:02 GMT Received: by mail-control.mail.uu.net id QQjfef03898 for mpls-outgoing; Mon, 4 Sep 2000 10:27:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfef03893 for ; Mon, 4 Sep 2000 10:27:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfef24097 for ; Mon, 4 Sep 2000 06:27:37 -0400 (EDT) Received: from neo.it.comsat.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neo.it.comsat.com [134.133.200.200]) id QQjfef23831 for ; Mon, 4 Sep 2000 10:27:07 GMT Received: (from smadmin@localhost) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) id e84ALrR23635; Mon, 4 Sep 2000 06:21:53 -0400 (EDT) Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e84ALoo23631 for ; Mon, 4 Sep 2000 06:21:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfef22129; Mon, 4 Sep 2000 10:24:35 GMT Received: by mail-control.mail.uu.net id QQjfef03574 for mpls-outgoing; Mon, 4 Sep 2000 10:24:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfef03569 for ; Mon, 4 Sep 2000 10:24:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfef23824 for ; Mon, 4 Sep 2000 06:24:03 -0400 (EDT) Received: from ams_exch_dmz.versatel.nl by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.versatel.nl [212.48.37.11]) id QQjfef21658 for ; Mon, 4 Sep 2000 10:23:46 GMT Received: by AMS_EXCH_DMZ with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Sep 2000 12:08:41 +0200 Message-ID: <10A66F7F29FBD3118C310008C7249D124DD810@AMS_EXCHANGE> From: Cor van Rij To: "'Juan Diego Otero'" , MPLS WG Subject: RE: ISPs offering VPN service Date: Mon, 4 Sep 2000 12:25:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Mail-Filter: omnivore ver 1.0.0 Sender: owner-mpls@UU.NET Precedence: bulk Hi VersaTel will offer it within the next 6 months regards cor > -----Original Message----- > From: Juan Diego Otero [SMTP:diego@estos.upc.es] > Sent: maandag 4 september 2000 13:04 > To: MPLS WG > Subject: ISPs offering VPN service > > Hi, > > I would like to know if there is any ISP currently > offering (or if it is planning to do it) > a VPN service based on MPLS. > > Thanks a lot > > Diego Otero From owner-mpls@UU.NET Mon Sep 4 07:02:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02230 for ; Mon, 4 Sep 2000 07:02:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfei08579; Mon, 4 Sep 2000 11:01:57 GMT Received: by mail-control.mail.uu.net id QQjfei12132 for mpls-outgoing; Mon, 4 Sep 2000 11:01:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfei11029 for ; Mon, 4 Sep 2000 11:01:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfei18438 for ; Mon, 4 Sep 2000 07:01:26 -0400 (EDT) Received: from satoru.prism by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.144.254]) id QQjfei13171 for ; Mon, 4 Sep 2000 11:01:10 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.9.3/8.9.3) with ESMTP id UAA06277 for ; Mon, 4 Sep 2000 20:00:43 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: mpls@UU.NET Subject: RE: ISPs offering VPN service In-Reply-To: <10A66F7F29FBD3118C310008C7249D124DD810@AMS_EXCHANGE> References: <10A66F7F29FBD3118C310008C7249D124DD810@AMS_EXCHANGE> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000904200043O.satoru@japan-telecom.co.jp> Date: Mon, 04 Sep 2000 20:00:43 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 44 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, As far as i know... There are two VPN services based on MPLS which named SOLTERIA provided by JAPAN-TELECOM,and Super-VPN provided by NTT-Communications, in Japan. GlobalOne has a international VPN service named Global Intranet VPN, it's based on MPLS too. regards. -- Satoru Matsushima From: Cor van Rij Subject: RE: ISPs offering VPN service Date: Mon, 4 Sep 2000 12:25:04 +0200 > Hi > > VersaTel will offer it within the next 6 months > > regards > > cor > > > -----Original Message----- > > From: Juan Diego Otero [SMTP:diego@estos.upc.es] > > Sent: maandag 4 september 2000 13:04 > > To: MPLS WG > > Subject: ISPs offering VPN service > > > > Hi, > > > > I would like to know if there is any ISP currently > > offering (or if it is planning to do it) > > a VPN service based on MPLS. > > > > Thanks a lot > > > > Diego Otero > From owner-mpls@UU.NET Mon Sep 4 07:06:54 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02266 for ; Mon, 4 Sep 2000 07:06:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfei15631; Mon, 4 Sep 2000 11:05:12 GMT Received: by mail-control.mail.uu.net id QQjfei17521 for mpls-outgoing; Mon, 4 Sep 2000 11:04:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfei17507 for ; Mon, 4 Sep 2000 11:04:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfei18682 for ; Mon, 4 Sep 2000 07:04:25 -0400 (EDT) Received: from neo.it.comsat.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neo.it.comsat.com [134.133.200.200]) id QQjfei15001 for ; Mon, 4 Sep 2000 11:04:25 GMT Received: (from smadmin@localhost) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) id e84AxBp23766; Mon, 4 Sep 2000 06:59:11 -0400 (EDT) Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e84Ax8o23762 for ; Mon, 4 Sep 2000 06:59:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfei08541; Mon, 4 Sep 2000 11:01:55 GMT Received: by mail-control.mail.uu.net id QQjfei12132 for mpls-outgoing; Mon, 4 Sep 2000 11:01:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfei11029 for ; Mon, 4 Sep 2000 11:01:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfei18438 for ; Mon, 4 Sep 2000 07:01:26 -0400 (EDT) Received: from satoru.prism by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.144.254]) id QQjfei13171 for ; Mon, 4 Sep 2000 11:01:10 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.9.3/8.9.3) with ESMTP id UAA06277 for ; Mon, 4 Sep 2000 20:00:43 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: mpls@UU.NET Subject: RE: ISPs offering VPN service In-Reply-To: <10A66F7F29FBD3118C310008C7249D124DD810@AMS_EXCHANGE> References: <10A66F7F29FBD3118C310008C7249D124DD810@AMS_EXCHANGE> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000904200043O.satoru@japan-telecom.co.jp> Date: Mon, 04 Sep 2000 20:00:43 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 44 X-Mail-Filter: omnivore ver 1.0.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, As far as i know... There are two VPN services based on MPLS which named SOLTERIA provided by JAPAN-TELECOM,and Super-VPN provided by NTT-Communications, in Japan. GlobalOne has a international VPN service named Global Intranet VPN, it's based on MPLS too. regards. -- Satoru Matsushima From: Cor van Rij Subject: RE: ISPs offering VPN service Date: Mon, 4 Sep 2000 12:25:04 +0200 > Hi > > VersaTel will offer it within the next 6 months > > regards > > cor > > > -----Original Message----- > > From: Juan Diego Otero [SMTP:diego@estos.upc.es] > > Sent: maandag 4 september 2000 13:04 > > To: MPLS WG > > Subject: ISPs offering VPN service > > > > Hi, > > > > I would like to know if there is any ISP currently > > offering (or if it is planning to do it) > > a VPN service based on MPLS. > > > > Thanks a lot > > > > Diego Otero > From owner-mpls@UU.NET Mon Sep 4 10:45:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04278 for ; Mon, 4 Sep 2000 10:45:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfew16945; Mon, 4 Sep 2000 14:44:09 GMT Received: by mail-control.mail.uu.net id QQjfew05797 for mpls-outgoing; Mon, 4 Sep 2000 14:43:39 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfew05791 for ; Mon, 4 Sep 2000 14:43:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfew20727 for ; Mon, 4 Sep 2000 10:43:29 -0400 (EDT) Received: from ss3000e.cselt.it by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ss3000e.cselt.it [163.162.41.5]) id QQjfew16242 for ; Mon, 4 Sep 2000 14:42:45 GMT Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G0D00GCA97MC4@ss3000e.cselt.it> for mpls@uu.net; Mon, 4 Sep 2000 16:21:22 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Mon, 04 Sep 2000 16:23:48 +0200 Content-return: allowed Date: Mon, 04 Sep 2000 16:21:24 +0200 From: "D'Albenzio Raffaele" Subject: Info about mpls-vpn To: "'mpls@uu.net'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I have a question on draft-rosen-rfc2547bis, section 5. In the MPLS VPN architecture proposed in the draft, to ensure interoperability among different implementations, it is required to support LDP for setting up LSP across the backbone. However, other methods are possible. Can I use, for example, RSVP-TE extensions to create LSP between PEs? Thank you, Raffaele. __________________________ Raffaele D'Albenzio CSELT - Centro Studi E Laboratori di Telecomunicazioni Services and Applications, Networking Corporate Networks: Networks and Systems Integration Via Reiss Romoli, 274 - 10148 Torino (Italy) Phone +39 011 228 5798 Fax +39 011 228 5069 e-mail: raffaele.dalbenzio@cselt.it From owner-mpls@UU.NET Mon Sep 4 12:54:19 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05262 for ; Mon, 4 Sep 2000 12:54:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfff22743; Mon, 4 Sep 2000 16:53:33 GMT Received: by mail-control.mail.uu.net id QQjfff06828 for mpls-outgoing; Mon, 4 Sep 2000 16:53:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfff06822 for ; Mon, 4 Sep 2000 16:53:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfff23357 for ; Mon, 4 Sep 2000 12:53:06 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfff22423 for ; Mon, 4 Sep 2000 16:53:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA25437 for mpls@uu.net; Mon, 4 Sep 2000 12:53:05 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfff06808 for ; Mon, 4 Sep 2000 16:52:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfff23303 for ; Mon, 4 Sep 2000 12:52:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfff29819 for ; Mon, 4 Sep 2000 16:52:33 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA12027; Mon, 4 Sep 2000 09:52:51 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA10093; Mon, 4 Sep 2000 09:52:34 -0700 (PDT) Message-ID: <39B3D417.43252FA8@cisco.com> Date: Mon, 04 Sep 2000 09:55:51 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "D'Albenzio Raffaele" CC: "'mpls@uu.net'" Subject: Re: Info about mpls-vpn References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Raffaele, Technically - yes. RSVP-TE or even GRE tunnels between PEs will work fine. Operationally you need to make sure that if you go this path you will need to engineer your TE LSPs the way that even at some failure conditions you will still have an active LSP connectivity between PEs. If not since you are not running LDP the core your PE-PE connectivity will be lost for VPN customers as falling back to plain IP will not help. R. > D'Albenzio Raffaele wrote: > > Hi all, > > I have a question on draft-rosen-rfc2547bis, section 5. > > In the MPLS VPN architecture proposed in the draft, to ensure > interoperability among different implementations, it is required to support > LDP for setting up LSP across the backbone. However, other methods are > possible. > Can I use, for example, RSVP-TE extensions to create LSP between PEs? > > Thank you, > Raffaele. > __________________________ > Raffaele D'Albenzio > CSELT - Centro Studi E Laboratori di Telecomunicazioni > Services and Applications, Networking > Corporate Networks: Networks and Systems Integration > Via Reiss Romoli, 274 - 10148 Torino (Italy) > Phone +39 011 228 5798 > Fax +39 011 228 5069 > e-mail: raffaele.dalbenzio@cselt.it From owner-mpls@UU.NET Mon Sep 4 16:05:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06550 for ; Mon, 4 Sep 2000 16:05:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjffs13193; Mon, 4 Sep 2000 20:04:30 GMT Received: by mail-control.mail.uu.net id QQjffs04704 for mpls-outgoing; Mon, 4 Sep 2000 20:04:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjffs04698 for ; Mon, 4 Sep 2000 20:03:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjffs15145 for ; Mon, 4 Sep 2000 16:03:50 -0400 (EDT) Received: from granger.mail.mindspring.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: granger.mail.mindspring.net [207.69.200.148]) id QQjffs19165 for ; Mon, 4 Sep 2000 20:03:49 GMT Received: from jluciani (user-2ive1mb.dialup.mindspring.com [165.247.6.203]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA28289; Mon, 4 Sep 2000 16:03:47 -0400 (EDT) Message-ID: <011d01c016ab$84511960$739ffea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: , Cc: References: Subject: Re: control channel lambdas Date: Mon, 4 Sep 2000 16:05:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I have seen 3 general choices in literature: If the control channels are strictly hop by hop and you are running a short distance (i.e., no amplification needed for control channel) then there have been proposals to use 1310 or something at the end of the C band (e.g., something on the ITU grid around 1510). The amplification and hop by hop restrictions are there because usually EDFAs do not usually amplify in these wavelengths (although I guess some do now). Those wavelengths thus do not steal from the set of useful data carrying wavelengths which would be in the range of EDFAs. BTW, many receivers are broad enough to receive 1310 even if built for C band (this is a bane as well as a boon); this was not the case for the tunable lasers for a while although I would not be surprised if you can find them now. If the restrictions on distance and amplication are not acceptable, then just pick one on the grid which your EDFAs cover. --Jim ---- Original Message ----- From: To: Cc: Sent: Wednesday, August 30, 2000 10:59 PM Subject: control channel lambdas > Can anyone point me in the direction of work that has been done to specify > what lambdas controls channels should use? > > Thanks, > > Spence From owner-mpls@UU.NET Mon Sep 4 20:34:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08427 for ; Mon, 4 Sep 2000 20:34:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfgk14155; Tue, 5 Sep 2000 00:33:56 GMT Received: by mail-control.mail.uu.net id QQjfgk07299 for mpls-outgoing; Tue, 5 Sep 2000 00:33:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfgk07289 for ; Tue, 5 Sep 2000 00:33:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfgk28887 for ; Mon, 4 Sep 2000 20:33:17 -0400 (EDT) Received: from ucayali.unired.net.pe by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ucayali.unired.net.pe [206.138.105.38]) id QQjfgk24455 for ; Tue, 5 Sep 2000 00:32:57 GMT Received: from jesus ([207.17.223.124]) by ucayali.unired.net.pe (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e84EXZ414197; Mon, 4 Sep 2000 19:33:35 +0500 (GMT) Message-ID: <002801c016cf$d74d90c0$7cdf11cf@jesus> From: "=?iso-8859-1?Q?Jes=FAs_Rodr=EDguez_Stuart?=" To: "Juan Diego Otero" , "MPLS WG" Subject: RE: ISPs offering VPN service Date: Mon, 4 Sep 2000 19:24:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C016A5.C3056720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C016A5.C3056720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juan Actually, Telefonica del PERU is offering VPN Services based on MPLS. JRSTUART jrstuart@telefonica.com.pe Network Solutions Chief - CCEE Telefonica del Peru -----Mensaje original----- De: Juan Diego Otero Para: MPLS WG Fecha: Domingo, 03 de Septiembre de 2000 07:13 p.m. Asunto: ISPs offering VPN service Hi,=20 I would like to know if there is any ISP currently=20 offering (or if it is planning to do it)=20 a VPN service based on MPLS.=20 Thanks a lot=20 Diego Otero=20 ------=_NextPart_000_001A_01C016A5.C3056720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Juan
 
Actually, Telefonica del PERU is offering VPN = Services based=20 on MPLS.
 
 
 
JRSTUART
jrstuart@telefonica.com.pe=
Network Solutions Chief - CCEE
Telefonica del Peru
-----Mensaje = original-----
De:=20 Juan Diego Otero <diego@estos.upc.es>
Para:= =20 MPLS WG <mpls@UU.NET>
Fecha:=20 Domingo, 03 de Septiembre de 2000 07:13 p.m.
Asunto: = ISPs=20 offering VPN service

Hi,=20

I would like to know if there is any ISP currently
offering (or = if it=20 is planning to do it)
a VPN service based on MPLS.=20

Thanks a lot=20

Diego Otero

------=_NextPart_000_001A_01C016A5.C3056720-- From owner-mpls@UU.NET Tue Sep 5 01:24:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14504 for ; Tue, 5 Sep 2000 01:24:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfhd08016; Tue, 5 Sep 2000 05:23:35 GMT Received: by mail-control.mail.uu.net id QQjfhd22733 for mpls-outgoing; Tue, 5 Sep 2000 05:23:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfhd22723 for ; Tue, 5 Sep 2000 05:23:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfhd15730; Tue, 5 Sep 2000 01:23:04 -0400 (EDT) Received: from fsnt.future.futusoft.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjfhd29324; Tue, 5 Sep 2000 05:23:01 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 05 Sep 2000 11:06:22 +0530 Received: from arumugamr (arumugamr.future.futsoft.com [10.0.6.51]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA15871; Tue, 5 Sep 2000 10:40:29 +0530 Received: by localhost with Microsoft MAPI; Tue, 5 Sep 2000 10:51:15 +0530 Message-Id: <01C01727.36C4BB80.arumugamr@future.futsoft.com> From: ARUMUGAM R To: "'mpls@uu.net'" Cc: "'awduche@uu.net'" , "'lberger@labn.net'" , "'dhg@juniper.net'" , "'tonyl@home.net'" , "'vsriniva@cosinecom.com'" , "'swallow@cisco.com'" Subject: Question on forward compatibility in the Rsvp-Lsp-Tunnel Date: Tue, 5 Sep 2000 10:51:15 +0530 Organization: FSPL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a question in forward compatibility (section 4.4.5) of the rsvp-lsp-tunnel-07 draft. It is said that during loop detection processing, a node SHOULD parse over any unrecognized objects. My question is can we assume that the newsubobject's, TYPE & LENGTH field is stated exactly the same way of that of other subobjects, so that during parsing, the parser can move to the position defined by the length of the new subobject. Else if the length field is defined somewhere, how can I know where the length field of new subobject is defined. Regards Aru -------------------------------------------------------------------------------- Arumugam R Senior Software Engineer, Future Software Ltd. Chennai - 35 Fone-4330550 Extn-332 -------------------------------------------------------------------------------- From owner-mpls@UU.NET Tue Sep 5 07:55:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29064 for ; Tue, 5 Sep 2000 07:55:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfid06239; Tue, 5 Sep 2000 11:54:35 GMT Received: by mail-control.mail.uu.net id QQjfid26189 for mpls-outgoing; Tue, 5 Sep 2000 11:54:19 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfid26183 for ; Tue, 5 Sep 2000 11:54:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfid13067; Tue, 5 Sep 2000 07:53:59 -0400 (EDT) Received: from solen.ce.chalmers.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQjfid05821; Tue, 5 Sep 2000 11:53:58 GMT Received: from blomman13.ce.chalmers.se (blomman13.ce.chalmers.se [129.16.21.43]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id NAA25919; Tue, 5 Sep 2000 13:53:57 +0200 (MEST) Received: (from otel@localhost) by blomman13.ce.chalmers.se (8.8.8/8.8.8) id NAA09961; Tue, 5 Sep 2000 13:53:57 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14772.57045.342364.820985@blomman13.ce.chalmers.se> Date: Tue, 5 Sep 2000 13:53:57 +0200 (MEST) From: Florian-Daniel Otel To: mpls@UU.NET, te-wg@UU.NET Subject: Incremental MPLS (BCP document lookup) X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Florian-Daniel Otel Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I am looking for a case study document/white paper focused on/describing the possible means (maybe even claimed advantages ?) of introducing MPLS in a _incremental_ manner in a core network. TIA, Florian From owner-mpls@UU.NET Tue Sep 5 09:37:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01710 for ; Tue, 5 Sep 2000 09:37:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfik14491; Tue, 5 Sep 2000 13:36:31 GMT Received: by mail-control.mail.uu.net id QQjfik26249 for mpls-outgoing; Tue, 5 Sep 2000 13:35:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfik26244 for ; Tue, 5 Sep 2000 13:35:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfik28349 for ; Tue, 5 Sep 2000 09:35:47 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjfik13649 for ; Tue, 5 Sep 2000 13:35:31 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e85DZUn12529; Tue, 5 Sep 2000 09:35:30 -0400 (EDT) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id JAA45629; Tue, 5 Sep 2000 09:36:02 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200009051336.JAA45629@curtis-lt.avici.com> To: raszuk@cisco.com cc: "D'Albenzio Raffaele" , "'mpls@uu.net'" Reply-To: curtis@avici.com Subject: Re: Info about mpls-vpn In-reply-to: Your message of "Mon, 04 Sep 2000 09:55:51 PDT." <39B3D417.43252FA8@cisco.com> Date: Tue, 05 Sep 2000 09:36:02 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <39B3D417.43252FA8@cisco.com>, Robert Raszuk writes: > > Raffaele, > > Technically - yes. RSVP-TE or even GRE tunnels between PEs will work > fine. > > Operationally you need to make sure that if you go this path you will > need to engineer your TE LSPs the way that even at some failure > conditions you will still have an active LSP connectivity between PEs. > If not since you are not running LDP the core your PE-PE connectivity > will be lost for VPN customers as falling back to plain IP will not > help. > > R. Don't build broken networks is always good advice. If you are not using CAC (you are allowing overbooking but balancing traffic through other means) then there is no issue. That just happens to be the only supported mode for LDP (and there is no opportunity to balance traffic to reduce load). Curtis From owner-mpls@UU.NET Tue Sep 5 10:22:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03102 for ; Tue, 5 Sep 2000 10:22:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfin23778; Tue, 5 Sep 2000 14:19:56 GMT Received: by mail-control.mail.uu.net id QQjfin11313 for mpls-outgoing; Tue, 5 Sep 2000 14:19:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfin11303 for ; Tue, 5 Sep 2000 14:19:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfin07189 for ; Tue, 5 Sep 2000 10:19:08 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfin23076 for ; Tue, 5 Sep 2000 14:19:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA24207 for mpls@uu.net; Tue, 5 Sep 2000 10:19:06 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfin11286 for ; Tue, 5 Sep 2000 14:18:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfin07081 for ; Tue, 5 Sep 2000 10:18:49 -0400 (EDT) From: Spencer.Giacalone@predictive.com Received: from ares.predictive.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ares.predictive.com [63.67.30.134]) id QQjfin17460 for ; Tue, 5 Sep 2000 14:18:49 GMT To: "James V. Luciani" Cc: , , Subject: Re: control channel lambdas Date: Tue, 5 Sep 2000 10:18:47 -0400 Message-ID: X-MIMETrack: Serialize by Router on Ares/Predictive(Release 5.0.4a |July 24, 2000) at 09/05/2000 10:18:49 AM MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable

So is the specification of control lambdas an ITU area of work? Is there= any agreement at this time on a wavelength, or just proposals? You say to = "just pick one on the grid", but won't that effect interoperabili= ty?  What about determining/finding/checking/allocating redundant/dive= rse control channel Lambdas? Isn't it, err, important to insure that our co= ntrol channels -are- in the range of EDFAs? I mean, might not there be a ti= me when the control channel between 2 nodes is at maximum distance?

O= kay, enough questions out of me...

 

Thanks,

 =

Spence

 



"James V. L= uciani" <jluciani@tollbridgetech.com>
09/04/2000 04:05 PM AST
Please respond to &qu= ot;James V. Luciani"

To: <Spencer.Giacalone@predictive.com>, <mpls@UU.NET>=
cc: <Joseph.Abban@predictive.c= om>
bcc:
Subject: Re: control channel lambdas


= I have seen 3 general choices in literatur= e:
If the control channels are strictly hop by hop and you are running a= short
distance (i.e., no amplification needed for control channel) then= there have
been proposals to use 1310 or something at the end of the C = band (e.g.,
something on the ITU grid around 1510). The amplification an= d hop by hop
restrictions are there because usually EDFAs do not usually= amplify in these
wavelengths (although I guess some do now).  Thos= e wavelengths thus do not
steal from the set of useful data carrying wav= elengths which would be in the
range of EDFAs.  BTW, many receivers= are broad enough to receive 1310 even
if built for C band (this is a ba= ne as well as a boon); this was not the
case for the tunable lasers for = a while although I would not be surprised if
you can find them now.
I= f the restrictions on distance and amplication are not acceptable, then
= just pick one on the grid which your EDFAs cover.

--Jim

---- Original Message -----
From: <Spencer.Giacalone@predictive.com&= gt;
To: <mpls@UU.NET>
Cc: <Joseph.Abban@predictive.com>Sent: Wednesday, August 30, 2000 10:59 PM
Subject: control channel lam= bdas


> Can anyone poi= nt me in the direction of work that has been done to specify
> what l= ambdas controls channels should use?
>
> Thanks,
>
>= ; Spence

= From owner-mpls@UU.NET Tue Sep 5 10:40:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03686 for ; Tue, 5 Sep 2000 10:40:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfio09446; Tue, 5 Sep 2000 14:39:15 GMT Received: by mail-control.mail.uu.net id QQjfio12600 for mpls-outgoing; Tue, 5 Sep 2000 14:38:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfio12581 for ; Tue, 5 Sep 2000 14:38:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfio25390 for ; Tue, 5 Sep 2000 10:38:17 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfio08004 for ; Tue, 5 Sep 2000 14:37:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA27232 for mpls@uu.net; Tue, 5 Sep 2000 10:37:15 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfio12439 for ; Tue, 5 Sep 2000 14:36:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfio25077 for ; Tue, 5 Sep 2000 10:36:16 -0400 (EDT) Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjfio07026 for ; Tue, 5 Sep 2000 14:36:15 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA28559; Tue, 5 Sep 2000 07:36:09 -0700 (PDT) Message-Id: <200009051436.HAA28559@omega.cisco.com> To: "D'Albenzio Raffaele" cc: "'mpls@uu.net'" Subject: Re: Info about mpls-vpn In-reply-to: Your message of "Mon, 04 Sep 2000 16:21:24 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28557.968164569.1@cisco.com> Date: Tue, 05 Sep 2000 07:36:09 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Raffaele, > I have a question on draft-rosen-rfc2547bis, section 5. > > In the MPLS VPN architecture proposed in the draft, to ensure > interoperability among different implementations, it is required to support > LDP for setting up LSP across the backbone. However, other methods are > possible. > Can I use, for example, RSVP-TE extensions to create LSP between PEs? Yes you can. To do this you'll need to be able to correlate the tail-end of such LSPs with the Next-Hop carried in BGP. Yakov. From owner-mpls@UU.NET Tue Sep 5 10:52:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03963 for ; Tue, 5 Sep 2000 10:52:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfip18817; Tue, 5 Sep 2000 14:51:01 GMT Received: by mail-control.mail.uu.net id QQjfip13745 for mpls-outgoing; Tue, 5 Sep 2000 14:50:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfip13738 for ; Tue, 5 Sep 2000 14:50:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfip13519 for ; Tue, 5 Sep 2000 10:50:03 -0400 (EDT) From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjfip17719 for ; Tue, 5 Sep 2000 14:49:48 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Tue, 5 Sep 2000 15:48:55 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Tue, 5 Sep 2000 15:48:54 +0100 Message-ID: To: curtis@avici.com, raszuk@cisco.com Cc: Raffaele.Dalbenzio@CSELT.IT, mpls@UU.NET Subject: RE: Info about mpls-vpn Date: Tue, 5 Sep 2000 15:48:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, it would also be nice to know (esp for operators) the pros/cons of using various nested LDP-types. For example, in theory it seems I could run put BGP4 label-ditsributed LSPs (say for VPN constructs) over a server layer of vanilla-LDP distributed LSPs or RSVP-LDP distributed LSPs. I could also think of other nested LDP-type combinations. But a key question for me here is 'What is their dynamic behaviour under all types of fault condition'? I still have not got my head around this one, and I sure some modes of operation would be better than others. If anyone else has pondered on this and come to any views I would be grateful to hear them. Regards, Neil > -----Original Message----- > From: Curtis Villamizar [SMTP:curtis@avici.com] > Sent: Tuesday, September 05, 2000 2:36 PM > To: raszuk@cisco.com > Cc: D'Albenzio Raffaele; 'mpls@uu.net' > Subject: Re: Info about mpls-vpn > > > In message <39B3D417.43252FA8@cisco.com>, Robert Raszuk writes: > > > > Raffaele, > > > > Technically - yes. RSVP-TE or even GRE tunnels between PEs will work > > fine. > > > > Operationally you need to make sure that if you go this path you will > > need to engineer your TE LSPs the way that even at some failure > > conditions you will still have an active LSP connectivity between PEs. > > If not since you are not running LDP the core your PE-PE connectivity > > will be lost for VPN customers as falling back to plain IP will not > > help. > > > > R. > > > Don't build broken networks is always good advice. If you are not > using CAC (you are allowing overbooking but balancing traffic through > other means) then there is no issue. That just happens to be the only > supported mode for LDP (and there is no opportunity to balance traffic > to reduce load). > > Curtis From owner-mpls@UU.NET Tue Sep 5 11:26:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04909 for ; Tue, 5 Sep 2000 11:26:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfir06831; Tue, 5 Sep 2000 15:24:07 GMT Received: by mail-control.mail.uu.net id QQjfir28572 for mpls-outgoing; Tue, 5 Sep 2000 15:23:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfir28564 for ; Tue, 5 Sep 2000 15:23:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfir04675 for ; Tue, 5 Sep 2000 11:23:13 -0400 (EDT) Received: from apocalypse.quantum3d.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [206.184.176.5]) id QQjfir13232 for ; Tue, 5 Sep 2000 15:22:57 GMT Received: from saturn.quantum3d.com (SATURN [206.184.177.29]) by apocalypse.quantum3d.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QV1N4M7W; Tue, 5 Sep 2000 08:19:24 -0700 Received: from DT02017 ([206.184.177.31]) by saturn.quantum3d.com (Lotus Domino Release 5.0.4) with SMTP id 2000090508213686:2024 ; Tue, 5 Sep 2000 08:21:36 -0700 Reply-To: From: "Thomas Huang" To: "'S.Matsushima'" , Subject: MPLS based VPN services from ATT // RE: ISPs offering VPN service Date: Wed, 22 Sep 1999 08:25:35 -0700 Message-ID: <002601bf050e$b8445430$4664a8c0@DT02017> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <20000904200043O.satoru@japan-telecom.co.jp> X-MIMETrack: Itemize by SMTP Server on saturn/Polaris(Release 5.0.4 |June 8, 2000) at 09/05/2000 08:21:36 AM, Serialize by Router on saturn/Polaris(Release 5.0.4 |June 8, 2000) at 09/05/2000 08:21:38 AM, Serialize complete at 09/05/2000 08:21:38 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In addition to NTT, I think AT&T announced MPLS based VPN service, which is based on their ATM infrastructure at that time. I attached the article that I received that time FYI. Thomas Huang FOR RELEASE WEDNESDAY, JULY 26, 2000 AT&T Announces New Portfolio Of Enterprise-Class Networking And Broadband Virtual Private Network (VPN) Services For Businesses Company Debuts Enterprise-Class Hosting, Public Key Infrastructure and Network-Based Firewall Services BASKING RIDGE, N.J. - AT&T announced today a new array of enterprise-class networking elements to boost the security, scalability, and speed of its next generation business networks. In a related announcement today, AT&T said it has enriched its Broadband Business Services portfolio and has accelerated the market roll out of its Digital Subscriber Line (DSL) Internet service. "AT&T is providing businesses with an unparalleled networking environment to augment the security and scalability of their intranets, extranets and remote access VPNs," said Kathleen Earley, president of AT&T Data and Internet Services. "This array of new capabilities meets the diverse networking needs of all businesses. We've got it all and it's available today." "A market renaissance for IP VPNs is just around the corner as service providers overcome technical and market obstacles that have made IVPN implementation and selection difficult," said Eric Hindin, vice president at The Yankee Group. "AT&T's position in the IVPN market is looking very strong. Based largely on the strength of its IP-Enabled Frame Relay service, we expect AT&T to take over the top overall IVPN market-share position by the end of 2000. The service is extremely popular with existing Frame Relay customers and has sent AT&T's Frame Relay and IVPN competitors scrambling to build similar services. These latest announcements contain a number of industry firsts and will help AT&T maintain that lead, by meeting customer requirements in areas including higher speeds and more robust security." For businesses using their Frame Relay networks to carry mission-critical hosted applications, AT&T is enabling them to connect their networks to AT&T Internet Data Centers (IDCs). For small- to mid-sized businesses that want to extend the functionality of their DSL Internet connections, AT&T will offer them the ability to create IPSec-compliant broadband VPNs. For businesses that want to extend the reach and flexibility of their ATM networks, AT&T has IP-enabled that network and will provide additional Quality of Service (QoS) functionality using Multi Protocol Label Switching (MPLS) capabilities. And for businesses that want to establish trading communities and secure extranets, AT&T is announcing its Public Key Infrastructure that will allow business partners, suppliers and vendors using multiple carriers to exchange digital certificates in a secure and trusted network environment. In addition, AT&T now will offer DSL access to its market-leading Frame Relay network, which has been performing at a precedent-setting 99.999 percent ("Five Nines") reliability this year. The company also has developed a network-based security utility to provide Internet access for businesses that already use their Frame Relay networks for intranet applications. Secure Networks Broadband VPNs For small- and medium-sized businesses that want to create IP-based Wide Area Networks to connect their branch locations, franchises, suppliers and distributors via dedicated, secure DSL connections, AT&T today announced a trial of broadband-based VPN services. This service complements the existing capabilities offered through AT&T's suite of award-winning Global Remote Access VPN services and features end-to-end IPSec delivered over "always-on," high-speed, multi-user DSL and cable access lines. This service, currently in controlled introduction, allows users to link to and share applications via a centrally located managed VPN gateway, which acts as the termination point for multiple IPSec tunnels. AT&T Broadband VPN service will be generally availability in September 2000. Public Key Infrastructure For businesses that want to establish trading communities and secure extranets, AT&T is announcing its Public Key Infrastructure (PKI) and will now offer digital certificates as an option supporting VPN Internet Protocol Security (IPSec). The PKI will allow business partners, suppliers and vendors using multiple carriers to exchange digital certificates in a secure and trusted network environment. Businesses that need extranets for their suppliers, employees, and customers can take special advantage of this architecture. AT&T's Managed IPSec feature provides businesses with a highly secure, scalable, and interoperable means to globally connect end users across multiple networks and service providers. Digital certificates are used to authenticate a user's identity when connecting businesses and their computers to the Internet. AT&T is building a PKI to generate, maintain, and manage the digital certificates used for this service. AT&T plans to offer PKI services in the third quarter of 2000. Pricing will be announced upon availability. Network-based Security For businesses that already use their Frame Relay networks for intranet applications, AT&T also announced today an Advanced Network Based Security Utility that extends the functionality of AT&T's existing Network Based Firewall Service. Now businesses can use their Frame Relay networks to securely access the Internet as well as to run intranet applications. This offer helps businesses leverage their existing Frame Relay networks without burdening their hub sites and frame VPNs. It eliminates the need for customer premises infrastructure and for the highly specialized staff required to administer and to manage that infrastructure around-the-clock. The utility is hosted in an AT&T-secured facility with redundant connections to AT&T's Frame Relay and IP networks. AT&T will conduct market trials of the service in the fourth quarter of 2000. Scalable Network Environment Internet Data Center Connectivity to Private Data Networks AT&T also will extend the reach of its Internet Data Centers (IDCs) by connecting them to both the public Internet as well as secure, private data networks. This means businesses will be able to terminate both private enterprise VPNs and Internet-based VPNs within AT&T's Internet Data Centers. This is a tremendous benefit to corporations interested in outsourcing hosted applications. By connecting AT&T IDCs to its private IP-enabled high-speed packet services, AT&T will allow businesses to host applications in an enterprise-class networking environment with industry-leading security and network Service Level Agreements (SLAs). These network SLAs include a 99.99 percent network availability, a 60-millisecond latency guarantee and repair times in four hours or less. This capability will further enhance AT&T's ability to meet the needs of the ASP marketplace. ASPs can now deploy applications not only on AT&T's OC192/OC48 IP backbone, but also on its secure enterprise-class private data network. Shared Frame Relay connections at speeds of 56Kbps and 128Kbps are available today at AT&T's San Diego, Redwood City, Mesa and New York City data centers. AT&T, BT and Concert jointly announced plans in April to invest $2 billion over three years to deliver seamless, global e-commerce services via a network of 44 IDCs in 16 countries. MPLS for ATM To help businesses address critical internetworking issues, AT&T today also debuted IP-Enabled ATM. This new feature complements AT&T's existing IP-Enabled Frame Relay service and means businesses can use their existing Frame Relay and ATM networks to build IP-based intranets and extranets without having to build a separate IP network or modify the IP applications they are using. Both services use standards-based MPLS. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of S.Matsushima Sent: Monday, September 04, 2000 4:01 AM To: mpls@UU.NET Subject: RE: ISPs offering VPN service Hi, As far as i know... There are two VPN services based on MPLS which named SOLTERIA provided by JAPAN-TELECOM,and Super-VPN provided by NTT-Communications, in Japan. GlobalOne has a international VPN service named Global Intranet VPN, it's based on MPLS too. regards. -- Satoru Matsushima From: Cor van Rij Subject: RE: ISPs offering VPN service Date: Mon, 4 Sep 2000 12:25:04 +0200 > Hi > > VersaTel will offer it within the next 6 months > > regards > > cor > > > -----Original Message----- > > From: Juan Diego Otero [SMTP:diego@estos.upc.es] > > Sent: maandag 4 september 2000 13:04 > > To: MPLS WG > > Subject: ISPs offering VPN service > > > > Hi, > > > > I would like to know if there is any ISP currently > > offering (or if it is planning to do it) > > a VPN service based on MPLS. > > > > Thanks a lot > > > > Diego Otero > From owner-mpls@UU.NET Tue Sep 5 14:00:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10041 for ; Tue, 5 Sep 2000 14:00:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfjb02990; Tue, 5 Sep 2000 17:59:16 GMT Received: by mail-control.mail.uu.net id QQjfjb07238 for mpls-outgoing; Tue, 5 Sep 2000 17:58:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfjb07228 for ; Tue, 5 Sep 2000 17:58:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfjb05840 for ; Tue, 5 Sep 2000 13:58:33 -0400 (EDT) Received: from maplenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82]) id QQjfjb06544 for ; Tue, 5 Sep 2000 17:58:28 GMT Received: from prasuncomp (farhad_pc [192.168.10.239]) by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id KAA04838 for ; Tue, 5 Sep 2000 10:58:22 -0700 (PDT) Message-ID: <00d001c01763$3257f440$ef0aa8c0@maplenetworks.com> From: "Sudhanshu Jain" To: Subject: OSPF on FA-LSP Date: Tue, 5 Sep 2000 11:00:37 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01C01728.85B5F8C0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C01728.85B5F8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I am looking for OSPF procedure on Forwarding Adjacency(FA)-LSP. Is = there any specific work done on that? Assume a FA-LSP without any control packet flowing through the FA-LSP.=20 In such a case, is it possible to use procedures similar to section 5.1 = in draft-kompella-lsp-hierarchy-00.txt (section 5.1) for OSPF with or = without un-numbered support? Thanks, -Sudhanshu ------=_NextPart_000_00CD_01C01728.85B5F8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I am looking for OSPF procedure on = Forwarding=20 Adjacency(FA)-LSP. Is there any specific work done on that?
 
Assume a FA-LSP without any control = packet flowing=20 through the FA-LSP.
 
In such a case, is it possible to use = procedures=20 similar to section 5.1 in draft-kompella-lsp-hierarchy-00.txt (section = 5.1) for=20 OSPF with or without un-numbered support?
 
Thanks,
-Sudhanshu
------=_NextPart_000_00CD_01C01728.85B5F8C0-- From owner-mpls@UU.NET Tue Sep 5 14:27:29 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10746 for ; Tue, 5 Sep 2000 14:27:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfjd24196; Tue, 5 Sep 2000 18:26:45 GMT Received: by mail-control.mail.uu.net id QQjfjd21618 for mpls-outgoing; Tue, 5 Sep 2000 18:26:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfjd21583 for ; Tue, 5 Sep 2000 18:25:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfjd24036 for ; Tue, 5 Sep 2000 14:25:48 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQjfjd23131 for ; Tue, 5 Sep 2000 18:25:48 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA14498; Tue, 5 Sep 2000 11:25:43 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id LAA03147; Tue, 5 Sep 2000 11:24:23 -0700 (PDT) Date: Tue, 5 Sep 2000 11:24:23 -0700 (PDT) From: Kireeti Kompella Message-Id: <200009051824.LAA03147@kummer.juniper.net> To: mpls@UU.NET, sjain@maplenetworks.com Subject: Re: OSPF on FA-LSP Sender: owner-mpls@UU.NET Precedence: bulk > I am looking for OSPF procedure on Forwarding Adjacency(FA)-LSP. Is > there any specific work done on that? > > Assume a FA-LSP without any control packet flowing through the FA-LSP. > > In such a case, is it possible to use procedures similar to section 5.1 > in draft-kompella-lsp-hierarchy-00.txt (section 5.1) for OSPF with or > without un-numbered support? Why would you want to do this? Kireeti. From owner-mpls@UU.NET Tue Sep 5 15:10:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11549 for ; Tue, 5 Sep 2000 15:10:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfjg00855; Tue, 5 Sep 2000 19:09:53 GMT Received: by mail-control.mail.uu.net id QQjfjg06964 for mpls-outgoing; Tue, 5 Sep 2000 19:09:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfjg06938 for ; Tue, 5 Sep 2000 19:09:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfjg22680 for ; Tue, 5 Sep 2000 15:09:07 -0400 (EDT) Received: from maplenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82]) id QQjfjg29828 for ; Tue, 5 Sep 2000 19:08:47 GMT Received: from prasuncomp (farhad_pc [192.168.10.239]) by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id LAA05933; Tue, 5 Sep 2000 11:49:09 -0700 (PDT) Message-ID: <00fa01c0176a$4f2d1260$ef0aa8c0@maplenetworks.com> From: "Sudhanshu Jain" To: "Kireeti Kompella" , References: <200009051824.LAA03147@kummer.juniper.net> Subject: Re: OSPF on FA-LSP Date: Tue, 5 Sep 2000 11:51:24 -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 Hi Kireeti, One of the reason is these FA-LSP could be STS switched path but these path are TDM capable ( e.g STS-48 which is allowed to set 16 STS-3 channel). For this purpose, one possibility is to have a dedicated Control channel and let all control traffic flow on it. Or use some other indirect method to learn route on it. -Sudhanshu ----- Original Message ----- From: "Kireeti Kompella" To: ; Sent: Tuesday, September 05, 2000 11:24 AM Subject: Re: OSPF on FA-LSP > > I am looking for OSPF procedure on Forwarding Adjacency(FA)-LSP. Is > > there any specific work done on that? > > > > Assume a FA-LSP without any control packet flowing through the FA-LSP. > > > > In such a case, is it possible to use procedures similar to section 5.1 > > in draft-kompella-lsp-hierarchy-00.txt (section 5.1) for OSPF with or > > without un-numbered support? > > Why would you want to do this? > > Kireeti. > From owner-mpls@UU.NET Tue Sep 5 15:56:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12685 for ; Tue, 5 Sep 2000 15:56:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfjj07974; Tue, 5 Sep 2000 19:55:28 GMT Received: by mail-control.mail.uu.net id QQjfjj13250 for mpls-outgoing; Tue, 5 Sep 2000 19:55:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfjj13235 for ; Tue, 5 Sep 2000 19:54:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfjj03904 for ; Tue, 5 Sep 2000 15:54:52 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQjfjj07065 for ; Tue, 5 Sep 2000 19:54:35 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA20164; Tue, 5 Sep 2000 12:54:33 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id MAA03485; Tue, 5 Sep 2000 12:53:12 -0700 (PDT) Date: Tue, 5 Sep 2000 12:53:12 -0700 (PDT) From: Kireeti Kompella Message-Id: <200009051953.MAA03485@kummer.juniper.net> To: kireeti@juniper.net, mpls@UU.NET, sjain@maplenetworks.com Subject: Re: OSPF on FA-LSP Sender: owner-mpls@UU.NET Precedence: bulk Hi Sudhanshu, > One of the reason is these FA-LSP could be STS switched path but these path > are TDM capable ( e.g STS-48 which is allowed to set 16 STS-3 channel). > > For this purpose, one possibility is to have a dedicated Control channel and > let all control traffic flow on it. Or use some other indirect method to > learn route on it. I'm not sure I understand. However, note that we assume that the "LSRs" in an optical network are all running OSPF (or ISIS). So, the head end and the tail end of the FA-LSP should already be 'connected' by OSPF. Route and TE information are flooded using standard OSPF mechanisms. As for a control channel, some means of communicating control info between every pair of adjacent LSRs is also assumed. Remote communication is only needed (we think) for RSVP signalling of tunneled LSPs (hence section 5.1); this is not needed for OSPF or ISIS. But if you think remote OSPF is needed, perhaps virtual links are what you want? Kireeti. From owner-mpls@UU.NET Tue Sep 5 18:02:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14751 for ; Tue, 5 Sep 2000 18:02:23 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfjs10843; Tue, 5 Sep 2000 22:01:40 GMT Received: by mail-control.mail.uu.net id QQjfjs20579 for mpls-outgoing; Tue, 5 Sep 2000 22:01:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfjs19645 for ; Tue, 5 Sep 2000 22:01:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfjs09862 for ; Tue, 5 Sep 2000 18:00:53 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfjs17754 for ; Tue, 5 Sep 2000 22:00:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA28350 for mpls@uu.net; Tue, 5 Sep 2000 18:00:52 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfjs17262 for ; Tue, 5 Sep 2000 22:00:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfjs00627; Tue, 5 Sep 2000 18:00:04 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjfjs09495; Tue, 5 Sep 2000 22:00:02 GMT Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA11810; Tue, 5 Sep 2000 15:00:23 -0700 (PDT) Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by bulkrate.cisco.com (Mirapoint) with ESMTP id ACG00828; Tue, 5 Sep 2000 15:00:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20000906084934.00b09300@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 08:59:54 +1100 To: Florian-Daniel Otel From: Jeremy Lawrence Subject: Re: Incremental MPLS (BCP document lookup) Cc: mpls@UU.NET, te-wg@UU.NET In-Reply-To: <14772.57045.342364.820985@blomman13.ce.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Florian, >I am looking for a case study document/white paper focused >on/describing the possible means (maybe even claimed advantages ?) of >introducing MPLS in a _incremental_ manner in a core network. What does the core network look like before MPLS is turned on? If the core network is an IP router network then there is at least one router implementation where MPLS signalling (LDP or RSVP) can be enabled on a link-by-link basis in a live network (possibly after a software upgrade, which can be done node-by-node). The advantage of is largely that the network can still be forwarding IP traffic while the MPLS upgrade is going on. If the core network is an ATM network, there are many more options. Regards, Jeremy From owner-mpls@UU.NET Wed Sep 6 04:44:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05775 for ; Wed, 6 Sep 2000 04:44:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfli23450; Wed, 6 Sep 2000 08:42:59 GMT Received: by mail-control.mail.uu.net id QQjfli01980 for mpls-outgoing; Wed, 6 Sep 2000 08:42:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfli01974 for ; Wed, 6 Sep 2000 08:42:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfli16955; Wed, 6 Sep 2000 04:42:36 -0400 (EDT) Received: from solen.ce.chalmers.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQjfli23155; Wed, 6 Sep 2000 08:42:36 GMT Received: from blomman13.ce.chalmers.se (blomman13.ce.chalmers.se [129.16.21.43]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id KAA02001; Wed, 6 Sep 2000 10:42:35 +0200 (MEST) Received: (from otel@localhost) by blomman13.ce.chalmers.se (8.8.8/8.8.8) id KAA01315; Wed, 6 Sep 2000 10:42:34 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14774.890.822433.702863@blomman13.ce.chalmers.se> Date: Wed, 6 Sep 2000 10:42:34 +0200 (MEST) From: Florian-Daniel Otel To: Jeremy Lawrence Cc: mpls@UU.NET, te-wg@UU.NET Subject: Re: Incremental MPLS (BCP document lookup) In-Reply-To: <4.3.2.7.2.20000906084934.00b09300@bulkrate.cisco.com> References: <14772.57045.342364.820985@blomman13.ce.chalmers.se> <4.3.2.7.2.20000906084934.00b09300@bulkrate.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Florian-Daniel Otel Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy, First of all, thanks for the insight. Second, as I didn't get any replies other than yours I will expand (below) the reason for my questioning. > Florian, >> I am looking for a case study document/white paper focused >> on/describing the possible means (maybe even claimed advantages ?) of >> introducing MPLS in a _incremental_ manner in a core network. > What does the core network look like before MPLS is turned on? Very plain and very simple: It is a transit network, small core size (< 10 routers) , star-of-stars topology, IP over PPP/HDLC connections. Two external links to higher tier ISPs and several "customer" links. The network carries basically two diffent types of traffic that have to be distributed. The two types of traffic source from several locations, with some locations sourcing both types. The way they are handling it right now is w/ BGP peering as the traffic is mostly inter-AS bound. The claimed advantage of using MPLS on this simplistic topology is that the two types of traffic can be aggregated at different levels and the trunks handled independently. > If the core network is an IP router network then there is at least > one router implementation where MPLS signalling (LDP or RSVP) can be > enabled on a link-by-link basis in a live network (possibly after a > software upgrade, which can be done node-by-node). The advantage > of is largely that the network can still be forwarding IP traffic > while the MPLS upgrade is going on. Giving the "if-it-works-don't-fix-it" attitude towards things of most operators in order to make a successful "MPLS sales" job to the operator one has to convince them that they can do it incrementally with minimum fuss (this operator attidude is "we don't want increased or even _different_ complexity than the one we have now.."). That is why running RSVP or LDP won't do it. What I had in mind was that, at least in initial stages, they should hook label distribution on existing BGP peering and do independent LSP control. And after they get confortable w/ it they can start doing fancier stuff like running RSVP-TE/CR-LDP e.g to reserve resources (bandwidth) based on traffic type, etc. Anything wrong with this picture ? Ideas ? All in all that is why I was looking for a document describing a way to incrementally implement MPLS in a net and the claimed advantages...;) > Regards, > Jeremy All the best, Florian. P.S: This might be more of an operational (TE) question than mpls so if you consider it off-topic please reply off-list. From owner-mpls@UU.NET Wed Sep 6 06:46:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07057 for ; Wed, 6 Sep 2000 06:46:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjflr12681; Wed, 6 Sep 2000 10:45:55 GMT Received: by mail-control.mail.uu.net id QQjflr02983 for mpls-outgoing; Wed, 6 Sep 2000 10:45:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjflr02978 for ; Wed, 6 Sep 2000 10:45:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjflr11166 for ; Wed, 6 Sep 2000 06:45:18 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjflr12228 for ; Wed, 6 Sep 2000 10:45:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA08142 for mpls@uu.net; Wed, 6 Sep 2000 06:45:17 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjflq02753 for ; Wed, 6 Sep 2000 10:44:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjflq28507; Wed, 6 Sep 2000 06:44:41 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjflq11767; Wed, 6 Sep 2000 10:44:41 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06876; Wed, 6 Sep 2000 06:44:40 -0400 (EDT) Message-Id: <200009061044.GAA06876@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, te-wg@UU.NET, ospf@discuss.microsoft.com, isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-dharanikota-interarea-mpls-te-ext-00.txt Date: Wed, 06 Sep 2000 06:44:37 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF, IS-IS, RSVP, CR-LDP Extensions to Support Inter-Area Traffic Engineering Using MPLS TE Author(s) : S. Dharanikota, S. Venkatachalam Filename : draft-dharanikota-interarea-mpls-te-ext-00.txt Pages : 20 Date : 05-Sep-00 In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_FWK] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_FWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt 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-dharanikota-interarea-mpls-te-ext-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-dharanikota-interarea-mpls-te-ext-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: <20000905135234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dharanikota-interarea-mpls-te-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135234.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Sep 6 07:33:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08124 for ; Wed, 6 Sep 2000 07:33:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjflu09978; Wed, 6 Sep 2000 11:32:55 GMT Received: by mail-control.mail.uu.net id QQjflu17705 for mpls-outgoing; Wed, 6 Sep 2000 11:32:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjflu17700 for ; Wed, 6 Sep 2000 11:32:24 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjflu03735 for ; Wed, 6 Sep 2000 07:32:10 -0400 (EDT) Received: from beamer.mchh.siemens.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQjflu17288 for ; Wed, 6 Sep 2000 11:32:05 GMT Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA02362; Wed, 6 Sep 2000 13:31:33 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA13475; Wed, 6 Sep 2000 13:28:39 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Sep 2000 13:31:58 +0200 Message-ID: From: Heiles Juergen To: "'Spencer.Giacalone@predictive.com'" , "James V. Luciani" Cc: mpls@UU.NET, Joseph.Abban@predictive.com Subject: AW: control channel lambdas Date: Wed, 6 Sep 2000 13:31:55 +0200 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA08124 The ITU has defined in G.692 "Optical Interfaces for Multichannel systems with Optical Amplifiers" wavelengths for the Optical Supervisory Channel OSC. The defined wavelength is 1510 nm and 1480, 1310 nm as alternatives. These are all outside of todays EDFA bands. G.692 is specific for SDH WDM systems. ITU iscurrently working on G.959.1 which will define the Optical interfaces for the Optical Transport Network OTN. The OSC normally runs between line amplifiers as the amplifiers require access to the OSC for management and control purposes. The OSC has therefore only to cross a span between line amplifiers. This can be achieved without amplification as the OSC bit rate is lower as the payload bit rate. Network operators don't won't to spent an in-band channel or the OSC as it can be used for revenue bearing traffic. Note that it will get more and more difficult to standardize out-of-band OSC wavelengths as the bands used for payload channels will be extended more and more. Today we use the C and L band and a new S band below the C band is proposed. In addition Raman amplification will conflict with for example 1510 and 1480 nm OSCs. The ITU is currently discussing the need for a dedicaded OSC for the inter-domain interface. For the intra-domain, specially for long haul applications the interfaces will be vendor specific in any case as every vendor will optimize its system for maximum distance or maximum capacity. I don't think that we can achieve interworking for these interfaces. Juergen > -----Urspr> üngliche Nachricht----- > Von: Spencer.Giacalone@predictive.com [SMTP:Spencer.Giacalone@predictive.com] > Gesendet am: Dienstag, 5. September 2000 16:19 > An: James V. Luciani > Cc: Spencer.Giacalone@predictive.com; mpls@UU.NET; Joseph.Abban@predictive.com > Betreff: Re: control channel lambdas > > So is the specification of control lambdas an ITU area of work? Is there any agreement at this time on a wavelength, or just proposals? You say to "just pick one on the grid", but won't that effect interoperability? What about determining/finding/checking/allocating redundant/diverse control channel Lambdas? Isn't it, err, important to insure that our control channels -are- in the range of EDFAs? I mean, might not there be a time when the control channel between 2 nodes is at maximum distance? > > Okay, enough questions out of me... > > > > Thanks, > > > > Spence > > > > > > "James V. Luciani" > 09/04/2000 04:05 PM AST > Please respond to "James V. Luciani" > > To: , > cc: > bcc: > Subject: Re: control channel lambdas > > > > > I have seen 3 general choices in literature: > If the control channels are strictly hop by hop and you are running a short > distance (i.e., no amplification needed for control channel) then there have > been proposals to use 1310 or something at the end of the C band (e.g., > something on the ITU grid around 1510). The amplification and hop by hop > restrictions are there because usually EDFAs do not usually amplify in these > wavelengths (although I guess some do now). Those wavelengths thus do not > steal from the set of useful data carrying wavelengths which would be in the > range of EDFAs. BTW, many receivers are broad enough to receive 1310 even > if built for C band (this is a bane as well as a boon); this was not the > case for the tunable lasers for a while although I would not be surprised if > you can find them now. > If the restrictions on distance and amplication are not acceptable, then > just pick one on the grid which your EDFAs cover. > > --Jim > > ---- Original Message ----- > From: > To: > Cc: > Sent: Wednesday, August 30, 2000 10:59 PM > Subject: control channel lambdas > > > > Can anyone point me in the direction of work that has been done to specify > > what lambdas controls channels should use? > > > > Thanks, > > > > Spence > > From owner-mpls@UU.NET Wed Sep 6 09:54:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12431 for ; Wed, 6 Sep 2000 09:54:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmd11680; Wed, 6 Sep 2000 13:53:54 GMT Received: by mail-control.mail.uu.net id QQjfmd21651 for mpls-outgoing; Wed, 6 Sep 2000 13:53:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfmd21646 for ; Wed, 6 Sep 2000 13:53:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfmd07239 for ; Wed, 6 Sep 2000 09:53:17 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfmd11108 for ; Wed, 6 Sep 2000 13:53:17 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA13919 for ; Wed, 6 Sep 2000 06:53:35 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA25168 for mpls@uu.net; Wed, 6 Sep 2000 09:53:15 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfgk07716 for ; Tue, 5 Sep 2000 00:43:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfgk00102 for ; Mon, 4 Sep 2000 20:43:09 -0400 (EDT) Received: from rip.psg.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjfgk00192 for ; Tue, 5 Sep 2000 00:43:09 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13W6pQ-0001bN-00 for mpls@uu.net; Mon, 04 Sep 2000 17:43:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: mpls wg Subject: RE: ISPs offering VPN service References: <002801c016cf$d74d90c0$7cdf11cf@jesus> Message-Id: Date: Mon, 04 Sep 2000 17:43:08 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ok. i have to ask. we have one early vpn customer who alone has over a thousand vpns (lots of branches). so, if i have a few hundred thousand 2547 vpns in my network, now is bgp gonna like this? how will the pes perform? is this thing actually gonna scale, or does it look good for six months and then run out of gas leaving me with a lot of burned customers? [ and, in case you were gonna ask, i believe ipsec will scale to millions, essentially because it follows the internet architectural principle to have the smarts at the edges, not the center ] randy From owner-mpls@UU.NET Wed Sep 6 11:31:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15082 for ; Wed, 6 Sep 2000 11:31:15 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmj27563; Wed, 6 Sep 2000 15:29:56 GMT Received: by mail-control.mail.uu.net id QQjfmj24662 for mpls-outgoing; Wed, 6 Sep 2000 15:29:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfmj24655 for ; Wed, 6 Sep 2000 15:29:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfmj16554 for ; Wed, 6 Sep 2000 11:29:19 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQjfmj13447 for ; Wed, 6 Sep 2000 15:29:03 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA03643; Wed, 6 Sep 2000 11:28:27 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Randy Bush'" , "'mpls wg'" Subject: RE: ISPs offering VPN service Date: Wed, 6 Sep 2000 11:28:24 -0400 Message-ID: <00a901c01817$19c79ac0$d001010a@tst.ennovatenetworks.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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Randy > Bush > Sent: Monday, September 04, 2000 8:43 PM > To: mpls wg > Subject: RE: ISPs offering VPN service > > > ok. i have to ask. > > we have one early vpn customer who alone has over a thousand > vpns (lots of > branches). so, if i have a few hundred thousand 2547 vpns in > my network, > now is bgp gonna like this? how will the pes perform? > > is this thing actually gonna scale, or does it look good for > six months > and then run out of gas leaving me with a lot of burned customers? > I think you are probably right. It seems that the model in RFC 2547 may be flawed because it fails to separate internal VPN control and configuration within a domain from the routing control plane primarily designed for carrying external inter- domain transit traffic. Besides the scalability problems you mentioned, adding VPN related policies (basically, internal traffic of a domain) to something that was originally designed to provide policy control of inter-domain traffic doesn't seem obviously appropriate. It is not going to help busy network administrators who need to manage large number of BGP nodes, and resolve policy conflicts in increasingly large and complex networks. Cheers, --brijesh Ennovate Networks Inc. From owner-mpls@UU.NET Wed Sep 6 12:19:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16466 for ; Wed, 6 Sep 2000 12:19:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmn22625; Wed, 6 Sep 2000 16:18:47 GMT Received: by mail-control.mail.uu.net id QQjfmn11375 for mpls-outgoing; Wed, 6 Sep 2000 16:18:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfmn11350 for ; Wed, 6 Sep 2000 16:17:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfmn26896 for ; Wed, 6 Sep 2000 12:17:38 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfmn05900 for ; Wed, 6 Sep 2000 16:17:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA14213 for mpls@uu.net; Wed, 6 Sep 2000 12:17:22 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfmn11229 for ; Wed, 6 Sep 2000 16:16:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfmn05402 for ; Wed, 6 Sep 2000 12:16:26 -0400 (EDT) Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjfmn20648 for ; Wed, 6 Sep 2000 16:16:25 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA14899; Wed, 6 Sep 2000 09:16:02 -0700 (PDT) Message-Id: <200009061616.JAA14899@omega.cisco.com> To: Randy Bush cc: mpls wg Subject: Re: ISPs offering VPN service In-reply-to: Your message of "Mon, 04 Sep 2000 17:43:08 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14897.968256962.1@cisco.com> Date: Wed, 06 Sep 2000 09:16:02 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Randy, > ok. i have to ask. And I'll try to answer :-) > we have one early vpn customer who alone has over a thousand vpns (lots of > branches). so, if i have a few hundred thousand 2547 vpns in my network, > now is bgp gonna like this? Could you be more specific, please. > how will the pes perform? Could you be more specific, please. > is this thing actually gonna scale, or does it look good for six months > and then run out of gas leaving me with a lot of burned customers? The scalability analysis is presented in Section 15 of draft-rosen-rfc2547bis-02.txt. I hope that analysis answers your question. > [ and, in case you were gonna ask, i believe ipsec will scale to millions, Is it just your *belief* that "ipsec will scale to millions", or do you have some formal analysis to support this. And, by the way, there are several ways to use IPSec to build VPNs. Which one you have in mind ? > essentially because it follows the internet architectural principle to > have the smarts at the edges, not the center ] "the smarts at the edges" is precisely the model used by BGP/MPLS VPN. So, following your logic, BGP/MPLS VPN "will scale to millions". Yakov. From owner-mpls@UU.NET Wed Sep 6 12:50:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17464 for ; Wed, 6 Sep 2000 12:50:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmp02418; Wed, 6 Sep 2000 16:49:12 GMT Received: by mail-control.mail.uu.net id QQjfmp13229 for mpls-outgoing; Wed, 6 Sep 2000 16:48:34 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfmp13223 for ; Wed, 6 Sep 2000 16:48:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfmp11456 for ; Wed, 6 Sep 2000 12:48:25 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfmp01711 for ; Wed, 6 Sep 2000 16:48:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA18447 for mpls@uu.net; Wed, 6 Sep 2000 12:48:23 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfmp13200 for ; Wed, 6 Sep 2000 16:47:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfmp11277 for ; Wed, 6 Sep 2000 12:47:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjfmp00834 for ; Wed, 6 Sep 2000 16:47:19 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA09576; Wed, 6 Sep 2000 09:47:39 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA11093; Wed, 6 Sep 2000 09:47:21 -0700 (PDT) Message-ID: <39B675CD.840D4FF8@cisco.com> Date: Wed, 06 Sep 2000 09:50:21 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: mpls wg Subject: Re: ISPs offering VPN service References: <002801c016cf$d74d90c0$7cdf11cf@jesus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Randy, Let me try to add few comments to Yakov's earlier response. > we have one early vpn customer who alone has over a thousand vpns (lots of > branches). so, if i have a few hundred thousand 2547 vpns in my network, > now is bgp gonna like this? First if this is one customer this typically means one vpn as all branches will belong to the same vpn. How he requires to interconnect them is still flexible both full mesh (any talks to any) or hub and spoke (branches jaust talk to headquarter) is just a matter of one ext community value configuration. Now regarding the scaling issue. First note that the number of vpns does not really matter at all here. What matters is the number of routes injected by each vpn member. In your case typically braches have one subnet so few thousands of prefixes is still not the issue. > how will the pes perform? During my current deployment experience with multiple customers there was never an issue with the PE scaling. Why ? - since I have never came across any VPN site which would not fit to the PE. So as long as this condition holds when one PE get's full (I mean he memory is getting full or CPU for what ever reason is dying) one can easily add another PE and still grow easily. Ok now depending what hardware/software you are using you may get some scaling limitations on vpnv4 reflector simply due to the fact that in some cases you may find end customers networks messed up big time without any hope for summarization. So what we can do here is a few things: reflector partitioning (based on RT value), (including pushing ORF to PEs), use router with more memory/cpu power or even use zebra. > is this thing actually gonna scale, or does it look good for six months > and then run out of gas leaving me with a lot of burned customers? For deployed customers I don't think there is an issue. For new customers down the path when your current capapcity get's busy they would need to wait before being added. > [ and, in case you were gonna ask, i believe ipsec will scale to millions, > essentially because it follows the internet architectural principle to > have the smarts at the edges, not the center ] There are different ways to provide VPNs and all have it's own usage. It was said a lot of time but ipsec has slight issue with overlay scheme associated maintenance. Setting thousands of vpns with nice tool may not be an issue but reconfiguring it based on the customer's open tickets is a good job security for some time in the NOC. In MPLS-VPNs all smarts are on the edge. In fact expcept reflectors (which could also be on the edge) core has not idea that there is any vpn at all. One of the biggest advantages except easy addtion/modifications of membership or policy I find the dramatic reduction of customer's routing peers all across his network as he will peer with one (maybe two for redundancy) rather with thousands. R. From owner-mpls@UU.NET Wed Sep 6 12:54:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17553 for ; Wed, 6 Sep 2000 12:54:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmp19823; Wed, 6 Sep 2000 16:53:14 GMT Received: by mail-control.mail.uu.net id QQjfmp13479 for mpls-outgoing; Wed, 6 Sep 2000 16:52:55 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfmp13460 for ; Wed, 6 Sep 2000 16:52:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfmp12342 for ; Wed, 6 Sep 2000 12:52:39 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjfmp05022 for ; Wed, 6 Sep 2000 16:52:08 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA13437; Wed, 6 Sep 2000 09:52:28 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA25675; Wed, 6 Sep 2000 12:52:06 -0400 (EDT) Message-Id: <200009061652.MAA25675@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: bkumar@ennovatenetworks.com cc: "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service In-reply-to: Your message of Wed, 06 Sep 2000 11:28:24 -0400. <00a901c01817$19c79ac0$d001010a@tst.ennovatenetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 06 Sep 2000 12:52:06 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Brijesh> I think you are probably right. It seems that the model in RFC 2547 Brijesh> may be flawed because it fails to separate internal VPN control and Brijesh> configuration within a domain from the routing control plane Brijesh> primarily designed for carrying external inter-domain transit Brijesh> traffic. No it doesn't. It does use BGP for both purposes though. The fact that technology which is primarily designed for one application is also used for a second application is not generally considered to be a bad thing. Brijesh> adding VPN related policies (basically, internal traffic of a Brijesh> domain) to something that was originally designed to provide policy Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. The "VPN-related policies" are primarily expressed as filtering on community attributes, which is actually fits in quite well with normal BGP functions. Brijesh> Besides the scalability problems you mentioned, The only scalability problem Randy mentioned is that as you get more customers, you might have to add more equipment. I'd like to see the scheme in which the hardware cost is independent of the load! Brijesh> It is not going to help busy network administrators who need to Brijesh> manage large number of BGP nodes, and resolve policy conflicts in Brijesh> increasingly large and complex networks. This is sophistry. You could argue against any VPN scheme whatsoever by pointing out that it creates some administrative burden, when compared with not having any VPN scheme at all. That's not very interesting, it's only interesting to compare two VPN schemes, for instance RFC2547 vs. configuring, managing, and maintaining hundreds of thousands of point-to-point tunnels. From owner-mpls@UU.NET Wed Sep 6 13:36:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18837 for ; Wed, 6 Sep 2000 13:36:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfms22841; Wed, 6 Sep 2000 17:36:33 GMT Received: by mail-control.mail.uu.net id QQjfms27956 for mpls-outgoing; Wed, 6 Sep 2000 17:36:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfms27930 for ; Wed, 6 Sep 2000 17:35:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfms12514 for ; Wed, 6 Sep 2000 13:35:32 -0400 (EDT) Received: from postal.adn.alcatel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [143.209.80.56]) id QQjfms22004 for ; Wed, 6 Sep 2000 17:35:31 GMT Received: from adn.alcatel.com ([143.209.82.130]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA3919; Wed, 6 Sep 2000 13:44:29 -0400 Message-ID: <39B68101.E613C7DE@adn.alcatel.com> Date: Wed, 06 Sep 2000 13:38:09 -0400 From: Sitarama R Kalipatnapu X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On the note of scalability of BGP/MPLS VPNs, adding more hardware seems to do the trick. But on a close observation it appears, BGP is the choke point. BGP running in the provider edge seems to peer with the customer edges and also distribute MPLS labels across PE edges. The questions are: 1. Do we have alternate solutions to provide MPLS VPNs without BGP ? 2. If so are they effective ? 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) in the BGP/MPLS VPNs model ? Thank You. --Sitaram Eric Rosen wrote: > Brijesh> I think you are probably right. It seems that the model in RFC 2547 > Brijesh> may be flawed because it fails to separate internal VPN control and > Brijesh> configuration within a domain from the routing control plane > Brijesh> primarily designed for carrying external inter-domain transit > Brijesh> traffic. > > No it doesn't. It does use BGP for both purposes though. The fact that > technology which is primarily designed for one application is also used for > a second application is not generally considered to be a bad thing. > > Brijesh> adding VPN related policies (basically, internal traffic of a > Brijesh> domain) to something that was originally designed to provide policy > Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. > > The "VPN-related policies" are primarily expressed as filtering on community > attributes, which is actually fits in quite well with normal BGP functions. > > Brijesh> Besides the scalability problems you mentioned, > > The only scalability problem Randy mentioned is that as you get more > customers, you might have to add more equipment. I'd like to see the scheme > in which the hardware cost is independent of the load! > > Brijesh> It is not going to help busy network administrators who need to > Brijesh> manage large number of BGP nodes, and resolve policy conflicts in > Brijesh> increasingly large and complex networks. > > This is sophistry. You could argue against any VPN scheme whatsoever by > pointing out that it creates some administrative burden, when compared with > not having any VPN scheme at all. That's not very interesting, it's only > interesting to compare two VPN schemes, for instance RFC2547 > vs. configuring, managing, and maintaining hundreds of thousands of > point-to-point tunnels. From owner-mpls@UU.NET Wed Sep 6 13:55:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19234 for ; Wed, 6 Sep 2000 13:55:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmt21383; Wed, 6 Sep 2000 17:55:00 GMT Received: by mail-control.mail.uu.net id QQjfmt29151 for mpls-outgoing; Wed, 6 Sep 2000 17:54:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfmt29146 for ; Wed, 6 Sep 2000 17:54:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfmt24499 for ; Wed, 6 Sep 2000 13:54:30 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfmt06844 for ; Wed, 6 Sep 2000 17:54:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA29028 for mpls@uu.net; Wed, 6 Sep 2000 13:54:29 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfmt29132 for ; Wed, 6 Sep 2000 17:53:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfmt24360 for ; Wed, 6 Sep 2000 13:53:42 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjfmt20521 for ; Wed, 6 Sep 2000 17:53:41 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA06701; Wed, 6 Sep 2000 10:54:01 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA11130; Wed, 6 Sep 2000 10:53:43 -0700 (PDT) Message-ID: <39B6855A.31C9BD86@cisco.com> Date: Wed, 06 Sep 2000 10:56:42 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sitarama R Kalipatnapu CC: erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sitarama, BGP is not a choke point. First it is already there in all edge routers in all ISPs I know of and adding the new AF to it does not cause it to choke in the right implementation. Notice that the "choking" effect all depends how one sets the timers (per AF of course - so it does not effect plain IPV4 updates or other bgp IPV4 mechanisms). As a contary to what you are saying many customers are setting the VPNv4 timers more aggresively then ipv4 timers to allow equal to IGP convergence and even that is not causing bgp to "choke" in a production networks. The scalability of MPLS-VPNs is achived by the fact that BGP is being used as a tool there so it would be a mistake to even attempt it's replacement by some other means. R. > On the note of scalability of BGP/MPLS VPNs, adding more hardware > seems to do the trick. But on a close observation it appears, BGP is the > choke point. BGP running in the provider edge seems to peer with the > customer edges and also distribute MPLS labels across PE edges. The > questions are: > > 1. Do we have alternate solutions to provide MPLS VPNs without BGP ? > 2. If so are they effective ? > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > in the BGP/MPLS VPNs model ? > > Thank You. > > --Sitaram > > Eric Rosen wrote: > > > Brijesh> I think you are probably right. It seems that the model in RFC 2547 > > Brijesh> may be flawed because it fails to separate internal VPN control and > > Brijesh> configuration within a domain from the routing control plane > > Brijesh> primarily designed for carrying external inter-domain transit > > Brijesh> traffic. > > > > No it doesn't. It does use BGP for both purposes though. The fact that > > technology which is primarily designed for one application is also used for > > a second application is not generally considered to be a bad thing. > > > > Brijesh> adding VPN related policies (basically, internal traffic of a > > Brijesh> domain) to something that was originally designed to provide policy > > Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. > > > > The "VPN-related policies" are primarily expressed as filtering on community > > attributes, which is actually fits in quite well with normal BGP functions. > > > > Brijesh> Besides the scalability problems you mentioned, > > > > The only scalability problem Randy mentioned is that as you get more > > customers, you might have to add more equipment. I'd like to see the scheme > > in which the hardware cost is independent of the load! > > > > Brijesh> It is not going to help busy network administrators who need to > > Brijesh> manage large number of BGP nodes, and resolve policy conflicts in > > Brijesh> increasingly large and complex networks. > > > > This is sophistry. You could argue against any VPN scheme whatsoever by > > pointing out that it creates some administrative burden, when compared with > > not having any VPN scheme at all. That's not very interesting, it's only > > interesting to compare two VPN schemes, for instance RFC2547 > > vs. configuring, managing, and maintaining hundreds of thousands of > > point-to-point tunnels. From owner-mpls@UU.NET Wed Sep 6 14:50:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20647 for ; Wed, 6 Sep 2000 14:50:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmx21652; Wed, 6 Sep 2000 18:50:33 GMT Received: by mail-control.mail.uu.net id QQjfmx14549 for mpls-outgoing; Wed, 6 Sep 2000 18:50:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfmx14544 for ; Wed, 6 Sep 2000 18:50:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfmx05107 for ; Wed, 6 Sep 2000 14:49:44 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjfmx02882 for ; Wed, 6 Sep 2000 18:49:44 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e86Ingn09100; Wed, 6 Sep 2000 14:49:42 -0400 (EDT) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id OAA47759; Wed, 6 Sep 2000 14:50:09 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200009061850.OAA47759@curtis-lt.avici.com> To: neil.2.harrison@bt.com cc: curtis@avici.com, raszuk@cisco.com, Raffaele.Dalbenzio@CSELT.IT, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Info about mpls-vpn In-reply-to: Your message of "Tue, 05 Sep 2000 15:48:58 BST." Date: Wed, 06 Sep 2000 14:50:09 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , nei l.2.harrison@bt.com writes: > Hi Curtis, it would also be nice to know (esp for operators) the pros/cons > of using various nested LDP-types. For example, in theory it seems I could > run put BGP4 label-ditsributed LSPs (say for VPN constructs) over a server > layer of vanilla-LDP distributed LSPs or RSVP-LDP distributed LSPs. I could > also think of other nested LDP-type combinations. But a key question for me > here is 'What is their dynamic behaviour under all types of fault > condition'? I still have not got my head around this one, and I sure some > modes of operation would be better than others. If anyone else has pondered > on this and come to any views I would be grateful to hear them. > > Regards, Neil Neil, Without going into any detail, I'll just make one point by way of example. Consider a 50 node core and 1,000 nodes around the perimeter and what would happen if a link in the core failed. Without tunnels within tunnels there is the potential to have to lay out 1,000s of the 1,000,000 LSP required for a full TE mesh. If the edge-to-edge tunnels ride inside aggregate tunnels within the core, then a much smaller number of the 2,500 tunnels in the core need to be rerouted. If you are running BGP/VPN inside LDP, the same improvement would apply to LDP or LDP inside aggregate TE tunnels. Recovering a smaller number of TE tunnels should be easier than recovering a much larger number of LDP label mappings. A subtle point is that if doing DU with LDP it would also help to avoid advertising any LDP learned label mapping back out another LDP/TE under the assumption that the TE nodes are logically full meshed and that advertisement is redundant. If you look at the scaling issues of the overall problem and at the fault recovery problem dropping LDP entirely and doing TE tunnels inside TE across areas has advantages over LDP alone or LDP inside TE. This would make for some interesting simulation projects. Regards, Curtis From owner-mpls@UU.NET Wed Sep 6 15:03:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20858 for ; Wed, 6 Sep 2000 15:03:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmy02823; Wed, 6 Sep 2000 19:03:14 GMT Received: by mail-control.mail.uu.net id QQjfmy22126 for mpls-outgoing; Wed, 6 Sep 2000 19:02:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfmy22071 for ; Wed, 6 Sep 2000 19:02:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfmy00347 for ; Wed, 6 Sep 2000 15:02:27 -0400 (EDT) Received: from devmail.dev.tivoli.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136]) id QQjfmy12672 for ; Wed, 6 Sep 2000 19:02:12 GMT Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id OAA22656 for ; Wed, 6 Sep 2000 14:02:11 -0500 (CDT) Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70]) by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id PAA24959 for ; Wed, 6 Sep 2000 15:04:32 -0400 (EDT) From: "Paul Tasillo" To: "mpls@UU. net" Subject: MPLS Mibs in production code Date: Wed, 6 Sep 2000 15:01:59 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Aside from Cisco, are there any other vendors that have support for any of the MPLS MIBs in production (ie. publically available today)? Thanks in advance, Paul From owner-mpls@UU.NET Wed Sep 6 15:09:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20912 for ; Wed, 6 Sep 2000 15:09:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmy18451; Wed, 6 Sep 2000 19:09:23 GMT Received: by mail-control.mail.uu.net id QQjfmy27737 for mpls-outgoing; Wed, 6 Sep 2000 19:08:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfmy27703 for ; Wed, 6 Sep 2000 19:08:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfmy01592; Wed, 6 Sep 2000 15:08:28 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjfmy06776; Wed, 6 Sep 2000 19:07:57 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e86J7un11141; Wed, 6 Sep 2000 15:07:56 -0400 (EDT) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id PAA47826; Wed, 6 Sep 2000 15:08:28 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200009061908.PAA47826@curtis-lt.avici.com> To: Florian-Daniel Otel cc: mpls@UU.NET, te-wg@UU.NET Reply-To: curtis@avici.com Subject: Re: Incremental MPLS (BCP document lookup) In-reply-to: Your message of "Tue, 05 Sep 2000 13:53:57 +0200." <14772.57045.342364.820985@blomman13.ce.chalmers.se> Date: Wed, 06 Sep 2000 15:08:28 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <14772.57045.342364.820985@blomman13.ce.chalmers.se>, Florian-Daniel Otel writes: > > > Dear all, > > > I am looking for a case study document/white paper focused > on/describing the possible means (maybe even claimed advantages ?) of > introducing MPLS in a _incremental_ manner in a core network. > > TIA, > > Florian Try the NANOG meeting archives. Allan Hannan (of Global Crossings at the time) gave a presentation where he described this transition. Briefly: 1. Initially leave IGP metrics alone. 2. Bring up a full set of zero bandwidth LSPs. They will follow the IGP metrics. These are used just to collect traffic measurements. 3. Measure the traffic on each LSP for a week or more. 4. Start configuring bandwidth parameters on the LSP and they will start to do some traffic engineering for you and should yield some relief from congestion if your network had any. 5. Continue to measure and periodically update the bandwidth parameters based on the measured utilization. 6. Optionally tweak the metrics if needed (should not be). I think Allan provided slides that gave a bit more detail. Curtis From owner-mpls@UU.NET Wed Sep 6 15:10:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20942 for ; Wed, 6 Sep 2000 15:10:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmy08804; Wed, 6 Sep 2000 19:10:04 GMT Received: by mail-control.mail.uu.net id QQjfmy27840 for mpls-outgoing; Wed, 6 Sep 2000 19:09:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfmy27811 for ; Wed, 6 Sep 2000 19:09:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfmy09240 for ; Wed, 6 Sep 2000 15:09:13 -0400 (EDT) Received: from portcullis.ral.virata.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.rsacom.com [208.209.94.122]) id QQjfmy07987 for ; Wed, 6 Sep 2000 19:09:13 GMT Received: from mango.ral.virata.com (mango.ral.virata.com [172.16.1.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id GAA18869; Wed, 6 Sep 2000 06:35:03 -0400 Received: from cowboy.ral.virata.com (cowboy.ral.virata.com [192.168.1.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA21000; Wed, 6 Sep 2000 15:09:12 -0400 Received: by COWBOY with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Sep 2000 15:11:55 -0400 Message-ID: <2B31A87FDF5DD411A74200508BD94E4902CFFA@COWBOY> From: "Achkinazi, Igor" To: Paul Tasillo , "mpls@UU. net" Subject: RE: MPLS Mibs in production code Date: Wed, 6 Sep 2000 15:11:54 -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 Hi, Paul Virata has support for LDP and LSR MIBs right now and packet classification and MPLS TE MIBs until end of the year. Igor Achkinazi -----Original Message----- From: Paul Tasillo [mailto:Paul.tasillo@tivoli.com] Sent: Wednesday, September 06, 2000 3:02 PM To: mpls@UU. net Subject: MPLS Mibs in production code Aside from Cisco, are there any other vendors that have support for any of the MPLS MIBs in production (ie. publically available today)? Thanks in advance, Paul From owner-mpls@UU.NET Wed Sep 6 15:22:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21143 for ; Wed, 6 Sep 2000 15:22:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfmz19666; Wed, 6 Sep 2000 19:22:53 GMT Received: by mail-control.mail.uu.net id QQjfmz29417 for mpls-outgoing; Wed, 6 Sep 2000 19:22:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfmz29409 for ; Wed, 6 Sep 2000 19:22:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfmz11793 for ; Wed, 6 Sep 2000 15:22:04 -0400 (EDT) Received: from postal.adn.alcatel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [143.209.80.56]) id QQjfmz18813 for ; Wed, 6 Sep 2000 19:21:48 GMT Received: from adn.alcatel.com ([143.209.82.130]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA46AA; Wed, 6 Sep 2000 15:30:04 -0400 Message-ID: <39B699C0.630AF10E@adn.alcatel.com> Date: Wed, 06 Sep 2000 15:23:44 -0400 From: Sitarama R Kalipatnapu X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com CC: erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert, Let me rephrase my question regarding scalability. 1. When do you decide to add another PE router, as the number of VPNs supported is increasing ? 2. What makes us add a second PE router ? 3. Is this connected to BGP ? Thanks, --Sitaram Robert Raszuk wrote: > Sitarama, > > BGP is not a choke point. First it is already there in all edge routers > in all ISPs I know of and adding the new AF to it does not cause it to > choke in the right implementation. Notice that the "choking" effect all > depends how one sets the timers (per AF of course - so it does not > effect plain IPV4 updates or other bgp IPV4 mechanisms). As a contary to > what you are saying many customers are setting the VPNv4 timers more > aggresively then ipv4 timers to allow equal to IGP convergence and even > that is not causing bgp to "choke" in a production networks. > > The scalability of MPLS-VPNs is achived by the fact that BGP is being > used as a tool there so it would be a mistake to even attempt it's > replacement by some other means. > > R. > > > On the note of scalability of BGP/MPLS VPNs, adding more hardware > > seems to do the trick. But on a close observation it appears, BGP is the > > choke point. BGP running in the provider edge seems to peer with the > > customer edges and also distribute MPLS labels across PE edges. The > > questions are: > > > > 1. Do we have alternate solutions to provide MPLS VPNs without BGP ? > > 2. If so are they effective ? > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > in the BGP/MPLS VPNs model ? > > > > Thank You. > > > > --Sitaram > > > > Eric Rosen wrote: > > > > > Brijesh> I think you are probably right. It seems that the model in RFC 2547 > > > Brijesh> may be flawed because it fails to separate internal VPN control and > > > Brijesh> configuration within a domain from the routing control plane > > > Brijesh> primarily designed for carrying external inter-domain transit > > > Brijesh> traffic. > > > > > > No it doesn't. It does use BGP for both purposes though. The fact that > > > technology which is primarily designed for one application is also used for > > > a second application is not generally considered to be a bad thing. > > > > > > Brijesh> adding VPN related policies (basically, internal traffic of a > > > Brijesh> domain) to something that was originally designed to provide policy > > > Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. > > > > > > The "VPN-related policies" are primarily expressed as filtering on community > > > attributes, which is actually fits in quite well with normal BGP functions. > > > > > > Brijesh> Besides the scalability problems you mentioned, > > > > > > The only scalability problem Randy mentioned is that as you get more > > > customers, you might have to add more equipment. I'd like to see the scheme > > > in which the hardware cost is independent of the load! > > > > > > Brijesh> It is not going to help busy network administrators who need to > > > Brijesh> manage large number of BGP nodes, and resolve policy conflicts in > > > Brijesh> increasingly large and complex networks. > > > > > > This is sophistry. You could argue against any VPN scheme whatsoever by > > > pointing out that it creates some administrative burden, when compared with > > > not having any VPN scheme at all. That's not very interesting, it's only > > > interesting to compare two VPN schemes, for instance RFC2547 > > > vs. configuring, managing, and maintaining hundreds of thousands of > > > point-to-point tunnels. From owner-mpls@UU.NET Wed Sep 6 15:32:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21382 for ; Wed, 6 Sep 2000 15:32:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfna27542; Wed, 6 Sep 2000 19:32:28 GMT Received: by mail-control.mail.uu.net id QQjfna00138 for mpls-outgoing; Wed, 6 Sep 2000 19:32:04 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfna00132 for ; Wed, 6 Sep 2000 19:32:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfna06621 for ; Wed, 6 Sep 2000 15:31:47 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfna26696 for ; Wed, 6 Sep 2000 19:31:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA15812 for mpls@uu.net; Wed, 6 Sep 2000 15:31:31 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfna29993 for ; Wed, 6 Sep 2000 19:30:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfna13655 for ; Wed, 6 Sep 2000 15:30:45 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjfna26055 for ; Wed, 6 Sep 2000 19:30:45 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Sep 2000 15:25:50 -0400 Message-ID: <7BF58A904536D411ADD400508BC97B85046BE3@xover1.netplane.com> From: "Kullberg, Alan" To: "'Paul Tasillo'" , "mpls@UU. net" Subject: RE: MPLS Mibs in production code Date: Wed, 6 Sep 2000 15:25:49 -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 NetPlane supports the LDP MIB in the current shipping version of our MPLS software. We will support the TE and LSR MIBs at the end of September. Alan > -----Original Message----- > From: Paul Tasillo [mailto:Paul.tasillo@tivoli.com] > Sent: Wednesday, September 06, 2000 3:02 PM > To: mpls@UU. net > Subject: MPLS Mibs in production code > > > Aside from Cisco, are there any other vendors that have > support for any of > the MPLS MIBs in production (ie. publically available today)? > > Thanks in advance, > Paul > > From owner-mpls@UU.NET Wed Sep 6 15:36:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21461 for ; Wed, 6 Sep 2000 15:36:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfna10921; Wed, 6 Sep 2000 19:36:04 GMT Received: by mail-control.mail.uu.net id QQjfna00280 for mpls-outgoing; Wed, 6 Sep 2000 19:35:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfna00275 for ; Wed, 6 Sep 2000 19:35:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfna14629 for ; Wed, 6 Sep 2000 15:35:06 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfna29491 for ; Wed, 6 Sep 2000 19:34:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA16680 for mpls@uu.net; Wed, 6 Sep 2000 15:34:50 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfna00234 for ; Wed, 6 Sep 2000 19:34:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfna14434 for ; Wed, 6 Sep 2000 15:34:13 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfna28914 for ; Wed, 6 Sep 2000 19:33:58 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA27757; Wed, 6 Sep 2000 12:34:13 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA11180; Wed, 6 Sep 2000 12:33:56 -0700 (PDT) Message-ID: <39B69CD7.74FCFA14@cisco.com> Date: Wed, 06 Sep 2000 12:36:55 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sitarama R Kalipatnapu CC: erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sitarama, > 1. When do you decide to add another PE router, as the number of > VPNs supported is increasing ? Let me say once again that number of VPNs does not trigger addition of another PE. Why ? Simply because the overhead of vrf is memory consumption wise not significant. What does matter is the number of routes your VPNs give you as you need to store them in the vpnv4 bgp table as well in RIBs & FIBs for given vrfs. So it really depends on the operator's comfort with a given router to run at X% of memory utlization. Notice that in moders routers the memory limit and upgrade flexibility is growing so even that may not be a very significant factor. The same applies to CPU. > 2. What makes us add a second PE router ? See above. > 3. Is this connected to BGP ? No. In a peering VPN model you need to maintain customer routes. What ever protocol you would use you will still have a potential of hitting the hardware limitations at some point and bgp is quite ortogonal to this. Just one more comment on your last question: > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > in the BGP/MPLS VPNs model ? Using bgp to carry labels for vpn routes is totally not an issue as it just extending the NLRI size by 20 bits without any processing penalty. BGP is more or less just a vehicle here. R. > > Thanks, > > --Sitaram > > Robert Raszuk wrote: > > > Sitarama, > > > > BGP is not a choke point. First it is already there in all edge routers > > in all ISPs I know of and adding the new AF to it does not cause it to > > choke in the right implementation. Notice that the "choking" effect all > > depends how one sets the timers (per AF of course - so it does not > > effect plain IPV4 updates or other bgp IPV4 mechanisms). As a contary to > > what you are saying many customers are setting the VPNv4 timers more > > aggresively then ipv4 timers to allow equal to IGP convergence and even > > that is not causing bgp to "choke" in a production networks. > > > > The scalability of MPLS-VPNs is achived by the fact that BGP is being > > used as a tool there so it would be a mistake to even attempt it's > > replacement by some other means. > > > > R. > > > > > On the note of scalability of BGP/MPLS VPNs, adding more hardware > > > seems to do the trick. But on a close observation it appears, BGP is the > > > choke point. BGP running in the provider edge seems to peer with the > > > customer edges and also distribute MPLS labels across PE edges. The > > > questions are: > > > > > > 1. Do we have alternate solutions to provide MPLS VPNs without BGP ? > > > 2. If so are they effective ? > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > in the BGP/MPLS VPNs model ? > > > > > > Thank You. > > > > > > --Sitaram > > > > > > Eric Rosen wrote: > > > > > > > Brijesh> I think you are probably right. It seems that the model in RFC 2547 > > > > Brijesh> may be flawed because it fails to separate internal VPN control and > > > > Brijesh> configuration within a domain from the routing control plane > > > > Brijesh> primarily designed for carrying external inter-domain transit > > > > Brijesh> traffic. > > > > > > > > No it doesn't. It does use BGP for both purposes though. The fact that > > > > technology which is primarily designed for one application is also used for > > > > a second application is not generally considered to be a bad thing. > > > > > > > > Brijesh> adding VPN related policies (basically, internal traffic of a > > > > Brijesh> domain) to something that was originally designed to provide policy > > > > Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. > > > > > > > > The "VPN-related policies" are primarily expressed as filtering on community > > > > attributes, which is actually fits in quite well with normal BGP functions. > > > > > > > > Brijesh> Besides the scalability problems you mentioned, > > > > > > > > The only scalability problem Randy mentioned is that as you get more > > > > customers, you might have to add more equipment. I'd like to see the scheme > > > > in which the hardware cost is independent of the load! > > > > > > > > Brijesh> It is not going to help busy network administrators who need to > > > > Brijesh> manage large number of BGP nodes, and resolve policy conflicts in > > > > Brijesh> increasingly large and complex networks. > > > > > > > > This is sophistry. You could argue against any VPN scheme whatsoever by > > > > pointing out that it creates some administrative burden, when compared with > > > > not having any VPN scheme at all. That's not very interesting, it's only > > > > interesting to compare two VPN schemes, for instance RFC2547 > > > > vs. configuring, managing, and maintaining hundreds of thousands of > > > > point-to-point tunnels. From owner-mpls@UU.NET Wed Sep 6 15:41:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21715 for ; Wed, 6 Sep 2000 15:41:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfna04667; Wed, 6 Sep 2000 19:41:40 GMT Received: by mail-control.mail.uu.net id QQjfna00659 for mpls-outgoing; Wed, 6 Sep 2000 19:41:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfna00646 for ; Wed, 6 Sep 2000 19:41:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfna15812 for ; Wed, 6 Sep 2000 15:41:03 -0400 (EDT) Received: from relay1.smtp.psi.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: relay1.smtp.psi.net [38.8.14.2]) id QQjfna03690 for ; Wed, 6 Sep 2000 19:40:31 GMT Received: from [204.242.142.104] (helo=am) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 13Wl3Z-0001ij-00; Wed, 6 Sep 2000 15:40:25 -0400 From: "Alex Mondrus" To: "Kullberg, Alan" , "'Paul Tasillo'" , "mpls@UU. net" Subject: RE: MPLS Mibs in production code Date: Wed, 6 Sep 2000 15:52:03 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <7BF58A904536D411ADD400508BC97B85046BE3@xover1.netplane.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit IPOptical will support both http://www.ipoptical.com Alex Mondrus -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kullberg, Alan Sent: Wednesday, September 06, 2000 3:26 PM To: 'Paul Tasillo'; mpls@UU. net Subject: RE: MPLS Mibs in production code NetPlane supports the LDP MIB in the current shipping version of our MPLS software. We will support the TE and LSR MIBs at the end of September. Alan > -----Original Message----- > From: Paul Tasillo [mailto:Paul.tasillo@tivoli.com] > Sent: Wednesday, September 06, 2000 3:02 PM > To: mpls@UU. net > Subject: MPLS Mibs in production code > > > Aside from Cisco, are there any other vendors that have > support for any of > the MPLS MIBs in production (ie. publically available today)? > > Thanks in advance, > Paul > > From owner-mpls@UU.NET Wed Sep 6 16:01:15 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22046 for ; Wed, 6 Sep 2000 16:01:15 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnc19888; Wed, 6 Sep 2000 20:01:14 GMT Received: by mail-control.mail.uu.net id QQjfnc03985 for mpls-outgoing; Wed, 6 Sep 2000 20:00:40 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfnc03862 for ; Wed, 6 Sep 2000 20:00:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnc12392 for ; Wed, 6 Sep 2000 16:00:31 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfnb18326 for ; Wed, 6 Sep 2000 19:59:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA21003 for mpls@uu.net; Wed, 6 Sep 2000 15:59:56 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfnb02467 for ; Wed, 6 Sep 2000 19:59:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfnb18944 for ; Wed, 6 Sep 2000 15:59:19 -0400 (EDT) Received: from dnsmx1pya.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQjfnb29850 for ; Wed, 6 Sep 2000 19:59:17 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id PAA13682 for ; Wed, 6 Sep 2000 15:56:23 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256952.006D8678 ; Wed, 6 Sep 2000 15:56:18 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256952.006D8603.00@notes949.cc.telcordia.com> Date: Wed, 6 Sep 2000 15:54:49 -0400 Subject: question on RSVP-TE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have questions on how to define the "Session name" in Session Attribute object, is there any reference which I can get for this one? Thanks, Julia From owner-mpls@UU.NET Wed Sep 6 16:03:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22078 for ; Wed, 6 Sep 2000 16:03:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnc21791; Wed, 6 Sep 2000 20:03:26 GMT Received: by mail-control.mail.uu.net id QQjfnc06394 for mpls-outgoing; Wed, 6 Sep 2000 20:02:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnc06346 for ; Wed, 6 Sep 2000 20:02:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnc12932 for ; Wed, 6 Sep 2000 16:02:37 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfnc21096 for ; Wed, 6 Sep 2000 20:02:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA21512 for mpls@uu.net; Wed, 6 Sep 2000 16:02:36 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnc05957 for ; Wed, 6 Sep 2000 20:02:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfnc12852 for ; Wed, 6 Sep 2000 16:02:09 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQjfnc02345 for ; Wed, 6 Sep 2000 20:02:08 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id PAA07428 for ; Wed, 6 Sep 2000 15:57:04 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256952.006D93A2 ; Wed, 6 Sep 2000 15:56:52 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256952.006D92FD.00@notes949.cc.telcordia.com> Date: Wed, 6 Sep 2000 15:55:22 -0400 Subject: subscribe Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Wed Sep 6 16:20:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22384 for ; Wed, 6 Sep 2000 16:20:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnd16254; Wed, 6 Sep 2000 20:20:03 GMT Received: by mail-control.mail.uu.net id QQjfnd16483 for mpls-outgoing; Wed, 6 Sep 2000 20:19:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfnd16472 for ; Wed, 6 Sep 2000 20:19:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnd22919 for ; Wed, 6 Sep 2000 16:19:33 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfnd03328 for ; Wed, 6 Sep 2000 20:19:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA24499 for mpls@uu.net; Wed, 6 Sep 2000 16:19:17 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfnd16435 for ; Wed, 6 Sep 2000 20:18:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnd22752 for ; Wed, 6 Sep 2000 16:18:47 -0400 (EDT) Received: from dnsmx2pya.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQjfnd02933 for ; Wed, 6 Sep 2000 20:18:47 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id QAA19079 for ; Wed, 6 Sep 2000 16:13:05 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256952.006F0CD9 ; Wed, 6 Sep 2000 16:12:57 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256952.006F0B51.00@notes949.cc.telcordia.com> Date: Wed, 6 Sep 2000 16:11:25 -0400 Subject: Question on RSVP_TE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have question on RSVP_TE: Extensiton to RSVP for LSP tunnels: 06.txt On page 41, there is a Name Length in Session Attribute Object, which says that "the length of the display string before padding, in bytes". If it is in byte, why needs any padding, and if it needs any padding, the padding is put before the "Session name" or after the "Session name". Thanks, Julia From owner-mpls@UU.NET Wed Sep 6 16:31:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22750 for ; Wed, 6 Sep 2000 16:31:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfne25245; Wed, 6 Sep 2000 20:31:24 GMT Received: by mail-control.mail.uu.net id QQjfne17622 for mpls-outgoing; Wed, 6 Sep 2000 20:31:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfne17611 for ; Wed, 6 Sep 2000 20:30:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfne25049 for ; Wed, 6 Sep 2000 16:30:43 -0400 (EDT) Received: from postal.adn.alcatel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [143.209.80.56]) id QQjfne12335 for ; Wed, 6 Sep 2000 20:30:42 GMT Received: from adn.alcatel.com ([143.209.82.130]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA4FF3; Wed, 6 Sep 2000 16:38:58 -0400 Message-ID: <39B6A9E5.1939914C@adn.alcatel.com> Date: Wed, 06 Sep 2000 16:32:37 -0400 From: Sitarama R Kalipatnapu X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com CC: erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert, I agree with your analysis. But which entity in the router is consuming the resources of the router ! That I think is VRFs, BGP RIBs and FIBs. In that sense, we may say, BGP induced chokepoint of the router. As we add more VPNs the number of VRFs in the router increases, pushing the demands on memory and CPU. In the case of BGP peering with customer edge, BGP demands on the router resources is even higher. As we rely more on BGP to do everything for the MPLS VPNs, the CPU time consumed by BGP increases. One of my earlier questions was on the 'BGP induced choke point'. > > > 3. Is it possible to unload the demands on BGP (carrying interior MPLS labels ) > > > in the BGP/MPLS VPNs model ? Can something be done about it to ease load on BGP ? Thanks. --Sitaram Robert Raszuk wrote: > Sitarama, > > > 1. When do you decide to add another PE router, as the number of > > VPNs supported is increasing ? > > Let me say once again that number of VPNs does not trigger addition of > another PE. Why ? Simply because the overhead of vrf is memory > consumption wise not significant. What does matter is the number of > routes your VPNs give you as you need to store them in the vpnv4 bgp > table as well in RIBs & FIBs for given vrfs. So it really depends on the > operator's comfort with a given router to run at X% of memory > utlization. Notice that in moders routers the memory limit and upgrade > flexibility is growing so even that may not be a very significant > factor. > > The same applies to CPU. > > > 2. What makes us add a second PE router ? > > See above. > > > 3. Is this connected to BGP ? > > No. In a peering VPN model you need to maintain customer routes. What > ever protocol you would use you will still have a potential of hitting > the hardware limitations at some point and bgp is quite ortogonal to > this. > > Just one more comment on your last question: > > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > > in the BGP/MPLS VPNs model ? > > Using bgp to carry labels for vpn routes is totally not an issue as it > just extending the NLRI size by 20 bits without any processing penalty. > BGP is more or less just a vehicle here. > > R. > > > > > Thanks, > > > > --Sitaram > > > > Robert Raszuk wrote: > > > > > Sitarama, > > > > > > BGP is not a choke point. First it is already there in all edge routers > > > in all ISPs I know of and adding the new AF to it does not cause it to > > > choke in the right implementation. Notice that the "choking" effect all > > > depends how one sets the timers (per AF of course - so it does not > > > effect plain IPV4 updates or other bgp IPV4 mechanisms). As a contary to > > > what you are saying many customers are setting the VPNv4 timers more > > > aggresively then ipv4 timers to allow equal to IGP convergence and even > > > that is not causing bgp to "choke" in a production networks. > > > > > > The scalability of MPLS-VPNs is achived by the fact that BGP is being > > > used as a tool there so it would be a mistake to even attempt it's > > > replacement by some other means. > > > > > > R. > > > > > > > On the note of scalability of BGP/MPLS VPNs, adding more hardware > > > > seems to do the trick. But on a close observation it appears, BGP is the > > > > choke point. BGP running in the provider edge seems to peer with the > > > > customer edges and also distribute MPLS labels across PE edges. The > > > > questions are: > > > > > > > > 1. Do we have alternate solutions to provide MPLS VPNs without BGP ? > > > > 2. If so are they effective ? > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > > in the BGP/MPLS VPNs model ? > > > > > > > > Thank You. > > > > > > > > --Sitaram > > > > > > > > Eric Rosen wrote: > > > > > > > > > Brijesh> I think you are probably right. It seems that the model in RFC 2547 > > > > > Brijesh> may be flawed because it fails to separate internal VPN control and > > > > > Brijesh> configuration within a domain from the routing control plane > > > > > Brijesh> primarily designed for carrying external inter-domain transit > > > > > Brijesh> traffic. > > > > > > > > > > No it doesn't. It does use BGP for both purposes though. The fact that > > > > > technology which is primarily designed for one application is also used for > > > > > a second application is not generally considered to be a bad thing. > > > > > > > > > > Brijesh> adding VPN related policies (basically, internal traffic of a > > > > > Brijesh> domain) to something that was originally designed to provide policy > > > > > Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. > > > > > > > > > > The "VPN-related policies" are primarily expressed as filtering on community > > > > > attributes, which is actually fits in quite well with normal BGP functions. > > > > > > > > > > Brijesh> Besides the scalability problems you mentioned, > > > > > > > > > > The only scalability problem Randy mentioned is that as you get more > > > > > customers, you might have to add more equipment. I'd like to see the scheme > > > > > in which the hardware cost is independent of the load! > > > > > > > > > > Brijesh> It is not going to help busy network administrators who need to > > > > > Brijesh> manage large number of BGP nodes, and resolve policy conflicts in > > > > > Brijesh> increasingly large and complex networks. > > > > > > > > > > This is sophistry. You could argue against any VPN scheme whatsoever by > > > > > pointing out that it creates some administrative burden, when compared with > > > > > not having any VPN scheme at all. That's not very interesting, it's only > > > > > interesting to compare two VPN schemes, for instance RFC2547 > > > > > vs. configuring, managing, and maintaining hundreds of thousands of > > > > > point-to-point tunnels. From owner-mpls@UU.NET Wed Sep 6 16:50:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23013 for ; Wed, 6 Sep 2000 16:50:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnf09414; Wed, 6 Sep 2000 20:50:38 GMT Received: by mail-control.mail.uu.net id QQjfnf19732 for mpls-outgoing; Wed, 6 Sep 2000 20:50:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnf19724 for ; Wed, 6 Sep 2000 20:50:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnf22296 for ; Wed, 6 Sep 2000 16:49:57 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfnf27592 for ; Wed, 6 Sep 2000 20:49:57 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA04684 for ; Wed, 6 Sep 2000 13:50:15 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA26670 for mpls@uu.net; Wed, 6 Sep 2000 16:49:55 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnf19299 for ; Wed, 6 Sep 2000 20:45:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfnf21267 for ; Wed, 6 Sep 2000 16:45:37 -0400 (EDT) Received: from nsa-mail.us.newbridge.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [209.58.11.226]) id QQjfnf05495 for ; Wed, 6 Sep 2000 20:45:36 GMT Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id QAA01683 for ; Wed, 6 Sep 2000 16:37:24 -0400 (EDT) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "herndon-mh1.us.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdBAAa000QA; Wed Sep 6 16:37:18 2000 Received: from nsamail01.us.newbridge.com by herndon-mh1.us.newbridge.com with ESMTP for mpls@UU.NET; Wed, 6 Sep 2000 16:45:04 -0400 Received: from alcatel.com ([138.120.241.67]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA1FBA; Wed, 6 Sep 2000 16:45:02 -0400 Message-Id: <39B6B04F.9A6747F8@alcatel.com> Date: Wed, 06 Sep 2000 16:59:59 -0400 From: "Ramana V Gollamudi" Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com CC: Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In comparison with a "real" private network (say made up of leased lines) one would expect the route scaling to be addressed by using route aggregration (for example at OSPF Area border routers if one is using OSPF within the private network). How is this type of aggregration done in mpls/bgp VPNs? Am I correct in assuming that this one of the scaling issues? And how is this to be solved? Regards, Ramana Robert Raszuk wrote: > Sitarama, > > > 1. When do you decide to add another PE router, as the number of > > VPNs supported is increasing ? > > Let me say once again that number of VPNs does not trigger addition of > another PE. Why ? Simply because the overhead of vrf is memory > consumption wise not significant. What does matter is the number of > routes your VPNs give you as you need to store them in the vpnv4 bgp > table as well in RIBs & FIBs for given vrfs. So it really depends on the > operator's comfort with a given router to run at X% of memory > utlization. Notice that in moders routers the memory limit and upgrade > flexibility is growing so even that may not be a very significant > factor. > > The same applies to CPU. > > > 2. What makes us add a second PE router ? > > See above. > > > 3. Is this connected to BGP ? > > No. In a peering VPN model you need to maintain customer routes. What > ever protocol you would use you will still have a potential of hitting > the hardware limitations at some point and bgp is quite ortogonal to > this. > > Just one more comment on your last question: > > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > > in the BGP/MPLS VPNs model ? > > Using bgp to carry labels for vpn routes is totally not an issue as it > just extending the NLRI size by 20 bits without any processing penalty. > BGP is more or less just a vehicle here. > > R. > > > > > Thanks, > > > > --Sitaram > > > > Robert Raszuk wrote: > > > > > Sitarama, > > > > > > BGP is not a choke point. First it is already there in all edge routers > > > in all ISPs I know of and adding the new AF to it does not cause it to > > > choke in the right implementation. Notice that the "choking" effect all > > > depends how one sets the timers (per AF of course - so it does not > > > effect plain IPV4 updates or other bgp IPV4 mechanisms). As a contary to > > > what you are saying many customers are setting the VPNv4 timers more > > > aggresively then ipv4 timers to allow equal to IGP convergence and even > > > that is not causing bgp to "choke" in a production networks. > > > > > > The scalability of MPLS-VPNs is achived by the fact that BGP is being > > > used as a tool there so it would be a mistake to even attempt it's > > > replacement by some other means. > > > > > > R. > > > > > > > On the note of scalability of BGP/MPLS VPNs, adding more hardware > > > > seems to do the trick. But on a close observation it appears, BGP is the > > > > choke point. BGP running in the provider edge seems to peer with the > > > > customer edges and also distribute MPLS labels across PE edges. The > > > > questions are: > > > > > > > > 1. Do we have alternate solutions to provide MPLS VPNs without BGP ? > > > > 2. If so are they effective ? > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > > in the BGP/MPLS VPNs model ? > > > > > > > > Thank You. > > > > > > > > --Sitaram > > > > > > > > Eric Rosen wrote: > > > > > > > > > Brijesh> I think you are probably right. It seems that the model in RFC 2547 > > > > > Brijesh> may be flawed because it fails to separate internal VPN control and > > > > > Brijesh> configuration within a domain from the routing control plane > > > > > Brijesh> primarily designed for carrying external inter-domain transit > > > > > Brijesh> traffic. > > > > > > > > > > No it doesn't. It does use BGP for both purposes though. The fact that > > > > > technology which is primarily designed for one application is also used for > > > > > a second application is not generally considered to be a bad thing. > > > > > > > > > > Brijesh> adding VPN related policies (basically, internal traffic of a > > > > > Brijesh> domain) to something that was originally designed to provide policy > > > > > Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. > > > > > > > > > > The "VPN-related policies" are primarily expressed as filtering on community > > > > > attributes, which is actually fits in quite well with normal BGP functions. > > > > > > > > > > Brijesh> Besides the scalability problems you mentioned, > > > > > > > > > > The only scalability problem Randy mentioned is that as you get more > > > > > customers, you might have to add more equipment. I'd like to see the scheme > > > > > in which the hardware cost is independent of the load! > > > > > > > > > > Brijesh> It is not going to help busy network administrators who need to > > > > > Brijesh> manage large number of BGP nodes, and resolve policy conflicts in > > > > > Brijesh> increasingly large and complex networks. > > > > > > > > > > This is sophistry. You could argue against any VPN scheme whatsoever by > > > > > pointing out that it creates some administrative burden, when compared with > > > > > not having any VPN scheme at all. That's not very interesting, it's only > > > > > interesting to compare two VPN schemes, for instance RFC2547 > > > > > vs. configuring, managing, and maintaining hundreds of thousands of > > > > > point-to-point tunnels. From owner-mpls@UU.NET Wed Sep 6 17:03:40 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23260 for ; Wed, 6 Sep 2000 17:03:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfng09150; Wed, 6 Sep 2000 21:03:39 GMT Received: by mail-control.mail.uu.net id QQjfng27663 for mpls-outgoing; Wed, 6 Sep 2000 21:03:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfng27630 for ; Wed, 6 Sep 2000 21:03:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfng25174 for ; Wed, 6 Sep 2000 17:03:06 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35]) id QQjfng18459 for ; Wed, 6 Sep 2000 21:02:36 GMT Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Wed, 6 Sep 2000 17:01:49 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id SM3LVW73; Wed, 6 Sep 2000 14:01:45 -0700 Received: from nortelnetworks.com (lead.engeast.baynetworks.com [192.32.148.52]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id SHHJ1Y3F; Wed, 6 Sep 2000 17:00:55 -0400 Message-ID: <39B6B088.85E3A488@nortelnetworks.com> Date: Wed, 06 Sep 2000 17:00:56 -0400 From: "Rajesh Saluja" X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ramana V Gollamudi CC: raszuk@cisco.com, Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6B04F.9A6747F8@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ramana V Gollamudi wrote: > In comparison with a "real" private network (say made up of leased lines) one would > expect the route scaling to be addressed by using route aggregration (for example at > OSPF Area border routers if one is using OSPF within the private network). How is this > type of aggregration done in mpls/bgp VPNs? Am I correct in assuming that this one of > the scaling issues? And how is this to be solved? > > Regards, > > Ramana BGP can advertise aggregated routes from a VRF. This is not an issue with MPLS/BGP VPNs. ( the only issue in this case may be double lookup while receiving packets from the core ) The scaling issue may be with : - BGP managing a bigger RIB - BGP maintaining thousands of EBGP peers ( if BGP is run between CE and PE ) Regards, Rajesh From owner-mpls@UU.NET Wed Sep 6 17:33:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23660 for ; Wed, 6 Sep 2000 17:33:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfni10976; Wed, 6 Sep 2000 21:33:06 GMT Received: by mail-control.mail.uu.net id QQjfni06181 for mpls-outgoing; Wed, 6 Sep 2000 21:32:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfni06154 for ; Wed, 6 Sep 2000 21:32:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfni06076 for ; Wed, 6 Sep 2000 17:32:34 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfni00450 for ; Wed, 6 Sep 2000 21:32:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA05804 for mpls@uu.net; Wed, 6 Sep 2000 17:32:17 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfni06052 for ; Wed, 6 Sep 2000 21:31:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfni00690 for ; Wed, 6 Sep 2000 17:31:42 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfni00074 for ; Wed, 6 Sep 2000 21:31:41 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA05739; Wed, 6 Sep 2000 17:31:40 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA00328; Wed, 6 Sep 2000 17:31:40 -0400 (EDT) Message-Id: <200009062131.RAA00328@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Hong Liao" cc: mpls@UU.NET, swallow@cisco.com Subject: Re: question on RSVP-TE In-reply-to: Your message of "Wed, 06 Sep 2000 15:54:49 EDT." <85256952.006D8603.00@notes949.cc.telcordia.com> Date: Wed, 06 Sep 2000 17:31:40 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Julia - > I have questions on how to define the "Session name" in Session Attribute > object, is there any reference which I can get for this one? This is just a text string that can be used by net management. By carrying it along in the signalling the same name is used at all nodes along the tunnel. This makes it easier for operators to pick out a particular tunnel of interest, ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Sep 6 17:39:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23743 for ; Wed, 6 Sep 2000 17:39:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfni16136; Wed, 6 Sep 2000 21:39:39 GMT Received: by mail-control.mail.uu.net id QQjfni06586 for mpls-outgoing; Wed, 6 Sep 2000 21:39:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfni06581 for ; Wed, 6 Sep 2000 21:39:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfni01751 for ; Wed, 6 Sep 2000 17:38:58 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfni04895 for ; Wed, 6 Sep 2000 21:38:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA07012 for mpls@uu.net; Wed, 6 Sep 2000 17:38:56 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfni06564 for ; Wed, 6 Sep 2000 21:38:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfni01648 for ; Wed, 6 Sep 2000 17:38:22 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjfni15003 for ; Wed, 6 Sep 2000 21:38:22 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA02076; Wed, 6 Sep 2000 17:38:21 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA08542; Wed, 6 Sep 2000 17:38:21 -0400 (EDT) Message-Id: <200009062138.RAA08542@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Hong Liao" cc: mpls@UU.NET, swallow@cisco.com Subject: Re: Question on RSVP_TE In-reply-to: Your message of "Wed, 06 Sep 2000 16:11:25 EDT." <85256952.006F0B51.00@notes949.cc.telcordia.com> Date: Wed, 06 Sep 2000 17:38:21 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Julia - > On page 41, there is a Name Length in Session Attribute Object, which says that > "the length of the display string before padding, in bytes". If it is in byte, > why needs any padding, and if it needs any padding, the padding is put before > the "Session name" or after the "Session name". RSVP objects are always a multiple of 4. The name sits in the final bytes of the object with the length delimited by the object length. But if the session name is not a multiple of 4 bytes you get some core residue at the end. The Name Length allows you to pick out just the name. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Sep 6 18:18:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24107 for ; Wed, 6 Sep 2000 18:18:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnl02089; Wed, 6 Sep 2000 22:18:40 GMT Received: by mail-control.mail.uu.net id QQjfnl21126 for mpls-outgoing; Wed, 6 Sep 2000 22:18:20 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfnl21119 for ; Wed, 6 Sep 2000 22:18:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfnl08347 for ; Wed, 6 Sep 2000 18:18:03 -0400 (EDT) Received: from dnsmx2pya.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQjfnl14404 for ; Wed, 6 Sep 2000 22:17:33 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id SAA06786; Wed, 6 Sep 2000 18:09:00 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256952.0079AB4F ; Wed, 6 Sep 2000 18:08:57 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: George Swallow cc: "Hong Liao" , mpls@UU.NET Message-ID: <85256952.0079AAC3.00@notes949.cc.telcordia.com> Date: Wed, 6 Sep 2000 18:07:27 -0400 Subject: Re: question on RSVP-TE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk George, >This is just a text string that can be used by net management. By >carrying it along in the signalling the same name is used at all nodes >along the tunnel. This makes it easier for operators to pick out a >particular tunnel of interest, 1) For the "Session name" in Session Attribute object, does it mean any given Session name for the session created along the tunnel? 2) So for the padding, you mean basically it should be at least 4, or multiple of 4 bytes. Then my question is that the padding should be put before or after the Session name? For my understanding, it should be put padding after. Thanks for your time. Julia George Swallow on 09/06/2000 05:31:40 PM To: "Hong Liao" cc: mpls@UU.NET, swallow@cisco.com (bcc: Hong Liao/Telcordia) Subject: Re: question on RSVP-TE Julia - > I have questions on how to define the "Session name" in Session Attribute > object, is there any reference which I can get for this one? This is just a text string that can be used by net management. By carrying it along in the signalling the same name is used at all nodes along the tunnel. This makes it easier for operators to pick out a particular tunnel of interest, ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Sep 6 18:34:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24311 for ; Wed, 6 Sep 2000 18:34:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnm26097; Wed, 6 Sep 2000 22:34:18 GMT Received: by mail-control.mail.uu.net id QQjfnm22119 for mpls-outgoing; Wed, 6 Sep 2000 22:33:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfnm22111 for ; Wed, 6 Sep 2000 22:33:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnm16141 for ; Wed, 6 Sep 2000 18:33:44 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfnm12525 for ; Wed, 6 Sep 2000 22:33:04 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA13154 for mpls@uu.net; Wed, 6 Sep 2000 18:33:03 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnm22066 for ; Wed, 6 Sep 2000 22:32:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnm10534 for ; Wed, 6 Sep 2000 18:32:15 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfnm11829 for ; Wed, 6 Sep 2000 22:31:59 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA01271; Wed, 6 Sep 2000 15:32:18 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA11211; Wed, 6 Sep 2000 15:32:01 -0700 (PDT) Message-ID: <39B6C692.A70F883D@cisco.com> Date: Wed, 06 Sep 2000 15:34:58 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ramana V Gollamudi CC: Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6B04F.9A6747F8@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ramana, > In comparison with a "real" private network (say made up of leased lines) one would > expect the route scaling to be addressed by using route aggregration (for example at > OSPF Area border routers if one is using OSPF within the private network). How is this > type of aggregration done in mpls/bgp VPNs? Am I correct in assuming that this one of > the scaling issues? And how is this to be solved? If you can summarize in IGP in the leased line model you are fine the same summarization can be done on either on CE or on PE. If your addressing alows you can do either IGP summarization or BGP aggregation. So this is no issue. The issue may exist in some cases when even in the leased line model any summarization is not possible. R. > Regards, > > Ramana > > Robert Raszuk wrote: > > > Sitarama, > > > > > 1. When do you decide to add another PE router, as the number of > > > VPNs supported is increasing ? > > > > Let me say once again that number of VPNs does not trigger addition of > > another PE. Why ? Simply because the overhead of vrf is memory > > consumption wise not significant. What does matter is the number of > > routes your VPNs give you as you need to store them in the vpnv4 bgp > > table as well in RIBs & FIBs for given vrfs. So it really depends on the > > operator's comfort with a given router to run at X% of memory > > utlization. Notice that in moders routers the memory limit and upgrade > > flexibility is growing so even that may not be a very significant > > factor. > > > > The same applies to CPU. > > > > > 2. What makes us add a second PE router ? > > > > See above. > > > > > 3. Is this connected to BGP ? > > > > No. In a peering VPN model you need to maintain customer routes. What > > ever protocol you would use you will still have a potential of hitting > > the hardware limitations at some point and bgp is quite ortogonal to > > this. > > > > Just one more comment on your last question: > > > > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > > > in the BGP/MPLS VPNs model ? > > > > Using bgp to carry labels for vpn routes is totally not an issue as it > > just extending the NLRI size by 20 bits without any processing penalty. > > BGP is more or less just a vehicle here. > > > > R. > > > > > > > > Thanks, > > > > > > --Sitaram > > > > > > Robert Raszuk wrote: > > > > > > > Sitarama, > > > > > > > > BGP is not a choke point. First it is already there in all edge routers > > > > in all ISPs I know of and adding the new AF to it does not cause it to > > > > choke in the right implementation. Notice that the "choking" effect all > > > > depends how one sets the timers (per AF of course - so it does not > > > > effect plain IPV4 updates or other bgp IPV4 mechanisms). As a contary to > > > > what you are saying many customers are setting the VPNv4 timers more > > > > aggresively then ipv4 timers to allow equal to IGP convergence and even > > > > that is not causing bgp to "choke" in a production networks. > > > > > > > > The scalability of MPLS-VPNs is achived by the fact that BGP is being > > > > used as a tool there so it would be a mistake to even attempt it's > > > > replacement by some other means. > > > > > > > > R. > > > > > > > > > On the note of scalability of BGP/MPLS VPNs, adding more hardware > > > > > seems to do the trick. But on a close observation it appears, BGP is the > > > > > choke point. BGP running in the provider edge seems to peer with the > > > > > customer edges and also distribute MPLS labels across PE edges. The > > > > > questions are: > > > > > > > > > > 1. Do we have alternate solutions to provide MPLS VPNs without BGP ? > > > > > 2. If so are they effective ? > > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > > > in the BGP/MPLS VPNs model ? > > > > > > > > > > Thank You. > > > > > > > > > > --Sitaram > > > > > > > > > > Eric Rosen wrote: > > > > > > > > > > > Brijesh> I think you are probably right. It seems that the model in RFC 2547 > > > > > > Brijesh> may be flawed because it fails to separate internal VPN control and > > > > > > Brijesh> configuration within a domain from the routing control plane > > > > > > Brijesh> primarily designed for carrying external inter-domain transit > > > > > > Brijesh> traffic. > > > > > > > > > > > > No it doesn't. It does use BGP for both purposes though. The fact that > > > > > > technology which is primarily designed for one application is also used for > > > > > > a second application is not generally considered to be a bad thing. > > > > > > > > > > > > Brijesh> adding VPN related policies (basically, internal traffic of a > > > > > > Brijesh> domain) to something that was originally designed to provide policy > > > > > > Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. > > > > > > > > > > > > The "VPN-related policies" are primarily expressed as filtering on community > > > > > > attributes, which is actually fits in quite well with normal BGP functions. > > > > > > > > > > > > Brijesh> Besides the scalability problems you mentioned, > > > > > > > > > > > > The only scalability problem Randy mentioned is that as you get more > > > > > > customers, you might have to add more equipment. I'd like to see the scheme > > > > > > in which the hardware cost is independent of the load! > > > > > > > > > > > > Brijesh> It is not going to help busy network administrators who need to > > > > > > Brijesh> manage large number of BGP nodes, and resolve policy conflicts in > > > > > > Brijesh> increasingly large and complex networks. > > > > > > > > > > > > This is sophistry. You could argue against any VPN scheme whatsoever by > > > > > > pointing out that it creates some administrative burden, when compared with > > > > > > not having any VPN scheme at all. That's not very interesting, it's only > > > > > > interesting to compare two VPN schemes, for instance RFC2547 > > > > > > vs. configuring, managing, and maintaining hundreds of thousands of > > > > > > point-to-point tunnels. From owner-mpls@UU.NET Wed Sep 6 19:14:04 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24654 for ; Wed, 6 Sep 2000 19:14:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfno09676; Wed, 6 Sep 2000 23:12:36 GMT Received: by mail-control.mail.uu.net id QQjfno06252 for mpls-outgoing; Wed, 6 Sep 2000 23:12:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfno06244 for ; Wed, 6 Sep 2000 23:12:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfno21244; Wed, 6 Sep 2000 19:12:14 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQjfno19622; Wed, 6 Sep 2000 23:11:58 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16711; Wed, 6 Sep 2000 16:11:28 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id QAA07680; Wed, 6 Sep 2000 16:10:04 -0700 (PDT) Date: Wed, 6 Sep 2000 16:10:04 -0700 (PDT) From: Kireeti Kompella Message-Id: <200009062310.QAA07680@kummer.juniper.net> To: jboyle@Level3.net, mpls@UU.NET, te-wg@UU.NET Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt Sender: owner-mpls@UU.NET Precedence: bulk Hi Jim, > I believe the best thing to do is to accept kireeti's draft as a te-wg > item, as it has both running code and rough (very) consensus behind > it. I'm happy to hear that. My personal opinion: the two drafts address different (but valid) aspects of TE tunnels; having two drafts is the right thing to do, especially in view of the different tasks that each is better suited to (configuration/debugging vs. operation/maintenance). I will re-issue the draft as a TE WG draft. Kireeti. From owner-mpls@UU.NET Wed Sep 6 19:39:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24924 for ; Wed, 6 Sep 2000 19:39:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnq07628; Wed, 6 Sep 2000 23:39:49 GMT Received: by mail-control.mail.uu.net id QQjfnq07892 for mpls-outgoing; Wed, 6 Sep 2000 23:39:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnq07887 for ; Wed, 6 Sep 2000 23:39:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfnq19519 for ; Wed, 6 Sep 2000 19:39:25 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfnq07248 for ; Wed, 6 Sep 2000 23:39:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA19028 for mpls@uu.net; Wed, 6 Sep 2000 19:39:23 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnq07873 for ; Wed, 6 Sep 2000 23:39:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnq19440; Wed, 6 Sep 2000 19:39:00 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjfnq28360; Wed, 6 Sep 2000 23:38:44 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA12164; Wed, 6 Sep 2000 19:38:36 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX07036; Wed, 6 Sep 2000 19:38:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20000906185902.020a90f0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 19:27:47 -0400 To: Jim Boyle , mpls@UU.NET, te-wg@UU.NET From: "Thomas D. Nadeau" Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt Cc: swallow@cisco.com, Arun Viswanathan , cheenu@tachion.com In-Reply-To: <4.3.1.0.20000906140117.00be79f0@10.1.0.131> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Jim, >As the WG chair in question, I would like to point out two things: > >a) my message to tom was not from "lack of consensus", it was an attempt >to redirect his efforts away from "proprietary" and stylistic complaints >to an exploration of how a combination of the two mibs might be done, and >what would be the impact for implementors and operators (the last part has >not been addressed). It was not framed as the solution, in fact I made it >clear that it should not be thought of that way. But why are we shutting off that work? Why did you assign it in the first place? I have not heard from anyone on the list pro/con, but I personally vote to include it into the MPLS-TE-MIB because I think it is important. From several private conversations I have heard that folks liked the compromised solution (i.e.: of incorporating these non-overlapping things into the MPLS-TE-MIB). I hope they respond in public to this thread. When I told these folks that Kireeti, Arun, Cheenu and I were working on a proposal to fold-in the important parts from his MIB into the MPLS-TE-MIB, they were extatic. Let me now outline the advantage of that solution versus adopting another MIB: a) This has all the objects that *all* the operators wanted. That is, those who wanted the objects from Kireeti's MIB and those who wanted the objects from the MPLS-TE-MIB. I think that this is a very important point (perhaps the most important one that I will make now) since I think that this was the goal we were all working very hard to achieve. Adoption of Kireeti's MIB will only diverge the work and create confusion in the marketplace. b) This obviates the need for having Kireeti's MIB because those objects are now in the MPLS-TE-MIB, which from a recent thread on the MPLS mailing list, vendors are implementing and operators are using! I am sure that although vendors will not be terribly happy having to implement the few more objects than were proposed to be folded into the MPLS-TE-MIB, they will be happy to since a good set of vendors have expressed definite interest in them. This solution DOES NOT impact operators since they are free to choose from the set of objects required for implementation. The burden is on the vendors to implement a few more objects which they might have anyway. c) Adopting the other MIB now will be a duplication of effort with the MPLS WG. There is nothing which is in Kireeti's MIB that is not in the MPLS-TE-MIB (or can be added in the future if the WGs see fit to do so). In the future I see a problem with the coordination of both MIBs, since I cannot foresee anything that belongs in Kireeti's MIB not going into the MPLS-TE-MIB. >b) in terms of consensus, there were two compelling arguments > - merge, as we can't have two mibs > - adopt kireeti's as it has all the right information w/ minimal added > complexity Lets not forget the argument of dropping the MIB after we incorporated its salient features into the MPLS-TE-MIB. >The issue of complexity is an obvious one, as there have been discussions >around "minimal implementations" or "conformance relaxation" or >"non-conformant implementations". Some have also pointed out that having >two documents really is not that bad of a thing as they will both tie into >the mib structure independently. This is a misnomer. The MIB structure as a whole does contain many objects, regardless of which actual document they reside in. However, the fact of the matter is that it makes no sense to duplicate a large set of objects under any of the sub-trees. This is what we will effectively have if we adopt Kireeti's MIB after we fold-in the objects from his MIB. >I believe the best thing to do is to accept kireeti's draft as a te-wg >item, as it has both running code and rough (very) consensus behind >it. The mpls wg mib currently does not have the right focus for the te-wg >and all folding kireeti's draft into it does (from the standpoint of >someone who only needs access to the information in kireeti's) is add >complexity. You are unnecessarily complicating the issue here. Folding in of the objects does not complicate things unnecessarily for the operator. What it does is get everyone what they need, regardless of which subset of vendors they were from. The reasons why are: a) From what I understand, operators are after a subset of objects from the MPLS-TE-MIB (including Kireeti's changes). Some of the operators who were originally in favor of Kireeti's MIB have told me that they were only after 2 or 3 objects from his MIB. They did not care if there are other objects in there or in the MPLS-TE-MIB. So, if the intersection of objects is included (and made mandatory which is what was proposed) we make everyone happy. I hope that these operators will now speak and make their thoughts known. b) The MPLS-TE-MIB is not much more complicated than Kireeti's MIB despite some recent advertisements. Yes, it is a bit more complicated at the expense of providing for a far more robust set of functionality (i.e.: tunnels as interfaces, make-before-break, etc...), but NOT at the expense of providing for any of the things which are in Kireeti's MIB. To prove my point, the MPLS-TE-MIB has 4 tables: tunnelTable perfTable HopTable ARHopTable CRHopTable -- added from Kireeti's MIB resourceTable Notifications Kireeti's MIB has one table: tunnel table. All that we have done is break things out and allow things to be a bit more flexible, as well as make provision for additional functionallity which is desired by many. The tunnel table contains a subset of what is available in Kireeti's tunnel table (while making the indexing much better). The various hop tables including the last one, are there to allow for a more orderly representation of the hops for those who care to look at them. For those who just want the source/dest of the tunnel, we have provided these right in the tunnelTable as they are used to from Kireeti's MIB. We have also proposed consolidating a few things with the recent changes from Kireeti's MIB so that we could provide easy access for those operators who were currently using his MIB. So, for all of the reasons outlined above, I do not think that it is necessary or desirable or wise to adopt Kireeti's MIB and move it forward due to its duplication of efforts with the MPLS-TE-MIB, and its lack of features which are desired by some operators. The addition of these, plus the modifications necessary to Kireeti's MIB to make it IESG-worthy will make it look strikingly similar to the MPLS-TE-MIB, further duplicating precious time and effort. --Tom From owner-mpls@UU.NET Wed Sep 6 19:45:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24969 for ; Wed, 6 Sep 2000 19:45:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnr03574; Wed, 6 Sep 2000 23:45:42 GMT Received: by mail-control.mail.uu.net id QQjfnr08603 for mpls-outgoing; Wed, 6 Sep 2000 23:45:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnr08596 for ; Wed, 6 Sep 2000 23:45:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfnr20336 for ; Wed, 6 Sep 2000 19:45:11 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfnq10952 for ; Wed, 6 Sep 2000 23:44:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA19830 for mpls@uu.net; Wed, 6 Sep 2000 19:44:40 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnq08348 for ; Wed, 6 Sep 2000 23:44:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnq20231; Wed, 6 Sep 2000 19:44:12 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjfnq02129; Wed, 6 Sep 2000 23:43:41 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA12494; Wed, 6 Sep 2000 19:43:41 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX07066; Wed, 6 Sep 2000 19:43:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20000906192938.02086f00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 19:32:51 -0400 To: mpls@UU.NET, te-wg@UU.NET From: "Thomas D. Nadeau" Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt In-Reply-To: <200009062310.QAA07680@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I was going to send this out just before I saw Jim's last message and replied, so please excuse the misorder. Jim and I have been having some offline discussions about the two MIBs in question (Kireeti's and the MPLS-TE-MIB), and perceive several options: - pick one (which?) and let it move onto the standards track - move both separately onto the standards track - merge them and move the merged one onto the standards track Arun, Cheenu and I understood that the third option was being requested, and hence merged the MIBs and sent out the email of Wed, 30 Aug 2000 16:06:19 -0400 concerning that activity. However, I'm not sure that I have actually heard the working group's viewpoint or consensus on this, and would like a straw poll. Could you please reply to the list with your opinion on the above, even if only to say "I don't have a strong opinion"? Thank you, --Tom From owner-mpls@UU.NET Wed Sep 6 21:16:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25612 for ; Wed, 6 Sep 2000 21:16:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnx09949; Thu, 7 Sep 2000 01:16:16 GMT Received: by mail-control.mail.uu.net id QQjfnx07469 for mpls-outgoing; Thu, 7 Sep 2000 01:15:50 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnx07460 for ; Thu, 7 Sep 2000 01:15:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfnx01767 for ; Wed, 6 Sep 2000 21:15:32 -0400 (EDT) Received: from apocalypse.quantum3d.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [206.184.176.5]) id QQjfnx09066 for ; Thu, 7 Sep 2000 01:15:01 GMT Received: from saturn.quantum3d.com (SATURN [206.184.177.29]) by apocalypse.quantum3d.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QV1N430V; Wed, 6 Sep 2000 18:11:27 -0700 Received: from DT02017 ([206.184.177.31]) by saturn.quantum3d.com (Lotus Domino Release 5.0.4) with SMTP id 2000090618133940:2527 ; Wed, 6 Sep 2000 18:13:39 -0700 Reply-To: From: "Thomas Huang" To: Subject: Any other IETF drafts on the SONET CES over MPLS Date: Thu, 16 Sep 1999 18:17:42 -0700 Message-ID: <000601bf00aa$713e93b0$4464a8c0@DT02017> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on saturn/Polaris(Release 5.0.4 |June 8, 2000) at 09/06/2000 06:13:39 PM, Serialize by Router on saturn/Polaris(Release 5.0.4 |June 8, 2000) at 09/06/2000 06:13:39 PM, Serialize complete at 09/06/2000 06:13:39 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: For now, I have only found one draft regarding Sonet Circuit Emulation over MPLS (CEM) by Malis, Vernon, and Voglsang. Are there any other documets regarding MPLS for SONET Control? I have Eric Mannie's MPLS for SDH draft dated March 2, 2000. Regards, /Thomas From owner-mpls@UU.NET Wed Sep 6 21:45:46 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26807 for ; Wed, 6 Sep 2000 21:45:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfnz00440; Thu, 7 Sep 2000 01:45:45 GMT Received: by mail-control.mail.uu.net id QQjfnz09298 for mpls-outgoing; Thu, 7 Sep 2000 01:45:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfnz09281 for ; Thu, 7 Sep 2000 01:45:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnz11101; Wed, 6 Sep 2000 21:45:08 -0400 (EDT) Received: from maplenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82]) id QQjfnz25004; Thu, 7 Sep 2000 01:45:03 GMT Received: from prasuncomp (farhad_pc [192.168.10.239]) by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id SAA29348; Wed, 6 Sep 2000 18:44:55 -0700 (PDT) Message-ID: <034d01c0186d$8b6c3400$ef0aa8c0@maplenetworks.com> From: "Sudhanshu Jain" To: , , "Thomas D. Nadeau" References: <4.3.2.7.2.20000906192938.02086f00@bucket.cisco.com> Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt Date: Wed, 6 Sep 2000 18:47:12 -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 Hi Thomas, I agree with your approach and here are my views to this effort. I would like to see single MIB addressing all related issue as it help to clear the confusion. IMHO, LSP info ( in this draft) is not specific to tunnel only and so there is no point them merging it with TE-MIB. Instead, it should be get augmented to mplsXCEntry in LSR MIB. Any comments? Also, why do we have named draft-ietf-mpls-te-mib.txt as "TE-MIB"? IMHO, it should be Tunnel-MIB :)) Is traffic engineering is limited to tunnels only? Thanks, -Sudhanshu ----- Original Message ----- From: "Thomas D. Nadeau" To: ; Sent: Wednesday, September 06, 2000 4:32 PM Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt > > I was going to send this out just before I saw > Jim's last message and replied, so please excuse the > misorder. > > Jim and I have been having some offline discussions about the > two MIBs in question (Kireeti's and the MPLS-TE-MIB), and perceive > several options: > > - pick one (which?) and let it move onto the standards track > - move both separately onto the standards track > - merge them and move the merged one onto the standards track > > Arun, Cheenu and I understood that the third option was being requested, > and hence merged the MIBs and sent out the email of Wed, 30 Aug 2000 > 16:06:19 -0400 > concerning that activity. However, I'm not sure that I have actually heard the > working group's viewpoint or consensus on this, and would like a straw > poll. Could > you please reply to the list with your opinion on the above, even if only > to say "I don't have a strong opinion"? > > Thank you, > > --Tom > > From owner-mpls@UU.NET Wed Sep 6 23:29:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28655 for ; Wed, 6 Sep 2000 23:29:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfof04523; Thu, 7 Sep 2000 03:29:24 GMT Received: by mail-control.mail.uu.net id QQjfof08949 for mpls-outgoing; Thu, 7 Sep 2000 03:28:55 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfof08937 for ; Thu, 7 Sep 2000 03:28:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfof17307; Wed, 6 Sep 2000 23:28:42 -0400 (EDT) Received: from force10networks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQjfof12953; Thu, 7 Sep 2000 03:28:41 GMT Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Sep 2000 20:28:39 -0700 Message-ID: <071bc2912d16b792bf9ec10604a7906239b70b71@force10networks.com> From: Arun Viswanathan To: "'Sudhanshu Jain'" , mpls@UU.NET, te-wg@UU.NET, "Thomas D. Nadeau" Subject: RE: Consensus for draft-kompella-mpls-te-mib-00.txt Date: Wed, 6 Sep 2000 20:28:32 -0700 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 Sudhanshu, > I agree with your approach and here are my views to this effort. > > I would like to see single MIB addressing all related issue > as it help to > clear the confusion. > > IMHO, LSP info ( in this draft) is not specific to tunnel > only and so there > is no point them merging it with TE-MIB. Instead, it should > be get augmented > to mplsXCEntry in LSR MIB. I think the confusion is arising out of the use of the term LSP in Kireeti's MIB to actually mean tunnels as defined in RSVP/CRLDP drafts or as in MPLS-TE-MIB. So there are no objects in Kireeti's MIB that need to go into the LSR MIB. > > Any comments? > > Also, why do we have named draft-ietf-mpls-te-mib.txt as > "TE-MIB"? IMHO, it > should be Tunnel-MIB :)) We could have, but I doubt if that would have changed anything with regard to this debate :-) -arun > > > From owner-mpls@UU.NET Wed Sep 6 23:52:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29308 for ; Wed, 6 Sep 2000 23:52:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfoh18942; Thu, 7 Sep 2000 03:52:27 GMT Received: by mail-control.mail.uu.net id QQjfoh10399 for mpls-outgoing; Thu, 7 Sep 2000 03:51:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfoh10394 for ; Thu, 7 Sep 2000 03:51:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfoh27012 for ; Wed, 6 Sep 2000 23:51:55 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfoh18204 for ; Thu, 7 Sep 2000 03:51:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA06061 for mpls@uu.net; Wed, 6 Sep 2000 23:51:24 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfoh10381 for ; Thu, 7 Sep 2000 03:51:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfoh26943 for ; Wed, 6 Sep 2000 23:51:15 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfoh17904 for ; Thu, 7 Sep 2000 03:50:59 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id UAA26971; Wed, 6 Sep 2000 20:51:18 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id UAA11363; Wed, 6 Sep 2000 20:50:57 -0700 (PDT) Message-ID: <39B71154.720B6054@cisco.com> Date: Wed, 06 Sep 2000 20:53:56 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sitarama R Kalipatnapu CC: erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6A9E5.1939914C@adn.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Sitarama, > I agree with your analysis. I am glad. > But which entity in the router is consuming > the resources of the router ! That I think is VRFs, BGP RIBs and FIBs. > In that sense, we may say, BGP induced chokepoint of the router. First let me clarify that VRFs structures, RIBs & FIBs have nothing to do with BGP. They do just fine even if bgp process is not running at all in a stand alone box configuration. And in that case you may go out of given box resources at the very close point as if you would run bgp on this box and peer with other PEs/RRs. BGP is just the transport vehicle for routes to get to those other edge boxes which do need them. Isn't it the main task of bgp to advertise reachability information and associated with them policy ? With multiprotocol extensions this can be done for different kind of addresses ipv4, multicast, ipv6, E.164 etc ... in our case we are using it for vpnv4 addresses. Afterall if you corelate each prefix to a passenger and bgp process as a flight crew can one blame a pilot or a flight attendent that this is no enough sits on the plane. Sure flight attended will have a bit of more work to do but they can not help that the size of the plane is limited and that some passengers will need to catch another one. (Of course plane is a router). > As we add more VPNs the number of VRFs in the router increases, > pushing the demands on memory and CPU. If those VPNs inject a lot of routes yes. If they are just using one default out to a headquarter I would not say that even with the number of vrf reaching platform maxinterface limit there is an issue. > In the case of BGP peering > with customer edge, BGP demands on the router resources is even > higher. As we rely more on BGP to do everything for the MPLS > VPNs, the CPU time consumed by BGP increases. One of my earlier > questions was on the 'BGP induced choke point'. Notice that inbound processing, maintenance and update generation are all independent. Without getting into OS design of any of today available on the market routers and it's cpu power even with a decent number of PE-CE EBGP sessions we have never seen as cpu hog caused by bgp. I am sory that I can't quantify any number here but too many variables are involved in the equation. R. > > > > 3. Is it possible to unload the demands on BGP (carrying interior MPLS labels ) > > > > in the BGP/MPLS VPNs model ? > > Can something be done about it to ease load on BGP ? > > Thanks. > > --Sitaram > > Robert Raszuk wrote: > > > Sitarama, > > > > > 1. When do you decide to add another PE router, as the number of > > > VPNs supported is increasing ? > > > > Let me say once again that number of VPNs does not trigger addition of > > another PE. Why ? Simply because the overhead of vrf is memory > > consumption wise not significant. What does matter is the number of > > routes your VPNs give you as you need to store them in the vpnv4 bgp > > table as well in RIBs & FIBs for given vrfs. So it really depends on the > > operator's comfort with a given router to run at X% of memory > > utlization. Notice that in moders routers the memory limit and upgrade > > flexibility is growing so even that may not be a very significant > > factor. > > > > The same applies to CPU. > > > > > 2. What makes us add a second PE router ? > > > > See above. > > > > > 3. Is this connected to BGP ? > > > > No. In a peering VPN model you need to maintain customer routes. What > > ever protocol you would use you will still have a potential of hitting > > the hardware limitations at some point and bgp is quite ortogonal to > > this. > > > > Just one more comment on your last question: > > > > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > > > in the BGP/MPLS VPNs model ? > > > > Using bgp to carry labels for vpn routes is totally not an issue as it > > just extending the NLRI size by 20 bits without any processing penalty. > > BGP is more or less just a vehicle here. > > > > R. > > > > > > > > Thanks, > > > > > > --Sitaram > > > > > > Robert Raszuk wrote: > > > > > > > Sitarama, > > > > > > > > BGP is not a choke point. First it is already there in all edge routers > > > > in all ISPs I know of and adding the new AF to it does not cause it to > > > > choke in the right implementation. Notice that the "choking" effect all > > > > depends how one sets the timers (per AF of course - so it does not > > > > effect plain IPV4 updates or other bgp IPV4 mechanisms). As a contary to > > > > what you are saying many customers are setting the VPNv4 timers more > > > > aggresively then ipv4 timers to allow equal to IGP convergence and even > > > > that is not causing bgp to "choke" in a production networks. > > > > > > > > The scalability of MPLS-VPNs is achived by the fact that BGP is being > > > > used as a tool there so it would be a mistake to even attempt it's > > > > replacement by some other means. > > > > > > > > R. > > > > > > > > > On the note of scalability of BGP/MPLS VPNs, adding more hardware > > > > > seems to do the trick. But on a close observation it appears, BGP is the > > > > > choke point. BGP running in the provider edge seems to peer with the > > > > > customer edges and also distribute MPLS labels across PE edges. The > > > > > questions are: > > > > > > > > > > 1. Do we have alternate solutions to provide MPLS VPNs without BGP ? > > > > > 2. If so are they effective ? > > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS labels ) > > > > > in the BGP/MPLS VPNs model ? > > > > > > > > > > Thank You. > > > > > > > > > > --Sitaram > > > > > > > > > > Eric Rosen wrote: > > > > > > > > > > > Brijesh> I think you are probably right. It seems that the model in RFC 2547 > > > > > > Brijesh> may be flawed because it fails to separate internal VPN control and > > > > > > Brijesh> configuration within a domain from the routing control plane > > > > > > Brijesh> primarily designed for carrying external inter-domain transit > > > > > > Brijesh> traffic. > > > > > > > > > > > > No it doesn't. It does use BGP for both purposes though. The fact that > > > > > > technology which is primarily designed for one application is also used for > > > > > > a second application is not generally considered to be a bad thing. > > > > > > > > > > > > Brijesh> adding VPN related policies (basically, internal traffic of a > > > > > > Brijesh> domain) to something that was originally designed to provide policy > > > > > > Brijesh> control of inter-domain traffic doesn't seem obviously appropriate. > > > > > > > > > > > > The "VPN-related policies" are primarily expressed as filtering on community > > > > > > attributes, which is actually fits in quite well with normal BGP functions. > > > > > > > > > > > > Brijesh> Besides the scalability problems you mentioned, > > > > > > > > > > > > The only scalability problem Randy mentioned is that as you get more > > > > > > customers, you might have to add more equipment. I'd like to see the scheme > > > > > > in which the hardware cost is independent of the load! > > > > > > > > > > > > Brijesh> It is not going to help busy network administrators who need to > > > > > > Brijesh> manage large number of BGP nodes, and resolve policy conflicts in > > > > > > Brijesh> increasingly large and complex networks. > > > > > > > > > > > > This is sophistry. You could argue against any VPN scheme whatsoever by > > > > > > pointing out that it creates some administrative burden, when compared with > > > > > > not having any VPN scheme at all. That's not very interesting, it's only > > > > > > interesting to compare two VPN schemes, for instance RFC2547 > > > > > > vs. configuring, managing, and maintaining hundreds of thousands of > > > > > > point-to-point tunnels. From owner-mpls@UU.NET Thu Sep 7 00:15:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29487 for ; Thu, 7 Sep 2000 00:15:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfoj03288; Thu, 7 Sep 2000 04:15:03 GMT Received: by mail-control.mail.uu.net id QQjfoi23495 for mpls-outgoing; Thu, 7 Sep 2000 04:14:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfoi23490 for ; Thu, 7 Sep 2000 04:14:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfoi22857 for ; Thu, 7 Sep 2000 00:14:25 -0400 (EDT) Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjfoi17413 for ; Thu, 7 Sep 2000 04:13:52 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 07 Sep 2000 09:57:03 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA31351; Thu, 7 Sep 2000 09:32:09 +0530 Reply-To: From: "Manikantan S" To: "'Paul Tasillo'" , "'mpls@UU. net'" Subject: RE: MPLS Mibs in production code Date: Thu, 7 Sep 2000 09:42:00 +0530 Message-Id: <000901c01881$c5e2d940$1006000a@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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Future Software Supports LDP MIB and TE MIB in the current shipping versions of its MPLS software - FutureMPLS. The support for LSR MIB will be available in the next releases. thanks and regards mani ----------------------------------------- S.Manikantan Project Manager Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Paul Tasillo Sent: Thursday, 7 September 2000 12:32 AM To: mpls@UU. net Subject: MPLS Mibs in production code Aside from Cisco, are there any other vendors that have support for any of the MPLS MIBs in production (ie. publically available today)? Thanks in advance, Paul From owner-mpls@UU.NET Thu Sep 7 00:37:24 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29685 for ; Thu, 7 Sep 2000 00:37:24 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfok04770; Thu, 7 Sep 2000 04:37:12 GMT Received: by mail-control.mail.uu.net id QQjfok24853 for mpls-outgoing; Thu, 7 Sep 2000 04:36:39 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfok24848 for ; Thu, 7 Sep 2000 04:36:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfok02417 for ; Thu, 7 Sep 2000 00:36:34 -0400 (EDT) Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjfok04169 for ; Thu, 7 Sep 2000 04:36:31 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 07 Sep 2000 10:19:45 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA32110; Thu, 7 Sep 2000 09:54:49 +0530 Reply-To: From: "Manikantan S" To: "'Hong Liao'" Cc: Subject: RE: question on RSVP-TE Date: Thu, 7 Sep 2000 10:04:41 +0530 Message-Id: <000a01c01884$f0e0fc00$1006000a@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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <85256952.0079AAC3.00@notes949.cc.telcordia.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Julia # #>This is just a text string that can be used by net management. By #>carrying it along in the signalling the same name is used at all nodes #>along the tunnel. This makes it easier for operators to pick out a #>particular tunnel of interest, # #1) For the "Session name" in Session Attribute object, does it mean any given #Session name for the session created along the tunnel? mani> Yes. My understanding is that, it is any given session name for easy reference associated with the tunnel. # #2) So for the padding, you mean basically it should be at least 4, or multiple #of 4 bytes. Then my question is that the padding should be put before or after #the Session name? For my understanding, it should be put padding after. mani> Reproducing the last paragraph above section 4.7.4 Page 51 in "draft-ietf-mpls-rsvp-lsp-tunnel-07.txt" for your refernce --------------------------------------------------------------------- The contents of the Session Name field are a string, typically of displayable characters. The Length MUST always be a multiple of 4 and MUST be at least 8. For an object length that is not a multiple of 4, the object is padded with trailing NULL characters. The Name Length field contains the actual string length. --------------------------------------------------------------------- As indicated above the Length should be atleaset 8 (and not 4), and multiple of 4. Regarding the padding, it should be after the session name. thanks in advance with best regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com web : www.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Thu Sep 7 00:37:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29715 for ; Thu, 7 Sep 2000 00:37:59 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfok18979; Thu, 7 Sep 2000 04:37:53 GMT Received: by mail-control.mail.uu.net id QQjfok24871 for mpls-outgoing; Thu, 7 Sep 2000 04:37:22 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfok24866 for ; Thu, 7 Sep 2000 04:37:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfok02475 for ; Thu, 7 Sep 2000 00:37:09 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQjfok04271 for ; Thu, 7 Sep 2000 04:36:39 GMT Received: from gketell-lt.juniper.net (ssh.juniper.net [207.17.136.39]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id VAA02288; Wed, 6 Sep 2000 21:35:34 -0700 (PDT) Message-Id: <4.3.2.7.2.20000906212856.0170b060@localhost> X-Sender: gketell@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 21:35:31 -0700 To: raszuk@cisco.com, Sitarama R Kalipatnapu From: Greg Ketell Subject: Re: ISPs offering VPN service Cc: erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" In-Reply-To: <39B71154.720B6054@cisco.com> References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6A9E5.1939914C@adn.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 08:53 PM 9/6/2000 -0700, Robert Raszuk wrote: >Hi Sitarama, > > > I agree with your analysis. > >I am glad. > > > But which entity in the router is consuming > > the resources of the router ! That I think is VRFs, BGP RIBs and FIBs. > > In that sense, we may say, BGP induced chokepoint of the router. > >First let me clarify that VRFs structures, RIBs & FIBs have nothing to >do with BGP. They do just fine even if bgp process is not running at all >in a stand alone box configuration. And in that case you may go out of >given box resources at the very close point as if you would run bgp on >this box and peer with other PEs/RRs. > >BGP is just the transport vehicle for routes to get to those other edge >boxes which do need them. Isn't it the main task of bgp to advertise >reachability information and associated with them policy ? With >multiprotocol extensions this can be done for different kind of >addresses ipv4, multicast, ipv6, E.164 etc ... in our case we are using >it for vpnv4 addresses. > >Afterall if you corelate each prefix to a passenger and bgp process as a >flight crew can one blame a pilot or a flight attendent that this is no >enough sits on the plane. Sure flight attended will have a bit of more >work to do but they can not help that the size of the plane is limited >and that some passengers will need to catch another one. (Of course >plane is a router). > > > As we add more VPNs the number of VRFs in the router increases, > > pushing the demands on memory and CPU. > >If those VPNs inject a lot of routes yes. If they are just using one >default out to a headquarter The whole reason customers/ISPs want IP/MPLS VPNs to so simplify networking requirements. Assuming one route per site with no any-to-any reachability you have just eliminated the entire benefit of this technology. Why have it in this scenario? The reality is that people want this for any-to-any reachability which means multiple routes per VRF. Now your flight crew is responsible not just for the passengers on this plane but on all the other associated planes too. GK >I would not say that even with the number >of vrf reaching platform maxinterface limit there is an issue. > > > In the case of BGP peering > > with customer edge, BGP demands on the router resources is even > > higher. As we rely more on BGP to do everything for the MPLS > > VPNs, the CPU time consumed by BGP increases. One of my earlier > > questions was on the 'BGP induced choke point'. > >Notice that inbound processing, maintenance and update generation are >all independent. Without getting into OS design of any of today >available on the market routers and it's cpu power even with a decent >number of PE-CE EBGP sessions we have never seen as cpu hog caused by >bgp. I am sory that I can't quantify any number here but too many >variables are involved in the equation. > >R. > > > > > > 3. Is it possible to unload the demands on BGP > (carrying interior MPLS labels ) > > > > > in the BGP/MPLS VPNs model ? > > > > Can something be done about it to ease load on BGP ? > > > > Thanks. > > > > --Sitaram > > > > Robert Raszuk wrote: > > > > > Sitarama, > > > > > > > 1. When do you decide to add another PE router, as the number of > > > > VPNs supported is increasing ? > > > > > > Let me say once again that number of VPNs does not trigger addition of > > > another PE. Why ? Simply because the overhead of vrf is memory > > > consumption wise not significant. What does matter is the number of > > > routes your VPNs give you as you need to store them in the vpnv4 bgp > > > table as well in RIBs & FIBs for given vrfs. So it really depends on the > > > operator's comfort with a given router to run at X% of memory > > > utlization. Notice that in moders routers the memory limit and upgrade > > > flexibility is growing so even that may not be a very significant > > > factor. > > > > > > The same applies to CPU. > > > > > > > 2. What makes us add a second PE router ? > > > > > > See above. > > > > > > > 3. Is this connected to BGP ? > > > > > > No. In a peering VPN model you need to maintain customer routes. What > > > ever protocol you would use you will still have a potential of hitting > > > the hardware limitations at some point and bgp is quite ortogonal to > > > this. > > > > > > Just one more comment on your last question: > > > > > > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS > labels ) > > > > > > in the BGP/MPLS VPNs model ? > > > > > > Using bgp to carry labels for vpn routes is totally not an issue as it > > > just extending the NLRI size by 20 bits without any processing penalty. > > > BGP is more or less just a vehicle here. > > > > > > R. > > > > > > > > > > > Thanks, > > > > > > > > --Sitaram > > > > > > > > Robert Raszuk wrote: > > > > > > > > > Sitarama, > > > > > > > > > > BGP is not a choke point. First it is already there in all edge > routers > > > > > in all ISPs I know of and adding the new AF to it does not cause > it to > > > > > choke in the right implementation. Notice that the "choking" > effect all > > > > > depends how one sets the timers (per AF of course - so it does not > > > > > effect plain IPV4 updates or other bgp IPV4 mechanisms). As a > contary to > > > > > what you are saying many customers are setting the VPNv4 timers more > > > > > aggresively then ipv4 timers to allow equal to IGP convergence > and even > > > > > that is not causing bgp to "choke" in a production networks. > > > > > > > > > > The scalability of MPLS-VPNs is achived by the fact that BGP is being > > > > > used as a tool there so it would be a mistake to even attempt it's > > > > > replacement by some other means. > > > > > > > > > > R. > > > > > > > > > > > On the note of scalability of BGP/MPLS VPNs, adding more hardware > > > > > > seems to do the trick. But on a close observation it appears, > BGP is the > > > > > > choke point. BGP running in the provider edge seems to peer > with the > > > > > > customer edges and also distribute MPLS labels across PE edges. The > > > > > > questions are: > > > > > > > > > > > > 1. Do we have alternate solutions to provide MPLS VPNs without > BGP ? > > > > > > 2. If so are they effective ? > > > > > > 3. Is it possible to unload the demands on BGP (carrying MPLS > labels ) > > > > > > in the BGP/MPLS VPNs model ? > > > > > > > > > > > > Thank You. > > > > > > > > > > > > --Sitaram > > > > > > > > > > > > Eric Rosen wrote: > > > > > > > > > > > > > Brijesh> I think you are probably right. It seems that the > model in RFC 2547 > > > > > > > Brijesh> may be flawed because it fails to separate internal > VPN control and > > > > > > > Brijesh> configuration within a domain from > the routing control plane > > > > > > > Brijesh> > primarily designed for carrying external inter-domain transit > > > > > > > Brijesh> traffic. > > > > > > > > > > > > > > No it doesn't. It does use BGP for both purposes > though. The fact that > > > > > > > technology which is primarily designed for one application > is also used for > > > > > > > a second application is not generally considered to be a bad > thing. > > > > > > > > > > > > > > Brijesh> adding VPN related > policies (basically, internal traffic of a > > > > > > > Brijesh> domain) to something that was originally designed to > provide policy > > > > > > > Brijesh> control of inter-domain traffic doesn't seem > obviously appropriate. > > > > > > > > > > > > > > The "VPN-related policies" are primarily expressed as > filtering on community > > > > > > > attributes, which is actually fits in quite well with normal > BGP functions. > > > > > > > > > > > > > > Brijesh> Besides the scalability problems you mentioned, > > > > > > > > > > > > > > The only scalability problem Randy mentioned > is that as you get more > > > > > > > customers, you might have to add more equipment. I'd like to > see the scheme > > > > > > > in which the hardware cost is independent of the load! > > > > > > > > > > > > > > Brijesh> It is not going to help busy network > administrators who need to > > > > > > > Brijesh> manage large number of BGP nodes, and > resolve policy conflicts in > > > > > > > Brijesh> increasingly large and complex networks. > > > > > > > > > > > > > > This is sophistry. You could argue against any VPN > scheme whatsoever by > > > > > > > pointing out that it creates some administrative burden, > when compared with > > > > > > > not having any VPN scheme at all. That's not > very interesting, it's only > > > > > > > > interesting to compare two VPN schemes, for instance RFC2547 > > > > > > > > vs. configuring, managing, and maintaining hundreds of thousands of > > > > > > > point-to-point tunnels. From owner-mpls@UU.NET Thu Sep 7 01:52:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05722 for ; Thu, 7 Sep 2000 01:52:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfop06813; Thu, 7 Sep 2000 05:52:52 GMT Received: by mail-control.mail.uu.net id QQjfop11016 for mpls-outgoing; Thu, 7 Sep 2000 05:52:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfop11010 for ; Thu, 7 Sep 2000 05:52:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfop11474 for ; Thu, 7 Sep 2000 01:52:15 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfop06055 for ; Thu, 7 Sep 2000 05:51:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA15905 for mpls@uu.net; Thu, 7 Sep 2000 01:51:44 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfop10964 for ; Thu, 7 Sep 2000 05:51:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfop04219 for ; Thu, 7 Sep 2000 01:50:59 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfop05649 for ; Thu, 7 Sep 2000 05:50:58 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA13643; Wed, 6 Sep 2000 22:51:17 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id WAA11382; Wed, 6 Sep 2000 22:50:56 -0700 (PDT) Message-ID: <39B72D73.C5B6EE29@cisco.com> Date: Wed, 06 Sep 2000 22:53:55 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Greg Ketell CC: Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6A9E5.1939914C@adn.alcatel.com> <4.3.2.7.2.20000906212856.0170b060@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Greg, > The whole reason customers/ISPs want IP/MPLS VPNs to so simplify networking > requirements. Assuming one route per site with no any-to-any reachability > you have just eliminated the entire benefit of this technology. Why have > it in this scenario? This scenario was just to demonstrate the casue of router's resources limits not to suggest any type of deployment scenario. Now since you have asked the question there is a lot of current enterprises is useing leased lines technology or PVC for it's own connectivity. Those usually go from small sites to big centers. Those customers are so used to this model that that they want to maintain this model even if they go to mpls-vpns from any service provider. Sometimes this comes from centalized application, sometimes just from security point of view. That is not too say that I personely like hub and spoke. In fact I do agree with you that full mesh is the way to go and mpls-vpns easily allow it. > The reality is that people want this for any-to-any reachability which > means multiple routes per VRF. Now your flight crew is responsible not > just for the passengers on this plane but on all the other associated > planes too. Not really. Remember the same bgp process and the same router handles all vpnv4 trie/tries (depnding on the implementation choice). So this is still one plane. The difference is that it happens to carry passengers belonging to closed groups (marked or separated by RD value) which are not allowed to be mixed with each other. R. From owner-mpls@UU.NET Thu Sep 7 03:05:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13087 for ; Thu, 7 Sep 2000 03:05:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfou19716; Thu, 7 Sep 2000 07:05:17 GMT Received: by mail-control.mail.uu.net id QQjfou08412 for mpls-outgoing; Thu, 7 Sep 2000 07:05:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfou08403 for ; Thu, 7 Sep 2000 07:04:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfou19885 for ; Thu, 7 Sep 2000 03:04:47 -0400 (EDT) Received: from csa.iisc.ernet.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjfou19082 for ; Thu, 7 Sep 2000 07:04:06 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id MAA12896 for ; Thu, 7 Sep 2000 12:33:21 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id MAA11373 for ; Thu, 7 Sep 2000 12:33:33 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Thu, 7 Sep 2000 12:33:32 +0530 (IST) From: Ramanjaneyulu Y T To: mpls@UU.NET Subject: questions on RSVP-MPLS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, we are using RSVP-TE for label distribution. I have the following questions in this regard. If someone already discussed please provide pointers in mail archives. * MPLS requires label from downstream LSR . Does MPLS generates label or RSVP-TE generates label for setting LSP ? * While using make before break , should we generate new label for new LSP or use old LSP labels on the common links. If the same label is used , then how can we use the old resources of the old LSP?.Also it may happens that we may have 2 reservation states blocks with same label mapping. The problem comes at common node , where old and new LSP splits. In this case there are 2 entries in LSR for incoming label. How to resolve this?. Is this implementation issue or are there any drafts addressing this problem?. Thanks in advance. Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@rediffmail.com BANGALORE - 560012 | kingytr@excite.com PH: 0091 - 080 - 3092622 ( HOSTEL ) | 0091 - 080 - 3092906 ( LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- From owner-mpls@UU.NET Thu Sep 7 03:19:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13168 for ; Thu, 7 Sep 2000 03:19:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfov10286; Thu, 7 Sep 2000 07:19:00 GMT Received: by mail-control.mail.uu.net id QQjfov09605 for mpls-outgoing; Thu, 7 Sep 2000 07:18:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfov09600 for ; Thu, 7 Sep 2000 07:18:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfov14119 for ; Thu, 7 Sep 2000 03:18:19 -0400 (EDT) From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjfov27622 for ; Thu, 7 Sep 2000 07:18:18 GMT Received: from cclmsent02.lon.bt.com by gollum (local) with ESMTP; Thu, 7 Sep 2000 08:19:10 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Thu, 7 Sep 2000 08:17:37 +0100 Message-ID: To: curtis@avici.com Cc: mpls@UU.NET Subject: RE: Info about mpls-vpn Date: Thu, 7 Sep 2000 08:17:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis observered: > If you are running BGP/VPN inside LDP, the same improvement would > apply to LDP or LDP inside aggregate TE tunnels. Recovering a smaller > number of TE tunnels should be easier than recovering a much larger > number of LDP label mappings. [Harrison,N,Neil,INC1 X] This is the key point Curtis. From our experience in other technologies we have concluded that multiple levels of restoration are not a good thing. Its better (i) to minimise the number of nested technologies (for lots of reasons, but here let's just consider failures and restoration wrt MPLS LSPs) and (ii) have fast bottom-level (coarse) transport restoration with slower top-level (fine) transport restoration. Now, since LSPs can be nested and they can also be provided by several LDP-type mechanisms (I am being generic here, and covering vanilla-LDP, RSVP-LDP, CR-LDP and BGP4-LDP when I say 'LDP-type' as techniques for label distribution) there are 2 variables: - nested LSPs per se, say from same LDP-type, implies practical restoration considerations would limit the number of nested levels (assuming lower level has to react 1st)......but now hold-offs are within a homogenous LDP-type - nested LSPs from different LDP-types, implies same as above from practical restoration considerations, but now we have potential dependancies between the LDP-types. From the last point, and noting that one would want the higher level LSPs to be more 'defect duration tolerant' than the lower LSPs, I am wondering if all the possible client/server nested LDP-type relationships have been considered......simply so that higher level LSPs don't start reacting to seeing failures before lower level LSPs have had chance to react? I gave the example of of a VPN whose top-level LSP topology was constructed using BGP4 label distribution maybe sitting on server layer TE-like LSPs constructs from (either?) RSVP-LDP or CR-LDP....but if we use the latter, I assume we also have to run vanilla-LDP (which would then be a server layer to CR-LDP....assuming, for example, I was running DU). Now since the correct forwarding behaviour of an LSP at level N is predicated on there being a valid server LSP at level N-1 (and this would recurse to the number of nested LSP levels considered), my concern was whether we had thought through these aspects at all? Hence my question as to what LDP-type nested relationships are better than others. Does anyone else see my concerns, or am I missing something in my problem statement? > If you look at the scaling issues of the overall problem and at the > fault recovery problem dropping LDP entirely and doing TE tunnels > inside TE across areas has advantages over LDP alone or LDP inside TE. [Harrison,N,Neil,INC1 X] Quite......and this is the view I am coming to, minimise LDP-types (and also number of nested LSP levels). Best regards, Neil From owner-mpls@UU.NET Thu Sep 7 04:13:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13663 for ; Thu, 7 Sep 2000 04:13:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfoy24353; Thu, 7 Sep 2000 08:13:16 GMT Received: by mail-control.mail.uu.net id QQjfoy24548 for mpls-outgoing; Thu, 7 Sep 2000 08:12:43 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfoy24532 for ; Thu, 7 Sep 2000 08:12:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfoy27699; Thu, 7 Sep 2000 04:12:19 -0400 (EDT) Received: from sdtmail02.mtn.co.za by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sdtpix1.mtn.co.za [196.35.196.130]) id QQjfoy27363; Thu, 7 Sep 2000 08:12:16 GMT Received: by SDTMAIL02 with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 10:11:55 +0200 Message-ID: <435D6BCB9DBDD11188F800805FF585830863DC4C@sdtmail03.mtn.co.za> From: Magatho Anthony Mello To: Florian-Daniel Otel , Jeremy Lawrence Cc: mpls@UU.NET, te-wg@UU.NET Subject: RE: Incremental MPLS (BCP document lookup) Date: Thu, 7 Sep 2000 10:11:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I am interested in the response. Please copy me if you get or send any responses off-list. -----Original Message----- From: Florian-Daniel Otel [mailto:otel@ce.chalmers.se] Sent: Wednesday, 06 September 2000 10:43 AM To: Jeremy Lawrence Cc: mpls@UU.NET; te-wg@UU.NET Subject: Re: Incremental MPLS (BCP document lookup) Jeremy, First of all, thanks for the insight. Second, as I didn't get any replies other than yours I will expand (below) the reason for my questioning. > Florian, >> I am looking for a case study document/white paper focused >> on/describing the possible means (maybe even claimed advantages ?) of >> introducing MPLS in a _incremental_ manner in a core network. > What does the core network look like before MPLS is turned on? Very plain and very simple: It is a transit network, small core size (< 10 routers) , star-of-stars topology, IP over PPP/HDLC connections. Two external links to higher tier ISPs and several "customer" links. The network carries basically two diffent types of traffic that have to be distributed. The two types of traffic source from several locations, with some locations sourcing both types. The way they are handling it right now is w/ BGP peering as the traffic is mostly inter-AS bound. The claimed advantage of using MPLS on this simplistic topology is that the two types of traffic can be aggregated at different levels and the trunks handled independently. > If the core network is an IP router network then there is at least > one router implementation where MPLS signalling (LDP or RSVP) can be > enabled on a link-by-link basis in a live network (possibly after a > software upgrade, which can be done node-by-node). The advantage > of is largely that the network can still be forwarding IP traffic > while the MPLS upgrade is going on. Giving the "if-it-works-don't-fix-it" attitude towards things of most operators in order to make a successful "MPLS sales" job to the operator one has to convince them that they can do it incrementally with minimum fuss (this operator attidude is "we don't want increased or even _different_ complexity than the one we have now.."). That is why running RSVP or LDP won't do it. What I had in mind was that, at least in initial stages, they should hook label distribution on existing BGP peering and do independent LSP control. And after they get confortable w/ it they can start doing fancier stuff like running RSVP-TE/CR-LDP e.g to reserve resources (bandwidth) based on traffic type, etc. Anything wrong with this picture ? Ideas ? All in all that is why I was looking for a document describing a way to incrementally implement MPLS in a net and the claimed advantages...;) > Regards, > Jeremy All the best, Florian. P.S: This might be more of an operational (TE) question than mpls so if you consider it off-topic please reply off-list. From owner-mpls@UU.NET Thu Sep 7 07:16:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14879 for ; Thu, 7 Sep 2000 07:16:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfpl00418; Thu, 7 Sep 2000 11:16:34 GMT Received: by mail-control.mail.uu.net id QQjfpl10376 for mpls-outgoing; Thu, 7 Sep 2000 11:16:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfpl10329 for ; Thu, 7 Sep 2000 11:16:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfpl06685 for ; Thu, 7 Sep 2000 07:15:58 -0400 (EDT) Received: from ss3000e.cselt.it by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ss3000e.cselt.it [163.162.41.5]) id QQjfpl26741 for ; Thu, 7 Sep 2000 11:15:41 GMT Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G0I002DOKLO6J@ss3000e.cselt.it> for mpls@uu.net; Thu, 7 Sep 2000 13:15:26 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Thu, 07 Sep 2000 13:17:39 +0200 Content-return: allowed Date: Thu, 07 Sep 2000 13:10:24 +0200 From: "D'Albenzio Raffaele" Subject: CE IP address To: "'mpls@uu.net'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I have a question about draft-rosen-rfc2547bis-02 In section 12 he says that I can assign to a CE router an address coming from SP address space or VPN address space. If the SP want to manage the CE then he must assing to CE an address coming from the address space of SP. The question is: if the address space of the SP is a private address space (e.g 10.x.x.x) and if the address assigned to the CE is equal to the address assigned to a router or a client of the customer VPN (that also have a private address space 10.x.x.x), can I have any problem of address overlapping? Thank you, Raffaele. From owner-mpls@UU.NET Thu Sep 7 10:13:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16603 for ; Thu, 7 Sep 2000 10:13:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfpw16751; Thu, 7 Sep 2000 14:13:48 GMT Received: by mail-control.mail.uu.net id QQjfpw26311 for mpls-outgoing; Thu, 7 Sep 2000 14:13:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfpw26306 for ; Thu, 7 Sep 2000 14:13:21 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfpw12439 for ; Thu, 7 Sep 2000 10:13:12 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfpw16079 for ; Thu, 7 Sep 2000 14:13:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA15916 for mpls@uu.net; Thu, 7 Sep 2000 10:13:11 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfpw26279 for ; Thu, 7 Sep 2000 14:12:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfpw12341 for ; Thu, 7 Sep 2000 10:12:37 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjfpw15624 for ; Thu, 7 Sep 2000 14:12:36 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 10:07:42 -0400 Message-ID: <7BF58A904536D411ADD400508BC97B8501BFAA@xover1.netplane.com> From: "Friedeborn, William" To: "'mpls@UU.NET'" Subject: MPLS TE MIB - ARHop table Date: Thu, 7 Sep 2000 10:07:41 -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 I noticed the text description for the ARHop table differs from the index information. Specifically the description says "Each row in this table is indexed primarily by the same indices, mplsTunnelIndex and mplsTunnelInstance, as the row of the corresponding tunnel in mplsTunnelTable. Each row also has a third index mplsTunnelARHopIndex" The entry says "INDEX { mplsTunnelARHopListIndex, mplsTunnelARHopIndex }" Is it supposed to be INDEX {mplsTunnelIndex, mplsTunnelInstance, mplsTunnelARHopIndex} Bill From owner-mpls@UU.NET Thu Sep 7 10:26:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16858 for ; Thu, 7 Sep 2000 10:26:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfpx28499; Thu, 7 Sep 2000 14:26:46 GMT Received: by mail-control.mail.uu.net id QQjfpx27567 for mpls-outgoing; Thu, 7 Sep 2000 14:26:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfpx27536 for ; Thu, 7 Sep 2000 14:26:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfpx14947 for ; Thu, 7 Sep 2000 10:25:54 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfpx13186 for ; Thu, 7 Sep 2000 14:25:53 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA22681 for ; Thu, 7 Sep 2000 07:26:12 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA29171 for mpls@uu.net; Thu, 7 Sep 2000 10:25:52 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfnl21077 for ; Wed, 6 Sep 2000 22:17:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfnl08194; Wed, 6 Sep 2000 18:17:02 -0400 (EDT) Received: from hme0.s0092.idc1.oss.level3.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gdffw1.denver1.level3.net [209.244.1.161]) id QQjfnl00890; Wed, 6 Sep 2000 22:17:01 GMT Received: from vmboyle1.Level3.com ([10.1.39.132]) by hme0.s0092.idc1.oss.level3.com (8.8.8+Sun/8.8.8) with ESMTP id QAA24740; Wed, 6 Sep 2000 16:16:52 -0600 (MDT) Message-Id: <4.3.1.0.20000906140117.00be79f0@10.1.0.131> X-Sender: jboyle@10.1.0.131 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 06 Sep 2000 16:23:30 -0600 To: mpls@UU.NET, te-wg@UU.NET From: Jim Boyle Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 04:06 PM 8/30/00 -0400, Cheenu Srinivasan wrote: >MPLS/TE WG members, > > This message is in response to the recent introduction >of the draft entitled, "draft-kompella-mpls-te-mib-00.txt" to >the TE WG and the debate which followed. Since no consensus could >be reached in the TE WG as to whether or not to adopt this draft, >the TE WG chair felt that this work was still important, and as such >has directed the author of this draft and the authors of the >MPLS-TE-MIB to work out a consensus for folding-in the salient >portions of the draft into the MPLS-TE-MIB. We have done so, and >below you will find the fruits of our labor. We will wait for the >feedback of the working groups before posting a revised version of >MPLS-TE-MIB incorporating these changes. As the WG chair in question, I would like to point out two things: a) my message to tom was not from "lack of consensus", it was an attempt to redirect his efforts away from "proprietary" and stylistic complaints to an exploration of how a combination of the two mibs might be done, and what would be the impact for implementors and operators (the last part has not been addressed). It was not framed as the solution, in fact I made it clear that it should not be thought of that way. b) in terms of consensus, there were two compelling arguments - merge, as we can't have two mibs - adopt kireeti's as it has all the right information w/ minimal added complexity The issue of complexity is an obvious one, as there have been discussions around "minimal implementations" or "conformance relaxation" or "non-conformant implementations". Some have also pointed out that having two documents really is not that bad of a thing as they will both tie into the mib structure independently. I believe the best thing to do is to accept kireeti's draft as a te-wg item, as it has both running code and rough (very) consensus behind it. The mpls wg mib currently does not have the right focus for the te-wg and all folding kireeti's draft into it does (from the standpoint of someone who only needs access to the information in kireeti's) is add complexity. It is important that the operational community has a way to monitor TE networks, and right now, draft-kompella-mpls-te-mib-00.txt is the best starting place for that. regards, Jim > Tom Nadeau > Kireeti Kompella > Cheenu Srinivasan > Arun Vishwanathan > >--------------------------------------------------------------------------------------- > > > 1. Two scalars to indicate the number of configured and > active tunnels: mplsConfiguredTunnels and mplsActiveTunnels. An > "active" tunnel denotes an mplsTunnelEntry with > mplsTunnelOperStatus = Up. A "configured" tunnel denotes an > mplsTunnelEntry whose mplsTunnelRowStatus is "active". > > 2. The addition of a new performance table which AUGMENTS > the mpslTunnelTable which includes the following > attributes: > > mplsTunnelPerfPackets OBJECT-TYPE > SYNTAX Counter32 > > mplsTunnelHCPerfPackets OBJECT-TYPE > SYNTAX Counter64 > > mplsTunnelErrors OBJECT-TYPE > SYNTAX Counter32 > > mplsTunnelPerfBytes OBJECT-TYPE > SYNTAX Counter32 > > mplsTunnelHCPerfBytes OBJECT-TYPE > SYNTAX Counter64 > > 3. The following objects will be added to the tunnelTable > to allow for further monitoring of the state > of the tunnel once it is configured. > > mplsTunnelPrimaryTimeUp TimeStamp, > mplsTunnelPathChanges Counter32, > mplsTunnelLastPathChange TimeStamp, > mplsTunnelCreationTime TimeStamp, > mplsTunnelStateTransitions Unsigned32, > mplsTunnelEgressLSRId Unsigned32, > > A path change is when the current active path (over which > packets are being forwarded) changes to another path. > > 4. The addition of a new table called mplsTunnelCHopTable > which lists the computed HOPs for a tunnel path. > > 5. We will enhance the mplsTunnelHopStrictOrLoose object > to change its name to mplsTunnelHopType. This object > will become an enumeration of { strict, loose }. > > 6. A new bit will be added to the mplsTunnelSessionAttribute > called ComputePath. This bit instructs the LSR to > use Constraint-based Routing to compute the actual path to > be traversed by this tunnel instance. > > 7. Resource class affinity attributes associated with a traffic > tunnel can be used to specify the class of resources which are > to be explicitly included or excluded from the path of the > traffic > trunk. These are policy attributes which can be used to impose > additional constraints on the path traversed by a given traffic > trunk. > > Three new objects shall be added to the tunnelEntry: > > mplsTunnelIncludeAnyAffinity OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A link satisfies the include-any constraint iff the > constraint is zero, > or the link and the constraint have a resource class in common." > REFERENCE "See section section 5.6.3 of RFC 2702." > > mplsTunnelIncludeAllAffinity OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A link satisfies the include-all constraint if and only if the > link > contains all of the administrative groups specified in the > constraint." > REFERENCE "RFC 2702, section 5.6.3." > > mplsTunnelExcludeAllAffinity OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A link satisfies the exclude constraint if and only if the > link contains none of the administrative groups specified in > the constraint." > REFERENCE "RFC 2702, section 5.6.3." > > 8. A scalar which will denote which type(s) of TE distribution > protocol(s) > is(are) in use by the LSR. > > mplsTunnelTEDistProto OBJECT-TYPE > SYNTAX BITS { other (0), ospf(1), isis (2) } > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The traffic engineering distribution protocol(s) used by this > LSR. Note that > an LSR may support more than one distribution protocol > simultaneously." > >--------------------------------------------------------------------------------------- > From owner-mpls@UU.NET Thu Sep 7 10:27:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16894 for ; Thu, 7 Sep 2000 10:27:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfpx14526; Thu, 7 Sep 2000 14:27:26 GMT Received: by mail-control.mail.uu.net id QQjfpx27668 for mpls-outgoing; Thu, 7 Sep 2000 14:26:50 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfpx27663 for ; Thu, 7 Sep 2000 14:26:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfpx07020 for ; Thu, 7 Sep 2000 10:26:17 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjfpx28024 for ; Thu, 7 Sep 2000 14:26:16 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA10698 for ; Thu, 7 Sep 2000 07:26:36 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA29179 for mpls@uu.net; Thu, 7 Sep 2000 10:26:15 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfoi23111 for ; Thu, 7 Sep 2000 04:09:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfoi22224 for ; Thu, 7 Sep 2000 00:09:47 -0400 (EDT) Received: from zsulink.zsu.edu.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: zsulink.zsu.edu.cn [202.116.64.1]) id QQjfoi13964 for ; Thu, 7 Sep 2000 04:09:43 GMT Received: from yulu ([202.116.78.73]) by zsulink.zsu.edu.cn (8.10.0/8.10.0) with SMTP id e87493w26785 for ; Thu, 7 Sep 2000 12:09:03 +0800 (CST) Message-ID: <01ef01c01881$cbb41b40$494e74ca@yulu.zsu.edu.cn> From: "yulu" To: Subject: mpls simulator reqired Date: Thu, 7 Sep 2000 12:11:45 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EA_01C018C4.CA31ECA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01EA_01C018C4.CA31ECA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, =20 Do u know where I can find simulator for mpls with multicast,Please = respond with URLs, Thank you in advance! Regards lucy ------=_NextPart_000_01EA_01C018C4.CA31ECA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
   
   Do u know where I can = find=20 simulator for mpls with multicast,Please respond with URLs,

Thank = you in=20 advance!

Regards
lucy

------=_NextPart_000_01EA_01C018C4.CA31ECA0-- From owner-mpls@UU.NET Thu Sep 7 10:27:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16907 for ; Thu, 7 Sep 2000 10:27:43 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfpx29610; Thu, 7 Sep 2000 14:27:42 GMT Received: by mail-control.mail.uu.net id QQjfpx27688 for mpls-outgoing; Thu, 7 Sep 2000 14:27:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfpx27673 for ; Thu, 7 Sep 2000 14:26:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfpx07164 for ; Thu, 7 Sep 2000 10:26:52 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfpx13975 for ; Thu, 7 Sep 2000 14:26:52 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA23337 for ; Thu, 7 Sep 2000 07:27:11 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA29187 for mpls@uu.net; Thu, 7 Sep 2000 10:26:50 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfom29647 for ; Thu, 7 Sep 2000 05:00:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfom05338; Thu, 7 Sep 2000 01:00:54 -0400 (EDT) Received: from roam.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [195.149.150.42]) id QQjfom04726; Thu, 7 Sep 2000 05:00:54 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Wto4-0006xo-00; Thu, 07 Sep 2000 07:01:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Kireeti Kompella Cc: jboyle@Level3.net, mpls@UU.NET, te-wg@UU.NET Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt References: <200009062310.QAA07680@kummer.juniper.net> Message-Id: Date: Thu, 07 Sep 2000 07:01:00 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I will re-issue the draft as a TE WG draft. thank you. this became non-productive a while ago. fyi, keith has comments just waiting to drop on you. :-) randy From owner-mpls@UU.NET Thu Sep 7 10:28:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16937 for ; Thu, 7 Sep 2000 10:28:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfpx16091; Thu, 7 Sep 2000 14:28:43 GMT Received: by mail-control.mail.uu.net id QQjfpx27760 for mpls-outgoing; Thu, 7 Sep 2000 14:28:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfpx27739 for ; Thu, 7 Sep 2000 14:28:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfpx07351 for ; Thu, 7 Sep 2000 10:27:49 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfpx14723 for ; Thu, 7 Sep 2000 14:27:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA23841 for ; Thu, 7 Sep 2000 07:27:52 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA29199 for mpls@uu.net; Thu, 7 Sep 2000 10:27:32 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfot26071 for ; Thu, 7 Sep 2000 06:51:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfot18530 for ; Thu, 7 Sep 2000 02:51:22 -0400 (EDT) Received: from roam.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: randy.workshop.sigz.net [195.149.150.111]) id QQjfot16904 for ; Thu, 7 Sep 2000 06:50:52 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13WvWM-000737-00; Thu, 07 Sep 2000 08:50:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Robert Raszuk Cc: Greg Ketell , Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6A9E5.1939914C@adn.alcatel.com> <4.3.2.7.2.20000906212856.0170b060@localhost> <39B72D73.C5B6EE29@cisco.com> Message-Id: Date: Thu, 07 Sep 2000 08:50:50 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > That is not too say that I personely like hub and spoke. In fact I do > agree with you that full mesh is the way to go and mpls-vpns easily > allow it. while i may agree with you technically. enterprises are used to it, and may be slow to make the cultural change. so i expect customers to be in a common process of evolving reconfiguration. randy From owner-mpls@UU.NET Thu Sep 7 10:29:25 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16975 for ; Thu, 7 Sep 2000 10:29:24 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfpx17020; Thu, 7 Sep 2000 14:29:24 GMT Received: by mail-control.mail.uu.net id QQjfpx27839 for mpls-outgoing; Thu, 7 Sep 2000 14:28:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfpx27818 for ; Thu, 7 Sep 2000 14:28:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfpx15437 for ; Thu, 7 Sep 2000 10:28:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfpx15852 for ; Thu, 7 Sep 2000 14:28:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA24496 for ; Thu, 7 Sep 2000 07:28:51 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA29218 for mpls@uu.net; Thu, 7 Sep 2000 10:28:31 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfpf12010 for ; Thu, 7 Sep 2000 09:54:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfpf07779 for ; Thu, 7 Sep 2000 05:54:14 -0400 (EDT) Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjfpf07239 for ; Thu, 7 Sep 2000 09:53:59 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 10:53:41 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA103@monk.datcon.co.uk> From: Adrian Farrel To: Paul Tasillo , "mpls@UU. net" Subject: RE: MPLS Mibs in production code Date: Thu, 7 Sep 2000 10:53:42 +0100 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 Data Connection's portable MPLS software has very strong MIB support including the TE MIB, LSR MIB and LDP MIB, which has been available from the first release. Our MIB support is, of course, continually evolving to track the developing MIB drafts and to add support for features in and extensions to the signaling drafts where they are not covered by the MIB drafts. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Paul Tasillo [mailto:Paul.tasillo@tivoli.com] >Sent: Wednesday, September 06, 2000 8:02 PM >To: mpls@UU. net >Subject: MPLS Mibs in production code > > >Aside from Cisco, are there any other vendors that have >support for any of >the MPLS MIBs in production (ie. publically available today)? > >Thanks in advance, >Paul > > From owner-mpls@UU.NET Thu Sep 7 10:29:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16986 for ; Thu, 7 Sep 2000 10:29:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfpx01890; Thu, 7 Sep 2000 14:29:49 GMT Received: by mail-control.mail.uu.net id QQjfpx27842 for mpls-outgoing; Thu, 7 Sep 2000 14:28:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfpx27809 for ; Thu, 7 Sep 2000 14:28:37 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfpx07532 for ; Thu, 7 Sep 2000 10:28:29 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfpx15191 for ; Thu, 7 Sep 2000 14:27:58 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA24094 for ; Thu, 7 Sep 2000 07:28:17 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA29205 for mpls@uu.net; Thu, 7 Sep 2000 10:27:57 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfoy24583 for ; Thu, 7 Sep 2000 08:13:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfoy27784; Thu, 7 Sep 2000 04:13:18 -0400 (EDT) Received: from mail1.noc.ntt.co.jp by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.noc.ntt.co.jp [210.163.32.53]) id QQjfoy28038; Thu, 7 Sep 2000 08:13:17 GMT Received: from mail1.noc.west.ntt.co.jp (mail1.noc.west.ntt.co.jp) by mail1.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id RAA12434; Thu, 7 Sep 2000 17:13:14 +0900 (JST) Received: from indigo.hq.west.ntt.co.jp by mail1.noc.west.ntt.co.jp (8.9.3/3.7W) id RAA07237; Thu, 7 Sep 2000 17:13:13 +0900 (JST) Received: from tiger.rdc.west.ntt.co.jp (plum.hq.west.ntt.co.jp [10.56.1.13]) by indigo.hq.west.ntt.co.jp (8.9.3+3.2W/3.7W00082113) with ESMTP id RAA26061; Thu, 7 Sep 2000 17:09:25 +0900 (JST) Received: from m ([10.56.90.38]) by tiger.rdc.west.ntt.co.jp (8.9.1a/3.7WNTT_WEST_RDC_1.0) with SMTP id RAA21109; Thu, 7 Sep 2000 17:13:01 +0900 (JST) Message-Id: <4.1-J.20000907165636.0144bed0@10.56.75.212> X-Sender: m.kitamura@pop.rdc.west.ntt.co.jp Reply-To: m.kitamura@rdc.west.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1-J Date: Thu, 07 Sep 2000 17:15:08 +0900 To: mpls@UU.NET, te-wg@UU.NET From: Masakazu Kitamura Subject: Help me, please Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I know that many routers has a function mapping label based destination address information, when the router forwards packets at Edge router. Please tell me if you know that there is the router that has a function mapping label based Policy-based routing information at Edge router, someone? $B!d!d!d!d!d!d!d(B NTT$B@>F|K\!!8&5f3+H/%;%s%?(B $B%M%C%H%o!<%/%7%9%F%`3+H/C4Ev(B $BKLB; Thu, 7 Sep 2000 11:07:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqa03114; Thu, 7 Sep 2000 15:07:27 GMT Received: by mail-control.mail.uu.net id QQjfqa12038 for mpls-outgoing; Thu, 7 Sep 2000 15:06:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfqa12026 for ; Thu, 7 Sep 2000 15:06:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqa22771; Thu, 7 Sep 2000 11:06:36 -0400 (EDT) Received: from almso1.proxy.att.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQjfqa02347; Thu, 7 Sep 2000 15:06:36 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id LAA18431; Thu, 7 Sep 2000 11:06:35 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id LAA25812; Thu, 7 Sep 2000 11:05:08 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Sep 2000 11:06:27 -0400 Message-ID: <1B08859602C8D211B66F0000C0769CFA0223EFA5@njc240po03.mt.att.com> From: "Fang, Luyuan, ALSVC" To: "'Thomas D. Nadeau'" , mpls@UU.NET, te-wg@UU.NET Subject: RE: Consensus for draft-kompella-mpls-te-mib-00.txt Date: Thu, 7 Sep 2000 11:06:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I would still support the third option: - merge them and move the merged one onto the standards track. Many networks, including ours are in multi-vendor environment today. It would increase the complexity even more if we have to deal with multi-MIBs for each new technology, on top of the multi-vendor, multi-service issues. Thanks, Luyuan Fang AT&T IP Network Architecture -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, September 06, 2000 7:33 PM To: mpls@UU.NET; te-wg@UU.NET Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt I was going to send this out just before I saw Jim's last message and replied, so please excuse the misorder. Jim and I have been having some offline discussions about the two MIBs in question (Kireeti's and the MPLS-TE-MIB), and perceive several options: - pick one (which?) and let it move onto the standards track - move both separately onto the standards track - merge them and move the merged one onto the standards track Arun, Cheenu and I understood that the third option was being requested, and hence merged the MIBs and sent out the email of Wed, 30 Aug 2000 16:06:19 -0400 concerning that activity. However, I'm not sure that I have actually heard the working group's viewpoint or consensus on this, and would like a straw poll. Could you please reply to the list with your opinion on the above, even if only to say "I don't have a strong opinion"? Thank you, --Tom From owner-mpls@UU.NET Thu Sep 7 11:09:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18056 for ; Thu, 7 Sep 2000 11:09:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqa04669; Thu, 7 Sep 2000 15:08:58 GMT Received: by mail-control.mail.uu.net id QQjfqa12256 for mpls-outgoing; Thu, 7 Sep 2000 15:08:36 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfqa12251 for ; Thu, 7 Sep 2000 15:08:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqa15337 for ; Thu, 7 Sep 2000 11:08:22 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfqa04073 for ; Thu, 7 Sep 2000 15:08:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA26809 for mpls@uu.net; Thu, 7 Sep 2000 11:08:21 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfqa12134 for ; Thu, 7 Sep 2000 15:07:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqa15212 for ; Thu, 7 Sep 2000 11:07:41 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfqa17830 for ; Thu, 7 Sep 2000 15:07:40 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA22142; Thu, 7 Sep 2000 08:07:59 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA11714; Thu, 7 Sep 2000 08:07:39 -0700 (PDT) Message-ID: <39B7B02A.177229A@cisco.com> Date: Thu, 07 Sep 2000 08:11:38 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "D'Albenzio Raffaele" CC: "'mpls@uu.net'" Subject: Re: CE IP address References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes you can and you will have problems as using duplicate addresses in the same logical network may not be a good idea. R. > D'Albenzio Raffaele wrote: > > I have a question about draft-rosen-rfc2547bis-02 > > In section 12 he says that I can assign to a CE router an address coming > from SP address space or VPN address space. > If the SP want to manage the CE then he must assing to CE an address coming > from the address space of SP. > > The question is: if the address space of the SP is a private address space > (e.g 10.x.x.x) and if > the address assigned to the CE is equal to the address assigned to a router > or a client of the > customer VPN (that also have a private address space 10.x.x.x), can I have > any problem of address overlapping? > > Thank you, > Raffaele. From owner-mpls@UU.NET Thu Sep 7 11:14:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18250 for ; Thu, 7 Sep 2000 11:14:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqa10080; Thu, 7 Sep 2000 15:14:50 GMT Received: by mail-control.mail.uu.net id QQjfqa12615 for mpls-outgoing; Thu, 7 Sep 2000 15:14:15 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqa12610 for ; Thu, 7 Sep 2000 15:14:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqa24339 for ; Thu, 7 Sep 2000 11:14:03 -0400 (EDT) Received: from ns1.arch.bellsouth.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2]) id QQjfqa23421 for ; Thu, 7 Sep 2000 15:14:03 GMT Received: from SARTHE ([205.152.173.69]) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) with SMTP id LAA25645 for ; Thu, 7 Sep 2000 11:14:03 -0400 (EDT) From: "Christian Kuhtz" To: "'mpls wg'" Subject: RE: ISPs offering VPN service Date: Thu, 7 Sep 2000 11:16:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > That is not too say that I personely like hub and spoke. In fact I do > > agree with you that full mesh is the way to go and mpls-vpns easily > > allow it. > > while i may agree with you technically. enterprises are used to it, and may > be slow to make the cultural change. so i expect customers to be in a > common process of evolving reconfiguration. I'm lost with this argumentation. In MPLS VPNs, default is that traffic starts to automatically flow shortest path/fully meshed by the very nature of it. Basically, all sites of a given customer just attach to a common net. So, that said, what evolution is there for customers to go thru? No "evolving reconfiguration"... But, if you really want them to, you can just make MPLS VPNs look like hub & spoke, why you would ever want to force that inside the vpn (you can always do it on a TE level regardless, if you desire to) escapes me, but it is possible. Cheers, Chris -- Christian Kuhtz, Sr. Network Architect Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From owner-mpls@UU.NET Thu Sep 7 11:34:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19000 for ; Thu, 7 Sep 2000 11:34:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqc26250; Thu, 7 Sep 2000 15:34:07 GMT Received: by mail-control.mail.uu.net id QQjfqc14815 for mpls-outgoing; Thu, 7 Sep 2000 15:33:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfqc14804 for ; Thu, 7 Sep 2000 15:33:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqc20305 for ; Thu, 7 Sep 2000 11:33:12 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjfqc25509 for ; Thu, 7 Sep 2000 15:33:12 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e87FXA404189; Thu, 7 Sep 2000 11:33:10 -0400 (EDT) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA54211; Thu, 7 Sep 2000 11:33:42 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200009071533.LAA54211@curtis-lt.avici.com> To: neil.2.harrison@bt.com cc: curtis@avici.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Info about mpls-vpn In-reply-to: Your message of "Thu, 07 Sep 2000 08:17:42 BST." Date: Thu, 07 Sep 2000 11:33:41 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk Neil, I just included the parts of your message that I wanted to clarify. btw- We should probably us the terminology in draft-kompella-mpls-optical-00.txt (PSC, etc) rather than inner and outer or upper and lower. In message , nei l.2.harrison@bt.com writes: > Curtis observered: > > If you are running BGP/VPN inside LDP, the same improvement would > > apply to LDP or LDP inside aggregate TE tunnels. Recovering a smaller > > number of TE tunnels should be easier than recovering a much larger > > number of LDP label mappings. > [Harrison,N,Neil,INC1 X] This is the key point Curtis. From our > experience in other technologies we have concluded that multiple levels of > restoration are not a good thing. Its better (i) to minimise the number of > nested technologies (for lots of reasons, but here let's just consider > failures and restoration wrt MPLS LSPs) and (ii) have fast bottom-level > (coarse) transport restoration with slower top-level (fine) transport > restoration. Now, since LSPs can be nested and they can also be provided by > several LDP-type mechanisms (I am being generic here, and covering > vanilla-LDP, RSVP-LDP, CR-LDP and BGP4-LDP when I say 'LDP-type' as > techniques for label distribution) there are 2 variables: The edge-to-edge tunnels should not see a failure. The failure within the core should be handled by the TE tunnel within the core and should be transparent to the edge-to-edge tunnels. > From the last point, and noting that one would want the higher level > LSPs to be more 'defect duration tolerant' than the lower LSPs, I am > wondering if all the possible client/server nested LDP-type relationships > have been considered......simply so that higher level LSPs don't start > reacting to seeing failures before lower level LSPs have had chance to > react? The lower level LSPs in effect do not get notification that a break has occurred because they use the PSC tunnel which remains up. The IGP will flood the link change of the core link that went down, but the lower level LSP does not know which set of links the PSC tunnel uses and does not see any withdrawl of the PSC adjacency as long as it has a backup or it is rerouted before the time threshhold to withdraw it. The IGP flood indicating a PSC is withdrawn and the resv-tear for tunnels inside a PSC should be suppressed for some configured time interval by the ingress to the PSC tunnel. Regards, Curtis From owner-mpls@UU.NET Thu Sep 7 11:54:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19430 for ; Thu, 7 Sep 2000 11:54:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqd26107; Thu, 7 Sep 2000 15:54:41 GMT Received: by mail-control.mail.uu.net id QQjfqd16120 for mpls-outgoing; Thu, 7 Sep 2000 15:54:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfqd16111 for ; Thu, 7 Sep 2000 15:54:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqd01747 for ; Thu, 7 Sep 2000 11:54:01 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfqd25455 for ; Thu, 7 Sep 2000 15:54:01 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA04717 for mpls@uu.net; Thu, 7 Sep 2000 11:54:00 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfqd16094 for ; Thu, 7 Sep 2000 15:53:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqd23919 for ; Thu, 7 Sep 2000 11:53:17 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfqd24894 for ; Thu, 7 Sep 2000 15:53:17 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA28572; Thu, 7 Sep 2000 08:53:35 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA11718; Thu, 7 Sep 2000 08:53:15 -0700 (PDT) Message-ID: <39B7BADA.F0EF0AE4@cisco.com> Date: Thu, 07 Sep 2000 08:57:14 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ramana V Gollamudi CC: Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6B04F.9A6747F8@alcatel.com> <39B6C692.A70F883D@cisco.com> <39B7B2E0.4E6FE220@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ramana, Now we are moving this thread to a deployment arena which I am always not clear if this is the right mailing list to continue on ... but well if the subject is interesting and nothing is vendor specific we can just proceed until somebody says "stop it". > Robert, > > Is the assumption that most of a given VPN routes will be fed into few PE boxes to make > useful aggregation feasible at that point? In fact a few production networks - especially where the aggregation is really needed (DSL, cable access lines) into mpls-vpns are using this method of aggregation. The drawback is suboptimal routing but well nothing comes for free. > What happens if the VPN feeds a lot of routes at > different points into different PE edge boxes ( for example - each CE is a 7-Eleven feeding > only few routes)? The level of aggregation possible at given PE box may not be much in this > case. Where does aggregation happen in such a case? Or is this scenario unlikely and hence > needed not be solved? This is a likely scenario and you are correct you can not aggregate much. The good news is that if those are branches like 7-eleven they usually have one subnet so even having thousands of them (no matter to which vpns they belong) is not so scary. Much more scary are enterprises with screwed addressing giving you 100,000 routes from multiple points that you can not summarize. The plane mpls-vpn technology will still work as long as you have partitioned reflectors, and good enough routers as PEs. Of course for those cases (which by the way I only saw a few) you may also use Carrier's Carrier model, or even CCC/AToM/IPSec - all depending how big is given customer's mesh. In those examples there is no issue at all with the number of routes injected into your core. > In the leased line scenario, I am assuming that the VPN customer has insight into the VPN > topology and hence can connect his "leased lines or PVCs" in some type of order so as to > have points where aggregation is feasable. In the mpls/bgp case, the customer just connects > to service, which is good as it simplifies life for the VPN customer, but the provider needs > to solve this problem. Agreed. R. From owner-mpls@UU.NET Thu Sep 7 12:06:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19720 for ; Thu, 7 Sep 2000 12:06:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqe06063; Thu, 7 Sep 2000 16:06:20 GMT Received: by mail-control.mail.uu.net id QQjfqe29891 for mpls-outgoing; Thu, 7 Sep 2000 16:05:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqe29846 for ; Thu, 7 Sep 2000 16:05:47 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqe03952; Thu, 7 Sep 2000 12:05:40 -0400 (EDT) Received: from mail.makesys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.makesys.com [204.30.100.64]) id QQjfqe21547; Thu, 7 Sep 2000 16:05:09 GMT Received: from makesys.com (mlclient13 [204.30.100.103]) by mail.makesys.com (8.10.1/8.10.1) with ESMTP id e87G56I12947; Thu, 7 Sep 2000 12:05:06 -0400 (EDT) Message-ID: <39B7BCB1.1B417638@makesys.com> Date: Thu, 07 Sep 2000 12:05:05 -0400 From: Weigang Cao X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fang, Luyuan, ALSVC" CC: mpls@UU.NET, te-wg@UU.NET Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt References: <1B08859602C8D211B66F0000C0769CFA0223EFA5@njc240po03.mt.att.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Fang, Luyuan, ALSVC" wrote: > I would still support the third option: > - merge them and move the merged one onto the standards track. > So do I --I prefer merge them to one. I am working on network discovery& traffic collection project, one single TE-MIB is very helpful for discovery muti-vendor devices. Thanks, Weigang Cao Make System Inc, A Network Resource Planning Company > > Many networks, including ours are in multi-vendor environment today. It > would increase the complexity even more if we have to deal with multi-MIBs > for each new technology, on top of the multi-vendor, multi-service issues. > > Thanks, > > Luyuan Fang > AT&T > IP Network Architecture > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, September 06, 2000 7:33 PM > To: mpls@UU.NET; te-wg@UU.NET > Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt > > I was going to send this out just before I saw > Jim's last message and replied, so please excuse the > misorder. > > Jim and I have been having some offline discussions about the > two MIBs in question (Kireeti's and the MPLS-TE-MIB), and perceive > several options: > > - pick one (which?) and let it move onto the standards track > - move both separately onto the standards track > - merge them and move the merged one onto the standards track > > Arun, Cheenu and I understood that the third option was being > requested, > and hence merged the MIBs and sent out the email of Wed, 30 Aug 2000 > 16:06:19 -0400 > concerning that activity. However, I'm not sure that I have actually heard > the > working group's viewpoint or consensus on this, and would like a straw > poll. Could > you please reply to the list with your opinion on the above, even if only > to say "I don't have a strong opinion"? > > Thank you, > > --Tom From owner-mpls@UU.NET Thu Sep 7 12:17:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19871 for ; Thu, 7 Sep 2000 12:17:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqf02305; Thu, 7 Sep 2000 16:17:48 GMT Received: by mail-control.mail.uu.net id QQjfqf01572 for mpls-outgoing; Thu, 7 Sep 2000 16:17:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqf01561 for ; Thu, 7 Sep 2000 16:17:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqf06022 for ; Thu, 7 Sep 2000 12:16:46 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfqf14990 for ; Thu, 7 Sep 2000 16:16:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA08409 for mpls@uu.net; Thu, 7 Sep 2000 12:16:41 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqf01472 for ; Thu, 7 Sep 2000 16:16:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqf05812; Thu, 7 Sep 2000 12:15:59 -0400 (EDT) Received: from tnnt3.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQjfqf14017; Thu, 7 Sep 2000 16:15:29 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 12:19:34 -0400 Message-ID: From: Cheenu Srinivasan To: "'Jim Boyle'" , mpls@UU.NET, te-wg@UU.NET Subject: RE: Consensus for draft-kompella-mpls-te-mib-00.txt Date: Thu, 7 Sep 2000 12:19:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C018E7.692B7D86" 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_01C018E7.692B7D86 Content-Type: text/plain; charset="iso-8859-1" > I believe the best thing to do is to accept kireeti's draft > as a te-wg > item, as it has both running code and rough (very) consensus behind > it. The mpls wg mib currently does not have the right focus > for the te-wg > and all folding kireeti's draft into it does (from the standpoint of > someone who only needs access to the information in kireeti's) is add > complexity. It is important that the operational community > has a way to > monitor TE networks, and right now, > draft-kompella-mpls-te-mib-00.txt is > the best starting place for that. Jim, As far as I can see we do not have any kind of working group consensus to make Kireeti's MIB a working group document. There were at least as many opinions to fold in the functionality from Kireeti's MIB into the existing TE MIB but for some reason you have chosen to ignore this. Also, since we posted the email explaining the "consensus MIB" with these additions we have not heard any dissent over the last week. In my opinion the whole process of consensus driven decision making is getting rail-roaded. Cheenu > > regards, > > Jim > > > > > Tom Nadeau > > Kireeti Kompella > > Cheenu Srinivasan > > Arun Vishwanathan > > > >------------------------------------------------------------- > -------------------------- > > > > > > 1. Two scalars to indicate the number of configured and > > active tunnels: mplsConfiguredTunnels and > mplsActiveTunnels. An > > "active" tunnel denotes an mplsTunnelEntry with > > mplsTunnelOperStatus = Up. A "configured" tunnel > denotes an > > mplsTunnelEntry whose mplsTunnelRowStatus is "active". > > > > 2. The addition of a new performance table which AUGMENTS > > the mpslTunnelTable which includes the following > > attributes: > > > > mplsTunnelPerfPackets OBJECT-TYPE > > SYNTAX Counter32 > > > > mplsTunnelHCPerfPackets OBJECT-TYPE > > SYNTAX Counter64 > > > > mplsTunnelErrors OBJECT-TYPE > > SYNTAX Counter32 > > > > mplsTunnelPerfBytes OBJECT-TYPE > > SYNTAX Counter32 > > > > mplsTunnelHCPerfBytes OBJECT-TYPE > > SYNTAX Counter64 > > > > 3. The following objects will be added to the tunnelTable > > to allow for further monitoring of the state > > of the tunnel once it is configured. > > > > mplsTunnelPrimaryTimeUp TimeStamp, > > mplsTunnelPathChanges Counter32, > > mplsTunnelLastPathChange TimeStamp, > > mplsTunnelCreationTime TimeStamp, > > mplsTunnelStateTransitions Unsigned32, > > mplsTunnelEgressLSRId Unsigned32, > > > > A path change is when the current active path (over which > > packets are being forwarded) changes to another path. > > > > 4. The addition of a new table called mplsTunnelCHopTable > > which lists the computed HOPs for a tunnel path. > > > > 5. We will enhance the mplsTunnelHopStrictOrLoose object > > to change its name to mplsTunnelHopType. This object > > will become an enumeration of { strict, loose }. > > > > 6. A new bit will be added to the > mplsTunnelSessionAttribute > > called ComputePath. This bit instructs the LSR to > > use Constraint-based Routing to compute the > actual path to > > be traversed by this tunnel instance. > > > > 7. Resource class affinity attributes associated > with a traffic > > tunnel can be used to specify the class of > resources which are > > to be explicitly included or excluded from the > path of the > > traffic > > trunk. These are policy attributes which can be > used to impose > > additional constraints on the path traversed by > a given traffic > > trunk. > > > > Three new objects shall be added to the tunnelEntry: > > > > mplsTunnelIncludeAnyAffinity OBJECT-TYPE > > SYNTAX Integer32 > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A link satisfies the include-any constraint iff the > > constraint is zero, > > or the link and the constraint have a resource > class in common." > > REFERENCE "See section section 5.6.3 of RFC 2702." > > > > mplsTunnelIncludeAllAffinity OBJECT-TYPE > > SYNTAX Integer32 > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A link satisfies the include-all constraint if > and only if the > > link > > contains all of the administrative groups > specified in the > > constraint." > > REFERENCE "RFC 2702, section 5.6.3." > > > > mplsTunnelExcludeAllAffinity OBJECT-TYPE > > SYNTAX Integer32 > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A link satisfies the exclude constraint if and > only if the > > link contains none of the administrative groups > specified in > > the constraint." > > REFERENCE "RFC 2702, section 5.6.3." > > > > 8. A scalar which will denote which type(s) of TE > distribution > > protocol(s) > > is(are) in use by the LSR. > > > > mplsTunnelTEDistProto OBJECT-TYPE > > SYNTAX BITS { other (0), ospf(1), isis (2) } > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The traffic engineering distribution protocol(s) > used by this > > LSR. Note that > > an LSR may support more than one distribution protocol > > simultaneously." > > > >------------------------------------------------------------- > -------------------------- > > > > ------_=_NextPart_001_01C018E7.692B7D86 Content-Type: text/html; charset="iso-8859-1"

> I believe the best thing to do is to accept kireeti's draft
> as a te-wg
> item, as it has both running code and rough (very) consensus behind
> it.  The mpls wg mib currently does not have the right focus
> for the te-wg
> and all folding kireeti's draft into it does (from the standpoint of
> someone who only needs access to the information in kireeti's) is add
> complexity. It is important that the operational community
> has a way to
> monitor TE networks, and right now,
> draft-kompella-mpls-te-mib-00.txt is
> the best starting place for that.

Jim,

As far as I can see we do not have any kind of working group consensus
to make Kireeti's MIB a working group document. There were at least
as many opinions to fold in the functionality from Kireeti's
MIB into the existing TE MIB but for some reason you have chosen to
ignore this. Also, since we posted the email explaining the "consensus
MIB" with these additions we have not heard any dissent over the last week.
In my opinion the whole process of consensus driven decision making is
getting rail-roaded.

Cheenu

>
> regards,
>
> Jim
>
>
>
> >         Tom Nadeau
> >         Kireeti Kompella
> >         Cheenu Srinivasan
> >         Arun Vishwanathan
> >
> >-------------------------------------------------------------
> --------------------------
> >
> >
> >         1. Two scalars to indicate the number of configured and
> >            active tunnels: mplsConfiguredTunnels and
> mplsActiveTunnels. An
> >            "active" tunnel denotes an mplsTunnelEntry with
> >            mplsTunnelOperStatus = Up. A "configured" tunnel
> denotes an
> >            mplsTunnelEntry whose mplsTunnelRowStatus is "active".
> >
> >         2. The addition of a new performance table which AUGMENTS
> >            the mpslTunnelTable which includes the following
> >            attributes:
> >
> >         mplsTunnelPerfPackets OBJECT-TYPE
> >         SYNTAX     Counter32
> >
> >         mplsTunnelHCPerfPackets OBJECT-TYPE
> >         SYNTAX     Counter64
> >
> >         mplsTunnelErrors OBJECT-TYPE
> >         SYNTAX  Counter32
> >
> >         mplsTunnelPerfBytes OBJECT-TYPE
> >         SYNTAX     Counter32
> >
> >         mplsTunnelHCPerfBytes OBJECT-TYPE
> >         SYNTAX     Counter64
> >
> >         3. The following objects will be added to the tunnelTable
> >            to allow for further monitoring of the state
> >            of the tunnel once it is configured.
> >
> >                 mplsTunnelPrimaryTimeUp    TimeStamp,
> >                 mplsTunnelPathChanges      Counter32,
> >                 mplsTunnelLastPathChange   TimeStamp,
> >                 mplsTunnelCreationTime     TimeStamp,
> >                 mplsTunnelStateTransitions Unsigned32,
> >                 mplsTunnelEgressLSRId      Unsigned32,
> >
> >         A path change is when the current active path (over which
> >         packets are being forwarded) changes to another path.
> >
> >         4. The addition of a new table called mplsTunnelCHopTable
> >            which lists the computed HOPs for a tunnel path.
> >
> >         5. We will enhance the mplsTunnelHopStrictOrLoose object
> >            to change its name to mplsTunnelHopType. This object
> >            will become an enumeration of { strict, loose }.
> >
> >         6.  A new bit will be added to the
> mplsTunnelSessionAttribute
> >             called ComputePath. This bit instructs the LSR to
> >             use Constraint-based Routing to compute the
> actual path to
> >             be traversed by this tunnel instance.
> >
> >         7. Resource class affinity attributes associated
> with a traffic
> >            tunnel can be used to specify the class of
> resources which are
> >            to be explicitly included or excluded from the
> path of the
> > traffic
> >            trunk. These are policy attributes which can be
> used to impose
> >            additional constraints on the path traversed by
> a given traffic
> >            trunk.
> >
> >         Three new objects shall be added to the tunnelEntry:
> >
> >         mplsTunnelIncludeAnyAffinity OBJECT-TYPE
> >         SYNTAX          Integer32
> >         MAX-ACCESS      not-accessible
> >         STATUS          current
> >         DESCRIPTION
> >           "A link satisfies the include-any constraint iff  the
> > constraint is zero,
> >            or the link and the constraint have a resource
> class in common."
> >         REFERENCE "See section section 5.6.3 of RFC 2702."
> >
> >         mplsTunnelIncludeAllAffinity OBJECT-TYPE
> >         SYNTAX          Integer32
> >         MAX-ACCESS    not-accessible
> >         STATUS        current
> >         DESCRIPTION
> >           "A link satisfies the include-all constraint if
> and only if the
> > link
> >            contains all of the administrative groups
> specified in the
> > constraint."
> >         REFERENCE "RFC 2702, section 5.6.3."
> >
> >         mplsTunnelExcludeAllAffinity OBJECT-TYPE
> >         SYNTAX          Integer32
> >         MAX-ACCESS    not-accessible
> >         STATUS          current
> >         DESCRIPTION
> >           "A link satisfies the exclude constraint if and
> only if the
> >           link contains none of the administrative groups
> specified in
> >           the constraint."
> >         REFERENCE "RFC 2702, section 5.6.3."
> >
> >         8. A scalar which will denote which type(s) of TE
> distribution
> > protocol(s)
> >            is(are) in use by the LSR.
> >
> >         mplsTunnelTEDistProto OBJECT-TYPE
> >         SYNTAX      BITS { other (0), ospf(1), isis (2) }
> >         MAX-ACCESS    not-accessible
> >         STATUS        current
> >         DESCRIPTION
> >           "The traffic engineering distribution protocol(s)
> used by this
> > LSR. Note that
> >            an LSR may support more than one distribution protocol
> > simultaneously."
> >
> >-------------------------------------------------------------
> --------------------------
> >
>
>

------_=_NextPart_001_01C018E7.692B7D86-- From owner-mpls@UU.NET Thu Sep 7 12:47:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20643 for ; Thu, 7 Sep 2000 12:47:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqh07323; Thu, 7 Sep 2000 16:47:32 GMT Received: by mail-control.mail.uu.net id QQjfqh03508 for mpls-outgoing; Thu, 7 Sep 2000 16:47:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqh03503 for ; Thu, 7 Sep 2000 16:47:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqh11205 for ; Thu, 7 Sep 2000 12:47:04 -0400 (EDT) Received: from web3001.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web3001.mail.yahoo.com [204.71.202.164]) id QQjfqh29049 for ; Thu, 7 Sep 2000 16:47:03 GMT Received: (qmail 14759 invoked by uid 60001); 7 Sep 2000 16:47:03 -0000 Message-ID: <20000907164703.14758.qmail@web3001.mail.yahoo.com> Received: from [141.212.130.253] by web3001.mail.yahoo.com; Thu, 07 Sep 2000 09:47:03 PDT Date: Thu, 7 Sep 2000 09:47:03 -0700 (PDT) From: Jessica Yu Subject: Re: ISPs offering VPN service To: raszuk@cisco.com, Randy Bush Cc: mpls wg MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk --- Robert Raszuk wrote: > > > how will the pes perform? > > During my current deployment experience with > multiple customers there > was never an issue with the PE scaling. Why ? - > since I have never came > across any VPN site which would not fit to the PE. It would depend on how many VPNs a PE suports and how large each VPN is, and what kind of hardware used for PE in the deployment cases you mentioned. > So as long as this > condition holds when one PE get's full (I mean he > memory is getting full > or CPU for what ever reason is dying) one can easily > add another PE and > still grow easily. Yes, except adding more PEs means adding more PEs to the iBGP mesh or adding more burdens to Route Reflector if RR is used, which itself may need other mechanisms to reliefe burdens, as you stated below. > > Ok now depending what hardware/software you are > using you may get some > scaling limitations on vpnv4 reflector simply due to > the fact that in > some cases you may find end customers networks > messed up big time > without any hope for summarization. So what we can > do here is a few > things: reflector partitioning (based on RT value), > (including pushing > ORF to PEs), use router with more memory/cpu power > or even use zebra. ...... > > There are different ways to provide VPNs and all > have it's own usage. It > was said a lot of time but ipsec has slight issue > with overlay scheme > associated maintenance. Setting thousands of vpns > with nice tool may not > be an issue but reconfiguring it based on the > customer's open tickets is > a good job security for some time in the NOC. It's not necessary the case. Directory based VPN management tool is able to handle both building and reconfiguring ipsec based VPN in a more scalable way. There is at least one such product that I am aware of. Cheers! --jessica ===== __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Thu Sep 7 13:24:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21543 for ; Thu, 7 Sep 2000 13:24:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqj29316; Thu, 7 Sep 2000 17:24:41 GMT Received: by mail-control.mail.uu.net id QQjfqj18406 for mpls-outgoing; Thu, 7 Sep 2000 17:24:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfqj18395 for ; Thu, 7 Sep 2000 17:24:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqj10594; Thu, 7 Sep 2000 13:23:53 -0400 (EDT) Received: from force10networks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQjfqj28065; Thu, 7 Sep 2000 17:23:23 GMT Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 10:23:21 -0700 Message-ID: From: Arun Viswanathan To: "'Jim Boyle'" , mpls@UU.NET, te-wg@UU.NET Subject: RE: Consensus for draft-kompella-mpls-te-mib-00.txt Date: Thu, 7 Sep 2000 10:23:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="=_74e4be134776458ad8dad899e4dca1de" 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. --=_74e4be134776458ad8dad899e4dca1de Content-Type: text/plain; charset="iso-8859-1" > I believe the best thing to do is to accept kireeti's draft > as a te-wg > item, as it has both running code and rough (very) consensus behind > it. Jim, 'Very rough consensus' is obviously not rough consensus, and could very well mean no consensus :-) That certainly seems to be the case here. -arun --=_74e4be134776458ad8dad899e4dca1de Content-Type: text/html; charset="iso-8859-1"
 
 

> I believe the best thing to do is to accept kireeti's draft
> as a te-wg
> item, as it has both running code and rough (very) consensus behind
> it.    

Jim,
    'Very rough consensus' is obviously not rough consensus,
and could very well mean no consensus :-)
That certainly seems to be the case here.
 
-arun
 
--=_74e4be134776458ad8dad899e4dca1de-- From owner-mpls@UU.NET Thu Sep 7 13:33:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21792 for ; Thu, 7 Sep 2000 13:33:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqk06192; Thu, 7 Sep 2000 17:33:03 GMT Received: by mail-control.mail.uu.net id QQjfqk19333 for mpls-outgoing; Thu, 7 Sep 2000 17:32:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfqk19318 for ; Thu, 7 Sep 2000 17:32:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqk18649; Thu, 7 Sep 2000 13:32:05 -0400 (EDT) Received: from maplenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82]) id QQjfqk09294; Thu, 7 Sep 2000 17:32:04 GMT Received: from prasuncomp (farhad_pc [192.168.10.239]) by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id KAA06971; Thu, 7 Sep 2000 10:31:56 -0700 (PDT) Message-ID: <042501c018f1$d6bd77a0$ef0aa8c0@maplenetworks.com> From: "Sudhanshu Jain" To: "Arun Viswanathan" , , , "Thomas D. Nadeau" References: <071bc2912d16b792bf9ec10604a7906239b70b71@force10networks.com> Subject: draft-kompella-mpls-te-mib-00.txt Date: Thu, 7 Sep 2000 10:34:13 -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 Hi Arun, I am changing the subject line to avoid any confusion with current hot discussion on MIB merging. This mail also address the same issue, but to avoid any confusion with the other mail. Please see my inline comments. ----- Original Message ----- From: "Arun Viswanathan" To: "'Sudhanshu Jain'" ; ; ; "Thomas D. Nadeau" Sent: Wednesday, September 06, 2000 8:28 PM Subject: RE: Consensus for draft-kompella-mpls-te-mib-00.txt > > Sudhanshu, > > > I agree with your approach and here are my views to this effort. > > > > I would like to see single MIB addressing all related issue > > as it help to > > clear the confusion. > > > > IMHO, LSP info ( in this draft) is not specific to tunnel > > only and so there > > is no point them merging it with TE-MIB. Instead, it should > > be get augmented > > to mplsXCEntry in LSR MIB. > > I think the confusion is arising out of the use of the term LSP in > Kireeti's MIB to actually mean tunnels as defined in RSVP/CRLDP drafts > or as in MPLS-TE-MIB. So there are no objects in Kireeti's MIB that > need to go into the LSR MIB. > I think, tunnel MIB objects are present only on ingress LSR and to some extent to egress LSR. Please correct me, if I am wrong. As far the MPLS TE (Traffic Engineering) is concerned, it need to be performed at each hop not just at ingress and egress. So if this is the case, I think current MPLS-TE MIB is not the correct mib representing MPLS Traffic Engineering, as it address some TE aspects like session attribute etc for the configuration purpose at the head end of the tunnel only. On the other hand, objects like mplsLspAge, mplsLspTimeUp, mplsLspPrimaryTimeUp, mplsLspTransition, mplsPathPropertis etc. in Kireeti's mib need to be monitor at each hop. May be these objects should be addresses based on different index as oppose to mplsLspName as specified in Kireeti's MIB. Any comments ? > > > > Also, why do we have named draft-ietf-mpls-te-mib.txt as > > "TE-MIB"? IMHO, it > > should be Tunnel-MIB :)) > > We could have, but I doubt if that would have changed anything > with regard to this debate :-) > I think it will make the difference. Tunnel MIB is to address objects only at ingress (and egress) LSRs only. While TE-MIB should address issues for the whole path. Also, current subject of traffic engineering is very pre-mature in MPLS and it is better separate tunnel configuration from MPLS traffic engineering. Tunnel is a configurable entity while traffic engineering in MPLS domain should work on path not on tunnel. -Sudhanshu From owner-mpls@UU.NET Thu Sep 7 14:06:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22422 for ; Thu, 7 Sep 2000 14:06:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqm11229; Thu, 7 Sep 2000 18:06:47 GMT Received: by mail-control.mail.uu.net id QQjfqm04509 for mpls-outgoing; Thu, 7 Sep 2000 18:06:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfqm04477 for ; Thu, 7 Sep 2000 18:06:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqm18250 for ; Thu, 7 Sep 2000 14:05:54 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjfqm04265 for ; Thu, 7 Sep 2000 18:05:23 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 11:52:18 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE9CD@BGSLC02> From: Irwin Lazar To: "'yulu'" , mpls@UU.NET Subject: RE: mpls simulator reqired Date: Thu, 7 Sep 2000 11:52:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C018F4.5D4AFCFA" 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_01C018F4.5D4AFCFA Content-Type: text/plain; charset="gb2312" There are links to a few at http://www.mplsrc.com/vendor.shtml -----Original Message----- From: yulu [mailto:lucy_yu@163.net] Sent: Thursday, September 07, 2000 12:12 AM To: mpls@UU.NET Subject: mpls simulator reqired Hi, Do u know where I can find simulator for mpls with multicast,Please respond with URLs, Thank you in advance! Regards lucy ------_=_NextPart_001_01C018F4.5D4AFCFA Content-Type: text/html; charset="gb2312"
There are links to a few at http://www.mplsrc.com/vendor.shtml
-----Original Message-----
From: yulu [mailto:lucy_yu@163.net]
Sent: Thursday, September 07, 2000 12:12 AM
To: mpls@UU.NET
Subject: mpls simulator reqired

Hi,
   
   Do u know where I can find simulator for mpls with multicast,Please respond with URLs,

Thank you in advance!

Regards
lucy

------_=_NextPart_001_01C018F4.5D4AFCFA-- From owner-mpls@UU.NET Thu Sep 7 14:14:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22560 for ; Thu, 7 Sep 2000 14:14:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqm20564; Thu, 7 Sep 2000 18:14:33 GMT Received: by mail-control.mail.uu.net id QQjfqm05226 for mpls-outgoing; Thu, 7 Sep 2000 18:14:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqm05221 for ; Thu, 7 Sep 2000 18:14:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqm26904 for ; Thu, 7 Sep 2000 14:14:00 -0400 (EDT) Received: from turin.trillium.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: turin.trillium.com [38.187.146.197]) id QQjfqm19330 for ; Thu, 7 Sep 2000 18:13:29 GMT Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by turin.trillium.com (8.11.0/8.11.0) with ESMTP id e87IHlH20415; Thu, 7 Sep 2000 11:17:47 -0700 (PDT) Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id LAA09455; Thu, 7 Sep 2000 11:13:08 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 11:05:15 -0700 Message-ID: <8BBD33A986C5D311804000902719FF5D952C58@aega.trillium.com> From: Prem Shankar Sharma To: "'Alex Mondrus'" , "Kullberg, Alan" , "'Paul Tasillo'" , "mpls@UU. net" Cc: Prem Shankar Sharma Subject: RE: MPLS Mibs in production code Date: Thu, 7 Sep 2000 11:05:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Trillium's MPLS solution supports all three MIBs and they are available in the product being shipped: * LDP MIB * LSR MIB * TE MIB Thanks. Prem > -----Original Message----- > From: Alex Mondrus [mailto:alex.mondrus@ipoptical.com] > Sent: Wednesday, September 06, 2000 12:52 PM > To: Kullberg, Alan; 'Paul Tasillo'; mpls@UU. net > Subject: RE: MPLS Mibs in production code > > > IPOptical will support both > > http://www.ipoptical.com > > Alex Mondrus > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Kullberg, > Alan > Sent: Wednesday, September 06, 2000 3:26 PM > To: 'Paul Tasillo'; mpls@UU. net > Subject: RE: MPLS Mibs in production code > > > NetPlane supports the LDP MIB in the current shipping > version of our MPLS software. We will support the TE > and LSR MIBs at the end of September. > > Alan > > > -----Original Message----- > > From: Paul Tasillo [mailto:Paul.tasillo@tivoli.com] > > Sent: Wednesday, September 06, 2000 3:02 PM > > To: mpls@UU. net > > Subject: MPLS Mibs in production code > > > > > > Aside from Cisco, are there any other vendors that have > > support for any of > > the MPLS MIBs in production (ie. publically available today)? > > > > Thanks in advance, > > Paul > > > > > From owner-mpls@UU.NET Thu Sep 7 14:18:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22681 for ; Thu, 7 Sep 2000 14:18:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqn24757; Thu, 7 Sep 2000 18:18:02 GMT Received: by mail-control.mail.uu.net id QQjfqn05685 for mpls-outgoing; Thu, 7 Sep 2000 18:17:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfqn05672 for ; Thu, 7 Sep 2000 18:17:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqn27627 for ; Thu, 7 Sep 2000 14:17:05 -0400 (EDT) Received: from prue.eim.surrey.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQjfqn23288 for ; Thu, 7 Sep 2000 18:16:49 GMT Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13X6E5-0006e3-00; Thu, 07 Sep 2000 19:16:41 +0100 Date: Thu, 7 Sep 2000 19:16:35 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Prem Shankar Sharma cc: "mpls@UU. net" Subject: RE: MPLS Mibs in production code In-Reply-To: <8BBD33A986C5D311804000902719FF5D952C58@aega.trillium.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 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 7 Sep 2000, Prem Shankar Sharma wrote: > Trillium's MPLS solution please remind me: what was the problem, exactly? L. > supports all three MIBs and > they are available in the product being shipped: > * LDP MIB > * LSR MIB > * TE MIB > > Thanks. > Prem PGP From owner-mpls@UU.NET Thu Sep 7 14:18:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22705 for ; Thu, 7 Sep 2000 14:18:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqn25898; Thu, 7 Sep 2000 18:18:48 GMT Received: by mail-control.mail.uu.net id QQjfqn05758 for mpls-outgoing; Thu, 7 Sep 2000 18:18:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqn05726 for ; Thu, 7 Sep 2000 18:17:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqn27772; Thu, 7 Sep 2000 14:17:48 -0400 (EDT) Received: from force10networks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQjfqn24402; Thu, 7 Sep 2000 18:17:47 GMT Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 11:17:45 -0700 Message-ID: From: Arun Viswanathan To: "'Sudhanshu Jain'" , Arun Viswanathan , mpls@UU.NET, te-wg@UU.NET, "Thomas D. Nadeau" Subject: RE: draft-kompella-mpls-te-mib-00.txt Date: Thu, 7 Sep 2000 11:17:45 -0700 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 Sudhanshu, > I think, tunnel MIB objects are present only on ingress LSR > and to some > extent to egress LSR. Please correct me, if I am wrong. When you say tunnel MIB, I am assuming you mean the current MPLS-TE-MIB. The initial intent of the MIB was to have the objects only at head-end and tail-end of the tunnel. But its scope got extended in the last few revs so that the objects may be optionally maintained at the intermediate nodes. > > As far the MPLS TE (Traffic Engineering) is concerned, it need to be > performed at each hop not just at ingress and egress. So if > this is the See above. The MPLS-TE-MIB objects are mainly for the head-end and may optionally be maintained at subsequent nodes. > case, I think current MPLS-TE MIB is not the correct mib > representing MPLS > Traffic Engineering, as it address some TE aspects like > session attribute > etc for the configuration purpose at the head end of the tunnel only. > > On the other hand, objects like mplsLspAge, mplsLspTimeUp, > mplsLspPrimaryTimeUp, mplsLspTransition, mplsPathPropertis > etc. in Kireeti's > mib need to be monitor at each hop. Objects in Kireeti's MIB are for the head-end of a tunnel only. This is my understanding from my discussions with Kireeti. > > May be these objects should be addresses based on different > index as oppose > to mplsLspName as specified in Kireeti's MIB. > > Any comments ? > > > > > > > Also, why do we have named draft-ietf-mpls-te-mib.txt as > > > "TE-MIB"? IMHO, it > > > should be Tunnel-MIB :)) > > > > We could have, but I doubt if that would have changed anything > > with regard to this debate :-) > > > > I think it will make the difference. Tunnel MIB is to address > objects only > at ingress (and egress) LSRs only. While TE-MIB should > address issues for > the whole path. See above. -arun > > From owner-mpls@UU.NET Thu Sep 7 14:20:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22761 for ; Thu, 7 Sep 2000 14:20:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqn28744; Thu, 7 Sep 2000 18:20:55 GMT Received: by mail-control.mail.uu.net id QQjfqn06023 for mpls-outgoing; Thu, 7 Sep 2000 18:20:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfqn05990 for ; Thu, 7 Sep 2000 18:20:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqn22446 for ; Thu, 7 Sep 2000 14:20:10 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfqn27577 for ; Thu, 7 Sep 2000 18:20:01 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA27677 for mpls@uu.net; Thu, 7 Sep 2000 14:19:50 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfqn05898 for ; Thu, 7 Sep 2000 18:19:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqn22232 for ; Thu, 7 Sep 2000 14:19:30 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfqn26959 for ; Thu, 7 Sep 2000 18:19:30 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA29868; Thu, 7 Sep 2000 11:19:45 -0700 (PDT) Received: from cisco.com (warsaw.cisco.com [171.69.71.119]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA11737; Thu, 7 Sep 2000 11:19:25 -0700 (PDT) Message-ID: <39B7D9F7.2856F028@cisco.com> Date: Thu, 07 Sep 2000 11:09:59 -0700 From: Robert Raszuk Reply-To: rraszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Kuhtz CC: "'mpls wg'" Subject: Re: ISPs offering VPN service References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Christian, Just to clarify one thing ... > In MPLS VPNs, default is that traffic starts to automatically flow shortest > path/fully meshed by the very nature of it. In mpls-vpn there is no default. The prefix distribution among PEs via IBGP fully depends on the policy you configure. There is no default policy (at least in one vendor I know a few things about :). So for one operator full mesh configuration may be the default he has chosen, for the other hub and spoke with hub as a headquater CEs, yet for another hub & spoke with hub being a PE (aggregation case discussed earlier). Good mpls-vpn provisioning tool should allow you to pick any of the above by just click of the mouse on a per VPN basis. Based on the real life observations I agree with Randy for the transition to full mesh for everybody may take time. R. From owner-mpls@UU.NET Thu Sep 7 14:46:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23567 for ; Thu, 7 Sep 2000 14:46:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqp20196; Thu, 7 Sep 2000 18:46:02 GMT Received: by mail-control.mail.uu.net id QQjfqp08224 for mpls-outgoing; Thu, 7 Sep 2000 18:45:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfqp08219 for ; Thu, 7 Sep 2000 18:45:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqp02499 for ; Thu, 7 Sep 2000 14:45:16 -0400 (EDT) Received: from roam.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dynamic219.workshop.sigz.net [195.149.150.219]) id QQjfqp02566 for ; Thu, 7 Sep 2000 18:45:14 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13X6fY-00081o-00; Thu, 07 Sep 2000 20:45:04 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Ramana V Gollamudi , Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6B04F.9A6747F8@alcatel.com> <39B6C692.A70F883D@cisco.com> <39B7B2E0.4E6FE220@alcatel.com> <39B7BADA.F0EF0AE4@cisco.com> Message-Id: Date: Thu, 07 Sep 2000 20:45:04 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Much more scary are enterprises with screwed addressing giving you 100,000 > routes from multiple points that you can not summarize. operationally, we do not usually consider customers with separate address space at each location to be screwed, and we try not to screw them. > you may also use Carrier's Carrier model, or even CCC/AToM/IPSec - all > depending how big is given customer's mesh. In those examples there is > no issue at all with the number of routes injected into your core. but i am cheered that you're seeing why i am worried about this scaling. randy From owner-mpls@UU.NET Thu Sep 7 14:52:19 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23859 for ; Thu, 7 Sep 2000 14:52:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqp08579; Thu, 7 Sep 2000 18:52:14 GMT Received: by mail-control.mail.uu.net id QQjfqp08533 for mpls-outgoing; Thu, 7 Sep 2000 18:51:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqp08500 for ; Thu, 7 Sep 2000 18:51:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqp09102; Thu, 7 Sep 2000 14:51:09 -0400 (EDT) Received: from roam.psg.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dynamic219.workshop.sigz.net [195.149.150.219]) id QQjfqp25555; Thu, 7 Sep 2000 18:50:38 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13X6l6-000826-00; Thu, 07 Sep 2000 20:50:48 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cheenu Srinivasan Cc: "'Jim Boyle'" , mpls@UU.NET, te-wg@UU.NET Subject: RE: Consensus for draft-kompella-mpls-te-mib-00.txt References: Message-Id: Date: Thu, 07 Sep 2000 20:50:48 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit the tewg has been asked by the iesg to take up the te mib. can we please get to work now? i believe that some folk actually have technical comments. thanks. randy From owner-mpls@UU.NET Thu Sep 7 14:58:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23930 for ; Thu, 7 Sep 2000 14:58:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqp13793; Thu, 7 Sep 2000 18:58:06 GMT Received: by mail-control.mail.uu.net id QQjfqp08939 for mpls-outgoing; Thu, 7 Sep 2000 18:57:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfqp08934 for ; Thu, 7 Sep 2000 18:57:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqp05130 for ; Thu, 7 Sep 2000 14:57:18 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfqp13050 for ; Thu, 7 Sep 2000 18:57:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA04965 for mpls@uu.net; Thu, 7 Sep 2000 14:57:17 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfqp08914 for ; Thu, 7 Sep 2000 18:56:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqp04958 for ; Thu, 7 Sep 2000 14:56:29 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfqp12388 for ; Thu, 7 Sep 2000 18:56:28 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA02392; Thu, 7 Sep 2000 11:56:47 -0700 (PDT) Received: from cisco.com (warsaw.cisco.com [171.69.71.119]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA11745; Thu, 7 Sep 2000 11:56:27 -0700 (PDT) Message-ID: <39B7E2A4.4EBFDDFF@cisco.com> Date: Thu, 07 Sep 2000 11:47:00 -0700 From: Robert Raszuk Reply-To: rraszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Robert Raszuk , Ramana V Gollamudi , Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6B04F.9A6747F8@alcatel.com> <39B6C692.A70F883D@cisco.com> <39B7B2E0.4E6FE220@alcatel.com> <39B7BADA.F0EF0AE4@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Randy, > > you may also use Carrier's Carrier model, or even CCC/AToM/IPSec - all > > depending how big is given customer's mesh. In those examples there is > > no issue at all with the number of routes injected into your core. > > but i am cheered that you're seeing why i am worried about this scaling. Yes I do. But the worry comes from the currently available routers resources perspective not the mpls-vpn technology by itself. With a new router generation where you can store >> then 100,000 routes (comming soon at least from three vendors I know about) I will not be worried anymore :). R. From owner-mpls@UU.NET Thu Sep 7 15:04:46 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24150 for ; Thu, 7 Sep 2000 15:04:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqq19885; Thu, 7 Sep 2000 19:04:44 GMT Received: by mail-control.mail.uu.net id QQjfqq21107 for mpls-outgoing; Thu, 7 Sep 2000 19:04:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfqq20986 for ; Thu, 7 Sep 2000 19:03:47 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqq11676; Thu, 7 Sep 2000 15:03:44 -0400 (EDT) Received: from maplenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82]) id QQjfqq18920; Thu, 7 Sep 2000 19:03:43 GMT Received: from prasuncomp (farhad_pc [192.168.10.239]) by maplenetworks.com (8.9.3+Sun/8.9.3/jcm Maplenetworks hub 1.4) with SMTP id MAA08767; Thu, 7 Sep 2000 12:03:35 -0700 (PDT) Message-ID: <049b01c018fe$a49d35a0$ef0aa8c0@maplenetworks.com> From: "Sudhanshu Jain" To: "Arun Viswanathan" , , , "Thomas D. Nadeau" References: Subject: Re: draft-kompella-mpls-te-mib-00.txt Date: Thu, 7 Sep 2000 12:05:52 -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 Hi Arun, Please see my inline comments too. ----- Original Message ----- From: "Arun Viswanathan" To: "'Sudhanshu Jain'" ; "Arun Viswanathan" ; ; ; "Thomas D. Nadeau" Sent: Thursday, September 07, 2000 11:17 AM Subject: RE: draft-kompella-mpls-te-mib-00.txt > > > > Sudhanshu, > > > I think, tunnel MIB objects are present only on ingress LSR > > and to some > > extent to egress LSR. Please correct me, if I am wrong. > > When you say tunnel MIB, I am assuming you mean the current MPLS-TE-MIB. > The initial intent of the MIB was to have the objects only at > head-end and tail-end of the tunnel. But its scope got extended in the > last few revs so that the objects may be optionally maintained at the > intermediate nodes. So you mean to say, for traffic engineering, each LSR on a path, need to manage Tunnel as oppose to the LSP. BTW, what are the benefits to club the traffic engineering issue with the Tunnel objects? And, how are we going to address TE for LSP's for which there is no tunnel have been configured e.g. ATM LSP? > > > > > As far the MPLS TE (Traffic Engineering) is concerned, it need to be > > performed at each hop not just at ingress and egress. So if > > this is the > > See above. The MPLS-TE-MIB objects are mainly for the head-end and > may optionally be maintained at subsequent nodes. > > > case, I think current MPLS-TE MIB is not the correct mib > > representing MPLS > > Traffic Engineering, as it address some TE aspects like > > session attribute > > etc for the configuration purpose at the head end of the tunnel only. > > > > On the other hand, objects like mplsLspAge, mplsLspTimeUp, > > mplsLspPrimaryTimeUp, mplsLspTransition, mplsPathPropertis > > etc. in Kireeti's > > mib need to be monitor at each hop. > > Objects in Kireeti's MIB are for the head-end of a tunnel only. > This is my understanding from my discussions with Kireeti. If this is the case, I think we need to address some of these issue at each hop like, mplsLspTimeUp, mplsLspPrimaryTimeUp, mplsLspTransition etc. As these objects are specific to hop as oppose to path. -Sudhanshu From owner-mpls@UU.NET Thu Sep 7 16:08:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26081 for ; Thu, 7 Sep 2000 16:08:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqu29447; Thu, 7 Sep 2000 20:08:37 GMT Received: by mail-control.mail.uu.net id QQjfqu08134 for mpls-outgoing; Thu, 7 Sep 2000 20:08:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfqu08129 for ; Thu, 7 Sep 2000 20:08:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqu26597 for ; Thu, 7 Sep 2000 16:07:34 -0400 (EDT) Received: from postal.adn.alcatel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [143.209.80.56]) id QQjfqu27546 for ; Thu, 7 Sep 2000 20:07:18 GMT Received: from adn.alcatel.com ([143.209.81.67]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAAF48; Thu, 7 Sep 2000 16:15:36 -0400 Message-ID: <39B7F639.26C2D008@adn.alcatel.com> Date: Thu, 07 Sep 2000 16:10:34 -0400 From: Senthil Venkatachalam Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Darek Skalecki CC: mpls@UU.NET, dhara_s@yahoo.com, Senthil Venkatachalam Subject: Re: LSP setup across IGP areas References: <200008161049.GAA21550@ietf.org> <399AB10E.D52BF1D2@americasm01.nt.com> <399C007B.EB8EE1A@americasm01.nt.com> Content-Type: multipart/alternative; boundary="------------DB9F1DB4368937D9BD9D5EE0" Sender: owner-mpls@UU.NET Precedence: bulk --------------DB9F1DB4368937D9BD9D5EE0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Darek, Thanks for your comments, sorry for the delay in our reply as we were caught up with other stuff.. Please find our comments inline: Skalecki, Darek (EXCHANGE:CAR:9K12) wrote: > I have a couple of questions/comments in association with > draft-venkatachalam-interarea-mpls-te-00.txt about LSP setup across IGP > areas. > > 1. In section 4.4 (Routing algorithm): > > 6. If the destination is in this area, calculate an intra-area route > from the originating node to the destination that satisfies the > ^^^^^^^^^^^^^^^^ > constraints, and splice the egress of the original LSP and the > ^^^^^^^^^^^^ > ingress of the new LSP. > > Shouldn't it be transit ABR instead of originating node, and also upstream > LSP instead of original LSP. > Yes, you are right. The algorithm should be reworded to describe the creation of each LSP section, the head of which is either the originating node or the head ABR of the section. "originating node" should be "head node of the new LSP section" and "original LSP" should be "upstream LSP section" > > 2. Is there some special software entity besides the signaling entity > (RSVP-TE or CR-LDP) at ABR that splices upstream LSP section to downstream > LSP section. Is this entity what you call routing process in step 4 of > section 4.4. Is this entity responsible for intercepting LABEL_REQUEST and > PATH (as well as other CR-LDP and RSVP) messages at ABRs. > The two major entities are signaling and routing entities. Our proposal does not add any new componets to the LSP setup mechanisms. The only extensions we have to support our idea is to extend these components to use primary and secondary criteria related concepts at the ABRs. > > 3. About crankback. It is stated that crankback is to the previous nearest > ABR from the point of failure. At that ABR the routing algorithm by > routing process is repeated. Is there any mechanism that prevents the > selection of the same ABR as was used previously. For example, refering to > the following example > > Area 1 Area 0 Area 2 > -------------------- ------------------ ------------------------ > | | | | | | > | |N1 PPS1 ------- PPS3 -------- PPS5 |N2 | > | |-------------- |ABR1 |--------------|ABR 2 |--------X-------| | > | |-------| ------- -------- --|PPS7 |------| | > | PSS2 | ------- PSS4 -------- |-----| PSS6 | > | --------|ABR 3 |--------------|ABR 4 |--------- | > | ------- -------- | > | | | | | | > -------------------- ------------------- ------------------------- > > Let's assume PPS5 failed and we initially cranked back to ABR 2 but there > was no intra-area route to the destination so we cranked back to ABR1. At > ABR1 when performing the algorithm of section 4.4 we should not consider > ABR2 as this is from where we cranked back and we know that ABR2 already > tried unsuccessfully to route to the destination. > Good point. In our companion draft (draft-dharanikota-interarea-mpls-te-ext-00.txt), we have to extend the signaling error conditions to include the ABR information, which is not considered presently. We will include it in the next revision. Using this ABR information, the routing protocol can prune the ABR from its calculation, and hence avoid it in the next attempt. > > Also, routing in response to crankback really depends on whether the > failure causing the crankback was within the current area or another > downstream area. If it was within the current area then same downstream > ABR can be selected. If it was outside of the current area then a > different ABR should be selected. For example, if PPS5 fails and we crank > back to ABR2 then to ABR1 (as I eluded to above) then ABR2 should not be > considered when routing at ABR1. On the other hand, if PPS3 fails and we > crank back to ABR1 then ABR2 should be considered. > > 4. Have you given some thought to the idea that an LSP section failure in > one area should not have an effect on surrounding LSP sections in other > areas. For example, refering to the above picture, if PPS3 fails then > another intra-area route through Area 0 between ABR1 and ABR2 is computed > and LSP section reestablished along that route without affecting LSP > sections PPS1 and PPS5. This would be similar to "local repair" where > local = area. > Local repair is an interesting concept, in conjunction with our draft - it will be a good candidate for the next revision. > > Cheers, > > Darek > > > Thanks and appreciate your comments, Senthil & Sudheer. -- Senthil K. Venkatachalam senthil.venkatachalam@adn.alcatel.com Off#:4223, MBox: (703) 654-8635 [Off] Alcatel USA (703) 654-8272 [Fax] __________________________________________________________________ --------------DB9F1DB4368937D9BD9D5EE0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Darek,

Thanks for your comments, sorry for the delay in our reply
as we were caught up with other stuff..

Please find our comments inline:

Skalecki, Darek (EXCHANGE:CAR:9K12) wrote:

I have a couple of questions/comments in association with draft-venkatachalam-interarea-mpls-te-00.txt about LSP setup across IGP areas.

1. In section 4.4 (Routing algorithm):

   6. If the destination is in this area, calculate an intra-area route
      from the originating node to the destination that satisfies the
               ^^^^^^^^^^^^^^^^
      constraints, and splice the egress of the original LSP and the
                                                ^^^^^^^^^^^^
      ingress of the new LSP.

Shouldn't it be transit ABR instead of originating node, and also upstream LSP instead of original LSP.
 

Yes, you are right. The algorithm should be reworded to describe the
creation of each LSP section, the head of which is either the
originating node or the head ABR of the section.

"originating node" should be "head node of the new LSP section"
and
"original LSP" should be "upstream LSP section"
 

 
2. Is there some special software entity besides the signaling entity (RSVP-TE or CR-LDP) at ABR that splices upstream LSP section to downstream LSP section. Is this entity what you call routing process in step 4 of section 4.4. Is this entity responsible for intercepting LABEL_REQUEST and PATH (as well as other CR-LDP and RSVP) messages at ABRs.
 
The two major entities are signaling and routing entities. Our proposal does not add any new componets
to the LSP setup mechanisms. The only extensions we have to support our idea is to extend these
components to use primary and secondary criteria related concepts at the ABRs.
 
 
3. About crankback. It is stated that crankback is to the previous nearest ABR from the point of failure. At that ABR the routing algorithm by routing process is repeated.  Is there any mechanism that prevents the selection of the same ABR as was used previously. For example, refering to the following example

Area 1                      Area 0                    Area 2
--------------------    ------------------     ------------------------
|                  |    |                 |    |                       |
|  |N1  PPS1       -------    PPS3       --------      PPS5      |N2   |
|  |-------------- |ABR1  |--------------|ABR 2 |--------X-------|     |
|  |-------|       -------               -------- --|PPS7 |------|     |
|   PSS2   |       -------    PSS4       --------   |-----| PSS6       |
|          --------|ABR 3 |--------------|ABR 4  |---------            |
|                  -------               --------                      |
|                  |    |                 |    |                       |
--------------------    -------------------    -------------------------

Let's assume PPS5 failed and we initially cranked back to ABR 2 but there was no intra-area route to the destination so we cranked back to ABR1. At ABR1 when performing the algorithm of section 4.4 we should not consider ABR2 as this is from where we cranked back and we know that ABR2 already tried unsuccessfully to route to the destination.
 

Good point. In our companion draft (draft-dharanikota-interarea-mpls-te-ext-00.txt), we have to extend
the signaling error conditions to include the ABR information, which is not considered presently. We will
include it in the next revision. Using this ABR information, the routing protocol can prune the ABR from its
calculation, and hence avoid it in the next attempt.
 
 
Also, routing in response to crankback really depends on whether the failure causing the crankback was within the current area or another downstream area. If it was within the current area then same downstream ABR can be selected. If it was outside of the current area then a different ABR should be selected. For example, if PPS5 fails and we crank back to ABR2 then to ABR1 (as I eluded to above) then ABR2 should not be considered when routing at ABR1. On the other hand, if PPS3 fails and we crank back to ABR1 then ABR2 should be considered.

4. Have you given some thought to the idea that an LSP section failure in one area should not have an effect on surrounding LSP sections in other areas. For example, refering to the above picture, if PPS3 fails then another intra-area route through Area 0 between ABR1 and ABR2 is computed and LSP section reestablished along that route without affecting LSP sections PPS1 and PPS5. This would be similar to "local repair" where local = area.
 

Local repair is an interesting concept, in conjunction with our draft -
it will be a good candidate for the next revision.
 
 
Cheers,

Darek
 
 
 

Thanks and appreciate your comments,
Senthil & Sudheer. 
-- 
Senthil K. Venkatachalam     senthil.venkatachalam@adn.alcatel.com
Off#:4223, MBox:             (703) 654-8635 [Off]
Alcatel USA                  (703) 654-8272 [Fax]
__________________________________________________________________
  --------------DB9F1DB4368937D9BD9D5EE0-- From owner-mpls@UU.NET Thu Sep 7 16:34:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26586 for ; Thu, 7 Sep 2000 16:34:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqr05169; Thu, 7 Sep 2000 19:22:51 GMT Received: by mail-control.mail.uu.net id QQjfqr23258 for mpls-outgoing; Thu, 7 Sep 2000 19:22:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfqr23251 for ; Thu, 7 Sep 2000 19:22:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqr10853 for ; Thu, 7 Sep 2000 15:21:54 -0400 (EDT) Received: from roam.psg.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dynamic219.workshop.sigz.net [195.149.150.219]) id QQjfqr01339 for ; Thu, 7 Sep 2000 19:21:34 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13X7EW-00083x-00; Thu, 07 Sep 2000 21:21:12 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Robert Raszuk , Ramana V Gollamudi , Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6B04F.9A6747F8@alcatel.com> <39B6C692.A70F883D@cisco.com> <39B7B2E0.4E6FE220@alcatel.com> <39B7BADA.F0EF0AE4@cisco.com> <39B7E2A4.4EBFDDFF@cisco.com> Message-Id: Date: Thu, 07 Sep 2000 21:21:12 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Yes I do. But the worry comes from the currently available routers > resources perspective not the mpls-vpn technology by itself. With a new > router generation where you can store >> then 100,000 routes (comming > soon at least from three vendors I know about) I will not be worried > anymore :). the problems with bgp scaling is not a matter of ram. for a scary example of one small aspect of the current bgp mess see http://www.acm.org/sigcomm2000/conf/paper/sigcomm2000-5-2.ps.gz randy From owner-mpls@UU.NET Thu Sep 7 17:26:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27686 for ; Thu, 7 Sep 2000 17:26:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqz13797; Thu, 7 Sep 2000 21:26:46 GMT Received: by mail-control.mail.uu.net id QQjfqz25986 for mpls-outgoing; Thu, 7 Sep 2000 21:26:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfqz25981 for ; Thu, 7 Sep 2000 21:26:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqz12791 for ; Thu, 7 Sep 2000 17:26:11 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfqz05185 for ; Thu, 7 Sep 2000 21:26:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA26067 for mpls@uu.net; Thu, 7 Sep 2000 17:26:10 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfqz25937 for ; Thu, 7 Sep 2000 21:25:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqz16216; Thu, 7 Sep 2000 17:25:30 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjfqz12565; Thu, 7 Sep 2000 21:25:30 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA00230; Thu, 7 Sep 2000 17:25:29 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (dhcp-171-71-237-208.cisco.com [171.71.237.208]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA05539; Thu, 7 Sep 2000 17:25:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20000907171103.02095f00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Sep 2000 17:13:29 -0400 To: "Sudhanshu Jain" , "Arun Viswanathan" , , From: "Thomas D. Nadeau" Subject: Re: draft-kompella-mpls-te-mib-00.txt In-Reply-To: <042501c018f1$d6bd77a0$ef0aa8c0@maplenetworks.com> References: <071bc2912d16b792bf9ec10604a7906239b70b71@force10networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >I think, tunnel MIB objects are present only on ingress LSR and to some >extent to egress LSR. Please correct me, if I am wrong. It is possible (though not mandatory) to have vendors implement the MPLS-TE-MIB at intermediate hops. However, it is designed to do so. I know of several implementations where this is supported on every hop. In fact, the recent indexing modifications I made to the tunnel table allow for this. >As far the MPLS TE (Traffic Engineering) is concerned, it need to be >performed at each hop not just at ingress and egress. So if this is the >case, I think current MPLS-TE MIB is not the correct mib representing MPLS >Traffic Engineering, as it address some TE aspects like session attribute >etc for the configuration purpose at the head end of the tunnel only. > >On the other hand, objects like mplsLspAge, mplsLspTimeUp, >mplsLspPrimaryTimeUp, mplsLspTransition, mplsPathPropertis etc. in Kireeti's >mib need to be monitor at each hop. > >May be these objects should be addresses based on different index as oppose >to mplsLspName as specified in Kireeti's MIB. I agree with you. These are available at intermediate hops using the MPLS-TE-MIB. What might be better is to make it mandatory (or a subset of the objects) at intermedite hops. --Tom From owner-mpls@UU.NET Thu Sep 7 17:28:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27718 for ; Thu, 7 Sep 2000 17:28:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfqz06881; Thu, 7 Sep 2000 21:28:19 GMT Received: by mail-control.mail.uu.net id QQjfqz26167 for mpls-outgoing; Thu, 7 Sep 2000 21:28:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqz26133 for ; Thu, 7 Sep 2000 21:27:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqz16666 for ; Thu, 7 Sep 2000 17:27:51 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfqz06327 for ; Thu, 7 Sep 2000 21:27:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA26348 for mpls@uu.net; Thu, 7 Sep 2000 17:27:50 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfqz26086 for ; Thu, 7 Sep 2000 21:27:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfqz16610; Thu, 7 Sep 2000 17:27:23 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjfqz14591; Thu, 7 Sep 2000 21:27:23 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA00458; Thu, 7 Sep 2000 17:27:22 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (dhcp-171-71-237-208.cisco.com [171.71.237.208]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA05561; Thu, 7 Sep 2000 17:27:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20000907171457.0209d060@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Sep 2000 17:15:22 -0400 To: Adrian Farrel , Sudhanshu Jain , Arun Viswanathan , mpls@UU.NET, te-wg@UU.NET From: "Thomas D. Nadeau" Subject: RE: draft-kompella-mpls-te-mib-00.txt In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2CA12A@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >I think Tom extended the MIB to support its use at transit LSRs one (or >two?) versions ago. Yes, correct. --Tom From owner-mpls@UU.NET Thu Sep 7 18:32:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28505 for ; Thu, 7 Sep 2000 18:32:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfre07761; Thu, 7 Sep 2000 22:32:34 GMT Received: by mail-control.mail.uu.net id QQjfre13276 for mpls-outgoing; Thu, 7 Sep 2000 22:32:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfre13270 for ; Thu, 7 Sep 2000 22:32:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfre27129 for ; Thu, 7 Sep 2000 18:31:55 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQjfre06777 for ; Thu, 7 Sep 2000 22:31:40 GMT Received: from gketell-lt.juniper.net (ssh.juniper.net [207.17.136.39]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id PAA26590; Thu, 7 Sep 2000 15:30:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20000907152305.01723c10@localhost> X-Sender: gketell@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Sep 2000 15:29:56 -0700 To: rraszuk@cisco.com, Randy Bush From: Greg Ketell Subject: Re: ISPs offering VPN service Cc: Robert Raszuk , Ramana V Gollamudi , Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'mpls wg'" In-Reply-To: <39B7E2A4.4EBFDDFF@cisco.com> References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6B04F.9A6747F8@alcatel.com> <39B6C692.A70F883D@cisco.com> <39B7B2E0.4E6FE220@alcatel.com> <39B7BADA.F0EF0AE4@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:47 AM 9/7/2000 -0700, Robert Raszuk wrote: >Randy, > > > > you may also use Carrier's Carrier model, or even CCC/AToM/IPSec - all > > > depending how big is given customer's mesh. In those examples there is > > > no issue at all with the number of routes injected into your core. > > > > but i am cheered that you're seeing why i am worried about this scaling. > >Yes I do. But the worry comes from the currently available routers >resources perspective not the mpls-vpn technology by itself. With a new >router generation where you can store >> then 100,000 routes (comming >soon at least from three vendors I know about) I will not be worried >anymore :). You should be. As you pointed out earlier, many customers with many route prefixes per customer is the target of this service. With most of these prefixes being aggregated today we have route table growth that is faster than some router vendors can keep up with. Now, unaggregate them all (or even just 10-20% of them). Now you are outgrowing the Processor manufacturers and RAM manufactures capabilities. Yikes! The fact that adding one prefix on a PE router in timbuktu will affect all your other PE routers (either as an additional prefix or as additional filtering requirements) and you have a scenario where a router that was working fine could go belly up with no one any where near it. ORF will help the PE but at the cost of performance on the RRvpn's. So now you add more RRvpn's... Just how good is that provisioning tool anyway? GK >R. From owner-mpls@UU.NET Thu Sep 7 22:42:04 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03568 for ; Thu, 7 Sep 2000 22:42:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfru11016; Fri, 8 Sep 2000 02:42:03 GMT Received: by mail-control.mail.uu.net id QQjfru14745 for mpls-outgoing; Fri, 8 Sep 2000 02:41:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfru14740 for ; Fri, 8 Sep 2000 02:41:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfru01589 for ; Thu, 7 Sep 2000 22:41:26 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfru10417 for ; Fri, 8 Sep 2000 02:41:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA20456 for mpls@uu.net; Thu, 7 Sep 2000 22:41:23 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfru14620 for ; Fri, 8 Sep 2000 02:40:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfru27329 for ; Thu, 7 Sep 2000 22:40:49 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfru27418 for ; Fri, 8 Sep 2000 02:40:48 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA22510; Thu, 7 Sep 2000 19:41:06 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA11781; Thu, 7 Sep 2000 19:40:46 -0700 (PDT) Message-ID: <39B852A1.F13DE475@cisco.com> Date: Thu, 07 Sep 2000 19:44:49 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Greg Ketell CC: rraszuk@cisco.com, Randy Bush , Ramana V Gollamudi , Sitarama R Kalipatnapu , erosen@cisco.com, bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009061652.MAA25675@erosen-sun.cisco.com> <39B68101.E613C7DE@adn.alcatel.com> <39B6855A.31C9BD86@cisco.com> <39B699C0.630AF10E@adn.alcatel.com> <39B69CD7.74FCFA14@cisco.com> <39B6B04F.9A6747F8@alcatel.com> <39B6C692.A70F883D@cisco.com> <39B7B2E0.4E6FE220@alcatel.com> <39B7BADA.F0EF0AE4@cisco.com> <4.3.2.7.2.20000907152305.01723c10@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Greg, > >Yes I do. But the worry comes from the currently available routers > >resources perspective not the mpls-vpn technology by itself. With a new > >router generation where you can store >> then 100,000 routes (comming > >soon at least from three vendors I know about) I will not be worried > >anymore :). > > You should be. As you pointed out earlier, many customers with many route > prefixes per customer is the target of this service. Many customers with many prefixes is still fine even today. Many customers with HUGE amount of unaggregated prefixes is getting us close to the hardware limits - but still on a per box basis - not per mpls-vpn as a whole. There are two reasons why I am not too worried about the extreme cases are: A. I know only 3-4 worldwide big enterprise networks which may be getting to this kind of prefix numbers in a range of 100,000 routes in their own internal network. B. Those from item A I talked with were going to use mpls-vpn by themselves as they already running the entire network by themselves to easily connect their department and branches and would not be intersted any time soon to give the function of running the corporate network to SP/ISP. So what it means to us is: 1. The cases where we hit the scaling limits of today's hardware will be not too often 2. If those global enterprises will start looking at MPLS from the ISP/SP perspective Carrier's Carrier solution of mpls-vpn will in a scalable way alow to accomodate such customers into any provider's core. > The fact that adding one prefix on a PE router in timbuktu will affect all > your other PE routers (either as an additional prefix or as additional > filtering requirements) and you have a scenario where a router that was > working fine could go belly up with no one any where near it. Ha that I would call very poor implementation of mpls-vpns. The one I am familar with a bit does not have this characteristic :) There are very easy ways to avoid this from happening, otherwise it would be quite a challange to keep the IPSs/SPs network running at all provided that all prefixes are injected dynamically. > ORF will help the PE but at the cost of performance on the RRvpn's. This is in fact just the opposite :). You want to limit the routes each reflector receives to only those he is interested in serving by pushing policy to PEs. PEs do the filtering before sending vpnv4 updates so only those updates which needs to be received by given reflector cluster are being send accordingly. This helps in two ways: a) frees up relfectors from additional inbound filtering, B) distributes the filtering to many PEs - "smart edge" concept. Since you have asked - on the reflectors on the other hand all PEs can be in a peer group so update generation happens only once and then is just the low cost replication. R. From owner-mpls@UU.NET Fri Sep 8 01:11:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06023 for ; Fri, 8 Sep 2000 01:11:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfse20770; Fri, 8 Sep 2000 05:11:47 GMT Received: by mail-control.mail.uu.net id QQjfse28414 for mpls-outgoing; Fri, 8 Sep 2000 05:11:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfse28408 for ; Fri, 8 Sep 2000 05:11:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfse16244 for ; Fri, 8 Sep 2000 01:11:05 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQjfse01648 for ; Fri, 8 Sep 2000 05:10:50 GMT Received: from oleary-lt (oleary-lt.jnpr.net [172.24.12.165]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id WAA14965; Thu, 7 Sep 2000 22:10:36 -0700 (PDT) Message-Id: <4.2.0.58.20000907220818.02c0e100@garnet.juniper.net> X-Sender: doleary@garnet.juniper.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 07 Sep 2000 22:14:51 -0700 To: rraszuk@cisco.com, Christian Kuhtz From: "dave o'leary" Subject: Re: ISPs offering VPN service Cc: "'mpls wg'" In-Reply-To: <39B7D9F7.2856F028@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:09 AM 9/7/00 -0700, Robert Raszuk wrote: >Christian, > >Just to clarify one thing ... > > > In MPLS VPNs, default is that traffic starts to automatically flow shortest > > path/fully meshed by the very nature of it. > >In mpls-vpn there is no default. The prefix distribution among PEs via >IBGP fully depends on the policy you configure. There is no default >policy (at least in one vendor I know a few things about :). I think that Christian's point is that if no policy is explicitly configured to filter (whether directly in the routers or via a provisioning system), then it is reasonable to assume that the VPN attributes will be distributed around the full mesh just as regular IPv4 prefix information is distributed, hence a full mesh VPN. At least in my recollection of configuring one vendor's products (the same one that I assume you are talking about), when (i)BGP peering is established, the default is to send everything unless it is explicitly configured. Of course, it has been a few years since I've configured BGP on a type-C box.... :-) dave From owner-mpls@UU.NET Fri Sep 8 01:32:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08499 for ; Fri, 8 Sep 2000 01:32:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfsg03600; Fri, 8 Sep 2000 05:32:32 GMT Received: by mail-control.mail.uu.net id QQjfsg29726 for mpls-outgoing; Fri, 8 Sep 2000 05:32:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfsg29721 for ; Fri, 8 Sep 2000 05:31:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfsg18637 for ; Fri, 8 Sep 2000 01:31:36 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjfsg02545 for ; Fri, 8 Sep 2000 05:31:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA01423 for mpls@uu.net; Fri, 8 Sep 2000 01:31:04 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfsg29599 for ; Fri, 8 Sep 2000 05:30:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfsg18496 for ; Fri, 8 Sep 2000 01:30:15 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfsg15018 for ; Fri, 8 Sep 2000 05:30:14 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA23890; Thu, 7 Sep 2000 22:30:33 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id WAA11904; Thu, 7 Sep 2000 22:30:13 -0700 (PDT) Message-ID: <39B87A56.35C6B1D5@cisco.com> Date: Thu, 07 Sep 2000 22:34:14 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "dave o'leary" CC: rraszuk@cisco.com, Christian Kuhtz , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <4.2.0.58.20000907220818.02c0e100@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dave, Actually distributing prefixes everywhere and even worse accepting them to all PEs would be very bad idea in the mpls-vpn case. The "timbuktu" example Greg brought earlier should tell you why. So by default (meaning without configuring any policy = without setting any route target ext. community) vpnv4 routes should not be accepted to any of the remote vpnv4 bgp tables then vrfs and hence by default you will see no routes in that vrf and (as Eric Gray correctly pointed out offline) by default you will see packet drop :). As this is implementation specific issue not related to interoperability I don't think that we should continue on this particular topic on a mailing list dedicated to mpls protocol specific issues. Of course other mpls-vpn architecture related questions are still welcome. R. > At 11:09 AM 9/7/00 -0700, Robert Raszuk wrote: > >Christian, > > > >Just to clarify one thing ... > > > > > In MPLS VPNs, default is that traffic starts to automatically flow shortest > > > path/fully meshed by the very nature of it. > > > >In mpls-vpn there is no default. The prefix distribution among PEs via > >IBGP fully depends on the policy you configure. There is no default > >policy (at least in one vendor I know a few things about :). > > I think that Christian's point is that if no policy is explicitly configured > to filter (whether directly in the routers or via a provisioning system), > then it is reasonable to assume that the VPN attributes will be distributed > around the full mesh just as regular IPv4 prefix information is distributed, > hence a full mesh VPN. At least in my recollection of configuring one > vendor's products (the same one that I assume you are talking about), > when (i)BGP peering is established, the default is to send everything > unless it is explicitly configured. Of course, it has been a few years > since I've configured BGP on a type-C box.... :-) > > dave From owner-mpls@UU.NET Fri Sep 8 02:30:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17957 for ; Fri, 8 Sep 2000 02:30:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfsk22184; Fri, 8 Sep 2000 06:30:31 GMT Received: by mail-control.mail.uu.net id QQjfsk14877 for mpls-outgoing; Fri, 8 Sep 2000 06:30:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfsj14871 for ; Fri, 8 Sep 2000 06:29:47 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfsj25071 for ; Fri, 8 Sep 2000 02:29:45 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjfsj08969 for ; Fri, 8 Sep 2000 06:29:14 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Sep 2000 00:16:13 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE9D7@BGSLC02> From: Irwin Lazar To: "'mpls@uu.net'" Cc: "'mpls-ops@mplsrc.com'" Subject: MPLScon 2001 - Call for Presentations Date: Fri, 8 Sep 2000 00:16:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0195C.497680C4" 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_01C0195C.497680C4 Content-Type: text/plain; charset="iso-8859-1" MPLScon 2001 - The MPLS Conference and Exhibition, <> will be held March 26-29,2001 in San Jose California. A Call for Presentations for this event is attached. If you have any questions, please contact me via e-mail at ilazar@tbg.com or via phone at 703-742-9659. Sincerely, Irwin Lazar Conference Director MPLScon 2001 ------_=_NextPart_000_01C0195C.497680C4 Content-Type: application/octet-stream; name="MPLSconCFP.pdf" Content-Disposition: attachment; filename="MPLSconCFP.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDQol4uPP0w0KIA0KMTIgMCBvYmoNCjw8DQovTGVuZ3RoIDEzIDAgUg0KL0ZpbHRl ciAvRmxhdGVEZWNvZGUgDQo+Pg0Kc3RyZWFtDQpIicRX227jRhL9gvmHflpMAI+mL7zmZTHxZePF TGLYxmYf5qVFtaReU2yGTUrjv0/1jRdZE9OLXQUGDMkmu6tOnTp16qfHdzQhizRGKU4XNEbo8eod RvCziDFFzQa9+3iDEYnc/9bvPuAFiTICnwsEn3HCIvh8QO+/3H1+KFSFvlJKMPkBPf7nXZaag7E5 0/62b1BCYvcGsg99oISawz8Qtoj9o+anv5rae+EqmqXhEJZEqTvkcSvQl65sZd2oVhWqRJ/5UpTo 4SDbYiurDbpU1Vo0oioE+hu6/raVS9lKVdnLGUsXLyJkLJkGyOjCxOcxgCcXGNMhFpb5WC55WaIb 1aC7RmhRtdzco+0hhCYDFh9vCMrNV5uYPQdwyfIpLoRG9lrq36GjdxYkZtS/SFjCfAl4U2wRTez7 ETHhugsN7FHiIsbu2Q8u/5D7Ik5z++/3NHcBj143+eZ9mNiHeYEeeIX+qbS4QJef7EtJclzwE3kl 2Dw05DXCYqBEAg+QEd5pnobzcJ5NGSc10kI8mVr/3vFSrqVYoVo0GsBH60btULttVLfZqq6FjwLJ atXptnlGrUK6FvwJ/mL/0apaFog3gmsXCT4KA2rtw4hw7Ku+Erpo5BLuBN6pwwL+CkcVA+vsFRCO wzWnI4wWOLPdYOtIA6fRQQKRZFWU3QqC2gLECBhVQz5yWQq0BoqZcFdiDzfWO6AaUutAG3dBwNde 0RcPp8mAHWpFsa1UqTZS6Askd3UpzFkGSF6tIIBWbBpuv7943vxXQVS8dESK0jl0G6cO+ZKQehJ7 FTmoplyhSrTw4QmCcjmxmBwXgkYhpzgl7t0dr/gmBGtfTNniDS2AcxbiyRPPWVFxQHwckUFmx5sn 0U6uIulI7OZcltFQFRYnvipLrg11G7Xqilbbq7Ro9rIQGmjleyNOnVyO4CAk7dUgpV4NHjztDJ+R +FaLooXDoWhbvnchsykVk1E9bHAmf8PeAlqqsEc0rdQidIvrk3bLbVc9O9aupC46bcK94/B0IWtH IE9OdkzOdCAnCeQUTqSB5YXa1bwydLNJVIXqGr5xaehuuZOtQatWmpdQmsNWgv7ZMJa2A7VcQQ+u bMOc7OeMJn1rJD5lXhSibrnpXF4qCB0myRYpSLHRiwDcayJnHhld9X64PsgeG8s5TuKAPaWR74Xf DLK3Gnmd+7ubqflIl793u3todP904gDTcdAxkofpNZZTowXPtsh1I3ZSNINmguaA3BRqLxp7GaX5 YkSiHIfGxGnkG9M2yp/NaGBLuN2T3B46rVWO0yFmPwKWDbwNHFQbYeqD2g5YIy0ZNJRwxZuVDpQ0 s/gCKSAxN9QaNZfh0N5QBRS1LtWzFdS65JU+LhuEEadZD3vsW82cZdtDGsH3IgE4reCeeuwFTOuo xtwEBPa3Ig54VxvQdbgSgjlAIkH1T5GWQKMGIDLWQ7xX5V4Y0Q5jAc68gM9+mkfTVs/jnm7uAJO3 faNX0f+V0MVJkFXKGB0LXdA2VICRgOIDpTZidotFNJ1y5NUmi4LURHkwMSctG7rkMPmASEL/6KKJ j23iqZaPj+J50XSEDAQ+cs3GwOgjrtgeM9ibPlyrEsyF/WZMig+MJvHrgbmH/hyoibnElAZ6xGSk DuhnqaF1ni01ft2b6omDR4jOQQjnE0cbTS4NRsi98pUmqfOxLw06ydLJwWQY80eYE5L09ir1zfqp 0ocB1987oft1gOA3GYYY/GCIiRLmNclsQMzZ4T6oqXenvZAlNB5pPQgCmI3d1/f66w9Ghi3mYC/l pvIjz/Q4HB+5WUBBa9+yUTAWnRl/nPS2nYZU74WhjeVQV6+g0xDwv+iaxqju7fXjjcv7N7Bbpkj/ AOteI160cg97m3AumubZ63RjJDl3unFPN8rYjHRtpiA/3e5FhmxOZ8fMZehCOFeSaRB0xvKRjvlp gWDNKpV6uuiz7DcLL2wGi3XXdmbMwQMrn3EWz9geGSXOQZ5Ss5H00qO6RENdyCjkW9hxGusJlrKU 7TN6NHJQbbyqMTZD1Uh8bpoNFoSQvqtq1fidgWsttDaAa0O2muvW/r1nncMb4qajdQyT3hNmqVd9 A5E8hqh1ECGxXpsr/YTEr85rTJwrpbPLlmfBnpMc50dls6sppPebsefX36QL6s5bzDC5s3iGXyZJ Og7t/1/DD2aFjcLOBg01nrJ72J4+PX5xJ8BWMt9qpSzQnEXE0xxt1cHtROZMQwN7SaH83B7hM2tt jYPC4TTsiAZ7c/JHv7GJVly4K+1VjXDG1msWxmOszZU5HV8JYfrxlswoXRSdt3LGRrJ+qEWxH/pj Qqq1yxsaRyERiAlpuYMd115DfGLXHfm9c0zQyEJXoj3AoNSeKzMElMaZE9AzIpb36wbxnLkSfuEI UKGd/Ab5iGovG1VZ7frRn5uN6MeS4KEjzPzsuTarHwBxgW4avhPoXpT8+cIA7haxnWr8FpRGr6HD zgwN6He/FKSRtwxXSnjzt+NPAj38+sv140fTvbJaNyDmTVeY4QnivgRHCN3m+yWeMa3gD5NpNRLc U4ps5kLW29UMZyOdegBfystTokuy7+T7nahCgYdFgZ17pOZ4WM5yNsryM1+KEl1BFzdy2dkG79P1 p8bR/K3BKD8mwUBFaebvQtxKJ2+kdhJyeW/fy8lbNhICu0FII0n9BPh8dWf74P7hX3dzZ8ogJPBM gmOn0O8fr/3UeLWPAJP0/NY0z4cq4mBN+VNY9laikNpUcAmyKUQVQCZRPAPliSRHaQA6IX8l0BTe OO+KEyJhIZJBB2rfGEh3tWNvNraYOImDn6Pwunvb2FYERhJdwmrQNhymJvrJzrZ7WCTgVF+hdM5s A5t/XiM+WAESrMDP4Lc4rDZWPUqrHvog22ILRrzdagTumS9LqbeQomFLCxpfoZU6VF7GMzx/tz1t nUdKHlwWGLd+a8vJ2G7eCw2+XlTFM/oIX1ZdteLmywsnnc7YhZL87LtQL9yUhG30EyjoXjR7KQ5G SltRbCtVqo0UbkGqewE3xFt2slwZ+jYDEta7GXhclzL6Rpec0ZBKHGUebefYfP1Y7HzraNLinE4A mng7NsfbxenZrR1OaB8NY0MHAHyA8l6uxABjnrxJY2nv9TDN4jGGBhn7PJin/mkc9ZtJeNqgB4sI 7IfWQ9lX0uRNA7XXu5xFnl2lBFM2cMV1bTJnz2SMjNrjlN+atLGJL6FsHF+PJU1PJHEi/MG70QmE vzhyoSvIY1PZrnCe3FhvX/U0f+tu2K8pFFOf+e3n68sLdGl/3/770lny24c7dAlxoIe2W4Wu9BpO 6MvOSLIwbfM0LLa3u7oUJlq3dd0LM0mCWOFsRrvk+K/wKHEWUIoy7Je5SyNXwaXcqLJUB/PtUdWy CCmxZHQk/S9MNSXHIyOerCKTZJVj9RGEZJok/U6KjIQUaZz6FG+rVmwaVyurruIbeGqTJWw2fwxq HGnlg6GJBaw5YWhiYIleQMCLTnMi6lMjQwu0VEe70LGEN9EtTaE6nKBVkA6wiQrKhKBgAXddE/MS 00EcYL6H5kkjPaQS0sTMAtlZkKLBHGsBh1k2GJvAG8umptCyLT8vpxI19MwMCYaeawgvAKWLWGcN CmVuZHN0cmVhbQ0KZW5kb2JqDQoxMyAwIG9iag0KMjcwNg0KZW5kb2JqDQo0IDAgb2JqDQo8PA0K L1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDIwIDAgUg0K L1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMgMTIgMCBSDQo+Pg0KZW5kb2JqDQoyMCAwIG9i ag0KPDwNCi9GMCA2IDAgUg0KL0YxIDggMCBSDQovRjIgMTAgMCBSDQovRjMgMTQgMCBSDQovRjQg MTYgMCBSDQovRjUgMTggMCBSDQo+Pg0KZW5kb2JqDQoyMiAwIG9iag0KPDwNCi9MZW5ndGggMjMg MCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZSANCj4+DQpzdHJlYW0NCkiJxVfZbttIFv0C/0M9DTpA LLMWFln9MmgvyRiI04rl+MkvNFmSOU2xBJKyx38/t1aRtgJR0xMGDbgjiVW8yznnnnt+d4IZQwnG CN1dnkRI/9es0MnZpxiJWRLD18uTaIb1P3L4Dd29oN/UB3T37xNuPl6av/CTfQZ+ReZXTNzPZ59w /6aI09QdICRO7JHr9aaSa1l3WVeqGqklup6jrsmWyzJHsl6VtZRNWa/QttV/b+ZfFuYlhMIt8Zs4 SCoGkZwSluqnTjHW/7Mx/azs0ij2YUTiTXI69Ea2ZVXKOn9FWV3Ax2JbF5n++C61eHY4s5jOdGLk J2fFRciK7Enqm1qcXajF2xQwxyO6gxMxWXeYEO4AIwm2R3S4qBwC0CbynDWl2raorDtAn2rQKuvk S/aKGrU1eW8a1alcVS16+O3a5kwJ0++zrz+FdBlP+uGf2qd2z0BU0EVfHM58fRcfXX0oSWeD8sBj OPUnogS7E38u5p8+oqvrz7fzhw+2SLz3mh+VPzXx/nwIUU58CDGlrvRZna10IYHwATXpqAKG6mGW ch8J85R7zFpZoFp2L6r5qzUnkmgEnaycDKBIdlm4x6L+AzpCTmg/wh2Fkz1pvE8gSnz8KYn78X+1 8aNL0IxVbfTiUm4q9aqB6sptyTO6WlEakEMijxx0LtsOzZss78pc2nLxZES5gN8WO7ZCulxs0PQh fh4IT8xJ9ubuU517MsQRDc+8Q5IHEov8mfNtWRVGXtXjtu0+BpntAgje6WvERrCDEDKkx8/PD0dh QOI0DEiQoFWTdT4FrUkKVVmzko520VGsibh/B0s8gds8q6QevKFklo/4uJsT5q+OUuHCtzHnar2B FB6hM90reim7J3T+eW7UVPp6R+/ELmIsKAeLnXI0clnJvFNNa2iRq3opC9kY9W5dRdIxw4dxy/jp +hslxBOeYO4K9D2AE0FfN7JZqmbtbor47nUzjMNpnJgmanTsNUvmtMAjeIz55CSOcdAhmjodulGF rHQddEvbcr2t7DTulB6xUBHUgVC9YXE6+0XDgkaDQRAQlf5wfkCAEcxBd2HMKN7X/EuowbNs0Ldt ZngCs3Ehm2dQ5t9tUVM6Qrgwj3+BNgM6fVtxkpB96QWntSfBs4sqa9veF26MjsFwKmZT81gEXQLN tocutMQ1ZWuXmNvF/dyykI1A6UBmMSiTuz1JhAPK3ZWhxsWtjV4cA32QHRbC9d73y+Xc8KqwmAt9 cobeViB+W6Z9ZCB0ah3FnPUvdRPSZt0bhnrWxUFwCXWS6ffMP+5udLZg4C/Obz+ie/3n+/ntwwc7 YXtCw48yWv9XpWF8NsqVkhDd37SkjO2CZ4PgvSc11t3w2KkSHbXrselh4i8FRWLxrhy+DWgdMvEb jDiCVUKESqXCVQq1r20n1+1HtJbdkyrgH2aE2etxNKJQhEeT+xLKvEAwGM/20NV/Olm32lRp7b6+ uLF6sfaLWwAWTsYM4gEthaGFKZ0wZNnPEC7G+PQkmrZYQfuxSPqo0vqcbTZVmVvvsvjyxwMsEe3/ gi1GvW7RJHK61VtjjFNs1HNZyMErK7cS8F6tCQt2i/vePssKtXbOwhn9ydUSXLuvpV5HSD/IbNVI QxbbnJgcli8jcdMiOWyInvH/Ui+wcFQV+GRZFxrML1lToI2Cqr2Cac4eK8Cdbl5RNmax2H3r0KjL Xro1TNrpEIS3v66IeAcNRnvQKOSmUq+72qV8jGLCAjoQgv3K3w8gjfwCBu7Y7Rc326orASydylWF vmTrxyJDC1jB8ied14OO0Hy5ePhgBR08zRibKYizmRMKejAy4DEdlhcd9A46atfBTuZPtarUqpTg Jp81xuWLJ8WYrKzFnhazInSNCde1uyeJblUltVExECpryA9lVeVGydGau5MBxl1katOBcoAUGDTI 4r3oAqZDxUXsE/Lzs6yXTdZ2zTbvto2VHiEOVZiC9k+9ctKwm8SR303mWj/1fPNrpxVU/empXD25 K9OBNT+o28F8gd/0L8qes7LKHku78biS+znXE3U3TJODBQRXnowyhX1p4HQXGSc9bbqff20t7+Nk BEGo+AXLZRQngSIUO4r86ditKeLc1jsJcDXFo5gvJmd+zENTKHVN+W4Acf55joYObOPx2gNLOma5 3Hn7nnVJ/doK7fdWwJmuMeJPOJ/cpMZp2GIpxv1idSCW92XTbYFYt2rbSbCpChbbH5SNYHEEq09N 4Tz8qBBvC2dTY4MdMYoHN/ra4jEjiEbR9IM18AvI4o3DbjsK8uj10iw15mu38LjCJoc9IaHxpKZQ dyNhaf/aHRKSPSh4r+op39kqkoT2QwHyRrVtsNLOkjfoUW21JwkClNIxnGJvBOiwqNN0t7d5Stwr Hco/gBCFVGjhqG28kKHA7w6J6RgLyn7BLipwmNUR69Pcbz551oBHr2HleZboWbnKG3/r6i2iETiM 0tn0g4xhnx1NqMvu0mwHOsPrOTJ2PQdX5RyfSVrWz2Wjas3FIxw6IPpYo6DJMtz6rmHvaVxV9w6b vWYTjJP5EcP+GTvGXKp1VtY9DHI+IglwUdNqRcRC6MwvcReNBLT1fKK5JUkHOad+imiVSO3BIJim jZusewqiUdhyvJEKAr0YMSFSR8tpTRiJPXZplOxj5m7YflOLseoI6Y1ImdipcRyUg+7PKPe9NLHa F4vBzD5o7lPmGxwnwjUYXYAYlZDUXDbtRuZak5ydFmPgjUEPJtegsApQsDP20OcttKYqa5gUS9Wg QuZ2FXp5AmcN6cF3tep0jwujVj03xUYglsRi0qGv0cq82QXH0e894NBal1w7a62y7yH6TnAZGTEu CZ94XP59b7P7RdbZYyXtz9EO9JQIn27MuX1HEQqmlkvZAE4sk1N8EO6xmBYFqUj8qTiOiB+466zJ QdFBqMwF8ZFKwLmf4kSkboprqjQSZB0opBeSoPgApkLj7Qw49ChXZf1P5PQH04OIErSPqN2u+kMp hOpQGsx87IeviQawfqXH+aYpW4m+yu5FNX85tcKUHUb41d3JfwGCqOAYDQplbmRzdHJlYW0NCmVu ZG9iag0KMjMgMCBvYmoNCjIyODINCmVuZG9iag0KMjEgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0K L1BhcmVudCA1IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMSA4IDAgUiANCi9GMiAx MCAwIFIgDQovRjQgMTYgMCBSIA0KL0Y1IDE4IDAgUiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4N Ci9Db250ZW50cyAyMiAwIFINCj4+DQplbmRvYmoNCjI1IDAgb2JqDQo8PA0KL0xlbmd0aCAyNiAw IFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlIA0KPj4NCnN0cmVhbQ0KSIm9V9tu4zYQ/YL8Ax9TIHFI 6kJqX9osNkENNIm7cbsosC+0zNhsZEml5KTu13d4k+Rc1sqLESBIbF5mzsycc/h5fkIwR4zgCU0Q mn85wcj86BU6ubiOUTZh5uOHEzzBxPyVw5do/oxOv9OU/YTmf5/Ek8R+9sX+ztE5nhBud8EqZJeQ qFtzcU32Ds38oROSxX7PpZaoXUv4reU/W6XlRpZtgx4qjZayLqqdKlfoZvbbPVIlEiWCb6WutWok KmX7XOnH5md7bURodysd3OpvpDzbi/I8ijA6hz1uxxGSTzIeYqEZc5t+rZ7RsyqKt9JCjVqVorDJ u7N5YurmToe7aZyyYZznDocQ4oQktMM78hfKUiwKuUS50FpJ/QJDQpJB+ONQtGvOCfEtFb7pwbW3 kxBIQmN3gK3pvcy32q5P+psNrCQhw9RUu/vkIqTmumER3ggqsf191OLGWeajialNNmSooLArLVpV lVDpdo2ms0bmZ+FAPDmYDYn55JjZwFLMYj48tmtByt5ov9eNl2ZpqDexwMAZf85uUWPKDbV0Fecj csepy90Fd6Ri8qibVJz4wbGdargIyAoVYiELtFRNq9Via2sryiWqBdQ319JVu9ZVLpvG3UYTeihX yvlwjvbmbzBU3QIIFHPqT0si2x9w2hziu962W2DU6sGSh5ucjPbk8W4MLD765LA0kBQlkdtzV9eV brelapV0UhAEANRBr6wiyFZXdVWoVjjsv6mldEinpKeIESyJ+/vpQJQEujKyBPwIXaufFJTSZYLJ CBwjHh+9a1lHQRTb+YNN34y2WPCaXBSgtBXaSEhJlaZNG4OkVwB/fMYG2U0IpXQY6VJuAGsvFnEy goqhGkemrr6e6R4RmyaZzp5Se0CaHWaeH6vaxXU0TIbEQbDgz9hL3EyUQBNfVJNvm8ZQwryqVe77 iLBDIUA9jwwdiwKdxCkfYPckdbNt0OX8xh3C98T64ITFnfxHKfPYoGkDVKoasH2iKHaWVvNKa5m3 YPwWopXeksTxmDZLyLGJixDKQsXZHloufTwWINe0HZHHQXEsMiCWAf31rpYv0X+/faP0qKbBWrao wyOmAzyMBQKyllosVBHUP0tG0CiB6+jx9Z+mIRP461Um7gI+RmQGnQs6Q0KNKeVe6ZbVRoCsWeMg mxa8uWrW5gXkOSIbAxL3FvyYdheHiaZx5ifaGA9dFZ3tMHptpvo7pRGMuLfv+EPiDA2QdOEFJ1nV rQI1g3NjQxnSRZuwMTxB2OQ9Xh8aq4h0HZBw3wHTB7SrtkjAhbYPoF7wkFKla2c+1E2c4M5BRjzM cy00BK6g2EZ3AZ2qBLA02lTOqwFY8PyrjWg0Z0avLuDLtXiS5t0L9kZYKySCOvAh41nP3uk/ib3+ 28OMUfUKdIbqAnQfHCyYAOCUx7J6niBfbobHdBvzj6sfQvhCHTHHgSuzhHuunN7M7r7OL2/n6PZu fhVc6kFh5uTofBB1NjtiqZ/cv6AVNmKHmu1io1pXw3YtXFFr400b4XuejZpi57yOOsURDV0KlsV3 +SUYxhp6GzjIPmMa1KyrbbFEC2jDBrSoXEITlnLbalGYTyDRRi0KOfqZw/BxsyTdXCQ0zMXMTYF4 qtTSEhQUSzZnllLMvxuhH6UnYZr1dIQ7Dic8cDgMs9lnJ9ZuNkJtT6pVm8NMo2cF9G64YwiswwuT EawVObU5Kmq8exXh8CryoD1UQCbQ5qiV+bqsimq1Q6KuC+Bk2zBnSG2AZTZdB52BoauLamc+gX82 aqWFwzZKhukDvBHv4A02yPhmo4+w06PhNg2YL6Zxp0bB8zfQn61c7VxZWq1E4Yw38MdB18E+zG+s 03ZMfV/M79D9H59vpnN0iWZfr+6vbueX8+nd7Sfva/kIF2cX9XXfL1Hap01D2u+JFGpqKR6N7ojW +W4Jo9x6TKHGvSaT4Na9hDh13XsWkr5OLNTJNQe09xIJtyXd25MlQQJwFgVJbFVbGHlbunbYF1EW Hp+QKvOgGjbS5oXQ5FrVpr2MckLKOnQHjlx3DOWceqtOYFiCVR/O4j5h71lTs6PjD0bTEHiFpvoZ cP1N/Cc0elICeXPOeiTHuMKY9E6KeycFnrAwdXLL6VA9MCJIr9Cepvo5KUwkv7SL1SSvNnbr1Rye IRbTCJ4j5s1rrobWeDj5DF8x5r4iEwvUCbbnu9Nh/gIBEOzDAvOwNuoGkTEc2RvS+EMPQeaQPIX3 gZfGPrfh/tc7SerCOc3SJHM9S/adJOaZr3EPJLgrz+EHJm3gONO4S5z6NQ/iX99dUK0X3WVeb4yH DonScPUAJMo+5Hkj+hKl9E2Q32onih0lnHKg0lcwdXnDguD6enHDiVVHm0ZMPZ/8vgUGsTZALKpt aw29ZY5gC4BWK+MNnA8CsnG30mwymH2wTQHThGRvjpBrp2hknTplZC9c04CW/RoYgv8BweJJpw0K ZW5kc3RyZWFtDQplbmRvYmoNCjI2IDAgb2JqDQoxODQwDQplbmRvYmoNCjI0IDAgb2JqDQo8PA0K L1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjEg OCAwIFIgDQovRjIgMTAgMCBSIA0KL0YzIDE0IDAgUiANCi9GNCAxNiAwIFIgDQo+Pg0KL1Byb2NT ZXQgMiAwIFINCj4+DQovQ29udGVudHMgMjUgMCBSDQo+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PA0K L1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05hbWUgL0YwDQovQmFzZUZvbnQgL0Fy aWFsLEJvbGQNCi9GaXJzdENoYXIgMzENCi9MYXN0Q2hhciAyNTUNCi9XaWR0aHMgWyA3NTAgMjc4 IDMzMyA0NzQgNTU2IDU1NiA4ODkgNzIyIDIzOCAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzgg DQoyNzggNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDMzMyAzMzMgNTg0 IDU4NCA1ODQgDQo2MTEgOTc1IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDU1 NiA3MjIgNjExIDgzMyA3MjIgDQo3NzggNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2 NjcgNjY3IDYxMSAzMzMgMjc4IDMzMyA1ODQgDQo1NTYgMzMzIDU1NiA2MTEgNTU2IDYxMSA1NTYg MzMzIDYxMSA2MTEgMjc4IDI3OCA1NTYgMjc4IDg4OSA2MTEgDQo2MTEgNjExIDYxMSAzODkgNTU2 IDMzMyA2MTEgNTU2IDc3OCA1NTYgNTU2IDUwMCAzODkgMjgwIDM4OSA1ODQgDQo3NTAgNTU2IDc1 MCAyNzggNTU2IDUwMCAxMDAwIDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyA2NjcgNjExIDYxMSAN CjYxMSA3NTAgMjc4IDI3OCA1MDAgNTAwIDM1MCA1NTYgMTAwMCAzMzMgMTAwMCA1NTYgMzMzIDU1 NiA0NzkgNTAwIA0KNTAwIDI3OCAzMzMgMzMzIDYxMSA1NTYgNzIyIDI4MCA1NTYgMzMzIDczNyA2 NjcgNTU2IDU4NCAzMzMgNzM3IA0KNjExIDQwMCA1NDkgMzMzIDI3OCAzMzMgNTc2IDU1NiAyNzgg MzMzIDU1NiA1NTYgNTU2IDYxMSAzMzMgMzg1IA0KNTAwIDcyMiA3MjIgNzIyIDcyMiA3MjIgNjEx IDcyMiA3MjIgNzIyIDY2NyA2NjcgNjY3IDY2NyAyNzggMjc4IA0KNzIyIDcyMiA3MjIgNzIyIDc3 OCA3NzggNzc4IDc3OCA1ODQgNzIyIDcyMiA3MjIgNzIyIDcyMiA2NjcgNjExIA0KNjExIDM4OSA1 NTYgNTU2IDU1NiA1NTYgMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IA0K NzE5IDYxMSA2MTEgNjExIDYxMSA2MTEgNjExIDYxMSA1NDkgMzg5IDYxMSA2MTEgNjExIDYxMSA1 NTYgMzMzIA0KMzMzIF0NCi9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQovRm9udERlc2NyaXB0 b3IgNyAwIFINCj4+DQplbmRvYmoNCjcgMCBvYmoNCjw8DQovVHlwZSAvRm9udERlc2NyaXB0b3IN Ci9Gb250TmFtZSAvQXJpYWwsQm9sZA0KL0ZsYWdzIDE2NDE2DQovRm9udEJCb3ggWyAtMjUwIC0y MTEgMTMyNiA5NDcgXQ0KL01pc3NpbmdXaWR0aCA3MzcNCi9TdGVtViAxNTENCi9TdGVtSCAxNTEN Ci9JdGFsaWNBbmdsZSAwDQovQ2FwSGVpZ2h0IDk0Nw0KL1hIZWlnaHQgNjYyDQovQXNjZW50IDk0 Nw0KL0Rlc2NlbnQgLTIxMQ0KL0xlYWRpbmcgMjExDQovTWF4V2lkdGggMTEwNQ0KL0F2Z1dpZHRo IDQ3NA0KPj4NCmVuZG9iag0KOCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1 ZVR5cGUNCi9OYW1lIC9GMQ0KL0Jhc2VGb250IC9BcmlhbA0KL0ZpcnN0Q2hhciAzMQ0KL0xhc3RD aGFyIDI1NQ0KL1dpZHRocyBbIDc1MCAyNzggMjc4IDM1NSA1NTYgNTU2IDg4OSA2NjcgMTkxIDMz MyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCANCjI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1 NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgNTg0IDU4NCANCjU1NiAxMDE1IDY2NyA2NjcgNzIy IDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDUwMCA2NjcgNTU2IDgzMyA3MjIgDQo3NzggNjY3IDc3 OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAyNzggMjc4IDI3OCA0NjkgDQo1 NTYgMzMzIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgz MyA1NTYgDQo1NTYgNTU2IDU1NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAz MzQgMjYwIDMzNCA1ODQgDQo3NTAgNTU2IDc1MCAyMjIgNTU2IDMzMyAxMDAwIDU1NiA1NTYgMzMz IDEwMDAgNjY3IDMzMyA2NjcgNjExIDYxMSANCjYxMSA3NTAgMjIyIDIyMiAzMzMgMzMzIDM1MCA1 NTYgMTAwMCAzMzMgMTAwMCA1MDAgMzMzIDUwMCAzNzUgNTAwIA0KNTAwIDI3OCAzMzMgMzMzIDU1 NiA1NTYgNjY3IDI2MCA1NTYgMzMzIDczNyA2NjcgNTU2IDU4NCAzMzMgNzM3IA0KNjExIDQwMCA1 NDkgMzMzIDIyMiAzMzMgNTc2IDUzNyAyNzggMzMzIDU1NiA1MDAgNTU2IDU1NiAzMzMgMjkyIA0K NTAwIDcyMiA2NjcgNjY3IDY2NyA2NjcgNTU2IDcyMiA3MjIgNzIyIDY2NyA2NjcgNjY3IDY2NyAy NzggMjc4IA0KNzIyIDcyMiA3MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA1ODQgNzIyIDcyMiA3MjIg NzIyIDcyMiA2NjcgNjExIA0KNjExIDMzMyA1NTYgNTU2IDU1NiA1NTYgMjIyIDUwMCA1MDAgNTAw IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IA0KNjE1IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1 NiA1NDkgMzMzIDU1NiA1NTYgNTU2IDU1NiA1MDAgMjc4IA0KMzMzIF0NCi9FbmNvZGluZyAvV2lu QW5zaUVuY29kaW5nDQovRm9udERlc2NyaXB0b3IgOSAwIFINCj4+DQplbmRvYmoNCjkgMCBvYmoN Cjw8DQovVHlwZSAvRm9udERlc2NyaXB0b3INCi9Gb250TmFtZSAvQXJpYWwNCi9GbGFncyAzMg0K L0ZvbnRCQm94IFsgLTI1MCAtMjMxIDEyOTIgMTAwMCBdDQovTWlzc2luZ1dpZHRoIDc2OQ0KL1N0 ZW1WIDg0DQovU3RlbUggODQNCi9JdGFsaWNBbmdsZSAwDQovQ2FwSGVpZ2h0IDEwMDANCi9YSGVp Z2h0IDcwMA0KL0FzY2VudCAxMDAwDQovRGVzY2VudCAtMjMxDQovTGVhZGluZyAyMzENCi9NYXhX aWR0aCAxMDc3DQovQXZnV2lkdGggNDYyDQo+Pg0KZW5kb2JqDQoxMCAwIG9iag0KPDwNCi9UeXBl IC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5cGUNCi9OYW1lIC9GMg0KL0Jhc2VGb250IC9BcmlhbCxJ dGFsaWMNCi9GaXJzdENoYXIgMzENCi9MYXN0Q2hhciAyNTUNCi9XaWR0aHMgWyA3NTAgMjc4IDI3 OCAzNTUgNTU2IDU1NiA4ODkgNjY3IDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggDQoy NzggNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggNTg0IDU4 NCA1ODQgDQo1NTYgMTAxNSA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAg NjY3IDU1NiA4MzMgNzIyIA0KNzc4IDY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3 IDY2NyA2MTEgMjc4IDI3OCAyNzggNDY5IA0KNTU2IDMzMyA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3 OCA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IA0KNTU2IDU1NiA1NTYgMzMzIDUwMCAy NzggNTU2IDUwMCA3MjIgNTAwIDUwMCA1MDAgMzM0IDI2MCAzMzQgNTg0IA0KNzUwIDU1NiA3NTAg MjIyIDU1NiAzMzMgMTAwMCA1NTYgNTU2IDMzMyAxMDAwIDY2NyAzMzMgNjY3IDYxMSA2MTEgDQo2 MTEgNzUwIDIyMiAyMjIgMzMzIDMzMyAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTAwIDMzMyA1MDAg MzU0IDUwMCANCjUwMCAyNzggMzMzIDMzMyA1NTYgNTU2IDY2NyAyNjAgNTU2IDMzMyA3MzcgNjY3 IDU1NiA1ODQgMzMzIDczNyANCjYxMSA0MDAgNTQ5IDMzMyAyMjIgMzMzIDU3NiA1MzcgMjc4IDMz MyA1NTYgNTAwIDU1NiA1NTYgMzMzIDI4MSANCjUwMCA3MjIgNjY3IDY2NyA2NjcgNjY3IDU1NiA3 MjIgNzIyIDcyMiA2NjcgNjY3IDY2NyA2NjcgMjc4IDI3OCANCjcyMiA3MjIgNzIyIDcyMiA3Nzgg Nzc4IDc3OCA3NzggNTg0IDcyMiA3MjIgNzIyIDcyMiA3MjIgNjY3IDYxMSANCjYxMSAzMzMgNTU2 IDU1NiA1NTYgNTU2IDIyMiA1MDAgNTAwIDUwMCA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCANCjYy NSA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTQ5IDMzMyA1NTYgNTU2IDU1NiA1NTYgNTAw IDI3OCANCjMzMyBdDQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0KL0ZvbnREZXNjcmlwdG9y IDExIDAgUg0KPj4NCmVuZG9iag0KMTEgMCBvYmoNCjw8DQovVHlwZSAvRm9udERlc2NyaXB0b3IN Ci9Gb250TmFtZSAvQXJpYWwsSXRhbGljDQovRmxhZ3MgOTYNCi9Gb250QkJveCBbIC0yNTAgLTIz MSAxMjkyIDEwMDAgXQ0KL01pc3NpbmdXaWR0aCA3NjkNCi9TdGVtViA4NA0KL1N0ZW1IIDg0DQov SXRhbGljQW5nbGUgLTExDQovQ2FwSGVpZ2h0IDEwMDANCi9YSGVpZ2h0IDcwMA0KL0FzY2VudCAx MDAwDQovRGVzY2VudCAtMjMxDQovTGVhZGluZyAyMzENCi9NYXhXaWR0aCAxMDc3DQovQXZnV2lk dGggNDYyDQo+Pg0KZW5kb2JqDQoxNCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAv VHJ1ZVR5cGUNCi9OYW1lIC9GMw0KL0Jhc2VGb250IC9BcmlhbCxCb2xkSXRhbGljDQovRmlyc3RD aGFyIDMxDQovTGFzdENoYXIgMjU1DQovV2lkdGhzIFsgNzUwIDI3OCAzMzMgNDc0IDU1NiA1NTYg ODg5IDcyMiAyMzggMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4IA0KMjc4IDU1NiA1NTYgNTU2 IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAzMzMgMzMzIDU4NCA1ODQgNTg0IA0KNjExIDk3 NSA3MjIgNzIyIDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1NTYgNzIyIDYxMSA4MzMgNzIy IA0KNzc4IDY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2MTEgMzMzIDI3 OCAzMzMgNTg0IA0KNTU2IDMzMyA1NTYgNjExIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAy NzggNTU2IDI3OCA4ODkgNjExIA0KNjExIDYxMSA2MTEgMzg5IDU1NiAzMzMgNjExIDU1NiA3Nzgg NTU2IDU1NiA1MDAgMzg5IDI4MCAzODkgNTg0IA0KNzUwIDU1NiA3NTAgMjc4IDU1NiA1MDAgMTAw MCA1NTYgNTU2IDMzMyAxMDAwIDY2NyAzMzMgNjY3IDYxMSA2MTEgDQo2MTEgNzUwIDI3OCAyNzgg NTAwIDUwMCAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTU2IDMzMyA1NTYgNDc5IDUwMCANCjUwMCAy NzggMzMzIDMzMyA2MTEgNTU2IDcyMiAyODAgNTU2IDMzMyA3MzcgNjY3IDU1NiA1ODQgMzMzIDcz NyANCjYxMSA0MDAgNTQ5IDMzMyAyNzggMzMzIDU3NiA1NTYgMjc4IDMzMyA1NTYgNTU2IDU1NiA2 MTEgMzMzIDM5NiANCjUwMCA3MjIgNzIyIDcyMiA3MjIgNzIyIDYxMSA3MjIgNzIyIDcyMiA2Njcg NjY3IDY2NyA2NjcgMjc4IDI3OCANCjcyMiA3MjIgNzIyIDcyMiA3NzggNzc4IDc3OCA3NzggNTg0 IDcyMiA3MjIgNzIyIDcyMiA3MjIgNjY3IDYxMSANCjYxMSAzODkgNTU2IDU1NiA1NTYgNTU2IDI3 OCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCANCjc0MCA2MTEgNjExIDYxMSA2 MTEgNjExIDYxMSA2MTEgNTQ5IDM4OSA2MTEgNjExIDYxMSA2MTEgNTU2IDMzMyANCjMzMyBdDQov RW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0KL0ZvbnREZXNjcmlwdG9yIDE1IDAgUg0KPj4NCmVu ZG9iag0KMTUgMCBvYmoNCjw8DQovVHlwZSAvRm9udERlc2NyaXB0b3INCi9Gb250TmFtZSAvQXJp YWwsQm9sZEl0YWxpYw0KL0ZsYWdzIDE2NDgwDQovRm9udEJCb3ggWyAtMjUwIC0yMzEgMTIwMCAx MDAwIF0NCi9NaXNzaW5nV2lkdGggNzY5DQovU3RlbVYgMTQ4DQovU3RlbUggMTQ4DQovSXRhbGlj QW5nbGUgLTExDQovQ2FwSGVpZ2h0IDEwMDANCi9YSGVpZ2h0IDcwMA0KL0FzY2VudCAxMDAwDQov RGVzY2VudCAtMjMxDQovTGVhZGluZyAyMzENCi9NYXhXaWR0aCAxMDAwDQovQXZnV2lkdGggNDYy DQo+Pg0KZW5kb2JqDQoxNiAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5 cGUNCi9OYW1lIC9GNA0KL0Jhc2VGb250IC9TeW1ib2wNCi9GaXJzdENoYXIgMzENCi9MYXN0Q2hh ciAyNTUNCi9XaWR0aHMgWyA2MDAgMjUwIDMzMyA3MTMgNTAwIDU0OSA4MzMgNzc4IDQzOSAzMzMg MzMzIDUwMCA1NDkgMjUwIDU0OSAyNTAgDQoyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAw IDUwMCA1MDAgNTAwIDI3OCAyNzggNTQ5IDU0OSA1NDkgDQo0NDQgNTQ5IDcyMiA2NjcgNzIyIDYx MiA2MTEgNzYzIDYwMyA3MjIgMzMzIDYzMSA3MjIgNjg2IDg4OSA3MjIgDQo3MjIgNzY4IDc0MSA1 NTYgNTkyIDYxMSA2OTAgNDM5IDc2OCA2NDUgNzk1IDYxMSAzMzMgODYzIDMzMyA2NTggDQo1MDAg NTAwIDYzMSA1NDkgNTQ5IDQ5NCA0MzkgNTIxIDQxMSA2MDMgMzI5IDYwMyA1NDkgNTQ5IDU3NiA1 MjEgDQo1NDkgNTQ5IDUyMSA1NDkgNjAzIDQzOSA1NzYgNzEzIDY4NiA0OTMgNjg2IDQ5NCA0ODAg MjAwIDQ4MCA1NDkgDQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDQo2MDAgNjAwIDYyMCAyNDcgNTQ5IDE2NyA3 MTMgNTAwIDc1MyA3NTMgNzUzIDc1MyAxMDQyIDk4NyA2MDMgOTg3IA0KNjAzIDQwMCA1NDkgNDEx IDU0OSA1NDkgNzEzIDQ5NCA0NjAgNTQ5IDU0OSA1NDkgNTQ5IDEwMDAgNjAzIDEwMDAgDQo2NTgg ODIzIDY4NiA3OTUgOTg3IDc2OCA3NjggODIzIDc2OCA3NjggNzEzIDcxMyA3MTMgNzEzIDcxMyA3 MTMgDQo3MTMgNzY4IDcxMyA3OTAgNzkwIDg5MCA4MjMgNTQ5IDI1MCA3MTMgNjAzIDYwMyAxMDQy IDk4NyA2MDMgOTg3IA0KNjAzIDQ5NCAzMjkgNzkwIDc5MCA3ODYgNzEzIDM4NCAzODQgMzg0IDM4 NCAzODQgMzg0IDQ5NCA0OTQgNDk0IA0KNDk0IDYwMCAzMjkgMjc0IDY4NiA2ODYgNjg2IDM4NCAz ODQgMzg0IDM4NCAzODQgMzg0IDQ5NCA0OTQgNDk0IA0KNjAwIF0NCi9Gb250RGVzY3JpcHRvciAx NyAwIFINCj4+DQplbmRvYmoNCjE3IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQov Rm9udE5hbWUgL1N5bWJvbA0KL0ZsYWdzIDYNCi9Gb250QkJveCBbIC0yNTAgLTIzMSAxMjkyIDEw MDAgXQ0KL01pc3NpbmdXaWR0aCA2MTUNCi9TdGVtViAxMTINCi9TdGVtSCAxMTINCi9JdGFsaWNB bmdsZSAwDQovQ2FwSGVpZ2h0IDEwMDANCi9YSGVpZ2h0IDcwMA0KL0FzY2VudCAxMDAwDQovRGVz Y2VudCAtMjMxDQovTGVhZGluZyAyMzENCi9NYXhXaWR0aCAxMDc3DQovQXZnV2lkdGggNjE1DQo+ Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5cGUN Ci9OYW1lIC9GNQ0KL0Jhc2VGb250IC9Db3VyaWVyTmV3DQovRmlyc3RDaGFyIDMxDQovTGFzdENo YXIgMjU1DQovV2lkdGhzIFsgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA0KNjAwIF0NCi9FbmNvZGluZyAvV2luQW5zaUVu Y29kaW5nDQovRm9udERlc2NyaXB0b3IgMTkgMCBSDQo+Pg0KZW5kb2JqDQoxOSAwIG9iag0KPDwN Ci9UeXBlIC9Gb250RGVzY3JpcHRvcg0KL0ZvbnROYW1lIC9Db3VyaWVyTmV3DQovRmxhZ3MgMzUN Ci9Gb250QkJveCBbIC0yNTAgLTMwOCA3MzggOTIzIF0NCi9NaXNzaW5nV2lkdGggNjE1DQovU3Rl bVYgMTEyDQovU3RlbUggMTEyDQovSXRhbGljQW5nbGUgMA0KL0NhcEhlaWdodCA5MjMNCi9YSGVp Z2h0IDY0Ng0KL0FzY2VudCA5MjMNCi9EZXNjZW50IC0zMDgNCi9MZWFkaW5nIDIzMQ0KL01heFdp ZHRoIDYxNQ0KL0F2Z1dpZHRoIDYxNQ0KPj4NCmVuZG9iag0KMiAwIG9iag0KWyAvUERGIC9UZXh0 ICBdDQplbmRvYmoNCjUgMCBvYmoNCjw8DQovS2lkcyBbNCAwIFIgMjEgMCBSIDI0IDAgUiBdDQov Q291bnQgMw0KL1R5cGUgL1BhZ2VzDQovTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdDQo+Pg0KZW5k b2JqDQoxIDAgb2JqDQo8PA0KL0NyZWF0b3IgPEZFRkYwMDREMDA1MDAwNEMwMDUzMDA2MzAwNkYw MDZFMDAyMDAwNDMwMDYxMDA2QzAwNkMwMDIwMDA2NjAwNkYwMDcyMDAyMDAwNTAwMDcyMDA2NTAw NzMwMDY1MDA2RTAwNzQwMDYxMDA3NDAwNjkwMDZGMDA2RTAwNzMwMDIwMDAyRDAwMjAwMDREMDA2 OTAwNjMwMDcyMDA2RjAwNzMwMDZGMDA2NjAwNzQwMDIwMDA1NzAwNkYwMDcyMDA2ND4NCi9DcmVh dGlvbkRhdGUgKEQ6MjAwMDA5MDgwMjI4MTQpDQovVGl0bGUgPEZFRkYwMDREMDA1MDAwNEMwMDUz MDA2MzAwNkYwMDZFMDA0MzAwNDYwMDUwPg0KL1Byb2R1Y2VyIChBY3JvYmF0IFBERldyaXRlciA0 LjAgZm9yIFdpbmRvd3MpDQo+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PA0KL1BhZ2VzIDUgMCBSDQov VHlwZSAvQ2F0YWxvZw0KL0RlZmF1bHRHcmF5IDI3IDAgUg0KL0RlZmF1bHRSR0IgIDI4IDAgUg0K Pj4NCmVuZG9iag0KMjcgMCBvYmoNClsvQ2FsR3JheQ0KPDwNCi9XaGl0ZVBvaW50IFswLjk1MDUg MSAxLjA4OTEgXQ0KL0dhbW1hIDAuMjQ2OCANCj4+DQpdDQplbmRvYmoNCjI4IDAgb2JqDQpbL0Nh bFJHQg0KPDwNCi9XaGl0ZVBvaW50IFswLjk1MDUgMSAxLjA4OTEgXQ0KL0dhbW1hIFswLjI0Njgg MC4yNDY4IDAuMjQ2OCBdDQovTWF0cml4IFswLjQzNjEgMC4yMjI1IDAuMDEzOSAwLjM4NTEgMC43 MTY5IDAuMDk3MSAwLjE0MzEgMC4wNjA2IDAuNzE0MSBdDQo+Pg0KXQ0KZW5kb2JqDQp4cmVmDQow IDI5DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMTYyNTAgMDAwMDAgbg0KMDAwMDAxNjExMCAw MDAwMCBuDQowMDAwMDE2NjE2IDAwMDAwIG4NCjAwMDAwMDI4MzcgMDAwMDAgbg0KMDAwMDAxNjE0 NCAwMDAwMCBuDQowMDAwMDA3NzM5IDAwMDAwIG4NCjAwMDAwMDg4NTcgMDAwMDAgbg0KMDAwMDAw OTEzOCAwMDAwMCBuDQowMDAwMDEwMjUyIDAwMDAwIG4NCjAwMDAwMTA1MjYgMDAwMDAgbg0KMDAw MDAxMTY0OSAwMDAwMCBuDQowMDAwMDAwMDIxIDAwMDAwIG4NCjAwMDAwMDI4MTMgMDAwMDAgbg0K MDAwMDAxMTkzMyAwMDAwMCBuDQowMDAwMDEzMDU5IDAwMDAwIG4NCjAwMDAwMTMzNTIgMDAwMDAg bg0KMDAwMDAxNDQ0MCAwMDAwMCBuDQowMDAwMDE0NzE3IDAwMDAwIG4NCjAwMDAwMTU4MzMgMDAw MDAgbg0KMDAwMDAwMjk1NyAwMDAwMCBuDQowMDAwMDA1NDQ1IDAwMDAwIG4NCjAwMDAwMDMwNTMg MDAwMDAgbg0KMDAwMDAwNTQyMSAwMDAwMCBuDQowMDAwMDA3NTY3IDAwMDAwIG4NCjAwMDAwMDU2 MTcgMDAwMDAgbg0KMDAwMDAwNzU0MyAwMDAwMCBuDQowMDAwMDE2NzEzIDAwMDAwIG4NCjAwMDAw MTY4MDEgMDAwMDAgbg0KdHJhaWxlcg0KPDwNCi9TaXplIDI5DQovUm9vdCAzIDAgUg0KL0luZm8g MSAwIFINCi9JRCBbPDkzMDBiZTRlYzEwZjExNzIxMWFkMjg5ZDY5YjhlM2EwPjw5MzAwYmU0ZWMx MGYxMTcyMTFhZDI4OWQ2OWI4ZTNhMD5dDQo+Pg0Kc3RhcnR4cmVmDQoxNjk3OQ0KJSVFT0YNCg== ------_=_NextPart_000_01C0195C.497680C4-- From owner-mpls@UU.NET Fri Sep 8 10:00:23 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22792 for ; Fri, 8 Sep 2000 10:00:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfto28414; Fri, 8 Sep 2000 14:00:14 GMT Received: by mail-control.mail.uu.net id QQjftn05061 for mpls-outgoing; Fri, 8 Sep 2000 13:59:56 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjftn05056 for ; Fri, 8 Sep 2000 13:59:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjftn00816 for ; Fri, 8 Sep 2000 09:59:41 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjftn27781 for ; Fri, 8 Sep 2000 13:59:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA00627 for mpls@uu.net; Fri, 8 Sep 2000 09:58:00 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjftn04986 for ; Fri, 8 Sep 2000 13:57:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjftn24788; Fri, 8 Sep 2000 09:57:23 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjftn00272; Fri, 8 Sep 2000 13:57:19 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA01996; Fri, 8 Sep 2000 09:57:11 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA10551; Fri, 8 Sep 2000 09:57:10 -0400 (EDT) Message-Id: <200009081357.JAA10551@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Randy Bush cc: Cheenu Srinivasan , "'Jim Boyle'" , mpls@UU.NET, te-wg@UU.NET, swallow@cisco.com Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt In-reply-to: Your message of "Thu, 07 Sep 2000 20:50:48 +0200." Date: Fri, 08 Sep 2000 09:57:10 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Randy - > the tewg has been asked by the iesg to take up the te mib. Are you speaking for yourself as an AD or is the entine IESG behind this? I thought some of the key goals of the IESG was to limit duplication of efforts and to promote peace among work groups. As far as I concerned you are failing at both. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Sep 8 10:09:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23021 for ; Fri, 8 Sep 2000 10:09:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfto06383; Fri, 8 Sep 2000 14:09:15 GMT Received: by mail-control.mail.uu.net id QQjfto17504 for mpls-outgoing; Fri, 8 Sep 2000 14:08:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfto17496 for ; Fri, 8 Sep 2000 14:08:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfto02523; Fri, 8 Sep 2000 10:08:20 -0400 (EDT) Received: from roam.psg.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: randy.workshop.sigz.net [195.149.150.111]) id QQjfto05559; Fri, 8 Sep 2000 14:08:19 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13XOp4-0000GP-00; Fri, 08 Sep 2000 16:08:06 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: George Swallow Cc: Cheenu Srinivasan , "'Jim Boyle'" , mpls@UU.NET, te-wg@UU.NET Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt References: <200009081357.JAA10551@lir.cisco.com> Message-Id: Date: Fri, 08 Sep 2000 16:08:06 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >> the tewg has been asked by the iesg to take up the te mib. > Are you speaking for yourself as an AD or is the entine IESG behind > this? i spoke, well wrote, precisely. > I thought some of the key goals of the IESG was to limit duplication > of efforts and to promote peace among work groups. As far as I > concerned you are failing at both. we're doing the best we can with the goal of good technical solutions. randy From owner-mpls@UU.NET Fri Sep 8 10:12:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23129 for ; Fri, 8 Sep 2000 10:12:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfto09998; Fri, 8 Sep 2000 14:12:38 GMT Received: by mail-control.mail.uu.net id QQjfto17950 for mpls-outgoing; Fri, 8 Sep 2000 14:12:17 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfto17945 for ; Fri, 8 Sep 2000 14:12:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfto03409 for ; Fri, 8 Sep 2000 10:12:05 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjfto08695 for ; Fri, 8 Sep 2000 14:11:35 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA14042; Fri, 8 Sep 2000 07:11:55 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA02469; Fri, 8 Sep 2000 10:11:33 -0400 (EDT) Message-Id: <200009081411.KAA02469@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Randy Bush cc: Robert Raszuk , Robert Raszuk , Ramana V Gollamudi , Sitarama R Kalipatnapu , bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service In-reply-to: Your message of Thu, 07 Sep 2000 21:21:12 +0200. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 08 Sep 2000 10:11:32 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Randy> for a scary example of one small aspect of the current bgp mess While it may be true that Internet routing is a mess, it is disingenuous to blame that on BGP. BGP is the routing technology that allows the Internet to scale as well as it does (which is pretty damn well), and nothing better is known. The "messiness" is not due to any inherent characteristic of BGP, but to the messiness of the Internet routing environment itself, with so many providers who don't trust each other and can barely cooperate. BGP did not create the mess, it is just the best way we know of coping with it. There's certainly no reason why BGP should not be used to advantage in a less messy environment, it is after all the most scalable routing protocol known. (Outside of the research community, at least.) But as is clearly stated in RFC2547, it is not aimed at supporting VPNs over the Internet, so the messiness of the Internet routing environment is irrelevant. From owner-mpls@UU.NET Fri Sep 8 10:32:14 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23524 for ; Fri, 8 Sep 2000 10:32:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjftq28217; Fri, 8 Sep 2000 14:32:11 GMT Received: by mail-control.mail.uu.net id QQjftq19304 for mpls-outgoing; Fri, 8 Sep 2000 14:31:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjftq19298 for ; Fri, 8 Sep 2000 14:31:32 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjftq01982 for ; Fri, 8 Sep 2000 10:31:30 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjftq27056 for ; Fri, 8 Sep 2000 14:30:59 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA02812; Fri, 8 Sep 2000 07:31:18 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA02520; Fri, 8 Sep 2000 10:30:57 -0400 (EDT) Message-Id: <200009081430.KAA02520@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "Ramana V Gollamudi" cc: raszuk@cisco.com, Sitarama R Kalipatnapu , bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service In-reply-to: Your message of Thu, 07 Sep 2000 11:23:12 -0400. <39B7B2E0.4E6FE220@alcatel.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 08 Sep 2000 10:30:57 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Ramana> What happens if the VPN feeds a lot of routes at different points Ramana> into different PE edge boxes ( for example - each CE is a 7-Eleven Ramana> feeding only few routes)? There are a number of techniques which can be used to improve the aggregatibility. In this particular case, I think it unlikely that each of the 100,000 7-11 stores connects to a different PE router. Each store probably connects directly to an access network of some sort which attaches a whole bunch of stores to a single PE router, where they can all be homed to the same VRF. From owner-mpls@UU.NET Fri Sep 8 10:38:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23659 for ; Fri, 8 Sep 2000 10:38:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjftq04273; Fri, 8 Sep 2000 14:38:42 GMT Received: by mail-control.mail.uu.net id QQjftq19572 for mpls-outgoing; Fri, 8 Sep 2000 14:38:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjftq19567 for ; Fri, 8 Sep 2000 14:38:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjftq03201 for ; Fri, 8 Sep 2000 10:38:13 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjftq03663 for ; Fri, 8 Sep 2000 14:38:12 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA07233; Fri, 8 Sep 2000 07:38:31 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA02545; Fri, 8 Sep 2000 10:38:10 -0400 (EDT) Message-Id: <200009081438.KAA02545@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Randy Bush cc: Robert Raszuk , Robert Raszuk , Ramana V Gollamudi , Sitarama R Kalipatnapu , bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service In-reply-to: Your message of Fri, 08 Sep 2000 16:19:12 +0200. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 08 Sep 2000 10:38:10 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Randy> then why are we discussing it in the ietf? i guess we should should Randy> have the rfc made irrelevant. It is being discussed in the IETF because (a) there are a large number of service providers who find the technology useful, (b) the service providers want public standards to ensure multi-vendor interoperability of the technology, (c) the technology is IP-based, and (d) the IETF is the place for setting standards based on IP technology. However, you may wish to take this up further with the Area Directors. From owner-mpls@UU.NET Fri Sep 8 10:41:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23704 for ; Fri, 8 Sep 2000 10:41:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjftq06505; Fri, 8 Sep 2000 14:41:37 GMT Received: by mail-control.mail.uu.net id QQjftq19815 for mpls-outgoing; Fri, 8 Sep 2000 14:41:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjftq19730 for ; Fri, 8 Sep 2000 14:41:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjftq08995 for ; Fri, 8 Sep 2000 10:41:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjftq05808 for ; Fri, 8 Sep 2000 14:41:01 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA04421 for ; Fri, 8 Sep 2000 07:41:22 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA02580 for mpls@uu.net; Fri, 8 Sep 2000 10:40:59 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfpz29220 for ; Thu, 7 Sep 2000 14:47:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfpz11487 for ; Thu, 7 Sep 2000 10:47:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjfpz02199 for ; Thu, 7 Sep 2000 14:47: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 KAA15763 for ; Thu, 7 Sep 2000 10:47:51 -0400 (EDT) Received: from fore.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 KAA11374 for ; Thu, 7 Sep 2000 10:47:53 -0400 (EDT) Message-ID: <39B7AA9E.4E7C480D@fore.com> Date: Thu, 07 Sep 2000 10:47:58 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Question on RSVP_TE References: <200009062138.RAA08542@lir.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George Swallow wrote: > > RSVP objects are always a multiple of 4. The name sits in the final > bytes of the object with the length delimited by the object length. > But if the session name is not a multiple of 4 bytes you get some core > residue at the end. The Name Length allows you to pick out just the > name. Also note that the name, in the session-atrtributes object is _NOT_ a null-terminated string. It is a counted string, whose length is the name-length field of the object. When using these strings in C, be sure to allocate at least one extra byte and explicitly append a NULL character. Do _NOT_ assume that the session attribute object will have a NULL character following the last character of the name. If the name length is a multiple of 4, then the byte following the name will be the first byte of the next object in the message, which could be non-zero. -- David From owner-mpls@UU.NET Fri Sep 8 10:44:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23755 for ; Fri, 8 Sep 2000 10:44:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjftq10008; Fri, 8 Sep 2000 14:44:01 GMT Received: by mail-control.mail.uu.net id QQjftq20070 for mpls-outgoing; Fri, 8 Sep 2000 14:43:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjftq20059 for ; Fri, 8 Sep 2000 14:43:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjftq04458 for ; Fri, 8 Sep 2000 10:43:27 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjftq08439 for ; Fri, 8 Sep 2000 14:43:12 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA05762 for ; Fri, 8 Sep 2000 07:43:32 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA02609 for mpls@uu.net; Fri, 8 Sep 2000 10:43:10 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfsh00984 for ; Fri, 8 Sep 2000 05:55:43 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfsh26449 for ; Fri, 8 Sep 2000 01:55:41 -0400 (EDT) Received: from mta4.263.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.44.46]) id QQjfsh18326 for ; Fri, 8 Sep 2000 05:55:39 GMT Received: by mta4.263.net (Postfix, from userid 60001) id EB94A1C2E8E02; Fri, 8 Sep 2000 09:56:04 +0800 (CST) MIME-Version: 1.0 Message-Id: <39B84734.16173@mta4> Date: Fri, 8 Sep 2000 09:56:04 +0800 (CST) From: "³Ë·ã" To: mpls@UU.NET Subject: question X-Priority: 3 X-Originating-IP: [210.77.224.144] Sender: owner-mpls@UU.NET Precedence: bulk Content-Type: text/plain; charset=unknown-8bit X-MIME-Autoconverted: from 8bit to base64 by wodc7mr1.ffx.ops.us.uu.net id QQjftq10008 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA23755 Dear Sir: i'm a researcher interested in MPLS technology now. But my interest mainly lies in the MPLS application in Wireless ATM backbone network. I didn't see any standards about it.Could you please give me some advice on this area. Best Regards! _____________________________________________ Ê׶¼ÔÚÏß--ÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net @263.netÖйú×î´óµÄÔÚÏßÓÊ¾Ö http://freemail.263.net ÖйúÈ˵ÄÔÚÏß¹ºÎïÀÖÔ°¡ª¡ª263ÉÌ³Ç http://shopping.263.net From owner-mpls@UU.NET Fri Sep 8 10:44:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23767 for ; Fri, 8 Sep 2000 10:44:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjftq09756; Fri, 8 Sep 2000 14:44:14 GMT Received: by mail-control.mail.uu.net id QQjftq20075 for mpls-outgoing; Fri, 8 Sep 2000 14:43:45 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjftq20051 for ; Fri, 8 Sep 2000 14:43:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjftq09539 for ; Fri, 8 Sep 2000 10:43:07 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjftq07850 for ; Fri, 8 Sep 2000 14:42:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA05362 for ; Fri, 8 Sep 2000 07:42:57 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA02599 for mpls@uu.net; Fri, 8 Sep 2000 10:42:35 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfqk20231 for ; Thu, 7 Sep 2000 17:42:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfqk20491; Thu, 7 Sep 2000 13:42:36 -0400 (EDT) Received: from miles.dataconnection.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQjfqk16825; Thu, 7 Sep 2000 17:42:35 GMT Received: by smtp2.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 18:42:32 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA12A@monk.datcon.co.uk> From: Adrian Farrel To: Sudhanshu Jain , Arun Viswanathan , mpls@UU.NET, te-wg@UU.NET, "Thomas D. Nadeau" Subject: RE: draft-kompella-mpls-te-mib-00.txt Date: Thu, 7 Sep 2000 18:42:22 +0100 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 Sudhanshu, I think Tom extended the MIB to support its use at transit LSRs one (or two?) versions ago. As far as I can see there are a few extensions still needed (possibly to the signaling protocol!) to make this work really smoothly, but it is almost there. Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Sudhanshu Jain [mailto:sjain@maplenetworks.com] >Sent: Thursday, September 07, 2000 6:34 PM >To: Arun Viswanathan; mpls@UU.NET; te-wg@UU.NET; Thomas D. Nadeau >Subject: draft-kompella-mpls-te-mib-00.txt > > >Hi Arun, > >I am changing the subject line to avoid any confusion with current hot >discussion on MIB merging. This mail also address the same >issue, but to >avoid any confusion with the other mail. > >Please see my inline comments. > >----- Original Message ----- >From: "Arun Viswanathan" >To: "'Sudhanshu Jain'" ; ; >; "Thomas D. Nadeau" >Sent: Wednesday, September 06, 2000 8:28 PM >Subject: RE: Consensus for draft-kompella-mpls-te-mib-00.txt > > >> >> Sudhanshu, >> >> > I agree with your approach and here are my views to this effort. >> > >> > I would like to see single MIB addressing all related issue >> > as it help to >> > clear the confusion. >> > >> > IMHO, LSP info ( in this draft) is not specific to tunnel >> > only and so there >> > is no point them merging it with TE-MIB. Instead, it should >> > be get augmented >> > to mplsXCEntry in LSR MIB. >> >> I think the confusion is arising out of the use of the term LSP in >> Kireeti's MIB to actually mean tunnels as defined in >RSVP/CRLDP drafts >> or as in MPLS-TE-MIB. So there are no objects in Kireeti's MIB that >> need to go into the LSR MIB. >> > >I think, tunnel MIB objects are present only on ingress LSR and to some >extent to egress LSR. Please correct me, if I am wrong. > >As far the MPLS TE (Traffic Engineering) is concerned, it need to be >performed at each hop not just at ingress and egress. So if this is the >case, I think current MPLS-TE MIB is not the correct mib >representing MPLS >Traffic Engineering, as it address some TE aspects like >session attribute >etc for the configuration purpose at the head end of the tunnel only. > >On the other hand, objects like mplsLspAge, mplsLspTimeUp, >mplsLspPrimaryTimeUp, mplsLspTransition, mplsPathPropertis >etc. in Kireeti's >mib need to be monitor at each hop. > >May be these objects should be addresses based on different >index as oppose >to mplsLspName as specified in Kireeti's MIB. > >Any comments ? > >> > >> > Also, why do we have named draft-ietf-mpls-te-mib.txt as >> > "TE-MIB"? IMHO, it >> > should be Tunnel-MIB :)) >> >> We could have, but I doubt if that would have changed anything >> with regard to this debate :-) >> > >I think it will make the difference. Tunnel MIB is to address >objects only >at ingress (and egress) LSRs only. While TE-MIB should address >issues for >the whole path. > >Also, current subject of traffic engineering is very >pre-mature in MPLS and >it is better separate tunnel configuration from MPLS traffic >engineering. >Tunnel is a configurable entity while traffic engineering in >MPLS domain >should work on path not on tunnel. > >-Sudhanshu > > > From owner-mpls@UU.NET Fri Sep 8 11:12:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24270 for ; Fri, 8 Sep 2000 11:12:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfts08151; Fri, 8 Sep 2000 15:12:56 GMT Received: by mail-control.mail.uu.net id QQjfts03979 for mpls-outgoing; Fri, 8 Sep 2000 15:12:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfts03973 for ; Fri, 8 Sep 2000 15:12:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfts10798 for ; Fri, 8 Sep 2000 11:12:10 -0400 (EDT) Received: from apocalypse.quantum3d.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [206.184.176.5]) id QQjfts06876 for ; Fri, 8 Sep 2000 15:11:39 GMT Received: from saturn.quantum3d.com (SATURN [206.184.177.29]) by apocalypse.quantum3d.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QV1N4QR3; Fri, 8 Sep 2000 08:08:04 -0700 Received: from DT02017 ([206.184.177.31]) by saturn.quantum3d.com (Lotus Domino Release 5.0.4) with SMTP id 2000090808101555:3005 ; Fri, 8 Sep 2000 08:10:15 -0700 Reply-To: From: "Thomas Huang" To: "'Randy Bush'" , "'Eric Rosen'" Cc: "'mpls wg'" Subject: RE: ISPs offering VPN service Date: Sat, 18 Sep 1999 08:14:25 -0700 Message-ID: <003001bf01e8$7ed65780$4464a8c0@DT02017> 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) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on saturn/Polaris(Release 5.0.4 |June 8, 2000) at 09/08/2000 08:10:15 AM, Serialize by Router on saturn/Polaris(Release 5.0.4 |June 8, 2000) at 09/08/2000 08:10:16 AM, Serialize complete at 09/08/2000 08:10:16 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: I noticed mpls-te@uunet also appeared in some of the email here. Is there a mailing list discussing the MPLS-TE more intensively? If so, where could I register on? Thanks. /Thomas From owner-mpls@UU.NET Fri Sep 8 11:44:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24728 for ; Fri, 8 Sep 2000 11:44:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjftu08515; Fri, 8 Sep 2000 15:44:25 GMT Received: by mail-control.mail.uu.net id QQjftu06901 for mpls-outgoing; Fri, 8 Sep 2000 15:43:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjftu06882 for ; Fri, 8 Sep 2000 15:43:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjftu17525 for ; Fri, 8 Sep 2000 11:43:34 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjftu07182 for ; Fri, 8 Sep 2000 15:43:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA16328 for ; Fri, 8 Sep 2000 08:43:24 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA02812 for mpls@uu.net; Fri, 8 Sep 2000 11:43:01 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjftt05157 for ; Fri, 8 Sep 2000 15:24:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjftt13396 for ; Fri, 8 Sep 2000 11:24:36 -0400 (EDT) Received: from nsa-mail.us.newbridge.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [209.58.11.226]) id QQjftt18979 for ; Fri, 8 Sep 2000 15:24:21 GMT Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id LAA07698 for ; Fri, 8 Sep 2000 11:16:09 -0400 (EDT) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "herndon-mh1.us.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdAAAa001sD; Fri Sep 8 11:16:05 2000 Received: from nsamail01.us.newbridge.com by herndon-mh1.us.newbridge.com with ESMTP for mpls@UU.NET; Fri, 8 Sep 2000 11:23:50 -0400 Received: from alcatel.com ([138.120.241.67]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5D49; Fri, 8 Sep 2000 11:23:49 -0400 Message-Id: <39B90813.4FC33A7F@alcatel.com> Date: Fri, 08 Sep 2000 11:38:59 -0400 From: "Ramana V Gollamudi" Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: raszuk@cisco.com, Sitarama R Kalipatnapu , bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009081430.KAA02520@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The 7-Eleven (large VPN customer) is only one case that could lead to this scenario of route scaling. There are other ways this could happen, but I agree that having lot of CEs terminated on a few PEs is one way of solving the route scaling problem. Given the existing infrastructure, this is likely to be the common way. Another extreme example of solving the route scaling problem for large VPN customers would be to back haul all the traffic of large customers into few large PE routers which are connected in some private mesh using VCs/LSPs, and avoid a lot of the complexity associated with pushing all these routes into BGP and/or internet stability etc. altogether. To me this implies two assumptions in this type of VPNs, there is a tunnel (leased line/ATM or FR VC/LSP) type access network and large capacity PE boxes, as opposed to starting with small boxes and adding more boxes with growth. True? Regards, Ramana Eric Rosen wrote: > Ramana> What happens if the VPN feeds a lot of routes at different points > Ramana> into different PE edge boxes ( for example - each CE is a 7-Eleven > Ramana> feeding only few routes)? > > There are a number of techniques which can be used to improve the > aggregatibility. In this particular case, I think it unlikely that each > of the 100,000 7-11 stores connects to a different PE router. Each store > probably connects directly to an access network of some sort which attaches > a whole bunch of stores to a single PE router, where they can all be homed > to the same VRF. From owner-mpls@UU.NET Fri Sep 8 12:21:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25286 for ; Fri, 8 Sep 2000 12:21:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjftp18078; Fri, 8 Sep 2000 14:20:13 GMT Received: by mail-control.mail.uu.net id QQjftp18536 for mpls-outgoing; Fri, 8 Sep 2000 14:19:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjftp18531 for ; Fri, 8 Sep 2000 14:19:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjftp04830 for ; Fri, 8 Sep 2000 10:19:44 -0400 (EDT) Received: from roam.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: randy.workshop.sigz.net [195.149.150.111]) id QQjftp17313 for ; Fri, 8 Sep 2000 14:19:28 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13XOzo-0000Gw-00; Fri, 08 Sep 2000 16:19:12 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: Robert Raszuk , Robert Raszuk , Ramana V Gollamudi , Sitarama R Kalipatnapu , bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009081411.KAA02469@erosen-sun.cisco.com> Message-Id: Date: Fri, 08 Sep 2000 16:19:12 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > But as is clearly stated in RFC2547, it is not aimed at supporting VPNs > over the Internet, so the messiness of the Internet routing environment is > irrelevant. then why are we discussing it in the ietf? i guess we should should have the rfc made irrelevant. randy From owner-mpls@UU.NET Fri Sep 8 12:56:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25821 for ; Fri, 8 Sep 2000 12:56:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjftz13725; Fri, 8 Sep 2000 16:56:18 GMT Received: by mail-control.mail.uu.net id QQjftz07806 for mpls-outgoing; Fri, 8 Sep 2000 16:56:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjftz07793 for ; Fri, 8 Sep 2000 16:55:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjftz02308 for ; Fri, 8 Sep 2000 12:55:46 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjftz13138 for ; Fri, 8 Sep 2000 16:55:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA28074 for mpls@uu.net; Fri, 8 Sep 2000 12:55:44 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjftz07742 for ; Fri, 8 Sep 2000 16:55:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjftz02215; Fri, 8 Sep 2000 12:55:08 -0400 (EDT) From: Spencer.Giacalone@predictive.com Received: from athena.predictive.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: athena.predictive.com [208.209.197.197]) id QQjftz12564; Fri, 8 Sep 2000 16:55:04 GMT To: "Thomas D. Nadeau" Cc: mpls@UU.NET, owner-te-wg@UU.NET, te-wg@UU.NET Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Fri, 8 Sep 2000 12:57:18 -0400 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.4a |July 24, 2000) at 09/08/2000 12:57:25 PM, Serialize complete at 09/08/2000 12:57:25 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Merge and move on.... Decisiveness is good... -Spence "Thomas D. Nadeau" Sent by: owner-te-wg@UU.NET 09/06/00 07:32 PM To: mpls@UU.NET, te-wg@UU.NET cc: Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt I was going to send this out just before I saw Jim's last message and replied, so please excuse the misorder. Jim and I have been having some offline discussions about the two MIBs in question (Kireeti's and the MPLS-TE-MIB), and perceive several options: - pick one (which?) and let it move onto the standards track - move both separately onto the standards track - merge them and move the merged one onto the standards track Arun, Cheenu and I understood that the third option was being requested, and hence merged the MIBs and sent out the email of Wed, 30 Aug 2000 16:06:19 -0400 concerning that activity. However, I'm not sure that I have actually heard the working group's viewpoint or consensus on this, and would like a straw poll. Could you please reply to the list with your opinion on the above, even if only to say "I don't have a strong opinion"? Thank you, --Tom From owner-mpls@UU.NET Fri Sep 8 14:36:31 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27653 for ; Fri, 8 Sep 2000 14:36:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfug08302; Fri, 8 Sep 2000 18:36:21 GMT Received: by mail-control.mail.uu.net id QQjfug11346 for mpls-outgoing; Fri, 8 Sep 2000 18:35:54 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjfug11338 for ; Fri, 8 Sep 2000 18:35:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfug22745 for ; Fri, 8 Sep 2000 14:35:42 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjfug07613 for ; Fri, 8 Sep 2000 18:35:26 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA11193 for ; Fri, 8 Sep 2000 11:35:45 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA03357 for mpls@uu.net; Fri, 8 Sep 2000 14:35:24 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjfuc24324 for ; Fri, 8 Sep 2000 17:42:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfuc11263; Fri, 8 Sep 2000 13:42:38 -0400 (EDT) Received: from ns-inetext.inet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns-inetext.inet.com [199.171.211.140]) id QQjfuc26770; Fri, 8 Sep 2000 17:42:23 GMT Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id MAA05315; Fri, 8 Sep 2000 12:42:22 -0500 (CDT) Received: from inet.com ([172.16.13.183]) by harpo.inetint.com (Netscape Messaging Server 3.6) with ESMTP id AAA373C; Fri, 8 Sep 2000 12:42:21 -0500 Message-ID: <39B924FF.1B34D67B@inet.com> Date: Fri, 08 Sep 2000 12:42:23 -0500 From: Mart Nurmet Organization: Inet - Staff Engineer X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: mpls@UU.NET, te-wg@UU.NET Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt References: <4.3.2.7.2.20000906192938.02086f00@bucket.cisco.com> Content-Type: multipart/mixed; boundary="------------3D65BDE6A0984645C49B6570" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------3D65BDE6A0984645C49B6570 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would prefer the MIBs merged. Competing ones even if slight are couterproductive. -Mart "Thomas D. Nadeau" wrote: > I was going to send this out just before I saw > Jim's last message and replied, so please excuse the > misorder. > > Jim and I have been having some offline discussions about the > two MIBs in question (Kireeti's and the MPLS-TE-MIB), and perceive > several options: > > - pick one (which?) and let it move onto the standards track > - move both separately onto the standards track > - merge them and move the merged one onto the standards track > > Arun, Cheenu and I understood that the third option was being requested, > and hence merged the MIBs and sent out the email of Wed, 30 Aug 2000 > 16:06:19 -0400 > concerning that activity. However, I'm not sure that I have actually heard the > working group's viewpoint or consensus on this, and would like a straw > poll. Could > you please reply to the list with your opinion on the above, even if only > to say "I don't have a strong opinion"? > > Thank you, > > --Tom --------------3D65BDE6A0984645C49B6570 Content-Type: text/x-vcard; charset=us-ascii; name="mart.nurmet.vcf" Content-Description: Card for Mart Nurmet Content-Disposition: attachment; filename="mart.nurmet.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Nurmet;Mart tel;fax:469 330 4001 tel;home:972 424-9593 tel;work:469 330-4291 x-mozilla-html:TRUE url:http://www.inet.com org:Inet Technologies Inc.;Technology & Architecture version:2.1 email;internet:mart.nurmet@inet.com title:Staff Engineer adr;quoted-printable:;;1500 N. Greenville Ave. =0D=0ARoom 11073;Richrdson;Texas;75081;USA fn:Mart Nurmet end:vcard --------------3D65BDE6A0984645C49B6570-- From owner-mpls@UU.NET Fri Sep 8 17:14:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00712 for ; Fri, 8 Sep 2000 17:14:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfuq07827; Fri, 8 Sep 2000 21:14:26 GMT Received: by mail-control.mail.uu.net id QQjfuq02195 for mpls-outgoing; Fri, 8 Sep 2000 21:14:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfuq02186 for ; Fri, 8 Sep 2000 21:13:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfuq20120 for ; Fri, 8 Sep 2000 17:13:38 -0400 (EDT) Received: from devmail.dev.tivoli.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136]) id QQjfuq04628 for ; Fri, 8 Sep 2000 21:13:22 GMT Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id QAA02339 for ; Fri, 8 Sep 2000 16:13:22 -0500 (CDT) Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70]) by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id RAA27410 for ; Fri, 8 Sep 2000 17:15:44 -0400 (EDT) From: "Paul Tasillo" To: "mpls@UU. net" Subject: FW: Consensus for draft-kompella-mpls-te-mib-00.txt Date: Fri, 8 Sep 2000 17:13:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004F_01C019B8.14575B00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C019B8.14575B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I agree. I had thought as Thomas had stated several emails ago that the decision to merge and drop the original Kireeti draft was already made and the work had been done. Why does the IESG feel that two MIBs would be appropriate? Are we interested in a good standard or appeasing people with running code? -Paul Tivoli Systems. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mart Nurmet Sent: Friday, September 08, 2000 1:42 PM To: Thomas D. Nadeau Cc: mpls@UU.NET; te-wg@UU.NET Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt I would prefer the MIBs merged. Competing ones even if slight are couterproductive. -Mart "Thomas D. Nadeau" wrote: > I was going to send this out just before I saw > Jim's last message and replied, so please excuse the > misorder. > > Jim and I have been having some offline discussions about the > two MIBs in question (Kireeti's and the MPLS-TE-MIB), and perceive > several options: > > - pick one (which?) and let it move onto the standards track > - move both separately onto the standards track > - merge them and move the merged one onto the standards track > > Arun, Cheenu and I understood that the third option was being requested, > and hence merged the MIBs and sent out the email of Wed, 30 Aug 2000 > 16:06:19 -0400 > concerning that activity. However, I'm not sure that I have actually heard the > working group's viewpoint or consensus on this, and would like a straw > poll. Could > you please reply to the list with your opinion on the above, even if only > to say "I don't have a strong opinion"? > > Thank you, > > --Tom ------=_NextPart_000_004F_01C019B8.14575B00 Content-Type: text/x-vcard; name="mart.nurmet.vcf" Content-Disposition: attachment; filename="mart.nurmet.vcf" Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Nurmet;Mart tel;fax:469 330 4001 tel;home:972 424-9593 tel;work:469 330-4291 x-mozilla-html:TRUE url:http://www.inet.com org:Inet Technologies Inc.;Technology & Architecture version:2.1 email;internet:mart.nurmet@inet.com title:Staff Engineer adr;quoted-printable:;;1500 N. Greenville Ave. =3D0D=3D0ARoom = 11073;Richrdson;Texas;75081;USA fn:Mart Nurmet end:vcard ------=_NextPart_000_004F_01C019B8.14575B00-- From owner-mpls@UU.NET Fri Sep 8 17:57:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01372 for ; Fri, 8 Sep 2000 17:57:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfut04661; Fri, 8 Sep 2000 21:56:57 GMT Received: by mail-control.mail.uu.net id QQjfut06151 for mpls-outgoing; Fri, 8 Sep 2000 21:56:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfut06143 for ; Fri, 8 Sep 2000 21:56:32 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfut25440 for ; Fri, 8 Sep 2000 17:56:23 -0400 (EDT) Received: from postal.adn.alcatel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [143.209.80.56]) id QQjfut09418 for ; Fri, 8 Sep 2000 21:56:07 GMT Received: from adn.alcatel.com ([143.209.82.130]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA2E30; Fri, 8 Sep 2000 18:05:07 -0400 Message-ID: <39B9610B.A4C19B59@adn.alcatel.com> Date: Fri, 08 Sep 2000 17:58:35 -0400 From: Sitarama R Kalipatnapu X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Randy Bush , Robert Raszuk , Robert Raszuk , Ramana V Gollamudi , bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009081411.KAA02469@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I will have to agree with Eric Rosen on this. BGP is the only way inter-domain routing can be achieved in the Internet and that is what it is designed for. BGP cannot be blamed for this 'role of BGP'. Can something be done about it ! However the issue here seems to be the other roles that BGP plays in the context of MPLS VPNs and its consequential effects. May be something can be done here. --Sitaram Eric Rosen wrote: > Randy> for a scary example of one small aspect of the current bgp mess > > While it may be true that Internet routing is a mess, it is disingenuous to > blame that on BGP. BGP is the routing technology that allows the Internet > to scale as well as it does (which is pretty damn well), and nothing better > is known. > > The "messiness" is not due to any inherent characteristic of BGP, but to the > messiness of the Internet routing environment itself, with so many providers > who don't trust each other and can barely cooperate. BGP did not create the > mess, it is just the best way we know of coping with it. There's certainly > no reason why BGP should not be used to advantage in a less messy > environment, it is after all the most scalable routing protocol known. > (Outside of the research community, at least.) > > But as is clearly stated in RFC2547, it is not aimed at supporting VPNs over > the Internet, so the messiness of the Internet routing environment is > irrelevant. From owner-mpls@UU.NET Sat Sep 9 03:30:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20091 for ; Sat, 9 Sep 2000 03:30:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfwg18023; Sat, 9 Sep 2000 07:30:14 GMT Received: by mail-control.mail.uu.net id QQjfwf24946 for mpls-outgoing; Sat, 9 Sep 2000 07:29:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfwf24938 for ; Sat, 9 Sep 2000 07:29:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjfwf25595 for ; Sat, 9 Sep 2000 03:29:44 -0400 (EDT) From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjfwf01058 for ; Sat, 9 Sep 2000 07:29:29 GMT Received: from chqlubnt02.lon.bt.com by gollum (local) with ESMTP; Sat, 9 Sep 2000 08:30:38 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Sat, 9 Sep 2000 08:29:06 +0100 Message-ID: To: mpls@UU.NET Subject: RE: ISPs offering VPN service Date: Sat, 9 Sep 2000 08:29:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Randy Bush Thursday, September 07, 2000 8:21 PM > Subject: Re: ISPs offering VPN service > > > the problems with bgp scaling is not a matter of ram. for a scary example > of one small aspect of the current bgp mess see > > http://www.acm.org/sigcomm2000/conf/paper/sigcomm2000-5-2.ps.gz > [Harrison,N,Neil,INC1 X] Thanks for this reference Randy. Very interesting paper. Some observations I draw from a 1st pass on this paper in the context of the current thread discussion are: - these effects are a function of BGP per se, but they can be 'made worse' by poor (or at least non-harmonised) implementations - the fact that BGP is being used to also distribute labels is incidental to the observed BGP performance - all forwarding behaviour (be this Diffserv say (at either IP or MPLS layers) or LSPs within an MPLS layer network itself for example) is generally predicated on a stable routing environment. So QoS-type metrics/objectives (eg loss, delay) are *only* relevant to the up-state.....whatever this means, since it is not defined as yet for IP/MPLS networks......and should *not* be associated with the down-state, ie availability and QoS SLA-type considerations should be orthogonal, otherwise the former screws-up the latter's statistical significance. A corollary observation here is that the data/user-plane forwarding QoS performance *must* always be worse than that determined by the stability of the control-plane, ie we need to add (it will not be linear) user-plane defects/impairments to those arising from control-plane mechanisms. - and from all the above it seems I can conclude that: Any VPN service offered on an IP/MPLS basis looks like it will experience QoS/outage impairments significantly larger (and more frequent?) than from traditional WAN technologies of TDM leased-lines, FR or ATM. This concerns me since, as an operator, at some stage I will have to make availability and QoS statements in SLAs to customers of VPNs. - the paper deals with the effects of routing information change, but a further factor we have to consider is the mechanisms for causing that information to change and, in particular, what sort of physical server layer disturbances (eg short breaks) would give rise to this behaviour. - and this all brings me back to a point I have raised a couple of times (and to which only Eric Gray and Curtis Vilamizar responded - thanks) and that is the expected dynamic defect behaviour of different types of label distribution techniques when nested. And it would appear, from this paper, that those predicated on BGP (but to be fair I guess this would apply to any such interdomain cases?) are likely to get quite large outage events. Regards, Neil From owner-mpls@UU.NET Sat Sep 9 04:37:15 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20439 for ; Sat, 9 Sep 2000 04:37:15 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfwk05202; Sat, 9 Sep 2000 08:37:13 GMT Received: by mail-control.mail.uu.net id QQjfwk12780 for mpls-outgoing; Sat, 9 Sep 2000 08:36:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjfwk12772 for ; Sat, 9 Sep 2000 08:36:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfwk03669 for ; Sat, 9 Sep 2000 04:36:47 -0400 (EDT) Received: from roam.psg.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: roam.psg.com [147.28.4.2]) id QQjfwk28959 for ; Sat, 9 Sep 2000 08:36:44 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Xg76-0000Mr-00; Sat, 09 Sep 2000 10:35:52 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Ramana V Gollamudi" Cc: erosen@cisco.com, raszuk@cisco.com, Sitarama R Kalipatnapu , bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009081430.KAA02520@erosen-sun.cisco.com> <39B90813.4FC33A7F@alcatel.com> Message-Id: Date: Sat, 09 Sep 2000 10:35:52 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > having lot of CEs terminated on a few PEs is one way of solving the route > scaling problem. in a very large or global isp? randy From owner-mpls@UU.NET Sat Sep 9 16:34:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22991 for ; Sat, 9 Sep 2000 16:34:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjfyg08665; Sat, 9 Sep 2000 20:34:49 GMT Received: by mail-control.mail.uu.net id QQjfyg07445 for mpls-outgoing; Sat, 9 Sep 2000 20:34:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjfyg07431 for ; Sat, 9 Sep 2000 20:34:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjfyg05395 for ; Sat, 9 Sep 2000 16:34:03 -0400 (EDT) Received: from osf1.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQjfyg22494 for ; Sat, 9 Sep 2000 20:34:03 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id QAA12641; Sat, 9 Sep 2000 16:29:47 -0400 (EDT) Date: Sat, 9 Sep 2000 16:29:47 -0400 (EDT) From: Rajiv Papneja To: =?X-UNKNOWN?B?s8u34w==?= cc: mpls@UU.NET Subject: Re: question In-Reply-To: <39B84734.16173@mta4> Message-ID: 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 QAA22991 Hi, We have a paper coming up in the IEEE WCNC2000 which talks about the application of MPLS in the wireless scenario. The paper title is as follows. B. Jabbari, R. Papneja, E. Dinan, "Label Switched Packet Transfer for Wireless Cellular Networks," IEEE Wireless Communication Networks Conference, Chicago, IL, September 2000. Regards -Rajiv Papneja On Fri, 8 Sep 2000, ³Ë·ã wrote: > Dear Sir: > i'm a researcher interested in MPLS technology now. But my interest mainly lies in the MPLS application in Wireless ATM backbone network. > I didn't see any standards about it.Could you please give me some advice on this area. > Best Regards! > > _____________________________________________ > Ê׶¼ÔÚÏß--ÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net > @263.netÖйú×î´óµÄÔÚÏßÓÊ¾Ö http://freemail.263.net > ÖйúÈ˵ÄÔÚÏß¹ºÎïÀÖÔ°¡ª¡ª263ÉÌ³Ç http://shopping.263.net > > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4700 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Mon Sep 11 09:43:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02166 for ; Mon, 11 Sep 2000 09:43:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgeo01985; Mon, 11 Sep 2000 13:43:04 GMT Received: by mail-control.mail.uu.net id QQjgeo06745 for mpls-outgoing; Mon, 11 Sep 2000 13:42:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgeo06740 for ; Mon, 11 Sep 2000 13:42:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgeo19121 for ; Mon, 11 Sep 2000 09:42:11 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgeo01006 for ; Mon, 11 Sep 2000 13:41:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA17779 for mpls@uu.net; Mon, 11 Sep 2000 09:41:55 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgeo06646 for ; Mon, 11 Sep 2000 13:41:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgeo18860 for ; Mon, 11 Sep 2000 09:41:13 -0400 (EDT) Received: from nsa-mail.us.newbridge.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [209.58.11.226]) id QQjgeo00243 for ; Mon, 11 Sep 2000 13:40:53 GMT Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id JAA11888 for ; Mon, 11 Sep 2000 09:32:38 -0400 (EDT) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "herndon-mh1.us.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdAAAa002te; Mon Sep 11 09:32:28 2000 Received: from nsamail01.us.newbridge.com by herndon-mh1.us.newbridge.com with ESMTP for mpls@UU.NET; Mon, 11 Sep 2000 09:40:11 -0400 Received: from alcatel.com ([138.120.241.67]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA6289; Mon, 11 Sep 2000 09:40:10 -0400 Message-Id: <39BCE432.3AA46529@alcatel.com> Date: Mon, 11 Sep 2000 09:54:58 -0400 From: "Ramana V Gollamudi" Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: erosen@cisco.com, raszuk@cisco.com, Sitarama R Kalipatnapu , bkumar@ennovatenetworks.com, "'mpls wg'" Subject: Re: ISPs offering VPN service References: <200009081430.KAA02520@erosen-sun.cisco.com> <39B90813.4FC33A7F@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Randy, This is one of the ways that was suggested to get around the problem that occurs when route summarization becomes a problem. If you are concerned that in global ISPs this back hauling of traffic over VC technologies is not operationally/economical feasible then certainly the problem remains, and it would help if more operators spoke up on the need to solve this aspect of the problem. Randy Bush wrote: > > having lot of CEs terminated on a few PEs is one way of solving the route > > scaling problem. > > in a very large or global isp? > > randy From owner-mpls@UU.NET Mon Sep 11 09:49:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02297 for ; Mon, 11 Sep 2000 09:49:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgep06990; Mon, 11 Sep 2000 13:49:35 GMT Received: by mail-control.mail.uu.net id QQjgep07577 for mpls-outgoing; Mon, 11 Sep 2000 13:49:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgep07570 for ; Mon, 11 Sep 2000 13:49:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgep28872 for ; Mon, 11 Sep 2000 09:48:46 -0400 (EDT) Received: from roam.psg.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dhcp070.ripemtg.ripe.net [193.0.4.70]) id QQjgep02160 for ; Mon, 11 Sep 2000 13:48:45 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13YTx8-000187-00; Mon, 11 Sep 2000 15:48:54 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Ramana V Gollamudi" Cc: mpls wg Subject: Re: ISPs offering VPN service References: <200009081430.KAA02520@erosen-sun.cisco.com> <39B90813.4FC33A7F@alcatel.com> <39BCE432.3AA46529@alcatel.com> Message-Id: Date: Mon, 11 Sep 2000 15:48:54 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >>> having lot of CEs terminated on a few PEs is one way of solving the route >>> scaling problem. >> in a very large or global isp? > This is one of the ways that was suggested to get around the problem that > occurs when route summarization becomes a problem. If you are concerned > that in global ISPs this back hauling of traffic over VC technologies is > not operationally/economical feasible then certainly the problem remains, > and it would help if more operators spoke up on the need to solve this > aspect of the problem. what does the backhauling do to my customer's latency (and when latency goes up, so does the likelihood of increased jitter)? was the additional latency what they expected from a vpn service? randy From owner-mpls@UU.NET Mon Sep 11 09:51:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02391 for ; Mon, 11 Sep 2000 09:51:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgep08798; Mon, 11 Sep 2000 13:51:39 GMT Received: by mail-control.mail.uu.net id QQjgep07839 for mpls-outgoing; Mon, 11 Sep 2000 13:51:04 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgep07832 for ; Mon, 11 Sep 2000 13:51:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgep29244 for ; Mon, 11 Sep 2000 09:50:56 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgep08129 for ; Mon, 11 Sep 2000 13:50:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA19484 for mpls@uu.net; Mon, 11 Sep 2000 09:50:54 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgep07734 for ; Mon, 11 Sep 2000 13:50:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgep29078 for ; Mon, 11 Sep 2000 09:50:09 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjgep07583 for ; Mon, 11 Sep 2000 13:50:09 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA26679; Mon, 11 Sep 2000 09:49:59 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAI05142; Mon, 11 Sep 2000 09:49:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20000911094531.02090460@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Sep 2000 09:46:22 -0400 To: "Friedeborn, William" , "'mpls@UU.NET'" From: "Thomas D. Nadeau" Subject: Re: MPLS TE MIB - ARHop table Cc: cheenu@tachion.com, arun Viswanathan In-Reply-To: <7BF58A904536D411ADD400508BC97B8501BFAA@xover1.netplane.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Bill, Sorry for the delay on the reply to this. I was away when I got this last week. >I noticed the text description for the ARHop table differs from the index >information. > >Specifically the description says > "Each row in this table is indexed primarily by the > same indices, mplsTunnelIndex and > mplsTunnelInstance, as the row of the corresponding > tunnel in mplsTunnelTable. Each row also has a > third index mplsTunnelARHopIndex" > >The entry says "INDEX { mplsTunnelARHopListIndex, mplsTunnelARHopIndex }" > >Is it supposed to be >INDEX {mplsTunnelIndex, mplsTunnelInstance, mplsTunnelARHopIndex} Yes, the description should be updated. Thanks for catching this. --Tom >Bill From owner-mpls@UU.NET Mon Sep 11 10:43:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03811 for ; Mon, 11 Sep 2000 10:43:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjges19765; Mon, 11 Sep 2000 14:43:00 GMT Received: by mail-control.mail.uu.net id QQjges22852 for mpls-outgoing; Mon, 11 Sep 2000 14:42:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjges22847 for ; Mon, 11 Sep 2000 14:42:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjges09649 for ; Mon, 11 Sep 2000 10:42:23 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQjges19107 for ; Mon, 11 Sep 2000 14:42:23 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id KAA06833; Mon, 11 Sep 2000 10:41:46 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Ramana V Gollamudi'" , "'Randy Bush'" Cc: "'mpls wg'" Subject: RE: ISPs offering VPN service Date: Mon, 11 Sep 2000 10:41:45 -0400 Message-ID: <001301c01bfe$69bcd500$d001010a@tst.ennovatenetworks.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.2910.0) In-reply-to: <39BCE432.3AA46529@alcatel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ramana, I don't think that is the way scalability problems with RFC 2547 can be addressed. It is not practical to terminate lots of CEs over a single PEs. More interfaces means more PE-CE routing adjacencies. By doing what you suggested, you will only shift PE-PE domain scalability issues to PE-CE domains. Making a PE more powerful than they really need to be, and forcing lots of CEs to peer with some limited number of PEs, one will significantly add to the cost of infrastructure. The good solution is the one that does not put impractical constraints on carriers for deploying services. Does I-BGP to I-BGP communication model provide an acceptable solution for VPN signalling in terms of scalability, granularity, speed of convergence and ease of maintenance? Many don't believe it does! Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Ramana V > Gollamudi > > Randy, > > This is one of the ways that was suggested to get around the > problem that occurs > when route summarization becomes a problem. If you are > concerned that in global > ISPs this back hauling of traffic over VC technologies is not > operationally/economical feasible then certainly the problem > remains, and it > would help if more operators spoke up on the need to solve > this aspect of the > problem. > > Randy Bush wrote: > > > > having lot of CEs terminated on a few PEs is one way of > solving the route > > > scaling problem. > > > > in a very large or global isp? > > > > randy From owner-mpls@UU.NET Mon Sep 11 11:01:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04192 for ; Mon, 11 Sep 2000 11:01:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgeu00777; Mon, 11 Sep 2000 15:01:06 GMT Received: by mail-control.mail.uu.net id QQjgeu24433 for mpls-outgoing; Mon, 11 Sep 2000 15:00:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgeu24354 for ; Mon, 11 Sep 2000 15:00:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgeu13207 for ; Mon, 11 Sep 2000 11:00:15 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgeu05186 for ; Mon, 11 Sep 2000 15:00:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA29778 for mpls@uu.net; Mon, 11 Sep 2000 11:00:09 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjget23790 for ; Mon, 11 Sep 2000 14:59:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjget13024 for ; Mon, 11 Sep 2000 10:59:53 -0400 (EDT) Received: from fw7.usa.alcatel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: fw7.usa.alcatel.com [192.245.102.17]) id QQjget04627 for ; Mon, 11 Sep 2000 14:59:37 GMT Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id JAA09377 for ; Mon, 11 Sep 2000 09:56:19 -0500 (CDT) Received: from (relay2-alt.usa.alcatel.com [143.209.167.22]) by fw7 via smap (V2.1) id xmaa09173; Mon, 11 Sep 00 09:55:21 -0500 Received: from lcmail01.usa.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA24826 for ; Mon, 11 Sep 2000 09:59:26 -0500 (CDT) Received: from usa.alcatel.com ([128.251.97.48]) by lcmail01.usa.alcatel.com (Netscape Messaging Server 4.15 lcmail01 Aug 8 2000 13:22:32) with ESMTP id G0Q9N400.R88 for ; Mon, 11 Sep 2000 09:59:28 -0500 Message-ID: <39BCF305.75A374AE@usa.alcatel.com> Date: Mon, 11 Sep 2000 09:58:13 -0500 From: "Aziz Mohammed" Organization: Alcatel X-Mailer: Mozilla 4.72 [en]C-ANS 1.02 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit unsubscribe From owner-mpls@UU.NET Mon Sep 11 11:30:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04894 for ; Mon, 11 Sep 2000 11:30:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjget24643; Mon, 11 Sep 2000 14:53:00 GMT Received: by mail-control.mail.uu.net id QQjget23483 for mpls-outgoing; Mon, 11 Sep 2000 14:52:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjget23454 for ; Mon, 11 Sep 2000 14:52:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjget01955 for ; Mon, 11 Sep 2000 10:52:26 -0400 (EDT) Received: from laptoy770.fictitious.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [209.66.129.242]) id QQjget28377 for ; Mon, 11 Sep 2000 14:52:24 GMT Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.9.2/8.9.2) with ESMTP id KAA67669; Mon, 11 Sep 2000 10:52:09 -0400 (EDT) (envelope-from curtis@laptoy770.fictitious.org) Message-Id: <200009111452.KAA67669@laptoy770.fictitious.org> To: erosen@cisco.com cc: "Ramana V Gollamudi" , raszuk@cisco.com, Sitarama R Kalipatnapu , bkumar@ennovatenetworks.com, "'Randy Bush'" , "'mpls wg'" Reply-To: curtis@avici.com Subject: Re: ISPs offering VPN service In-reply-to: Your message of "Fri, 08 Sep 2000 10:30:57 EDT." <200009081430.KAA02520@erosen-sun.cisco.com> Date: Mon, 11 Sep 2000 10:52:09 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200009081430.KAA02520@erosen-sun.cisco.com>, Eric Rosen writes: > Ramana> What happens if the VPN feeds a lot of routes at different points > Ramana> into different PE edge boxes ( for example - each CE is a 7-Eleven > Ramana> feeding only few routes)? > > There are a number of techniques which can be used to improve the > aggregatibility. In this particular case, I think it unlikely that each > of the 100,000 7-11 stores connects to a different PE router. Each store > probably connects directly to an access network of some sort which attaches > a whole bunch of stores to a single PE router, where they can all be homed > to the same VRF. Last I remember configuring routers for a provider aggregation had to be configured (they don't happen automagically) and generating aggregates from a database was a black art with too few practitioners. In fact configuring anything from a database was practiced by too few practitioners partically leading to this Internet routing mess that we've wasted so much time discussing. Managing the aggregation of private address space for the benefit of each customer is something I'd rather not have to do, but then again I don't work for a provider anymore so I guess someone else gets to decide if this sounds like too much work. Then again, giving the customer a static route and a single (easily aggregted) prefix at each interface and requiring the customer to do multihop BGP to get any private addresses would probably work fine, scale fine, and only look slightly ugly architecturally. Then only the CPE router is concerned with any prefix explosion in private address space. Over and out. Curtis From owner-mpls@UU.NET Mon Sep 11 11:52:40 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05411 for ; Mon, 11 Sep 2000 11:52:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgex21689; Mon, 11 Sep 2000 15:52:39 GMT Received: by mail-control.mail.uu.net id QQjgex09602 for mpls-outgoing; Mon, 11 Sep 2000 15:52:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgex09585 for ; Mon, 11 Sep 2000 15:52:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgex12560 for ; Mon, 11 Sep 2000 11:52:00 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgex20584 for ; Mon, 11 Sep 2000 15:51:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA07764 for mpls@uu.net; Mon, 11 Sep 2000 11:51:29 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgex09502 for ; Mon, 11 Sep 2000 15:51:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgex23669 for ; Mon, 11 Sep 2000 11:50:52 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjgex07479 for ; Mon, 11 Sep 2000 15:50:51 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA15205; Mon, 11 Sep 2000 08:51:10 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA13726; Mon, 11 Sep 2000 08:50:50 -0700 (PDT) Message-ID: <39BD002F.D6E0F9FF@cisco.com> Date: Mon, 11 Sep 2000 08:54:23 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: bkumar@ennovatenetworks.com CC: "'Ramana V Gollamudi'" , "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service References: <001301c01bfe$69bcd500$d001010a@tst.ennovatenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Brijesh, What are PE-PE domain scalability issues with 2547 ? This is not what we were talking about at all here. R. > Hi Ramana, > > I don't think that is the way scalability problems with RFC 2547 can > be addressed. > > It is not practical to terminate lots of CEs over a single PEs. More > interfaces means more PE-CE routing adjacencies. By doing what you > suggested, you will only shift PE-PE domain scalability issues to > PE-CE domains. Making a PE more powerful than they really need to be, > and forcing lots of CEs to peer with some limited number of PEs, one > will significantly add to the cost of infrastructure. The good > solution is the one that does not put impractical constraints on > carriers for deploying services. > > Does I-BGP to I-BGP communication model provide an acceptable solution > for VPN signalling in terms of scalability, granularity, speed of > convergence and ease of maintenance? Many don't believe it does! > > Cheers, > > --brijesh > Ennovate Networks Inc. > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > > Of Ramana V > > Gollamudi > > > > Randy, > > > > This is one of the ways that was suggested to get around the > > problem that occurs > > when route summarization becomes a problem. If you are > > concerned that in global > > ISPs this back hauling of traffic over VC technologies is not > > operationally/economical feasible then certainly the problem > > remains, and it > > would help if more operators spoke up on the need to solve > > this aspect of the > > problem. > > > > Randy Bush wrote: > > > > > > having lot of CEs terminated on a few PEs is one way of > > solving the route > > > > scaling problem. > > > > > > in a very large or global isp? > > > > > > randy From owner-mpls@UU.NET Mon Sep 11 12:34:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06118 for ; Mon, 11 Sep 2000 12:34:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgfa09157; Mon, 11 Sep 2000 16:34:14 GMT Received: by mail-control.mail.uu.net id QQjgfa24110 for mpls-outgoing; Mon, 11 Sep 2000 16:33:55 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgfa24105 for ; Mon, 11 Sep 2000 16:33:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgfa19404 for ; Mon, 11 Sep 2000 12:32:16 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjgfa23407 for ; Mon, 11 Sep 2000 16:32:00 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA23215; Mon, 11 Sep 2000 09:32:19 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA12745; Mon, 11 Sep 2000 12:31:57 -0400 (EDT) Message-Id: <200009111631.MAA12745@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: bkumar@ennovatenetworks.com cc: "'Ramana V Gollamudi'" , "'Randy Bush'" , "'mpls wg'" Subject: Re: ISPs offering VPN service In-reply-to: Your message of Mon, 11 Sep 2000 10:41:45 -0400. <001301c01bfe$69bcd500$d001010a@tst.ennovatenetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Sep 2000 12:31:57 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Brijesh> It is not practical to terminate lots of CEs over a single PEs. On the contrary, each PE generally attaches to lots and lots of CEs. Provider edge systems tend to be quite powerful, and have lots of "high touch" features. However, the aggregation problem for VPNs is not quite the same as the aggregation problem in global routing. In a default-free zone, a global routing table (for the public Internet) must hold (non-default) routes which match ALL globally reachable addresses. A VPN-specific routing table only needs to hold routes for addresses within the VPN. No single router needs to hold routing tables for all VPNs. So the pressure to aggregate the VPN addresses is not nearly the same as the pressure to aggregate the globally reachable addresses. For most VPN customers, this won't be much of an issue. In practice, I think that this is a major issue only when integrating dialup connections and the like into the VPN. Curtis> Managing the aggregation of private address space for the benefit of Curtis> each customer is something I'd rather not have to do, but then again Curtis> I don't work for a provider anymore so I guess someone else gets to Curtis> decide if this sounds like too much work. One needs to keep in mind that the provider might otherwise be managing a large number of point-to-point VCs, and then providing a managed backbone service to each customer as well. As I've said before, it's not valid to compare the amount of work needed to provide VPN service with the amount of work needed if you don't provide it. From owner-mpls@UU.NET Mon Sep 11 12:58:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06443 for ; Mon, 11 Sep 2000 12:58:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgfb26331; Mon, 11 Sep 2000 16:57:54 GMT Received: by mail-control.mail.uu.net id QQjgfb25468 for mpls-outgoing; Mon, 11 Sep 2000 16:57:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgfb25463 for ; Mon, 11 Sep 2000 16:57:28 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgfb22845 for ; Mon, 11 Sep 2000 12:55:20 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjgfb10612 for ; Mon, 11 Sep 2000 16:55:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA14786; Mon, 11 Sep 2000 09:55:38 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA12780; Mon, 11 Sep 2000 12:55:17 -0400 (EDT) Message-Id: <200009111655.MAA12780@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: neil.2.harrison@bt.com cc: mpls@UU.NET Subject: Re: ISPs offering VPN service In-reply-to: Your message of Sat, 09 Sep 2000 08:29:06 +0100. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Sep 2000 12:55:17 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk If one believes the various claims made about the poor state of the public Internet routing system, then the one thing which is clear is that one should not use a VPN scheme which is based on IP or IPsec tunnels that traverse the public Internet and then terminate on the customer site. I think that these schemes are likely to have the availability/reliabil- ity/quality problems that you mention. It's quite ironic that those who are shouting loudest about the poor state of Internet routing seem to favor CPE-based IP tunneling schemes, which depend ENTIRELY on Internet routing. While there are a number of problems in the distribution of public IP routes around the Internet, I haven't seen any clear statement or reasoned argument as to why these problems should affect the distribution of the VPN-IP routes in the more controlled environment offered by a VPN service provider. From owner-mpls@UU.NET Mon Sep 11 13:45:54 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07042 for ; Mon, 11 Sep 2000 13:45:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgfe22529; Mon, 11 Sep 2000 17:44:48 GMT Received: by mail-control.mail.uu.net id QQjgfe10688 for mpls-outgoing; Mon, 11 Sep 2000 17:43:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgfe10683 for ; Mon, 11 Sep 2000 17:43:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgfe13680 for ; Mon, 11 Sep 2000 13:40:30 -0400 (EDT) Received: from almso1.proxy.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQjgfe19095 for ; Mon, 11 Sep 2000 17:40:30 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id NAA05825; Mon, 11 Sep 2000 13:40:29 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA20680; Mon, 11 Sep 2000 13:42:24 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Mon, 11 Sep 2000 13:40:26 -0400 Message-ID: <15BF137B61C7D211BAF50000C0589CFA0216D556@njc240po02.mt.att.com> From: "Chase, Christopher J (Chris), ALNTK" To: "'Christian Kuhtz'" , "'mpls wg'" Subject: RE: ISPs offering VPN service Date: Mon, 11 Sep 2000 13:40:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Enforcing a topology within the provider portion of the VPN makes perfect sense, rather than expecting the VPN owner to enforce a topology. Customers may not have the capability to implement or manage TE tunnels to enforce a topology on top of the any-to-any connectivity. In addition, that would require running MPLS to the CE instead of providing a VPN service that uses standard IP CE-PE interface (e.g., FR or PPP). Examples of wanting other topologies: inter corporate extranets, network based firewall services, regional company gateways. One big advantage of the MPLS VPN hub-and-spoke topology over the private-line/VC model is circuit aggregation. The hub or data center site only needs to terminate a single logical connection independent of the number of remote sites. I know a lot of large enterprise networks using the PVC hub-and-spoke model having to spread those PVCs across many ports and routers at the hub site. Chris Chase AT&T IP Enabled FR Architect > -----Original Message----- > From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] > Sent: Thursday, September 07, 2000 11:16 AM > To: 'mpls wg' > Subject: RE: ISPs offering VPN service > > > > > > > That is not too say that I personely like hub and spoke. > In fact I do > > > agree with you that full mesh is the way to go and > mpls-vpns easily > > > allow it. > > > > while i may agree with you technically. enterprises are > used to it, and may > > be slow to make the cultural change. so i expect customers > to be in a > > common process of evolving reconfiguration. > > I'm lost with this argumentation. > > In MPLS VPNs, default is that traffic starts to automatically > flow shortest > path/fully meshed by the very nature of it. Basically, all > sites of a given > customer just attach to a common net. So, that said, what > evolution is there > for customers to go thru? > > No "evolving reconfiguration"... > > But, if you really want them to, you can just make MPLS VPNs > look like hub & > spoke, why you would ever want to force that inside the vpn > (you can always do > it on a TE level regardless, if you desire to) escapes me, > but it is possible. > > Cheers, > Chris > > -- > Christian Kuhtz, Sr. Network Architect > Architecture, BellSouth.net > -wk, -hm > Atlanta, GA > "Speaking > for myself only." > From owner-mpls@UU.NET Mon Sep 11 14:22:23 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07490 for ; Mon, 11 Sep 2000 14:22:23 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgfh27630; Mon, 11 Sep 2000 18:21:31 GMT Received: by mail-control.mail.uu.net id QQjgfh25436 for mpls-outgoing; Mon, 11 Sep 2000 18:20:53 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgfh25428 for ; Mon, 11 Sep 2000 18:20:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgfg20399 for ; Mon, 11 Sep 2000 14:14:23 -0400 (EDT) Received: from ckmso1.proxy.att.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQjgfg22576 for ; Mon, 11 Sep 2000 18:14:22 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id OAA04764; Mon, 11 Sep 2000 14:12:41 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA24186; Mon, 11 Sep 2000 14:14:37 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Mon, 11 Sep 2000 14:12:41 -0400 Message-ID: <15BF137B61C7D211BAF50000C0589CFA0216D557@njc240po02.mt.att.com> From: "Chase, Christopher J (Chris), ALNTK" To: "'raszuk@cisco.com'" , Sitarama R Kalipatnapu Cc: "'mpls wg'" , bkumar@ennovatenetworks.com, "'Randy Bush'" , "'erosen@cisco.com'" Subject: RE: ISPs offering VPN service Date: Mon, 11 Sep 2000 14:12:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Adding new PEs to handle new VPNs is fine. However, I do have to apriori anticipate the number of routes in a single VPN. So I have to limit the number of VPNs on a given PE. As a particular VPN adds sites, all the routes for that VPN show up at every PE the VPN touches. If the PE routing table is reaching capacity because of the growth of existing VPNs then adding an additional PE will not alleviate that problem. Without very conservative provisioning assignment rules in place I may have to "rehome" VPNs off of the constrained PE. I would prefer not to rehome - so instead I try to be very conservative in provisioning assignment. As a result it may mean an interim of underutilized PEs until individual VPNs stabilize in size (it can take up to a year or more for some enterprises to deploy a complete network). Additionally, to aid in the scalability of VPNs on a PE we feel that it is important that the PE be able to limit the total routes in a vrf. I do not want a customer to accidentally inject Internet routes into his VPN and consume all the route table resources on the PE - thus affecting other VPNs on the same VPN. My goal is that the customer should pay proportionately to the amount of PE resources he consumes. Thus the limit on the number of routes in the VPN should be proportional to the number of sites in the VPN. Most business models I have seen the revenue for a VPN scales linearly with the number of sites. Making this association is not unreasonable since large enterprise networks I am familiar with have the number of routes scale as 2*N+C where N is the number of sites and C is a constant representing the routes at the hub site. Large enterprises with hundreds or thousands of sites have a single network (LAN) at all their "remote" sites. (The multiplier is 1 if the CE-PE link is a subnet of the site summarized network). I can not summarize as a MPLS VPN provider in the middle of an enterprise network. But if the customer is paying proportionately to the utilized network resources then I don't have a problem with not summarizing. As long as the ratio of total number of PEs (and RRs) to total number of CEs stays constant as the network grows then I am fine. If I need more PE's then it means I am making more money. If a VPN is serving a carrier application rather than enterprise then the 2N+C model does not hold. But that VPN is ideal for carrier's carrier VPN where only N site routes need to be directly exposed in the provider VPN. Chris Chase AT&T IP Enabled Frame Relay Architect > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Wednesday, September 06, 2000 3:37 PM > To: Sitarama R Kalipatnapu > Cc: erosen@cisco.com; bkumar@ennovatenetworks.com; 'Randy Bush'; 'mpls > wg' > Subject: Re: ISPs offering VPN service > > > > Sitarama, > > > 1. When do you decide to add another PE router, as the number of > > VPNs supported is increasing ? > > Let me say once again that number of VPNs does not trigger addition of > another PE. Why ? Simply because the overhead of vrf is memory > consumption wise not significant. What does matter is the number of > routes your VPNs give you as you need to store them in the vpnv4 bgp > table as well in RIBs & FIBs for given vrfs. So it really > depends on the > operator's comfort with a given router to run at X% of memory > utlization. Notice that in moders routers the memory limit and upgrade > flexibility is growing so even that may not be a very significant > factor. > > The same applies to CPU. > > > 2. What makes us add a second PE router ? > > See above. > > > 3. Is this connected to BGP ? > > No. In a peering VPN model you need to maintain customer routes. What > ever protocol you would use you will still have a potential of hitting > the hardware limitations at some point and bgp is quite ortogonal to > this. > > Just one more comment on your last question: > > > > > 3. Is it possible to unload the demands on BGP > (carrying MPLS labels ) > > > > in the BGP/MPLS VPNs model ? > > Using bgp to carry labels for vpn routes is totally not an issue as it > just extending the NLRI size by 20 bits without any > processing penalty. > BGP is more or less just a vehicle here. > > R. > > > > > Thanks, > > > > --Sitaram > > > > Robert Raszuk wrote: > > > > > Sitarama, > > > > > > BGP is not a choke point. First it is already there in > all edge routers > > > in all ISPs I know of and adding the new AF to it does > not cause it to > > > choke in the right implementation. Notice that the > "choking" effect all > > > depends how one sets the timers (per AF of course - so it does not > > > effect plain IPV4 updates or other bgp IPV4 mechanisms). > As a contary to > > > what you are saying many customers are setting the VPNv4 > timers more > > > aggresively then ipv4 timers to allow equal to IGP > convergence and even > > > that is not causing bgp to "choke" in a production networks. > > > > > > The scalability of MPLS-VPNs is achived by the fact that > BGP is being > > > used as a tool there so it would be a mistake to even attempt it's > > > replacement by some other means. > > > > > > R. > > > > > > > On the note of scalability of BGP/MPLS VPNs, adding > more hardware > > > > seems to do the trick. But on a close observation it > appears, BGP is the > > > > choke point. BGP running in the provider edge seems to > peer with the > > > > customer edges and also distribute MPLS labels across > PE edges. The > > > > questions are: > > > > > > > > 1. Do we have alternate solutions to provide MPLS VPNs > without BGP ? > > > > 2. If so are they effective ? > > > > 3. Is it possible to unload the demands on BGP > (carrying MPLS labels ) > > > > in the BGP/MPLS VPNs model ? > > > > > > > > Thank You. > > > > > > > > --Sitaram > > > > > > > > Eric Rosen wrote: > > > > > > > > > Brijesh> I think you are probably right. It seems > that the model in RFC 2547 > > > > > Brijesh> may be flawed because it fails to separate > internal VPN control and > > > > > Brijesh> configuration within a domain from the > routing control plane > > > > > Brijesh> primarily designed for carrying external > inter-domain transit > > > > > Brijesh> traffic. > > > > > > > > > > No it doesn't. It does use BGP for both purposes > though. The fact that > > > > > technology which is primarily designed for one > application is also used for > > > > > a second application is not generally considered to > be a bad thing. > > > > > > > > > > Brijesh> adding VPN related policies (basically, > internal traffic of a > > > > > Brijesh> domain) to something that was originally > designed to provide policy > > > > > Brijesh> control of inter-domain traffic doesn't seem > obviously appropriate. > > > > > > > > > > The "VPN-related policies" are primarily expressed as > filtering on community > > > > > attributes, which is actually fits in quite well with > normal BGP functions. > > > > > > > > > > Brijesh> Besides the scalability problems you mentioned, > > > > > > > > > > The only scalability problem Randy mentioned is > that as you get more > > > > > customers, you might have to add more equipment. I'd > like to see the scheme > > > > > in which the hardware cost is independent of the load! > > > > > > > > > > Brijesh> It is not going to help busy network > administrators who need to > > > > > Brijesh> manage large number of BGP nodes, and > resolve policy conflicts in > > > > > Brijesh> increasingly large and complex networks. > > > > > > > > > > This is sophistry. You could argue against any > VPN scheme whatsoever by > > > > > pointing out that it creates some administrative > burden, when compared with > > > > > not having any VPN scheme at all. That's not very > interesting, it's only > > > > > interesting to compare two VPN schemes, > for instance RFC2547 > > > > > vs. configuring, managing, and maintaining > hundreds of thousands of > > > > > point-to-point tunnels. > From owner-mpls@UU.NET Mon Sep 11 15:04:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08120 for ; Mon, 11 Sep 2000 15:04:55 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgfj23935; Mon, 11 Sep 2000 18:57:49 GMT Received: by mail-control.mail.uu.net id QQjgfj27433 for mpls-outgoing; Mon, 11 Sep 2000 18:57:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgfj27428 for ; Mon, 11 Sep 2000 18:57:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgfj27717 for ; Mon, 11 Sep 2000 14:55:03 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgfj24463 for ; Mon, 11 Sep 2000 18:54:47 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA06968 for mpls@uu.net; Mon, 11 Sep 2000 14:54:46 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgfj27267 for ; Mon, 11 Sep 2000 18:54:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgfj12550 for ; Mon, 11 Sep 2000 14:50:36 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjgfj20456 for ; Mon, 11 Sep 2000 18:50:05 GMT Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA01864 for ; Mon, 11 Sep 2000 11:50:27 -0700 (PDT) Received: from cisco.com (dhcp-171-70-63-137.cisco.com [171.70.63.137]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACN05038 (AUTH nkhurana); Mon, 11 Sep 2000 12:03:22 -0700 (PDT) Message-ID: <39BD35A3.211FC5C5@cisco.com> Date: Mon, 11 Sep 2000 12:42:27 -0700 From: Neeraj Khurana Reply-To: nkhurana@cisco.com X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: unsubscribe References: <39BCF305.75A374AE@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit unsubscribe From owner-mpls@UU.NET Mon Sep 11 16:55:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08939 for ; Mon, 11 Sep 2000 16:55:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgfr25557; Mon, 11 Sep 2000 20:54:51 GMT Received: by mail-control.mail.uu.net id QQjgfr01590 for mpls-outgoing; Mon, 11 Sep 2000 20:54:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgfr01585 for ; Mon, 11 Sep 2000 20:54:21 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgfr19202 for ; Mon, 11 Sep 2000 16:53:45 -0400 (EDT) Received: from roam.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dhcp070.ripemtg.ripe.net [193.0.4.70]) id QQjgfr24712 for ; Mon, 11 Sep 2000 20:53:44 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13YaaH-0001Pn-00; Mon, 11 Sep 2000 22:53:45 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: neil.2.harrison@bt.com, mpls@UU.NET Subject: Re: ISPs offering VPN service References: <200009111655.MAA12780@erosen-sun.cisco.com> Message-Id: Date: Mon, 11 Sep 2000 22:53:45 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > If one believes the various claims made about the poor state of the public > Internet routing system before leaping to conclusions, one probably needs to understand it (the real operational network) as well. randy From owner-mpls@UU.NET Tue Sep 12 00:38:58 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14214 for ; Tue, 12 Sep 2000 00:38:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjggw14472; Tue, 12 Sep 2000 04:38:36 GMT Received: by mail-control.mail.uu.net id QQjggw02256 for mpls-outgoing; Tue, 12 Sep 2000 04:38:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjggw02251 for ; Tue, 12 Sep 2000 04:38:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjggw06760 for ; Tue, 12 Sep 2000 00:37:39 -0400 (EDT) Received: from roam.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dhcp070.ripemtg.ripe.net [193.0.4.70]) id QQjggw18651 for ; Tue, 12 Sep 2000 04:37:38 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13YhpU-0001VJ-00; Tue, 12 Sep 2000 06:37:56 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: mpls@UU.NET Subject: Re: ISPs offering VPN service References: <200009111655.MAA12780@erosen-sun.cisco.com> Message-Id: Date: Tue, 12 Sep 2000 06:37:56 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >> If one believes the various claims made about the poor state of the public >> Internet routing system > before leaping to conclusions, one probably needs to understand it (the real > operational network) as well. apologies. i was a bit abrupt. late and tired. sorry. the net does work. i did get your message. and packets do flow. it comes down to scaling. operators have watched the size of our networks more than double every year, and spend our days and nights maintaining stability and service despite protocols in which we find continual growing pains (e.g. craig's paper on the needed bgp fix) and which we know do not scale linearly. so we are very sceptical of adding weight or complexity in the center, and prefer to offload as much as possible to the edges. and 2547[bis] looks as if it adds weight and complexity in the center, and it is not at all clear how it would scale when we're talking gillions of vpns and links. and we do not succumb to the mpls fantasy that, because they look like circuits, they are circuits and there are not a few layers of the usual causes of worry below them. and, as many of us are considering deploying mpls as part of cbr traffic engineering, the issues of igp, inter-provider, etc. etc. keep us very cautious. randy From owner-mpls@UU.NET Tue Sep 12 01:56:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20379 for ; Tue, 12 Sep 2000 01:56:11 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjghb07510; Tue, 12 Sep 2000 05:55:41 GMT Received: by mail-control.mail.uu.net id QQjghb18042 for mpls-outgoing; Tue, 12 Sep 2000 05:55:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjghb18031 for ; Tue, 12 Sep 2000 05:54:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjghb15253 for ; Tue, 12 Sep 2000 01:54:25 -0400 (EDT) Received: from csa.iisc.ernet.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjghb14601 for ; Tue, 12 Sep 2000 05:53:44 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id LAA02391 for ; Tue, 12 Sep 2000 11:22:35 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id LAA20646 for ; Tue, 12 Sep 2000 11:23:22 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Tue, 12 Sep 2000 11:23:22 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Questions regarding the RSVP-TE and MPLS interaction. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I am currently doing a Project in RSVP-TE and MPLS alongwith my collegue and had several question to ask on these. I have been reading the drafts for RSVP-TE uptill the most recent one that is RSVP_TE 07.txt. These drafts have been discussing the various object formats in the messages used by RSVP-TE and their use. The draft has mentioned something like LSP tunnel and a Traffic Engineered Tunnel. (Page 8). The objects in the Path messages like the session object and the Sender Template object contains these fields like LSP ID and Tunnel ID. But how do u realise this Traffic Engineered Tunnel and LSP tunnel in the MPLS domain. And once this tunnel is created how do u acheive Traffic Engineering over it. These things are not very clear to me. and I am confused as to how the parameters like LSP ID and Tunnel ID in the RSVP_TE will help me create an MPLS tunnel (which may be comprised of several LSPs) and also as to how i engineer the traffic over this tunnel. What sort of interaction will RSVP-TE and MPLS require between them so that the various things like LSP ID and TUNNEL ID in the signalling of RSVP-TE will finally boil down to an MPLS LSP Tunnel or a TE Tunnel being created. Please explain as to how this can be realised. Thanking in advance Prasanna _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Tue, 12 Sep 2000 05:14:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgho20248; Tue, 12 Sep 2000 09:14:22 GMT Received: by mail-control.mail.uu.net id QQjgho15390 for mpls-outgoing; Tue, 12 Sep 2000 09:13:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgho15385 for ; Tue, 12 Sep 2000 09:13:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgho04714 for ; Tue, 12 Sep 2000 05:11:36 -0400 (EDT) From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjgho18628 for ; Tue, 12 Sep 2000 09:11:36 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Tue, 12 Sep 2000 10:10:57 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id ; Tue, 12 Sep 2000 10:09:27 +0100 Message-ID: To: mpls@UU.NET Subject: RE: ISPs offering VPN service Date: Tue, 12 Sep 2000 10:09:23 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric Rosen wrote on Monday, September 11, 2000 5:55 PM Re: ISPs offering VPN service > It's quite ironic that those who are shouting loudest about the poor > state > of Internet routing seem to favor CPE-based IP tunneling schemes, > which > depend ENTIRELY on Internet routing. [Harrison,N,Neil,INC1 X] Quite. If I assume the results given in the paper on 'Delayed Internet Routing Convergence' from Michigan University are correct (and I see no reason why they should not be) then I, as an operator, would have some real concerns about the nature of the SLAs I could agree with my VPN customers. Maybe some VPN customers (who are used to trad L1/2 VPN solutions) might not be so happy about this type of performance? And in which case I would need an alternative solution that is *proved* to be stable enough.......and that includes both the dynamic defect behaviour from control-plane aberrations as well as those arising from data-plane aberrations (which are likely to be sourced from L1, and where the data-plane behaviour could also impact the control-plane behaviour). > While there are a number of problems in the distribution of public IP > routes > around the Internet, I haven't seen any clear statement or reasoned > argument > as to why these problems should affect the distribution of the VPN-IP > routes > in the more controlled environment offered by a VPN service provider. [Harrison,N,Neil,INC1 X] I agree. However, I have seen many pleas for 'comments from operators' and I have given one of my concerns here, which as yet is still unresolved to my satisfaction.....so I will briefly repeat it as I think it is relevant to trying to compare different methods of delivering VPNs: An SLA related to QoS is all about the up-state forwarding behaviour when everything is working as expected. A more important SLA however is related to when things are not working as expected and there are outages. I can easily imagine a situation where the QoS SLAs are common (ie the same or very similar) across the majority of VPNs, but where the availability SLAs need to be very different across VPNs (or even across different workgroups in the same VPN). I can't appeal to DiffServ here since this assumes an up-state (and as an aside observation DiffServ will mutate failures into QoS hits, skewed by class wrt to forwarding 'survival' priority....which is not really what I want). So what I need is a better handle on LSP failure behaviour and tools to provide this....hence the OAM ID which some of us are now working on. To provide VPNs using MPLS one has to have at least a label stack depth of 2. Adding other considerations (eg TE) will also increase the label stacking depth. I now have 2 degrees of freedom wrt to client/server LSP relationships: - nesting within a single LDP-type - nesting across multiple LDP-types What I want to understand better is the expected defect behaviour for various combination of LDP-type nesting, ie stacking of LSPs using vanilla-LDP, CR-LDP, RSVP-LDP and BGP4-LDP in various arrangements. I would expect there to be some differences and I think this needs to be explored and better understood by operators. If we understood the above better, operators would be able to say something more concrete about MPLS VPN behaviour and the SLAs we could set/enforce......and from your observations here Eric, I would also suggest we have to add other methods of VPN construct (eg IPSec) to the list for evaluation/comparison purposes. These all ought to be benchmarked against the trad L1/L2-type of VPN behaviour. And yes I am well aware of the config/scaling issues here, but if a particular VPN technology cannot, for whatever reason, offer the QoS/availability that some customers will demand then we should know about this. Regards, Neil > > From owner-mpls@UU.NET Tue Sep 12 06:55:31 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28945 for ; Tue, 12 Sep 2000 06:55:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjghv23428; Tue, 12 Sep 2000 10:55:07 GMT Received: by mail-control.mail.uu.net id QQjghv02775 for mpls-outgoing; Tue, 12 Sep 2000 10:54:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjghv02765 for ; Tue, 12 Sep 2000 10:54:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjghv14517 for ; Tue, 12 Sep 2000 06:53:00 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjghv27409 for ; Tue, 12 Sep 2000 10:52:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA20675 for mpls@uu.net; Tue, 12 Sep 2000 06:52:59 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjghv02719 for ; Tue, 12 Sep 2000 10:52:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjghv14340 for ; Tue, 12 Sep 2000 06:51:10 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjghv25975 for ; Tue, 12 Sep 2000 10:50:54 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28743; Tue, 12 Sep 2000 06:50:53 -0400 (EDT) Message-Id: <200009121050.GAA28743@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lmp-00.txt Date: Tue, 12 Sep 2000 06:50:53 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Link Management Protocol (LMP) Author(s) : J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter, L. Berger, D. Saha, D. Basak, H. Sandick Filename : draft-ietf-mpls-lmp-00.txt Pages : 34 Date : 11-Sep-00 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with bundled links consisting of a number of user component links and an associated control channel. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and will be used for both link provisioning and fault isolation. A unique feature of LMP is that it is able to isolate faults in both opaque and transparent networks, independent of the encoding scheme used for the component links. LMP will be used to maintain control channel connectivity, verify component link connectivity, and isolate link, fiber, or channel failures within the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lmp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lmp-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: <20000911143503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000911143503.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Sep 12 06:55:33 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28955 for ; Tue, 12 Sep 2000 06:55:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjghv28836; Tue, 12 Sep 2000 10:55:05 GMT Received: by mail-control.mail.uu.net id QQjghv02770 for mpls-outgoing; Tue, 12 Sep 2000 10:54:34 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjghv02764 for ; Tue, 12 Sep 2000 10:54:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjghv14514 for ; Tue, 12 Sep 2000 06:53:00 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjghv27407 for ; Tue, 12 Sep 2000 10:52:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA20674 for mpls@uu.net; Tue, 12 Sep 2000 06:52:59 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjghv02718 for ; Tue, 12 Sep 2000 10:52:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjghv14329 for ; Tue, 12 Sep 2000 06:50:49 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjghv25916 for ; Tue, 12 Sep 2000 10:50:49 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28726; Tue, 12 Sep 2000 06:50:47 -0400 (EDT) Message-Id: <200009121050.GAA28726@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-recovery-frmwrk-00.txt Date: Tue, 12 Sep 2000 06:50:47 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Framework for MPLS-based Recovery Author(s) : V. Sharma et al. Filename : draft-ietf-mpls-recovery-frmwrk-00.txt Pages : 30 Date : 11-Sep-00 Multi-protocol label switching (MPLS) [1] integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling [2] [3] [4] [5] [6] support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-recovery-frmwrk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-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: <20000911143454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-recovery-frmwrk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000911143454.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Sep 12 10:16:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04434 for ; Tue, 12 Sep 2000 10:16:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgij15049; Tue, 12 Sep 2000 14:16:26 GMT Received: by mail-control.mail.uu.net id QQjgij01669 for mpls-outgoing; Tue, 12 Sep 2000 14:15:43 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgij01630 for ; Tue, 12 Sep 2000 14:15:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgij18519 for ; Tue, 12 Sep 2000 10:15:09 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjgii13891 for ; Tue, 12 Sep 2000 14:14:39 GMT Received: from tellium.com (node1.tellium.com [151.198.92.15]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e8CE7UM02227; Tue, 12 Sep 2000 10:07:30 -0400 (EDT) Message-ID: <39BE398F.F992D026@tellium.com> Date: Tue, 12 Sep 2000 10:11:27 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, routing-discussion@ietf.org Subject: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt] Content-Type: multipart/mixed; boundary="------------6EC2A1215DD71CBDCC0D0364" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------6EC2A1215DD71CBDCC0D0364 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I regret to bring to your attention the following draft which was recently announced. Please be warned that I might apply for a BOF slot in the upcoming IETF meeting to discuss this topic. Regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com --------------6EC2A1215DD71CBDCC0D0364 Content-Type: message/rfc822 Content-Disposition: inline Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e8CCJFM26831; Tue, 12 Sep 2000 08:19:15 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA23809 for ietf-123-outbound.05@ietf.org; Tue, 12 Sep 2000 07:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA23418 for ; Tue, 12 Sep 2000 06:49:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28552 for ; Tue, 12 Sep 2000 06:49:57 -0400 (EDT) Message-Id: <200009121049.GAA28552@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-bala-mplamps-00.txt Date: Tue, 12 Sep 2000 06:49:57 -0400 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLampS: Electricity over IP (with an MPLS control plane) Author(s) : B. Rajagopalan Filename : draft-bala-mplamps-00.txt Pages : 7 Date : 11-Sep-00 Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve manageability of delivering electricity. This draft is motivated by such drafts as SONET/SDH over IP/MPLS [2,3] (with apologies to their authors). Readers of the previous drafts have been observed scratching their heads and muttering, 'What next?'. This draft answers that question. This draft has also been written as a public service. It was recently announced that the routing area will consider work items of the form 'foo-over-MPLS'. There are possibly many who are wondering how to exploit this opportunity and write random drafts to achieve prominence in the MPLS area. This draft illustrates the key ingredients that go into producing any 'foo-over-MPLS' draft and may be used as a template for all such work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bala-mplamps-00.txt 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-bala-mplamps-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-bala-mplamps-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: <20000911143321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bala-mplamps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bala-mplamps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000911143321.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------6EC2A1215DD71CBDCC0D0364-- From owner-mpls@UU.NET Tue Sep 12 11:07:12 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05927 for ; Tue, 12 Sep 2000 11:07:12 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgim12681; Tue, 12 Sep 2000 15:06:56 GMT Received: by mail-control.mail.uu.net id QQjgim16211 for mpls-outgoing; Tue, 12 Sep 2000 15:06:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgim15663 for ; Tue, 12 Sep 2000 15:06:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgim00258 for ; Tue, 12 Sep 2000 11:06:01 -0400 (EDT) Received: from fortress.fnc.fujitsu.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1]) id QQjgim11855 for ; Tue, 12 Sep 2000 15:06:01 GMT Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id KAA07257; Tue, 12 Sep 2000 10:05:59 -0500 (CDT) Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Sep 2000 10:06:00 -0500 Message-ID: From: "Dawkins, Spencer" To: "'mpls@UU.NET'" , "'routing-discussion@ietf.org'" Subject: RE: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt] Date: Tue, 12 Sep 2000 10:05:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Bala, You ARE a genius. I note that you're about 180 degrees out of phase, because April Fool's Day was six months ago (or six months from now, whatever). To software guys like me, having your polarity reversed 180 degrees demonstrates your prowess with working code (or working SOMEthing?), which means that all you need NOW is rough consensus. Your draft would make consensus on almost any topic rougher. Therefore, we must be very close to IETF last call for mplamps as a proposed standard. Are you still looking for co-authors? Or is the only opportunity in interoperability testing, when you convince other implementers to stick their fingers into electrical outlets so we can advance mplamps to draft standard? This was great. Thanks for making my week! ("Please be warned ..." - I love it!) Spencer > -----Original Message----- > From: Bala Rajagopalan [SMTP:braja@tellium.com] > Sent: Tuesday, September 12, 2000 9:11 AM > To: mpls@UU.NET; routing-discussion@ietf.org > Subject: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt] > > > I regret to bring to your attention the following draft which was > recently > announced. Please be warned that I might apply for a BOF slot in the > upcoming IETF meeting to discuss this topic. > > Regards, > > -- > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > << Message: I-D ACTION:draft-bala-mplamps-00.txt >> From owner-mpls@UU.NET Tue Sep 12 11:17:01 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06369 for ; Tue, 12 Sep 2000 11:17:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgin27684; Tue, 12 Sep 2000 15:16:43 GMT Received: by mail-control.mail.uu.net id QQjgin20271 for mpls-outgoing; Tue, 12 Sep 2000 15:16:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgin20261 for ; Tue, 12 Sep 2000 15:16:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgin23166 for ; Tue, 12 Sep 2000 11:15:59 -0400 (EDT) Received: from server.nayna.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 069-035.dsl.popsite.net [64.24.69.35]) id QQjgin27100 for ; Tue, 12 Sep 2000 15:15:43 GMT Received: from nayna.com (069-034.dsl.popsite.net [64.24.69.34]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id IAA15885; Tue, 12 Sep 2000 08:07:10 -0700 X-Authentication-Warning: server.nayna.com: Host 069-034.dsl.popsite.net [64.24.69.34] claimed to be nayna.com Message-ID: <39BE46A6.7DC39B31@nayna.com> Date: Tue, 12 Sep 2000 08:07:18 -0700 From: Sudheer Dharnikota X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gaitonde Anandprasanna CC: mpls@UU.NET Subject: Re: Questions regarding the RSVP-TE and MPLS interaction. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Prasanna: The general concept is "you create the paths with some characteristics and later associate who can use these paths". MPLS TE will tell ou how to create to these paths. You (as an ISP or what have you) have to decide how to use them. sudheer Gaitonde Anandprasanna wrote: > > > > I am currently doing a Project in RSVP-TE and MPLS alongwith my > collegue and had several question to ask on these. > > I have been reading the drafts for RSVP-TE uptill the most recent one > that is RSVP_TE 07.txt. > > These drafts have been discussing the various object formats in the > messages used by RSVP-TE and their use. > > The draft has mentioned something like LSP tunnel and a Traffic > Engineered Tunnel. (Page 8). The objects in the Path messages like the > session object and the Sender Template object contains these fields like > LSP ID and Tunnel ID. But how do u realise this Traffic Engineered Tunnel > and LSP tunnel in the MPLS domain. > > And once this tunnel is created how do u acheive Traffic Engineering over > it. These things are not very clear to me. and I am confused as to how the > parameters like LSP ID and Tunnel ID in the RSVP_TE will help me create > an MPLS tunnel (which may be comprised of several LSPs) and also as to how > i engineer the traffic over this tunnel. > > What sort of interaction will RSVP-TE and MPLS require between them so > that the various things like LSP ID and TUNNEL ID in the signalling of > RSVP-TE will finally boil down to an MPLS LSP Tunnel or a TE Tunnel being > created. > > Please explain as to how this can be realised. > > Thanking in advance > > Prasanna > > > _____________________________ > _ |ANANDPRASANNA GAITONDE | _ > / )|COMP. SCIENCE & AUTOMATION |( \ > / / |D-7,IISc HOSTEL | \ \ > / / |INDIAN INSTITUTE OF SCIENCE| \ \ > _( (_ |BANGALORE-560012. | _) )_ > (((\ \>|_/->___________________<-\_| (\\\\ \_/ /LAB Ph.(080)3092906 \ \_/ ////) > \ /HOSTEL Ph.- \ / > \ _/ (080)3092452 \_ / > / /-----------------------------\ \ > / Email Id- \ > / prasanna@csa.iisc.ernet.in \ > --------------------------------------------- > ----------------------------------------------- > > -------------------------------------------------------------------------------- > > ************************************************************************* > | | | | __ ___ _____ __ _ _ __ (_) ___ ___ __| | __ _ _ _ > | |_| |/ _` \ \ / / _ \ / _` | | '_ \| |/ __/ _ \ / _` |/ _` | | | | > | _ | (_| |\ V / __/ | (_| | | | | | | (_| __/ | (_| | (_| | |_| | > |_| |_|\__,_| \_/ \___| \__,_| |_| |_|_|\___\___| \__,_|\__,_|\__, | > ************************************************************************* From owner-mpls@UU.NET Tue Sep 12 11:22:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06533 for ; Tue, 12 Sep 2000 11:22:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgin01450; Tue, 12 Sep 2000 15:22:25 GMT Received: by mail-control.mail.uu.net id QQjgin20972 for mpls-outgoing; Tue, 12 Sep 2000 15:21:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgin20965 for ; Tue, 12 Sep 2000 15:21:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgin02967 for ; Tue, 12 Sep 2000 11:21:12 -0400 (EDT) Received: from viper2.alleghenypower.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: viper2.alleghenypower.com [198.77.48.2]) id QQjgin00511 for ; Tue, 12 Sep 2000 15:21:11 GMT Received: from viper2.alleghenypower.com (root@localhost) by viper2.alleghenypower.com with ESMTP id LAA24843 for ; Tue, 12 Sep 2000 11:21:11 -0400 (EDT) Message-Id: <200009121521.LAA24833@viper2.alleghenypower.com> From: "Hull, Kenneth A." To: mpls@UU.NET, routing-discussion@ietf.org Subject: RE: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt] Date: Tue, 12 Sep 2000 11:21:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk This adds new meaning to flickering lights. We now have a visual indication of route flapping, slow convergence, etc. > -----Original Message----- > From: Bala Rajagopalan [SMTP:braja@tellium.com] > Sent: Tuesday, September 12, 2000 10:11 AM > To: mpls@UU.NET; routing-discussion@ietf.org > Subject: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt] > > > I regret to bring to your attention the following draft which was > recently > announced. Please be warned that I might apply for a BOF slot in the > upcoming IETF meeting to discuss this topic. > > Regards, > > -- > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > << Message: I-D ACTION:draft-bala-mplamps-00.txt >> From owner-mpls@UU.NET Wed Sep 13 07:00:54 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04311 for ; Wed, 13 Sep 2000 07:00:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjglo17788; Wed, 13 Sep 2000 11:00:43 GMT Received: by mail-control.mail.uu.net id QQjglo21535 for mpls-outgoing; Wed, 13 Sep 2000 11:00:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjglo20901 for ; Wed, 13 Sep 2000 11:00:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgln12642 for ; Wed, 13 Sep 2000 06:59:53 -0400 (EDT) Received: from smtp2.cluster.oleane.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQjgln10329 for ; Wed, 13 Sep 2000 10:59:53 GMT Received: from oleane (dyn-1-1-110.Vin.dialup.oleane.fr [195.25.4.110]) by smtp2.cluster.oleane.net with SMTP id NAA36955 for ; Wed, 13 Sep 2000 13:02:25 +0200 (CEST) Message-ID: <013d01c01d71$61dc2060$7501a8c0@oleane.oleane.com> From: "Peter Lewis" To: Subject: IP over DWDM 2000 International Conference, Paris 27-30 November, 2000 Date: Wed, 13 Sep 2000 12:57:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01C01D82.25003B20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_013A_01C01D82.25003B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This event aims at presenting an up-to-date state of the art in the = design of new Internet network architectures. It will be a unique = opportunity for researchers, network operators and service providers = from both the IP world and the optical networking world to discuss the = potentialities of all these promising perspectives.=20 http://www.upperside.fr/badwdm.htm ------=_NextPart_000_013A_01C01D82.25003B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This event aims at presenting an up-to-date state of the art in the = design=20 of new Internet network architectures. It will be a unique opportunity = for=20 researchers, network operators and service providers from both the IP = world and=20 the optical networking world to discuss the potentialities of all these=20 promising perspectives.
 
http://www.upperside.fr/badwd= m.htm
------=_NextPart_000_013A_01C01D82.25003B20-- From owner-mpls@UU.NET Wed Sep 13 09:16:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07389 for ; Wed, 13 Sep 2000 09:16:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjglx19432; Wed, 13 Sep 2000 13:16:47 GMT Received: by mail-control.mail.uu.net id QQjglx03490 for mpls-outgoing; Wed, 13 Sep 2000 13:16:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjglx03431 for ; Wed, 13 Sep 2000 13:16:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjglx01487; Wed, 13 Sep 2000 09:16:02 -0400 (EDT) Received: from blsmsgims03.bls.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: iocfirewall2ext.bls.com [139.76.64.4]) id QQjglx25542; Wed, 13 Sep 2000 13:15:47 GMT Received: from SMTP (blsmsgims03.bls.com [139.76.86.35]) by blsmsgims03.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SYQ2NP3G; Wed, 13 Sep 2000 09:15:47 -0400 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.35 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 13 Sep 2000 13:15:46 0000 (GMT) Received: from gf5142_gxsmlg (g0214070 [90.30.214.70]) by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id JAA18969; Wed, 13 Sep 2000 09:15:34 -0400 (EDT) From: "Steven Wright" To: "'Jeremy Lawrence'" , "'Florian-Daniel Otel'" Cc: , Subject: RE: Incremental MPLS (BCP document lookup) Date: Wed, 13 Sep 2000 09:15:31 -0400 Message-ID: <000601c01d84$b2409780$46d61e5a@gf5142_gxsmlg.snt.bst.bls.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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <4.3.2.7.2.20000906084934.00b09300@bulkrate.cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-te-wg@UU.NET [mailto:owner-te-wg@UU.NET]On Behalf > Of Jeremy > Lawrence > Sent: Tuesday, September 05, 2000 6:00 PM > To: Florian-Daniel Otel > Cc: mpls@UU.NET; te-wg@UU.NET > Subject: Re: Incremental MPLS (BCP document lookup) > > > Florian, > > > >I am looking for a case study document/white paper focused > >on/describing the possible means (maybe even claimed advantages ?) of > >introducing MPLS in a _incremental_ manner in a core network. > > What does the core network look like before MPLS is turned on? > > If the core network is an IP router network then there is at least > one router implementation where MPLS signalling (LDP or RSVP) can be > enabled on a link-by-link basis in a live network (possibly after a > software upgrade, which can be done node-by-node). The advantage > of is largely that the network can still be forwarding IP traffic > while the MPLS upgrade is going on. > > If the core network is an ATM network, there are many more options. > Is there any documentation ( BCP etc ) listing the options for evolving from ATM towards MPLS ? regards Steven Wright > Regards, > > Jeremy > > > From owner-mpls@UU.NET Wed Sep 13 10:48:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09576 for ; Wed, 13 Sep 2000 10:48:52 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgmd15777; Wed, 13 Sep 2000 14:48:40 GMT Received: by mail-control.mail.uu.net id QQjgmd21769 for mpls-outgoing; Wed, 13 Sep 2000 14:48:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgmd21764 for ; Wed, 13 Sep 2000 14:48:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgmd16974 for ; Wed, 13 Sep 2000 10:47:54 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjgmd08635 for ; Wed, 13 Sep 2000 14:47:48 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA16636 for ; Wed, 13 Sep 2000 07:48:08 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA15734 for mpls@uu.net; Wed, 13 Sep 2000 10:47:47 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgla04058 for ; Wed, 13 Sep 2000 07:37:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgla22294 for ; Wed, 13 Sep 2000 03:37:00 -0400 (EDT) Received: from router-f.hirp.ece.iisc.ernet.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: unalloc-94net-223.iisc.ernet.in [144.16.94.223] (may be forged)) id QQjgla05851 for ; Wed, 13 Sep 2000 07:36:21 GMT Received: from localhost (root@localhost) by router-f.hirp.ece.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA01108 for ; Tue, 12 Sep 2000 14:46:04 +0530 Date: Tue, 12 Sep 2000 14:46:04 +0530 (IST) From: root To: mpls@UU.NET Subject: Question regarding Label stacking. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I was reading the most recent draft of RSVP-TE. But did not find any mention of Label stacking being supported. For heirarchical tunnel establishment in MPLS RSVP-TE should be able to support label stacking . i.e the RESV message should be able to carry more thn one label object for the same LSP. Is it allowed ? Yours sincerely Prasanna From owner-mpls@UU.NET Wed Sep 13 10:48:58 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09586 for ; Wed, 13 Sep 2000 10:48:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgmd09237; Wed, 13 Sep 2000 14:48:29 GMT Received: by mail-control.mail.uu.net id QQjgmd21762 for mpls-outgoing; Wed, 13 Sep 2000 14:48:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgmd21750 for ; Wed, 13 Sep 2000 14:47:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgmd16897 for ; Wed, 13 Sep 2000 10:47:31 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjgmd08211 for ; Wed, 13 Sep 2000 14:47:15 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA16283 for ; Wed, 13 Sep 2000 07:47:35 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA15727 for mpls@uu.net; Wed, 13 Sep 2000 10:47:13 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgkl05200 for ; Wed, 13 Sep 2000 03:48:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgkl28008 for ; Tue, 12 Sep 2000 23:47:09 -0400 (EDT) Received: from web2904.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web2904.mail.yahoo.com [128.11.68.47]) id QQjgkl28849 for ; Wed, 13 Sep 2000 03:47:05 GMT Received: (qmail 5573 invoked by uid 60001); 13 Sep 2000 03:47:05 -0000 Message-ID: <20000913034705.5572.qmail@web2904.mail.yahoo.com> Received: from [192.51.44.15] by web2904.mail.yahoo.com; Tue, 12 Sep 2000 20:47:05 PDT Date: Tue, 12 Sep 2000 20:47:05 -0700 (PDT) From: Ashwini Gupte Subject: Query on MPLS To: vijay@torrentnet.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello Vijay, I am developing diagnostic software to test the edge router. I am goimg to use MPLS in OSPF environment. I have following doubts about it. Could you please help me in this regard ? 1. When we use LDP with OSPF, are there any changes to be done in OPSF packet formats ? What does it mean by piggybacking the label in routing protocol ? Does this mean that labels are added in form of TLV in OSPF LSAs ? 2. How do we establish LDP sessions between LSRs in the above case ? Do we establish OSPF environment separately and then establish LDP sessions ? Hoping to hear from you. Thanks and regards, Ashwini __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Wed Sep 13 11:55:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10967 for ; Wed, 13 Sep 2000 11:55:52 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgmh29252; Wed, 13 Sep 2000 15:55:31 GMT Received: by mail-control.mail.uu.net id QQjgmh08250 for mpls-outgoing; Wed, 13 Sep 2000 15:55:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgmh08237 for ; Wed, 13 Sep 2000 15:54:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgmh29864 for ; Wed, 13 Sep 2000 11:54:39 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgmh00207 for ; Wed, 13 Sep 2000 15:54:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA07491 for mpls@uu.net; Wed, 13 Sep 2000 11:54:37 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgmh08212 for ; Wed, 13 Sep 2000 15:54:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgmh02859 for ; Wed, 13 Sep 2000 11:53:58 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjgmh29543 for ; Wed, 13 Sep 2000 15:53:43 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 11:53:26 -0400 Message-ID: <87009604743AD411B1F600508BA0F959071484@xover.hjinc.com> From: "Atkinson, Stephen" To: mpls@UU.NET Subject: LDP MIB 07 FEC Table Date: Wed, 13 Sep 2000 11:53:25 -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 I'm trying to understand the purpose of the LDP MIB FEC Table, which comes under the "mplsLdpGeneralGroup", when the "mplsLdpMappingGroup" (where FEC Table used to live) isn't implemented. Is it intended as a means of setting up LSPs via row creation? If so, there is no way of associating a FEC row with an LSP, or of knowing whether the LSP was successfully signalled. So, what use is the FEC Table if the mplsLdpMappingGroup isn't implemented? Regards, steve atkinson From owner-mpls@UU.NET Wed Sep 13 12:13:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11404 for ; Wed, 13 Sep 2000 12:13:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgmi14633; Wed, 13 Sep 2000 16:13:20 GMT Received: by mail-control.mail.uu.net id QQjgmi21544 for mpls-outgoing; Wed, 13 Sep 2000 16:12:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgmi21526 for ; Wed, 13 Sep 2000 16:12:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgmi06820 for ; Wed, 13 Sep 2000 12:12:11 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgmi13685 for ; Wed, 13 Sep 2000 16:12:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA10284 for mpls@uu.net; Wed, 13 Sep 2000 12:12:10 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgmi21457 for ; Wed, 13 Sep 2000 16:11:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgmi03152 for ; Wed, 13 Sep 2000 12:11:35 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [216.241.231.251]) id QQjgmi13256 for ; Wed, 13 Sep 2000 16:11:35 GMT Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 09:15:22 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E53@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Mark Dewey'" , mpls@UU.NET Cc: rsvp@ISI.EDU, int-serv@ISI.EDU Subject: RE: CR-LDP traffic parameter TLV and RSVP Date: Wed, 13 Sep 2000 09:15:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Mark, For supporting Diffserv, a new Diffserv object/TLV is introduced for RSVP and CR-LDP respectively in "MPLS support of Diffserv draft". In case of RSVP, if the Diffserv object and the CoS object are not present the node should implement Intserv, however, the presence of each one indicates non-Intserv (Diffserv) implementation. Regards, -Shahram -----Original Message----- From: Mark Dewey [mailto:deweymark@hotmail.com] Sent: Wednesday, August 30, 2000 1:55 PM To: mpls@uu.net Cc: rsvp@ISI.EDU; int-serv@ISI.EDU Subject: CR-LDP traffic parameter TLV and RSVP Hi, I apologize for the wide distribution. I am not sure which mailing list this question belongs to. I understand, in CR-LDP, the qos characteristics(e.g bandwidth) of an LSP tunnel can be specified in traffic parameter (e.g CDR) TLV. How is this value specified in RSVP if it were used to establish a LSP tunnel with qos characteristics? If sender TSPEC object is used, should the node implement integrated services (CL,GS)? Thanks, -Mark _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Wed Sep 13 15:18:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16352 for ; Wed, 13 Sep 2000 15:18:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgmv08754; Wed, 13 Sep 2000 19:18:37 GMT Received: by mail-control.mail.uu.net id QQjgmv15032 for mpls-outgoing; Wed, 13 Sep 2000 19:18:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgmv15027 for ; Wed, 13 Sep 2000 19:18:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgmv14336 for ; Wed, 13 Sep 2000 15:18:04 -0400 (EDT) Received: from dnsmx2pya.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQjgmv08028 for ; Wed, 13 Sep 2000 19:18:03 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id PAA25368 for ; Wed, 13 Sep 2000 15:15:47 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256959.0069CBD8 ; Wed, 13 Sep 2000 15:15:34 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256959.0069CAFE.00@notes949.cc.telcordia.com> Date: Wed, 13 Sep 2000 15:13:48 -0400 Subject: RSVP-TE question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have questions for the IPv4 address of Explicit Route Object contents field. Is it ingress's node's IP address? Thanks in advance. Julia From owner-mpls@UU.NET Wed Sep 13 16:57:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17515 for ; Wed, 13 Sep 2000 16:57:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgnb10312; Wed, 13 Sep 2000 20:56:51 GMT Received: by mail-control.mail.uu.net id QQjgnb04700 for mpls-outgoing; Wed, 13 Sep 2000 20:56:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgnb04695 for ; Wed, 13 Sep 2000 20:56:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgnb24886 for ; Wed, 13 Sep 2000 16:56:21 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgnb09718 for ; Wed, 13 Sep 2000 20:55:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA21116 for mpls@uu.net; Wed, 13 Sep 2000 16:55:50 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgnb04663 for ; Wed, 13 Sep 2000 20:55:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgnb24710 for ; Wed, 13 Sep 2000 16:55:08 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQjgnb17572 for ; Wed, 13 Sep 2000 20:54:53 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 16:54:52 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEECD@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Atkinson, Stephen'" , mpls@UU.NET Subject: RE: LDP MIB 07 FEC Table Date: Wed, 13 Sep 2000 16:54:51 -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 > -----Original Message----- > From: Atkinson, Stephen [mailto:stevea@netplane.com] > Sent: Wednesday, September 13, 2000 11:53 AM > To: mpls@UU.NET > Subject: LDP MIB 07 FEC Table > > > > I'm trying to understand the purpose of the LDP MIB FEC Table, > which comes under the "mplsLdpGeneralGroup", when the > "mplsLdpMappingGroup" (where FEC Table used to live) isn't > implemented. Is it intended as a means of setting up LSPs > via row creation? If so, there is no way of associating a FEC > row with an LSP, or of knowing whether the LSP was successfully > signalled. So, what use is the FEC Table if the mplsLdpMappingGroup > isn't implemented? Hi Stephen, The FEC table was moved to the mplsLdpGeneralGroup because it doesn't have a direct dependency on the LSR MIB being implemented which is true of the other objects in the mplsLdpMappingGroup. Assuming that the mplsLdpMappingGroup is not implemented, there is still a need to solve the LSP issues you mention above, which means that these would be in proprietary MIBs. If a proprietary MIB has a LIB/XC table, they should use this FEC Table and map between the prioritary LIB/XC table and the standard FEC table. As you can see the FEC table is pretty minimal. Thanks, Joan > > Regards, > steve atkinson > From owner-mpls@UU.NET Thu Sep 14 00:56:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23828 for ; Thu, 14 Sep 2000 00:56:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgoh29293; Thu, 14 Sep 2000 04:56:14 GMT Received: by mail-control.mail.uu.net id QQjgoh05400 for mpls-outgoing; Thu, 14 Sep 2000 04:55:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgoh05390 for ; Thu, 14 Sep 2000 04:55:43 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgoh08898 for ; Thu, 14 Sep 2000 00:55:30 -0400 (EDT) Received: from fsnt.future.futusoft.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjgoh12098 for ; Thu, 14 Sep 2000 04:55:26 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 14 Sep 2000 10:39:01 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA31817; Thu, 14 Sep 2000 10:13:07 +0530 Reply-To: From: "Manikantan S" To: "'Hong Liao'" , Subject: RE: RSVP-TE question Date: Thu, 14 Sep 2000 10:22:56 +0530 Message-Id: <000501c01e07$a6c35f40$1006000a@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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <85256959.0069CAFE.00@notes949.cc.telcordia.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello #-----Original Message----- #From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Hong Liao #Sent: Thursday, 14 September 2000 12:44 AM #To: mpls@uu.net #Subject: RSVP-TE question # # # # #Hi, # #I have questions for the IPv4 address of Explicit Route Object contents field. # #Is it ingress's node's IP address? Mani> No. it is not the Ingress's node's IP Address. It is the IP address of the network or the host that is decided to be made part of the LSP/Tunnel. For example consider the following network 10.1.1.1 10.1.2.2 10.1.3.2 LERA---------------------LSR1--------------------LSR2---------------------LE RB 10.1.1.2 10.1.2.1 10.1.3.1 1) From LERA a RSVP Path message (containing strict ER hops) can sent to LERB with three strict ER Hops the IPv4 address in the first, second and third ER hops will (can) be 10.1.1.2, 10.1.2.1 and 10.1.3.1 respectively and the Prefix length of 32 for all the three addresses. 2) From LERA a RSVP Path message (containing strict ER hops) can sent to LERB with three strict ER Hops the IPv4 address in the first, second and third ER hops will (can) be 10.1.2.0, 10.1.3.0 and 10.1.3.1 respectively and the Prefix length of 24 for the first two ER hops and 32 for all the third ER hop. # #Thanks in advance. # #Julia regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com web : www.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Thu Sep 14 09:10:57 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10579 for ; Thu, 14 Sep 2000 09:10:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgpo14588; Thu, 14 Sep 2000 13:10:44 GMT Received: by mail-control.mail.uu.net id QQjgpo13685 for mpls-outgoing; Thu, 14 Sep 2000 13:10:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgpo13679 for ; Thu, 14 Sep 2000 13:10:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgpo07799 for ; Thu, 14 Sep 2000 09:08:04 -0400 (EDT) Received: from laptoy770.fictitious.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laptoy-ether.fictitious.org [209.66.129.226] (may be forged)) id QQjgpo18834 for ; Thu, 14 Sep 2000 13:07:47 GMT Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.9.2/8.9.2) with ESMTP id JAA73705; Thu, 14 Sep 2000 09:02:02 -0400 (EDT) (envelope-from curtis@laptoy770.fictitious.org) Message-Id: <200009141302.JAA73705@laptoy770.fictitious.org> To: erosen@cisco.com cc: bkumar@ennovatenetworks.com, "'Ramana V Gollamudi'" , "'Randy Bush'" , "'mpls wg'" Reply-To: curtis@avici.com Subject: Re: ISPs offering VPN service In-reply-to: Your message of "Mon, 11 Sep 2000 12:31:57 EDT." <200009111631.MAA12745@erosen-sun.cisco.com> Date: Thu, 14 Sep 2000 09:02:02 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200009111631.MAA12745@erosen-sun.cisco.com>, Eric Rosen writes: > > Curtis> Managing the aggregation of private address space for the benefit of > Curtis> each customer is something I'd rather not have to do, but then again > Curtis> I don't work for a provider anymore so I guess someone else gets to > Curtis> decide if this sounds like too much work. > > One needs to keep in mind that the provider might otherwise be managing a > large number of point-to-point VCs, and then providing a managed backbone > service to each customer as well. As I've said before, it's not valid to > compare the amount of work needed to provide VPN service with the amount of > work needed if you don't provide it. To configure a VC you don't need to know about the subnets behind the customer's CE router. You seemed to have lost my point. If you need to configure things on the PE to help manage the customers proviate address space the amount of work can become unbounded (largely due to the fact that the amount of customer clue is highly bounded, ie "what's CIDR mean"). I suggested a way to avoid participating in managing the customers private address space. That would make the work comparable to that of managing VCs as long as the public side addresses were sensibly CIDR allocated. Curtis From owner-mpls@UU.NET Thu Sep 14 09:52:23 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12063 for ; Thu, 14 Sep 2000 09:52:23 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgpr19162; Thu, 14 Sep 2000 13:51:56 GMT Received: by mail-control.mail.uu.net id QQjgpr17121 for mpls-outgoing; Thu, 14 Sep 2000 13:51:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgpr17113 for ; Thu, 14 Sep 2000 13:51:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgpr20306 for ; Thu, 14 Sep 2000 09:47:32 -0400 (EDT) Received: from laptoy770.fictitious.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laptoy-ether.fictitious.org [209.66.129.226] (may be forged)) id QQjgpr10084 for ; Thu, 14 Sep 2000 13:47:01 GMT Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.9.2/8.9.2) with ESMTP id JAA73810; Thu, 14 Sep 2000 09:47:15 -0400 (EDT) (envelope-from curtis@laptoy770.fictitious.org) Message-Id: <200009141347.JAA73810@laptoy770.fictitious.org> To: Bala Rajagopalan cc: mpls@UU.NET, routing-discussion@ietf.org Reply-To: curtis@avici.com Subject: Re: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt] In-reply-to: Your message of "Tue, 12 Sep 2000 10:11:27 EDT." <39BE398F.F992D026@tellium.com> Date: Thu, 14 Sep 2000 09:47:15 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <39BE398F.F992D026@tellium.com>, Bala Rajagopalan writes: > This is a multi-part message in MIME format. > --------------6EC2A1215DD71CBDCC0D0364 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > I regret to bring to your attention the following draft which was > recently > announced. Please be warned that I might apply for a BOF slot in the > upcoming IETF meeting to discuss this topic. > > Regards, > > -- > > Bala Rajagopalan Bala, Are you applying for the position of Foo over Lambda Switching WG chair? The work seems to fit in with the direction of the OIF signaling WG. Curtis From owner-mpls@UU.NET Thu Sep 14 10:17:46 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12756 for ; Thu, 14 Sep 2000 10:17:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgpt07258; Thu, 14 Sep 2000 14:17:07 GMT Received: by mail-control.mail.uu.net id QQjgpt01612 for mpls-outgoing; Thu, 14 Sep 2000 14:16:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgpt01605 for ; Thu, 14 Sep 2000 14:16:21 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgps26613 for ; Thu, 14 Sep 2000 10:08:46 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35]) id QQjgps01029 for ; Thu, 14 Sep 2000 14:08:45 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Thu, 14 Sep 2000 10:06:16 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 14 Sep 2000 10:06:12 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4029F986B@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'curtis@avici.com'" , Bala Rajagopalan Cc: mpls@UU.NET, routing-discussion@ietf.org Subject: RE: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt] Date: Thu, 14 Sep 2000 10:06:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01E54.EA081BE0" 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_01C01E54.EA081BE0 Content-Type: text/plain; charset="iso-8859-1" Love the idea of a BOF but I have an even better idea. Lets create a FORUM for it with montly meetings in Hawaii. After all it will take ages for all our products to be mplamps compatible so these meetings would have to go on for ... years? Closed door interoperability testing would be held in some equally tropical place ;) Cheers, Peter -----Original Message----- From: Curtis Villamizar [SMTP:curtis@avici.com] Sent: Thursday, September 14, 2000 9:47 AM To: Bala Rajagopalan Cc: mpls@UU.NET; routing-discussion@ietf.org Subject: Re: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt] In message <39BE398F.F992D026@tellium.com>, Bala Rajagopalan writes: > This is a multi-part message in MIME format. > --------------6EC2A1215DD71CBDCC0D0364 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > I regret to bring to your attention the following draft which was > recently > announced. Please be warned that I might apply for a BOF slot in the > upcoming IETF meeting to discuss this topic. > > Regards, > > -- > > Bala Rajagopalan Bala, Are you applying for the position of Foo over Lambda Switching WG chair? The work seems to fit in with the direction of the OIF signaling WG. Curtis ------_=_NextPart_001_01C01E54.EA081BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: I-D ACTION:draft-bala-mplamps-00.txt]

Love the idea of a BOF but I  = have an even better idea. Lets create a FORUM for it with montly = meetings in Hawaii.  After all it will take ages for all our = products to be mplamps compatible so these meetings would have to go on = for ... years? Closed door interoperability testing would be held in = some equally tropical place ;)

Cheers,

Peter

    -----Original = Message-----
    From:   Curtis = Villamizar [SMTP:curtis@avici.com]
    Sent:   Thursday, September 14, 2000 9:47 AM
    To:     Bala Rajagopalan
    Cc:     mpls@UU.NET; routing-discussion@ietf.org
    Subject:       = Re: [Fwd: I-D = ACTION:draft-bala-mplamps-00.txt]


    In message = <39BE398F.F992D026@tellium.com>, Bala Rajagopalan writes:
    > This is a multi-part message in = MIME format.
    > = --------------6EC2A1215DD71CBDCC0D0364
    > Content-Type: text/plain; = charset=3Dus-ascii
    > Content-Transfer-Encoding: = 7bit
    >
    >
    > I regret to bring to your = attention the following draft which was
    > recently
    > announced. Please be warned that = I might apply for a BOF slot in the
    > upcoming IETF meeting to discuss = this topic.
    >
    > Regards,
    >
    > --
    >
    > Bala Rajagopalan


    Bala,

    Are you applying for the position of = Foo over Lambda Switching WG
    chair?  The work seems to fit in = with the direction of the OIF
    signaling WG.

    Curtis

------_=_NextPart_001_01C01E54.EA081BE0-- From owner-mpls@UU.NET Thu Sep 14 11:35:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17276 for ; Thu, 14 Sep 2000 11:35:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgpy28180; Thu, 14 Sep 2000 15:34:59 GMT Received: by mail-control.mail.uu.net id QQjgpy20180 for mpls-outgoing; Thu, 14 Sep 2000 15:34:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgpy20170 for ; Thu, 14 Sep 2000 15:34:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgpx07341 for ; Thu, 14 Sep 2000 11:28:27 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjgpx25901 for ; Thu, 14 Sep 2000 15:28:26 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29639 for ; Thu, 14 Sep 2000 08:28:46 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA19546 for mpls@uu.net; Thu, 14 Sep 2000 11:28:25 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgpw18133 for ; Thu, 14 Sep 2000 15:13:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgpw05823 for ; Thu, 14 Sep 2000 11:06:42 -0400 (EDT) Received: from io.worldonline.be by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: io.worldonline.be [212.233.1.146]) id QQjgpw07495 for ; Thu, 14 Sep 2000 15:05:36 GMT Received: from c1p9a6 (dp51-140.worldonline.be [212.233.51.140]) by io.worldonline.be (8.8.5/8.8.5) with SMTP id RAA16746 for ; Thu, 14 Sep 2000 17:03:23 +0200 (MET DST) Message-ID: <000a01c01e5d$59d384c0$8c33e9d4@c1p9a6> From: "Robben Paul" To: Subject: question: DiffServ versus RSVP Date: Thu, 14 Sep 2000 17:06:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C01E6E.1B1264C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C01E6E.1B1264C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm currently making a thesis regarding IP-based VPN's, paying special = attention to traffic engineering and QoS. Something isn't clear to me. I read a couple of articles regarding the = use of explicit routes with CR-LDP and the extended RSVP. Apparently, some companies prefer the former, others the latter, but = there doesn't seem to be an official statement yet of which one's the = best. But however, RSVP still is a "hot topic". On the other hand, I also read some articles about DiffServ, mentionning = that DiffServ evolved from Intserv, which is based on RSVP, and that, = within some time, DiffServ will eliminate the need to use RSVP in WAN = area's.=20 I think I must be missing something here... 1. Some time ago, a reader from the MPLS-list described DiffServ as a = traffic light with reserved lanes for taxi's and busses. Its job is to = help prioritize things once congestion starts, and to penalize some = flows to allow others to get less delay or loss. So, I guess DiffServ = doesn't operate on the level of 1 LSP, but on a whole bunch of them? 2. On the other hand, the extended RSVP is a way to set up explicit = routes. So RSVP is important for each LSP separately? So, I don't really understand how DiffServ could eliminate the use of = RSVP??? It seems to me that, although they both serve QoS, they are = working on a complete different scale... Can anybody make me see the light in the darkness? :) Thanks in advance, Fran=E7oise Beckers (Global One) ------=_NextPart_000_0007_01C01E6E.1B1264C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'm currently making a thesis regarding = IP-based=20 VPN's, paying special attention to traffic engineering and = QoS.
Something isn't clear to me. I read a = couple of=20 articles regarding the use of explicit routes with CR-LDP and the = extended=20 RSVP.
Apparently, some companies prefer the = former,=20 others the latter, but there doesn't seem to be an official = statement yet=20 of which one's the best. But however, RSVP still is a "hot = topic".
On the other hand, I also read some = articles about=20 DiffServ, mentionning that DiffServ evolved from Intserv, which is based = on=20 RSVP, and that, within some time, DiffServ will eliminate the need to = use RSVP=20 in WAN area's.
 
I think I must be missing something=20 here...
1. Some time ago, a reader from the = MPLS-list=20 described DiffServ as a traffic light with reserved lanes for taxi's and = busses.=20 Its job is to help prioritize things once congestion starts, and to = penalize=20 some flows to allow others to get less delay or loss. So, I guess = DiffServ=20 doesn't operate on the level of 1 LSP, but on a whole bunch of=20 them?
2. On the other hand, the extended RSVP = is a way to=20 set up explicit routes. So RSVP is important for each LSP=20 separately?
 
So, I don't really understand how = DiffServ could=20 eliminate the use of RSVP??? It seems to me that, although they both = serve QoS,=20 they are working on a complete different scale...
 
Can anybody make me see the light in = the=20 darkness?
:)
Thanks in advance,
 
Fran=E7oise Beckers
(Global One)
------=_NextPart_000_0007_01C01E6E.1B1264C0-- From owner-mpls@UU.NET Thu Sep 14 11:58:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17775 for ; Thu, 14 Sep 2000 11:58:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgpz16760; Thu, 14 Sep 2000 15:58:21 GMT Received: by mail-control.mail.uu.net id QQjgpz22941 for mpls-outgoing; Thu, 14 Sep 2000 15:58:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgpz22936 for ; Thu, 14 Sep 2000 15:58:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgpz11641 for ; Thu, 14 Sep 2000 11:57:48 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgpz13903 for ; Thu, 14 Sep 2000 15:57:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA14220 for mpls@uu.net; Thu, 14 Sep 2000 11:57:47 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgpz22877 for ; Thu, 14 Sep 2000 15:57:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgpz12174 for ; Thu, 14 Sep 2000 11:57:01 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [216.241.231.251]) id QQjgpz15584 for ; Thu, 14 Sep 2000 15:56:46 GMT Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 09:00:33 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E57@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Robben Paul'" , mpls@UU.NET Subject: RE: question: DiffServ versus RSVP Date: Thu, 14 Sep 2000 09:00:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01E64.E96F0E4A" 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_01C01E64.E96F0E4A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Your confusion comes from the fact that RSVP is only used for Intserv = and not MPLS. But RSVP-TE can support: =20 1) MPLS signaling (for label distribution) 2) Intserv or Diffserv signaling (for indicating the CoS, BW, ...) =20 When somebody says that Diffserv eliminates RSVP, you should probably interpret it as Diffserv eliminates RSVP use as Intserv signaling. =20 The other point is that Diffserv and RSVP-TE operate on completely = different dimensions (not different scale). RSVP-TE is used to setup the LSPs and signal the QoS requirement, while Diffserv is the scheduling mechanism implemented in an LSR.=20 =20 Regards, -Shahram -----Original Message----- From: Robben Paul [mailto:paul.robben@worldonline.be] Sent: Thursday, September 14, 2000 11:06 AM To: mpls@UU.NET Subject: question: DiffServ versus RSVP Hi, =20 I'm currently making a thesis regarding IP-based VPN's, paying special attention to traffic engineering and QoS. Something isn't clear to me. I read a couple of articles regarding the = use of explicit routes with CR-LDP and the extended RSVP. Apparently, some companies prefer the former, others the latter, but = there doesn't seem to be an official statement yet of which one's the best. = But however, RSVP still is a "hot topic". On the other hand, I also read some articles about DiffServ, = mentionning that DiffServ evolved from Intserv, which is based on RSVP, and that, = within some time, DiffServ will eliminate the need to use RSVP in WAN area's.=20 =20 I think I must be missing something here... 1. Some time ago, a reader from the MPLS-list described DiffServ as a traffic light with reserved lanes for taxi's and busses. Its job is to = help prioritize things once congestion starts, and to penalize some flows to allow others to get less delay or loss. So, I guess DiffServ doesn't = operate on the level of 1 LSP, but on a whole bunch of them? 2. On the other hand, the extended RSVP is a way to set up explicit = routes. So RSVP is important for each LSP separately? =20 So, I don't really understand how DiffServ could eliminate the use of RSVP??? It seems to me that, although they both serve QoS, they are = working on a complete different scale... =20 Can anybody make me see the light in the darkness? :) Thanks in advance, =20 Fran=E7oise Beckers (Global One) ------_=_NextPart_001_01C01E64.E96F0E4A Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by wodc7mr1.ffx.ops.us.uu.net id QQjgpz16760 Content-Transfer-Encoding: quoted-printable
Hi,
 
Your=20 confusion comes from the fact that RSVP is only used for Intserv and not = MPLS.=20 But RSVP-TE can support:
 
1)=20 MPLS signaling (for label distribution)
2)=20 Intserv or Diffserv signaling (for indicating the CoS, BW,=20 ...)
 
When=20 somebody says that Diffserv eliminates RSVP, you should probably interpre= t it as=20 Diffserv eliminates RSVP use as Intserv signaling.
 
The=20 other point is that Diffserv and RSVP-TE operate on completely diffe= rent=20 dimensions (not different scale). RSVP-TE is used to setup the LSPs = and=20 signal the QoS requirement, while Diffserv is the scheduling mechanism=20 implemented in an LSR.
 
Regards,
-Shahram
-----Original Message-----
From: Robben Paul=20 [mailto:paul.robben@worldonline.be]
Sent: Thursday, September= 14,=20 2000 11:06 AM
To: mpls@UU.NET
Subject: question: Di= ffServ=20 versus RSVP

Hi,
 
I'm currently making a thesis regardin= g IP-based=20 VPN's, paying special attention to traffic engineering and QoS.<= /DIV>
Something isn't clear to me. I read a = couple of=20 articles regarding the use of explicit routes with CR-LDP and the exten= ded=20 RSVP.
Apparently, some companies prefer the = former,=20 others the latter, but there doesn't seem to be an official statem= ent yet=20 of which one's the best. But however, RSVP still is a "hot=20 topic".
On the other hand, I also read some ar= ticles=20 about DiffServ, mentionning that DiffServ evolved from Intserv, which i= s based=20 on RSVP, and that, within some time, DiffServ will eliminate the need t= o use=20 RSVP in WAN area's.
 
I think I must be missing something=20 here...
1. Some time ago, a reader from the MP= LS-list=20 described DiffServ as a traffic light with reserved lanes for taxi's an= d=20 busses. Its job is to help prioritize things once congestion starts, an= d to=20 penalize some flows to allow others to get less delay or loss. So, I gu= ess=20 DiffServ doesn't operate on the level of 1 LSP, but on a whole bunch of= =20 them?
2. On the other hand, the extended RSV= P is a way=20 to set up explicit routes. So RSVP is important for each LSP=20 separately?
 
So, I don't really understand how Diff= Serv could=20 eliminate the use of RSVP??? It seems to me that, although they both se= rve=20 QoS, they are working on a complete different scale...
 
Can anybody make me see the light in t= he=20 darkness?
:)
Thanks in advance,
 
Fran=E7oise Beckers
(Global=20 One)
------_=_NextPart_001_01C01E64.E96F0E4A-- From owner-mpls@UU.NET Thu Sep 14 12:01:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17881 for ; Thu, 14 Sep 2000 12:01:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgqa19071; Thu, 14 Sep 2000 16:01:17 GMT Received: by mail-control.mail.uu.net id QQjgqa25692 for mpls-outgoing; Thu, 14 Sep 2000 16:00:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgqa25413 for ; Thu, 14 Sep 2000 16:00:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgqa12711 for ; Thu, 14 Sep 2000 12:00:26 -0400 (EDT) Received: from cod.ece.ucdavis.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cod.ece.ucdavis.edu [169.237.32.89]) id QQjgpz17970 for ; Thu, 14 Sep 2000 15:59:55 GMT Received: from localhost (wswen@localhost) by cod.ece.ucdavis.edu (8.8.7/8.8.7) with ESMTP id IAA05300; Thu, 14 Sep 2000 08:58:54 -0700 (PDT) Date: Thu, 14 Sep 2000 08:58:54 -0700 (PDT) From: Wushao Wen To: Robben Paul cc: mpls@UU.NET Subject: Re: question: DiffServ versus RSVP In-Reply-To: <000a01c01e5d$59d384c0$8c33e9d4@c1p9a6> Message-ID: 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 MAA17881 Hi, In fact the importance difference between the Differential Service with Integrated Service is that the Differential Service is a Per-Hop basis QoS mechanism where the Integrated Service is a end-to-end QoS mechanism. RSVP is used as a resource reservation protocol for the integrated service. In MPLS, there is some extension for the function of RSVP, but it is still limited as a signalling protocol only. DiffSer don't need the RSVP at all. Hope this can be helpful. Wushao On Thu, 14 Sep 2000, Robben Paul wrote: > Hi, > > I'm currently making a thesis regarding IP-based VPN's, paying special attention to traffic engineering and QoS. > Something isn't clear to me. I read a couple of articles regarding the use of explicit routes with CR-LDP and the extended RSVP. > Apparently, some companies prefer the former, others the latter, but there doesn't seem to be an official statement yet of which one's the best. But however, RSVP still is a "hot topic". > On the other hand, I also read some articles about DiffServ, mentionning that DiffServ evolved from Intserv, which is based on RSVP, and that, within some time, DiffServ will eliminate the need to use RSVP in WAN area's. > > I think I must be missing something here... > 1. Some time ago, a reader from the MPLS-list described DiffServ as a traffic light with reserved lanes for taxi's and busses. Its job is to help prioritize things once congestion starts, and to penalize some flows to allow others to get less delay or loss. So, I guess DiffServ doesn't operate on the level of 1 LSP, but on a whole bunch of them? > 2. On the other hand, the extended RSVP is a way to set up explicit routes. So RSVP is important for each LSP separately? > > So, I don't really understand how DiffServ could eliminate the use of RSVP??? It seems to me that, although they both serve QoS, they are working on a complete different scale... > > Can anybody make me see the light in the darkness? > :) > Thanks in advance, > > Françoise Beckers > (Global One) > From owner-mpls@UU.NET Thu Sep 14 12:08:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18000 for ; Thu, 14 Sep 2000 12:08:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgqa21167; Thu, 14 Sep 2000 16:08:29 GMT Received: by mail-control.mail.uu.net id QQjgqa05505 for mpls-outgoing; Thu, 14 Sep 2000 16:07:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgqa05355 for ; Thu, 14 Sep 2000 16:07:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgqa13577 for ; Thu, 14 Sep 2000 12:07:19 -0400 (EDT) Received: from mail-gw4.njit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-gw4.njit.edu [128.235.251.32]) id QQjgqa23110 for ; Thu, 14 Sep 2000 16:07:18 GMT Received: from lycia.njit.edu (lycia.njit.edu [128.235.205.120]) by mail-gw4.njit.edu (8.10.0/8.10.0) with ESMTP id e8EG7GJ26701; Thu, 14 Sep 2000 12:07:17 -0400 Received: (from jxy9918@localhost) by lycia.njit.edu (8.8.8+Sun/8.8.5) id MAA14112; Thu, 14 Sep 2000 12:07:15 -0400 (EDT) Date: Thu, 14 Sep 2000 12:07:15 -0400 (EDT) From: jie yang ee stnt Message-Id: <200009141607.MAA14112@lycia.njit.edu> To: wswen@ece.ucdavis.edu Subject: Re: question: DiffServ versus RSVP Cc: mpls@UU.NET X-Sun-Charset: ISO-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk I agree with RSVP is a signaling protocol, But I can't agree that Diffserv doesn't need RSVP. Actually at edge router, it absolutely needs a signaling protocol. RSVP maybe a good choice. ----- Begin Included Message ----- From owner-mpls@UU.NET Thu Sep 14 12:02 EDT 2000 To: Robben Paul cc: mpls@UU.NET Subject: Re: question: DiffServ versus RSVP MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oak.njit.edu id MAA18798 Hi, In fact the importance difference between the Differential Service with Integrated Service is that the Differential Service is a Per-Hop basis QoS mechanism where the Integrated Service is a end-to-end QoS mechanism. RSVP is used as a resource reservation protocol for the integrated service. In MPLS, there is some extension for the function of RSVP, but it is still limited as a signalling protocol only. DiffSer don't need the RSVP at all. Hope this can be helpful. Wushao On Thu, 14 Sep 2000, Robben Paul wrote: > Hi, > > I'm currently making a thesis regarding IP-based VPN's, paying special attention to traffic engineering and QoS. > Something isn't clear to me. I read a couple of articles regarding the use of explicit routes with CR-LDP and the extended RSVP. > Apparently, some companies prefer the former, others the latter, but there doesn't seem to be an official statement yet of which one's the best. But however, RSVP still is a "hot topic". > On the other hand, I also read some articles about DiffServ, mentionning that DiffServ evolved from Intserv, which is based on RSVP, and that, within some time, DiffServ will eliminate the need to use RSVP in WAN area's. > > I think I must be missing something here... > 1. Some time ago, a reader from the MPLS-list described DiffServ as a traffic light with reserved lanes for taxi's and busses. Its job is to help prioritize things once congestion starts, and to penalize some flows to allow others to get less delay or loss. So, I guess DiffServ doesn't operate on the level of 1 LSP, but on a whole bunch of them? > 2. On the other hand, the extended RSVP is a way to set up explicit routes. So RSVP is important for each LSP separately? > > So, I don't really understand how DiffServ could eliminate the use of RSVP??? It seems to me that, although they both serve QoS, they are working on a complete different scale... > > Can anybody make me see the light in the darkness? > :) > Thanks in advance, > > Françoise Beckers > (Global One) > ----- End Included Message ----- From owner-mpls@UU.NET Thu Sep 14 15:24:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22872 for ; Thu, 14 Sep 2000 15:24:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgqn16127; Thu, 14 Sep 2000 19:23:50 GMT Received: by mail-control.mail.uu.net id QQjgqn27833 for mpls-outgoing; Thu, 14 Sep 2000 19:23:22 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgqn27828 for ; Thu, 14 Sep 2000 19:23:21 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgqn15197 for ; Thu, 14 Sep 2000 15:23:04 -0400 (EDT) Received: from garcia.ME.Berkeley.EDU by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: garcia.ME.Berkeley.EDU [128.32.126.64]) id QQjgqn15215 for ; Thu, 14 Sep 2000 19:22:33 GMT Received: from garcia.ME.Berkeley.EDU (garcia.ME.Berkeley.EDU [128.32.126.64]) by garcia.ME.Berkeley.EDU (8.9.1b+Sun/8.9.1) with ESMTP id MAA07557; Thu, 14 Sep 2000 12:18:07 -0700 (PDT) Date: Thu, 14 Sep 2000 12:18:07 -0700 (PDT) From: Youhao Jing To: jie yang ee stnt cc: wswen@ece.ucdavis.edu, mpls@UU.NET Subject: Re: question: DiffServ versus RSVP In-Reply-To: <200009141607.MAA14112@lycia.njit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk >On Thu, 14 Sep 2000, jie yang ee stnt wrote: > > > I agree with RSVP is a signaling protocol, But I can't agree that > Diffserv doesn't need RSVP. Actually at edge router, it absolutely needs > a signaling protocol. RSVP maybe a good choice. DiffServ is intented to provide edge-to-edge QoS, not end-to-end as RSVP does. There has been discussions on integrating RSVP and DiffServ/MPLS to achieve end-to-end QoS, either through new extensions or other external elements and mechanisms. Here are the pointers: http://www.ietf.org/proceedings/98aug/slides/rsvp-bernet-slides-98aug/ QoS protocols and architecture, white paper at http://www.qosforum.com/ tech_resources.htm -Youhao > ----- Begin Included Message ----- > From owner-mpls@UU.NET Thu Sep 14 15:28:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22912 for ; Thu, 14 Sep 2000 15:28:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgqn19072; Thu, 14 Sep 2000 19:27:43 GMT Received: by mail-control.mail.uu.net id QQjgqn28114 for mpls-outgoing; Thu, 14 Sep 2000 19:27:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgqn28109 for ; Thu, 14 Sep 2000 19:27:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgqn18069 for ; Thu, 14 Sep 2000 15:27:02 -0400 (EDT) Received: from prue.eim.surrey.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQjgqn18303 for ; Thu, 14 Sep 2000 19:26:47 GMT Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13ZeeQ-0001l0-00; Thu, 14 Sep 2000 20:26:26 +0100 Date: Thu, 14 Sep 2000 20:26:22 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Youhao Jing cc: jie yang ee stnt , wswen@ece.ucdavis.edu, mpls@UU.NET Subject: Re: question: DiffServ versus RSVP In-Reply-To: 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 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 14 Sep 2000, Youhao Jing wrote: > >On Thu, 14 Sep 2000, jie yang ee stnt wrote: > > > > I agree with RSVP is a signaling protocol, But I can't agree that > > Diffserv doesn't need RSVP. Actually at edge router, it absolutely needs > > a signaling protocol. RSVP maybe a good choice. > > DiffServ is intented to provide edge-to-edge QoS, not end-to-end as RSVP > does. RSVP does not provide end-to-end QoS. It's a signalling protocol, not an enabling mechanism. L. PGP From owner-mpls@UU.NET Thu Sep 14 15:49:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23151 for ; Thu, 14 Sep 2000 15:49:52 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgqp11237; Thu, 14 Sep 2000 19:49:31 GMT Received: by mail-control.mail.uu.net id QQjgqp29729 for mpls-outgoing; Thu, 14 Sep 2000 19:48:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgqp29724 for ; Thu, 14 Sep 2000 19:48:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgqp22036 for ; Thu, 14 Sep 2000 15:48:35 -0400 (EDT) Received: from garcia.ME.Berkeley.EDU by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: garcia.ME.Berkeley.EDU [128.32.126.64]) id QQjgqp10243 for ; Thu, 14 Sep 2000 19:48:05 GMT Received: from garcia.ME.Berkeley.EDU (garcia.ME.Berkeley.EDU [128.32.126.64]) by garcia.ME.Berkeley.EDU (8.9.1b+Sun/8.9.1) with ESMTP id MAA07629; Thu, 14 Sep 2000 12:43:38 -0700 (PDT) Date: Thu, 14 Sep 2000 12:43:38 -0700 (PDT) From: Youhao Jing To: Lloyd Wood cc: jie yang ee stnt , wswen@ece.ucdavis.edu, mpls@UU.NET Subject: Re: question: DiffServ versus RSVP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 14 Sep 2000, Lloyd Wood wrote: > On Thu, 14 Sep 2000, Youhao Jing wrote: > > > >On Thu, 14 Sep 2000, jie yang ee stnt wrote: > > > > > > I agree with RSVP is a signaling protocol, But I can't agree that > > > Diffserv doesn't need RSVP. Actually at edge router, it absolutely needs > > > a signaling protocol. RSVP maybe a good choice. > > > > DiffServ is intented to provide edge-to-edge QoS, not end-to-end as RSVP > > does. > > RSVP does not provide end-to-end QoS. It's a signalling protocol, not > an enabling mechanism. Agreed. What I meant was RSVP/IntServ. -Youhao > > L. > > PGP > > From owner-mpls@UU.NET Thu Sep 14 17:01:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23991 for ; Thu, 14 Sep 2000 17:01:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgqu28648; Thu, 14 Sep 2000 21:00:36 GMT Received: by mail-control.mail.uu.net id QQjgqu18583 for mpls-outgoing; Thu, 14 Sep 2000 21:00:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgqu18318 for ; Thu, 14 Sep 2000 21:00:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgqu02666 for ; Thu, 14 Sep 2000 17:00:08 -0400 (EDT) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjgqt07054 for ; Thu, 14 Sep 2000 20:59:53 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 13:59:02 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D9540@exchsrv1.cosinecom.com> From: Jay Wang To: "'Youhao Jing'" , Lloyd Wood Cc: jie yang ee stnt , wswen@ece.ucdavis.edu, mpls@UU.NET Subject: RE: question: DiffServ versus RSVP Date: Thu, 14 Sep 2000 13:59:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01E8E.9B8B2270" 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_01C01E8E.9B8B2270 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Youhao Jing [mailto:yjing@garcia.ME.Berkeley.EDU] > Sent: Thursday, September 14, 2000 12:44 PM > To: Lloyd Wood > Cc: jie yang ee stnt; wswen@ece.ucdavis.edu; mpls@UU.NET > Subject: Re: question: DiffServ versus RSVP > > > On Thu, 14 Sep 2000, Lloyd Wood wrote: > > > On Thu, 14 Sep 2000, Youhao Jing wrote: > > > > > >On Thu, 14 Sep 2000, jie yang ee stnt wrote: > > > > > > > > I agree with RSVP is a signaling protocol, But I can't > agree that > > > > Diffserv doesn't need RSVP. Actually at edge router, it > absolutely needs > > > > a signaling protocol. RSVP maybe a good choice. > > > > > > DiffServ is intented to provide edge-to-edge QoS, not > end-to-end as RSVP > > > does. > > > > RSVP does not provide end-to-end QoS. It's a signalling > protocol, not > > an enabling mechanism. > > Agreed. What I meant was RSVP/IntServ. > > -Youhao > In any case, I don't think the comparison is meaningful. Diffserv and RSVP are apple and orange. - Jay > > > > L. > > > > > PGP > > > > > ------_=_NextPart_001_01C01E8E.9B8B2270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: question: DiffServ versus RSVP

> -----Original Message-----
> From: Youhao Jing [mailto:yjing@garcia.ME.Berk= eley.EDU]
> Sent: Thursday, September 14, 2000 12:44 = PM
> To: Lloyd Wood
> Cc: jie yang ee stnt; wswen@ece.ucdavis.edu; = mpls@UU.NET
> Subject: Re: question: DiffServ versus = RSVP
>
>
> On Thu, 14 Sep 2000, Lloyd Wood wrote:
>
> > On Thu, 14 Sep 2000, Youhao Jing = wrote:
> >
> > > >On Thu, 14 Sep 2000, jie yang ee = stnt wrote:
> > > >
> > > > I agree with RSVP is a signaling = protocol, But I can't
> agree that
> > > > Diffserv doesn't need RSVP. = Actually at edge router, it
> absolutely needs
> > > > a signaling protocol. RSVP maybe = a good choice.
> > >
> > > DiffServ is intented to provide = edge-to-edge QoS, not
> end-to-end as RSVP
> > > does.
> >
> > RSVP does not provide end-to-end QoS. It's = a signalling
> protocol, not
> > an enabling mechanism.
>
> Agreed. What I meant was RSVP/IntServ.
>
> -Youhao
>

In any case, I don't think the comparison is = meaningful.
Diffserv and RSVP are apple and orange.

- Jay

> >
> > L.
> >
> >
> <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> >
> >
>

------_=_NextPart_001_01C01E8E.9B8B2270-- From owner-mpls@UU.NET Thu Sep 14 18:03:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26540 for ; Thu, 14 Sep 2000 18:03:59 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgqy02680; Thu, 14 Sep 2000 22:03:23 GMT Received: by mail-control.mail.uu.net id QQjgqy12273 for mpls-outgoing; Thu, 14 Sep 2000 22:02:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgqy12160 for ; Thu, 14 Sep 2000 22:02:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgqy09630 for ; Thu, 14 Sep 2000 18:02:28 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjgqy05096 for ; Thu, 14 Sep 2000 22:02:12 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 SAA23331 for ; Thu, 14 Sep 2000 18:02:09 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA15561 for ; Thu, 14 Sep 2000 18:02:12 -0400 (EDT) Message-ID: <39C14B07.D3E64435@marconi.com> Date: Thu, 14 Sep 2000 18:02:47 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: question: DiffServ versus RSVP References: <64DC8FA90382D411BA060090277AEE41774E57@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > When somebody says that Diffserv eliminates RSVP, you should probably > interpret it as Diffserv eliminates RSVP use as Intserv signaling. I usually interpret it as a misunderstanding of what the two protocols are meant to provide. Diffserv allows traffic to be broken up into different classes of service - which are queued and prioritized separately. It does not, however, provide a mechanism to define (in each router) what specific QoS should be provided for each class. These can be ignored (making Diffserv merely a priority scheme), they can be hand-configured, they can be configured through network management, or they can be signalled. RSVP is one means by which these can be signalled. RSVP and Diffserv solve two different problems. There are situations where it makes sense to use one, or the other, or both. -- David From owner-mpls@UU.NET Thu Sep 14 20:57:05 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28078 for ; Thu, 14 Sep 2000 20:57:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgrj01564; Fri, 15 Sep 2000 00:56:46 GMT Received: by mail-control.mail.uu.net id QQjgrj26731 for mpls-outgoing; Fri, 15 Sep 2000 00:56:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgrj26724 for ; Fri, 15 Sep 2000 00:56:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgrj29099 for ; Thu, 14 Sep 2000 20:55:46 -0400 (EDT) Received: from garcia.ME.Berkeley.EDU by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: garcia.ME.Berkeley.EDU [128.32.126.64]) id QQjgrj08973 for ; Fri, 15 Sep 2000 00:55:41 GMT Received: from garcia.ME.Berkeley.EDU (garcia.ME.Berkeley.EDU [128.32.126.64]) by garcia.ME.Berkeley.EDU (8.9.1b+Sun/8.9.1) with ESMTP id RAA08478; Thu, 14 Sep 2000 17:51:04 -0700 (PDT) Date: Thu, 14 Sep 2000 17:51:04 -0700 (PDT) From: Youhao Jing To: Jay Wang cc: Lloyd Wood , jie yang ee stnt , wswen@ece.ucdavis.edu, mpls@UU.NET Subject: RE: question: DiffServ versus RSVP In-Reply-To: <7EB7C6B62C4FD41196A80090279A29112D9540@exchsrv1.cosinecom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk >On Thu, 14 Sep 2000, Jay Wang wrote: > > > > > -----Original Message----- > > From: Youhao Jing [mailto:yjing@garcia.ME.Berkeley.EDU] > > Sent: Thursday, September 14, 2000 12:44 PM > > To: Lloyd Wood > > Cc: jie yang ee stnt; wswen@ece.ucdavis.edu; mpls@UU.NET > > Subject: Re: question: DiffServ versus RSVP > > > > > > On Thu, 14 Sep 2000, Lloyd Wood wrote: > > > > > On Thu, 14 Sep 2000, Youhao Jing wrote: > > > > > > > >On Thu, 14 Sep 2000, jie yang ee stnt wrote: > > > > > > > > > > I agree with RSVP is a signaling protocol, But I can't > > agree that > > > > > Diffserv doesn't need RSVP. Actually at edge router, it > > absolutely needs > > > > > a signaling protocol. RSVP maybe a good choice. > > > > > > > > DiffServ is intented to provide edge-to-edge QoS, not > > end-to-end as RSVP > > > > does. > > > > > > RSVP does not provide end-to-end QoS. It's a signalling > > protocol, not > > > an enabling mechanism. > > > > Agreed. What I meant was RSVP/IntServ. > > > > -Youhao > > > > In any case, I don't think the comparison is meaningful. > Diffserv and RSVP are apple and orange. Jay, please see the full version of my original response. The message I wanted to convey is both DiffServ and RSVP/IntServ have their limitations, and there has been work going on trying to integrate them to get end-to-end QoS. -Youhao > > - Jay > > > > > > > L. > > > > > > > > PGP > > > > > > > > > From owner-mpls@UU.NET Thu Sep 14 21:20:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28296 for ; Thu, 14 Sep 2000 21:20:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgrl21794; Fri, 15 Sep 2000 01:19:48 GMT Received: by mail-control.mail.uu.net id QQjgrl10815 for mpls-outgoing; Fri, 15 Sep 2000 01:19:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgrl10806 for ; Fri, 15 Sep 2000 01:19:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgrl25609 for ; Thu, 14 Sep 2000 21:18:57 -0400 (EDT) Received: from mail-gw4.njit.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-gw4.njit.edu [128.235.251.32]) id QQjgrl09194 for ; Fri, 15 Sep 2000 01:18:26 GMT Received: from lycia.njit.edu (lycia.njit.edu [128.235.205.120]) by mail-gw4.njit.edu (8.10.0/8.10.0) with ESMTP id e8F1IOJ03189; Thu, 14 Sep 2000 21:18:24 -0400 Received: (from jxy9918@localhost) by lycia.njit.edu (8.8.8+Sun/8.8.5) id VAA15459; Thu, 14 Sep 2000 21:18:21 -0400 (EDT) Date: Thu, 14 Sep 2000 21:18:21 -0400 (EDT) From: jie yang ee stnt Message-Id: <200009150118.VAA15459@lycia.njit.edu> To: david.charlap@marconi.com Subject: Re: question: DiffServ versus RSVP Cc: mpls@UU.NET X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk David, your comments do make sense. But, do you mean,the only point in common for different diffserv providers is that they merge flows into different classes? how they merge flows, what kind of QoS they can provide on each class may be quite different from provider to provider. Right? I am doubting whether diffserv could offer QoS that meets various end-to-end requirements. I was thinking the possibility that at edge router we apply Interserv mechanisms which is based on flow and at core router we use diffserv which is based on class. I doubt, since diffserv is a kind of coarse grain flow management, it is not easy to guarantee per-flow QoS as many applications require, if not impossible. Jie ----- Begin Included Message ----- From owner-mpls@UU.NET Thu Sep 14 18:04 EDT 2000 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: question: DiffServ versus RSVP Content-Transfer-Encoding: 7bit Diffserv allows traffic to be broken up into different classes of service - which are queued and prioritized separately. It does not, however, provide a mechanism to define (in each router) what specific QoS should be provided for each class. These can be ignored (making Diffserv merely a priority scheme), they can be hand-configured, they can be configured through network management, or they can be signalled. RSVP is one means by which these can be signalled. RSVP and Diffserv solve two different problems. There are situations where it makes sense to use one, or the other, or both. -- David From owner-mpls@UU.NET Thu Sep 14 21:35:29 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29456 for ; Thu, 14 Sep 2000 21:35:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgrm00075; Fri, 15 Sep 2000 01:35:09 GMT Received: by mail-control.mail.uu.net id QQjgrm12204 for mpls-outgoing; Fri, 15 Sep 2000 01:34:39 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgrm12183 for ; Fri, 15 Sep 2000 01:34:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgrm26722 for ; Thu, 14 Sep 2000 21:33:59 -0400 (EDT) Received: from exchsrv1.cosinecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjgrm29171 for ; Fri, 15 Sep 2000 01:33:28 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 18:32:38 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D9545@exchsrv1.cosinecom.com> From: Jay Wang To: "'Youhao Jing'" Cc: Lloyd Wood , jie yang ee stnt , wswen@ece.ucdavis.edu, mpls@UU.NET Subject: RE: question: DiffServ versus RSVP Date: Thu, 14 Sep 2000 18:32:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01EB4.D455C030" 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_01C01EB4.D455C030 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Youhao Jing [mailto:yjing@garcia.ME.Berkeley.EDU] > Sent: Thursday, September 14, 2000 5:51 PM > To: Jay Wang > Cc: Lloyd Wood; jie yang ee stnt; wswen@ece.ucdavis.edu; mpls@UU.NET > Subject: RE: question: DiffServ versus RSVP > > > >On Thu, 14 Sep 2000, Jay Wang wrote: > > > > > > > > > -----Original Message----- > > > From: Youhao Jing [mailto:yjing@garcia.ME.Berkeley.EDU] > > > Sent: Thursday, September 14, 2000 12:44 PM > > > To: Lloyd Wood > > > Cc: jie yang ee stnt; wswen@ece.ucdavis.edu; mpls@UU.NET > > > Subject: Re: question: DiffServ versus RSVP > > > > > > > > > On Thu, 14 Sep 2000, Lloyd Wood wrote: > > > > > > > On Thu, 14 Sep 2000, Youhao Jing wrote: > > > > > > > > > >On Thu, 14 Sep 2000, jie yang ee stnt wrote: > > > > > > > > > > > > I agree with RSVP is a signaling protocol, But I can't > > > agree that > > > > > > Diffserv doesn't need RSVP. Actually at edge router, it > > > absolutely needs > > > > > > a signaling protocol. RSVP maybe a good choice. > > > > > > > > > > DiffServ is intented to provide edge-to-edge QoS, not > > > end-to-end as RSVP > > > > > does. > > > > > > > > RSVP does not provide end-to-end QoS. It's a signalling > > > protocol, not > > > > an enabling mechanism. > > > > > > Agreed. What I meant was RSVP/IntServ. > > > > > > -Youhao > > > > > > > In any case, I don't think the comparison is meaningful. > > Diffserv and RSVP are apple and orange. > > Jay, please see the full version of my original response. The > message I wanted to convey is both DiffServ and RSVP/IntServ > have their limitations, and there has been work going on trying > to integrate them to get end-to-end QoS. > > -Youhao > Youhao, I did not feel the exchanges were fruitful because for one thing, I don't think this end-to-end vs. edge-to-edge argument makes much sense. There is nothing, IMHO, in Diffserv architecture that prevents us from having a DS domain that covers "end-to-end". Can a CPE, connected to an "edge" through a point-to-point or switched technologies, adopt a network processor that is DS enabled, absolutely yes. On top of that, Diffserv was created to get Intserv-like effect without per-flow (hence very stateful) signaling. It is done, instead, by way of an aggregated, and per-hop, manner. That is why someone else had pointed out that the spirit of Diffserv is to alleviate the burden of flow-based signaling using things like RSVP, but this does not means that Diffserv can not work with RSVP. RSVP is a more of a choice of convenience than necessity (particularly when it comes to a bandwidth-ridden MPLS-LSP setup). In other words, it is MPLS-LSP setup which needs RSVP (or the like) signaling support. To get the desired QoS for the LSP does not necessarily have to. cheers, - Jay > > > > - Jay > > > > > > > > > > L. > > > > > > > > > > > > PGP > > > > > > > > > > > > > > ------_=_NextPart_001_01C01EB4.D455C030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: question: DiffServ versus RSVP

> -----Original Message-----
> From: Youhao Jing [mailto:yjing@garcia.ME.Berk= eley.EDU]
> Sent: Thursday, September 14, 2000 5:51 = PM
> To: Jay Wang
> Cc: Lloyd Wood; jie yang ee stnt; = wswen@ece.ucdavis.edu; mpls@UU.NET
> Subject: RE: question: DiffServ versus = RSVP
>
>
> >On Thu, 14 Sep 2000, Jay Wang wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Youhao Jing [mailto:yjing@garcia.ME.Berk= eley.EDU]
> > > Sent: Thursday, September 14, 2000 = 12:44 PM
> > > To: Lloyd Wood
> > > Cc: jie yang ee stnt; = wswen@ece.ucdavis.edu; mpls@UU.NET
> > > Subject: Re: question: DiffServ = versus RSVP
> > >
> > >
> > > On Thu, 14 Sep 2000, Lloyd Wood = wrote:
> > >
> > > > On Thu, 14 Sep 2000, Youhao Jing = wrote:
> > > >
> > > > > >On Thu, 14 Sep 2000, = jie yang ee stnt wrote:
> > > > > >
> > > > > > I agree with RSVP is a = signaling protocol, But I can't
> > > agree that
> > > > > > Diffserv doesn't need = RSVP. Actually at edge router, it
> > > absolutely needs
> > > > > > a signaling protocol. = RSVP maybe a good choice.
> > > > >
> > > > > DiffServ is intented to = provide edge-to-edge QoS, not
> > > end-to-end as RSVP
> > > > > does.
> > > >
> > > > RSVP does not provide end-to-end = QoS. It's a signalling
> > > protocol, not
> > > > an enabling mechanism.
> > >
> > > Agreed. What I meant was = RSVP/IntServ.
> > >
> > > -Youhao
> > >
> >
> > In any case, I don't think the comparison = is meaningful.
> > Diffserv and RSVP are apple and = orange.
>
> Jay, please see the full version of my original = response. The
> message I wanted to convey is both DiffServ and = RSVP/IntServ
> have their limitations, and there has been work = going on trying
> to integrate them to get end-to-end QoS. =
>
> -Youhao
>

Youhao, I did not feel the exchanges were fruitful = because
for one thing, I don't think this end-to-end vs. = edge-to-edge
argument makes much sense. There is nothing, IMHO, = in Diffserv
architecture that prevents us from having a DS = domain that covers
"end-to-end". Can a CPE, connected to an = "edge" through a
point-to-point or switched technologies, adopt a = network processor
that is DS enabled, absolutely yes.

On top of that, Diffserv was created to get = Intserv-like effect
without per-flow (hence very stateful) signaling. It = is done, instead,
by way of an aggregated, and per-hop, manner.  = That is why someone
else had pointed out that the spirit of Diffserv is = to alleviate the
burden of flow-based signaling using things like = RSVP, but this does
not means that Diffserv can not work with RSVP. RSVP = is a more of a
choice of convenience than necessity (particularly = when it comes to a
bandwidth-ridden MPLS-LSP setup). In other words, it = is MPLS-LSP setup
which needs RSVP (or the like) signaling support. To = get the desired
QoS for the LSP does not necessarily have to. =

cheers,

- Jay
 

> >
> > - Jay
> >
> > > >
> > > > L.
> > > >
> > > >
> > >
> <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> > > >
> > > >
> > >
> >
>

------_=_NextPart_001_01C01EB4.D455C030-- From owner-mpls@UU.NET Fri Sep 15 08:32:52 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18620 for ; Fri, 15 Sep 2000 08:32:52 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgte16467; Fri, 15 Sep 2000 12:32:13 GMT Received: by mail-control.mail.uu.net id QQjgte23072 for mpls-outgoing; Fri, 15 Sep 2000 12:31:56 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgte23058 for ; Fri, 15 Sep 2000 12:31:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgte17769 for ; Fri, 15 Sep 2000 08:31:31 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjgte16028 for ; Fri, 15 Sep 2000 12:31:15 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 IAA19753 for ; Fri, 15 Sep 2000 08:31:13 -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 IAA21572 for ; Fri, 15 Sep 2000 08:31:15 -0400 (EDT) Message-ID: <39C216B8.EFB336B9@marconi.com> Date: Fri, 15 Sep 2000 08:31:52 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: question: DiffServ versus RSVP References: <200009150118.VAA15459@lycia.njit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jie yang ee stnt wrote: > > But, do you mean,the only point in common for different diffserv > providers is that they merge flows into different classes? how they > merge flows, what kind of QoS they can provide on each class may be > quite different from provider to provider. > Right? Correct. If two providers choose to use different QoS levels for different DiffServ classes, then (hopefully), they should change the DiffServ values as packets cross from one administrative domain to another. If they don't, then the QoS values for the classes will change over the path of the packet. > I am doubting whether diffserv could offer QoS that meets various > end-to-end requirements. It doesn't. And it isn't meant to. > I was thinking the possibility that at edge router we apply Interserv > mechanisms which is based on flow and at core router we use diffserv > which is based on class. I doubt, since diffserv is a kind of coarse > grain flow management, it is not easy to guarantee per-flow QoS as > many applications require, if not impossible. If you need end-to-end per-flow reservations, then you need something bigger than DiffServ. MPLS is one possibility. Another is IP over ATM or Frame Relay. Another is to use hop-by-hop routers that can make reservations. Setting up the QoS levels for such a network can be done through configuration, management, or signalling. -- David From owner-mpls@UU.NET Fri Sep 15 08:39:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18730 for ; Fri, 15 Sep 2000 08:39:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgte19358; Fri, 15 Sep 2000 12:39:20 GMT Received: by mail-control.mail.uu.net id QQjgte23623 for mpls-outgoing; Fri, 15 Sep 2000 12:38:55 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgte23613 for ; Fri, 15 Sep 2000 12:38:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgte11170 for ; Fri, 15 Sep 2000 08:38:39 -0400 (EDT) Received: from prue.eim.surrey.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQjgte01475 for ; Fri, 15 Sep 2000 12:38:38 GMT Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Zul7-0003u8-00; Fri, 15 Sep 2000 13:38:25 +0100 Date: Fri, 15 Sep 2000 13:38:22 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: David Charlap cc: mpls@UU.NET Subject: Re: question: DiffServ versus RSVP In-Reply-To: <39C216B8.EFB336B9@marconi.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 Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 15 Sep 2000, David Charlap wrote: > jie yang ee stnt wrote: > > > > But, do you mean,the only point in common for different diffserv > > providers is that they merge flows into different classes? how they > > merge flows, what kind of QoS they can provide on each class may be > > quite different from provider to provider. > > Right? > > Correct. > > If two providers choose to use different QoS levels for different > DiffServ classes, then (hopefully), they should change the DiffServ > values as packets cross from one administrative domain to another. > > If they don't, then the QoS values for the classes will change over the > path of the packet. If they do, the QoS values can still be altered as the mappings between different sets of classes defining different classes are imperfect, and downstream degradation results. > > I am doubting whether diffserv could offer QoS that meets various > > end-to-end requirements. > > It doesn't. And it isn't meant to. > > > I was thinking the possibility that at edge router we apply Interserv > > mechanisms which is based on flow and at core router we use diffserv > > which is based on class. I doubt, since diffserv is a kind of coarse > > grain flow management, it is not easy to guarantee per-flow QoS as > > many applications require, if not impossible. > > If you need end-to-end per-flow reservations, then you need something > bigger than DiffServ. you mean edge-to-edge there, surely? L. > MPLS is one possibility. Another is IP over ATM or Frame Relay. > Another is to use hop-by-hop routers that can make reservations. > > Setting up the QoS levels for such a network can be done through > configuration, management, or signalling. > > -- David PGP From owner-mpls@UU.NET Fri Sep 15 11:04:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20698 for ; Fri, 15 Sep 2000 11:04:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgto01982; Fri, 15 Sep 2000 15:03:44 GMT Received: by mail-control.mail.uu.net id QQjgto07103 for mpls-outgoing; Fri, 15 Sep 2000 15:03:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgto06776 for ; Fri, 15 Sep 2000 15:03:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgto07432 for ; Fri, 15 Sep 2000 11:03:03 -0400 (EDT) Received: from osf1.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQjgto10828 for ; Fri, 15 Sep 2000 15:02:48 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id LAA25514 for ; Fri, 15 Sep 2000 11:02:44 -0400 (EDT) Date: Fri, 15 Sep 2000 11:02:43 -0400 (EDT) From: Rajiv Papneja To: mpls@UU.NET Subject: MPLS2000 Registration - Deadline Extended Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Colleagues: We are pleased to inform you that, due to much appreciated sponsor support, we are able to extend the reduced registration fee date for MPLS2000 through 9/30/00. A number of rooms are still available at the Sheraton Premiere for the nights of October 22 and 23. Please contact them soon for reservations. MPLS 2000 is the 3rd Annual International Conference on MPLS, being held on the pastoral Fairfax, Virginia, campus of George Mason University October 22-24, 2000. The theme of this year's conference is "From MPLS to MPLambdaS." Conference information, detailed technical program, hotel and travel information, and registration information can be found at: http://www.gmu.edu/departments/ail/MPLS2000/ MPLS2000 is co-hosted by George Mason University and UUNET Technologies and is being sponsored by Cisco Systems, Nortel Networks, Juniper Networks, Make Systems, Ennovate Networks, Ixia, Spirent Communications, IronBridge Networks, Avici Systems, Agilent Technologies, Marconi Communications, Ericsson, Redback, Unisphere Solutions, Virginia's Center for Innovative Technology, and Vivace Networks. Sponsors will be exhibiting their products and services throughout the day Monday and Tuesday. If you have any further queries, you may contact Pam Jones (mailto:pjone3@gmu.edu) Advanced Internet Lab, 703-993-4700. We look forward to seeing you in October! Regards - Rajiv From owner-mpls@UU.NET Fri Sep 15 11:12:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20805 for ; Fri, 15 Sep 2000 11:12:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgto08262; Fri, 15 Sep 2000 15:12:28 GMT Received: by mail-control.mail.uu.net id QQjgto11498 for mpls-outgoing; Fri, 15 Sep 2000 15:11:58 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgto11360 for ; Fri, 15 Sep 2000 15:11:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgto00349 for ; Fri, 15 Sep 2000 11:11:38 -0400 (EDT) Received: from mail-gw4.njit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-gw4.njit.edu [128.235.251.32]) id QQjgto07684 for ; Fri, 15 Sep 2000 15:11:38 GMT Received: from lycia.njit.edu (lycia.njit.edu [128.235.205.120]) by mail-gw4.njit.edu (8.10.0/8.10.0) with ESMTP id e8FF4W519997; Fri, 15 Sep 2000 11:04:32 -0400 Received: (from jxy9918@localhost) by lycia.njit.edu (8.8.8+Sun/8.8.5) id LAA00806; Fri, 15 Sep 2000 11:04:30 -0400 (EDT) Date: Fri, 15 Sep 2000 11:04:30 -0400 (EDT) From: jie yang ee stnt Message-Id: <200009151504.LAA00806@lycia.njit.edu> To: mpls@UU.NET, david.charlap@marconi.com Subject: Re: question: DiffServ versus RSVP X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk >If two providers choose to use different QoS levels for different >DiffServ classes, then (hopefully), they should change the DiffServ >values as packets cross from one administrative domain to another. >>If they don't, then the QoS values for the classes will change over the >>path of the packet. > I am doubting whether diffserv could offer QoS that meets various > end-to-end requirements. >>It doesn't. And it isn't meant to. In my mind, diffserv was proposed because Interserv+RSVP was based on flow and is not scalable. In Diffserv since traffic is not based on flow but based on class, it is a more scalable traffic engineering mechanism. What else diffserv is meant to? > I was thinking the possibility that at edge router we apply Interserv > mechanisms which is based on flow and at core router we use diffserv > which is based on class. I doubt, since diffserv is a kind of coarse > grain flow management, it is not easy to guarantee per-flow QoS as > many applications require, if not impossible. what I envisioned here is, even if in core router we don't have per-flow management, by some other mechanisms, such as reservation, CAC, priority queueing, etc, we can offer same QoS via per-class management as via per-flow management when traffic comes out of the domain. it means, the internal forwarding mechanism is transparent from outside. it seems, with current track on diffserv, it will not work. >>If you need end-to-end per-flow reservations, then you need something >>bigger than DiffServ. agree. but this reservation should happen only at edge router of a domain to avoid scalability problem. >>MPLS is one possibility. Another is IP over ATM or Frame Relay. >>Another is to use hop-by-hop routers that can make reservations. MPLS is still based on flow. And, it is becoming more and more complex. The power of TCP/IP is its simplicity. That is why it overwhelms ATM. will MPLS repeat the failure of ATM ? >>Setting up the QoS levels for such a network can be done through >>configuration, management, or signalling. come back to diffserv, SLA+RSVP+bandwidth broker may offer some clue on how to make it. Do yo have any idea on it? thanks, Jie From owner-mpls@UU.NET Fri Sep 15 11:19:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20846 for ; Fri, 15 Sep 2000 11:19:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgtp18415; Fri, 15 Sep 2000 15:18:52 GMT Received: by mail-control.mail.uu.net id QQjgtp12193 for mpls-outgoing; Fri, 15 Sep 2000 15:18:19 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgtp12173 for ; Fri, 15 Sep 2000 15:18:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgtp01100 for ; Fri, 15 Sep 2000 11:16:05 -0400 (EDT) Received: from garcia.ME.Berkeley.EDU by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: garcia.ME.Berkeley.EDU [128.32.126.64]) id QQjgtp10613 for ; Fri, 15 Sep 2000 15:15:31 GMT Received: from garcia.ME.Berkeley.EDU (garcia.ME.Berkeley.EDU [128.32.126.64]) by garcia.ME.Berkeley.EDU (8.9.1b+Sun/8.9.1) with ESMTP id IAA09476; Fri, 15 Sep 2000 08:11:03 -0700 (PDT) Date: Fri, 15 Sep 2000 08:11:03 -0700 (PDT) From: Youhao Jing To: Jay Wang cc: mpls@UU.NET Subject: RE: question: DiffServ versus RSVP In-Reply-To: <7EB7C6B62C4FD41196A80090279A29112D9545@exchsrv1.cosinecom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk >On Thu, 14 Sep 2000, Jay Wang wrote: > > > Jay, please see the full version of my original response. The > > message I wanted to convey is both DiffServ and RSVP/IntServ > > have their limitations, and there has been work going on trying > > to integrate them to get end-to-end QoS. > > > > -Youhao > > > > Youhao, I did not feel the exchanges were fruitful because > for one thing, I don't think this end-to-end vs. edge-to-edge > argument makes much sense. There is nothing, IMHO, in Diffserv > architecture that prevents us from having a DS domain that covers > "end-to-end". Can a CPE, connected to an "edge" through a > point-to-point or switched technologies, adopt a network processor > that is DS enabled, absolutely yes. Just to make my point clear: DiffServ, by aggregating flows into classes and dealing them with PHBs, avoided IntServ/RSVP scaling problems, thus became attractive to service providers. By using a consistant queuing/dropping treatment for each aggregate from backbone network ingress edge where flow classification occurs to egress edge, DiffServ provide Class of Service at per-aggregate level. However, as a trade-off, it's my understanding that DiffServ lost or at least difficult in providing fine quality control between senders and receivers of each flows. That's what I meant by "end-to-end" QoS. > > On top of that, Diffserv was created to get Intserv-like effect > without per-flow (hence very stateful) signaling. It is done, instead, > by way of an aggregated, and per-hop, manner. That is why someone > else had pointed out that the spirit of Diffserv is to alleviate the > burden of flow-based signaling using things like RSVP, but this does > not means that Diffserv can not work with RSVP. Indeed, as I pointed out in my original email, people have been investigating the ways to make DiffServ works with RSVP to achieve end-to-end QoS. -Youhao > RSVP is a more of a > choice of convenience than necessity (particularly when it comes to a > bandwidth-ridden MPLS-LSP setup). In other words, it is MPLS-LSP setup > which needs RSVP (or the like) signaling support. To get the desired > QoS for the LSP does not necessarily have to. > > cheers, > > - Jay > > > > > > > > - Jay > > > > > > > > > > > > > L. > > > > > > > > > > > > > > > > PGP > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Sep 15 11:23:25 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20909 for ; Fri, 15 Sep 2000 11:23:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgtp20546; Fri, 15 Sep 2000 15:22:58 GMT Received: by mail-control.mail.uu.net id QQjgtp12522 for mpls-outgoing; Fri, 15 Sep 2000 15:22:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgtp12514 for ; Fri, 15 Sep 2000 15:22:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgtp02035 for ; Fri, 15 Sep 2000 11:22:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjgtp15266 for ; Fri, 15 Sep 2000 15:21:55 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 LAA17618 for ; Fri, 15 Sep 2000 11:21:49 -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 LAA00358 for ; Fri, 15 Sep 2000 11:21:51 -0400 (EDT) Message-ID: <39C23EB5.8C6F08B4@marconi.com> Date: Fri, 15 Sep 2000 11:22:29 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: question: DiffServ versus RSVP References: <200009151504.LAA00806@lycia.njit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jie yang ee stnt wrote: > > In my mind, diffserv was proposed because Interserv+RSVP was based on > flow and is not scalable. In Diffserv since traffic is not based on > flow but based on class, it is a more scalable traffic engineering > mechanism. What else diffserv is meant to? It does not work end-to-end. A host can not specify Diffserve classes in the packets it generates. Actually, it can, but as soon as it hits an ISP that is implementing DiffServ, these values will be discarded and replaced with values that the ISP is using. DiffServ is primarily being used to establish priorities within a network core. Not to provide a consistent end-to-end quality level. >> If you need end-to-end per-flow reservations, then you need >> something bigger than DiffServ. > > agree. but this reservation should happen only at edge router of a > domain to avoid scalability problem. You're answering a question that was not asked. The question I was responding to specifically asked about end-to-end per-flow reservations. -- David From owner-mpls@UU.NET Fri Sep 15 11:31:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21061 for ; Fri, 15 Sep 2000 11:31:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgtq24398; Fri, 15 Sep 2000 15:31:22 GMT Received: by mail-control.mail.uu.net id QQjgtq13299 for mpls-outgoing; Fri, 15 Sep 2000 15:30:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgtq13286 for ; Fri, 15 Sep 2000 15:30:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgtp02969 for ; Fri, 15 Sep 2000 11:27:49 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgtp22697 for ; Fri, 15 Sep 2000 15:27:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA15645 for mpls@uu.net; Fri, 15 Sep 2000 11:27:32 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgtp12955 for ; Fri, 15 Sep 2000 15:27:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgtp11656 for ; Fri, 15 Sep 2000 11:26:47 -0400 (EDT) Received: from sword.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQjgtp18738 for ; Fri, 15 Sep 2000 15:26:46 GMT Received: from ott-view3.cisco.com (ott-view3.cisco.com [161.44.208.198]) by sword.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA18005; Fri, 15 Sep 2000 11:26:33 -0400 (EDT) From: Erick Gonzalez Received: (erickg@localhost) by ott-view3.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id LAA09217; Fri, 15 Sep 2000 11:26:41 -0400 (EDT) Message-Id: <200009151526.LAA09217@ott-view3.cisco.com> Subject: Re: MPLS2000 Registration - Deadline Extended To: rpapneja@osf1.gmu.edu (Rajiv Papneja) Date: Fri, 15 Sep 2000 11:26:41 -0400 (EDT) Cc: mpls@UU.NET In-Reply-To: from "Rajiv Papneja" at Sep 15, 2000 11:02:43 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > Colleagues: > > We are pleased to inform you that, due to much appreciated sponsor > support, we are able to extend the reduced registration fee date for MPLS2000 > through 9/30/00. > > A number of rooms are still available at the Sheraton Premiere for > the nights of October 22 and 23. Please contact them soon for reservations. > not really .. I just called in and they said they were sold out... > MPLS 2000 is the 3rd Annual International Conference on MPLS, being held > on the pastoral Fairfax, Virginia, campus of George Mason University October > 22-24, 2000. The theme of this year's conference is "From MPLS to MPLambdaS." > Conference information, detailed technical program, hotel and travel > information, and registration information can be found at: > > http://www.gmu.edu/departments/ail/MPLS2000/ > > MPLS2000 is co-hosted by George Mason University and UUNET Technologies > and is being sponsored by Cisco Systems, Nortel Networks, Juniper > Networks, Make Systems, Ennovate Networks, Ixia, Spirent > Communications, IronBridge Networks, Avici Systems, Agilent Technologies, > Marconi Communications, Ericsson, Redback, Unisphere Solutions, Virginia's > Center for Innovative Technology, and Vivace Networks. Sponsors will be > exhibiting their products and services throughout the day Monday and > Tuesday. > > If you have any further queries, you may contact Pam Jones > (mailto:pjone3@gmu.edu) Advanced Internet Lab, 703-993-4700. > > We look forward to seeing you in October! > > Regards > - Rajiv > > > From owner-mpls@UU.NET Fri Sep 15 11:51:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21475 for ; Fri, 15 Sep 2000 11:51:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgtr02491; Fri, 15 Sep 2000 15:50:53 GMT Received: by mail-control.mail.uu.net id QQjgtr15087 for mpls-outgoing; Fri, 15 Sep 2000 15:50:28 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgtr15082 for ; Fri, 15 Sep 2000 15:50:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgtr06098 for ; Fri, 15 Sep 2000 11:50:12 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjgtr01876 for ; Fri, 15 Sep 2000 15:49:42 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA22451 for ; Fri, 15 Sep 2000 08:50:01 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA23567 for mpls@uu.net; Fri, 15 Sep 2000 11:49:40 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgrr01695 for ; Fri, 15 Sep 2000 02:54:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgrr07391; Thu, 14 Sep 2000 22:54:26 -0400 (EDT) Received: from WSUHUB.UC.TWSU.EDU by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: WSUHUB.UC.TWSU.EDU [156.26.1.1]) id QQjgrr12538; Fri, 15 Sep 2000 02:53:55 GMT Received: from WSUHUB.UC.TWSU.EDU by WSUHUB.UC.TWSU.EDU (PMDF V5.1-12 #D3148) id <01JU6FS7J9WG8WX6W7@WSUHUB.UC.TWSU.EDU>; Thu, 14 Sep 2000 21:57:26 CST Date: Thu, 14 Sep 2000 21:57:26 -0600 (CST) From: jamathew@WSUHUB.UC.TWSU.EDU Subject: Download NS-2 To: mpls@UU.NET, te-wg@UU.NET Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I wanted to get some information regarding the Network Simulator, and it's support for MPLS networks. How do i get a demo version of the Simulator, or is it possible to download a copy of the simulator. I am currently doing some research regarding MPLS networks, and it would be helpful to me to get some information regarding the Network Simulator. Jubil Alex Mathew 5400, 21st East Street, # 1005, Wichita, Kansas, 67208. Ph. No: (316)-689-8741 email: jubilm@hotmail.com jamathew@wsuhub.uc.twsu.edu From owner-mpls@UU.NET Fri Sep 15 11:58:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21540 for ; Fri, 15 Sep 2000 11:58:10 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgtr09099; Fri, 15 Sep 2000 15:57:16 GMT Received: by mail-control.mail.uu.net id QQjgtr15568 for mpls-outgoing; Fri, 15 Sep 2000 15:56:30 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgtr15554 for ; Fri, 15 Sep 2000 15:56:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgtr16211; Fri, 15 Sep 2000 11:56:22 -0400 (EDT) Received: from prue.eim.surrey.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQjgtr08281; Fri, 15 Sep 2000 15:56:07 GMT Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Zxq5-0006lG-00; Fri, 15 Sep 2000 16:55:45 +0100 Date: Fri, 15 Sep 2000 16:55:41 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: jamathew@WSUHUB.UC.TWSU.EDU cc: mpls@UU.NET, te-wg@UU.NET Subject: Re: Download NS-2 In-Reply-To: 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 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 14 Sep 2000 jamathew@WSUHUB.UC.TWSU.EDU wrote: > I wanted to get some information regarding the Network Simulator, and it's > support for MPLS networks. How do i get a demo version of the Simulator, There is no demo version. There is no commercial version either... > or is it possible to download a copy of the simulator. http://www.isi.edu/nsnam/ Snapshots of the simulator after 24 August 2000 now include Gaeil Ahn's MPLS simulation code, so you'll probably want to build ns from the daily snapshots of ns and tclcl rather than try adding third-party code to ns 2.1b6. L. PGP From owner-mpls@UU.NET Fri Sep 15 11:59:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21561 for ; Fri, 15 Sep 2000 11:59:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgtr06026; Fri, 15 Sep 2000 15:59:18 GMT Received: by mail-control.mail.uu.net id QQjgtr15763 for mpls-outgoing; Fri, 15 Sep 2000 15:58:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjgtr15700 for ; Fri, 15 Sep 2000 15:58:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgtr16496 for ; Fri, 15 Sep 2000 11:58:06 -0400 (EDT) Received: from mailer.syr.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailer.syr.edu [128.230.18.29]) id QQjgtr09477 for ; Fri, 15 Sep 2000 15:57:36 GMT Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.005E3696@mailer.syr.edu>; Fri, 15 Sep 2000 11:57:36 -0400 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id LAA29165; Fri, 15 Sep 2000 11:57:34 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Fri, 15 Sep 2000 11:57:34 -0400 (EDT) From: Ibrahim Okumus X-Sender: iokumus@rodan.syr.edu To: jamathew@WSUHUB.UC.TWSU.EDU cc: mpls@UU.NET Subject: Re: Download NS-2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk You can find useful information from the link below. http://www-mash.cs.berkeley.edu/ns/tutorial/index.html _______________________________ Ibrahim Taner OKUMUS Electrical&Computer Eng. Dept. Syracuse University Syracuse New York Homepage:http://web.syr.edu/~iokumus Home:1111 East Colvin St. Apt#2 Syracuse,NY,13210 Phone:(315) 4260806 _______________________________ On Thu, 14 Sep 2000 jamathew@WSUHUB.UC.TWSU.EDU wrote: > Hi, > > I wanted to get some information regarding the Network Simulator, and it's > support for MPLS networks. How do i get a demo version of the Simulator, > or is it possible to download a copy of the simulator. I am currently > doing some research regarding MPLS networks, and it would be helpful to me > to get some information regarding the Network Simulator. > > > > > Jubil Alex Mathew > 5400, 21st East Street, # 1005, > Wichita, Kansas, 67208. > Ph. No: (316)-689-8741 > email: jubilm@hotmail.com > jamathew@wsuhub.uc.twsu.edu > > > From owner-mpls@UU.NET Fri Sep 15 12:09:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21801 for ; Fri, 15 Sep 2000 12:09:11 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgts17116; Fri, 15 Sep 2000 16:08:24 GMT Received: by mail-control.mail.uu.net id QQjgts27817 for mpls-outgoing; Fri, 15 Sep 2000 16:07:34 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgts27808 for ; Fri, 15 Sep 2000 16:07:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgts08421 for ; Fri, 15 Sep 2000 12:07:25 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjgts16098 for ; Fri, 15 Sep 2000 16:07:09 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA04385 for ; Fri, 15 Sep 2000 09:07:08 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA23603 for mpls@uu.net; Fri, 15 Sep 2000 12:07:06 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgtr15967 for ; Fri, 15 Sep 2000 15:59:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgtr07329 for ; Fri, 15 Sep 2000 11:59:26 -0400 (EDT) Received: from ozias.inrs-telecom.uquebec.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ozias.inrs-telecom.uquebec.ca [192.26.211.164]) id QQjgtr05761 for ; Fri, 15 Sep 2000 15:58:51 GMT Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id LAA10335; Fri, 15 Sep 2000 11:58:50 -0400 (EDT) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id LAA04545; Fri, 15 Sep 2000 11:58:50 -0400 (EDT) Message-Id: <200009151558.LAA04545@cholla.INRS-Telecom.UQuebec.CA> Date: Fri, 15 Sep 2000 11:58:50 -0400 (EDT) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: Download NS-2 To: jamathew@wsuhub.uc.twsu.edu Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: R/o366OP24AnrM2Vphz98w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk [http://www.isi.edu/nsnam] for NS, see the contributed code page for info on the MPLS module. >Date: Thu, 14 Sep 2000 21:57:26 -0600 (CST) >From: jamathew@wsuhub.uc.twsu.edu >Subject: Download NS-2 >To: mpls@UU.NET, te-wg@UU.NET >MIME-version: 1.0 > > Hi, > >I wanted to get some information regarding the Network Simulator, and it's >support for MPLS networks. How do i get a demo version of the Simulator, >or is it possible to download a copy of the simulator. I am currently >doing some research regarding MPLS networks, and it would be helpful to me >to get some information regarding the Network Simulator. > > > > >Jubil Alex Mathew >5400, 21st East Street, # 1005, >Wichita, Kansas, 67208. >Ph. No: (316)-689-8741 >email: jubilm@hotmail.com > jamathew@wsuhub.uc.twsu.edu > Tarik From owner-mpls@UU.NET Fri Sep 15 17:08:30 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25019 for ; Fri, 15 Sep 2000 17:08:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgum20996; Fri, 15 Sep 2000 21:07:54 GMT Received: by mail-control.mail.uu.net id QQjgum13994 for mpls-outgoing; Fri, 15 Sep 2000 21:07:19 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjgum13973 for ; Fri, 15 Sep 2000 21:07:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgum14611 for ; Fri, 15 Sep 2000 17:07:07 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgum20609 for ; Fri, 15 Sep 2000 21:07:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA04407 for mpls@uu.net; Fri, 15 Sep 2000 17:07:05 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjgum13956 for ; Fri, 15 Sep 2000 21:06:51 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjgum14557 for ; Fri, 15 Sep 2000 17:06:33 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjgum20220 for ; Fri, 15 Sep 2000 21:06:03 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Sep 2000 17:05:46 -0400 Message-ID: <87009604743AD411B1F600508BA0F9591ABE40@xover.hjinc.com> From: "Kullberg, Alan" To: mpls@UU.NET Subject: LDP: no label resources Date: Fri, 15 Sep 2000 17:05:45 -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 When a Notification message with status code NoLabelResources is sent in response to a Label Request message, should the Message ID field in the Status TLV be set to the Message ID from the Label Request message? Alan From owner-mpls@UU.NET Fri Sep 15 18:12:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25477 for ; Fri, 15 Sep 2000 18:12:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjguq15087; Fri, 15 Sep 2000 22:12:17 GMT Received: by mail-control.mail.uu.net id QQjguq29170 for mpls-outgoing; Fri, 15 Sep 2000 22:11:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjguq29155 for ; Fri, 15 Sep 2000 22:11:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjguq05823 for ; Fri, 15 Sep 2000 18:11:19 -0400 (EDT) Received: from alpha.dtix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.dtix.com [198.62.174.1]) id QQjguq14584 for ; Fri, 15 Sep 2000 22:11:03 GMT Received: from localhost (siddharth@localhost) by alpha.dtix.com (8.9.3/8.8.7) with ESMTP id RAA00692; Fri, 15 Sep 2000 17:28:35 -0400 Date: Fri, 15 Sep 2000 17:28:35 -0400 (EDT) From: Siddharth Gahlaut To: "Kullberg, Alan" cc: mpls@UU.NET Subject: Re: LDP: no label resources In-Reply-To: <87009604743AD411B1F600508BA0F9591ABE40@xover.hjinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Alan, Either way should be fine. This Notification gives you information about the state of the Label Space and not a FEC Control Block. But since it has been sent in response to a request one may choose to set the Status TLV Msg ID == Req Msg ID. Siddharth On Fri, 15 Sep 2000, Kullberg, Alan wrote: > When a Notification message with status code NoLabelResources is sent > in response to a Label Request message, should the Message ID field in > the Status TLV be set to the Message ID from the Label Request message? > > Alan > From owner-mpls@UU.NET Sat Sep 16 13:13:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16049 for ; Sat, 16 Sep 2000 13:13:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjgxo08493; Sat, 16 Sep 2000 17:12:27 GMT Received: by mail-control.mail.uu.net id QQjgxo08666 for mpls-outgoing; Sat, 16 Sep 2000 17:11:56 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgxo08649 for ; Sat, 16 Sep 2000 17:11:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgxo05535 for ; Sat, 16 Sep 2000 13:11:21 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjgxo08277 for ; Sat, 16 Sep 2000 17:11:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA02452 for mpls@uu.net; Sat, 16 Sep 2000 13:11:19 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjgxo08531 for ; Sat, 16 Sep 2000 17:10:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjgxo05501 for ; Sat, 16 Sep 2000 13:10:46 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjgxo08129 for ; Sat, 16 Sep 2000 17:10:16 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA09437; Sat, 16 Sep 2000 10:10:14 -0700 (PDT) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA01680; Sat, 16 Sep 2000 13:10:14 -0400 (EDT) Message-Id: <200009161710.NAA01680@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: Siddharth Gahlaut cc: "Kullberg, Alan" , mpls@UU.NET Subject: Re: LDP: no label resources In-reply-to: Your message of "Fri, 15 Sep 2000 17:28:35 EDT." Date: Sat, 16 Sep 2000 13:10:14 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Siddharth, > Either way should be fine. > This Notification gives you information about the state of the Label Space > and not a FEC Control Block. But since it has been sent in response to > a request one may choose to set the Status TLV Msg ID == Req Msg ID. I disagree. The No Label Resources notification is sent in response to a specific Label Request message. It should include the Message ID of the Label Request message for which it is a response. Receipt of the Notification message signals completion of the Label Request transaction to the sender of the Label Request message. Bob > Siddharth > > On Fri, 15 Sep 2000, Kullberg, Alan wrote: > > > When a Notification message with status code NoLabelResources is sent > > in response to a Label Request message, should the Message ID field in > > the Status TLV be set to the Message ID from the Label Request message? > > > > Alan From owner-mpls@UU.NET Mon Sep 18 06:55:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01818 for ; Mon, 18 Sep 2000 06:55:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhdz26835; Mon, 18 Sep 2000 10:54:35 GMT Received: by mail-control.mail.uu.net id QQjhdz08755 for mpls-outgoing; Mon, 18 Sep 2000 10:54:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjhdz08750 for ; Mon, 18 Sep 2000 10:54:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhdz01935 for ; Mon, 18 Sep 2000 06:54:05 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjhdz26516 for ; Mon, 18 Sep 2000 10:53:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA23440 for mpls@uu.net; Mon, 18 Sep 2000 06:53:44 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjhdz08735 for ; Mon, 18 Sep 2000 10:53:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhdz16101 for ; Mon, 18 Sep 2000 06:53:13 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjhdz26284 for ; Mon, 18 Sep 2000 10:53:13 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01756; Mon, 18 Sep 2000 06:53:12 -0400 (EDT) Message-Id: <200009181053.GAA01756@ietf.org> To: IETF-Announce:; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: mpls@UU.NET From: The IESG Subject: Protocol Action: LDP Specification to Proposed Standard Date: Mon, 18 Sep 2000 06:53:11 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved LDP Specification as a Proposed Standards In the same action, the IESG approved publication of LDP Applicability as an Informational RFC. These documents are the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are David Oran and Rob Coltun. Technical Summary Multiprotocol Label Switching (MPLS) is a method for forwarding packets using short, fixed-length values carried by packets, called labels, to determine packet nexthops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) use the same packet encapsulations and agree on the meaning of the labels which are used to forward traffic between and through them. The common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. MPLS is currently being deployed in the Internet primarily as a technique for traffic engineering. Working Group Summary The working group just completed an editing phase removing normative references to a document that is not ready for publication as an INFORMATIONAL RFC. The WG believes these two documents are ready for publication. Protocol Quality Rob Coltun has reviewed these specs for the IESG. There are multiple implementations of LDP. Note to RFC Editor: In section 3.4.3 after the line IPv4 4 octet full IPv4 address please add the line IPv6 16 octet full IPv6 address From owner-mpls@UU.NET Mon Sep 18 06:59:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01910 for ; Mon, 18 Sep 2000 06:59:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhdz28242; Mon, 18 Sep 2000 10:58:51 GMT Received: by mail-control.mail.uu.net id QQjhdz08985 for mpls-outgoing; Mon, 18 Sep 2000 10:58:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjhdz08980 for ; Mon, 18 Sep 2000 10:58:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhdz16536 for ; Mon, 18 Sep 2000 06:58:25 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjhdz28067 for ; Mon, 18 Sep 2000 10:58:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA24046 for mpls@uu.net; Mon, 18 Sep 2000 06:58:23 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjhdz08966 for ; Mon, 18 Sep 2000 10:58:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhdz16488 for ; Mon, 18 Sep 2000 06:57:46 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjhdz27773 for ; Mon, 18 Sep 2000 10:57:16 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01859; Mon, 18 Sep 2000 06:57:15 -0400 (EDT) Message-Id: <200009181057.GAA01859@ietf.org> To: IETF-Announce:; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: mpls@UU.NET From: The IESG Subject: Protocol Action: VCID Notification over ATM link for LDP to Proposed Standard Date: Mon, 18 Sep 2000 06:57:15 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'VCID Notification over ATM link for LDP' as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are David Oran and Rob Coltun. Technical Summary This document specifies the procedures for the notification of VCID (Virtual Connection IDentifier) for an ATM-LSR (Label Switching Router). Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages in the LDP. The concept of VCID is introduced to solve this problem. VCID has the same value at both ends of a VC. This document specifies the procedure to share the VCID value between ATM-LSRs. Working Group Summary There was consensus in the WG for this document with no major objections. Protocol Quality Currently, there is no complete implementations. However there are implementations in progress. There is an implementation of VCID procedure based on FANP (RFC2129) which is almost same as the VCID notification for LDP, specified by the VCID document. The draft was reviewed by Rob Coltun for the IESG. From owner-mpls@UU.NET Mon Sep 18 08:37:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05307 for ; Mon, 18 Sep 2000 08:37:12 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjheg19513; Mon, 18 Sep 2000 12:36:20 GMT Received: by mail-control.mail.uu.net id QQjheg07101 for mpls-outgoing; Mon, 18 Sep 2000 12:35:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjheg07095 for ; Mon, 18 Sep 2000 12:35:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjheg10622 for ; Mon, 18 Sep 2000 08:35:46 -0400 (EDT) Received: from ext1.ics.forth.gr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ext1.ics.forth.gr [139.91.151.10]) id QQjheg19631 for ; Mon, 18 Sep 2000 12:35:43 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id PAA13027 for ; Mon, 18 Sep 2000 15:35:38 +0300 (EET DST) Received: from sappho.ics.forth.gr (sappho-lane.ics.forth.gr [139.91.157.50]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id PAA09999 for ; Mon, 18 Sep 2000 15:35:14 +0300 (EET DST) Received: from localhost (tziou@localhost) by sappho.ics.forth.gr (8.8.8/ICS-FORTH/C1) with ESMTP id PAA23792 for ; Mon, 18 Sep 2000 15:34:19 +0300 (EET DST) Posted-Date: Mon, 18 Sep 2000 15:34:19 +0300 (EET DST) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Organization: Date: Mon, 18 Sep 2000 15:34:19 +0300 (EET DST) From: Chrysostomos Tziouvaras To: mpls@UU.NET Subject: Seeking for info....... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Do you know any mailing list about MPL(ambda)S or Generalised MPLS? Tziouvaras Chrysostomos ICS-FORTH Researcher From owner-mpls@UU.NET Mon Sep 18 10:30:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08818 for ; Mon, 18 Sep 2000 10:30:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhen26070; Mon, 18 Sep 2000 14:29:16 GMT Received: by mail-control.mail.uu.net id QQjhen06714 for mpls-outgoing; Mon, 18 Sep 2000 14:28:48 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjhen06699 for ; Mon, 18 Sep 2000 14:28:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjhen27180 for ; Mon, 18 Sep 2000 10:28:40 -0400 (EDT) From: Vishal.Sharma@tellabs.com Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQjhen25636 for ; Mon, 18 Sep 2000 14:28:24 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id JAA27184; Mon, 18 Sep 2000 09:26:26 -0500 (CDT) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA02537; Mon, 18 Sep 2000 09:27:03 -0500 (CDT) X-OpenMail-Hops: 1 Date: Mon, 18 Sep 2000 09:10:06 -0500 Message-Id: Subject: RE: Seeking for info....... MIME-Version: 1.0 TO: mpls@UU.NET, tziou@ics.forth.gr Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 18 Sep 2000 09:10:06 -0500" Sender: owner-mpls@UU.NET Precedence: bulk Tziouvaras, Both MPLambdaS and Generalized MPLS are currently being pursued within the MPLS WG, so the appropriate list to discuss anything related to these two topics is the MPLS WG mailing list (namely this list). For related issues, you may also want to look at the IP-over-Optical mailing list, at IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical (actually the last address has changed, but I think if you try the above url, you will probably be redirected to the new one) -Vishal > -----Original Message----- > From: tziou@ics.forth.gr [mailto:tziou@ics.forth.gr] > Sent: Monday, September 18, 2000 8:34 AM > To: mpls@UU.NET > Subject: Seeking for info....... > > > Do you know any mailing list about MPL(ambda)S or Generalised MPLS? > > Tziouvaras Chrysostomos > ICS-FORTH Researcher > > From owner-mpls@UU.NET Mon Sep 18 11:55:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12153 for ; Mon, 18 Sep 2000 11:55:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhet01979; Mon, 18 Sep 2000 15:54:43 GMT Received: by mail-control.mail.uu.net id QQjhet24417 for mpls-outgoing; Mon, 18 Sep 2000 15:54:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjhet24412 for ; Mon, 18 Sep 2000 15:53:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhet11836 for ; Mon, 18 Sep 2000 11:53:34 -0400 (EDT) Received: from postal.redback.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQjhet01459 for ; Mon, 18 Sep 2000 15:53:34 GMT Received: from redback.com (pptp-15-143.redback.com [155.53.15.143]) by postal.redback.com (Postfix) with ESMTP id B182917BC0F; Mon, 18 Sep 2000 08:53:31 -0700 (PDT) Message-ID: <39C66546.6D40726C@redback.com> Date: Mon, 18 Sep 2000 11:56:06 -0700 From: Rob Coltun X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Cc: Ron Bonica Subject: draft-ietf-mpls-icmp-02.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS folks, the IESG has reviewed draft-ietf-mpls-icmp-02.txt and has decided not advance its publication for two reasons. First, the IESG and a handful of folks in the community feel that including information that exists at the sub-IP layer in ICMP is a "layer violation" and not entirely backward compatible with RFC 1122 and RFC 1812 (the draft does not directly address what happens to a host that receives this ICMP extension and does not support it). Second, the utility that the draft is addressing is generally very useful for diagnosing problems with other types tunneling protocols in addition to MPLS. For this reason, we would like to start a design team, headed by Ron, to develop more generalized version of what these extensions were designed to address. thanks, ---rob From owner-mpls@UU.NET Mon Sep 18 12:36:23 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14000 for ; Mon, 18 Sep 2000 12:36:23 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhew15628; Mon, 18 Sep 2000 16:35:17 GMT Received: by mail-control.mail.uu.net id QQjhew09199 for mpls-outgoing; Mon, 18 Sep 2000 16:34:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjhew09194 for ; Mon, 18 Sep 2000 16:34:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhew18308 for ; Mon, 18 Sep 2000 12:34:28 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjhew15281 for ; Mon, 18 Sep 2000 16:34:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29734 for ; Mon, 18 Sep 2000 09:34:47 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA03817 for mpls@uu.net; Mon, 18 Sep 2000 12:34:24 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjhev08543 for ; Mon, 18 Sep 2000 16:25:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjhev16823 for ; Mon, 18 Sep 2000 12:25:20 -0400 (EDT) Received: from daystrom.abatis-sys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [216.13.164.98]) id QQjhev11515 for ; Mon, 18 Sep 2000 16:25:20 GMT Received: by daystrom.abatissys.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 09:26:32 -0700 Message-ID: <811670B03A7DD211A2730008C709C20959F55A@daystrom.abatissys.com> From: "Li, Renwei" To: "'mpls@uu.net'" Subject: Determining the Network Layer Protocol Date: Mon, 18 Sep 2000 09:25:09 -0700 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 After all labels are popped off or when some errors are found, a networking device needs to process the network layer protocols. However, the network layer protocol is not specified in the MPLS label stack or any of its lower protocol headers. In the draft titled "MPLS Label Stack Encoding", some inference tricks are presented. Basically, the draft suggests that some labels be used only for packets of a particular network layer. On the other hand, in MPLS Control Protocol for PPP connection, no configuration options are provided. In LDP, CR-LDP, RSVP-LDP, no options are found to enable us to specify some labels for a particular network layer. In ATM VP/VC encoding, no standard way is provided to reserve some special VP/VC for a particular network layer protocol. Note that no matter which inference trick is used by following MPLS Label Stack Encoding, there is always an example so that one is unable to infer the network layer protocol. Since MPLS is intended for MULTIPLE PROTOCOLS, I am wondering why we don't just simply add one more field (maybe just one byte) in the MPLS header (for example, the last entry in the label stack) to denote the network layer protocol? Can the authors of the MPLS Label Stack Encoding or somebody else explain why it is not done so? Any reasons for that? Any comments? Thanks, Renwei Li Principal Technical Analyst Abatis Systems Corporation Phone: (604) 918-4706 Email: rli@abatis-sys.com From owner-mpls@UU.NET Mon Sep 18 12:43:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14289 for ; Mon, 18 Sep 2000 12:43:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhew18196; Mon, 18 Sep 2000 16:42:48 GMT Received: by mail-control.mail.uu.net id QQjhew09539 for mpls-outgoing; Mon, 18 Sep 2000 16:42:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjhew09532 for ; Mon, 18 Sep 2000 16:42:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhew29314 for ; Mon, 18 Sep 2000 12:41:56 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjhew17828 for ; Mon, 18 Sep 2000 16:41:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA02795 for mpls@uu.net; Mon, 18 Sep 2000 12:41:39 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjhew09370 for ; Mon, 18 Sep 2000 16:41:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhew29177 for ; Mon, 18 Sep 2000 12:41:00 -0400 (EDT) Received: from alpo.casc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpo.casc.com [152.148.10.6]) id QQjhew17589 for ; Mon, 18 Sep 2000 16:40:59 GMT Received: from ma8117ppatel4 ([152.148.92.175]) by alpo.casc.com (8.9.1a/8.9.1) with SMTP id MAA27424 for ; Mon, 18 Sep 2000 12:40:59 -0400 (EDT) Message-Id: <200009181640.MAA27424@alpo.casc.com> X-Sender: ppatel@mailbox.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 18 Sep 2000 12:35:56 -0400 To: mpls@UU.NET From: Pramod Patel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk auth 94571bc0 subscribe mpls pramod.patel@ascend.com From owner-mpls@UU.NET Mon Sep 18 13:11:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15073 for ; Mon, 18 Sep 2000 13:11:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhey28472; Mon, 18 Sep 2000 17:11:21 GMT Received: by mail-control.mail.uu.net id QQjhey22391 for mpls-outgoing; Mon, 18 Sep 2000 17:10:55 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjhey22385 for ; Mon, 18 Sep 2000 17:10:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhey23583 for ; Mon, 18 Sep 2000 13:10:33 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQjhey27021 for ; Mon, 18 Sep 2000 17:10:18 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 10:19:07 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A66213629B@ICARIAN> From: Eric Gray To: "'Li, Renwei'" Cc: "'MPLS mailing list'" Subject: RE: Determining the Network Layer Protocol Date: Mon, 18 Sep 2000 10:19:06 -0700 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 Renwei, LSPs are established using signaling and labels are provided from downstream LSRs. Therefore, it is expected of a downstream LSR that it shouldn't provide a label to an upstream LSR unless it knows how to forward packets received using that label. There are two ways that it might "know" how to forward labeled packets: 1) it is the egress for the corresponding LSP and knows how to forward the packet as an L3 packet (for whatever L3 applies) or 2) it has a corresponding label from a downstream LSR peer that it can use in forwarding the packet to that peer. Either way, labeled packets should eventually arrive at an egress LSR that knows what to do with them. -- Eric Gray > -----Original Message----- > From: Li, Renwei [mailto:rli@abatis-sys.com] > Sent: Monday, September 18, 2000 9:25 AM > To: 'mpls@uu.net' > Subject: Determining the Network Layer Protocol > > > After all labels are popped off or when some errors are > found, a networking > device needs to process the network layer protocols. However, > the network > layer protocol is not specified in the MPLS label stack or > any of its lower > protocol headers. > > In the draft titled "MPLS Label Stack Encoding", some > inference tricks are > presented. Basically, the draft suggests that some labels be > used only for > packets of a particular network layer. On the other hand, in > MPLS Control > Protocol for PPP connection, no configuration options are > provided. In LDP, > CR-LDP, RSVP-LDP, no options are found to enable us to > specify some labels > for a particular network layer. In ATM VP/VC encoding, no > standard way is > provided to reserve some special VP/VC for a particular network layer > protocol. > > Note that no matter which inference trick is used by > following MPLS Label > Stack Encoding, there is always an example so that one is > unable to infer > the network layer protocol. > > Since MPLS is intended for MULTIPLE PROTOCOLS, I am wondering > why we don't > just simply add one more field (maybe just one byte) in the > MPLS header (for > example, the last entry in the label stack) to denote the > network layer > protocol? Can the authors of the MPLS Label Stack Encoding or > somebody else > explain why it is not done so? Any reasons for that? Any comments? > > Thanks, > > Renwei Li > > Principal Technical Analyst > Abatis Systems Corporation > Phone: (604) 918-4706 > Email: rli@abatis-sys.com > > > > From owner-mpls@UU.NET Mon Sep 18 13:22:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15377 for ; Mon, 18 Sep 2000 13:22:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhez00717; Mon, 18 Sep 2000 17:21:57 GMT Received: by mail-control.mail.uu.net id QQjhez23504 for mpls-outgoing; Mon, 18 Sep 2000 17:21:36 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjhez23496 for ; Mon, 18 Sep 2000 17:21:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhez25133 for ; Mon, 18 Sep 2000 13:21:19 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjhez00305 for ; Mon, 18 Sep 2000 17:20:48 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 NAA08452 for ; Mon, 18 Sep 2000 13:20: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 NAA15263 for ; Mon, 18 Sep 2000 13:20:47 -0400 (EDT) Message-ID: <39C64F22.77A187B8@marconi.com> Date: Mon, 18 Sep 2000 13:21:38 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Determining the Network Layer Protocol References: <811670B03A7DD211A2730008C709C20959F55A@daystrom.abatissys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Li, Renwei" wrote: > > After all labels are popped off or when some errors are found, a > networking device needs to process the network layer protocols. > However, the network layer protocol is not specified in the MPLS label > stack or any of its lower protocol headers. When RSVP-TE is used to signal label distribution, this information is sent from the ingress node to the egress node as a part of the label-request object. I would be surprised if CR-LDP doesn't have a similar mechanism in it. -- David From owner-mpls@UU.NET Mon Sep 18 13:39:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15776 for ; Mon, 18 Sep 2000 13:39:28 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhfa07994; Mon, 18 Sep 2000 17:38:49 GMT Received: by mail-control.mail.uu.net id QQjhfa24714 for mpls-outgoing; Mon, 18 Sep 2000 17:38:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjhfa24708 for ; Mon, 18 Sep 2000 17:38:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhfa27830 for ; Mon, 18 Sep 2000 13:38:14 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjhfa06578 for ; Mon, 18 Sep 2000 17:37:43 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 NAA10126 for ; Mon, 18 Sep 2000 13:37:41 -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 NAA19545 for ; Mon, 18 Sep 2000 13:37:41 -0400 (EDT) Message-ID: <39C65319.2D20C2C7@marconi.com> Date: Mon, 18 Sep 2000 13:38:33 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Question on RSVP-TE and Resv Confirm messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit When a switch running RSVP-TE receives a Resv message with a Resv Confirm object in it, it will generate a ResvConfirm message to send back to the egress node. How should it send this message? Under RFC-2205, the message would be sent directly to the recipient without router-alert. It would be forwarded to the egress switch like any other data packet. Under the RSVP-TE draft, it is unclear how this should happen. If the message is sent in the same way, then it may not get delivered. The only route to the destination may not be known to the routing table. It is also possible to send it down the explicit-route that the Path message was send with. But this changes the original behavior. In order to do this, the ResvConfirm message must have the router-alert option set, and RSVP must participate in forwarding this message (by looking up the corresponding path state and its ERO in order to determine the next-hop.) -- David From owner-mpls@UU.NET Mon Sep 18 14:09:33 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16424 for ; Mon, 18 Sep 2000 14:09:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhfc17127; Mon, 18 Sep 2000 18:08:55 GMT Received: by mail-control.mail.uu.net id QQjhfc08042 for mpls-outgoing; Mon, 18 Sep 2000 18:08:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjhfc08037 for ; Mon, 18 Sep 2000 18:08:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhfc02868 for ; Mon, 18 Sep 2000 14:08:27 -0400 (EDT) From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjhfc16850 for ; Mon, 18 Sep 2000 18:08:27 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Mon, 18 Sep 2000 19:07:56 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Mon, 18 Sep 2000 19:07:50 +0100 Message-ID: To: rli@abatis-sys.com, mpls@UU.NET Subject: RE: Determining the Network Layer Protocol Date: Mon, 18 Sep 2000 19:07:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Li, Renwei wrote Monday, September 18, 2000 5:25 PM > After all labels are popped off or when some errors are found, a > networking > device needs to process the network layer protocols. However, the network > layer protocol is not specified in the MPLS label stack or any of its > lower > protocol headers. [Harrison,N,Neil,INC1 X] > Since MPLS is intended for MULTIPLE PROTOCOLS, I am wondering why we don't > just simply add one more field (maybe just one byte) in the MPLS header > (for > example, the last entry in the label stack) to denote the network layer > protocol? Can the authors of the MPLS Label Stack Encoding or somebody > else > explain why it is not done so? Any reasons for that? Any comments? > [Harrison,N,Neil,INC1 X] This is important for a reason you have not touched on.....but I will come back on that in a moment. Firstly, wrt to identification of the client layer network-type........it is generally assumed that there is a long-term temporal association between an LSP and its client payload for the duration of the LSP's lifetime. In other words it is assumed that there is no multiplexing of the client payload. With this assumption one does not need a payload identifier. A problem arises however when one needs to introduce defect handling procedures into MPLS. I will not go into the detail here (several of us are working on an ID where this detail will be given), but in essence we can have potential connectivity failure mechanisms in MPLS that do not afflict an IP layer, eg in addition to the well-known simple breaks and self-mismerging (aka looping) defects, we might also see swapped connections and mismerged (different) connections. These arise since LSPs use relative addressing, ie a label may only be interface unique. To detect/diagnose these types of connectivity failures one can periodically send a 'Connectivity Verification (CV)' packet from an LSP's source to its sink which contains a unique trail source identifier (note - each IP packet already effectively carries out this function since IP addresses are network-wide unique). With this functionality, however, the problem now is the diffentiation of such a CV packet from normal user-plane traffic. A payload identifier in the LSP header would have been the ideal solution, but this would be unlikely to have found favour with many (even a minor revising the use of the TTL field would have done). So we are likely to require additional special labels to identify such OAM functions from normal user-plane traffic....with the minor downside that this will increase the label depth on the issue of such OAM packets. Regards, Neil From owner-mpls@UU.NET Mon Sep 18 15:08:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17702 for ; Mon, 18 Sep 2000 15:08:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhfg13548; Mon, 18 Sep 2000 19:07:18 GMT Received: by mail-control.mail.uu.net id QQjhfg22875 for mpls-outgoing; Mon, 18 Sep 2000 19:06:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjhfg22864 for ; Mon, 18 Sep 2000 19:06:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhfg22107 for ; Mon, 18 Sep 2000 15:06:46 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjhfg13202 for ; Mon, 18 Sep 2000 19:06:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA27548 for mpls@uu.net; Mon, 18 Sep 2000 15:06:44 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjhfg22802 for ; Mon, 18 Sep 2000 19:06:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjhfg21970 for ; Mon, 18 Sep 2000 15:06:01 -0400 (EDT) Received: from viva.vivacenet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: w005.z208036016.sjc-ca.dsl.cnc.net [208.36.16.5]) id QQjhfg12457 for ; Mon, 18 Sep 2000 19:05:30 GMT Received: from AMALIS.vivacenet.com [209.206.27.73] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A5C812770346; Mon, 18 Sep 2000 11:58:16 -0700 Message-Id: <4.3.2.7.2.20000918145413.02b2b368@viva.vivacenet.com> X-Sender: Andy.Malis@viva.vivacenet.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Sep 2000 14:58:14 -0400 To: David Charlap From: "Andrew G. Malis" Subject: Re: Determining the Network Layer Protocol Cc: "'mpls@uu.net'" In-Reply-To: <39C64F22.77A187B8@marconi.com> References: <811670B03A7DD211A2730008C709C20959F55A@daystrom.abatissys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk David and Renwei, David Charlap wrote: >"Li, Renwei" wrote: > > After all labels are popped off or when some errors are found, a > > networking device needs to process the network layer protocols. > > However, the network layer protocol is not specified in the MPLS label > > stack or any of its lower protocol headers. > >When RSVP-TE is used to signal label distribution, this information is >sent from the ingress node to the egress node as a part of the >label-request object. > >I would be surprised if CR-LDP doesn't have a similar mechanism in it. draft-martini-l2circuit-trans-mpls-03.txt introduces a new LDP Virtual Circuit FEC TLV element for use with non-IP protocols carried over MPLS. The protocol type is signaled in the TLV as a part of label binding. Cheers, Andy ________________________________________________________________________ Andrew G. Malis Andy.Malis@vivacenetworks.com phone:408-383-7223 Vivace Networks/2730 Orchard Parkway/San Jose, CA 95134/fax:408-904-4748 http://www.vivacenetworks.com From owner-mpls@UU.NET Mon Sep 18 15:49:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18478 for ; Mon, 18 Sep 2000 15:49:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhfj03304; Mon, 18 Sep 2000 19:49:00 GMT Received: by mail-control.mail.uu.net id QQjhfj26004 for mpls-outgoing; Mon, 18 Sep 2000 19:48:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjhfj25993 for ; Mon, 18 Sep 2000 19:48:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjhfj29446 for ; Mon, 18 Sep 2000 15:47:50 -0400 (EDT) Received: from workhorse.fictitious.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjhfj00840 for ; Mon, 18 Sep 2000 19:47:17 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA36530; Mon, 18 Sep 2000 15:45:49 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200009181945.PAA36530@workhorse.fictitious.org> To: "Li, Renwei" cc: "'mpls@uu.net'" Reply-To: curtis@avici.com Subject: Re: Determining the Network Layer Protocol In-reply-to: Your message of "Mon, 18 Sep 2000 09:25:09 PDT." <811670B03A7DD211A2730008C709C20959F55A@daystrom.abatissys.com> Date: Mon, 18 Sep 2000 15:45:49 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <811670B03A7DD211A2730008C709C20959F55A@daystrom.abatissys.com>, "Li , Renwei" writes: > After all labels are popped off or when some errors are found, a networking > device needs to process the network layer protocols. However, the network > layer protocol is not specified in the MPLS label stack or any of its lower > protocol headers. See draft-ietf-mpls-rsvp-lsp-tunnel-07.txt section 4.2 starting on page 20. Generic format below, formats for ATM and FR on the following pages. Curtis 4.2. Label Request Object The Label Request Class is 19. Currently there three possible C_Types. Type 1 is a Label Request without label range. Type 2 is a label request with an ATM label range. Type 3 is a label request with a Frame Relay label range. The LABEL_REQUEST object formats are shown below. 4.2.1. Label Request without Label Range Class = 19, C_Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved This field is reserved. It MUST be set to zero on transmis- sion and MUST be ignored on receipt. L3PID an identifier of the layer 3 protocol using this path. Standard Ethertype values are used. From owner-mpls@UU.NET Mon Sep 18 16:08:55 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18829 for ; Mon, 18 Sep 2000 16:08:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhfk11997; Mon, 18 Sep 2000 20:07:19 GMT Received: by mail-control.mail.uu.net id QQjhfk08543 for mpls-outgoing; Mon, 18 Sep 2000 20:06:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjhfk08524 for ; Mon, 18 Sep 2000 20:06:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjhfk02880 for ; Mon, 18 Sep 2000 16:06:40 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjhfk09170 for ; Mon, 18 Sep 2000 20:06:40 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e8IK6Z401988; Mon, 18 Sep 2000 16:06:35 -0400 (EDT) Message-Id: <200009182006.e8IK6Z401988@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: David Charlap cc: mpls@UU.NET Subject: Re: Question on RSVP-TE and Resv Confirm messages In-reply-to: Your message of "Mon, 18 Sep 2000 13:38:33 EDT." <39C65319.2D20C2C7@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Sep 2000 16:06:34 -0400 Sender: owner-mpls@UU.NET Precedence: bulk David, > When a switch running RSVP-TE receives a Resv message with a Resv > Confirm object in it, it will generate a ResvConfirm message to send > back to the egress node. > > How should it send this message? > > Under RFC-2205, the message would be sent directly to the recipient > without router-alert. It would be forwarded to the egress switch like > any other data packet. This is not what RFC 2205 says. You have to use the router alert option to implement what the RFC requires: A ResvConf message is sent to the unicast address of a receiver host; the address is obtained from the RESV_CONFIRM object. However, a ResvConf message is forwarded to the receiver hop- by-hop, to accommodate the hop-by-hop integrity check mechanism. To make the hop-by-hop integrity check work and at the same time put the address of the receiver host in the IP destination address field, you have to use the router alert option. And if you look at the ISI "reference implementation", you will see that it does exactly that. > Under the RSVP-TE draft, it is unclear how this should happen. > > If the message is sent in the same way, then it may not get delivered. > The only route to the destination may not be known to the routing table. > > It is also possible to send it down the explicit-route that the Path > message was send with. But this changes the original behavior. In > order to do this, the ResvConfirm message must have the router-alert > option set, and RSVP must participate in forwarding this message (by > looking up the corresponding path state and its ERO in order to > determine the next-hop.) Sending it along the explicit route with the router alert is the only way you can get things to work. Markus From owner-mpls@UU.NET Mon Sep 18 16:30:29 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19224 for ; Mon, 18 Sep 2000 16:30:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjhfl19572; Mon, 18 Sep 2000 20:29:23 GMT Received: by mail-control.mail.uu.net id QQjhfl10325 for mpls-outgoing; Mon, 18 Sep 2000 20:28:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjhfl10313 for ; Mon, 18 Sep 2000 20:28:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjhfl06414 for ; Mon, 18 Sep 2000 16:28:17 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjhfl21958 for ; Mon, 18 Sep 2000 20:28:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA10269 for mpls@uu.net; Mon, 18 Sep 2000 16:28:16 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjhfl10235 for ; Mon, 18 Sep 2000 20:27:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjhfl29242 for ; Mon, 18 Sep 2000 16:27:22 -0400 (EDT) Received: from coltrane.dataconnection.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjhfl18600 for ; Mon, 18 Sep 2000 20:27:22 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 21:27:12 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA203@monk.datcon.co.uk> From: Adrian Farrel To: egray@zaffire.com Cc: mpls@UU.NET Subject: draft-gray-mpls-rsvp-oif-uni-ext Date: Mon, 18 Sep 2000 21:26:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, Thanks for this draft, it pulls things together nicely and shows how simply UNI can be performed with existing protocols. I have just a couple of questions. Is the Propagation Delay object wholly new? Have you any plans for what it looks like? In sections 3.4 and 5.4 (which need renumbering :-) you use a Notify to expedite the acknowledgement of a Tear if there is no suitable message on which to piggy-back the Ack. Why did you choose this rather than an Ack message? The Ack message exists for exactly this purpose, while the Notify requires an Error_Spec. I believe you may have cut and pasted a typo from draft-ietf-mpls-rsvp-lsp-tunnel-06.txt. George has fixed this in v7. TIME_VALUES should be mandatory on Path and Resv Lastly, I'm not sure that the format you have given for the Path is quite correct with regard to the GLR, LS and SL objects. Since my version of GMPLS doesn't have anything specific to say on the subject I can only piece it together from the text... - I don't think you can have Generalized Label Request and suggested label on the same Path message. - I think Label Set supplements both Generalized Label Request and Suggested Label. This (and the previous point) would give ::= [ ] [ ] | [

> -----Original Message-----
>=20 From: Grenville Armitage [mailto:gja@research.bell-labs.= com]=20
> Sent: Wednesday, September 27, 2000 11:32 = AM=20
> To: mpls@UU.NET
> = Subject:=20 B/W vs QoS Re: Any SPs using QoS ???
>=20
>
> =
>
> B/W isn't QoS. =
>
> B/W may become cheap(er), = but the=20 premium service will
> be constrained = jitter/loss=20 (or predictable delay/loss, take
> your = choice of=20 poison).
>
> = It isn't=20 even clear that one can solely say "overprovision"
> as the magic words to clear up jitter and loss. = Realities=20
> such as slow provisioning schedules and = technology=20 limitations
> can cause your B/W growth = to fall=20 behind the demand growth,
> creating = congestion=20 points.
>
> = Which=20 suggests anything that helps distribute congestion points =
> (e.g. MPLS TE) and helps differentiate traffic at=20 congestion
> points (e.g. Diffserv+MPLS) = will find=20 use.
>
> = cheers,=20
> gja
>=20

------=_NextPart_000_005E_01C02925.E92DDE40-- From owner-mpls@UU.NET Thu Sep 28 05:45:58 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15735 for ; Thu, 28 Sep 2000 05:45:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiot22655; Thu, 28 Sep 2000 09:45:24 GMT Received: by mail-control.mail.uu.net id QQjios03651 for mpls-outgoing; Thu, 28 Sep 2000 09:44:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjios03642 for ; Thu, 28 Sep 2000 09:44:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjios10825 for ; Thu, 28 Sep 2000 05:43:52 -0400 (EDT) Received: from yamato.ccrle.nec.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: yamato.ccrle.nec.de [195.37.70.1]) id QQjios22202 for ; Thu, 28 Sep 2000 09:43:51 GMT Received: from wallace.heidelberg.ccrle.nec.de (admin@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e8S9ob022062; Thu, 28 Sep 2000 11:50:37 +0200 (CEST) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA05741; Thu, 28 Sep 2000 11:47:01 +0200 Message-ID: <39D313F1.1DA20A60@ccrle.nec.de> Date: Thu, 28 Sep 2000 11:48:33 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Cheenu Srinivasan CC: "'curtis@avici.com'" , "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-ftn-mib-00.txt is now available References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Cheenu Srinivasan wrote: > > Curtis, > > Curtis Villamizar wrote: > > > > The DSCP, or more correctly a 64 bit DSCP mask, with one bit per > > possible DSCP value should be part of the FEC. Other > implementations > > (will) allow different DSCP values for the same IP prefix to be > routed > > onto different LSP. Where all DSCP values map into a single LSP, > then > > the mask is all ones. (The MIB should not be constrained to match a > > > specific vendors implementation limitations.) There is no way to > > apply different setup and holding priorities, different adaptivity > > parameters, and local protect to some DSCP values and not to other > > DSCP values without this capability. > > We can put in mapping of DSCP values to LSPs/Tunnels if this group > thinks its needed. What this MIB is not meant to do is DSCP remapping > which should be done in the diffserv MIB. Sure not. It really is just meant as an additional FEC descriptor without any additional action behind. Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From owner-mpls@UU.NET Thu Sep 28 05:47:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15756 for ; Thu, 28 Sep 2000 05:47:59 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiot03967; Thu, 28 Sep 2000 09:47:24 GMT Received: by mail-control.mail.uu.net id QQjiot04003 for mpls-outgoing; Thu, 28 Sep 2000 09:46:53 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjiot03995 for ; Thu, 28 Sep 2000 09:46:52 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiot11105 for ; Thu, 28 Sep 2000 05:46:33 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjiot23029 for ; Thu, 28 Sep 2000 09:46:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA12838 for mpls@uu.net; Thu, 28 Sep 2000 05:46:01 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjiot03849 for ; Thu, 28 Sep 2000 09:45:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiot01563 for ; Thu, 28 Sep 2000 05:45:10 -0400 (EDT) Received: from coltrane.dataconnection.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjiot03530 for ; Thu, 28 Sep 2000 09:45:10 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 10:44:59 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA2E2@monk.datcon.co.uk> From: Adrian Farrel To: Bora Akyol , "J. Noel Chiappa" Cc: mpls@UU.NET Subject: RE: Asymmetrical Bi-directional LSPs Date: Thu, 28 Sep 2000 10:44:58 +0100 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 Bora, I agree with your concerns about moving goal-posts, but... >-----Original Message----- >From: Bora Akyol [mailto:akyol@pluris.com] >"J. Noel Chiappa" wrote: >> > From: Bora Akyol >> > Although I don't like the idea, if this comes to >> >happen, option 3 >> > would be my preference. >> >> ??? LSP's aren't bidirectional anyway, right? (What *is* the >> opposite of 'merge' - 'spray'? :-) So what difference does it >> make if someone wants the back channel to take a different >> path? It's not like there's a mechanism already to do >> bidirectional LSP's and this is breaking it. > >Not quite true, if we do option 3, then we will have to add >another object to the PATH message to indicate the reverse >path that we would like the reverse LSP to follow. This is >more work and I am getting tired of adding new stuff to our >RSVP code almost every week ;-( This need not be the case. Consider that GMPLS allows a Label on a Path message. If we remove the requirement for a Label_Request/Suggested_Label we are there. >I do not want to add to RSVP-TE before it becomes an RFC. If >you look at MPLS WG web page, you will find that there is a >boatload of MPLS ID's but not many RFCs. >This is frustrating because things keep on changing and nothing is ever >finalized. I think MPLS WG should close its doors to new items >until it can clear its existing items. Agree. It is hard to develop to a draft that keep s changing. I may be wrong, but I believe that RSVP-TE is quite close to stable now. The changes I'm discussing would be for the Generalized Signaling draft, which (I assume) will make its separate way towards RFC. Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Thu Sep 28 06:48:04 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16552 for ; Thu, 28 Sep 2000 06:48:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiox04469; Thu, 28 Sep 2000 10:47:44 GMT Received: by mail-control.mail.uu.net id QQjiox18809 for mpls-outgoing; Thu, 28 Sep 2000 10:47:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjiox18804 for ; Thu, 28 Sep 2000 10:47:07 GMT Received: from usashexims04.corp.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: corpsmtpin.corp.us.uu.net [153.39.84.15]) id QQjiox06174; Thu, 28 Sep 2000 06:47:03 -0400 (EDT) Received: by corpsmtpin.corp.us.uu.net with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Sep 2000 06:43:58 -0400 Message-ID: From: "Winbush, Walter" To: "'Adrian Farrel'" , Bora Akyol , "J. Noel Chiappa" Cc: mpls@UU.NET Subject: Please remove (from Alias) Date: Thu, 28 Sep 2000 06:43:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Please remove.. -----Original Message----- From: Adrian Farrel [mailto:AF@dataconnection.com] Sent: Thursday, September 28, 2000 5:45 AM To: Bora Akyol; J. Noel Chiappa Cc: mpls@uu.net Subject: RE: Asymmetrical Bi-directional LSPs Bora, I agree with your concerns about moving goal-posts, but... >-----Original Message----- >From: Bora Akyol [mailto:akyol@pluris.com] >"J. Noel Chiappa" wrote: >> > From: Bora Akyol >> > Although I don't like the idea, if this comes to >> >happen, option 3 >> > would be my preference. >> >> ??? LSP's aren't bidirectional anyway, right? (What *is* the >> opposite of 'merge' - 'spray'? :-) So what difference does it >> make if someone wants the back channel to take a different >> path? It's not like there's a mechanism already to do >> bidirectional LSP's and this is breaking it. > >Not quite true, if we do option 3, then we will have to add >another object to the PATH message to indicate the reverse >path that we would like the reverse LSP to follow. This is >more work and I am getting tired of adding new stuff to our >RSVP code almost every week ;-( This need not be the case. Consider that GMPLS allows a Label on a Path message. If we remove the requirement for a Label_Request/Suggested_Label we are there. >I do not want to add to RSVP-TE before it becomes an RFC. If >you look at MPLS WG web page, you will find that there is a >boatload of MPLS ID's but not many RFCs. >This is frustrating because things keep on changing and nothing is ever >finalized. I think MPLS WG should close its doors to new items >until it can clear its existing items. Agree. It is hard to develop to a draft that keep s changing. I may be wrong, but I believe that RSVP-TE is quite close to stable now. The changes I'm discussing would be for the Generalized Signaling draft, which (I assume) will make its separate way towards RFC. Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Thu Sep 28 08:37:30 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18577 for ; Thu, 28 Sep 2000 08:37:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipe01898; Thu, 28 Sep 2000 12:36:51 GMT Received: by mail-control.mail.uu.net id QQjipe17830 for mpls-outgoing; Thu, 28 Sep 2000 12:36:36 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipe17825 for ; Thu, 28 Sep 2000 12:36:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipe25161 for ; Thu, 28 Sep 2000 08:36:24 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjipe26742 for ; Thu, 28 Sep 2000 12:36:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA23173 for mpls@uu.net; Thu, 28 Sep 2000 08:36:23 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipe17750 for ; Thu, 28 Sep 2000 12:36:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipe15832 for ; Thu, 28 Sep 2000 08:35:54 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjipe01677 for ; Thu, 28 Sep 2000 12:35:54 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA13713; Thu, 28 Sep 2000 08:35:53 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAF11964; Thu, 28 Sep 2000 08:35:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20000928083205.05a83c70@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 08:32:46 -0400 To: brunner@ccrle.nec.de, Cheenu Srinivasan From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-ftn-mib-00.txt is now available Cc: "'curtis@avici.com'" , "'mpls@uu.net'" In-Reply-To: <39D313F1.1DA20A60@ccrle.nec.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:48 AM 9/28/00 +0200, Marcus Brunner wrote: > > Cheenu Srinivasan wrote: > > > > Curtis, > > > > Curtis Villamizar wrote: > > > > > > The DSCP, or more correctly a 64 bit DSCP mask, with one bit per > > > possible DSCP value should be part of the FEC. Other > > implementations > > > (will) allow different DSCP values for the same IP prefix to be > > routed > > > onto different LSP. Where all DSCP values map into a single LSP, > > then > > > the mask is all ones. (The MIB should not be constrained to match a > > > > > specific vendors implementation limitations.) There is no way to > > > apply different setup and holding priorities, different adaptivity > > > parameters, and local protect to some DSCP values and not to other > > > DSCP values without this capability. > > > > We can put in mapping of DSCP values to LSPs/Tunnels if this group > > thinks its needed. What this MIB is not meant to do is DSCP remapping > > which should be done in the diffserv MIB. > >Sure not. It really is just meant as an additional FEC descriptor >without any additional action behind. I agree with Cheenu, lets hear from others about whether or not they think this value is important and should be included as an attribute. --Tom From owner-mpls@UU.NET Thu Sep 28 08:48:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18789 for ; Thu, 28 Sep 2000 08:48:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipf29525; Thu, 28 Sep 2000 12:47:20 GMT Received: by mail-control.mail.uu.net id QQjipf18442 for mpls-outgoing; Thu, 28 Sep 2000 12:46:56 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipf18434 for ; Thu, 28 Sep 2000 12:46:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipf26246 for ; Thu, 28 Sep 2000 08:46:33 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjipf29261 for ; Thu, 28 Sep 2000 12:46:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA24373 for mpls@uu.net; Thu, 28 Sep 2000 08:46:32 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipf18372 for ; Thu, 28 Sep 2000 12:46:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipf26152 for ; Thu, 28 Sep 2000 08:45:53 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjipf04035 for ; Thu, 28 Sep 2000 12:45:23 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA14496; Thu, 28 Sep 2000 08:45:14 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAF12026; Thu, 28 Sep 2000 08:45:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20000927223109.05a75300@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 08:42:07 -0400 To: "Mancour, Tim" , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Question regarding the MPLS-LSR-MIB and Ethernet Cc: cheenu Srinivasan , arun Viswanathan In-Reply-To: <6B190B34070BD411ACA000B0D0214E5609ED0F@newman.tenornet.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Tim, At 06:25 PM 9/27/00 -0400, Mancour, Tim wrote: >Hi, > >How would one setup an LSP over an Ethernet interface using the >MPLS-LSR-MIB? Consider the following where A, B , C, and D are all LSRs with >Ethernet interfaces attached to an Ethernet Bridge (S): > > A > | > B -- S -- C > | > D > >In the above, the label space of each LSR is independent so the interface >and topLabel from the out-segment table cannot be used to uniquely determine >the destination LSR. I think that you need to look at it from a different perspective. Let me also redraw your diagram and delete LSR D without loss of generallity: |-----C (1.2.3.4) A - [hub] -- Eth1 ---| |-----B (2.3.4.5) Now, if we have a example TFIB at LSR A that looks like: InLabel OutLabel OutIfIndex NextHopIPv4Addr 15 17 10 (Eth1) 1.2.3.4 18 17 10 (Eth1) 1.2.3.4 15 21 10 (Eth1) 1.2.3.4 At LSR A, it might call that interface Eth1 (ifIndex = 10). If a label swapping of (15, 17, ifIndex=10, NextHop=1.2.3.4) occurs, then outSegmentIndex might = 1, and outSegmentIfIndex = 10, outSegmentTopLabel = 17. If another entry is desired which goes to LSR B, say (18,17, ifIndex=10, NextHop=2.3.4.5), then another outSegmentIndex might be created say, 2, with outSegmentIfIndex = 10, outSegmentTopLabel = 17. Both entries are unique, and both indicate that the two different LSPs can come into A, and go out on the same interface under the same label to different peers. You might also be thinking of the case where (15,21, ifIndex=10, 1.2.3.4) too. Again, outSegmentIndex = 122, outSegmentIfIndex = 10, outSegmentTopLabel = 21, NextHopIpV4Addr=1.2.3.4. >Do we need to add a MAC address object to the mplsOutSegmentTable? I don't believe that we need the MAC address. The IPv4/v6NextHopAddr handles where the next hop is located, and the outSegmentIfIndex handles which MPLS-enabled interface the labels will leave "this" LSR at. The thing to keep in mind is that the outSegment Table's index is a plain integer to allow multiple copies of the same outgoing label to be used, either on the same outgoing interface, or even different interfaces. I hope this answers your question. Let me know if it does not. --Tom From owner-mpls@UU.NET Thu Sep 28 09:11:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19353 for ; Thu, 28 Sep 2000 09:11:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipg06385; Thu, 28 Sep 2000 13:11:11 GMT Received: by mail-control.mail.uu.net id QQjipg01206 for mpls-outgoing; Thu, 28 Sep 2000 13:10:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipg01201 for ; Thu, 28 Sep 2000 13:10:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipg19594 for ; Thu, 28 Sep 2000 09:10:31 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQjipg06154 for ; Thu, 28 Sep 2000 13:10:30 GMT Received: from toy.labn.net (labn.net [209.204.240.82]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id IAA18484; Thu, 28 Sep 2000 08:06:22 -0500 Message-Id: <4.3.2.7.2.20000928090711.00b23100@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 09:10:52 -0400 To: AF@dataconnection.com From: Lou Berger Subject: Re: Asymmetrical Bi-directional LSPs Cc: mpls@UU.NET In-Reply-To: <200009280602.XAA21666@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Adrian, I agree with Kireeti on this one. Furthermore, the premiss for this is that the reverse path must be calculated at the sender of the first LSP. Why can't the egress calculate the (possibly asymmetric) path on it's own? Your really asking for two LSPs, why signal them as one? (Even ATM doesn't support this.) Lou At 02:02 AM 9/28/00, Kireeti Kompella wrote: >Hi Adrian, > > > Lou Berger suggested I poll the list to see what interest there is in being > > able to set up asymmetrical bi-directional LSPs without the need for an > > exterior signaling protocol. > >For what it's worth, I neither see the need for this, nor am I >in favour of it. In my (admittedly cynical) view, there is a >perfectly good exterior protocol to do this, namely, telnet :-) > >I do see the need for symmetrical bi-directional LSPs (mostly for >optical and SONET trails) and (reluctantly at first) accepted the >need to extend RSVP for that. > >Kireeti. From owner-mpls@UU.NET Thu Sep 28 10:48:04 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22515 for ; Thu, 28 Sep 2000 10:48:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipn12652; Thu, 28 Sep 2000 14:47:26 GMT Received: by mail-control.mail.uu.net id QQjipn19437 for mpls-outgoing; Thu, 28 Sep 2000 14:46:48 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjipn19432 for ; Thu, 28 Sep 2000 14:46:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipn15001 for ; Thu, 28 Sep 2000 10:46:24 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjipn11937 for ; Thu, 28 Sep 2000 14:46: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 KAA14399 for ; Thu, 28 Sep 2000 10:46:16 -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 KAA18301 for ; Thu, 28 Sep 2000 10:46:18 -0400 (EDT) Message-ID: <39D359D5.40A77038@marconi.com> Date: Thu, 28 Sep 2000 10:46:45 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: mapping to ATM switching Hardware References: <200009280300.XAA28973@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Kainia Cloutier writes: >> >> I'm currently in London, attending the MPLS Next Generation >> Networking conference. I came to this conference with one objective: >> finding out how to map an LSP to specific ATM switching hardware, >> while using RSVP-TE. For the last several weeks, I read RFCs 2205, >> 2210, 2212 and several IETF drafts and still couldn't find one paper >> describing "an edge LSR, sending a path message with these parameters >> set in the ADSPEC and FLOWSPEC object, will receive, from a >> downstream node, an ATM CBR label mapping". (and so on and so forth >> for RT-VBR, NRT-VBR, UBR label mappings). Strangely enough, I haven't been able to locate an RFC or draft that maps IntServ-style QoS specs onto ATM-style. Which does strike me as odd. > QoS is supported with the services defined in the diff-serv WG and to > the extent that diff-serv services such as EF, AF, etc can be mapped > onto ATM you have compatibility with the legacy ATM devices. It is also supported by signalling QoS vis IntServ objects. Each ATM switch that supports IntServ will have to reserve according to these parameters. If the hardware can only make reservations using ATM-style parameters, then some form of mapping will be needed. Although there are a number of RFCs that mention RSVP and ATM together (2379, 2380, 2381 and 2381), a quick scan of their content didn't reveal any standard formulae for converting one style of resource representation to the other. -- David From owner-mpls@UU.NET Thu Sep 28 10:53:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22658 for ; Thu, 28 Sep 2000 10:53:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipn12805; Thu, 28 Sep 2000 14:47:41 GMT Received: by mail-control.mail.uu.net id QQjipn19449 for mpls-outgoing; Thu, 28 Sep 2000 14:47:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipn19444 for ; Thu, 28 Sep 2000 14:47:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipn15114 for ; Thu, 28 Sep 2000 10:46:53 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQjipn11970 for ; Thu, 28 Sep 2000 14:46:22 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with SMTP id KAA26727 for ; Thu, 28 Sep 2000 10:35:22 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256968.00502258 ; Thu, 28 Sep 2000 10:35:16 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256968.00502034.00@notes949.cc.telcordia.com> Date: Thu, 28 Sep 2000 10:35:01 -0400 Subject: RSVP-TE---4.3.1 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, RSVP-TE latest version 4.3.1 Applicability, it says that "The EXPLICIT_ROUTE object is assigned a class value of the form 0bbbbbbb", what is "obbbbbb" meaning? Explicit_route object class is 20, and put into 1 byte field or what? Thanks, Julia From owner-mpls@UU.NET Thu Sep 28 11:06:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22908 for ; Thu, 28 Sep 2000 11:06:36 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipo20961; Thu, 28 Sep 2000 15:06:08 GMT Received: by mail-control.mail.uu.net id QQjipo01775 for mpls-outgoing; Thu, 28 Sep 2000 15:05:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjipo01761 for ; Thu, 28 Sep 2000 15:05:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipo18349 for ; Thu, 28 Sep 2000 11:05:23 -0400 (EDT) Received: from workhorse.fictitious.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjipo20669 for ; Thu, 28 Sep 2000 15:05:20 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA30982; Thu, 28 Sep 2000 11:03:50 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200009281503.LAA30982@workhorse.fictitious.org> To: brunner@ccrle.nec.de cc: Cheenu Srinivasan , "'curtis@avici.com'" , "'mpls@uu.net'" Reply-To: curtis@avici.com Subject: Re: draft-ietf-mpls-ftn-mib-00.txt is now available In-reply-to: Your message of "Thu, 28 Sep 2000 11:48:33 +0200." <39D313F1.1DA20A60@ccrle.nec.de> Date: Thu, 28 Sep 2000 11:03:50 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <39D313F1.1DA20A60@ccrle.nec.de>, Marcus Brunner writes: > > > > Cheenu Srinivasan wrote: > > > > Curtis, > > > > Curtis Villamizar wrote: > > > > > > The DSCP, or more correctly a 64 bit DSCP mask, with one bit per > > > possible DSCP value should be part of the FEC. Other > > implementations > > > (will) allow different DSCP values for the same IP prefix to be > > routed > > > onto different LSP. Where all DSCP values map into a single LSP, > > then > > > the mask is all ones. (The MIB should not be constrained to match a > > > > > specific vendors implementation limitations.) There is no way to > > > apply different setup and holding priorities, different adaptivity > > > parameters, and local protect to some DSCP values and not to other > > > DSCP values without this capability. > > > > We can put in mapping of DSCP values to LSPs/Tunnels if this group > > thinks its needed. What this MIB is not meant to do is DSCP remapping > > which should be done in the diffserv MIB. > > Sure not. It really is just meant as an additional FEC descriptor > without any additional action behind. > > Marcus This is not DSCP remapping. It is mapping DSCP onto separate LSPs. The diffserv MIB does not cover that capability. Curtis From owner-mpls@UU.NET Thu Sep 28 11:10:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23027 for ; Thu, 28 Sep 2000 11:10:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipo22314; Thu, 28 Sep 2000 15:09:21 GMT Received: by mail-control.mail.uu.net id QQjipo02073 for mpls-outgoing; Thu, 28 Sep 2000 15:08:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjipo02052 for ; Thu, 28 Sep 2000 15:08:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipo18903 for ; Thu, 28 Sep 2000 11:08:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjipo23623 for ; Thu, 28 Sep 2000 15:08:32 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 LAA16639 for ; Thu, 28 Sep 2000 11:08:25 -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 LAA25561 for ; Thu, 28 Sep 2000 11:08:27 -0400 (EDT) Message-ID: <39D35F09.9CA2E9FB@marconi.com> Date: Thu, 28 Sep 2000 11:08:57 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "mpls@uu.net" Subject: Re: RSVP-TE--RRO References: <01C02937.63DC5CA0.arumugamr@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Arumugam R wrote: > > How can a single Resv message used for reserving multiple senders?. Please reread RFC 2205. It's explained in great detail. > In Rsvp-Lsp point of view, the TE tunnel should be an unique one in > the entire domain. And if every sender specifies a different session, this is exactly what you'll get. But RSVP also allows multiple senders to send to the same session. A receiver that gets Path messages from two different senders in the same session, it may send out a single Resv message for both of them. Remember: A session only specifies an endpoint (egress router, tunnel ID, and extended tunnel ID). And there can be multiple senders can be on the same ingress router (differentiated by the LSP ID). > Since the draft does not deal with multicasting applications, the > above following discussion holds good only for SE style( that too > during rerouting ) and not for FF style. Multiple senders in one session can and will happen for a short time during a make-before-break operation. It can also happen during some kinds of failures. During this time, when there are more than one sender for a single session, the next-hop routers can (and probably should) send out a single Resv message for all the senders in the session. -- David From owner-mpls@UU.NET Thu Sep 28 11:12:18 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23074 for ; Thu, 28 Sep 2000 11:12:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipo25548; Thu, 28 Sep 2000 15:11:49 GMT Received: by mail-control.mail.uu.net id QQjipo02307 for mpls-outgoing; Thu, 28 Sep 2000 15:11:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjipo02299 for ; Thu, 28 Sep 2000 15:11:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipo19352 for ; Thu, 28 Sep 2000 11:11:11 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQjipo23075 for ; Thu, 28 Sep 2000 15:10:56 GMT Received: from toy.labn.net (labn.net [209.204.240.82]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id KAA20236; Thu, 28 Sep 2000 10:06:47 -0500 Message-Id: <4.3.2.7.2.20000928111041.00d31f00@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 11:11:21 -0400 To: David Charlap From: Lou Berger Subject: Re: mapping to ATM switching Hardware Cc: mpls@UU.NET In-Reply-To: <39D359D5.40A77038@marconi.com> References: <200009280300.XAA28973@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk see rfc2381... At 10:46 AM 9/28/00, David Charlap wrote: >Curtis Villamizar wrote: > > Kainia Cloutier writes: > >> > >> I'm currently in London, attending the MPLS Next Generation > >> Networking conference. I came to this conference with one objective: > >> finding out how to map an LSP to specific ATM switching hardware, > >> while using RSVP-TE. For the last several weeks, I read RFCs 2205, > >> 2210, 2212 and several IETF drafts and still couldn't find one paper > >> describing "an edge LSR, sending a path message with these parameters > >> set in the ADSPEC and FLOWSPEC object, will receive, from a > >> downstream node, an ATM CBR label mapping". (and so on and so forth > >> for RT-VBR, NRT-VBR, UBR label mappings). > >Strangely enough, I haven't been able to locate an RFC or draft that >maps IntServ-style QoS specs onto ATM-style. Which does strike me as >odd. > > > QoS is supported with the services defined in the diff-serv WG and to > > the extent that diff-serv services such as EF, AF, etc can be mapped > > onto ATM you have compatibility with the legacy ATM devices. > >It is also supported by signalling QoS vis IntServ objects. Each ATM >switch that supports IntServ will have to reserve according to these >parameters. If the hardware can only make reservations using ATM-style >parameters, then some form of mapping will be needed. > >Although there are a number of RFCs that mention RSVP and ATM together >(2379, 2380, 2381 and 2381), a quick scan of their content didn't reveal >any standard formulae for converting one style of resource >representation to the other. > >-- David From owner-mpls@UU.NET Thu Sep 28 11:55:48 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24497 for ; Thu, 28 Sep 2000 11:55:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipr14329; Thu, 28 Sep 2000 15:55:08 GMT Received: by mail-control.mail.uu.net id QQjipr05897 for mpls-outgoing; Thu, 28 Sep 2000 15:54:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjipr05890 for ; Thu, 28 Sep 2000 15:54:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipr14861 for ; Thu, 28 Sep 2000 11:54:00 -0400 (EDT) Received: from fsnt.future.futsoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjipr13678 for ; Thu, 28 Sep 2000 15:53:41 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 28 Sep 2000 21:25:28 +0530 Received: from arumugamr (arumugamr.future.futsoft.com [10.0.6.51]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id VAA27733; Thu, 28 Sep 2000 21:11:51 +0530 Received: by localhost with Microsoft MAPI; Thu, 28 Sep 2000 21:20:06 +0530 Message-Id: <01C02991.DF81DB00.arumugamr@future.futsoft.com> From: Arumugam R Reply-To: "arumugamr@future.futsoft.com" To: "'David Charlap'" , "mpls@uu.net" Subject: RE: RSVP-TE--RRO Date: Thu, 28 Sep 2000 21:20:05 +0530 Organization: FSL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the comments. Also added the inline comments. -----Original Message----- From: David Charlap [SMTP:david.charlap@marconi.com] Sent: Thursday, September 28, 2000 8:39 PM To: mpls@uu.net Subject: Re: RSVP-TE--RRO Arumugam R wrote: > > How can a single Resv message used for reserving multiple senders?. Please reread RFC 2205. It's explained in great detail. > In Rsvp-Lsp point of view, the TE tunnel should be an unique one in > the entire domain. And if every sender specifies a different session, this is exactly what you'll get. But RSVP also allows multiple senders to send to the same session. A receiver that gets Path messages from two different senders in the same session, it may send out a single Resv message for both of them. Remember: A session only specifies an endpoint (egress router, tunnel ID, and extended tunnel ID). And there can be multiple senders can be on the same ingress router (differentiated by the LSP ID) [$$] If the Same Ingress Router (Behaving Like multiple senders) establishes multiple Sessions ( TE tunnels) with the Egress Router, then all the sessions will be having different Tunnel Id isn't. Between Ingress and Egress there can be a number of tunnels established based on policy considerations, depending on the traffic parameters required for each of them. But each tunnel should have an unique reservation along all the nodes between the Ingress and Egress, which can be achieved only by an unique Tunnel Id. Only during the reroute condition the Ingress of tunnel assigns a different LSP-ID for avoiding double counting of resources. All other occasions the nodes maintain reservations only based on the unique Tunnel Id, Egress Address pair I suppose. Please correct me if I am wrong. . > Since the draft does not deal with multicasting applications, the > above following discussion holds good only for SE style( that too > during rerouting ) and not for FF style. Multiple senders in one session can and will happen for a short time during a make-before-break operation. It can also happen during some kinds of failures. During this time, when there are more than one sender for a single session, the next-hop routers can (and probably should) send out a single Resv message for all the senders in the session. -- David From owner-mpls@UU.NET Thu Sep 28 11:57:30 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24568 for ; Thu, 28 Sep 2000 11:57:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipr15791; Thu, 28 Sep 2000 15:57:20 GMT Received: by mail-control.mail.uu.net id QQjipr06109 for mpls-outgoing; Thu, 28 Sep 2000 15:56:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipr06099 for ; Thu, 28 Sep 2000 15:56:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipr26698 for ; Thu, 28 Sep 2000 11:56:23 -0400 (EDT) Received: from workhorse.fictitious.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjipr14520 for ; Thu, 28 Sep 2000 15:55:50 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA31217; Thu, 28 Sep 2000 11:54:23 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200009281554.LAA31217@workhorse.fictitious.org> To: Fred Baker cc: Martin Picard , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Any SPs using QoS ??? In-reply-to: Your message of "Thu, 28 Sep 2000 08:44:05 +0200." <5.0.0.25.2.20000928083919.02f81ae0@flipper> Date: Thu, 28 Sep 2000 11:54:23 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.0.0.25.2.20000928083919.02f81ae0@flipper>, Fred Baker writes: > At 03:00 PM 9/26/00 -0400, Martin Picard wrote: > > Service Providers tend to say that their backbone will never be > > congested and if it ever gets there, then, bandwidth will be increased > > and therefore no Congestion Management or Congestion Avoidance > > mechanisms are necessary. Thats clearly what the ISP marketing people have to say. The engineers have to deal with reality and some still assert that timely delivery of bandwidth is not reality and an infinite budgest doesn't make good business sense. The engineers therefore have to design for the possibility (which some still assert is inevitable) that congestion will occur at times in various parts of the network. If increase in access speeds outpace core deployment that includes in the core. The network also needs to degrade gracefully when massive outage occurs. A few examples in the past 5 or so years (from memory) include earthquake in southern CA, CO fire in the Bay area, gas leak (power everything down) in LA area, floods in the mid-west, Amtrak wreck affecting both sides of track on East, gas company tearing up wrong pipe (major fiber conduit), and a hurricanes in the East affecting riverbed fiber, numerous smaller hurricane outages. I'm not in operations so this is just a very small subset covering only very big outages. The network can't just work well on sunny days. Congestion avoidance is needed. Curtis From owner-mpls@UU.NET Thu Sep 28 12:03:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24715 for ; Thu, 28 Sep 2000 12:03:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjips18720; Thu, 28 Sep 2000 16:02:31 GMT Received: by mail-control.mail.uu.net id QQjips09657 for mpls-outgoing; Thu, 28 Sep 2000 16:02:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjips09529 for ; Thu, 28 Sep 2000 16:01:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjips16054 for ; Thu, 28 Sep 2000 12:01:48 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjips18240 for ; Thu, 28 Sep 2000 16:01:48 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e8SG1l414893; Thu, 28 Sep 2000 12:01:48 -0400 (EDT) Message-Id: <200009281601.e8SG1l414893@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: mpls@UU.NET, Adrian Farrel Subject: Re: Multi-LSP Notify in GMPLS In-reply-to: Your message of "Wed, 27 Sep 2000 22:40:23 BST." <6DEA508A9A0ED31192E80000F6CC176E2CA2DF@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 12:01:47 -0400 Sender: owner-mpls@UU.NET Precedence: bulk Adrian, it seems to me the invention of the Notify message in GMPLS was not such a great idea. It's only purpose is to reduce the latency of error message delivery back to the LSP ingress. So instead of the slow path forwarding of the PathErr message by the router software you now get fast path forwarding of the Notify message by the router hardware. Does this gain justify the circumvention of RSVP's authentication mechanism (RFC 2747)? RSVP security is based on message authentication between neighbors but the Notify message is not send hop-by-hop through neighboring routers that are configured to trust each other. You now also point this out in your rewrite of section 5.1.1. There is also no discussion of backwards compatibility. In your modified version of section 5, you write: The Notify message does not replace existing error messages, but may initially be sent instead of existing error messages where the intent is that the Notify recipient should take remedial action before the network has recourse to the normal error processing. Because the Notify message is sent instead of a regular PathErr message, a node that receives the Notify but does not support it will not get any error indication from RSVP signalling at all! I suggest to remove the Notify message from the GMPLS draft. If not, the "Security Considerations" section needs to be updated: the Notify message *does* introduce new security issues. Markus From owner-mpls@UU.NET Thu Sep 28 12:12:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25095 for ; Thu, 28 Sep 2000 12:12:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjips22236; Thu, 28 Sep 2000 16:11:57 GMT Received: by mail-control.mail.uu.net id QQjips19075 for mpls-outgoing; Thu, 28 Sep 2000 16:11:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjips19064 for ; Thu, 28 Sep 2000 16:11:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjips28904 for ; Thu, 28 Sep 2000 12:11:10 -0400 (EDT) Received: from workhorse.fictitious.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjips21129 for ; Thu, 28 Sep 2000 16:11:09 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA31291; Thu, 28 Sep 2000 12:09:41 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200009281609.MAA31291@workhorse.fictitious.org> To: "Ronaldo Moreira Salles" cc: "Jay Wang" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: QoS or not QoS; RE: B/W vs QoS Re: Any SPs using QoS ??? In-reply-to: Your message of "Thu, 28 Sep 2000 08:27:16 BST." <006101c0291d$878b0800$0787c69b@ee.ic.ac.uk> Date: Thu, 28 Sep 2000 12:09:41 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <006101c0291d$878b0800$0787c69b@ee.ic.ac.uk>, "Ronaldo Moreira Salle s" writes: > This is a multi-part message in MIME format. > > ------=_NextPart_000_005E_01C02925.E92DDE40 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > QoS or not QoS; RE: B/W vs QoS Re: Any SPs using QoS ???I agree, but how = > can you support your arguments given the following technical analysis: > > http://www.statslab.cam.ac.uk/~frank/TALKS/RoySoc99/sld009.htm > > Cheers, > Ronaldo. Last mile access goes from 56kB to 2MB and penetration doubles and you have 2 orders of magnitude increase in backbone load. High end backbones currently use multiple OC48 or a few single OC192. Increase that by 2 orders of magnitude and then look at cost of doing so. What do people do with it? Watch the olympics. Graphics resolution gets higher. More audio and video on web pages. Better audio quality, higher video resolution and longer running. Point to point audio. And any new apps that come along. Etc. Providing all this BW costs money so whoever can do it most efficiently (multiplexing gain, TE, and congestion avoidance DOES matter) makes the most profit and others make less profit (and therefore have less capital to grow with) or lose money and go away. Curtis ps - I think we've beat this to death so can we please go back to discussing MPLS. From owner-mpls@UU.NET Thu Sep 28 12:24:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25477 for ; Thu, 28 Sep 2000 12:24:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipt03047; Thu, 28 Sep 2000 16:24:05 GMT Received: by mail-control.mail.uu.net id QQjipt20353 for mpls-outgoing; Thu, 28 Sep 2000 16:23:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipt20335 for ; Thu, 28 Sep 2000 16:23:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipt20621 for ; Thu, 28 Sep 2000 12:20:23 -0400 (EDT) Received: from dnsmx1pya.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQjipt29842 for ; Thu, 28 Sep 2000 16:20:18 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id MAA11341 for ; Thu, 28 Sep 2000 12:11:55 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256968.0058F968 ; Thu, 28 Sep 2000 12:11:50 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256968.0058F83E.00@notes949.cc.telcordia.com> Date: Thu, 28 Sep 2000 12:11:35 -0400 Subject: RSVP-TE --RRO Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, On RSVP-TE page 33, 4.4.1.1, Flags field, 01: Local protection available, it says that "This flag can only be set if the Local protection flag was set in the SESSION_ATTRIBUTE object of the corresponding Path message". Q: Suppose there is path message with RRO, but no SESSION_ATTRIBUTE object since it is optional in Path message, can this Flags field be set to 0x01(Local protection available). Thanks in advance. Julia From owner-mpls@UU.NET Thu Sep 28 12:26:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25515 for ; Thu, 28 Sep 2000 12:26:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipt03000; Thu, 28 Sep 2000 16:25:50 GMT Received: by mail-control.mail.uu.net id QQjipt20485 for mpls-outgoing; Thu, 28 Sep 2000 16:25:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjipt20477 for ; Thu, 28 Sep 2000 16:25:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipt21449 for ; Thu, 28 Sep 2000 12:23:23 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjipt00807 for ; Thu, 28 Sep 2000 16:23:22 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA19930 for ; Thu, 28 Sep 2000 09:23:23 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA05046 for mpls@uu.net; Thu, 28 Sep 2000 12:23:21 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjioq00713 for ; Thu, 28 Sep 2000 09:03:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjioq28827 for ; Thu, 28 Sep 2000 05:03:05 -0400 (EDT) Received: from alberich.cis.rl.ac.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alberich.cis.rl.ac.uk [130.246.75.145]) id QQjioq15105 for ; Thu, 28 Sep 2000 09:02:50 GMT Received: from rl.ac.uk (loge.cis.rl.ac.uk [130.246.75.92]) by alberich.cis.rl.ac.uk (8.9.3/8.9.3) with ESMTP id KAA23535; Thu, 28 Sep 2000 10:04:54 +0100 (BST) Message-ID: <39D308A7.6FBCDF0F@rl.ac.uk> Date: Thu, 28 Sep 2000 10:00:23 +0100 From: Chris Cooper Organization: CLRC at RAL X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: Martin Picard , mpls@UU.NET Subject: Re: Any SPs using QoS ??? References: <5.0.0.25.2.20000928083919.02f81ae0@flipper> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Fred Baker wrote: > > At 03:00 PM 9/26/00 -0400, Martin Picard wrote: > > Service Providers tend to say that their backbone will never be > > congested and if it ever gets there, then, bandwidth will be increased > > and therefore no Congestion Management or Congestion Avoidance > > mechanisms are necessary. > > I know of a number of service providers, including BT etc, who are > deploying services using QoS technologies. Whether or not the specific ones > I am talking with are using MPLS in the same application, I can't say; I > don't know, and I think some are and some aren't. > > The above statement is indeed what most of the SPs say, but it misses a > rather important fact. They are engineering their core to have enough > bandwidth that they experience a low drop rate. That means that QoS > perceived by their customers is not limited by their core. But it remains > limited by the link between the edge network and the SP, which is supplied > by the customer, and the delay and drop rates at the service provider end > of that link are invisible to him. As often as not, it is specifically this > link that will benefit from QoS technologies. Yes, exactly. I also have encountered this sort of assertion recently from SPs. But the basic issues seem not to have changed: see for example the summary of the infinite bandwidth argument provided in RFC1633 by Bob Braden, Dave Clark, and Scott Shenker in 1994. Chris ------------------------------------------------------------------- Chris Cooper Email: chris.cooper@rl.ac.uk Rutherford Appleton Laboratory Tel: +44 (0)1235 446211 Chilton Fax: +44 (0)1235 445597 (NB.NEW) Didcot, Oxon OX11 0QX, UK From owner-mpls@UU.NET Thu Sep 28 12:27:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25540 for ; Thu, 28 Sep 2000 12:27:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipt04455; Thu, 28 Sep 2000 16:26:57 GMT Received: by mail-control.mail.uu.net id QQjipt20563 for mpls-outgoing; Thu, 28 Sep 2000 16:26:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipt20544 for ; Thu, 28 Sep 2000 16:26:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipt03565 for ; Thu, 28 Sep 2000 12:23:58 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjipt02525 for ; Thu, 28 Sep 2000 16:23:42 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA25463 for ; Thu, 28 Sep 2000 09:24:06 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA05050 for mpls@uu.net; Thu, 28 Sep 2000 12:23:41 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjipt19926 for ; Thu, 28 Sep 2000 16:18:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipt20049 for ; Thu, 28 Sep 2000 12:18:03 -0400 (EDT) From: jeanlou.dupont@marconi.com Received: from notes.relteccorp.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [208.43.60.82]) id QQjipt28167 for ; Thu, 28 Sep 2000 16:18:02 GMT Received: by notes.relteccorp.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256968.00592455 ; Thu, 28 Sep 2000 12:13:40 -0400 X-Lotus-FromDomain: MCMAIN@MCEXT To: mpls@UU.NET Message-ID: <85256968.005914DC.00@notes.relteccorp.com> Date: Thu, 28 Sep 2000 12:14:08 -0400 Subject: Resource objects. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi all; Quick question: Could somebody tell me the relationship between the following tables: 1) "mplsTunnelResourceTable" in ; 2) "mplsTrafficParamTable" in . thanks. --- Jean-Lou Dupont jeanlou.dupont@marconi.com From owner-mpls@UU.NET Thu Sep 28 12:27:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25568 for ; Thu, 28 Sep 2000 12:27:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipt07444; Thu, 28 Sep 2000 16:27:02 GMT Received: by mail-control.mail.uu.net id QQjipt20568 for mpls-outgoing; Thu, 28 Sep 2000 16:26:30 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipt20545 for ; Thu, 28 Sep 2000 16:26:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipt03253 for ; Thu, 28 Sep 2000 12:23:05 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjipt00232 for ; Thu, 28 Sep 2000 16:22:35 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA19240 for ; Thu, 28 Sep 2000 09:22:35 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA05041 for mpls@uu.net; Thu, 28 Sep 2000 12:22:33 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjiof18815 for ; Thu, 28 Sep 2000 06:27:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiof16132 for ; Thu, 28 Sep 2000 02:27:41 -0400 (EDT) Received: from tid.tid.es by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tidos.tid.es [193.145.240.2]) id QQjiof16731 for ; Thu, 28 Sep 2000 06:26:54 GMT Received: from idecnet.com ([1.0.15.175]) by tid.tid.es (Netscape Messaging Server 4.15) with ESMTP id G1L37R00.J9L for ; Thu, 28 Sep 2000 08:26:15 +0200 Message-ID: <39D2E493.DD05F9C3@idecnet.com> Date: Thu, 28 Sep 2000 07:26:27 +0100 From: Michel Redondo Ferrero X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS/BGP routing question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Considering the next scenario: -Core and Border routers running IS-IS, MPLS -VPNs configured in Border routers using BGP/MPLS -Border routers running BGP with full-routing The question: Do Core routers need to run BGP? Is IS-IS enough? Thanks in advance for your answers. Michel Redondo Ferrero From owner-mpls@UU.NET Thu Sep 28 12:29:31 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25618 for ; Thu, 28 Sep 2000 12:29:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipt06144; Thu, 28 Sep 2000 16:29:00 GMT Received: by mail-control.mail.uu.net id QQjipt20778 for mpls-outgoing; Thu, 28 Sep 2000 16:28:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipt20754 for ; Thu, 28 Sep 2000 16:28:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipt22558 for ; Thu, 28 Sep 2000 12:26:13 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQjipt03177 for ; Thu, 28 Sep 2000 16:25:57 GMT Received: from toy.labn.net (labn.net [209.204.240.82]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id LAA08888; Thu, 28 Sep 2000 11:21:40 -0500 Message-Id: <4.3.2.7.2.20000928121657.00dac900@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 12:26:10 -0400 To: Markus Jork From: Lou Berger Subject: Re: Multi-LSP Notify in GMPLS Cc: mpls@UU.NET, Adrian Farrel In-Reply-To: <200009281601.e8SG1l414893@mailhost.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk See below. At 12:01 PM 9/28/00, Markus Jork wrote: >Adrian, > >it seems to me the invention of the Notify message in GMPLS was not >such a great idea. It's only purpose is to reduce the latency of >error message delivery back to the LSP ingress. So instead of the >slow path forwarding of the PathErr message by the router software >you now get fast path forwarding of the Notify message by the router >hardware. >Does this gain justify the circumvention of RSVP's authentication >mechanism (RFC 2747)? RSVP security is based on message authentication >between neighbors but the Notify message is not send hop-by-hop >through neighboring routers that are configured to trust each other. >You now also point this out in your rewrite of section 5.1.1. > >There is also no discussion of backwards compatibility. >In your modified version of section 5, you write: > > The Notify message does not replace existing error messages, but may > initially be sent instead of existing error messages where the intent > is that the Notify recipient should take remedial action before the > network has recourse to the normal error processing. > >Because the Notify message is sent instead of a regular PathErr >message, a node that receives the Notify but does not support it >will not get any error indication from RSVP signalling at all! I think it's worth pointing out that Adrian's version differs from the most recent draft, which says "The Notify message does not replace existing error messages. " I think any attempt to replace base RSVP messages with a notify would be misguided. I don't know if this is what Adrian meant to imply. (Although this is one reading of the his text.) >I suggest to remove the Notify message from the GMPLS draft. This would be fine with me particularly since a PathErr message doesn't modify state. (I'm sure some of my co-authors will disagree with me on dropping it.) Lou >If not, the "Security Considerations" section needs to be updated: >the Notify message *does* introduce new security issues. > >Markus From owner-mpls@UU.NET Thu Sep 28 12:29:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25629 for ; Thu, 28 Sep 2000 12:29:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipt05571; Thu, 28 Sep 2000 16:28:14 GMT Received: by mail-control.mail.uu.net id QQjipt20677 for mpls-outgoing; Thu, 28 Sep 2000 16:27:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipt20639 for ; Thu, 28 Sep 2000 16:27:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipt22387 for ; Thu, 28 Sep 2000 12:25:45 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjipt05670 for ; Thu, 28 Sep 2000 16:25:32 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 MAA24070 for ; Thu, 28 Sep 2000 12:25:29 -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 MAA20423 for ; Thu, 28 Sep 2000 12:25:31 -0400 (EDT) Message-ID: <39D37119.54911F1D@marconi.com> Date: Thu, 28 Sep 2000 12:26:01 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "mpls@uu.net" Subject: Re: RSVP-TE--RRO References: <01C02991.DF81DB00.arumugamr@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Arumugam R wrote: > > [$$] If the Same Ingress Router (Behaving Like multiple senders) > establishes multiple Sessions ( TE tunnels) with the Egress Router, > then all the sessions will be having different Tunnel Id isn't. Correct. Under normal conditions, every LSP will be using a separate session. > Between Ingress and Egress there can be a number of tunnels > established based on policy considerations, depending on the traffic > parameters required for each of them. But each tunnel should have an > unique reservation along all the nodes between the Ingress and Egress, > which can be achieved only by an unique Tunnel Id. Unique tunnel ID and extended tunnel ID. Otherwise, it is hard to prevent two different ingress routers from choosing the same tunnel ID. Another possibility, which is not as good, is to let all the LSPs remain in the same session (same tunnel ID and extended tunnel ID), and make FF-style reservations. But this should not be attempted, because an ingress router can not force the egress router to choose a particular reservation style. (I only mention the second possibility to point out that unique non-shared reservations don't _have_ to be achieved through multiple sessions, although that is the best way to do it.) > Only during the reroute condition the Ingress of tunnel assigns a > different LSP-ID for avoiding double counting of resources. It's not to avoid double-counting. It's to prevent the LSP from going down during a reroute. Make-before-break can't work if the LSP ID doesn't change. Transit routers will end up applying the PathTear message to the new route instead of to the old one. If the ingress router simly changes the ERO without doing make-before- break at all, similar problems will arise. Routers that are no longer on this LSP's route will eventually timeout and send PathTear messages downstream - which will cause the LSP (on its new route) to get torn from the point where the two routes merge to the egress router. > All other occasions the nodes maintain reservations only based on the > unique Tunnel Id, Egress Address pair I suppose. > Please correct me if I am wrong. This is the expectation. I don't think it would violate the MPLS drafts if two senders would deliberately try to establish paths in the same session (perhaps by using the all-zeros value of extended tunnel ID). If the egress router uses FF-style reservation, or if the reservation is for best-effort, or if the ingress routers don't care about sharing resources with each other, then everything should operate normally. Note that this is not really multicast. Multiple unicast LSPs are still being established, and each one still gets its own labels. The only difference between this and multiple sessions (from the data-plane perspective) is if SE-style reservations are used - in which case, resources will be shared between these LSPs wherever they have links in common. The main reason that this scenario probably won't be used by anybody is because resource sharing between LSPs (outside of make-before-break) is not something peole want. And SE style reservations are going to be used, in order to facilitate efficient make-before-break handling. -- David From owner-mpls@UU.NET Thu Sep 28 12:30:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25685 for ; Thu, 28 Sep 2000 12:30:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipt09695; Thu, 28 Sep 2000 16:29:58 GMT Received: by mail-control.mail.uu.net id QQjipt20803 for mpls-outgoing; Thu, 28 Sep 2000 16:29:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipt20798 for ; Thu, 28 Sep 2000 16:29:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipt22967 for ; Thu, 28 Sep 2000 12:27:07 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjipt07201 for ; Thu, 28 Sep 2000 16:26:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA26902 for mpls@uu.net; Thu, 28 Sep 2000 12:26:51 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipt20553 for ; Thu, 28 Sep 2000 16:26:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipt03696 for ; Thu, 28 Sep 2000 12:24:20 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjipt01040 for ; Thu, 28 Sep 2000 16:23:48 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA25486; Thu, 28 Sep 2000 09:22:46 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 09:27:11 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E6E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'David Charlap'" , mpls@UU.NET Cc: rsvp@ISI.EDU, int-serv@ISI.EDU Subject: RE: CR-LDP traffic parameter TLV and RSVP Date: Thu, 28 Sep 2000 09:27:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Tuesday, September 26, 2000 2:29 PM > To: mpls@UU.NET > Cc: rsvp@ISI.EDU; int-serv@ISI.EDU > Subject: Re: CR-LDP traffic parameter TLV and RSVP > > > CATANZARITI Sergio FTR&D/TI wrote: > > > > I would like to be back to my original question. That was how I will > > map, in a semantically compatible way, the COS-type values of > > Tspec/FlowSpec with the DS classes. Okay, assuming that I have clear > > the first case, mapping DS classes in the IntServ service types, (of > > course it is a joke... this presumption of understanding), for the > > second case, how to map COS-type values to DS classes, > > You really can't. There is no defined meaning for COS-type > values other > than zero (best effort). Any other value may be ignored, rejected, or > handled in a way you don't want. > Yes off course you can. You could map any COS-Type to a local (non-standard) DSCP value. > It's really not a good idea to use non-zero values for the COS-type, > unless you know precisely what your switch's implementation > will do with > it. > > > I do not think that it is a customization/local > configuration choice. > > Indeed, the draft (dratf-ietf-mpls-diff-ext-07.txt) says... > > > > Paragraph 5.6 > > When processing a path (respectively Resv) message for an E-LSP or > > an L-LSP using the COS service, a Diff-Serv capable LSR must ignore > > the value of the COS field within a COS SENDER_TSPEC (respectively a > > COS FLOWSPEC). > > Recognizing the fact that no classes other than zero have any standard > definition. > > > So, I guess that, when we (Diff Serv Routers) process RSVP/PATH > > messages with COS-type TSpec/FlowSpec for (L or E type) > LSPs carrying > > DS class trunks, the choice on how to implement service > treatments is > > not given by COS values but EXP and/or label value. So, I > do not worry > > about values mapping at all. > > Sounds right to me. > > -- David > From owner-mpls@UU.NET Thu Sep 28 12:34:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25840 for ; Thu, 28 Sep 2000 12:34:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipu08635; Thu, 28 Sep 2000 16:33:46 GMT Received: by mail-control.mail.uu.net id QQjipu21475 for mpls-outgoing; Thu, 28 Sep 2000 16:33:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjipu21461 for ; Thu, 28 Sep 2000 16:33:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipu06153 for ; Thu, 28 Sep 2000 12:30:53 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjipu10536 for ; Thu, 28 Sep 2000 16:30:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA28154 for mpls@uu.net; Thu, 28 Sep 2000 12:30:51 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjipu21076 for ; Thu, 28 Sep 2000 16:30:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipt23479 for ; Thu, 28 Sep 2000 12:28:31 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjipt05833 for ; Thu, 28 Sep 2000 16:28:31 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA26542; Thu, 28 Sep 2000 09:28:29 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 09:32:54 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E6F@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'David Charlap'" , mpls@UU.NET Cc: rsvp@ISI.EDU, int-serv@ISI.EDU Subject: RE: CR-LDP traffic parameter TLV and RSVP Date: Thu, 28 Sep 2000 09:32:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Tuesday, September 26, 2000 10:34 AM > To: mpls@UU.NET > Cc: rsvp@ISI.EDU; int-serv@ISI.EDU > Subject: Re: CR-LDP traffic parameter TLV and RSVP > > > Curtis Villamizar wrote: > > David Charlap writes: > >> > >> (And if you want to only use one LSP per DiffServ class, then you > >> don't have to signal the class at all - you can just > signal QoS for a > >> bunch of LSPs and let the edge routers do all the DiffServ work.) > > > > This is a unique idea. How does the router at the edge do WFQ or > > implement the three drop preferences for an AF class? :-) > > It doesn't. It picks IntServ parameters that approximate the > QoS level > required for each DS class and uses them when signalling the tunnels. > If the LSPs are signalled using the COS-type of TSpec and > FlowSpec, then > the switches in the cloud will have to have some sort of > agreement about > what the non-zero classes are supposed to mean. > > All the edge router does on the data plane is use the DS bits to pick > which tunnel to forward the traffic into. If the tunnels > have different > QoS or priority levels, then the different DS classes will end up with > those levels as well. It seems that you are mapping Diffserv PHBs to Intserv classes. In other words you want an Intserv network to behave like a PHB. This seems odd to me, and probably of no real world use. > > In this setup, the MPLS cloud is not actually using DS at all - it's > simply mapping the DS classes onto tunnels have their own > QoS/COS levels > that are signalled independantly of any DS signalling. > > -- David > From owner-mpls@UU.NET Thu Sep 28 12:42:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26096 for ; Thu, 28 Sep 2000 12:42:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipu18042; Thu, 28 Sep 2000 16:42:11 GMT Received: by mail-control.mail.uu.net id QQjipu21999 for mpls-outgoing; Thu, 28 Sep 2000 16:41:40 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipu21993 for ; Thu, 28 Sep 2000 16:41:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipu08807 for ; Thu, 28 Sep 2000 12:40:59 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjipu17572 for ; Thu, 28 Sep 2000 16:40: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 MAA25542; Thu, 28 Sep 2000 12:40:21 -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 MAA24526; Thu, 28 Sep 2000 12:40:23 -0400 (EDT) Message-ID: <39D37495.FAF7A0A@marconi.com> Date: Thu, 28 Sep 2000 12:40:53 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET CC: rsvp@ISI.EDU, int-serv@ISI.EDU Subject: Re: CR-LDP traffic parameter TLV and RSVP References: <64DC8FA90382D411BA060090277AEE41774E6E@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > David Charlap wrote: >> >> You really can't. There is no defined meaning for COS-type >> values other than zero (best effort). Any other value may be >> ignored, rejected, or handled in a way you don't want. > > Yes off course you can. You could map any COS-Type to a local > (non-standard) DSCP value. And ensure that every router along the LSP accepts the non-zero COS-type and handles it in the intended way. A human administrator may be able to make that guarantee, but there's no way switch software can do so on its own. In other words, any use of these COS-types to map DS classes would have to be through explicit administrative control. Such mappings can not be made automatically, because successful implementation requres meta-knowledge of how the entire cloud will support this non-standard feature. (Of course, a new draft may come along to solve this problem, if people really care. But that changes the problem - after approval of such a draft, use of the COS-type would no longer be non-standard.) -- David From owner-mpls@UU.NET Thu Sep 28 12:53:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26331 for ; Thu, 28 Sep 2000 12:53:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipv18696; Thu, 28 Sep 2000 16:53:39 GMT Received: by mail-control.mail.uu.net id QQjipv22666 for mpls-outgoing; Thu, 28 Sep 2000 16:53:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipv22659 for ; Thu, 28 Sep 2000 16:52:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipv28434 for ; Thu, 28 Sep 2000 12:52:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjipv22117 for ; Thu, 28 Sep 2000 16:52:08 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 MAA26449; Thu, 28 Sep 2000 12:50:45 -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 MAA26996; Thu, 28 Sep 2000 12:50:48 -0400 (EDT) Message-ID: <39D37706.579FCDBD@marconi.com> Date: Thu, 28 Sep 2000 12:51:18 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET CC: rsvp@ISI.EDU, int-serv@ISI.EDU Subject: Re: CR-LDP traffic parameter TLV and RSVP References: <64DC8FA90382D411BA060090277AEE41774E6F@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > It seems that you are mapping Diffserv PHBs to Intserv classes. In > other words you want an Intserv network to behave like a PHB. This > seems odd to me, and probably of no real world use. I didn't say what I'm doing. And I didn't say what I want. I merely mentioned another possible way of using DS and MPLS together. A way that I had already previously stated was not optimal, compared to the current draft. Somone else then asked a question, which I answered. -- David From owner-mpls@UU.NET Thu Sep 28 13:09:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26757 for ; Thu, 28 Sep 2000 13:09:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipw28919; Thu, 28 Sep 2000 17:09:17 GMT Received: by mail-control.mail.uu.net id QQjipw04976 for mpls-outgoing; Thu, 28 Sep 2000 17:08:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipw04961 for ; Thu, 28 Sep 2000 17:08:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipw13000 for ; Thu, 28 Sep 2000 13:08:24 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQjipw24877 for ; Thu, 28 Sep 2000 17:08:23 GMT Received: by LUX with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 10:08:23 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CEC9E@LUX> From: Jonathan Lang To: "'Lou Berger'" , Markus Jork Cc: mpls@UU.NET, Adrian Farrel Subject: RE: Multi-LSP Notify in GMPLS Date: Thu, 28 Sep 2000 10:08:22 -0700 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 Lou, You are correct that you don't have agreement with your co-authors on removing the Notify. The Notify message is a new general notification procedure that is NOT restricted to be sent to a source/destination node and should not be processed by intermediate nodes. These features are desirable for restoration/protection among other things. Thanks, Jonathan > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, September 28, 2000 9:26 AM > To: Markus Jork > Cc: mpls@UU.NET; Adrian Farrel > Subject: Re: Multi-LSP Notify in GMPLS > > > See below. > > At 12:01 PM 9/28/00, Markus Jork wrote: > >Adrian, > > > >it seems to me the invention of the Notify message in GMPLS was not > >such a great idea. It's only purpose is to reduce the latency of > >error message delivery back to the LSP ingress. So instead of the > >slow path forwarding of the PathErr message by the router software > >you now get fast path forwarding of the Notify message by the router > >hardware. Does this gain justify the circumvention of RSVP's authentication > >mechanism (RFC 2747)? RSVP security is based on message authentication > >between neighbors but the Notify message is not send hop-by-hop > >through neighboring routers that are configured to trust each other. > >You now also point this out in your rewrite of section 5.1.1. > > > >There is also no discussion of backwards compatibility. > >In your modified version of section 5, you write: > > > > The Notify message does not replace existing error messages, but may > > initially be sent instead of existing error messages where the intent > > is that the Notify recipient should take remedial action before the > > network has recourse to the normal error processing. > > > >Because the Notify message is sent instead of a regular PathErr > >message, a node that receives the Notify but does not support it > >will not get any error indication from RSVP signalling at all! > > I think it's worth pointing out that Adrian's version differs > from the most recent draft, which says "The Notify message does not replace > existing error messages. " I think any attempt to replace base RSVP messages with a > notify would be misguided. I don't know if this is what Adrian meant to > imply. (Although this is one reading of the his text.) > > >I suggest to remove the Notify message from the GMPLS draft. > > This would be fine with me particularly since a PathErr > message doesn't modify state. (I'm sure some of my co-authors will disagree > with me on dropping it.) > > Lou > > >If not, the "Security Considerations" section needs to be updated: > >the Notify message *does* introduce new security issues. > > > >Markus > From owner-mpls@UU.NET Thu Sep 28 13:16:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26988 for ; Thu, 28 Sep 2000 13:16:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipx29123; Thu, 28 Sep 2000 17:16:43 GMT Received: by mail-control.mail.uu.net id QQjipx05796 for mpls-outgoing; Thu, 28 Sep 2000 17:16:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipx05773 for ; Thu, 28 Sep 2000 17:16:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipw01509 for ; Thu, 28 Sep 2000 13:14:59 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQjipw00819 for ; Thu, 28 Sep 2000 17:14:43 GMT Received: from toy.labn.net (labn.net [209.204.240.82]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id MAA23625; Thu, 28 Sep 2000 12:10:26 -0500 Message-Id: <4.3.2.7.2.20000928131312.00bcfd20@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 13:15:01 -0400 To: Jonathan Lang From: Lou Berger Subject: RE: Multi-LSP Notify in GMPLS Cc: "'Lou Berger'" , Markus Jork , mpls@UU.NET, Adrian Farrel In-Reply-To: <51DA0AB3D747D311832F005004827CC02CEC9E@LUX> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Why do you care if intermediate nodes process the notify? Is it just intermediate node processing vs. forwarding latency? Lou At 01:08 PM 9/28/00, Jonathan Lang wrote: >Lou, > You are correct that you don't have agreement with your co-authors on >removing the Notify. The Notify message is a new general notification >procedure that is NOT restricted to be sent to a source/destination node and >should not be processed by intermediate nodes. These features are desirable >for restoration/protection among other things. > >Thanks, >Jonathan > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, September 28, 2000 9:26 AM > > To: Markus Jork > > Cc: mpls@UU.NET; Adrian Farrel > > Subject: Re: Multi-LSP Notify in GMPLS > > > > > > See below. > > > > At 12:01 PM 9/28/00, Markus Jork wrote: > > >Adrian, > > > > > >it seems to me the invention of the Notify message in GMPLS was not > > >such a great idea. It's only purpose is to reduce the latency of > > >error message delivery back to the LSP ingress. So instead of the > > >slow path forwarding of the PathErr message by the router software > > >you now get fast path forwarding of the Notify message by the router > > >hardware. Does this gain justify the circumvention of RSVP's >authentication > > >mechanism (RFC 2747)? RSVP security is based on message authentication > > >between neighbors but the Notify message is not send hop-by-hop > > >through neighboring routers that are configured to trust each other. > > >You now also point this out in your rewrite of section 5.1.1. > > > > > >There is also no discussion of backwards compatibility. > > >In your modified version of section 5, you write: > > > > > > The Notify message does not replace existing error messages, but may > > > initially be sent instead of existing error messages where the intent > > > is that the Notify recipient should take remedial action before the > > > network has recourse to the normal error processing. > > > > > >Because the Notify message is sent instead of a regular PathErr > > >message, a node that receives the Notify but does not support it > > >will not get any error indication from RSVP signalling at all! > > > > I think it's worth pointing out that Adrian's version differs > > from the most recent draft, which says "The Notify message does not >replace > > existing error messages. " I think any attempt to replace base RSVP >messages with a > > notify would be misguided. I don't know if this is what Adrian meant to > > imply. (Although this is one reading of the his text.) > > > > >I suggest to remove the Notify message from the GMPLS draft. > > > > This would be fine with me particularly since a PathErr > > message doesn't modify state. (I'm sure some of my co-authors will >disagree > > with me on dropping it.) > > > > Lou > > > > >If not, the "Security Considerations" section needs to be updated: > > >the Notify message *does* introduce new security issues. > > > > > >Markus > > From owner-mpls@UU.NET Thu Sep 28 13:36:14 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27440 for ; Thu, 28 Sep 2000 13:36:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipy09375; Thu, 28 Sep 2000 17:35:55 GMT Received: by mail-control.mail.uu.net id QQjipy06997 for mpls-outgoing; Thu, 28 Sep 2000 17:35:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipy06992 for ; Thu, 28 Sep 2000 17:35:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipy04454 for ; Thu, 28 Sep 2000 13:35:12 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjipy07536 for ; Thu, 28 Sep 2000 17:35:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA09864 for mpls@uu.net; Thu, 28 Sep 2000 13:35:11 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipy06975 for ; Thu, 28 Sep 2000 17:34:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipy16144 for ; Thu, 28 Sep 2000 13:30:55 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjipy06138 for ; Thu, 28 Sep 2000 17:30:54 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA22146; Thu, 28 Sep 2000 13:30:44 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-155.cisco.com [161.44.134.155]) by bucket.cisco.com (Mirapoint) with ESMTP id AAG01048; Thu, 28 Sep 2000 13:30:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20000928132620.02090dc0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 13:27:42 -0400 To: jeanlou.dupont@marconi.com, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Resource objects. In-Reply-To: <85256968.005914DC.00@notes.relteccorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Jean, >Hi all; > >Quick question: > >Could somebody tell me the relationship between the following tables: >1) "mplsTunnelResourceTable" in ; >2) "mplsTrafficParamTable" in . There is no relationship per se other than they both expose resource-related parameters for tunnels or LSPs. Keep in mind that in some implementations there might be a direct relationship, but in others there may not be. --Tom >thanks. > >--- >Jean-Lou Dupont >jeanlou.dupont@marconi.com From owner-mpls@UU.NET Thu Sep 28 13:51:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27880 for ; Thu, 28 Sep 2000 13:51:24 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipz17670; Thu, 28 Sep 2000 17:51:01 GMT Received: by mail-control.mail.uu.net id QQjipz11025 for mpls-outgoing; Thu, 28 Sep 2000 17:50:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjipz10865 for ; Thu, 28 Sep 2000 17:50:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipz07222 for ; Thu, 28 Sep 2000 13:49:26 -0400 (EDT) From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjipz16745 for ; Thu, 28 Sep 2000 17:49:26 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Thu, 28 Sep 2000 18:42:34 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id ; Thu, 28 Sep 2000 18:42:25 +0100 Message-ID: To: AF@dataconnection.com, mpls@UU.NET Subject: RE: Asymmetrical Bi-directional LSPs Date: Thu, 28 Sep 2000 18:42:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Adrian, 1st some quick observations on need or otherwise for bi-directionally symmetric LSPs: 1 Depends on application and whether LSP supporting public application directly (eg public voice service) or a larger aggregate service (eg a VPN.....which maybe has voice as 1 application component). For the former I think bi-directionally symmetric LSPs are essential (some may disagree I guess). 2 Let's look at the VPN issue a little bit further. Operators will need to be able to offer orthogonal availability and QoS SLAs to many customers, but esp VPN customers. QoS only applies to the up-state of a LSP and is only relevant to required forwarding behaviour of a given application and not its survivability requirement. That is, voice in 1 VPN may be mission critical but this may not be true in another VPN.....but both need EF treatment otherwise they don't work. But if we aggregate/merge DS classes in LSPs within the core of a MPLS network we will tend to lose sight of the VPN topology. On failure, DS aggregation will tend to favour survival of the EF class (ie if we have congestion), ie in other words CNLS networks mutate failures into QoS hits, and having several DS classes just skew this effect. So, the fundamental point I am trying to make here (in relation to the question you ask) is that (i) I must have the ability to offer SLAs which have orthogonal availability and QoS components and (ii) for some services such as VPNs I may *not* want to merge the traffic therein on a DS/LSP basis within my core network since the survivability index I wish to associate with that VPN is much more important than any QoS aspect......hence, I will need to use bi-directional (and ideally symmetric) LSPs if I am not controlling the applications which are using this VPN (and I am not, the customer is). 3 If I am aggregating only purely AF-types of traffic (eg current BE Internet, and outside VPNs) then uni-directionally established LSPs look seem OK. 4 There are some other issues wrt OAM and prot-sw that are impacted by the choice of unidirectional/bi-directional (asym/sym) LSPs, and also whether one can assume congruent user-plane and control-plane routings.......the latter will vary with technology, eg Optics. But these depend on whether one wants to tell an upstream end of an LSP from A->B that problems are being experienced at B. Some of these issues can be tackled outside the user-plane, eg via the control-plane or management-plane say, if this is appropriate. One factor that needs to be stressed however is in respect of any OAM BDI (backward defect indicator) in the case of bi-directional LSPs and unidirectional failures. Any BDI *must* be generated from the (source) trail termination of the return LSP and *not* some mid point. This allows correct arch operation for both symmetric and asymmetric bi-directional LSP routings. In terms of the 1,2,3 options you gave, I prefer 3. Neil From owner-mpls@UU.NET Thu Sep 28 13:56:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27994 for ; Thu, 28 Sep 2000 13:56:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipz15814; Thu, 28 Sep 2000 17:56:25 GMT Received: by mail-control.mail.uu.net id QQjipz19663 for mpls-outgoing; Thu, 28 Sep 2000 17:55:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipz19629 for ; Thu, 28 Sep 2000 17:55:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipz08009 for ; Thu, 28 Sep 2000 13:53:52 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjipz19497 for ; Thu, 28 Sep 2000 17:53:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA23561 for ; Thu, 28 Sep 2000 10:54:15 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA05398 for mpls@uu.net; Thu, 28 Sep 2000 13:53:49 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjipu21450 for ; Thu, 28 Sep 2000 16:33:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipu06281 for ; Thu, 28 Sep 2000 12:31:51 -0400 (EDT) Received: from sanmiguel.telindus.es by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [194.30.109.50]) id QQjipu11053 for ; Thu, 28 Sep 2000 16:31:46 GMT Received: by SANMIGUEL with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Sep 2000 18:28:23 +0200 Message-ID: From: Javier Antich To: Michel Redondo Ferrero Cc: mpls@UU.NET Subject: RE: MPLS/BGP routing question Date: Thu, 28 Sep 2000 18:28:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.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 NAA27994 Core Routers do not need to run BGP because they, in practice don't take routing decisions with user traffic (I mean traffic comming or going to Internet), they just switch frames based on their MPLS label. BGP decissions are made at the edge and packets sent to the BGP next hop through the corresponding MPLS LSP. Visite nuestro web: http://www.kerndatanet.com/ http://www.telindus.es _________________________________________________________________________ Javier Antich Romaguera. KERN DATANET -TELINDUS ESPAÑA Dpto Pre-Venta. Torre Metropolitana Plaza Ciudad de Viena, 6 -2º 28040 MADRID. (ESPAÑA). e-mail: javier.antich@telindus.es TF: (+34) 91 4560008 -----Mensaje original----- De: Michel Redondo Ferrero [SMTP:mredondo@idecnet.com] Enviado el: jueves 28 de septiembre de 2000 8:26 Para: mpls@UU.NET Asunto: MPLS/BGP routing question Hi, Considering the next scenario: -Core and Border routers running IS-IS, MPLS -VPNs configured in Border routers using BGP/MPLS -Border routers running BGP with full-routing The question: Do Core routers need to run BGP? Is IS-IS enough? Thanks in advance for your answers. Michel Redondo Ferrero From owner-mpls@UU.NET Thu Sep 28 13:58:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28045 for ; Thu, 28 Sep 2000 13:58:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjipz22332; Thu, 28 Sep 2000 17:58:30 GMT Received: by mail-control.mail.uu.net id QQjipz19933 for mpls-outgoing; Thu, 28 Sep 2000 17:57:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjipz19915 for ; Thu, 28 Sep 2000 17:57:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjipz19922 for ; Thu, 28 Sep 2000 13:53:18 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQjipz14540 for ; Thu, 28 Sep 2000 17:52:47 GMT Received: by LUX with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 10:52:47 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CEC9F@LUX> From: Jonathan Lang To: "'Lou Berger'" Cc: Markus Jork , mpls@UU.NET, Adrian Farrel Subject: RE: Multi-LSP Notify in GMPLS Date: Thu, 28 Sep 2000 10:52:46 -0700 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 Lou, As we've discussed before, latency is clearly an issue. Imagine a fiber cut where 80+ wavelengths are affected... Why would you want intermediate nodes processing messages that aren't intended for them? -Jonathan > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, September 28, 2000 10:15 AM > To: Jonathan Lang > Cc: 'Lou Berger'; Markus Jork; mpls@UU.NET; Adrian Farrel > Subject: RE: Multi-LSP Notify in GMPLS > > > Why do you care if intermediate nodes process the notify? Is it just > intermediate node processing vs. forwarding latency? > > Lou > > At 01:08 PM 9/28/00, Jonathan Lang wrote: > >Lou, > > You are correct that you don't have agreement with your > co-authors on > >removing the Notify. The Notify message is a new general > notification > >procedure that is NOT restricted to be sent to a > source/destination node and > >should not be processed by intermediate nodes. These > features are desirable > >for restoration/protection among other things. > > > >Thanks, > >Jonathan > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Thursday, September 28, 2000 9:26 AM > > > To: Markus Jork > > > Cc: mpls@UU.NET; Adrian Farrel > > > Subject: Re: Multi-LSP Notify in GMPLS > > > > > > > > > See below. > > > > > > At 12:01 PM 9/28/00, Markus Jork wrote: > > > >Adrian, > > > > > > > >it seems to me the invention of the Notify message in > GMPLS was not > > > >such a great idea. It's only purpose is to reduce the latency of > > > >error message delivery back to the LSP ingress. So instead of the > > > >slow path forwarding of the PathErr message by the > router software > > > >you now get fast path forwarding of the Notify message > by the router > > > >hardware. Does this gain justify the circumvention of RSVP's > >authentication > > > >mechanism (RFC 2747)? RSVP security is based on message > authentication > > > >between neighbors but the Notify message is not send hop-by-hop > > > >through neighboring routers that are configured to trust > each other. > > > >You now also point this out in your rewrite of section 5.1.1. > > > > > > > >There is also no discussion of backwards compatibility. > > > >In your modified version of section 5, you write: > > > > > > > > The Notify message does not replace existing error > messages, but may > > > > initially be sent instead of existing error messages > where the intent > > > > is that the Notify recipient should take remedial > action before the > > > > network has recourse to the normal error processing. > > > > > > > >Because the Notify message is sent instead of a regular PathErr > > > >message, a node that receives the Notify but does not support it > > > >will not get any error indication from RSVP signalling at all! > > > > > > I think it's worth pointing out that Adrian's version differs > > > from the most recent draft, which says "The Notify > message does not > >replace > > > existing error messages. " I think any attempt to > replace base RSVP > >messages with a > > > notify would be misguided. I don't know if this is what > Adrian meant to > > > imply. (Although this is one reading of the his text.) > > > > > > >I suggest to remove the Notify message from the GMPLS draft. > > > > > > This would be fine with me particularly since a PathErr > > > message doesn't modify state. (I'm sure some of my > co-authors will > >disagree > > > with me on dropping it.) > > > > > > Lou > > > > > > >If not, the "Security Considerations" section needs to > be updated: > > > >the Notify message *does* introduce new security issues. > > > > > > > >Markus > > > > From owner-mpls@UU.NET Thu Sep 28 14:00:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28156 for ; Thu, 28 Sep 2000 14:00:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqa23886; Thu, 28 Sep 2000 18:00:34 GMT Received: by mail-control.mail.uu.net id QQjiqa20191 for mpls-outgoing; Thu, 28 Sep 2000 18:00:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjipz20107 for ; Thu, 28 Sep 2000 17:59:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjipz08886 for ; Thu, 28 Sep 2000 13:59:41 -0400 (EDT) Received: from rly-ip01.mx.aol.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip01.mx.aol.com [205.188.156.49]) id QQjipz23160 for ; Thu, 28 Sep 2000 17:59:41 GMT Received: from tot-we.proxy.aol.com (tot-we.proxy.aol.com [205.188.195.1]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id NAA13964; Thu, 28 Sep 2000 13:59:38 -0400 (EDT) Received: from cs.columbia.edu (AC81F858.ipt.aol.com [172.129.248.88]) by tot-we.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e8SHxa815737; Thu, 28 Sep 2000 13:59:36 -0400 (EDT) Message-ID: <39D38618.74216C12@cs.columbia.edu> Date: Thu, 28 Sep 2000 13:55:36 -0400 From: Ping Pan X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Fred Baker , Martin Picard , mpls@UU.NET Subject: Re: Any SPs using QoS ??? References: <200009281554.LAA31217@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > In message <5.0.0.25.2.20000928083919.02f81ae0@flipper>, Fred Baker writes: > > At 03:00 PM 9/26/00 -0400, Martin Picard wrote: > > > Service Providers tend to say that their backbone will never be > > > congested and if it ever gets there, then, bandwidth will be increased > > > and therefore no Congestion Management or Congestion Avoidance > > > mechanisms are necessary. > > Thats clearly what the ISP marketing people have to say. > Yes. From various studies (Vern Paxson...), it was shown that end-to-end jitter can be quite high. Within core networks, packet delay and loss may be low. But after going through multiple domains, NAP's and POP's, not sure end-user service quality can be assured. (Some time back, I saw data shown that Internet packets go through 5-6 domains on average.... That's quite a few networks to travel.) > The network also needs to degrade gracefully when massive outage > occurs. A few examples in the past 5 or so years (from memory) > include earthquake in southern CA, CO fire in the Bay area, gas leak > (power everything down) in LA area, floods in the mid-west, Amtrak > wreck affecting both sides of track on East, gas company tearing up > wrong pipe (major fiber conduit), and a hurricanes in the East > affecting riverbed fiber, numerous smaller hurricane outages. I'm not > in operations so this is just a very small subset covering only very > big outages. The network can't just work well on sunny days. > Congestion avoidance is needed. > Yep! Another point here is the so-called Disruptive Innovation Effect (DIE). Andrew Odlyzko of ATT Research had talked about that the Internet traffic was doubled every 3-4 months in 1995 and 1996 due to the WEB expansion. A similar traffic growth pattern was shown in some networks last year sue to Napster. So unless SP's have some way (call it QoS guarantees or Traffic Engineering or Flow Isolations...) to protect existing users from sudden traffic bursts, I doubt that simply adding bandwidth to the network is the solution. Finally, from all the conversations that I had with SP people, they all complained about the complexity of managing QoS with the existing protocols, tools and fancy architectures. I never hear any of them saying that they don't need QoS. > Curtis - Ping From owner-mpls@UU.NET Thu Sep 28 14:08:58 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28386 for ; Thu, 28 Sep 2000 14:08:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqa19940; Thu, 28 Sep 2000 18:08:18 GMT Received: by mail-control.mail.uu.net id QQjiqa21368 for mpls-outgoing; Thu, 28 Sep 2000 18:07:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjiqa21363 for ; Thu, 28 Sep 2000 18:07:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqa21686 for ; Thu, 28 Sep 2000 14:02:40 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQjiqa17946 for ; Thu, 28 Sep 2000 18:02:24 GMT Received: from toy.labn.net (labn.net [209.204.240.82]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id MAA04220; Thu, 28 Sep 2000 12:58:04 -0500 Message-Id: <4.3.2.7.2.20000928135610.00b2cdc0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Sep 2000 14:02:40 -0400 To: Jonathan Lang From: Lou Berger Subject: RE: Multi-LSP Notify in GMPLS Cc: "'Lou Berger'" , Markus Jork , mpls@UU.NET, Adrian Farrel In-Reply-To: <51DA0AB3D747D311832F005004827CC02CEC9F@LUX> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:52 PM 9/28/00, Jonathan Lang wrote: >Lou, > As we've discussed before, latency is clearly an issue. Imagine a fiber >cut where 80+ wavelengths are affected... Jonathan, IMO Curtis (at least I think it was Curtis) gave you a valid answer here, i.e., let routing propagate this information. > Why would you want intermediate nodes processing messages that aren't >intended for them? How do you know which node is the "intended node"? Lou BTW it's okay for us to disagree here, we just need to id consensus... >-Jonathan > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, September 28, 2000 10:15 AM > > To: Jonathan Lang > > Cc: 'Lou Berger'; Markus Jork; mpls@UU.NET; Adrian Farrel > > Subject: RE: Multi-LSP Notify in GMPLS > > > > > > Why do you care if intermediate nodes process the notify? Is it just > > intermediate node processing vs. forwarding latency? > > > > Lou > > > > At 01:08 PM 9/28/00, Jonathan Lang wrote: > > >Lou, > > > You are correct that you don't have agreement with your > > co-authors on > > >removing the Notify. The Notify message is a new general > > notification > > >procedure that is NOT restricted to be sent to a > > source/destination node and > > >should not be processed by intermediate nodes. These > > features are desirable > > >for restoration/protection among other things. > > > > > >Thanks, > > >Jonathan > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Thursday, September 28, 2000 9:26 AM > > > > To: Markus Jork > > > > Cc: mpls@UU.NET; Adrian Farrel > > > > Subject: Re: Multi-LSP Notify in GMPLS > > > > > > > > > > > > See below. > > > > > > > > At 12:01 PM 9/28/00, Markus Jork wrote: > > > > >Adrian, > > > > > > > > > >it seems to me the invention of the Notify message in > > GMPLS was not > > > > >such a great idea. It's only purpose is to reduce the latency of > > > > >error message delivery back to the LSP ingress. So instead of the > > > > >slow path forwarding of the PathErr message by the > > router software > > > > >you now get fast path forwarding of the Notify message > > by the router > > > > >hardware. Does this gain justify the circumvention of RSVP's > > >authentication > > > > >mechanism (RFC 2747)? RSVP security is based on message > > authentication > > > > >between neighbors but the Notify message is not send hop-by-hop > > > > >through neighboring routers that are configured to trust > > each other. > > > > >You now also point this out in your rewrite of section 5.1.1. > > > > > > > > > >There is also no discussion of backwards compatibility. > > > > >In your modified version of section 5, you write: > > > > > > > > > > The Notify message does not replace existing error > > messages, but may > > > > > initially be sent instead of existing error messages > > where the intent > > > > > is that the Notify recipient should take remedial > > action before the > > > > > network has recourse to the normal error processing. > > > > > > > > > >Because the Notify message is sent instead of a regular PathErr > > > > >message, a node that receives the Notify but does not support it > > > > >will not get any error indication from RSVP signalling at all! > > > > > > > > I think it's worth pointing out that Adrian's version differs > > > > from the most recent draft, which says "The Notify > > message does not > > >replace > > > > existing error messages. " I think any attempt to > > replace base RSVP > > >messages with a > > > > notify would be misguided. I don't know if this is what > > Adrian meant to > > > > imply. (Although this is one reading of the his text.) > > > > > > > > >I suggest to remove the Notify message from the GMPLS draft. > > > > > > > > This would be fine with me particularly since a PathErr > > > > message doesn't modify state. (I'm sure some of my > > co-authors will > > >disagree > > > > with me on dropping it.) > > > > > > > > Lou > > > > > > > > >If not, the "Security Considerations" section needs to > > be updated: > > > > >the Notify message *does* introduce new security issues. > > > > > > > > > >Markus > > > > > > From owner-mpls@UU.NET Thu Sep 28 14:16:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28611 for ; Thu, 28 Sep 2000 14:16:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqb02405; Thu, 28 Sep 2000 18:16:28 GMT Received: by mail-control.mail.uu.net id QQjiqb22027 for mpls-outgoing; Thu, 28 Sep 2000 18:16:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjiqb21968 for ; Thu, 28 Sep 2000 18:15:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqb11546 for ; Thu, 28 Sep 2000 14:15:16 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjiqb22354 for ; Thu, 28 Sep 2000 18:15:16 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e8SIF8400475; Thu, 28 Sep 2000 14:15:08 -0400 (EDT) Message-Id: <200009281815.e8SIF8400475@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Jonathan Lang cc: "'Lou Berger'" , mpls@UU.NET, Adrian Farrel Subject: Re: Multi-LSP Notify in GMPLS In-reply-to: Your message of "Thu, 28 Sep 2000 10:52:46 PDT." <51DA0AB3D747D311832F005004827CC02CEC9F@LUX> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 14:15:08 -0400 Sender: owner-mpls@UU.NET Precedence: bulk Jonathan, > Lou, > As we've discussed before, latency is clearly an issue. Imagine a fiber > cut where 80+ wavelengths are affected... > Why would you want intermediate nodes processing messages that aren't > intended for them? > > -Jonathan I thought I gave an answer to this question in my original message... That's just how RSVP works and on what it bases its authentication mechanism. Markus > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, September 28, 2000 10:15 AM > > To: Jonathan Lang > > Cc: 'Lou Berger'; Markus Jork; mpls@UU.NET; Adrian Farrel > > Subject: RE: Multi-LSP Notify in GMPLS > > > > > > Why do you care if intermediate nodes process the notify? Is it just > > intermediate node processing vs. forwarding latency? > > > > Lou > > > > At 01:08 PM 9/28/00, Jonathan Lang wrote: > > >Lou, > > > You are correct that you don't have agreement with your > > co-authors on > > >removing the Notify. The Notify message is a new general > > notification > > >procedure that is NOT restricted to be sent to a > > source/destination node and > > >should not be processed by intermediate nodes. These > > features are desirable > > >for restoration/protection among other things. > > > > > >Thanks, > > >Jonathan > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Thursday, September 28, 2000 9:26 AM > > > > To: Markus Jork > > > > Cc: mpls@UU.NET; Adrian Farrel > > > > Subject: Re: Multi-LSP Notify in GMPLS > > > > > > > > > > > > See below. > > > > > > > > At 12:01 PM 9/28/00, Markus Jork wrote: > > > > >Adrian, > > > > > > > > > >it seems to me the invention of the Notify message in > > GMPLS was not > > > > >such a great idea. It's only purpose is to reduce the latency of > > > > >error message delivery back to the LSP ingress. So instead of the > > > > >slow path forwarding of the PathErr message by the > > router software > > > > >you now get fast path forwarding of the Notify message > > by the router > > > > >hardware. Does this gain justify the circumvention of RSVP's > > >authentication > > > > >mechanism (RFC 2747)? RSVP security is based on message > > authentication > > > > >between neighbors but the Notify message is not send hop-by-hop > > > > >through neighboring routers that are configured to trust > > each other. > > > > >You now also point this out in your rewrite of section 5.1.1. > > > > > > > > > >There is also no discussion of backwards compatibility. > > > > >In your modified version of section 5, you write: > > > > > > > > > > The Notify message does not replace existing error > > messages, but may > > > > > initially be sent instead of existing error messages > > where the intent > > > > > is that the Notify recipient should take remedial > > action before the > > > > > network has recourse to the normal error processing. > > > > > > > > > >Because the Notify message is sent instead of a regular PathErr > > > > >message, a node that receives the Notify but does not support it > > > > >will not get any error indication from RSVP signalling at all! > > > > > > > > I think it's worth pointing out that Adrian's version differs > > > > from the most recent draft, which says "The Notify > > message does not > > >replace > > > > existing error messages. " I think any attempt to > > replace base RSVP > > >messages with a > > > > notify would be misguided. I don't know if this is what > > Adrian meant to > > > > imply. (Although this is one reading of the his text.) > > > > > > > > >I suggest to remove the Notify message from the GMPLS draft. > > > > > > > > This would be fine with me particularly since a PathErr > > > > message doesn't modify state. (I'm sure some of my > > co-authors will > > >disagree > > > > with me on dropping it.) > > > > > > > > Lou > > > > > > > > >If not, the "Security Considerations" section needs to > > be updated: > > > > >the Notify message *does* introduce new security issues. > > > > > > > > > >Markus > > > > > > > From owner-mpls@UU.NET Thu Sep 28 14:22:23 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28791 for ; Thu, 28 Sep 2000 14:22:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqb25846; Thu, 28 Sep 2000 18:22:03 GMT Received: by mail-control.mail.uu.net id QQjiqb22607 for mpls-outgoing; Thu, 28 Sep 2000 18:21:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjiqb22587 for ; Thu, 28 Sep 2000 18:21:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqb24313 for ; Thu, 28 Sep 2000 14:18:35 -0400 (EDT) Received: from cypher.onfiber.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.108.78.2]) id QQjiqb03613 for ; Thu, 28 Sep 2000 18:18:34 GMT Received: by CYPHER.onfiber.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 13:18:32 -0500 Message-ID: <2AD266216F4FD41192FC00508BD9378E270140@CYPHER.onfiber.com> From: Chris Flores To: "'Javier Antich'" , Michel Redondo Ferrero Cc: mpls@UU.NET Subject: RE: MPLS/BGP routing question Date: Thu, 28 Sep 2000 13:18:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA28791 Interesting, then I have the following question. Let's say the transit backbone consists of a 3 level hierarchy - core, distribution and access. BGP is configured such that the access (or edge) routers are route reflector clients of the distribution routers. Furthermore, the distribution routers are route reflector clients of the core routers. As Michel Redondo Ferrero has stated, MPLS VPNs originate and terminate on the access or edge of the network (in his scenario). Why would you turn off BGP on the core routers? What if MPLS breaks or fails for any reason (i.e. software bug). Then, how would routing occur? Regards. chris -----Original Message----- From: Javier Antich [mailto:javier.antich@telindus.es] Sent: Thursday, September 28, 2000 11:28 AM To: Michel Redondo Ferrero Cc: mpls@UU.NET Subject: RE: MPLS/BGP routing question Core Routers do not need to run BGP because they, in practice don't take routing decisions with user traffic (I mean traffic comming or going to Internet), they just switch frames based on their MPLS label. BGP decissions are made at the edge and packets sent to the BGP next hop through the corresponding MPLS LSP. Visite nuestro web: http://www.kerndatanet.com/ http://www.telindus.es _________________________________________________________________________ Javier Antich Romaguera. KERN DATANET -TELINDUS ESPAÑA Dpto Pre-Venta. Torre Metropolitana Plaza Ciudad de Viena, 6 -2º 28040 MADRID. (ESPAÑA). e-mail: javier.antich@telindus.es TF: (+34) 91 4560008 -----Mensaje original----- De: Michel Redondo Ferrero [SMTP:mredondo@idecnet.com] Enviado el: jueves 28 de septiembre de 2000 8:26 Para: mpls@UU.NET Asunto: MPLS/BGP routing question Hi, Considering the next scenario: -Core and Border routers running IS-IS, MPLS -VPNs configured in Border routers using BGP/MPLS -Border routers running BGP with full-routing The question: Do Core routers need to run BGP? Is IS-IS enough? Thanks in advance for your answers. Michel Redondo Ferrero From owner-mpls@UU.NET Thu Sep 28 14:28:31 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28889 for ; Thu, 28 Sep 2000 14:28:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqb08089; Thu, 28 Sep 2000 18:28:17 GMT Received: by mail-control.mail.uu.net id QQjiqb22922 for mpls-outgoing; Thu, 28 Sep 2000 18:27:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjiqb22916 for ; Thu, 28 Sep 2000 18:27:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqb14051 for ; Thu, 28 Sep 2000 14:26:45 -0400 (EDT) Received: from workhorse.fictitious.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjiqb07096 for ; Thu, 28 Sep 2000 18:26:13 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA32080; Thu, 28 Sep 2000 14:24:43 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200009281824.OAA32080@workhorse.fictitious.org> To: David Charlap cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: mapping to ATM switching Hardware In-reply-to: Your message of "Thu, 28 Sep 2000 10:46:45 EDT." <39D359D5.40A77038@marconi.com> Date: Thu, 28 Sep 2000 14:24:43 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <39D359D5.40A77038@marconi.com>, David Charlap writes: > Curtis Villamizar wrote: > > Kainia Cloutier writes: > >> > >> I'm currently in London, attending the MPLS Next Generation > >> Networking conference. I came to this conference with one objective: > >> finding out how to map an LSP to specific ATM switching hardware, > >> while using RSVP-TE. For the last several weeks, I read RFCs 2205, > >> 2210, 2212 and several IETF drafts and still couldn't find one paper > >> describing "an edge LSR, sending a path message with these parameters > >> set in the ADSPEC and FLOWSPEC object, will receive, from a > >> downstream node, an ATM CBR label mapping". (and so on and so forth > >> for RT-VBR, NRT-VBR, UBR label mappings). > > Strangely enough, I haven't been able to locate an RFC or draft that > maps IntServ-style QoS specs onto ATM-style. Which does strike me as > odd. > > > QoS is supported with the services defined in the diff-serv WG and to > > the extent that diff-serv services such as EF, AF, etc can be mapped > > onto ATM you have compatibility with the legacy ATM devices. > > It is also supported by signalling QoS vis IntServ objects. Each ATM > switch that supports IntServ will have to reserve according to these > parameters. If the hardware can only make reservations using ATM-style > parameters, then some form of mapping will be needed. > > Although there are a number of RFCs that mention RSVP and ATM together > (2379, 2380, 2381 and 2381), a quick scan of their content didn't reveal > any standard formulae for converting one style of resource > representation to the other. > > -- David MPLS maps into diff-serv. Diff-serv does not specify how to implement a behavior, just the desired characteristics. Forget intserv. The RSVP tspec in RSPV/TE just carries the reservation amount (a per PSC usage is defined). This and the PHB is all diff-serv needs. If you think intserv is somehow important and if you think there is good reason to specify mapping of intserv to ATM, write a draft and take it to the ISSLL WG (intserv over specific link layers). Apparently there wasn't enough interest in the combination of intserv and ATM so far. Curtis From owner-mpls@UU.NET Thu Sep 28 14:39:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29239 for ; Thu, 28 Sep 2000 14:39:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqc04826; Thu, 28 Sep 2000 18:38:59 GMT Received: by mail-control.mail.uu.net id QQjiqc23600 for mpls-outgoing; Thu, 28 Sep 2000 18:38:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjiqc23594 for ; Thu, 28 Sep 2000 18:38:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqc16564 for ; Thu, 28 Sep 2000 14:37:21 -0400 (EDT) Received: from rip.psg.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjiqc04220 for ; Thu, 28 Sep 2000 18:37:20 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13eiYN-0003lO-00; Thu, 28 Sep 2000 11:37:07 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="su23SxTfFy" Content-Transfer-Encoding: 7bit To: Ping Pan Cc: mpls@UU.NET Subject: Re: Any SPs using QoS ??? References: <200009281554.LAA31217@workhorse.fictitious.org> <39D38618.74216C12@cs.columbia.edu> Message-Id: Date: Thu, 28 Sep 2000 11:37:07 -0700 Sender: owner-mpls@UU.NET Precedence: bulk --su23SxTfFy Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit hi ping, > From various studies (Vern Paxson...), it was shown that end-to-end > jitter can be quite high. i think it is actually less high inter-backbone than seems to be generally thought. e.g. i will append (humble apologies for the non-ascii, but it is a picture) a ippm-style ripe traffic measurement between verio denver and ripe in amsterdam. there are outliers. > Within core networks, packet delay and loss may be low. But after going > through multiple domains, NAP's and POP's i do not mean to be pedantic, but i am not aware of how, from a policy routing perspective, traffic would go through multiple naps. i push the point because the suckyness (sp?) of some of the naps is one of the worst sources of interprovider problems. i am not sure what 'domains' are. if you mean autonomous systems, then this devolves to naps, inter-provider private circuits, and intra-provider pops. a few naps suck, but even they are supposedly being fixed. and in the interim, folk tend to route around them as much as possible. as provisioning is the biggest pain in private peering engineering, inter-provider private circuits tend to be overprovisioned just so they don't have to be revisited. intra-provider pops are back to the backbone overprovision issue. > I saw data shown that Internet packets go through 5-6 domains on average. i become more and more curious what a 'domain' is. > Finally, from all the conversations that I had with SP people, they all > complained about the complexity of managing QoS with the existing > protocols, tools and fancy architectures. I never hear any of them > saying that they don't need QoS. complexity in the core is not known to improve reliability. randy --su23SxTfFy Content-Type: image/gif Content-Description: denver to ams Content-Disposition: inline; filename="den-ams.gif" Content-Transfer-Encoding: base64 R0lGODdhyAImAfcAAAAAABQUAwwmJkhubqmpqQsLBBErDaenp1UBAf0ICJmZmQBVVfaiogUF AQCqqgYSEhI4OCAyMgoKAlUAAKqqAA5ODAgNDQD//wD/AAgIAwIHB05OFvlsbFFR+lFRUU1N Tfz8/BwcCfr6+h0dAP4EBPb29hYWA0FBQfLy8j8/P/0GBkZGFDMzM6oAAN7e3hsBARArDQIG BgAEBABVABISBRsbGwMKCm5uSAA5AAYrBjk5ABMTE8TExMLCwqL2ov4DAw8PDwQdBA0NDWBg OgAdAAsLCwYTBggNCAkJCQETAQQNBAATAAcHBwIPAgUFBQANAAIHAgMDAwAHAAEBAQABABAq DAgIAaKiov8AAAg6Bzg4EgkcHP0LC1H6UVVVAAQmA/4CAiYmAAICAf0EBCMjCmxsbGpqagcH AlMBARtUVEhuSP4BATo6IFRUVE5OTv//////AAMDAUhISP0DA0JCQiRwJACqAP0QEB0AAB4e BDg4ODY2NjQ0NOXl5RtUGzAwMFRUG9/f3ywsLN3d3QByAGhoHigoKCAyICQkJBI4EiAgIB4e Hv0WFghACBAyEAw4DA8PAhwcHBoaGhgYGBYWFgwmDDQ0DxQUFBISEsPDwwQmBAkcCRAQEAga CAwMDAEaAQMWAwoKCggICAAUAAQKBAYGBgMKAwQEBAAKAAEIAQIGAgEEAQICAgAA//pRUQAE AAECAf4GBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAyAImAQAI/gBFCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzalQYCIXHjx5LbBxJsqTJkyhTqlypEUWNlzBjypxJs6bNmzhz6tzJs6fP nzjLgBxKtKjRo0iTKl3KtKnTp1CVEjAq0KOHq1izat3KtavXr2DDXolKtqzZs2jTql3LNq2H tnDjyp2rNgXdu3jz3p1atCqKt3r1Ag5MuLDhw4iPDk7MuDFhQzUcS57cli9Rv4spm92TWbPn z6AJdw5NujTIHQBMqyZteShmkABixx5tNLZT2bHH1k7ttAbv1cCDCy9K+yhu3Uh/EwV8vPZT ALqVL5X+XDn12yCRewBQ3Cjq4eAT/rcG+foj7tlMbSdVfx767qe+w8ufD7p7Ud5Xrg/FT5Q3 7+3O3ebfc2ZJp99S+bkH4F+pXeXUd/RFSNd4H5XnkXoJppfaFcWx9x937/V2oIQklhiXff2Z h4Jsb23n3oortpibizBeaFVuNrL411v59efggDWyiN6KQ7o4FneDGcmgdTQuGV2RODqIQo8x 2tgUhCZmeRaFHllIpHkN6rgkiLaBOOZYLr6l3pcuvqhem1fh96JLI2pp551NobifbFf0OSWS UzLn4KCpAQkjoRf62WOPUsK2IpVARpooozLWqCKk+1m5oX99cupnppbWORSWeJYqFVUiWAXb eR5weGGY/mgWCuifN75q66tULmibq0TmFytI8Zkq7LCKEfhRfnFSh16bhVp5KG6JIsnpnCo2 KWmQmo7ZrKPYcnstkGmm+CitV4pK7J1couAlq1a1+eWqZjLrnodgynvkf+6WuViw5/Y7rJ7c JvoniLwWyiGPR1oJoIOf4pjrmt5+m+2jlE6ZsKOYemsjpJ1aTC63C5v7Ean+DpvuutJtd++7 UxK54IKr3pogzGAyuPJ2NNNZ8s54AqziR2mqieOzTn7ZXNExzgYYss7W+LCU1ypZtHQJRgeq nG46LGbATZbLM7Enp/pXzDFniDODvRKsIHP+ndcpmmx/mSGR0vH79d0R+vzZ/m/ICSdyWiTj rWXYqtacndKAtXmzgnzeKLSYits6M9TU6iz45eHpTRnTHvUd3N9oBY45iYSPLV/Olo+uumqa ry6c6K7LV3rrk3EOLOix5y6Y7lrCzntws8tn5lB2/268YTV4sAdQzDfv/PPQRx+9ELgfT1np yUuv/fOYVG/992j51t745Jdv/vnop6/++uy37/7754E/XOmvwm///enLr//+/PcvGf3+C6AA B0jA3AGwgAhMoAIXODhUMfCBEIygBENzwAla8IIYzKBaKqjBDnrwgyDkIAhHSMISJlCEJkxh aMJFN7VVToUwhAsKY0hDxqiMacrxFZVqyMO0zLCH/kDMi4d2iLYqBfGIT/khEpcYF2QliExt Y6IUkaLEKVqxLExz1ROj6JIaYAITL0ECGJd3lRpwhozK44wHzKi85K3xjG7cgxrZiEY6xnGO cCxjHtOoxzb2EY1y/KMb7XiVQL7Rj4cEJB4RSUg+JnKQezRkIxspyT1ScpF1jCQmIYnISjJS k4IMpSMnGUmhTMiBdAmLKlfJyla68pWwjKUsZ0nLWtryllvxXFPM1xlovSsULBlIG4IpTGIK ZJjERGYyjalMjBygIZTYCyr3RD6oANOYEGkmNhmizW0upJveRAg4w2mQaEbFfEDbVJz+pJtI XFF/uizKCaTZF7FRc3xQ/nHnOxU4z6h0Rl5LStyQUKDPfSKwn3PhIG1aV1CDEhChiNkBYeJJ F4rOxaJNLAxG4bJRuAiCnpexp1wkGpqOJsakJyUNSg/zUbPoZqVDCYVoCkM7s9SULDfF6UwJ Y86ETpMoW/QeCk6BFZjmJad3QWpSSaPUufTUn/OiXUMdKkCIxgWF7SHLVKnqP6saq2lN2SpX HWNUyXi1Mj8F1VnEOlb9nXWXL/WeTAPTVKfUNU87pWte9fLUq6YVJK1Cy1zrw9TS3BUuh21L X5/CLNqRVC9lPUtkXTpRjVaWMC31aT2NE7+oPPYzk81LaEWrUtJkFqcDfUooitpW/r11LVjt /mw+WxvA1zLlYJP9LF5GGxXeQsW3TgFucC8bmNP6dbN00a1mhPsX5rastCU1rU1ZRLvBHpWm 2G0KbxOrlKU51yjcTcpi0YrcTAE0Ktb1zF29AAi2hHct73ULacYLVxh5j620tZ5tffjXZ/ly tsNib37bst/15Cgq+B3w7wq8pf6yJcEmErCC1cJgxeCmunu9boaXuuFUFoa+sHXwjYYHFaJe 5btoWW974WvYwoYGxLfFClmUW1HLEpe0N95tYYwrQxFn1bPQTYuE1YJithSZyNK1aREBPGHw VbgsWA3YUyBcoiE32SxPJo6s7ntlJ4PUNSIdipRQxxQqk8jKXY5K/pZT1CPvmTiwHNZrh+cS X/ACrc6mCwyM+VteeF2YLOnVjIrd2+IVzrdAVeJymo+3ZqhwcHw1NbOE0LxopzQasDNSdKXT 8qksXdopCoXzWolF6U0v5dPmadGMc6xjVtfY1Rfd8ZfJE+bsnNgsNK7dWkqNxdIcmdNJJktQ 0TtnOmd3d8U+0YdnXaFaA7VRqnWxkFesFjyfxdplwTZZ9rwe2TpF0qYWdqeHg2qmzLBSWiU1 tcPNlHK/cMrsToy21czsLjm7VrIBNGvxxOt4y9Ol3m5KoD2cbGXL+eAa1nO91XVvGLUZ0NJG S7/9WWjCvrhAAWdKruXya6N0vCgfH0rI/kUO67nwmLwhNU6iVx1dtUz8t74O8mdOvku0gNvf 5yr3UlBoJDIv5ebzeTnOPVLu8z6FCft+dWBGnp2Sc9zpcaF5iPvsozxDZeNk3fW60cJ0Ycvc M1KfTsaXMnBjFxyxZ2/LvK2eF243mOoivzXEDe3yrV+74p9Z+1PcThegD91UOj8V3NOptIHF 9UVV+4jfwyP0oX+aokZdfFvG/XfEBD4pWC0DgKADnUV1flMd84jkh9N4nH9aP7gru1z0zvq0 ExrhbV+4X+5DI+74Z50x0hVgVO+YQbM44uo99DnL9xSsc9TGS4f68ZOPWdk3vLEeij4Xjc8Y 5pb+tjFvOWjC/p4c4n+78pi7PBVFPDCh1a9t9BpqDaLgiZdE4SVliIxLhBJ/j9TAlPKv//xR oP/7298j/Ud/8ud/LgGAAyiA9od/Bmh/YQAIAfh//HeAEZiAEPiAD1iAE7h/F5h/EriBC6iB EoiBFhiCHEiBHpiB/neCI0iBItiBJPiBKTiAi9AYowd+JiJ+R/FD6edLPMgbNRgc1xdvODh3 yAZ7eLF2rWeEZWEufAdl/RUmFwZ6AOIrU/givNcYvldteBd8F8cYqyV3NlgyQ1gUj6YtUChQ 8TJQPwgcQchuRcdbaxiG9DGGRBFlNqduckgU7jYbuaV8k4d8OMZ8kCVrpzR4naNU/tSXUnVn ZNkHGl0HFdyHIGliVFeodsdWhAmHiUf4W6HVhGQRW/8VbXQ3ba83inknfNN1NGWWh19Dh0MB ivmGYHjIih+xh9wRK2aSeIaneLS4M64IEijUN5MVh6rRhuH2hunUKa3yeey0Q5VYipq4iUpI cNF4F54YFRwUVBDjFM+IGFkoX8AnaKjYWz82G7enex6RiGvxiM8liIE4iO6YF5H4dikHVPgU FUgHhrq2iOvYiKAVbMMnJsgifbdCjL0YHL/4ETyXFgZZGsZoau7WXFoERed3K0jnSbwSWLzy KRqZOGOxkR/ZkVYRkp2jGyLZXIFSkiMZKGhCkh6Dkhnp/pIc6ZIauQcqCZMemZIveZIn2Sct qZM9aZI0KZNCOSU2iZM3yZNEuZIx2SfexZQ5qUUzCZQyOYOFWI8gN3ZLoY6HYX12R1lft1wA CRUboiZn8y496BHdqIWu93vVSI2Z+BSRdY2O5mNaqRRraRjfmGJbKI5diFotlCRSCHqid5D+ kpAeYYejFmBfGYY6Fyvik28sxEIEZZj9gpgowHO+1ZCk8ZCbhpl42ZZsOY2rd4nSqHBXCWac FYrcGI5l4Zl25pqToXdOQZfnx5oa54eMqJtIxptyCXI6FRXzaBawuI1XEpav2Zheh5z7uH1k UU1MZpnCgpkK1TlAk26MaZiP/qmP3yedw0KdT+gsQsWZoQGbi1Z01EVspFmaosmX7Xl3POV8 9yGeRHiK/DiaFpefn2Gb5pEwmuadpQKeg2coQvWFomYn5plmEWlf6JV0AOpp8tkf9xidpZKg XYaeW/MgvglsGypZgNhqxRWh94Sbual9EqecveWPnsGOTjGcR3EwNZWX7rmeBveWZmejcsGf TVFFZiGj73kUFgpYfUkZtNkUOhpQZUGeD6oZAoqVTQec8JadB4lqP0ahSwqhqUlr87ml3Sks Qdpkn0YzJCZwP6pkZRqcNGqJ8ZmlzXYf3teapngWX1o4ceqXoMGfygJk8Qii8Ninfsqn8iii flal/sdponKKojDHnJLBok3homr1M1F6pXbSpKrZd7PYi6c3oRq6p3fBjo/oqR16Fo6KjeSX Fvl4oIuqdbtpqGIZGqMKJoTaFG8WckmohEdWq3GJF0e6c6UqWLIZFXPKdlyon56xq3coqZMq qMuxZFZ6J8E6YKCZFEqKrI1BqVoKXluGnV6KqH8XrUjho2aapmqKozWaq9aorBizLdb0q1AR rEWKV3VKGcZ6FlzJoZyqdO+Yr51KiJrlpJlCJizniKraj4qada5Kg9SqJdbaptgKHSGTi0Oj i5UppZiKsAl7g+gKG6p2Q7nBjDr0G9PqGc+aX956FOCabaZ5muYKlyob/ntsam8vejhto3vo iAInu7LAyq12NaSzOY6HEbIXaxgLC7P22B5bhJaxqB5ASxkjS1slaxRLG7SBMbQMl5VG+3lz k5Y2e0hrdGJRmZOmE5NUWThiK7Zh+7UrebZWoQOAYLZLg7YoqbZIGbdvC5VpW7dzC2d4q5Rk C7d6e4h2S7eAm7cmObh8K7eHu7c0+aptcaohB6qh2muRu5wh+rJVG5uG04PpV68fahbByqja VbCNwbhscbMUd6ZoirPsSa5wMa/jZ4iHGFi7Yo7sVIW6YbpxdqLQaJ/Eqhmum6RSSyJUO3vL kZ6TCSXDE7WS0bSt9bRFobxjBbp6MbwNNy+W/hKppsK8beW8RIG7jJWyuduy4suyupqx2VKg 7PoU7sqzkvGuS/G7Aauv+zq5KUq/iVq5/VqpWpahmyqw92mv/hvAM2exwTuH5hu7NwW9jaG9 Y8W9o2K/9/un83uvT9d8lku8JHedeirAh7qqHNyqzpkYHPACa1DCYFDCKGzCJ5zCLLzCKLzC MLwGK4wAL8zCNvzCLizDKQwGc8AIN3zCCAAGJ5zDJrwGsZDDY1DENbzEL/wDQHzDa/ADP8zE OyzEOrzDa0DDJezEWNzCOTzEJ0wCVgzDXLAGCVDCKqDFNxwLd1DEMazEU3zFT7zCJEACNUzE RFzDPzAGc9DCV4wG/gxwwc8nI+gbr2SxvulrQz5bGD+ABxPwyC2ABZI8yZRcyZZ8yZicyZq8 yZzcyZ78yaAcyqI8yqRcyqZ8ypvsCoL8ovzbpdmrs6ZHwAUsH9S7HjlloNKLFwzMVQ4MEt67 s6h7uqw7rqobF/BLhk+oqXDau8m5u8PKu/vZGJzroRD8mxRcwRJ8F6S7o8kcq4X6wc1MsKy6 OWNpGAo8y3FRyzHbjs2KoLDsb3Q4GH8mseeMzgR2wCpjRO2sJbtMVUPIIb+RQ8yolsEMFbg6 vuSb0Lt7zHXoY1K2zNDcwW7JzD37l1zXJERUs/Vsz2uhzvcRV9r6ytrZFhiiI+m30Ryd/hYe XbytvIoUS4tjiCE8orXTDJbXnFE3vXzZTBfbbG7kR5lXJ7pO8bkqCsIDzBbGqbVEhZFwO5Vl +5S39tRJOZQ66dSDspSEW9VFWbbyZ9WB69Vz65RZDZKBG5RMKX9mPdZPSbitstZ8S9Zq3TlA cMBbVFOz+swSjZ8RbafRjNQf8ifr5CuFmdLkdsDsIosvzYox/RvHm7yEXdir7Bytwiv7nCX9 7FC9/BG/DK/i6swKfaPF3LqGnZKFTNE569lEmsiJwdDFV83D5drYB9sIwq9ywXPZusH/+L9c V9TkfLCMgdKPXRYrDVQMEmmXCtPSLNuzrdxJAbk7bXIHjKTx/ruiA9ub49ycR50Ym80UB43Q qzvME+2y+XutbkqiZKfaTIHIhty+i1wYwB3c9BbZXHq9rlyh7yyEjYHL8F0aww1YiWPciZ2H mU3QnR3e3l2uoY3aTmXY0CmrDsreug2f69177U0YNS25Of2HGe7BgIoXPc2rsPumJQrOh3zf SpHLJy7UifHhx7rfptHfbfHehHHZBjXgE+vi/B3dDHncip3fBf29P87Z4K3X5SvfcrHdaBfh 4WraFG7RP4vjL67jLS7SUyrLUP4ZMM7KEIt4Q3PjVF6xjHHhlPvc2Cy/+Nrh2izlsHEkb+N5 oYcCYo7mJc7h1H3dksHiZ3HX4Xvg/gi+534O2uJd272aTph2IbhnJkhOzHkNjhOOhRUeGDJ+ 5UmR5eVNkS1UkDwu4FYu6ZRB6RLaKUkb6oO9rSPthUEu5Alu4H/+3YF+XP7afRV56e9CVGzU tW1d1oU7tm5ruEOparoOtnvLtrv+63fbXH6b61ItuMSu7LxSA1SNuM+uuGML7VOC1sh+7H2L 69met3Md5szd3J175nJe5oFq5EnBsYHtsIQJ5yqe3iYO7u3eleXs3pwOGp7O0miY77wY4HJo 43EewWYeaxsuzgEvF3j+uq/eFv8u7uFs3SSeqr6t3afO3eAL6Hyu6EU+3gw7F4mu4O367kjh vksh8uf+/uh6EemzPFr3PuX2XeqJgfIFrPJqbhYwr8sg/5mNoeefzeoX7/F9vvPGPPNl0fGq PudFX9FM3his3b8Fj9MDD8BNr+H4K+iwqxYLL/CkSPC5/fCOcfDAC9+Uh+VCr2/cadk3X2k2 XvP1DhIrv5ikXuWmXuBEvuo/D/QYf67mDhdEP/dGz/dIv9fyuukDhOJNDtkaT7RzofZ0QeP7 lPZr7xltT/OZ3u/J/fRQP+5OT+ZQOublfviXOxdXT+6ee/abz/WNQfhH4fX12fM+n+RD7vce t+St3mNVnxZ7z+i6e/QQnvSMsfQC9+CPfxiR//VvD+YvH/ydPvaIXfzIHfev/o/7qQ77dc/z eO/5GKz36L0U6s378mbyeRH6sW35uy3+1Kz5HqX8QW3nH0/nRl3nIXz8yC/7wo3+qgX8EUb6 Cur6uiix4L/c5G/TAIFC4ECCBQ0eRIjiSkKGDRsudBhRIkSJFRkKsphRIAGEIkRozLgD5EiN FEkO9ALopEGTK10ebPlSpsKZNQVinHnFAwCBVwBc8anwZ1CBoWw29HAUqVKGSZkedPrUYFSp A6lWFUipKseDHqsaxTry6smUNceGrXgWrUO1axlqlakTAE8UOwUC8GAXBV6Bkdz+BRxY8OCq J7Z2/CjVL2G0ZRk/hhwZoeGac+/SnWt5L93Fkj1//gYdeiXlp1wNelUs2qZj1a1dzyQtU/Ps zJeLum3LNLfS3TZ7+8b9F25pxF9V/5bI+iVywcwBOxduk/bl6SiYeNizJ28N7ToFeljoXSFE 8AqdlhcP1Hz48+x7kndfN756+evrp4dv/vv8/OLR73lvP/3uc4o+9NobEKiFDhQQvwYRdPA+ AAkMkEILDYwPPKAK7A9CDh8EUaFFDusqsadEEi0mkpRzSUXJXIQMxsdwmkkzu3ySSyiIOnut Rx9Xgu7H2JQyrSDUnuLxR41YVLJJJwca0iXN6prrvCoHSvJJLbdsLTwZE4rSpiIJOpKpLLlM iEk01wQtTLfAQitIIP+S/pOkOu1kij6CgvyyoeGYGnOgMpWCE7Q7DVITz+MWFe3PwM6sSE82 J6X0LzdnClSgQY8KJa/yKiUoUVBHdetStCCdqE9SV2VVIlNfyhSFTW1CtVJRW8XVplexQhEt VWv6NSe3gpVoN2Jb/ItGQIuTqlfQjmXo1pK6VA3atZQNrFCsDgWJW428jXRC3aYKLiOqJHXI 0aNinbUmbT0DVyBpzW0tXt5UU/evWnPlt9/v0jJo15XYNdFMfuf1N2GLBJaq07ysVXhYmNay lzF0JyPxtIKLLXAuiHz6CcuDVYq4ZJIYfupdqSqOiGW2ymVqj5Zcbio6qQg21zIcg9qZLhRU /o4s3hEoIFkmmmc6ejl8GXMWK4hJenokFY/u82KoJWbIaodcxHZdZifaiSe98BrbqaY9izpU OIp+Ke2q3H4Kbqa61hdU6JI+SW6TR0J5JJwr4sky2qrbl00v1t478YWZxnog8fL0Nby4EqJI 74ka3xYFumv6OyLvBMests0Euo677R72UMC6ekq9vtUHZFC+BVkP8dMCnRoaEP/Io91C28dr /XfYM+R9eONfF0/m42+vvfjdl+/9P9WZ99354K2vfUTCgB4X5rgVfF0qivAeb0/vCdJ6pXw5 /5qtzPAaPPTbRIv3cLZdIn9O+pcmrHDF//+XUixHOfMdpG8g6Rzg/sTGExzdKGQo8B+a7AdA CmKsfwS0ygDDkj9FRU6DINETxFqSPsmxBCIH1EgCJWKjK1GJL33J1QQrOEMoMYZ7LMEfnf5S g3KlryctEtcGTzIWF6lnfZhqH6EY5RIZGq1eSwTNEdFynYe9jXfHGiFNMCgdq8jsYxOTTxky UrmBAEg7eUGB8gIIExjJKCaSulNUkqIik8SLh5tDYomqcrYXyaSJbaNWilSDx1MJJIgFKcNY 0EguhGRnEp6QwxXKIEYNMdJxBcGO24ylnjqWQUGTxCFQxLg6oGBCDoi4SluSorw9UNKQanTc 7NDnuWOdZXxgnKUWHeeJCQXLO5wUBSJW/idFWCXxKBHk0h9pSEEU0kogmEhIJAuIBEmB71OO +0Mkr4AIRJRhD6esiy0bScalFKSNk9wO+HhYF2/OERFZ9OQoFeJJD5RBDkGkylm088pV2vNL o1SVDymHTxLiUJdrRIEnL8nGyunkCgACDyGLqcfU4EqZy/xfM92FkGsmZJEDwYSXYPnLGqwy KXM8JPgSikqLGKshZThF+DCpp5LiEEClWGhbwiNMgUxSZntABES16MMvqRJpL0sIJjx5SHPe p0GfK4MoMmakjXEKimRB3FGvCi/+DcYvD43leLz4RVmajyo8TEoN7PmHhQBom+9ZyCRZUQo5 WGWNYhTo1tDn/qXzrBN90pTnDw35nglhhxM8hcpgSdlKMUJ0m4iQZtaYihD1dLR8Hg1rYgVr EL92UbBqqWw3ezJK7ABIDhqtiAqPGcOsYpSZjPGLQgfiysuOVqaOqytCPLmgCb0zoR/jBFvR F0RRTu0g9vSmN8ezoYd6wLco4KFCwVqXVq4unuFprMwmOYl3ovGnc4QIXn86oRpss5Xg004r OSGHek7yndBkT0w0NNbuPHRCslXIeYWa3yug9Tz7yc48u1kGTGSzDGqFKBq5IwdvajeSymXu d7rrzry4dw+cQK1EVOtMi7bWtRlljBNK4Yky/OEUcijFJBOpEDmYsq6UQIQnUIAE/pm9MxRy kAMnTsEJTmACE4oogiIUMYlS0hgT77zCJADAYADgVCGTiMIUpvCHKYgCAKeYRClqoAhPsGIK AJAyK7wM5i9LGcxRAIAoWAHmIjQZzVFgBZxLAQBPqFXNZMZzSMvACg9EgRNSRoSYvZwXGnsC EwDAxCl4sgcpT8HLU1CEo//8hyavGRM1AMAkylCEU8Y0jYw+xRROEeUp9FgRYg70FCgBZi+H GgBzfTUiOPFoJKzZ0VGoQZkpXQpRACHMY65ymB3daFtPAROwnkIpSO1mMJeiCKLAqQcw0eU5 TwHTZhYzmIObyGe3cgoy7skkLjFVMlXVJlS07GPkdtG8/gUyNB+UiUTfFoVTYALKp0A1o0vB CkyIYtb0FsUfWAHTMkwhywMHyh4mwWlMROEKvPwvRcrQ4z8U4RQB3ux4Ansx5052T5aLCrQU 5HFLjtGh9CogUlFezlQlhJgu2fBG9/cSdncwNBwUS1cFg8wP91xJGY5IzGfCcy3V3OcJA7pL iH50posm6Q0RukyW7iSjNz1XTz/JKTwF75THSYcU+7rX3fLygRnTJjdkTP08nMOtSgbnICF7 szAXFq5Tdu5Ou3tV5F12ip6oWn5c+0rqjixBimbvFbV64puE9YRE/SVTb1LVFb8qxo+Ej3H7 y+AN6qvM510qhyeJ411y+RgB/v5+gnf3swZpw/NlrvUrC7sQx05uQZlb5jc3vVmeOPPQxB1J kwd+jyp/ENGvBPJKknzwKzV8jRxf+c+XCvMLUvyTOCzdk0o+9NckfYugHTivhz3Ywd+9tfje b2a/vaFyr1Xeq79RjFuL5pvqecjRX4DJor2mbD8T0qt7/ZP7u8ILDdBjCuuTP+1DQAsijr4z mA47vQSkFO6rCOeDwAo8mfyTlf2TOtZ6QAtEEwmUCO/TvfEjP9kTP7ErPwxsl5kQweb4P6Vp u6DRuUfxwBoMCxBEAeojCQrskeyzQR/BQYfgwR8kQgNSQQ18PA4swu2TiveZI48ZiP47igNc qPiz/r/7s0K3IEAEQj/+C0AmCrx2+0LVM7wmRJ+h8JkWdCISvJcTREETRAvz40IGVKL2w6oO zLkYhIy30wg5tAii+A7McIohXMJCxEEdHAkDXBUfLESni5vMSArCacRJvMCb6cINdEBKfBIJ /KX3sY2fYcOj4MPbqopR5MNR9MOMQESQUMPneEG2s0Ouej+s8MTRsY7S2o7uaB0MMR4HObnn iZDYiR1ePLlh7JAQIUYI6aVjvBBmNMYFIZ4EcUb+aJDCosbqkcbm2ZAKEcZr7MYE0Z4F1Jg9 GsM7BJbU+wwq1IgtbCkGIht33BFNlMeKOMRLTMJMnEchWZkWCpuokEKb/lDHg6K7K5xCgrQJ dlRFe8SkFgKZj4FCgfjHwVi3MLyackSb1dueUPw+N3Q9jixFmxFHqkoLNAQPNNQRQGzF2DNH 9sO9WJSMVKwJQszHCqxHOmQI2iibsoEhfJzJ1wjChpDJnkTAmhzHMYKf0JFEnhRK1fhJhkhJ /fHIj4zK8HvDsIDJ1FJIc+KL+PnEp5zKJaHIPHRJGZzFwYhIYTHIc8zCtRxILTzCdnQKrrTF 0jmjkgKP6wkgYEQQ5LkeWdLL6emd3Hkevmyef9lGbCRMxKSeb0xM5RnMxYzGxGRMyMwvwOzF vaTMx4yeDAnHnVvKz0QBohTJiXghKtERB4pH/qUEzc9oyoRQxNWUR9Est5H0xH4MxNIMStFg RNgsFdb7yhKEw46sSqlMQUu0ybPTw4zYTZVryeaMItjizZmUzdqritwMjeWMTqxoTYSwzuxk uunUv+pUQu+MjO08iLMEQLZsS85Ly/REC4S0iFXUCPQEjInEQxBCx4ssw4z8zTbsz40cTqqM w7dsmOS0COysGQMljFG0iKvERPKcRPDMQPFUTQgVDPM0iO60UNeS0BV8UFZB0A2tCQwtCK+0 ueAUzhRVUQG1SgJ9Cq2rIlkEw/v8lt1zzs9w0JdAN80LyB5tT/fEO7c0zqL0OwFciRC1O4vs o/30KhE1RBdtwFZB/lIndQkSJQj6JDz1DFL21FLxwb8hHc0ifbdXRD0ljYyAtAj4ZEGNHMH/ bNMAfQpUhNI6vNEVCctusVH36z3opFIi7FAkVLrx7FNL4dNBrcE/pVApvVNDVQorHQgTFUs4 jVM2ZckVlYocdQj5zAhItVSw1AJ7YdCWUtDBwNSVwNIy7VIvTVXMW9W5mdOjONVWPVA4gAMv QEsjTUeMbFJG9UBERTwQpVUdCFUnddSd5FWafNWz27pFpNVaPVbtZAwYvT4ARVHirFYWtdYW BdPZLNCxBEtatVUY9NbHGNaIKNWT0NBnNRlf/b0OA1cU0IIbUNdGLdR5hT52jVJgfVeE/rHX xSGMWK1IWS1IgQXIH30JNdWwrDwJgF3PI21WCvACokHVMcVVz0DYl+DUGqXUNZRU4MxWrDjX xlNYkshYbB2Jw2lWWg0BeT3RzyhX5sTReu3X4MNXpUhXyUDZlF3UmaVHmeVZxavZ1XJXnaXR n42IYgVFN33Ta/XYjzXZS03W9HNZwNPZnU3QcU27GQQMhsVPg83ShgXbt/nSkORWMSVDMKza os2a/FzSAbShZTVaq+sbn3AOTe0+uB2VnE1ZtY1bMIE/LgXcsFVVgr3V94TL+BxZyzPTbyVa MazYtgWNi3WJkhXVjRVXpm3aSZ09zOoJj/GZoEtcVhzViNDb/mblW47K06ktS8GgXICxXFjE XP+M3aNYnxzRkT0oTdA9TqmVUYdN2yFK3d6NWf7sWNmd3aXtVOMFWSoBiqEIm0C8i7oNXY1o XeU92aqFg3htWeHl3pcclodEAU9Di84KC/LFCvOVCvRNX7dQ36eQqr143k+sjoTdXakBX/EF jfZVTuy1WoTQ38f4X8II4MF4X7ozSdLZvCpUYIFkYKZ6owTOuAhOIwhm4AfOpYJw4Pm74AVu YAq24A2W4AzWYA7+YMUC4Qr2YIMAgs793OqYEt0l0hY5YOtY2xreIlxqpIew4dKlVYlN0oQg OQkeYQoeYoMI4i9xIx1miCBm4BMu/mInJogVjhNBnJ+uQ6grVqSSu2JSzGJM0mIu/uJU0iwr 7mIrBmMvRmMzLmO7SmM2VmMtXuMtjmNSHI4XduHPzdTp9SgqTlrUvVo/BuRAHuMx5uFaBYQb 0IJBVuQvbmNGNuNGhuRIdmNBduRJruQtfmSCCFmHqI53mWMxhuRPDuNRDmVStmQ5LuVUfmNV PmVRZmVUXuVYbmWDgAtIHAgW0hHErV+N6OQ/XmRJxuRMPuWUK+SUAIRwBeZgHmZhJsVkbuZl huZnjmZpVmZqpubd2OSGqI4o6IFu9uYT8OZvDuduBudwLmdzHuceoIR0PmdxHud2Jmd2Tud1 fmd5rud7/nbncaZndObnfs7nf+7mfQboHoBngrZnfw7ogx7ogmZofVboeMbnhU5nqdqJ5oWI KbFNXY7hldjmdEbohwbpj3Zojx7ofi7mQigEHdgASwiDFVgBMrAEGlhpMhiCcLaEmhZoj27n m47okBbpcM7pnvZpiCZpg7bpmvbmoBZqhB4CpCbqcG5qoy7qAqZF+ZkxJCiFUkACJIgCrcYE JKiBGkCCS/vqsPaxsB7rGihrsSZrsFbrS2NrtXbrtF7rs47rtaZrt7brvEbrtjZruObru9Zr wPZrwf7rvpZrxK5rwk5sw35rxZ7rwt7rwg7syW7symZsvJbszI7sxrZszfZs/s6GbLPOLbKl TtmwaiuQADE4gwawgjiwggYIgAbIA0iwAkiAhACQAEgwAdU2AUjY7d++7TyQbdwebgmQABMw gQb47dlWbtXOA93mbSvIAE/osq1WthGbK6xmBes+hVPY6u72hFHb6sBOa7E2687+akzI7rGO Au+OAqw+BWgj71qDNq4W6+/2hOzmtVPY766Wb61WNvmGtuwe7/uOb15jha3u6v7Wanrb71MQ 8K6mtqym8O8O7/1WMwb371F7cP++biT4bh/b7n2LcPCuNfjGagivb1aAthCXcPZucBNv76ye NvIuhfkuANtW7gZgA4qBx74lT7uFiiAX8g3N6COP/k4iL/LcVfInh3ILZPIop/IqJ8Ipt/Is 13Ltw/ItB82wWRAnFIoHGnPjagooDJsraUgWnpkW2uOQSXO+WPMyh4rdAHMXUvOHnPNbtmWO QnMxn/M9Z2E7/3NbDnTwxXMn35NCz/MHEnQXIpY7j/MnJHNrpt+NBhZEZwxA1/TACDk973QU 5PRKn+IXOnRS36AWEnM6t5MZFoqSbN7OjXX00Qs/n/XOhXWecXVdx+NFv/VX75mT7PX4tXVA BHaTDHaC6PWp2HW8CPZkv+WFQHWraPZch0djdxxFD8Rfp9tnd/WKxvYz53ZnP2Db5TtMjwtX 3/Qz/PX61Atvb3e6q/XP/oX2KW5eaxd2OiHJvdDKeLeI2aAIy9BJnWSdFzYIgOdz04Rfgh8Q g1d2zAj4BYpehjcPh3/4u4h4hX/H6M12Tob4hM9JPlZ4bf542wh5ji8Ii5ffjD95+E34vfgV hDd5QZSLZU8hPW4ZkScMY6f4YYnfltf2uIlfntf5qr4MoOdD2sD2nv93PsYRWwSdT3x5hJiN jpF2pLRqx/mog6h6WYd60bFjW6R6pw8ZuZwSkAl6qLf6r5/fVR97lH96s8fjp397l89luX/5 tE95sr96+bX5hNzlk5jfnbflwQeMOzb8sNAMtI/ErP/e+K1FlX8bcld1xzfKPn+h6TB8yR9z /lWPS6yX+oJvo1XPfNAX+8/5+87P/M+njqzvRJtH+9X3+7ZHw7+P/bhk/c3Y/Ny4fZTHexZ2 84cg/dxP/DlE95cofndX/dA/fKuO/NRnisWn9OQXn600fc7PEzmn9K+X4bi8aPnZfOjHdYyf fdefesrJ/O9vfamf9K1J//Jn/vjXSu+Hf7Gn/mynf7a3/GlniffX//gHiCsAPKAoaPAgwoIC CaIAcKUgAAAQJTakmPAixoIEMIoQkfEjyIkiQ5IsSTJixJEmV56kmLLiy5csZyKUaRClS4s0 aXoYOBKnyp0zezI8mDKmTpYeCApUaLEnCoEPoUqtmRTh0qgUmxak/urQ68OuOTNm5coVBViw CW0mLLv1qUSpasVqLYqV6VuDaeM61OtwIVm8Tv1qvTJ38Ee3iNHyNdxYr+CSirUSrlpR6MGN FztiTvy4M2jGdQ+Hnvlyb+HSK0/zXfpZNUjAdOW+hp1RtmjApE1HZAjVr0+xwZGCROlbZ8/g yRmmXF68N13gx4dbZLsWumjpwplLdJ7RePTt4i97/47993jvza9eV478PPaj2EuCzz7+MmjN CTnb1t5/p3fl/deSfwIOeJFMAc53IFY4dQdfcAw2CFR5BoaWXIQmOYdhhhIeyOFA1rXUF3HX hXTFQyKSpaKH/WFol1IQwviffgjx1yKO/jnquCOPmOE0Y1AhoRTWhSza1tNDuJGEJG5K9qia kfRVN9ZOUZr35JF9OSnZXwMxaWVnNR50I5Zlmnkmmp2VaNVq7KnpZn8JTgVdb2ytCWaaQj7F XUQC9SWgTMTV+RVBXxLJGKET9dknotzl6eNTc/o0KEZIrTmgmAaR+SinnXraY6CF0kkRho5B VJSlDjHaaHrxwZmll0k2RieQsln2KUuBjrWoqqmpJCiJKJ1qnXwi8dpUVXjiup0HshZG60cL +amsUJkWtOmy2Wq7LW839SpVSlwtChGRwPqJ30DIfkViiq+6uNxvIVJ5EG4dcnvlTxLJFy+q Uxqb00vnmghs/kX84ndvYvC6lFyQ9Pok1a2YcuQRwhVbXLGu/MrkmL7N6kTwen1lJ69CDR9Y rryUHiyWXSJfjKC/l+37o7c1ywxwzMm1i66+PXNIELXLovzzpQcRla+E1qKA7ctNO31mqEQ/ 6PHULe/as0IKG2enu6pV5edvVANtl5JnPW0zzzeHjXLN56aq6IzF3lwwqTuf/XWdXYHdUK0R hhv0TEozfTbhhUtI3NrFnuvnoSB3x93aSDZkd4sviqcycMKiV7iu/5K34MZA8bweii5PJHCx ITtKuOWsYj6h5gtKvBnFhtt++380X/6gl6vbnDrOrVKXJ+C4g1b8gchbrHyLgtduYjz00fPY IfOVdp1j9dKbNCSaDGtvcp7Ofz8++bat6q3pnXmPZvblu39v+weK/z799Zd0qP35679/8xPz /z8AAyjAARIQI/MrIAITqMAFMtBiB2wgBCMowQlS0DYPrCAGExgQADs= --su23SxTfFy-- From owner-mpls@UU.NET Thu Sep 28 14:42:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29311 for ; Thu, 28 Sep 2000 14:42:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqc06279; Thu, 28 Sep 2000 18:42:03 GMT Received: by mail-control.mail.uu.net id QQjiqc23945 for mpls-outgoing; Thu, 28 Sep 2000 18:41:25 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjiqc23940 for ; Thu, 28 Sep 2000 18:41:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqc28211 for ; Thu, 28 Sep 2000 14:34:22 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjiqc03164 for ; Thu, 28 Sep 2000 18:33:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA21912 for mpls@uu.net; Thu, 28 Sep 2000 14:33:50 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjiqc23344 for ; Thu, 28 Sep 2000 18:33:24 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqc15585 for ; Thu, 28 Sep 2000 14:33:07 -0400 (EDT) Received: from che-cse-115.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.128.23]) id QQjiqc11783 for ; Thu, 28 Sep 2000 18:32:52 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id OAA21809; Thu, 28 Sep 2000 14:32:24 -0400 (EDT) Date: Thu, 28 Sep 2000 14:32:24 -0400 From: Eric Osborne To: Chris Flores Cc: "'Javier Antich'" , Michel Redondo Ferrero , mpls@UU.NET Subject: Re: MPLS/BGP routing question Message-ID: <20000928143223.B21758@che-cse-115.cisco.com> References: <2AD266216F4FD41192FC00508BD9378E270140@CYPHER.onfiber.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <2AD266216F4FD41192FC00508BD9378E270140@CYPHER.onfiber.com>; from chris.flores@onfiber.com on Thu, Sep 28, 2000 at 01:18:27PM -0500 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by wodc7mr2.ffx.ops.us.uu.net id QQjiqc06279 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA29311 If MPLS breaks, and routing isn't available, then routing wouldn't occur. :) Having IP available as a backup path to MPLS is a nice belt-and-suspenders idea, but there are some services (MPLS VPNs, circuit transport, etc) that have no way to fall back to a non-MPLS path. eric On Thu, Sep 28, 2000 at 01:18:27PM -0500, Chris Flores wrote: > Interesting, then I have the following question. Let's say the transit > backbone consists of a 3 level hierarchy - core, distribution and access. > BGP is configured such that the access (or edge) routers are route reflector > clients of the distribution routers. Furthermore, the distribution routers > are route reflector clients of the core routers. As Michel Redondo Ferrero > has stated, MPLS VPNs originate and terminate on the access or edge of the > network (in his scenario). Why would you turn off BGP on the core routers? > What if MPLS breaks or fails for any reason (i.e. software bug). Then, how > would routing occur? > > Regards. > > chris > > -----Original Message----- > From: Javier Antich [mailto:javier.antich@telindus.es] > Sent: Thursday, September 28, 2000 11:28 AM > To: Michel Redondo Ferrero > Cc: mpls@UU.NET > Subject: RE: MPLS/BGP routing question > > > Core Routers do not need to run BGP because they, in practice don't take > routing decisions with user traffic (I mean traffic comming or going to > Internet), they just switch frames based on their MPLS label. BGP decissions > are made at the edge and packets sent to the BGP next hop through the > corresponding MPLS LSP. > > > > > > Visite nuestro web: http://www.kerndatanet.com/ > > http://www.telindus.es > _________________________________________________________________________ > Javier Antich Romaguera. KERN DATANET -TELINDUS > ESPAÑA > Dpto Pre-Venta. Torre Metropolitana > > Plaza Ciudad > de Viena, 6 -2º > 28040 MADRID. > (ESPAÑA). > e-mail: javier.antich@telindus.es > TF: (+34) 91 4560008 > > > > > -----Mensaje original----- > De: Michel Redondo Ferrero [SMTP:mredondo@idecnet.com] > Enviado el: jueves 28 de septiembre de 2000 8:26 > Para: mpls@UU.NET > Asunto: MPLS/BGP routing question > > Hi, > > Considering the next scenario: > > -Core and Border routers running IS-IS, MPLS > -VPNs configured in Border routers using BGP/MPLS > -Border routers running BGP with full-routing > > The question: > Do Core routers need to run BGP? Is IS-IS enough? > > Thanks in advance for your answers. > > Michel Redondo Ferrero From owner-mpls@UU.NET Thu Sep 28 14:58:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29615 for ; Thu, 28 Sep 2000 14:58:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqd11731; Thu, 28 Sep 2000 18:58:02 GMT Received: by mail-control.mail.uu.net id QQjiqd25026 for mpls-outgoing; Thu, 28 Sep 2000 18:57:25 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjiqd24994 for ; Thu, 28 Sep 2000 18:57:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqd02596 for ; Thu, 28 Sep 2000 14:52:32 -0400 (EDT) Received: from cypher.onfiber.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.108.78.2]) id QQjiqd09907 for ; Thu, 28 Sep 2000 18:52:15 GMT Received: by CYPHER.onfiber.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 13:52:13 -0500 Message-ID: <2AD266216F4FD41192FC00508BD9378E270142@CYPHER.onfiber.com> From: Chris Flores To: "'Eric Osborne'" Cc: "'Javier Antich'" , Michel Redondo Ferrero , mpls@UU.NET Subject: RE: MPLS/BGP routing question Date: Thu, 28 Sep 2000 13:52:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA29615 that was my point. in this scenario, you would not want to turn BGP off :) -----Original Message----- From: Eric Osborne [mailto:eosborne@cisco.com] Sent: Thursday, September 28, 2000 1:32 PM To: Chris Flores Cc: 'Javier Antich'; Michel Redondo Ferrero; mpls@UU.NET Subject: Re: MPLS/BGP routing question If MPLS breaks, and routing isn't available, then routing wouldn't occur. :) Having IP available as a backup path to MPLS is a nice belt-and-suspenders idea, but there are some services (MPLS VPNs, circuit transport, etc) that have no way to fall back to a non-MPLS path. eric On Thu, Sep 28, 2000 at 01:18:27PM -0500, Chris Flores wrote: > Interesting, then I have the following question. Let's say the transit > backbone consists of a 3 level hierarchy - core, distribution and access. > BGP is configured such that the access (or edge) routers are route reflector > clients of the distribution routers. Furthermore, the distribution routers > are route reflector clients of the core routers. As Michel Redondo Ferrero > has stated, MPLS VPNs originate and terminate on the access or edge of the > network (in his scenario). Why would you turn off BGP on the core routers? > What if MPLS breaks or fails for any reason (i.e. software bug). Then, how > would routing occur? > > Regards. > > chris > > -----Original Message----- > From: Javier Antich [mailto:javier.antich@telindus.es] > Sent: Thursday, September 28, 2000 11:28 AM > To: Michel Redondo Ferrero > Cc: mpls@UU.NET > Subject: RE: MPLS/BGP routing question > > > Core Routers do not need to run BGP because they, in practice don't take > routing decisions with user traffic (I mean traffic comming or going to > Internet), they just switch frames based on their MPLS label. BGP decissions > are made at the edge and packets sent to the BGP next hop through the > corresponding MPLS LSP. > > > > > > Visite nuestro web: http://www.kerndatanet.com/ > > http://www.telindus.es > _________________________________________________________________________ > Javier Antich Romaguera. KERN DATANET -TELINDUS > ESPAÑA > Dpto Pre-Venta. Torre Metropolitana > > Plaza Ciudad > de Viena, 6 -2º > 28040 MADRID. > (ESPAÑA). > e-mail: javier.antich@telindus.es > TF: (+34) 91 4560008 > > > > > -----Mensaje original----- > De: Michel Redondo Ferrero [SMTP:mredondo@idecnet.com] > Enviado el: jueves 28 de septiembre de 2000 8:26 > Para: mpls@UU.NET > Asunto: MPLS/BGP routing question > > Hi, > > Considering the next scenario: > > -Core and Border routers running IS-IS, MPLS > -VPNs configured in Border routers using BGP/MPLS > -Border routers running BGP with full-routing > > The question: > Do Core routers need to run BGP? Is IS-IS enough? > > Thanks in advance for your answers. > > Michel Redondo Ferrero From owner-mpls@UU.NET Thu Sep 28 14:58:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29631 for ; Thu, 28 Sep 2000 14:58:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqd02192; Thu, 28 Sep 2000 18:57:46 GMT Received: by mail-control.mail.uu.net id QQjiqd24987 for mpls-outgoing; Thu, 28 Sep 2000 18:57:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjiqd24981 for ; Thu, 28 Sep 2000 18:56:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqd21021 for ; Thu, 28 Sep 2000 14:56:31 -0400 (EDT) Received: from mercury.lcs.mit.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mercury.lcs.mit.edu [18.26.0.122]) id QQjiqd11109 for ; Thu, 28 Sep 2000 18:56:30 GMT Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id OAA23499; Thu, 28 Sep 2000 14:56:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: In-Reply-To: <200009281824.OAA32080@workhorse.fictitious.org> References: <200009281824.OAA32080@workhorse.fictitious.org> Date: Thu, 28 Sep 2000 14:56:17 -0400 To: curtis@avici.com, David Charlap From: John Wroclawski Subject: Re: mapping to ATM switching Hardware Cc: mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 2:24 PM -0400 9/28/00, Curtis Villamizar wrote: >In message <39D359D5.40A77038@marconi.com>, David Charlap writes: >> Although there are a number of RFCs that mention RSVP and ATM together >> (2379, 2380, 2381 and 2381), a quick scan of their content didn't reveal >> any standard formulae for converting one style of resource >> representation to the other. > >If you think intserv is somehow important and if you think there is >good reason to specify mapping of intserv to ATM, write a draft and >take it to the ISSLL WG (intserv over specific link layers). >Apparently there wasn't enough interest in the combination of intserv >and ATM so far. Actually, this was done ages ago, in the RFC's he mentioned. The mapping RFC is quite detailed about how to do a reasonable job, but doesn't give a single "right" answer because there are tradeoffs to be made, and because "ATM", with all of its myriad QoS options, was hardly a single fixed target. Intserv is primarily about QoS control for applications. Diffserv is about many things, including ISP-level differentiated QoS and, in some people's view, providing a useful building block for end-to-end app-level QoS. The notion that only one of these things is important might be a little short-sighted. Cheers, John From owner-mpls@UU.NET Thu Sep 28 15:00:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29723 for ; Thu, 28 Sep 2000 15:00:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqe04908; Thu, 28 Sep 2000 19:00:14 GMT Received: by mail-control.mail.uu.net id QQjiqd25285 for mpls-outgoing; Thu, 28 Sep 2000 18:59:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjiqd25280 for ; Thu, 28 Sep 2000 18:59:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqd21618 for ; Thu, 28 Sep 2000 14:58:39 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjiqd03178 for ; Thu, 28 Sep 2000 18:58:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA26405 for mpls@uu.net; Thu, 28 Sep 2000 14:58:37 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjiqd24998 for ; Thu, 28 Sep 2000 18:57:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqd02573 for ; Thu, 28 Sep 2000 14:52:30 -0400 (EDT) Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjiqd10014 for ; Thu, 28 Sep 2000 18:52:29 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA20695; Thu, 28 Sep 2000 11:52:22 -0700 (PDT) Message-Id: <200009281852.LAA20695@omega.cisco.com> To: Markus Jork cc: mpls@UU.NET Subject: Re: Multi-LSP Notify in GMPLS In-reply-to: Your message of "Thu, 28 Sep 2000 14:15:08 EDT." <200009281815.e8SIF8400475@mailhost.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20689.970167142.1@cisco.com> Date: Thu, 28 Sep 2000 11:52:22 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Markus, > > Lou, > > As we've discussed before, latency is clearly an issue. Imagine a fiber > > cut where 80+ wavelengths are affected... > > Why would you want intermediate nodes processing messages that aren't > > intended for them? > > > > -Jonathan > > I thought I gave an answer to this question in my original message... > That's just how RSVP works and on what it bases its authentication > mechanism. I would be curious to know whether the folks who use MPLS TE today also use RSVP authentication mechanism (or plan to use it in the near future). Yakov. > > Markus > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Thursday, September 28, 2000 10:15 AM > > > To: Jonathan Lang > > > Cc: 'Lou Berger'; Markus Jork; mpls@UU.NET; Adrian Farrel > > > Subject: RE: Multi-LSP Notify in GMPLS > > > > > > > > > Why do you care if intermediate nodes process the notify? Is it just > > > intermediate node processing vs. forwarding latency? > > > > > > Lou > > > > > > At 01:08 PM 9/28/00, Jonathan Lang wrote: > > > >Lou, > > > > You are correct that you don't have agreement with your > > > co-authors on > > > >removing the Notify. The Notify message is a new general > > > notification > > > >procedure that is NOT restricted to be sent to a > > > source/destination node and > > > >should not be processed by intermediate nodes. These > > > features are desirable > > > >for restoration/protection among other things. > > > > > > > >Thanks, > > > >Jonathan > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Thursday, September 28, 2000 9:26 AM > > > > > To: Markus Jork > > > > > Cc: mpls@UU.NET; Adrian Farrel > > > > > Subject: Re: Multi-LSP Notify in GMPLS > > > > > > > > > > > > > > > See below. > > > > > > > > > > At 12:01 PM 9/28/00, Markus Jork wrote: > > > > > >Adrian, > > > > > > > > > > > >it seems to me the invention of the Notify message in > > > GMPLS was not > > > > > >such a great idea. It's only purpose is to reduce the latency of > > > > > >error message delivery back to the LSP ingress. So instead of the > > > > > >slow path forwarding of the PathErr message by the > > > router software > > > > > >you now get fast path forwarding of the Notify message > > > by the router > > > > > >hardware. Does this gain justify the circumvention of RSVP's > > > >authentication > > > > > >mechanism (RFC 2747)? RSVP security is based on message > > > authentication > > > > > >between neighbors but the Notify message is not send hop-by-hop > > > > > >through neighboring routers that are configured to trust > > > each other. > > > > > >You now also point this out in your rewrite of section 5.1.1. > > > > > > > > > > > >There is also no discussion of backwards compatibility. > > > > > >In your modified version of section 5, you write: > > > > > > > > > > > > The Notify message does not replace existing error > > > messages, but may > > > > > > initially be sent instead of existing error messages > > > where the intent > > > > > > is that the Notify recipient should take remedial > > > action before the > > > > > > network has recourse to the normal error processing. > > > > > > > > > > > >Because the Notify message is sent instead of a regular PathErr > > > > > >message, a node that receives the Notify but does not support it > > > > > >will not get any error indication from RSVP signalling at all! > > > > > > > > > > I think it's worth pointing out that Adrian's version differs > > > > > from the most recent draft, which says "The Notify > > > message does not > > > >replace > > > > > existing error messages. " I think any attempt to > > > replace base RSVP > > > >messages with a > > > > > notify would be misguided. I don't know if this is what > > > Adrian meant to > > > > > imply. (Although this is one reading of the his text.) > > > > > > > > > > >I suggest to remove the Notify message from the GMPLS draft. > > > > > > > > > > This would be fine with me particularly since a PathErr > > > > > message doesn't modify state. (I'm sure some of my > > > co-authors will > > > >disagree > > > > > with me on dropping it.) > > > > > > > > > > Lou > > > > > > > > > > >If not, the "Security Considerations" section needs to > > > be updated: > > > > > >the Notify message *does* introduce new security issues. > > > > > > > > > > > >Markus > > > > > > > > > > > > From owner-mpls@UU.NET Thu Sep 28 15:02:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29769 for ; Thu, 28 Sep 2000 15:02:10 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqe06785; Thu, 28 Sep 2000 19:01:52 GMT Received: by mail-control.mail.uu.net id QQjiqe00379 for mpls-outgoing; Thu, 28 Sep 2000 19:01:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjiqe00083 for ; Thu, 28 Sep 2000 19:01:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqd04000 for ; Thu, 28 Sep 2000 14:58:30 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjiqd02454 for ; Thu, 28 Sep 2000 18:57:58 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id OAA20371; Thu, 28 Sep 2000 14:57:40 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Chris Flores'" , "'Javier Antich'" , "'Michel Redondo Ferrero'" Cc: Subject: RE: MPLS/BGP routing question Date: Thu, 28 Sep 2000 14:57:26 -0400 Message-ID: <04c701c0297d$f23b5780$d001010a@tst.ennovatenetworks.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.2910.0) In-reply-to: <2AD266216F4FD41192FC00508BD9378E270140@CYPHER.onfiber.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The claim that only edge routers need to run BGP/MPLS VPN software is not true, as you have correctly pointed out. It's not appropriate to consider the required Route Reflection as an edge router function. Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Chris > Flores > Interesting, then I have the following question. Let's say the transit > backbone consists of a 3 level hierarchy - core, distribution > and access. > BGP is configured such that the access (or edge) routers are > route reflector > clients of the distribution routers. Furthermore, the > distribution routers > are route reflector clients of the core routers. As Michel > Redondo Ferrero > has stated, MPLS VPNs originate and terminate on the access > or edge of the > network (in his scenario). Why would you turn off BGP on the > core routers? > What if MPLS breaks or fails for any reason (i.e. software > bug). Then, how > would routing occur? > > Regards. > > chris From owner-mpls@UU.NET Thu Sep 28 15:20:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00168 for ; Thu, 28 Sep 2000 15:20:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqf22959; Thu, 28 Sep 2000 19:20:09 GMT Received: by mail-control.mail.uu.net id QQjiqf08586 for mpls-outgoing; Thu, 28 Sep 2000 19:19:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjiqf08574 for ; Thu, 28 Sep 2000 19:19:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqf09029 for ; Thu, 28 Sep 2000 15:16:39 -0400 (EDT) Received: from field by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: field.videotron.net [205.151.222.108]) id QQjiqf19538 for ; Thu, 28 Sep 2000 19:16:39 GMT Received: from MartinPicard ([207.253.78.109]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with SMTP id <0G1M00IEN2UUMD@field.videotron.net> for mpls@UU.NET; Thu, 28 Sep 2000 15:16:06 -0400 (EDT) Date: Thu, 28 Sep 2000 15:09:23 -0400 From: Martin Picard Subject: Re: MPLS/BGP routing question To: bkumar@ennovatenetworks.com, "'Chris Flores'" , "'Javier Antich'" , "'Michel Redondo Ferrero'" Cc: mpls@UU.NET Message-id: <015c01c0297f$9d6e2280$35141aac@vsi.videotron.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: <04c701c0297d$f23b5780$d001010a@tst.ennovatenetworks.com> X-Priority: 3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > The claim that only edge routers need to run BGP/MPLS VPN software > is not true, as you have correctly pointed out. It's not appropriate > to consider the required Route Reflection as an edge router function. > You're right, MPLS VPN is not needed only the edge routers but also on the RRs. But it surely is not a requirement for the backbone routers. martin > Cheers, > --brijesh > Ennovate Networks Inc. > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Chris > > Flores > > Interesting, then I have the following question. Let's say the > transit > > backbone consists of a 3 level hierarchy - core, distribution > > and access. > > BGP is configured such that the access (or edge) routers are > > route reflector > > clients of the distribution routers. Furthermore, the > > distribution routers > > are route reflector clients of the core routers. As Michel > > Redondo Ferrero > > has stated, MPLS VPNs originate and terminate on the access > > or edge of the > > network (in his scenario). Why would you turn off BGP on the > > core routers? > > What if MPLS breaks or fails for any reason (i.e. software > > bug). Then, how > > would routing occur? > > > > Regards. > > > > chris > From owner-mpls@UU.NET Thu Sep 28 15:22:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00197 for ; Thu, 28 Sep 2000 15:22:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqf21442; Thu, 28 Sep 2000 19:22:05 GMT Received: by mail-control.mail.uu.net id QQjiqf08679 for mpls-outgoing; Thu, 28 Sep 2000 19:21:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjiqf08673 for ; Thu, 28 Sep 2000 19:21:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqf08669 for ; Thu, 28 Sep 2000 15:15:11 -0400 (EDT) Received: from mercury.polarisnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQjiqe18348 for ; Thu, 28 Sep 2000 19:14:54 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Thu, 28 Sep 2000 12:18:55 -0700 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 12:18:05 -0700 Message-ID: From: "Huang, Thomas" To: "Thomas D. Nadeau" , Lou Berger Cc: mpls@UU.NET Subject: how to pass the Tunnel session attributes in RSVP-TE extension Date: Thu, 28 Sep 2000 12:17:54 -0700 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 Hello: In MPLS-TE MIB, the TunnelSessionAttribute has mergingPermitted, isPersistent, and isPinned. If using RSVP-TE's SessionAttruibute, the Flags field has 4 values defined. Does that mean vendors could use the remaining values of this octet for mergingPermitted for instance? If not, what's the right way to pass those tunnel session attributes to the downstream nodes? Thank you. /Thomas From owner-mpls@UU.NET Thu Sep 28 15:26:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00241 for ; Thu, 28 Sep 2000 15:26:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqf23174; Thu, 28 Sep 2000 19:26:20 GMT Received: by mail-control.mail.uu.net id QQjiqf09060 for mpls-outgoing; Thu, 28 Sep 2000 19:25:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjiqf09035 for ; Thu, 28 Sep 2000 19:25:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqf28575 for ; Thu, 28 Sep 2000 15:25:17 -0400 (EDT) Received: from rly-ip02.mx.aol.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip02.mx.aol.com [152.163.225.160]) id QQjiqf22640 for ; Thu, 28 Sep 2000 19:25:02 GMT Received: from tot-te.proxy.aol.com (tot-te.proxy.aol.com [152.163.195.131]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id PAA22708; Thu, 28 Sep 2000 15:24:50 -0400 (EDT) Received: from cs.columbia.edu (ACA6C9F3.ipt.aol.com [172.166.201.243]) by tot-te.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e8SJOnX11806; Thu, 28 Sep 2000 15:24:49 -0400 (EDT) Message-ID: <39D39A12.C9390C1F@cs.columbia.edu> Date: Thu, 28 Sep 2000 15:20:50 -0400 From: Ping Pan X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: mpls@UU.NET Subject: Re: Any SPs using QoS ??? References: <200009281554.LAA31217@workhorse.fictitious.org> <39D38618.74216C12@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > > hi ping, > > > From various studies (Vern Paxson...), it was shown that end-to-end > > jitter can be quite high. > Hello, Randy, > i think it is actually less high inter-backbone than seems to be generally > thought. e.g. i will append (humble apologies for the non-ascii, but it is > a picture) a ippm-style ripe traffic measurement between verio denver and > ripe in amsterdam. there are outliers. > Thanks for the info. Is it the data between two backbones over one NAP? Is it generally the same for all inter-provider traffic? > > Within core networks, packet delay and loss may be low. But after going > > through multiple domains, NAP's and POP's > > i do not mean to be pedantic, but i am not aware of how, from a policy > routing perspective, traffic would go through multiple naps. i push the > point because the suckyness (sp?) of some of the naps is one of the worst > sources of interprovider problems. > > i am not sure what 'domains' are. if you mean autonomous systems, then > this devolves to naps, inter-provider private circuits, and intra-provider > pops. > I meant AS's. I first saw the data in http://moat.nlanr.net/ASPL/. I chatted with one of my colleagues in Bell Labs (he had gone already) a couple of months ago. He was working on inter-domain network topology stuff, and collected bunch of more up to date traces. He told me that the average AS length in his data was 5-6. My point was that even though major transit ISP's (Verio and UUnet) can control link congestion and transit delay within their networks, can all your customers (regional ISP's) provide the same level of service to end users? If no, what can we do about it? One solution may be to create a MPLS tunnel with bandwidth guarantees from one regional ISP over the backbones to another regional ISP... Thanks! -- Ping Pan http://www.cs.columbia.edu/~pingpan From owner-mpls@UU.NET Thu Sep 28 15:41:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00577 for ; Thu, 28 Sep 2000 15:41:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqg11746; Thu, 28 Sep 2000 19:41:36 GMT Received: by mail-control.mail.uu.net id QQjiqg10108 for mpls-outgoing; Thu, 28 Sep 2000 19:41:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjiqg10068 for ; Thu, 28 Sep 2000 19:40:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqg02401 for ; Thu, 28 Sep 2000 15:40:43 -0400 (EDT) Received: from rip.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjiqg10837 for ; Thu, 28 Sep 2000 19:40:42 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13ejXo-0004FT-00; Thu, 28 Sep 2000 12:40:36 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ping Pan Cc: mpls@UU.NET Subject: Re: Any SPs using QoS ??? References: <200009281554.LAA31217@workhorse.fictitious.org> <39D38618.74216C12@cs.columbia.edu> <39D39A12.C9390C1F@cs.columbia.edu> Message-Id: Date: Thu, 28 Sep 2000 12:40:36 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Thanks for the info. Is it the data between two backbones over one NAP? the picture was taken over something like the following route randy@r00.dnvrco01.us.bb> traceroute e01.overtoom.ripe.net traceroute to e01.overtoom.ripe.net (193.0.0.25), 30 hops max, 40 byte packets 1 p1-1-0-0.r01.dnvrco01.us.bb.verio.net (129.250.3.62) 0.534 ms 0.489 ms 0.457 ms 2 p1-2-0-1.r00.kscymo01.us.bb.verio.net (129.250.2.78) 11.269 ms 11.237 ms 11.257 ms 3 p1-6-1-1.r01.dllstx01.us.bb.verio.net (129.250.2.217) 22.848 ms 22.899 ms 22.862 ms 4 p4-2-0.r00.dllstx01.us.bb.verio.net (129.250.3.73) 22.818 ms 23.322 ms 22.811 ms 5 209.245.240.153 (209.245.240.153) 86.399 ms 86.287 ms 86.496 ms 6 so-6-0-0.mp1.Dallas1.level3.net (209.247.10.101) 86.477 ms 86.573 ms 86.574 ms 7 209.247.10.42 (209.247.10.42) 92.251 ms 92.358 ms 92.316 ms 8 209.244.3.189 (209.244.3.189) 165.139 ms 165.511 ms 165.184 ms 9 loopback0.mp1.London1.l3.net (212.113.2.11) 161.098 ms 160.528 ms 160.053 ms 10 212.187.128.90 (212.187.128.90) 168.302 ms 168.535 ms 168.703 ms 11 loopback0.core1.Amsterdam1.Level3.net (212.72.32.1) 168.208 ms 168.320 ms 167.960 ms 12 loopback0.ams-ix.Amsterdam1.Level3.net (212.72.32.8) 168.958 ms 168.964 ms 168.704 ms 13 Amsterdam1.ripe.net (193.148.15.68) 170.335 ms 170.670 ms 169.932 ms 14 fe20.pampus.ripe.net (193.0.0.246) 170.295 ms 170.049 ms 170.053 ms 15 s10.overtoom.ripe.net (193.0.0.53) 171.447 ms * 171.890 ms remembering that, due to hot potato (hmmm, time for lunch), symmetry should not be assumed. > Is it generally the same for all inter-provider traffic? of large providers. > I meant AS's. I first saw the data in http://moat.nlanr.net/ASPL/. I > chatted with one of my colleagues in Bell Labs (he had gone already) a > couple of months ago. He was working on inter-domain network topology > stuff, and collected bunch of more up to date traces. He told me that > the average AS length in his data was 5-6. i can believe that is what is in the routing tables. i suspect that the average number of ass traversed by a packet is less. > My point was that even though major transit ISP's (Verio and UUnet) can > control link congestion and transit delay within their networks, can all > your customers (regional ISP's) provide the same level of service to end > users? If no, what can we do about it? One solution may be to create a > MPLS tunnel with bandwidth guarantees from one regional ISP over the > backbones to another regional ISP... and this will manufacture bandwidth? and this will scale for a few thousand non-giant isps? randy From owner-mpls@UU.NET Thu Sep 28 16:02:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00982 for ; Thu, 28 Sep 2000 16:02:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqi29645; Thu, 28 Sep 2000 20:01:46 GMT Received: by mail-control.mail.uu.net id QQjiqi14956 for mpls-outgoing; Thu, 28 Sep 2000 20:01:04 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjiqi13994 for ; Thu, 28 Sep 2000 20:00:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqh18980 for ; Thu, 28 Sep 2000 15:56:29 -0400 (EDT) Received: from rly-ip01.mx.aol.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip01.mx.aol.com [205.188.156.49]) id QQjiqh03275 for ; Thu, 28 Sep 2000 19:56:29 GMT Received: from tot-te.proxy.aol.com (tot-te.proxy.aol.com [152.163.195.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id PAA19495; Thu, 28 Sep 2000 15:56:19 -0400 (EDT) Received: from cs.columbia.edu (ACA6C9F3.ipt.aol.com [172.166.201.243]) by tot-te.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e8SJuHX27165; Thu, 28 Sep 2000 15:56:17 -0400 (EDT) Message-ID: <39D3A172.60FE9D9C@cs.columbia.edu> Date: Thu, 28 Sep 2000 15:52:18 -0400 From: Ping Pan X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: mpls@UU.NET Subject: Re: Any SPs using QoS ??? References: <200009281554.LAA31217@workhorse.fictitious.org> <39D38618.74216C12@cs.columbia.edu> <39D39A12.C9390C1F@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > > > My point was that even though major transit ISP's (Verio and UUnet) can > > control link congestion and transit delay within their networks, can all > > your customers (regional ISP's) provide the same level of service to end > > users? If no, what can we do about it? One solution may be to create a > > MPLS tunnel with bandwidth guarantees from one regional ISP over the > > backbones to another regional ISP... > > and this will manufacture bandwidth? No. But it can provide admission control: if there is a bandwidth bottleneck somewhere, don't send the data, or multi-homing to another provider. > and this will scale for a few thousand non-giant isps? Maybe not with the current mechanism. ;-) > > randy -- Ping Pan http://www.cs.columbia.edu/~pingpan From owner-mpls@UU.NET Thu Sep 28 16:13:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01176 for ; Thu, 28 Sep 2000 16:13:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqi07243; Thu, 28 Sep 2000 20:12:43 GMT Received: by mail-control.mail.uu.net id QQjiqi24481 for mpls-outgoing; Thu, 28 Sep 2000 20:12:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjiqi24471 for ; Thu, 28 Sep 2000 20:12:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqi09907 for ; Thu, 28 Sep 2000 16:11:45 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjiqi08410 for ; Thu, 28 Sep 2000 20:11:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA22310; Thu, 28 Sep 2000 13:11:53 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA05804; Thu, 28 Sep 2000 16:11:28 -0400 (EDT) Message-Id: <200009282011.QAA05804@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Chris Flores cc: "'Eric Osborne'" , "'Javier Antich'" , Michel Redondo Ferrero , mpls@UU.NET Subject: Re: MPLS/BGP routing question In-reply-to: Your message of Thu, 28 Sep 2000 13:52:04 -0500. <2AD266216F4FD41192FC00508BD9378E270142@CYPHER.onfiber.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 28 Sep 2000 16:11:27 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Chris> that was my point. in this scenario, you would not want to turn BGP Chris> off :) I'm afraid you've missed the point. In the VPN scenario, it doesn't do any good to run BGP in the core, because the IP header of the packets do not contain the information you need to match the packet to its route. Besides which you could never hope to hold all routes from all VPNs in every core router anyway. From owner-mpls@UU.NET Thu Sep 28 16:20:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01277 for ; Thu, 28 Sep 2000 16:20:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqj11192; Thu, 28 Sep 2000 20:20:07 GMT Received: by mail-control.mail.uu.net id QQjiqj25210 for mpls-outgoing; Thu, 28 Sep 2000 20:19:35 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjiqj25199 for ; Thu, 28 Sep 2000 20:19:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqi22452 for ; Thu, 28 Sep 2000 16:11:17 -0400 (EDT) Received: from workhorse.fictitious.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjiqi06340 for ; Thu, 28 Sep 2000 20:11:16 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA32638; Thu, 28 Sep 2000 16:09:39 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200009282009.QAA32638@workhorse.fictitious.org> To: Jonathan Lang cc: "'Lou Berger'" , Markus Jork , mpls@UU.NET, Adrian Farrel Reply-To: curtis@avici.com Subject: Re: Multi-LSP Notify in GMPLS In-reply-to: Your message of "Thu, 28 Sep 2000 10:08:22 PDT." <51DA0AB3D747D311832F005004827CC02CEC9E@LUX> Date: Thu, 28 Sep 2000 16:09:39 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <51DA0AB3D747D311832F005004827CC02CEC9E@LUX>, Jonathan Lang writes: > Lou, > You are correct that you don't have agreement with your co-authors on > removing the Notify. The Notify message is a new general notification > procedure that is NOT restricted to be sent to a source/destination node and > should not be processed by intermediate nodes. These features are desirable > for restoration/protection among other things. > > Thanks, > Jonathan A path-error would also propogate to the ingress of a LSP and is seen by the controlling entity for each hop of the LSP, including a LSC LSP. So we've not adding any capability. Curtis From owner-mpls@UU.NET Thu Sep 28 16:20:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01290 for ; Thu, 28 Sep 2000 16:20:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqj11012; Thu, 28 Sep 2000 20:20:07 GMT Received: by mail-control.mail.uu.net id QQjiqj25190 for mpls-outgoing; Thu, 28 Sep 2000 20:19:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjiqj25185 for ; Thu, 28 Sep 2000 20:19:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqi21943 for ; Thu, 28 Sep 2000 16:08:49 -0400 (EDT) Received: from rip.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjiqi04869 for ; Thu, 28 Sep 2000 20:08:34 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13ejyk-0004QP-00; Thu, 28 Sep 2000 13:08:26 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ping Pan Cc: mpls@UU.NET Subject: Re: Any SPs using QoS ??? References: <200009281554.LAA31217@workhorse.fictitious.org> <39D38618.74216C12@cs.columbia.edu> <39D39A12.C9390C1F@cs.columbia.edu> <39D3A172.60FE9D9C@cs.columbia.edu> Message-Id: Date: Thu, 28 Sep 2000 13:08:26 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >>> My point was that even though major transit ISP's (Verio and UUnet) can >>> control link congestion and transit delay within their networks, can all >>> your customers (regional ISP's) provide the same level of service to end >>> users? If no, what can we do about it? One solution may be to create a >>> MPLS tunnel with bandwidth guarantees from one regional ISP over the >>> backbones to another regional ISP... >> and this will manufacture bandwidth? > > No. But it can provide admission control: if there is a bandwidth > bottleneck somewhere, don't send the data this has appeal. but ecn looks much simpler. randy From owner-mpls@UU.NET Thu Sep 28 16:21:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01308 for ; Thu, 28 Sep 2000 16:21:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqj11830; Thu, 28 Sep 2000 20:21:00 GMT Received: by mail-control.mail.uu.net id QQjiqj25229 for mpls-outgoing; Thu, 28 Sep 2000 20:20:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjiqj25214 for ; Thu, 28 Sep 2000 20:19:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiqj10984 for ; Thu, 28 Sep 2000 16:18:44 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjiqj10383 for ; Thu, 28 Sep 2000 20:18:28 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA27523; Thu, 28 Sep 2000 13:18:48 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA05822; Thu, 28 Sep 2000 16:18:23 -0400 (EDT) Message-Id: <200009282018.QAA05822@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: bkumar@ennovatenetworks.com cc: "'Chris Flores'" , "'Javier Antich'" , "'Michel Redondo Ferrero'" , mpls@UU.NET Subject: Re: MPLS/BGP routing question In-reply-to: Your message of Thu, 28 Sep 2000 14:57:26 -0400. <04c701c0297d$f23b5780$d001010a@tst.ennovatenetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 28 Sep 2000 16:18:23 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Brijesh> The claim that only edge routers need to run BGP/MPLS VPN software Brijesh> is not true, as you have correctly pointed out. It's not Brijesh> appropriate to consider the required Route Reflection as an edge Brijesh> router function. You can sure tell it's the season for political debates ;-) You're aware, aren't you, that route reflectors don't need to be in the path, and in fact don't need to pass data traffic at all. I suppose the more accurate statement would be that the only routers which need to both pass traffic and run BGP are the edge routers. From owner-mpls@UU.NET Thu Sep 28 16:31:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01503 for ; Thu, 28 Sep 2000 16:31:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiqk18166; Thu, 28 Sep 2000 20:31:32 GMT Received: by mail-control.mail.uu.net id QQjiqk26291 for mpls-outgoing; Thu, 28 Sep 2000 20:30:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjiqk26235 for ; Thu, 28 Sep 2000 20:30:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjiqj24255 for ; Thu, 28 Sep 2000 16:21:58 -0400 (EDT) Received: from smtp02.mrf.mail.rcn.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp02.mrf.mail.rcn.net [207.172.4.61]) id QQjiqj12522 for ; Thu, 28 Sep 2000 20:21:58 GMT Received: from 209-122-205-31.s31.tnt4.lnh.md.dialup.rcn.com ([209.122.205.31] helo=befirst600x1) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.15 #2) id 13ekBl-0001BJ-00; Thu, 28 Sep 2000 16:21:54 -0400 From: "Mark Jasen" To: "Ronaldo Moreira Salles" , "Jay Wang" Cc: Subject: RE: QoS or not QoS; RE: B/W vs QoS Re: Any SPs using QoS ??? Date: Thu, 28 Sep 2000 16:21:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C02968.35A642C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <006101c0291d$878b0800$0787c69b@ee.ic.ac.uk> Disposition-Notification-To: "Mark Jasen" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C02968.35A642C0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by wodc7mr1.ffx.ops.us.uu.net id QQjiqk18166 Content-Transfer-Encoding: quoted-printable Nice lab theory. Where=92s the practical application of the theory? The presentation did not discuss real-world implications and applications. T= he theories, at least as far as they can be discerned, do not take human err= or, differing hardware configurations, =93weakest link=94 issues and a non-un= iform universe into consideration. It also seems to indicate a constant bit-se= rvice demand. One of the hardest parts about learning economics from a textbook is that= it=92s tough to know when to apply theory and when to use real-world examples. = The presentation does not refute the original writer=92s perceptions, nor, in= fact, real world experience. Mark Jasen -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ronaldo Mo= reira Salles Sent: Thursday, September 28, 2000 3:27 AM To: Jay Wang Cc: mpls@UU.NET Subject: Re: QoS or not QoS; RE: B/W vs QoS Re: Any SPs using QoS ??? I agree, but how can you support your arguments given the following techn= ical analysis: http://www.statslab.cam.ac.uk/~frank/TALKS/RoySoc99/sld009.htm Cheers, Ronaldo. ----- Original Message ----- From: Jay Wang To: 'Grenville Armitage' ; mpls@UU.N= ET Sent: Wednesday, September 27, 2000 8:17 PM Subject: QoS or not QoS; RE: B/W vs QoS Re: Any SPs using QoS ??? I think Grenville has a point. To add to that, I think QoS can provide at least the following that simply throwing lots of BW at the network can not achieve: * Service Performance Predictability (throughput, jitter, latency, etc) * Service Prioritization * Bandwidth Slicing * Economical Scalability/Expandability * Support of Targeted Service Demand Profiling and Projection These QoS added values would have strong business implication to most ISP= s. - Jay > -----Original Message----- > From: Grenville Armitage [ mailto:gja@research.bell-labs.com] > Sent: Wednesday, September 27, 2000 11:32 AM > To: mpls@UU.NET > Subject: B/W vs QoS Re: Any SPs using QoS ??? > > > > > B/W isn't QoS. > > B/W may become cheap(er), but the premium service will > be constrained jitter/loss (or predictable delay/loss, take > your choice of poison). > > It isn't even clear that one can solely say "overprovision" > as the magic words to clear up jitter and loss. Realities > such as slow provisioning schedules and technology limitations > can cause your B/W growth to fall behind the demand growth, > creating congestion points. > > Which suggests anything that helps distribute congestion points > (e.g. MPLS TE) and helps differentiate traffic at congestion > points (e.g. Diffserv+MPLS) will find use. > > cheers, > gja > ------=_NextPart_000_0017_01C02968.35A642C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable QoS or not QoS; RE: B/W vs QoS Re: Any SPs using QoS ???

Ni= ce lab theory.  Where’s the = practical application of the theory?  = The presentation did not discuss real-world implications and = applications.  The theories, at least as far = as they can be discerned, do not take human error, differing hardware = configurations, “weakest link” issues and a non-uniform universe into consideration.  It also seems to indicate a = constant bit-service demand.  =

 

On= e of the hardest parts about learning economics from a textbook is that = it’s tough to know when to apply theory and when to use real-world examples.  The presentation does not = refute the original writer’s perceptions, nor, in fact, real world = experience.

 

Ma= rk Jasen

 

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf = Of Ronaldo Moreira Salles
Sent: Thursday, September = 28, 2000 3:27 AM
To: Jay Wang
Cc: mpls@UU.NET
Subject: Re: QoS or not = QoS; RE: B/W vs QoS Re: Any SPs using QoS ???

 

I agree, but how can you support = your arguments given the following technical = analysis:<= /p>

 <= /p>

h= ttp://www.statslab.cam.ac.uk/~frank/TALKS/RoySoc99/sld009.htm<= /font><= /p>

 <= /p>

Cheers,<= /p>

Ronaldo.<= /p>

----- Original Message -----

From: Jay = Wang

=

To: 'Grenville Armitage' ; mpls@UU.NET

Sent: Wednesday, = September 27, 2000 8:17 PM

Subject: QoS or not QoS; RE: B/W vs QoS Re: Any SPs using QoS ???

 <= /p>

I = think Grenville has a point. To add to that, I think QoS
can provide at least the following that simply throwing = lots
of BW at the network can not achieve: <= /p>

* = Service Performance Predictability (throughput, jitter, latency, = etc)
* Service Prioritization
* Bandwidth Slicing
* Economical Scalability/Expandability
* Support of Targeted Service Demand Profiling and = Projection <= /p>

These QoS added values would have strong business implication to most = ISPs. <= /p>

 <= /p>

- = Jay <= /p>

 <= /p>

> -----Original Message-----
> From: Grenville Armitage [mailto:gja@research.bell-labs.= com]
> Sent: Wednesday, September 27, 2000 11:32 = AM
> To: mpls@UU.NET
> Subject: B/W vs QoS Re: Any SPs using QoS = ???
>
>
>
>
> B/W isn't QoS.
>
> B/W may become cheap(er), but the premium service = will
> be constrained jitter/loss (or predictable delay/loss, = take
> your choice of poison).
>
> It isn't even clear that one can solely say "overprovision"
> as the magic words to clear up jitter and loss. = Realities
> such as slow provisioning schedules and technology limitations
> can cause your B/W growth to fall behind the demand = growth,
> creating congestion points.
>
> Which suggests anything that helps distribute = congestion points =
> (e.g. MPLS TE) and helps differentiate traffic at = congestion
> points (e.g. Diffserv+MPLS) will find = use.
>
> cheers,
> gja
>

------=_NextPart_000_0017_01C02968.35A642C0-- From owner-mpls@UU.NET Thu Sep 28 16:56:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01967 for ; Thu, 28 Sep 2000 16:56:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiql00129; Thu, 28 Sep 2000 20:56:26 GMT Received: by mail-control.mail.uu.net id QQjiql28060 for mpls-outgoing; Thu, 28 Sep 2000 20:56:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjiql28046 for ; Thu, 28 Sep 2000 20:55:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiql16824 for ; Thu, 28 Sep 2000 16:55:44 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjiql23118 for ; Thu, 28 Sep 2000 20:55:29 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id QAA26628; Thu, 28 Sep 2000 16:55:12 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: Cc: "'Chris Flores'" , "'Javier Antich'" , "'Michel Redondo Ferrero'" , Subject: RE: MPLS/BGP routing question Date: Thu, 28 Sep 2000 16:55:11 -0400 Message-ID: <000a01c0298e$65239720$d001010a@tst.ennovatenetworks.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.2910.0) In-Reply-To: <200009282018.QAA05822@erosen-sun.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, I don't think I said that Route Reflectors need to be in the path, or this function cannot be implemented on an Edge router itself. But given the performance difference in access routers and core routers, and the role of a route reflector in applying policies on behalf of clients, it is pretty obvious that a core router is more suitable for route reflection function. And we both agree that a router designated as Route Reflector need to run BGP. Cheers, --brijesh > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Eric > Rosen > Sent: Thursday, September 28, 2000 4:18 PM > To: bkumar@ennovatenetworks.com > Cc: 'Chris Flores'; 'Javier Antich'; 'Michel Redondo Ferrero'; > mpls@UU.NET > Subject: Re: MPLS/BGP routing question > > > Brijesh> The claim that only edge routers need to run > BGP/MPLS VPN software > Brijesh> is not true, as you have correctly pointed > out. It's not > Brijesh> appropriate to consider the required Route > Reflection as an edge > Brijesh> router function. > > You can sure tell it's the season for political debates ;-) > > You're aware, aren't you, that route reflectors don't need > to be in the > path, and in fact don't need to pass data traffic at all. > I suppose the > more accurate statement would be that the only routers > which need to both > pass traffic and run BGP are the edge routers. > From owner-mpls@UU.NET Thu Sep 28 17:00:14 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02093 for ; Thu, 28 Sep 2000 17:00:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjiql02035; Thu, 28 Sep 2000 20:59:59 GMT Received: by mail-control.mail.uu.net id QQjiql28249 for mpls-outgoing; Thu, 28 Sep 2000 20:59:29 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjiql28242 for ; Thu, 28 Sep 2000 20:59:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjiql29895 for ; Thu, 28 Sep 2000 16:57:21 -0400 (EDT) Received: from portcullis.ral.virata.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.rsacom.com [208.209.94.122]) id QQjiql23650 for ; Thu, 28 Sep 2000 20:57:21 GMT Received: from mango.ral.virata.com (mango.ral.virata.com [172.16.1.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id GAA22397; Thu, 28 Sep 2000 06:54:19 -0400 Received: from cowboy.ral.virata.com (cowboy.ral.virata.com [10.21.128.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA18050; Thu, 28 Sep 2000 16:57:20 -0400 Received: by COWBOY with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 16:56:15 -0400 Message-ID: <2B31A87FDF5DD411A74200508BD94E4902DFCB@COWBOY> From: "Bryskin, Igor" To: "'Adrian Farrel'" , mpls@UU.NET Subject: RE: Multi-LSP Notify in GMPLS Date: Thu, 28 Sep 2000 16:56:14 -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 Adrian, I was wondering why do we need the in the GMPLS Notify message ? My understanding is that the Notify message is meant to notify upstream nodes about certain events such as FIS, FRS without tearing down the LSPs. It would be reasonable for the Notify message to have the ResvTear like format (with FILTERSPEC list), because it will better suit the protection/restoration schemes especially for the MPT LSPs. Would it be better to have instead of ::= [] ::= [] [] ::= [] [] this ::= [] ::=