From owner-mpls@UU.NET Mon May 1 00:50: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 AAA09708 for ; Mon, 1 May 2000 00:50: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 QQingd05240; Mon, 1 May 2000 04:48:25 GMT Received: by mail-control.mail.uu.net id QQingd14076 for mpls-outgoing; Mon, 1 May 2000 04:48: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 QQingd14071 for ; Mon, 1 May 2000 04:48: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 QQingd22600 for ; Mon, 1 May 2000 00:48:01 -0400 (EDT) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49]) id QQingd00787 for ; Mon, 1 May 2000 04:48:01 GMT Received: from rice.math ([135.104.13.10]) by crufty; Mon May 1 00:46:24 EDT 2000 From: "Anwar Elwalid" Message-Id: <1000501004623.ZM9597@research.bell-labs.com> Date: Mon, 1 May 2000 00:46:23 -0400 In-Reply-To: Tulius Lima "info on MATE (MPLS Adaptive Traffic Engineering)" (Apr 28, 10:54pm) References: <390A40DA.8AC4E63C@dca.fee.unicamp.br> X-Mailer: Z-Mail (4.0.1 13Jan97) To: Tulius Lima , MPLS list Subject: Re: info on MATE (MPLS Adaptive Traffic Engineering) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Tulius, You can find a draft on MATE in: http://cm.bell-labs.com/cm/ms/who/anwar/MATE1.ID We are currently building a prototype of MATE. We have new results which prove the stability of the online adaptive load balancing algorithms we are using. The new results will be included in an upcoming revised draft. Regards, anwar Elwalid Lucent Technologies On Apr 28, 10:54pm, Tulius Lima wrote: > Subject: info on MATE (MPLS Adaptive Traffic Engineering) > Hello, > > > I am new to this list and I would like to know more about MATE > (MPLS Adaptive Traffic Engineering). > Is there anyone working on MATE these days? > I also would like to know what would be a good approuch to > create simulations with this algorithm. > > > Thanks in Advance! > Tulius Lima > > >-- End of excerpt from Tulius Lima From owner-mpls@UU.NET Mon May 1 10:17: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 KAA26825 for ; Mon, 1 May 2000 10:17: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 QQinhp15716; Mon, 1 May 2000 14:15:09 GMT Received: by mail-control.mail.uu.net id QQinho02978 for mpls-outgoing; Mon, 1 May 2000 14:14: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 QQinho02968 for ; Mon, 1 May 2000 14:14: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 QQinho22253 for ; Mon, 1 May 2000 10:14:44 -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 QQinho07664 for ; Mon, 1 May 2000 14:14:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA26235 for mpls@uu.net; Mon, 1 May 2000 10:14:43 -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 QQinho02953 for ; Mon, 1 May 2000 14:14: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 QQinho22187 for ; Mon, 1 May 2000 10:14:04 -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 QQinho14947 for ; Mon, 1 May 2000 14:14:04 GMT Received: from tnadeau-pc02 (ch2-dhcp134-203.cisco.com [161.44.134.203]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA11411; Mon, 1 May 2000 10:14:00 -0400 (EDT) Message-Id: <4.2.2.20000501101517.04575b00@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 01 May 2000 10:17:47 -0400 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: Fwd: RE: LSR MIB WG Last Call Issues Cc: cheenu Srinivasan , arun@force10networks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi All, We apologize, but due to a logistical error, the incorrect version of the MPLS LSR MIB was published on the MPLS WG's website last week. The SMI portion of the document was okay, but there were a few minor nits that were not in the version which was put up. We have since fixed the problem. The version you see there now is the correct WG Last Call version of the MIB. Sorry for the inconvenience. --Tom From owner-mpls@UU.NET Mon May 1 16:43: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 QAA05788 for ; Mon, 1 May 2000 16:43: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 QQinio08514; Mon, 1 May 2000 20:40:41 GMT Received: by mail-control.mail.uu.net id QQinio15258 for mpls-outgoing; Mon, 1 May 2000 20:40:10 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 QQinio15251 for ; Mon, 1 May 2000 20:40: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 QQinio27224 for ; Mon, 1 May 2000 16:40:05 -0400 (EDT) Received: from mailer.psc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailer.psc.edu [128.182.58.100]) id QQinio29321 for ; Mon, 1 May 2000 20:40:04 GMT Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer.psc.edu (8.9.3/8.9.3/psc) with ESMTP id QAA28178 for ; Mon, 1 May 2000 16:40:04 -0400 (EDT) Received: from psc.edu (cuckoo.psc.edu [128.182.61.60]) by dexter.psc.edu (8.9.3/8.9.3/psc) with ESMTP id QAA17915 for ; Mon, 1 May 2000 16:40:04 -0400 (EDT) Message-ID: <390DEBA3.DBA1D1CA@psc.edu> Date: Mon, 01 May 2000 16:40:03 -0400 From: Chris Rapier Organization: NLANR Engineering Services X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "mpls@UU.NET" Subject: Traceroute and MPLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit At the risk of sounding like an idiot I was wondering if there has been any thought on how to make traceroute work with mpls or add some path tracing functionality to it. I ran across some old messages in various archives but nothing that sounded really resolved. I've some ideas but I wanted to find out what the current thinking on the subject is. Thanks in advance Chris Rapier NLANR ES From owner-mpls@UU.NET Mon May 1 16:49: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 ESMTP id QAA06038 for ; Mon, 1 May 2000 16:49:00 -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 QQinip04392; Mon, 1 May 2000 20:47:25 GMT Received: by mail-control.mail.uu.net id QQinip15967 for mpls-outgoing; Mon, 1 May 2000 20:46: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 QQinip15957 for ; Mon, 1 May 2000 20:46: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 QQinip28375 for ; Mon, 1 May 2000 16:46:36 -0400 (EDT) Received: from ubatuba.dca.fee.unicamp.br by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ubatuba.dca.fee.unicamp.br [143.106.11.134]) id QQinip12465 for ; Mon, 1 May 2000 20:46:34 GMT Received: from dca.fee.unicamp.br (par-17.home.unicamp.br [143.106.200.17]) by ubatuba.dca.fee.unicamp.br (8.9.3/8.9.3) with ESMTP id RAA05567; Mon, 1 May 2000 17:46:16 -0300 (EST) Message-ID: <390DEDE1.5D51C038@dca.fee.unicamp.br> Date: Mon, 01 May 2000 17:49:37 -0300 From: Tulius Lima X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Anwar Elwalid , MPLS list Subject: Re: info on MATE (MPLS Adaptive Traffic Engineering) References: <390A40DA.8AC4E63C@dca.fee.unicamp.br> <1000501004623.ZM9597@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mr. Elwalid, Thanks for your reply . I have read the original draft (draft-widjaja-mpls-mate-00.txt) and now I've read the link you sent me. They are basicly the same and I was kinda hoping for the protocol specification. I am an MSc student and my thesis is going to be based on MPLS traffic engineering and MATE is going to be a big part of it. Our initial idea is to implement a simulation version of MATE. We will be using CACI's COMNET III as our base simulator. After that, though, everything is just a big blur. How long until we have the new version of the draft? And about your results, can you say anything in advance? Regards, Tulius Lima Anwar Elwalid wrote: > Tulius, > > You can find a draft on MATE in: > http://cm.bell-labs.com/cm/ms/who/anwar/MATE1.ID > > We are currently building a prototype of MATE. > We have new results which prove the stability of > the online adaptive load balancing algorithms we are using. > The new results will be included in an upcoming revised draft. From owner-mpls@UU.NET Mon May 1 16:54: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 QAA06165 for ; Mon, 1 May 2000 16:54: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 QQinip17336; Mon, 1 May 2000 20:53:11 GMT Received: by mail-control.mail.uu.net id QQinip16353 for mpls-outgoing; Mon, 1 May 2000 20:52: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 QQinip16345 for ; Mon, 1 May 2000 20:52: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 QQinip29560 for ; Mon, 1 May 2000 16:52:43 -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 QQinip16871 for ; Mon, 1 May 2000 20:52:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA24873 for mpls@uu.net; Mon, 1 May 2000 16:52: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 QQinip16287 for ; Mon, 1 May 2000 20:52: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 QQinip10790 for ; Mon, 1 May 2000 16:52:04 -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 QQinip07872 for ; Mon, 1 May 2000 20:52:04 GMT Received: from tnadeau-pc02 (ch2-dhcp134-203.cisco.com [161.44.134.203]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA29854; Mon, 1 May 2000 16:51:29 -0400 (EDT) Message-Id: <4.2.2.20000501165306.045375b0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 01 May 2000 16:54:22 -0400 To: Chris Rapier , "mpls@UU.NET" From: "Thomas D. Nadeau" Subject: Re: Traceroute and MPLS In-Reply-To: <390DEBA3.DBA1D1CA@psc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Take a look at: http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-01.txt The RRO object for RSVP also provides some of the information you seek. --Tom >At the risk of sounding like an idiot I was wondering if there has been >any thought on how to make traceroute work with mpls or add some path >tracing functionality to it. I ran across some old messages in various >archives but nothing that sounded really resolved. I've some ideas but I >wanted to find out what the current thinking on the subject is. > >Thanks in advance > >Chris Rapier >NLANR ES From owner-mpls@UU.NET Mon May 1 17:10: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 ESMTP id RAA06494 for ; Mon, 1 May 2000 17:10:00 -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 QQiniq18875; Mon, 1 May 2000 21:08:47 GMT Received: by mail-control.mail.uu.net id QQiniq25306 for mpls-outgoing; Mon, 1 May 2000 21:08:25 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 QQiniq25298 for ; Mon, 1 May 2000 21:08: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 QQiniq13547 for ; Mon, 1 May 2000 17:08:03 -0400 (EDT) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQiniq18304 for ; Mon, 1 May 2000 21:08:02 GMT Received: from rice.math ([135.104.13.10]) by crufty; Mon May 1 17:07:32 EDT 2000 From: "Anwar Elwalid" Message-Id: <1000501170731.ZM13777@research.bell-labs.com> Date: Mon, 1 May 2000 17:07:31 -0400 In-Reply-To: Tulius Lima "Re: info on MATE (MPLS Adaptive Traffic Engineering)" (May 1, 5:49pm) References: <390A40DA.8AC4E63C@dca.fee.unicamp.br> <1000501004623.ZM9597@research.bell-labs.com> <390DEDE1.5D51C038@dca.fee.unicamp.br> X-Mailer: Z-Mail (4.0.1 13Jan97) To: Tulius Lima , MPLS list Subject: Re: info on MATE (MPLS Adaptive Traffic Engineering) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk The only protocol specification that you need is for the path measurement function (probing). This can be done by extending ICMP, for example. anwar From owner-mpls@UU.NET Mon May 1 21:25: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 ESMTP id VAA09149 for ; Mon, 1 May 2000 21:25: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 QQinjh28469; Tue, 2 May 2000 01:25:56 GMT Received: by mail-control.mail.uu.net id QQinjh15060 for mpls-outgoing; Tue, 2 May 2000 01:25:43 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 QQinjh15055 for ; Tue, 2 May 2000 01:25: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 QQinjh16346 for ; Mon, 1 May 2000 21:25:24 -0400 (EDT) Received: from NOD.RESTON.MCI.NET by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: nod.Reston.mci.net [166.45.6.38]) id QQinjh17549 for ; Tue, 2 May 2000 01:25:24 GMT Received: from rbonica2 ([166.45.18.133]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JOWF1HEU3U934QAJ@shoe.reston.mci.net> for mpls@UU.NET; Mon, 1 May 2000 21:25:23 EST Date: Mon, 01 May 2000 21:12:13 -0400 From: Ron Bonica Subject: RE: Traceroute and MPLS In-reply-to: <390DEBA3.DBA1D1CA@psc.edu> To: Chris Rapier , mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: 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 Chris > Rapier > Sent: Monday, May 01, 2000 4:40 PM > To: mpls@UU.NET > Subject: Traceroute and MPLS > > > At the risk of sounding like an idiot I was wondering if there has been > any thought on how to make traceroute work with mpls See Section 2.4 of http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt. Also see http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-01.txt. or add some path > tracing functionality to it. Also see references to the RECORD_ROUTE object in http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-05.txt. (Especially Sections 2.2 and 4.4). I ran across some old messages in various > archives but nothing that sounded really resolved. I've some ideas but I > wanted to find out what the current thinking on the subject is. > > Thanks in advance > > Chris Rapier > NLANR ES > From owner-mpls@UU.NET Tue May 2 06:44: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 GAA26821 for ; Tue, 2 May 2000 06:44: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 QQinks20577; Tue, 2 May 2000 10:43:43 GMT Received: by mail-control.mail.uu.net id QQinks24157 for mpls-outgoing; Tue, 2 May 2000 10:43: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 QQinks24152 for ; Tue, 2 May 2000 10:43:13 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 QQinks04180 for ; Tue, 2 May 2000 06:43:04 -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 QQinks20137 for ; Tue, 2 May 2000 10:43:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA14966 for mpls@uu.net; Tue, 2 May 2000 06:43:02 -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 QQiniw10902 for ; Mon, 1 May 2000 22:39:28 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 QQiniw15063 for ; Mon, 1 May 2000 18:39:26 -0400 (EDT) From: Michael.Kelly@ascend.com Received: from drawbridge.ascend.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: drawbridge.ascend.com [198.4.92.1]) id QQiniw24085 for ; Mon, 1 May 2000 22:39:26 GMT Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id PAA16540 for ; Mon, 1 May 2000 15:32:36 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 1 May 2000 22:39:25 UT Received: from colton.ascend.com (colton.ascend.com [192.207.23.40]) by russet.ascend.com (8.9.1a/8.9.1) with SMTP id PAA22615 for ; Mon, 1 May 2000 15:39:24 -0700 (PDT) Received: by colton.ascend.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 882568D2.007C5158 ; Mon, 1 May 2000 15:37:52 -0700 X-Lotus-FromDomain: ASCEND To: mpls@UU.NET Message-ID: <882568D2.007C5094.00@colton.ascend.com> Date: Mon, 1 May 2000 15:34:07 -0700 Subject: Please unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk michael.kelly@ascend.com and mjkelly@lucent.com. Thank you From owner-mpls@UU.NET Tue May 2 08:29: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 ESMTP id IAA28817 for ; Tue, 2 May 2000 08:29: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 QQinkz22985; Tue, 2 May 2000 12:28:56 GMT Received: by mail-control.mail.uu.net id QQinkz17312 for mpls-outgoing; Tue, 2 May 2000 12:28: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 QQinkz17304 for ; Tue, 2 May 2000 12:28: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 QQinkz16464 for ; Tue, 2 May 2000 08:28:01 -0400 (EDT) From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQinkz22135 for ; Tue, 2 May 2000 12:28:01 GMT Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP; Tue, 2 May 2000 12:28:19 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2651.88) id ; Tue, 2 May 2000 12:28:08 +0100 Message-ID: To: dallan@nortelnetworks.com, Vishal.Sharma@tellabs.co, Srinivas.Makam@tellabs.com, mpls@UU.NET Subject: RE: Comments on draft-makam-mpls-recovery-frmwrk-00 Date: Tue, 2 May 2000 12:28:01 +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 Dave Allan wrote: > I think the first may be a bigger problem area than we think. > Because MPLS is defined over multiple media, presumably an LSP can span > multiple media, and therefore WHERE a defect occurs matters as far as how > fast we can take corrective action. > [Harrison,N,Neil,INC1 X] This is generic (ie more complex) example of the violation of layer independence. Here the problem is that one should be very careful when trying to use a defect (or QoS degradation) detection process in one layer network to create actions in another layer network. Consider this more simple example of just two self-homogeneous client/server technologies: Suppose we have a (server) Layer N trail between 2 nodes A and B. And suppose we have a (client) Layer N-1 trail also between nodes A and B. So here we have topological congruence between the different layer trails and so it might seem useful to use the Layer N OAM functions to create actions at the Layer N-1 level (or vice versa). Suppose we now have some performance degradation in the Layer N network that is detected via the specific Layer N overhead that is terminated at the Layer N trail termination point. Let us map this through the Layer N=>Layer N-1 adapatation function to the Layer N-1 trail termination point. Let us now use this to invoke a restoration action at Layer N-1 (maybe via the Layer N-1 control-plane). Let us assume the Layer N-1 trail is now restored via 2 additional nodes C and D.....so the Layer N-1 trail is still A->B, with routing A->C->D->B. This gives 3 concatenated Layer N trails, ie A->C, C->D and D->B. Since the Layer N trail overhead *must* terminate in each of the trails (ie at Layer N nodes) then to carry on with the assumption that we can map the Layer N OAM functionality to the Layer N-1 trail termination points means we need some way of getting this infomation (aggregated somehow) to the Layer N-1 trail termination function. This requires a re-engineering of the Layer N network, ie a new control-channel of some sort needs adding to Layer N. This now creates backwards compatibility issues for Layer N and is therefore unacceptable. Consider now the case Dave Allan points out. Here the trail at Layer N-1 (say an MPLS LSP) spans several *different* concatenated Layer N server technologies, eg a ATM trail, a SDH trail and an Optical trail. We now create an extreme form of architectural layer violation problem by having to match/carry the various Layer N OAM functions (over each other) and then ultimately to the Layer N-1 trail termination point....since this is where the Layer N-1 decisions (eg invoke protection-switching of Layer N-1 trail) need to be made. Clearly this is out of the question. Note that the key architectural issue here is that the inter-node links (not trails) which form the client layer network topology are created from flexing trails (not links) in a server layer network. And just as importantly......note that since there will be multiple client layers of a L1 network, and each will have a different topological (and highly uncertain) traffic demand (and where the access points of each client layer will not be congruent between themselves, and so by inference not congruent with the L1 topology), then this implies that the L1 network (esp its control-plane facets, such as addressing) *must not* be simply related to any one of its client layer networks. This latter aspect is a very important consideration for operators and needs to be well understood in the context of deciding which control-plane should be used at the optical layer. Regards, Neil From owner-mpls@UU.NET Tue May 2 22:11: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 ESMTP id WAA12499 for ; Tue, 2 May 2000 22:11: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 QQinnc24757; Wed, 3 May 2000 02:11:27 GMT Received: by mail-control.mail.uu.net id QQinnc26787 for mpls-outgoing; Wed, 3 May 2000 02:11:10 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 QQinnc26732 for ; Wed, 3 May 2000 02:11:01 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 QQinnc15609 for ; Tue, 2 May 2000 22:10:56 -0400 (EDT) Received: from smtprch2.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15]) id QQinnc24317 for ; Wed, 3 May 2000 02:10:55 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 2 May 2000 21:07:46 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 May 2000 21:10:27 -0500 Message-ID: <6DDA62170439D31185750000F80826AC026B2ABC@zmerd004.ca.nortel.com> From: "David Allan" To: Vishal.Sharma@tellabs.com, Vishal.Sharma@tellabs.co, Srinivas.Makam@tellabs.com, mpls@UU.NET Subject: RE: Comments on draft-makam-mpls-recovery-frmwrk-00 Date: Tue, 2 May 2000 21:10:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB4A4.BF969018" X-Orig: 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_01BFB4A4.BF969018 Content-Type: text/plain Vishal: > > > > 1) Not taking premature recovery action in the presence of lower > > layer restoration mechanisms. > > > > 2) Considering all sources of knowledge of failure (including layer > > violations). > > Ok, if I read you right, what you'd like to do is to have the framework > acknowledge both 1 and 2 > above, > and perhaps mention them separately. (Realizing of course that there are > still issues > with 2), greater than those that there might be with 1). I think doing > this would make > things clearer, while at the same time leaving room for different > implementations. > Yes: As for 1, MPLS MAY need to be cogniscent of multiple lower layer restoration technologies across the length of an LSP and allow for lower layer recovery where appropriate. I don't think we need to say much more at this point. As for 2, in the absence of lower layer restoration, MPLS should be congniscent of any source of failure indication. Normally this would be lower layers propagating defect indication up the stack in the absence of a layer repair strategy, but this may not be available OR not indicative of all possible faults an LSP is succeptable to. Therefore we may end up in conflict with other goals due to requisite layer violations. e.g. IGP failure detection triggering MPLS layer activity (BUTT UGLY). BTW if it is only MPLS subsuming SONET locally and still being unable to deal with brain dead routers in the LSP, we have not gained much. I doubt local repair strategy at the LSP level can scale. regards Dave ------_=_NextPart_001_01BFB4A4.BF969018 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on draft-makam-mpls-recovery-frmwrk-00

Vishal:

    <snip>
    >
    >       = 1) Not taking premature recovery action in the presence of lower
    > layer restoration = mechanisms.
    >
    >       = 2) Considering all sources of knowledge of failure (including = layer
    > violations).

    <snip>
    Ok, if I read you right, what you'd = like to do is to have the framework acknowledge both 1 and 2
    above,
    and perhaps mention them separately. = (Realizing of course that there are still issues
    with 2), greater than those that = there might be with 1). I think doing this would make
    things clearer, while at the same = time leaving room for different implementations.

    Yes:

    As for 1, MPLS MAY = need to be cogniscent of multiple lower layer restoration technologies = across the length of an LSP and allow for lower layer recovery where = appropriate. I don't think we need to say much more at this point. =

    As for 2, in the = absence of lower layer restoration, MPLS should be congniscent of any = source of failure indication. Normally this would be lower layers = propagating defect indication  up the stack in the absence of a = layer repair strategy, but this may not be available OR not indicative = of all possible faults an LSP is succeptable to. Therefore we may end = up in conflict with other goals due to requisite layer violations. e.g. = IGP failure detection triggering MPLS layer activity (BUTT UGLY). =

    BTW if it is only = MPLS subsuming SONET locally and still being unable to deal with brain = dead routers in the LSP, we have not gained much. I doubt local repair = strategy at the LSP level can scale.

    regards
    Dave

------_=_NextPart_001_01BFB4A4.BF969018-- From owner-mpls@UU.NET Wed May 3 06:24: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 GAA28061 for ; Wed, 3 May 2000 06:24: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 QQinoj27732; Wed, 3 May 2000 10:24:17 GMT Received: by mail-control.mail.uu.net id QQinoj24809 for mpls-outgoing; Wed, 3 May 2000 10:23:51 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 QQinoj24804 for ; Wed, 3 May 2000 10:23: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 QQinoj03952 for ; Wed, 3 May 2000 06:23:37 -0400 (EDT) From: peter.van_rompu@alcatel.be Received: from relay1.alcatel.be by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQinoj18832 for ; Wed, 3 May 2000 10:23:32 GMT Received: from bemta001.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.9.1) with SMTP id e43ANEb20746 for ; Wed, 3 May 2000 12:23:15 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C12568D4.00391112 ; Wed, 3 May 2000 12:23:19 +0200 X-Lotus-FromDomain: ALCATEL To: mpls@UU.NET Message-ID: Date: Wed, 3 May 2000 12:23:14 +0200 Subject: questions on Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, Can somebody help me this the following questions on the use of the LDP MIB. 1) mplsLdpEntityTable How can a SNMP Manager derive on which interfaces a LDP entity runs ? For LDP entities with mplsLdpEntityOptionalParameters set to atmParameters(2) or frameRelayParameters(3), my understanding is that the SNMP manager can derive this from the ifIndex found in the associated entry in the mplsLdpAtmParmsTable or mplsLdpFrameRelayParmsTable. Once the SNMP Manager knowns the ifIndex , the SNMP Manager can use the ifStackTable to figure out on which ATM/FR port this entity runs (am I correct ?) . But how to do this for a LDP entity using generic labels ? 2) mplsLdpEntityConfGenericTable I'm confused by the DESCRIPTION field of the mplsLdpEntityConfGenericTable definition : why does a SNMP Manager need to configure a generic label for LDP ? I thought it was sufficient for LDP to known the label pools in order to distribute labels ? 2) creation of a MPLS interface and activation of LDP on it. How can a SNMP manager create a MPLS interface using the available MIBs and associate a LDP entity to that newly created MPLS interface ? My understanding is that if the SNMP Manager wants LDP to use ATM or FrameRelay labels on the MPLS interface, the SNMP Manager needs to create an entry in the mplsLdpEntityTable, an entry in the mplsLdpEntityAtmParmsTable (which allows to configure for instance the VPI/VCI to be used by LDP) and one or more entries in the mplsLdpEntityConfAtmLabelRangeTable. As a result of these row creations, the SNMP agent might create a new MPLS interface, associate an ifIndex to it and fill the ifIndex for the newly created MPLS interface into the mplsLdpEntityTable. (Is this correct ?) But how can a SNMP manager create a new MPLS interface (for instance on ATM) using generic labels ? In this case the LDP entity might allready be configured - the only thing I would exspect to do is to configure somehow a VPI/VCI to be used by this LDP entity. Best regards, Peter Van Rompu - Alcatel Telecom From owner-mpls@UU.NET Wed May 3 06:36: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 ESMTP id GAA28287 for ; Wed, 3 May 2000 06:36: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 QQinok25544; Wed, 3 May 2000 10:36:23 GMT Received: by mail-control.mail.uu.net id QQinok25263 for mpls-outgoing; Wed, 3 May 2000 10:35: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 QQinok25257 for ; Wed, 3 May 2000 10:35:50 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 QQinok04940 for ; Wed, 3 May 2000 06:35:36 -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 QQinok03692 for ; Wed, 3 May 2000 10:35:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA29886 for mpls@uu.net; Wed, 3 May 2000 06:35:34 -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 QQinok25239 for ; Wed, 3 May 2000 10:35:10 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 QQinok04907 for ; Wed, 3 May 2000 06:35:04 -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 QQinok24714 for ; Wed, 3 May 2000 10:35:04 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28218; Wed, 3 May 2000 06:35:04 -0400 (EDT) Message-Id: <200005031035.GAA28218@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-fr-04.txt Date: Wed, 03 May 2000 06:35:04 -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 : Use of Label Switching on Frame Relay Networks Specification Author(s) : A. Conta, P. Doolan, A. Malis Filename : draft-ietf-mpls-fr-04.txt Pages : 25 Date : 02-May-00 This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol Label Switching Architecture described in [ARCH] and the Label Distribution Protocol (LDP) described in [LDP] relative to Frame Relay Networks. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fr-04.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-fr-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-fr-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000502104913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-fr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-fr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000502104913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed May 3 06:36: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 GAA28304 for ; Wed, 3 May 2000 06:36: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 QQinok04261; Wed, 3 May 2000 10:36:25 GMT Received: by mail-control.mail.uu.net id QQinok25266 for mpls-outgoing; Wed, 3 May 2000 10:35:58 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 QQinok25258 for ; Wed, 3 May 2000 10:35: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 QQinok04942 for ; Wed, 3 May 2000 06:35: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 QQinok24952 for ; Wed, 3 May 2000 10:35:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA29884 for mpls@uu.net; Wed, 3 May 2000 06:35:34 -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 QQinok25237 for ; Wed, 3 May 2000 10:35: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 QQinok27842 for ; Wed, 3 May 2000 06:35:00 -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 QQinok24655 for ; Wed, 3 May 2000 10:34:59 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28201; Wed, 3 May 2000 06:34:59 -0400 (EDT) Message-Id: <200005031034.GAA28201@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-multicast-01.txt Date: Wed, 03 May 2000 06:34:58 -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 IP Multicast in MPLS Author(s) : D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari Filename : draft-ietf-mpls-multicast-01.txt Pages : 28 Date : 02-May-00 This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-01.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-multicast-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-multicast-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000502104904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-multicast-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-multicast-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000502104904.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed May 3 08:12:36 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 IAA00560 for ; Wed, 3 May 2000 08:12:36 -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 QQinoq26233; Wed, 3 May 2000 12:12:33 GMT Received: by mail-control.mail.uu.net id QQinoq15584 for mpls-outgoing; Wed, 3 May 2000 12:12:02 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 QQinoq15395 for ; Wed, 3 May 2000 12:11: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 QQinoq07954 for ; Wed, 3 May 2000 08:11:36 -0400 (EDT) Received: from hd2.dot.net.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hd2.vsnl.net.in [202.54.30.2]) id QQinoq25545 for ; Wed, 3 May 2000 12:11:31 GMT Received: from hyd.chiplogic.com ([203.197.20.38]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id RAA08439 for ; Wed, 3 May 2000 17:39:36 +0530 (IST) Received: from chiplogic.com ([192.168.2.59]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id QAA13178 for ; Wed, 3 May 2000 16:49:39 +0530 Message-ID: <39100F28.EC56E921@chiplogic.com> Date: Wed, 03 May 2000 17:06:08 +0530 From: ksreeni X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls Subject: LDP request Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > 3.4.2 Request Driven Label Assignment > In this scheme labels are assigned in response to normal > processing of request based control traffic. Examples of such > control protocols are RSVP. As an LSR processes RSVP messages it > can, as it makes or changes entries in its forwarding tables, > assign labels to those entries. > Among the properties of this scheme are: > - The computational load of assignment and distribution and > the bandwidth consumed by label distribution are bounded by > the amount of control traffic in the system. > - Labels are in the general case preassigned. If a route > exists then a label has been assigned to it (and > distributed). Traffic may be label swapped immediately it > arrives, there is no label setup latency at forwarding time. > - Requires LSRs to be able to process control traffic load > only. > - Depending upon the number of flows supported, this approach > may require a larger number of labels to be assigned > compared with topology driven assignment. In the above the 4th paragraph says, labels are preassigned and distributed. How labels are preassigned and distributed even before the data packet has come to LER. If the labels are preassigned and distributed , when LDP request message is used. Can somebody answer my query by taking an unlabeled L3 packet as input to LER. thanks, Sreeni. From owner-mpls@UU.NET Wed May 3 10:37: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 KAA03293 for ; Wed, 3 May 2000 10:37: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 QQinpa23256; Wed, 3 May 2000 14:37:06 GMT Received: by mail-control.mail.uu.net id QQinpa11455 for mpls-outgoing; Wed, 3 May 2000 14:36:45 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 QQinpa11450 for ; Wed, 3 May 2000 14:36: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 QQinpa01403 for ; Wed, 3 May 2000 10:36: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 QQinpa28791 for ; Wed, 3 May 2000 14:36:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA22749 for mpls@uu.net; Wed, 3 May 2000 10:36:14 -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 QQinpa11343 for ; Wed, 3 May 2000 14:35: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 QQinpa01233 for ; Wed, 3 May 2000 10:35:31 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQinpa22064 for ; Wed, 3 May 2000 14:35:30 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 10:35:30 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15FA8F@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'peter.van_rompu@alcatel.be'" , mpls@UU.NET Subject: RE: questions on Date: Wed, 3 May 2000 10:35:29 -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: peter.van_rompu@alcatel.be [mailto:peter.van_rompu@alcatel.be] > Sent: Wednesday, May 03, 2000 6:23 AM > To: mpls@UU.NET > Subject: questions on > > > Hello Peter, > > Hello, > > Can somebody help me this the following questions on the use > of the LDP MIB. > > 1) mplsLdpEntityTable > > How can a SNMP Manager derive on which interfaces a LDP entity runs ? > > For LDP entities with mplsLdpEntityOptionalParameters set to > atmParameters(2) or frameRelayParameters(3), my understanding > is that the SNMP manager can derive this from the ifIndex > found in the associated entry in the mplsLdpAtmParmsTable or > mplsLdpFrameRelayParmsTable. Once the SNMP Manager knowns > the ifIndex , the SNMP Manager can use the ifStackTable to > figure out on which ATM/FR port this entity runs (am I correct ?) . yes. > > But how to do this for a LDP entity using generic labels ? This is the same. There is an ifIndex associated with a generic label also. This ifIndex would have the ifType of mpls (166). So in effect this would be the mpls interface layer. > > 2) mplsLdpEntityConfGenericTable > > I'm confused by the DESCRIPTION field of the > mplsLdpEntityConfGenericTable definition : why does a SNMP > Manager need to configure a generic label for LDP ? I thought > it was sufficient for LDP to known the label pools in order > to distribute labels ? Yes this is correct for ATM and Frame Relay, but for Generic Labels there is no mechanism in LDP to distribute a label pool (i.e. label range) for generic labels. (The last sentence of Section 3.5.3 of the LDP spec states: "Note that there is no Generic Session Parameters TLV for sessions which advertise Generic Labels.") > > 2) creation of a MPLS interface and activation of LDP on it. > > How can a SNMP manager create a MPLS interface using the > available MIBs and associate a LDP entity to that newly > created MPLS interface ? > > My understanding is that if the SNMP Manager wants LDP to use > ATM or FrameRelay labels on the MPLS interface, the SNMP > Manager needs to create an entry in the mplsLdpEntityTable, > an entry in the mplsLdpEntityAtmParmsTable (which allows to > configure for > instance the VPI/VCI to be used by LDP) and one or more > entries in the mplsLdpEntityConfAtmLabelRangeTable. As a > result of these row creations, the SNMP agent might create a > new MPLS interface, associate an ifIndex to it and fill the > ifIndex for the newly > created MPLS interface into the mplsLdpEntityTable. (Is this > correct ?) Essentially, yes you are correct. Although how this would take place exactly, would largely depend on when ifIndices are created (which is why the LDP MIB uses InterfaceIndexOrZero and why this is not needed for indexing into these Entity related tables.) In other words, an Entity is created at some point in time. At some other point in time, LSPs are established. The LSPs are between MPLS interfaces. It is upto the implementation on when the ifIndices are assigned, but the LDP MIB does stipulate that once LSP are established these InterfaceIndexOrZero objects need to have the value of the InterfaceIndex. > > But how can a SNMP manager create a new MPLS interface (for > instance on ATM) using generic labels ? In this case the LDP > entity might allready be configured - the only thing I would > exspect to do is to configure somehow a VPI/VCI to be used by this LDP > entity. I don't think this is correct. If it is an ATM interface then ATM labels (vpi,vci) would be used, so generic labels would not be used for this. You could have an incoming labelled packet which is from an ATM interface, forwarded out a PPP interface in which case you would forward using a generic label (for details see the draft-ietf-mpls-label-encaps-07.txt). In that case though, this would be two different labels. -Joan > > Best regards, > > Peter Van Rompu - Alcatel Telecom > > From owner-mpls@UU.NET Wed May 3 11:00: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 LAA03712 for ; Wed, 3 May 2000 11:00: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 QQinpc10249; Wed, 3 May 2000 15:00:18 GMT Received: by mail-control.mail.uu.net id QQinpb12451 for mpls-outgoing; Wed, 3 May 2000 14:59: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 QQinpb12442 for ; Wed, 3 May 2000 14:59: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 QQinpb12633 for ; Wed, 3 May 2000 10:59:07 -0400 (EDT) Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQinpb14832 for ; Wed, 3 May 2000 14:59:06 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id QAA06255; Wed, 3 May 2000 16:59:05 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id QAA16143; Wed, 3 May 2000 16:59:04 +0200 (MET DST) Date: Wed, 3 May 2000 16:59:04 +0200 (MET DST) To: mpls , ns-users@mash.cs.berkeley.edu Subject: Network Simulator 2 (ns-2) modules for MPLS and CBQ X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14608.12569.915224.732471@rasputin.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello all, I've seen some references to label switching (MPLS?) and CBQ modules for ns-2. Anyone can give me a pointer to them ? I didn't find anything after a quick look at ns homepage (http://www-mash.cs.berkeley.edu/ns/ns.html) Regrads, Florian. From owner-mpls@UU.NET Wed May 3 12:15: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 MAA05318 for ; Wed, 3 May 2000 12:15: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 QQinph11161; Wed, 3 May 2000 16:15:24 GMT Received: by mail-control.mail.uu.net id QQinpg02789 for mpls-outgoing; Wed, 3 May 2000 16:14:46 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 QQinpg02777 for ; Wed, 3 May 2000 16:14: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 QQinpg27182 for ; Wed, 3 May 2000 12:14:14 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQinpg10303 for ; Wed, 3 May 2000 16:14:14 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <2R4FMKDV>; Wed, 3 May 2000 09:19:06 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7C41@ICARIAN> From: Eric Gray To: "'ksreeni'" , mpls Subject: RE: LDP request Date: Wed, 3 May 2000 09:19:04 -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 Sreeni, In the future, please remember to identify the source of your quote. :-) I found this text in "A Framework for MPLS", by Ross Callon, George Swallow, N. Feldman, C Srinivasan, P. Doolan, and A. Fredette - dated 09/22/1999. This document merely discusses MPLS possibilities. To see what was actually proposed, read the architecture draft at http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-06.txt To see what has actually been defined, see specific drafts available at http://www.ietf.org/ids.by.wg/mpls.html -- Eric Gray > -----Original Message----- > From: ksreeni [mailto:ksreeni@chiplogic.com] > Sent: Wednesday, May 03, 2000 4:36 AM > To: mpls > Subject: LDP request > > > Hi, > > > 3.4.2 Request Driven Label Assignment > > > In this scheme labels are assigned in response to normal > > processing of request based control traffic. Examples of such > > control protocols are RSVP. As an LSR processes RSVP messages it > > can, as it makes or changes entries in its forwarding tables, > > assign labels to those entries. > > > Among the properties of this scheme are: > > > - The computational load of assignment and distribution and > > the bandwidth consumed by label distribution are bounded by > > the amount of control traffic in the system. > > > - Labels are in the general case preassigned. If a route > > exists then a label has been assigned to it (and > > distributed). Traffic may be label swapped immediately it > > arrives, there is no label setup latency at forwarding time. > > > - Requires LSRs to be able to process control traffic load > > only. > > > - Depending upon the number of flows supported, this approach > > may require a larger number of labels to be assigned > > compared with topology driven assignment. > > In the above the 4th paragraph says, labels are > preassigned and distributed. How labels are preassigned > and distributed even before the data packet has come to > LER. If the labels are preassigned and distributed , when > LDP request message is used. > > Can somebody answer my query by taking an unlabeled L3 packet as > input to LER. > > thanks, > Sreeni. > > From owner-mpls@UU.NET Wed May 3 12:18: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 MAA05448 for ; Wed, 3 May 2000 12:18: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 QQinph13765; Wed, 3 May 2000 16:18:40 GMT Received: by mail-control.mail.uu.net id QQinph03279 for mpls-outgoing; Wed, 3 May 2000 16:18: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 QQinph03273 for ; Wed, 3 May 2000 16:18: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 QQinph20653 for ; Wed, 3 May 2000 12:17:53 -0400 (EDT) Received: from mta1.mail.onsiteaccess.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.onsiteaccess.net [209.83.168.38]) id QQinph13050 for ; Wed, 3 May 2000 16:17:53 GMT Received: from eagle1.osaccess.net ([209.83.168.75]) by mta1.mail.onsiteaccess.net (InterMail vK.4.02.00.10 201-232-116-110 license 5966c05b3ce4c9d877760f650a55a100) with ESMTP id <20000503161459.UHEE6372.mta1@eagle1.osaccess.net>; Wed, 3 May 2000 12:14:59 -0400 Received: from localhost (jkelly@localhost) by eagle1.osaccess.net (8.8.8+Sun/8.8.8) with SMTP id MAA22636; Wed, 3 May 2000 12:16:08 -0400 (EDT) X-Authentication-Warning: eagle1.osaccess.net: jkelly owned process doing -bs Date: Wed, 3 May 2000 12:16:08 -0400 (EDT) From: Joe Kelly X-Sender: jkelly@eagle1.osaccess.net To: Eric Gray cc: "'ksreeni'" , mpls Subject: RE: LDP request In-Reply-To: <9A564CC874B5D3118FB9009027B0A6622D7C41@ICARIAN> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Get it back man! Smash some heads! :-) On Wed, 3 May 2000, Eric Gray wrote: > Sreeni, > > In the future, please remember to identify the > source of your quote. :-) > > I found this text in "A Framework for MPLS", by > Ross Callon, George Swallow, N. Feldman, C Srinivasan, > P. Doolan, and A. Fredette - dated 09/22/1999. > > This document merely discusses MPLS possibilities. > To see what was actually proposed, read the architecture > draft at > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-06.txt > > To see what has actually been defined, see specific drafts > available at > > http://www.ietf.org/ids.by.wg/mpls.html > > -- > Eric Gray > > > -----Original Message----- > > From: ksreeni [mailto:ksreeni@chiplogic.com] > > Sent: Wednesday, May 03, 2000 4:36 AM > > To: mpls > > Subject: LDP request > > > > > > Hi, > > > > > 3.4.2 Request Driven Label Assignment > > > > > In this scheme labels are assigned in response to normal > > > processing of request based control traffic. Examples of such > > > control protocols are RSVP. As an LSR processes RSVP messages it > > > can, as it makes or changes entries in its forwarding tables, > > > assign labels to those entries. > > > > > Among the properties of this scheme are: > > > > > - The computational load of assignment and distribution and > > > the bandwidth consumed by label distribution are bounded by > > > the amount of control traffic in the system. > > > > > - Labels are in the general case preassigned. If a route > > > exists then a label has been assigned to it (and > > > distributed). Traffic may be label swapped immediately it > > > arrives, there is no label setup latency at forwarding time. > > > > > - Requires LSRs to be able to process control traffic load > > > only. > > > > > - Depending upon the number of flows supported, this approach > > > may require a larger number of labels to be assigned > > > compared with topology driven assignment. > > > > In the above the 4th paragraph says, labels are > > preassigned and distributed. How labels are preassigned > > and distributed even before the data packet has come to > > LER. If the labels are preassigned and distributed , when > > LDP request message is used. > > > > Can somebody answer my query by taking an unlabeled L3 packet as > > input to LER. > > > > thanks, > > Sreeni. > > > > > Joseph Kelly 212-324-1543 Manager of Network Architecture jkelly@onsiteaccess.net OnSite Access From owner-mpls@UU.NET Wed May 3 12:22: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 ESMTP id MAA05543 for ; Wed, 3 May 2000 12:22: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 QQinph17025; Wed, 3 May 2000 16:22:39 GMT Received: by mail-control.mail.uu.net id QQinph03575 for mpls-outgoing; Wed, 3 May 2000 16:22: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 QQinph03567 for ; Wed, 3 May 2000 16:22: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 QQinph28539 for ; Wed, 3 May 2000 12:22:00 -0400 (EDT) Received: from mailhop1.nyroc.rr.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailhop1-1.nyroc.rr.com [24.92.226.166]) id QQinph16478 for ; Wed, 3 May 2000 16:21:59 GMT Received: from mailout2.nyroc.rr.com ([24.92.226.121]) by mailhop1.nyroc.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-59787U250000L250000S0V35) with ESMTP id com for ; Wed, 3 May 2000 12:18:41 -0400 Received: from city ([24.92.231.162]) by mailout2.nyroc.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-59787U250000L250000S0V35) with SMTP id com for ; Wed, 3 May 2000 12:10:14 -0400 Message-ID: <014001bfb51b$7aef22a0$a2e75c18@twcny.rr.com> From: "Taner OKUMUS" To: "mpls" References: <14608.12569.915224.732471@rasputin.ce.chalmers.se> Subject: Re: Network Simulator 2 (ns-2) modules for MPLS and CBQ Date: Wed, 3 May 2000 12:20:21 -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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit check out the following website: http://raonet.com/mns/english.html > Hello all, > > > I've seen some references to label switching (MPLS?) and CBQ modules for > ns-2. Anyone can give me a pointer to them ? I didn't find anything > after a quick look at ns homepage (http://www-mash.cs.berkeley.edu/ns/ns.html) > > > > Regrads, > > > Florian. > > regards; taner From owner-mpls@UU.NET Wed May 3 12:25: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 MAA05576 for ; Wed, 3 May 2000 12:25: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 QQinph08756; Wed, 3 May 2000 16:25:43 GMT Received: by mail-control.mail.uu.net id QQinph03759 for mpls-outgoing; Wed, 3 May 2000 16:25:05 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 QQinph03748 for ; Wed, 3 May 2000 16:25: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 QQinph21925 for ; Wed, 3 May 2000 12:24:53 -0400 (EDT) Received: from ns01.newbridge.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQinph18511 for ; Wed, 3 May 2000 16:24:52 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id MAA21809 for ; Wed, 3 May 2000 12:18:07 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAAy0HvM_; Wed May 3 12:17:59 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Wed, 3 May 2000 12:24:02 -0400 Received: from newbridge.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4118 for ; Wed, 3 May 2000 12:24:08 -0400 Message-Id: <3910527C.8DA2F636@newbridge.com> Date: Wed, 03 May 2000 12:23:24 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls Subject: Status of MPLS Drafts References: <9A564CC874B5D3118FB9009027B0A6622D7C41@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can someone give me an update of the status of the MPLS documents? My last understanding is the following are in IESG and would become a RFC anytime soon: RSVP Tunnels LDP CR-LDP MPLS Architecture MPLS Framework Label Stack Encoding ATM Encaps Is there an RFC number assigned to those draft now? Thanks, Hansen From owner-mpls@UU.NET Wed May 3 14:22: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 OAA08335 for ; Wed, 3 May 2000 14:22: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 QQinpp10585; Wed, 3 May 2000 18:22:32 GMT Received: by mail-control.mail.uu.net id QQinpp25468 for mpls-outgoing; Wed, 3 May 2000 18:22:06 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 QQinpp25463 for ; Wed, 3 May 2000 18:22:04 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 QQinpp20365 for ; Wed, 3 May 2000 14:21:58 -0400 (EDT) Received: from fulcrum by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: fulcrum.ie.cw.net [204.70.128.22]) id QQinpp10127 for ; Wed, 3 May 2000 18:21:58 GMT Received: from cw.net ([204.71.43.27]) by cw.net (PMDF V5.2-32 #43876) with ESMTPA id <0FTZ00HNOXOB5Z@cw.net> for mpls@UU.NET; Wed, 3 May 2000 14:21:47 -0400 (EDT) Date: Wed, 03 May 2000 14:21:44 -0700 From: Ming Lu Subject: Re: Network Simulator 2 (ns-2) modules for MPLS and CBQ Cc: mpls Message-id: <39109868.8BC1186D@cw.net> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en,pdf References: <14608.12569.915224.732471@rasputin.ce.chalmers.se> <014001bfb51b$7aef22a0$a2e75c18@twcny.rr.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit www.wandl.com Taner OKUMUS wrote: > check out the following website: > > http://raonet.com/mns/english.html > > > Hello all, > > > > > > I've seen some references to label switching (MPLS?) and CBQ modules for > > ns-2. Anyone can give me a pointer to them ? I didn't find anything > > after a quick look at ns homepage > (http://www-mash.cs.berkeley.edu/ns/ns.html) > > > > > > > > Regrads, > > > > > > Florian. > > > > > regards; > taner From owner-mpls@UU.NET Wed May 3 17:41: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 RAA11738 for ; Wed, 3 May 2000 17:41: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 QQinqc25072; Wed, 3 May 2000 21:41:08 GMT Received: by mail-control.mail.uu.net id QQinqc29550 for mpls-outgoing; Wed, 3 May 2000 21:40:31 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 QQinqc29545 for ; Wed, 3 May 2000 21:40: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 QQinqc25363 for ; Wed, 3 May 2000 17:40:13 -0400 (EDT) Received: from mx3out.umbc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx3out.umbc.edu [130.85.253.53]) id QQinqc24377 for ; Wed, 3 May 2000 21:40:13 GMT Received: from apollo.mctr.umbc.edu (apollo.mctr.umbc.edu [130.85.101.89]) by mx3out.umbc.edu (8.9.3/8.9.3) with ESMTP id RAA10954 for ; Wed, 3 May 2000 17:40:12 -0400 (EDT) Received: from discovery.mctr.umbc.edu (discovery.mctr.umbc.edu [130.85.101.115]) by apollo.mctr.umbc.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA27621 for ; Wed, 3 May 2000 17:40:11 -0400 (EDT) Received: from localhost (mpls@localhost) by discovery.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id RAA02268 for ; Wed, 3 May 2000 17:43:19 -0400 (EDT) X-Authentication-Warning: discovery.mctr.umbc.edu: mpls owned process doing -bs Date: Wed, 3 May 2000 17:43:19 -0400 (EDT) From: MPLS X-Sender: mpls@discovery.mctr.umbc.edu To: mpls Subject: traces to simulate QoS requests In-Reply-To: <39109868.8BC1186D@cw.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all, We are trying to simulate a workmodel for handling QoS requests. In this respect, are there any publicly available traces for real time call requests that request bandwidth at the ISPs. If not, is there some study that says what is a feasible distribution for the following: 1. b/w requirement of a QoS call 2. QoS call request arrival rate 3. QoS call duration Most of the reserach work has been done using uniform ditsribution for b/w requirement, poisson for arrival rate, and exponential for call duration. How close to the real life scenario are these assumptions. Thanks in advance, Gargi Banerjee From owner-mpls@UU.NET Wed May 3 18:22: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 SAA12130 for ; Wed, 3 May 2000 18:22: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 QQinqf04186; Wed, 3 May 2000 22:22:01 GMT Received: by mail-control.mail.uu.net id QQinqf09944 for mpls-outgoing; Wed, 3 May 2000 22:21: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 QQinqf09929 for ; Wed, 3 May 2000 22:21: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 QQinqf01068 for ; Wed, 3 May 2000 18:21:01 -0400 (EDT) From: lchang4@gmu.edu Received: from portal.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: portalknot.gmu.edu [129.174.0.8]) id QQinqf19525 for ; Wed, 3 May 2000 22:21:01 GMT Received: from gmu.edu (mail01.gmu.edu [129.174.0.6]) by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id SAA04021; Wed, 3 May 2000 18:20:57 -0400 (EDT) Date: Wed, 3 May 2000 18:20:57 -0400 (EDT) To: ksreeni Cc: mpls Message-ID: <1dc8821d5206.1d52061dc882@gmu.edu> X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: LDP request X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sreeni, > In the above the 4th paragraph says, labels are > preassigned and > distributed. How labels are preassigned and distributed even > before the Please refer to the Section 2.2 "Operation of LSP tunnels" and Section 3 "LSP Tunnel related Message Formats" in http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel- 05.txt. > data packet has come to LER. If the labels are preassigned and > distributed , when LDP request message is used. Please refer to the section 2.6 "Label Distribution and Management" in http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-06.txt. Lichung ----- Original Message ----- From: ksreeni Date: Wednesday, May 3, 2000 6:36 am Subject: LDP request > Hi, > > > 3.4.2 Request Driven Label Assignment > > > In this scheme labels are assigned in response to normal > > processing of request based control traffic. Examples of such > > control protocols are RSVP. As an LSR processes RSVP messages it > > can, as it makes or changes entries in its forwarding tables, > > assign labels to those entries. > > > Among the properties of this scheme are: > > > - The computational load of assignment and distribution and > > the bandwidth consumed by label distribution are bounded by > > the amount of control traffic in the system. > > > - Labels are in the general case preassigned. If a route > > exists then a label has been assigned to it (and > > distributed). Traffic may be label swapped immediately it > > arrives, there is no label setup latency at forwarding time. > > > - Requires LSRs to be able to process control traffic load > > only. > > > - Depending upon the number of flows supported, this approach > > may require a larger number of labels to be assigned > > compared with topology driven assignment. > > In the above the 4th paragraph says, labels are > preassigned and > distributed. How labels are preassigned and distributed even > before the > data packet has come to LER. If the labels are preassigned and > distributed , when LDP request message is used. > > Can somebody answer my query by taking an unlabeled L3 packet as > input to LER. > > thanks, > Sreeni. > > > From owner-mpls@UU.NET Thu May 4 05:07: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 ESMTP id FAA01280 for ; Thu, 4 May 2000 05:07: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 QQinrw14558; Thu, 4 May 2000 09:05:18 GMT Received: by mail-control.mail.uu.net id QQinrw08735 for mpls-outgoing; Thu, 4 May 2000 09:04: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 QQinrw08730 for ; Thu, 4 May 2000 09:04: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 QQinrw07707 for ; Thu, 4 May 2000 05:04:44 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQinrw13837 for ; Thu, 4 May 2000 09:03:59 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id OAA07313 for ; Thu, 4 May 2000 14:29:34 -0600 (GMT) Message-ID: <013401bf9d4b$f64fdbc0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: Service Level Agreement parameters Date: Mon, 3 Apr 2000 14:36:49 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0131_01BF9D7A.0B9442E0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0131_01BF9D7A.0B9442E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=20 I am implementing Classical IP over ATM in MPLS domain. For = interworking with other domains I need some agreement parameters with = the customers. Can someone help me out with some references on Service = Level Agreement(SLA) parameters which should be considered. Thanx in advance. santosh ------=_NextPart_000_0131_01BF9D7A.0B9442E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello
    I am implementing Classical IP over ATM in MPLS = domain.=20 For interworking with other domains I need some agreement parameters = with the=20 customers. Can someone help me out with some references on Service = Level=20 Agreement(SLA) parameters which should be considered.
Thanx in advance.

santosh
 
------=_NextPart_000_0131_01BF9D7A.0B9442E0-- From owner-mpls@UU.NET Thu May 4 06:23: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 GAA01715 for ; Thu, 4 May 2000 06:23: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 QQinsb11404; Thu, 4 May 2000 10:23:44 GMT Received: by mail-control.mail.uu.net id QQinsb21135 for mpls-outgoing; Thu, 4 May 2000 10:23: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 QQinsb21130 for ; Thu, 4 May 2000 10:23: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 QQinsb22653 for ; Thu, 4 May 2000 06:23:10 -0400 (EDT) From: peter.van_rompu@alcatel.be Received: from relay1.alcatel.be by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQinsb10849 for ; Thu, 4 May 2000 10:22:54 GMT Received: from bemta001.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.9.1) with SMTP id e44AMMr05135 for ; Thu, 4 May 2000 12:22:23 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C12568D5.0038FA7D ; Thu, 4 May 2000 12:22:21 +0200 X-Lotus-FromDomain: ALCATEL To: mpls@UU.NET Message-ID: Date: Thu, 4 May 2000 12:22:17 +0200 Subject: RE: questions on Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello Joan, Thank you for your reply - I think part of my confusion is because I don't understand the mplsLdpEntityConfGenericTable. From your reply I understand this table is used to configure the label range for Generic Labels. (I assumed that if you use generic labels, it is free to use the full 20bit space (with some reserved values) and there is no need to configure a range). But I still don't understand how you can configure a label range using the mplsLdpEntityConfGenericTable. What is the meaning of the mplsLdpConfGenericLabel object : is it an upper value for this label range ? From the MIB it seems more like all label values within the generic label space need to be configured. I'm also not sure my understanding about the use of ifIndex in the various LDP MIB tables is correct : - About the ifIndex used in the mplsLdpEntityAtmParmsTable : I assume this is a ifIndex which maps to the vpi/vci defined in mplsLdpEntityDefaultControlVpi/mplsLdpEntityDefaultControlVci and that there is no need to create ifIndices for every ATM label. The ifType associated to that ifIndex is = mpls (166). Is this correct ? - From your reply I understand there is a ifIndex associated with a generic label space - what does it model ? (is it a kind of virtual interface such as the AAL5 interface in the AtomMib ? can I derive the physical ports on which it is used through e.g. the ifStackTable ? can a SNMP Manager create such an interface ?). Peter "Cucchiara, Joan" on 05/03/2000 04:35:29 PM To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET cc: Subject: RE: questions on > -----Original Message----- > From: peter.van_rompu@alcatel.be [mailto:peter.van_rompu@alcatel.be] > Sent: Wednesday, May 03, 2000 6:23 AM > To: mpls@UU.NET > Subject: questions on > > > Hello Peter, > > Hello, > > Can somebody help me this the following questions on the use > of the LDP MIB. > > 1) mplsLdpEntityTable > > How can a SNMP Manager derive on which interfaces a LDP entity runs ? > > For LDP entities with mplsLdpEntityOptionalParameters set to > atmParameters(2) or frameRelayParameters(3), my understanding > is that the SNMP manager can derive this from the ifIndex > found in the associated entry in the mplsLdpAtmParmsTable or > mplsLdpFrameRelayParmsTable. Once the SNMP Manager knowns > the ifIndex , the SNMP Manager can use the ifStackTable to > figure out on which ATM/FR port this entity runs (am I correct ?) . yes. > > But how to do this for a LDP entity using generic labels ? This is the same. There is an ifIndex associated with a generic label also. This ifIndex would have the ifType of mpls (166). So in effect this would be the mpls interface layer. > > 2) mplsLdpEntityConfGenericTable > > I'm confused by the DESCRIPTION field of the > mplsLdpEntityConfGenericTable definition : why does a SNMP > Manager need to configure a generic label for LDP ? I thought > it was sufficient for LDP to known the label pools in order > to distribute labels ? Yes this is correct for ATM and Frame Relay, but for Generic Labels there is no mechanism in LDP to distribute a label pool (i.e. label range) for generic labels. (The last sentence of Section 3.5.3 of the LDP spec states: "Note that there is no Generic Session Parameters TLV for sessions which advertise Generic Labels.") > > 2) creation of a MPLS interface and activation of LDP on it. > > How can a SNMP manager create a MPLS interface using the > available MIBs and associate a LDP entity to that newly > created MPLS interface ? > > My understanding is that if the SNMP Manager wants LDP to use > ATM or FrameRelay labels on the MPLS interface, the SNMP > Manager needs to create an entry in the mplsLdpEntityTable, > an entry in the mplsLdpEntityAtmParmsTable (which allows to > configure for > instance the VPI/VCI to be used by LDP) and one or more > entries in the mplsLdpEntityConfAtmLabelRangeTable. As a > result of these row creations, the SNMP agent might create a > new MPLS interface, associate an ifIndex to it and fill the > ifIndex for the newly > created MPLS interface into the mplsLdpEntityTable. (Is this > correct ?) Essentially, yes you are correct. Although how this would take place exactly, would largely depend on when ifIndices are created (which is why the LDP MIB uses InterfaceIndexOrZero and why this is not needed for indexing into these Entity related tables.) In other words, an Entity is created at some point in time. At some other point in time, LSPs are established. The LSPs are between MPLS interfaces. It is upto the implementation on when the ifIndices are assigned, but the LDP MIB does stipulate that once LSP are established these InterfaceIndexOrZero objects need to have the value of the InterfaceIndex. > > But how can a SNMP manager create a new MPLS interface (for > instance on ATM) using generic labels ? In this case the LDP > entity might allready be configured - the only thing I would > exspect to do is to configure somehow a VPI/VCI to be used by this LDP > entity. I don't think this is correct. If it is an ATM interface then ATM labels (vpi,vci) would be used, so generic labels would not be used for this. You could have an incoming labelled packet which is from an ATM interface, forwarded out a PPP interface in which case you would forward using a generic label (for details see the draft-ietf-mpls-label-encaps-07.txt). In that case though, this would be two different labels. -Joan > > Best regards, > > Peter Van Rompu - Alcatel Telecom > > From owner-mpls@UU.NET Thu May 4 08:58: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 ESMTP id IAA05064 for ; Thu, 4 May 2000 08:58: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 QQinsl25149; Thu, 4 May 2000 12:58:16 GMT Received: by mail-control.mail.uu.net id QQinsl16729 for mpls-outgoing; Thu, 4 May 2000 12:57: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 QQinsl16724 for ; Thu, 4 May 2000 12:57:34 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 QQinsl21292 for ; Thu, 4 May 2000 08:57:33 -0400 (EDT) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQinsl07438 for ; Thu, 4 May 2000 12:57:32 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Thu, 4 May 2000 07:56:25 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KHL0HZVS; Thu, 4 May 2000 08:56:21 -0400 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNNLX75H; Thu, 4 May 2000 08:56:22 -0400 Message-ID: <39117373.83474558@americasm01.nt.com> Date: Thu, 04 May 2000 08:56:19 -0400 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls Subject: Re: traces to simulate QoS requests References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS wrote: > > Hi all, > We are trying to simulate a workmodel for handling QoS requests. > > In this respect, are there any publicly available traces for real time > call requests that request bandwidth at the ISPs. > > If not, is there some study that says what is a feasible > distribution for the following: > 1. b/w requirement of a QoS call > 2. QoS call request arrival rate > 3. QoS call duration > > Most of the reserach work has been done using uniform ditsribution > for b/w requirement, poisson for arrival rate, and exponential for call > duration. > How close to the real life scenario are these assumptions. > > Thanks in advance, > > Gargi Banerjee I'm not aware of a source of the data you are looking for however I'd warn you against using any of the nice clean models like poisson etc. You may be able to extrapolate from some existing ATM networks as a starting point. The rate that LSPs arrive, depart and how long they hold will depend on the applications using them and we cannot easily predict what applications will tend to do with them. Initially you will see REALLY long hold times but these will come down in time as more and more uses for LSPs evolve. My gut feeling is that LSPs will eventually have behavior like data only at a slower rate. I.e. chaotic, bursty etc. Cheers, Peter From owner-mpls@UU.NET Thu May 4 11:12: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 ESMTP id LAA07895 for ; Thu, 4 May 2000 11:12: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 QQinsu09150; Thu, 4 May 2000 15:12:07 GMT Received: by mail-control.mail.uu.net id QQinsu17955 for mpls-outgoing; Thu, 4 May 2000 15:11: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 QQinsu17949 for ; Thu, 4 May 2000 15:11: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 QQinsu28108 for ; Thu, 4 May 2000 11:09:50 -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 QQinsu07351 for ; Thu, 4 May 2000 15:09:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA08900 for mpls@uu.net; Thu, 4 May 2000 11:09:47 -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 QQinsu17661 for ; Thu, 4 May 2000 15:09: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 QQinsu27843 for ; Thu, 4 May 2000 11:08:23 -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 QQinsu23581 for ; Thu, 4 May 2000 15:08:23 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 May 2000 11:08:23 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15FA99@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'peter.van_rompu@alcatel.be'" , mpls@UU.NET Subject: RE: questions on Date: Thu, 4 May 2000 11:08:22 -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 Hello Peter, > > Hello Joan, > > Thank you for your reply - I think part of my confusion is > because I don't understand the mplsLdpEntityConfGenericTable. > > From your reply I understand this table is used to configure > the label range for Generic Labels. (I assumed that if you > use generic labels, it is free to use the full 20bit space > (with some reserved values) and there is no need to configure > a range). This table isn't used to configure label ranges; it is used to configure the actual generic labels. For LDP the generic labels are configured as specified in the encaps doc (draft-ietf-mpls-label-encaps-07.txt). > But I still don't understand how you can configure a label > range using the mplsLdpEntityConfGenericTable. What is the Currently, there is no way in LDP to communicate a label range for generic labels in LDP. That is why the MIB doesn't have a mechanism to configure a generic label range. I don't know why this was not included, perhaps someone could answer? > meaning of the mplsLdpConfGenericLabel object : is it an > upper value for this label range ? From the MIB it seems more no, this table configures actual generic labels (not ranges). > like all label > values within the generic label space need to be configured. yes, the MIB provides a mechanism for configuring the actual generic labels only. There is no mechanism in the current version of LDP for distributing a label range for generic labels. > > I'm also not sure my understanding about the use of ifIndex > in the various LDP MIB tables is correct : > > - About the ifIndex used in the mplsLdpEntityAtmParmsTable : > I assume this is a ifIndex which maps to the vpi/vci defined > in > mplsLdpEntityDefaultControlVpi/mplsLdpEntityDefaultControlVci > and that there is no need to create ifIndices for every ATM label. In practice ATM runs on an interface (in this sense a interface being a physical port). The ifLayering for ATM does not change for LDP. In theory you could have ATM (signalling) and ATM (LDP) running over the same physical port. They could have the same ifStack at the lower layers and differ at the upper layers. > The ifType associated to that ifIndex is = mpls (166). Is > this correct ? This is upto an implementation but for generic labels which get placed in a shim header then that would be the mpls (166). For ATM I think this is the cell layer and there would be an "mpls(166) ifLayer" someplace above within the ifStack. If there were label stacks being configured, and a label stack being pushed and/or popped, then this would also be at an ifLayer whose ifType was 166. > - From your reply I understand there is a ifIndex associated > with a generic label space - what does it model ? (is it a I wouldn't say "generic label space", there are perPlatform or perInterface label spaces. Again, I can only say that once data is forwarded using the label, the value of the ifIndex represents where in the ifLayer that the label was created. For generic labels this would be the mpls layer (with ifType 166). > kind of virtual interface such as the AAL5 interface in the > AtomMib ? can I derive the physical ports on which it is used > through e.g. > the ifStackTable ? can a SNMP Manager create such an interface ?). Yes, that is certainly the intention. For LDP a manager can configure the tables under the "Entity" branch and this would result in LDP running on a specific physical port. In other technologies such as IP over ATM or NHRP, it is also necessary to consult the ifStack to understand which physical port the protocols are running over, we specifically tried to follow those other MIB models. -Joan > > Peter > > > > > > "Cucchiara, Joan" on 05/03/2000 04:35:29 PM > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET > > cc: > > > > Subject: RE: questions on > > > > > > > > > > > -----Original Message----- > > From: peter.van_rompu@alcatel.be [mailto:peter.van_rompu@alcatel.be] > > Sent: Wednesday, May 03, 2000 6:23 AM > > To: mpls@UU.NET > > Subject: questions on > > > > > > > > Hello Peter, > > > > > Hello, > > > > Can somebody help me this the following questions on the use > > of the LDP MIB. > > > > 1) mplsLdpEntityTable > > > > How can a SNMP Manager derive on which interfaces a LDP > entity runs ? > > > > For LDP entities with mplsLdpEntityOptionalParameters set to > > atmParameters(2) or frameRelayParameters(3), my understanding > > is that the SNMP manager can derive this from the ifIndex > > found in the associated entry in the mplsLdpAtmParmsTable or > > mplsLdpFrameRelayParmsTable. Once the SNMP Manager knowns > > the ifIndex , the SNMP Manager can use the ifStackTable to > > figure out on which ATM/FR port this entity runs (am I correct ?) . > > yes. > > > > > But how to do this for a LDP entity using generic labels ? > > This is the same. There is an ifIndex associated with a > generic label also. This ifIndex would have the ifType of > mpls (166). So in effect this would be the mpls interface layer. > > > > > 2) mplsLdpEntityConfGenericTable > > > > I'm confused by the DESCRIPTION field of the > > mplsLdpEntityConfGenericTable definition : why does a SNMP > > Manager need to configure a generic label for LDP ? I thought > > it was sufficient for LDP to known the label pools in order > > to distribute labels ? > > Yes this is correct for ATM and Frame Relay, but for Generic > Labels there is no mechanism in LDP to distribute a > label pool (i.e. label range) for generic labels. > (The last sentence of Section 3.5.3 of the LDP > spec states: "Note that there is > no Generic Session Parameters TLV for sessions which > advertise Generic Labels.") > > > > > > 2) creation of a MPLS interface and activation of LDP on it. > > > > How can a SNMP manager create a MPLS interface using the > > available MIBs and associate a LDP entity to that newly > > created MPLS interface ? > > > > My understanding is that if the SNMP Manager wants LDP to use > > ATM or FrameRelay labels on the MPLS interface, the SNMP > > Manager needs to create an entry in the mplsLdpEntityTable, > > an entry in the mplsLdpEntityAtmParmsTable (which allows to > > configure for > > instance the VPI/VCI to be used by LDP) and one or more > > entries in the mplsLdpEntityConfAtmLabelRangeTable. As a > > result of these row creations, the SNMP agent might create a > > new MPLS interface, associate an ifIndex to it and fill the > > ifIndex for the newly > > created MPLS interface into the mplsLdpEntityTable. (Is this > > correct ?) > > Essentially, yes you are correct. Although how this would > take place exactly, would largely depend on when ifIndices are > created (which is why the LDP MIB uses InterfaceIndexOrZero > and why this is not needed for indexing into these Entity > related tables.) > > In other words, an Entity is created at some point in time. > At some other point in time, LSPs are established. The > LSPs are between MPLS interfaces. It is upto the implementation > on when the ifIndices are assigned, but the LDP MIB does stipulate > that once LSP are established these InterfaceIndexOrZero objects > need to have the value of the InterfaceIndex. > > > > > > But how can a SNMP manager create a new MPLS interface (for > > instance on ATM) using generic labels ? In this case the LDP > > entity might allready be configured - the only thing I would > > exspect to do is to configure somehow a VPI/VCI to be used > by this LDP > > entity. > > I don't think this is correct. If it is an ATM interface then > ATM labels (vpi,vci) would be used, so generic labels would not > be used for this. > > You could have an incoming labelled packet which is from > an ATM interface, forwarded out a PPP interface in which > case you would forward using a generic label (for details > see the draft-ietf-mpls-label-encaps-07.txt). In that > case though, this would be two different labels. > > -Joan > > > > > Best regards, > > > > Peter Van Rompu - Alcatel Telecom > > > > > > > From owner-mpls@UU.NET Thu May 4 11:54: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 ESMTP id LAA09217 for ; Thu, 4 May 2000 11:54: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 QQinsx25432; Thu, 4 May 2000 15:54:24 GMT Received: by mail-control.mail.uu.net id QQinsx20744 for mpls-outgoing; Thu, 4 May 2000 15:54:04 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 QQinsx20738 for ; Thu, 4 May 2000 15:53: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 QQinsx07715 for ; Thu, 4 May 2000 11:53:22 -0400 (EDT) Received: from alpha.netvision.net.il by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.netvision.net.il [194.90.1.13]) id QQinsx09295 for ; Thu, 4 May 2000 15:53:21 GMT Received: from localnet.cwnt.co.il (ras3-p22.hfa.netvision.net.il [62.0.147.22]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id SAA24091 for ; Thu, 4 May 2000 18:52:18 +0300 (IDT) Received: from 192.168.0.15 ([192.168.0.15]) by localnet.cwnt.co.il (WinRoute 3.04g) with SMTP; Thu, 4 May 2000 18:10:19 +0300 From: "Yoav Levy" To: Subject: simple question about label encapsulation Date: Thu, 4 May 2000 18:09:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_005E_01BFB5F3.F24805F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-MS-TNEF-Correlator: Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005E_01BFB5F3.F24805F0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit In the MPLS Label Stack Encoding Internet Draft the we have this paragraph 4. Label Value This 20-bit field carries the actual value of the Label. When a labeled packet is received, the label value at the top of the stack is looked up. As a result of a successful lookup one learns: (a) the next hop to which the packet is to be forwarded; (b) the operation to be performed on the label stack before forwarding; this operation may be to replace the top label stack entry with another, or to pop an entry off the label stack, or to replace the top label stack entry and then to push one or more additional entries on the label stack. My problem is this sentence about the label at the top of the stack - “As a result of a successful lookup one learns (a) the next hop” In case of penultimate LSR that do not supports pop operation the egress LSR should do lookup according to underlying label / IP header. ------=_NextPart_000_005E_01BFB5F3.F24805F0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjUQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5wQAAAAAAADrAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHBQAEABIACQAAAAQA/wAB A5AGAGQNAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAKgAAAHNpbXBsZSBxdWVzdGlvbiBhYm91dCBsYWJlbCBlbmNhcHN1bGF0aW9uAAAAAgFxAAEA AAAWAAAAAb+14xNx6aLqRSADEdSgJQAErNaoRwAAAgEdDAEAAAAUAAAAU01UUDpZTEVWWUBDV05U LkNPTQALAAEOAAAAAEAABg4ANsoO47W/AQIBCg4BAAAAGAAAAAAAAAD6AWPmb/3TEaAKAASs1qhH woAAAAsAHw4BAAAAAgEJEAEAAAA6CQAANgkAABAbAABMWkZ1ubkYNQcABgEBC2BuZzEwMyY3AGQA cmNwDdAyNfo1DGBjDUQBMAMwAQcNpfIzEFZmZRDSAfcCpANjiQIAY2gKwHNldALRUHBycTIAACoK oW6ybxOQIDAB0AHQNg3wcDA1MDQVYQHQFVA0fn0HbQKDAFAD1BM/FEti/xUhFZAU8ho0FhAHExck DhBREt0yMzgYlCAHbSD8Q0UXJBzRG90VgBzvHfWceXICgwwBEt0xNhdx6yA/A4JHCdFrIbQXcSJO djIjXx30VAhwIbQmoWLYaWRpAzEitjcboSbfIQOCKEhlYglwdyn/IbQRACjfHN8q9gcQAaAOsGcr 1SABIk04Ni2PHfRC/QdAdA6wIbQPIBedHLgHE/0eRjIxATN9H/c09SGWLXHvF6wjKDT0JMk5OI8m lzT0vygmFVAsXynXNPQrazMXcfcsfz8cLwozJqE4rTD3NPRXMoYCkQjmOwlvMEb/Zf8PAUgqDwJJ D0oYSBQPAkif/0xvTC1Lr0nfSC8RoDhgUfr/UxFSz1PZSBRUAlJvVj9V/fdVf1OvV3Q5JqBaxFwh VENDXCACgnN0eWwHkGh1CeB0AABxCVAUkAPwZGhjdGwKsVxeqA1gauZ1XZAFEGdoBUFeUQAg/mwY EABgATFhQAvxAzAyoA5yYREXY2Gyc25leN8YcAewBbAAwAJzcwBQXlFMc2IvwAFAc2EVMFz6awng cAuQXo9e8whgXuD1C4BlXcB2ZyBhYV//YQO/DDBhRi1wZQAEoAuAZzhgX2HWDDBiVGm7ZFBhGFBk nwIgYrhd8A1gahEgMV1T/yagZC9lP2ZPZ1ENQmfPaNX/DmFhXgwyYlhsT21WXUQRAP9uX29vcH9n USagcd9ovnQZs3Tvdf8gMwKCFFBjY/CfD9ENYD4gMrBnUCBEARCkYXUyoCBQCsBhCcDgYXBoIEYC IWO0DyDRXlFmaS0N4DgBQGbwz4OjeN9e8yuQZHIJUIXCsxfghcJ3NFFhGEBwYbL/ex9g/2INfn2D EIHQBRACMFYtgnADYToxcG+MYFModWJqBZB0jGBEYfh0ZTpjtDEAg0+EX4Vv/4Z/h4+Ik13gbXMO 8YCiaRjfMWBqfZVBio+Ll1JnQRhB/iArcA1hIaNj8A4Qji+PP9+QT5FfZs+Sn5OoMKCACND6Ygqw dGpRfH99iomADbOfL8CWbzDRmBELUHkvgoD3kZALEZiVc2O0LXCZj5qf/5uvnL+er4ifia+j/6UL jIJ/jCSNWTswXl9fb6uboMM5H4CxrH+tj5cWtMBEb2P+dQeAAjAF0IJAgBaqxID196v6gaAAYGMh 8LWGupG60+N+ZoCRSHlwBJCd8SUBpn0KobzRdzFcEDAOEDW9g2gjIDh38QDAcmfZcaA3OQ4QvwJy v1Nh8f8YULIAAzCx0bHAsgCpcQGA/m6M4ABgCfCA4LfQAgFjcH2TwmUA8LfQXaC80CagdukIkHdr C4BkIADDggTw/wdAEaEBQA7QqUJtUsTlAhDebwVCGGEUMo1wbQtRjXBRHkA6XFyLsG+CIW1vgnAD EAeQx5BNDrADYHNybwGAIE8BIA6wwtBcgclGRU1BSUwufrD+dL1gYfEKs3eSjQGlsMA22Qqgc3o7 MJ3yeAFAbVLxBJB5NzA7McYRzZUI4exzeM3CweFuXfBHEMuUPYF0YwMgFDMAgAWQbHbfcaF4oA9A Y3DQ4XEA4NDx/wGQACDRcsPRuBEBwdDhGCCfDcAAAHigDNABkCAuRjL/0NgmoNGSYfHR/9MP1B/R FP8RAHigBYHWH9cv2D/RFCAA33igrCDV79r/3Akp1KwPIPfZz97/2+liK1ACkeBv0SP/MQDdz+Lf 4+/k/9EFviHmof/R3+f/6Q/qH9FQLXDmn+xv/+1/7o/RBTsw62/xT/Jf82n/Cvm1g7IysYGxj7Kf q5KsD59h/AAC/MG007WFIEkCkd3+vyADoP/v/5J0XfABT9H/g01QTAXwTKFAniCDBgAMkGNrIEVu COD/bYIC7/+SAt//hBIwaeEYYH+BUC8QwXAHLwbTAq//VnfvFMAYIIExCrBpCv//ki4w/wz/Bt8K F8shghEPz/+SgkHzEX//kg0K+NIPvw9vE6//+MT5j/qfsu0WLxXfHAcd0vQ0LgR1VsSAR/AUTxa/ dx9/HZgd0lQM0C4wovAtvz4AxjCm8J4gpbDEcHKrYKcuIQqyusB0dUKhdh7S7iDJAAqjBIMuIN8g LycP/SJMV13w+XDckKMgBKFHIH8RAQUQCNEjQUcQyYCBIWQ+LAqjKyMlZY1gCqN0b/5wKG8pfx3R JdX10QURI0HNRpBveHClsHVwHkA04PcsINyQRxBzgaIl0dyQMwD2Y8mAONBmgaAxwzJALo9/HT01 Lx2nfsAtAW1gafBzPjo0vye/OW8iTB3RKGH+KQqjYvJtQC5gLkEMMAzQfwJ1K6g+UQSgI9ClZEcg O886zzofQS88PyhiPWQuYPtp4I1gaX7AP7W80cJSK3H/RfIs9zFEBKDCUR8PQ488eXtAJWoROwyy LCBFiGOAef8/4j5RUhDHEcmALg9JT0pf/0eKTy8cQ7gRzaAMMCOwEqG7GSAKsXIswGNgPkJwPiH3 ozBTdckAZk6/T88iiEdd/1SmTc1Hi1ODVi9XPyKIozD3pbAKsUYDcLNAgmA4UlTB/m1IgRKwgON+ wCVBU4Ikgv9HJBdvGH8ZjxqfXU9Qr0fV/9SQZm9CX2nfau8Dt01AbO/7ENPI0GKeMMgQI0Bubwpl /yNBmHBwXwDzjXAFUHIfHDT/oUCdwQqvChcrI3XfdOQt998lxnd/DgNR7xwHLXufHE/LChejEGRv 4HF1ziF+X///gzKfM6+Ab34fChc4WIU//4TvChc9ToiPf3PF0H/vh7//jR9sf47fj+8IJSQxmHEl 0e+RvxDTweCCMWm/AMdBBFD+UpO/je8CGS3hrlABIMYh/YLAcFUgl4AOTxC1eVJFlt+Z/wpmnB+X DwoXZRFQM+H/lb+efw18PhA0IKWwrlCiX/+iD3aYg4+k/xHtM8BGwAWPbwooPmCqj/+SdfZxwUB5 Z6pfqC92byAvr1//hFD/sT+vHwoXzVS0D/+SHkC1vz+RD7ePuJ+zb7lfumN9AAG98AAACwAAgAgg BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAA AAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAnagEAHgAlgAggBgAAAAAAwAAAAAAAAEYAAAAA VIUAAAEAAAAEAAAAOS4wAAMAJoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAvgAggBgAA AAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADCACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMA MoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgBBgAggBgAAAAAAwAAAAAAAAEYAAAAANoUA AAEAAAABAAAAAAAAAB4AQoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAEOA CCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwDbgAggBgAAAAAAwAAAAAAAAEYA AAAAgoUAAAEAAAALAPmACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAIB+A8BAAAAEAAAAPoB Y+Zv/dMRoAoABKzWqEcCAfoPAQAAABAAAAD6AWPmb/3TEaAKAASs1qhHAgH7DwEAAABOAAAAAAAA ADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpc V0lOTlRcb3V0bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAuAAAAPE5EQkJLQUFL UEtBRk1QREFNSExLTUVNRUNBQUEueWxldnlAY3dudC5jb20+AAAAAwAGEFCKsAkDAAcQ2AIAAAMA EBAAAAAAAwAREAEAAAAeAAgQAQAAAGUAAABJTlRIRU1QTFNMQUJFTFNUQUNLRU5DT0RJTkdJTlRF Uk5FVERSQUZUVEhFV0VIQVZFVEhJU1BBUkFHUkFQSDRMQUJFTFZBTFVFVEhJUzIwLUJJVEZJRUxE Q0FSUklFU1RIRUFDAAAAAEeO ------=_NextPart_000_005E_01BFB5F3.F24805F0-- From owner-mpls@UU.NET Thu May 4 12:55: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 ESMTP id MAA11087 for ; Thu, 4 May 2000 12:55: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 QQintb06669; Thu, 4 May 2000 16:55:52 GMT Received: by mail-control.mail.uu.net id QQintb02344 for mpls-outgoing; Thu, 4 May 2000 16:55: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 QQintb02339 for ; Thu, 4 May 2000 16:55:13 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 QQintb19181 for ; Thu, 4 May 2000 12:55:02 -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 QQintb21883 for ; Thu, 4 May 2000 16:55:01 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Thu, 4 May 2000 12:40:50 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 May 2000 12:40:44 -0400 Message-ID: From: "Bassam Fadlallah" To: "'mpls@UU.NET'" Subject: IPv6 in MPLS drafts Date: Thu, 4 May 2000 12:40:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB5E7.7DBF8700" 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_01BFB5E7.7DBF8700 Content-Type: text/plain; charset="iso-8859-1" Hi: I'd like to know if any consideration for IPv6 in MPLS drafts or working docs and where? Thanks, Bassam Fadlallah ------_=_NextPart_001_01BFB5E7.7DBF8700 Content-Type: text/html; charset="iso-8859-1" IPv6 in MPLS drafts

Hi:


I'd like to know if any consideration for  IPv6 in MPLS drafts or working docs and where?

Thanks,

Bassam Fadlallah


------_=_NextPart_001_01BFB5E7.7DBF8700-- From owner-mpls@UU.NET Thu May 4 16:05: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 QAA15668 for ; Thu, 4 May 2000 16:05: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 QQinto20208; Thu, 4 May 2000 20:05:03 GMT Received: by mail-control.mail.uu.net id QQinto13944 for mpls-outgoing; Thu, 4 May 2000 20:04: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 QQinto13926 for ; Thu, 4 May 2000 20:04:14 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 QQinto25746 for ; Thu, 4 May 2000 16:04:01 -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 QQinto19254 for ; Thu, 4 May 2000 20:03:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA22090 for mpls@uu.net; Thu, 4 May 2000 16:03:48 -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 QQinto13836 for ; Thu, 4 May 2000 20:03: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 QQinto25567 for ; Thu, 4 May 2000 16:02: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 QQinto03360 for ; Thu, 4 May 2000 20:02:55 GMT Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA21958 for ; Thu, 4 May 2000 16:02:54 -0400 (EDT) Message-Id: <4.2.0.58.20000504160409.00a5c9d0@pilgrim.cisco.com> X-Sender: rschmitt@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 04 May 2000 16:06:54 -0700 To: mpls@UU.NET From: Rob Schmitt Subject: LDP MIB - mplsLdpLsrObjects Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I would like to ask about the LDP MIB object mplsLdpLsrLabelRetentionMode. It is currently specified in the draft (05) as being an mplsLdpLsrObject (globally applicable objects). I think it would be desirable to be able to apply this object as an attribute on a per ENTITY basis, which is not possible as the current rev is written. Thank you. +-----------------------------------------------------------------+ Robert Schmitt CISCO SYSTEMS rschmitt@cisco.com Chelmsford, MA 978-244-3076 +----------------------------------------------------------------+ From owner-mpls@UU.NET Thu May 4 16:40: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 QAA16501 for ; Thu, 4 May 2000 16:40: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 QQintq28549; Thu, 4 May 2000 20:40:43 GMT Received: by mail-control.mail.uu.net id QQintq16226 for mpls-outgoing; Thu, 4 May 2000 20:40:08 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 QQintq16221 for ; Thu, 4 May 2000 20:40: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 QQintq12194 for ; Thu, 4 May 2000 16:39:53 -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 QQintq27771 for ; Thu, 4 May 2000 20:39:53 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id QAA15461; Thu, 4 May 2000 16:39:52 -0400 (EDT) Date: Thu, 4 May 2000 16:39:52 -0400 (EDT) From: Rajiv Papneja To: Yoav Levy cc: mpls@UU.NET Subject: Re: simple question about label encapsulation In-Reply-To: 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 QAA16501 Hi Please see the insert : On Thu, 4 May 2000, Yoav Levy wrote: > In the MPLS Label Stack Encoding Internet Draft the we have this paragraph > > 4. Label Value > > This 20-bit field carries the actual value of the Label. > > When a labeled packet is received, the label value at the top > of the stack is looked up. As a result of a successful lookup > one learns: > > (a) the next hop to which the packet is to be forwarded; > > (b) the operation to be performed on the label stack before > forwarding; this operation may be to replace the top > label stack entry with another, or to pop an entry off > the label stack, or to replace the top label stack entry > and then to push one or more additional entries on the > label stack. > > My problem is this sentence about the label at the top of the stack - “As a > result of a successful lookup one learns (a) the next hop” > > In case of penultimate LSR that do not supports pop operation the egress LSR > should do lookup according to underlying label / IP header. Comments : if the Penultimate LSR do not support poping then in this scenario, the egress LSR has to do two label lookups or one label lookup and network address lookup. For further reading please refer to the Section 3.16. "Penultimate Hop Popping" (http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-06.txt) Comments Take Care Rajiv > > ******************************** 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 Thu May 4 17:11: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 RAA17787 for ; Thu, 4 May 2000 17:11: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 QQints04099; Thu, 4 May 2000 21:10:30 GMT Received: by mail-control.mail.uu.net id QQints25726 for mpls-outgoing; Thu, 4 May 2000 21:10: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 QQints25684 for ; Thu, 4 May 2000 21:09:59 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 QQints08434 for ; Thu, 4 May 2000 17:09:45 -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 QQints03403 for ; Thu, 4 May 2000 21:09:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA01903 for mpls@uu.net; Thu, 4 May 2000 17:09: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 QQints25670 for ; Thu, 4 May 2000 21:09: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 QQints08352 for ; Thu, 4 May 2000 17:09:18 -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 QQints03104 for ; Thu, 4 May 2000 21:09:17 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 RAA19016 for ; Thu, 4 May 2000 17:09:12 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA13317 for ; Thu, 4 May 2000 17:09:11 -0400 (EDT) Message-Id: <200005042109.RAA13317@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Second WG last call on LSR MIB Date: Thu, 04 May 2000 17:09:11 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks - The previous last call resulted in enough changes that a second WG last call is in order. The purpose of this last call is not to raise new issues, but to insure that the issues raised in the previous last call have been satisfactorily addressed. As always, things that are just plain broken are always fair game. The last call will end Thurday, May 11, 5 pm edt. The draft is: MPLS Label Switch Router Management Information Base Using SMIv2 draft-ietf-mpls-lsr-mib-04.txt ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu May 4 17:33: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 RAA18720 for ; Thu, 4 May 2000 17:33: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 QQintu04473; Thu, 4 May 2000 21:33:07 GMT Received: by mail-control.mail.uu.net id QQintu27228 for mpls-outgoing; Thu, 4 May 2000 21:32: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 QQintu27223 for ; Thu, 4 May 2000 21:32: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 QQintu21671 for ; Thu, 4 May 2000 17:32: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 QQintu03691 for ; Thu, 4 May 2000 21:32:04 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA04750 for mpls@uu.net; Thu, 4 May 2000 17:32:03 -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 QQintu27207 for ; Thu, 4 May 2000 21:31: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 QQintu12491 for ; Thu, 4 May 2000 17:31:22 -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 QQintu03272 for ; Thu, 4 May 2000 21:31:22 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 May 2000 17:31:21 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15FA9D@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Rob Schmitt'" , mpls@UU.NET Subject: RE: LDP MIB - mplsLdpLsrObjects Date: Thu, 4 May 2000 17:31:12 -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 Robert, This was a previous request also and is on our list. The object will be removed from scalars which apply to the LSR as a whole, and added to each Entity. Thanks, Joan > -----Original Message----- > From: Rob Schmitt [mailto:rschmitt@cisco.com] > Sent: Thursday, May 04, 2000 7:07 PM > To: mpls@UU.NET > Subject: LDP MIB - mplsLdpLsrObjects > > > > > I would like to ask about the LDP MIB object > mplsLdpLsrLabelRetentionMode. > > It is currently specified in the draft (05) as > being an mplsLdpLsrObject (globally applicable > objects). I think it would be desirable to be > able to apply this object as an attribute on a > per ENTITY basis, which is not possible as the > current rev is written. > > Thank you. > +-----------------------------------------------------------------+ > Robert Schmitt CISCO SYSTEMS > rschmitt@cisco.com > Chelmsford, MA 978-244-3076 > +----------------------------------------------------------------+ > > > From owner-mpls@UU.NET Fri May 5 02:19: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 CAA11004 for ; Fri, 5 May 2000 02:19: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 QQinvd24159; Fri, 5 May 2000 06:16:55 GMT Received: by mail-control.mail.uu.net id QQinvd05613 for mpls-outgoing; Fri, 5 May 2000 06:16: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 QQinvd05608 for ; Fri, 5 May 2000 06:16:26 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 QQinvd24142 for ; Fri, 5 May 2000 02:16:09 -0400 (EDT) Received: from hd2.dot.net.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hd2.vsnl.net.in [202.54.30.2]) id QQinvd07788 for ; Fri, 5 May 2000 06:16:08 GMT Received: from hyd.chiplogic.com ([203.197.20.215]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id LAA26985 for ; Fri, 5 May 2000 11:40:24 +0530 (IST) Received: from chiplogic.com ([192.168.2.59]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id KAA01013 for ; Fri, 5 May 2000 10:52:59 +0530 Message-ID: <39125E86.2EDEC29B@chiplogic.com> Date: Fri, 05 May 2000 11:09:18 +0530 From: ksreeni X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls Subject: deployment 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 on the deployment of MPLS. Below I have given one practical example, So can somebody resolve my questions? _______ _______ H1------------| | WAN link | | H2------------| R |------------------------| ISP | H3------------| | | | ---------- ---------- Router at LER customer place In the above diagram R is the router at customer place ,having 3 hosts in the subnet and it is connected to ISP through WAN link. And ISP is an LER in the MPLS domain. (1) Do I need to deploy MPLS on my router? If yes, what are the benifits? (2) As per my knowledge , I am not finding any necessity of MPLS & LDP on end Host. Is that correct? (3) If ISP provides QOS based on the COS field in the SHIM header and the customer subscribed some BW at ISP. Then , Is that possible for ISP to policy the customer traffic at MPLS layer itself? Thanks, Sreeni. From owner-mpls@UU.NET Fri May 5 06:28: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 ESMTP id GAA12994 for ; Fri, 5 May 2000 06:28: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 QQinvt06785; Fri, 5 May 2000 10:28:01 GMT Received: by mail-control.mail.uu.net id QQinvt19690 for mpls-outgoing; Fri, 5 May 2000 10:27:32 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 QQinvt19683 for ; Fri, 5 May 2000 10:27: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 QQinvt19423 for ; Fri, 5 May 2000 06:27:03 -0400 (EDT) Received: from relay1.alcatel.be by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQinvt14331 for ; Fri, 5 May 2000 10:27:02 GMT Received: from sh.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e45AQob28634 for ; Fri, 5 May 2000 12:26:50 +0200 (MET DST) Received: from alcatel.be ([138.203.196.92]) by sh.bel.alcatel.be (8.7/8.7) with ESMTP id MAA19704 for ; Fri, 5 May 2000 12:23:18 +0200 (MET DST) Message-ID: <3912A0E1.8E68BACE@alcatel.be> Date: Fri, 05 May 2000 12:22:25 +0200 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: mpls multicast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, The working group draft "Framework for MPLS multicast" exists for a while now. We have the feeling it gives a fairly good overview of the issues and possible solutions, but at regular times the message pops up (in the Working Group meeting and on the list) that multicast in MPLS needs further study. Can anyone on the list make this remark more concrete and indicate uncovered issues/dimensions that need coverage in a framework document? We would be glad to explore/investigate them. The draft is at: http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-01.txt cheers, dirk From owner-mpls@UU.NET Fri May 5 08:54:10 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 IAA17289 for ; Fri, 5 May 2000 08:54: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 QQinwd04191; Fri, 5 May 2000 12:54:09 GMT Received: by mail-control.mail.uu.net id QQinwd15086 for mpls-outgoing; Fri, 5 May 2000 12:53: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 QQinwd15081 for ; Fri, 5 May 2000 12:53: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 QQinwd07262 for ; Fri, 5 May 2000 08:53:16 -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 QQinwd03533 for ; Fri, 5 May 2000 12:53:13 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 05 May 2000 18:33:30 +0530 Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id SAA14852 for ; Fri, 5 May 2000 18:11:59 +0530 Received: by localhost with Microsoft MAPI; Fri, 5 May 2000 18:18:29 +0530 Message-Id: <01BFB6BE.504F9EE0.manis@future.futsoft.com> From: manikantan To: "'mpls@uu.net'" Cc: "'manis'" Subject: LDP Abort message notification Date: Fri, 5 May 2000 18:18:28 +0530 Importance: high X-Priority: 1 (Highest) 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 Hello Can some one clarify my doubts? When a downstream LSR (LDP Peer) receives an LDP Abort message from its upstream LSR (LDP Peer) it is expected to respond with a notification message with status indicating "Label Request Aborted - 0x00000015". My doubts are 1) What should be message id value in the Status TLV that is to be sent in the notification message? a) Should the message id value be the message id value of the Label request message received from the upstream peer earlier (for which the abort is sent now)? b) or Should the message id value be the message id value of the Label Abort message received from the upstream peer? 2) If the message id is to be the value of the one that is received in the label Abort message, then how do we indicate the message id of the earlier received Label Request message. ( this is required to locate the LSP control block). Should the message id of the earlier received Label Request message be sent in the Optional parameter - Extended Status? Thanks in advance with best regards mani From owner-mpls@UU.NET Fri May 5 09:25: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 JAA18153 for ; Fri, 5 May 2000 09:25: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 QQinwf24201; Fri, 5 May 2000 13:25:41 GMT Received: by mail-control.mail.uu.net id QQinwf25693 for mpls-outgoing; Fri, 5 May 2000 13:25:17 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 QQinwf25688 for ; Fri, 5 May 2000 13:25: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 QQinwf12577 for ; Fri, 5 May 2000 09:24:59 -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 QQinwf16070 for ; Fri, 5 May 2000 13:24:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA29662 for mpls@uu.net; Fri, 5 May 2000 09:24: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 QQinwf25667 for ; Fri, 5 May 2000 13:24:36 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 QQinwf08468 for ; Fri, 5 May 2000 09:24:35 -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 QQinwf23444 for ; Fri, 5 May 2000 13:24:34 GMT Received: from focal.cisco.com (focal.cisco.com [171.69.204.16]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09699; Fri, 5 May 2000 09:24:24 -0400 (EDT) Received: from localhost (rhthomas@localhost) by focal.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA09842; Fri, 5 May 2000 09:24:23 -0400 (EDT) Message-Id: <200005051324.JAA09842@focal.cisco.com> X-Authentication-Warning: focal.cisco.com: rhthomas owned process doing -bs To: manikantan cc: "'mpls@uu.net'" , "'manis'" Subject: Re: LDP Abort message notification In-reply-to: Your message of "Fri, 05 May 2000 18:18:28 +0530." <01BFB6BE.504F9EE0.manis@future.futsoft.com> Date: Fri, 05 May 2000 09:24:23 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Mani, > Can some one clarify my doubts? > > When a downstream LSR (LDP Peer) receives an LDP Abort > message from its upstream LSR (LDP Peer) it is expected to > respond with a notification message with status indicating > "Label Request Aborted - 0x00000015". > > My doubts are > 1) What should be message id value in the Status TLV > that is to be sent in the notification message? > > a) Should the message id value be the message id > value of the Label request message received from the > upstream peer earlier (for which the abort is sent now)? > b) or Should the message id value be the message id > value of the Label Abort message received from the > upstream peer? It should be b), the message id of the received Label Abort message. > 2) If the message id is to be the value of the one that is > received in the label Abort message, then how do > we indicate the message id of the earlier received > Label Request message. ( this is required to locate > the LSP control block). From Section 3.5.9.1. Label Abort Request Message Procedures of draft-ietf-mpls-ldp-0x.txt: When an LSR receives a Label Abort Request message, if it has not previously responded to the Label Request being aborted with a Label Mapping message or some other Notification message, it must acknowledge the abort by responding with a Label Request Aborted Notification message. The Notification must include a Label Request Message ID TLV that carries the message ID of the aborted Label Request message. Bob > Should the message id of the earlier received Label > Request message be sent in the Optional parameter - > Extended Status? From owner-mpls@UU.NET Fri May 5 09:34: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 ESMTP id JAA18433 for ; Fri, 5 May 2000 09:34: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 QQinwg22396; Fri, 5 May 2000 13:34:32 GMT Received: by mail-control.mail.uu.net id QQinwg26248 for mpls-outgoing; Fri, 5 May 2000 13:33: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 QQinwg26241 for ; Fri, 5 May 2000 13:33:53 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 QQinwg14177 for ; Fri, 5 May 2000 09:33:47 -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 QQinwg29830 for ; Fri, 5 May 2000 13:33:45 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 05 May 2000 19:14:04 +0530 Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id SAA15627; Fri, 5 May 2000 18:52:34 +0530 Received: by localhost with Microsoft MAPI; Fri, 5 May 2000 18:58:58 +0530 Message-Id: <01BFB6C3.F7B9F360.manis@future.futsoft.com> From: manikantan To: "'Bob Thomas'" , manikantan Cc: "'mpls@uu.net'" , "'manis'" Subject: RE: LDP Abort message notification Date: Fri, 5 May 2000 18:58:56 +0530 Importance: high X-Priority: 1 (Highest) 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 Bob, Thanks for the reply. I have a doubt still mentioned below. # #> Can some one clarify my doubts? #> #> When a downstream LSR (LDP Peer) receives an LDP Abort #> message from its upstream LSR (LDP Peer) it is expected to #> respond with a notification message with status indicating #> "Label Request Aborted - 0x00000015". #> #> My doubts are #> 1) What should be message id value in the Status TLV #> that is to be sent in the notification message? #> #> a) Should the message id value be the message id #> value of the Label request message received from the #> upstream peer earlier (for which the abort is sent now)? #> b) or Should the message id value be the message id #> value of the Label Abort message received from the #> upstream peer? # #It should be b), the message id of the received Label Abort message. # # #> 2) If the message id is to be the value of the one that is #> received in the label Abort message, then how do #> we indicate the message id of the earlier received #> Label Request message. ( this is required to locate #> the LSP control block). # # #>From Section 3.5.9.1. Label Abort Request Message Procedures of #draft-ietf-mpls-ldp-0x.txt: # # When an LSR receives a Label Abort Request message, if it has not # previously responded to the Label Request being aborted with a Label # Mapping message or some other Notification message, it must # acknowledge the abort by responding with a Label Request Aborted # Notification message. The Notification must include a Label Request # Message ID TLV that carries the message ID of the aborted Label # Request message. # # #Bob But when we say that the Notification must include a Label Request Message ID TLV, the normal format of the Notification message allows for the status TLV and three optional parameters the extended status, the returned message and returned PDU types. so, how do we fit the Request Message ID TLV here? Do I make the assumption/understand as 1) The message id in the Status TLV of the Notification message is equal to the one received in the Label Abort message. 2) The 2 byte message type in the status TLV set to Label Abort message 3) (Looking at the Abort message type), The info after the status TLV in the notification message be filled with Label Request Message ID TLV? OR Send in an optional parameter TLV with Returned Message type, Return the Label Abort message itself back. thanks in advance with best regards mani From owner-mpls@UU.NET Fri May 5 10:00:11 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 KAA19275 for ; Fri, 5 May 2000 10:00:11 -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 QQinwi09035; Fri, 5 May 2000 14:00:11 GMT Received: by mail-control.mail.uu.net id QQinwh27654 for mpls-outgoing; Fri, 5 May 2000 13:59: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 QQinwh27649 for ; Fri, 5 May 2000 13: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 QQinwh14910 for ; Fri, 5 May 2000 09:59:08 -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 QQinwh16497 for ; Fri, 5 May 2000 13:59:07 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA04347 for mpls@uu.net; Fri, 5 May 2000 09:59:06 -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 QQinwh27613 for ; Fri, 5 May 2000 13:58: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 QQinwh14762 for ; Fri, 5 May 2000 09:58:18 -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 QQinwh15944 for ; Fri, 5 May 2000 13:58:18 GMT Received: from focal.cisco.com (focal.cisco.com [171.69.204.16]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA13440; Fri, 5 May 2000 09:58:15 -0400 (EDT) Received: from localhost (rhthomas@localhost) by focal.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA18699; Fri, 5 May 2000 09:58:14 -0400 (EDT) Message-Id: <200005051358.JAA18699@focal.cisco.com> X-Authentication-Warning: focal.cisco.com: rhthomas owned process doing -bs To: manikantan , "'mpls@uu.net'" Subject: Re: LDP Abort message notification In-reply-to: Your message of "Fri, 05 May 2000 18:58:56 +0530." <01BFB6C3.F7B9F360.manis@future.futsoft.com> Date: Fri, 05 May 2000 09:58:14 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Mani, > Thanks for the reply. I have a doubt still mentioned below. > > # > #> Can some one clarify my doubts? > #> > #> When a downstream LSR (LDP Peer) receives an LDP Abort > #> message from its upstream LSR (LDP Peer) it is expected to > #> respond with a notification message with status indicating > #> "Label Request Aborted - 0x00000015". > #> > #> My doubts are > #> 1) What should be message id value in the Status TLV > #> that is to be sent in the notification message? > #> > #> a) Should the message id value be the message id > #> value of the Label request message received from the > #> upstream peer earlier (for which the abort is sent now)? > #> b) or Should the message id value be the message id > #> value of the Label Abort message received from the > #> upstream peer? > # > #It should be b), the message id of the received Label Abort message. > # > # > #> 2) If the message id is to be the value of the one that is > #> received in the label Abort message, then how do > #> we indicate the message id of the earlier received > #> Label Request message. ( this is required to locate > #> the LSP control block). > # > # > #>From Section 3.5.9.1. Label Abort Request Message Procedures of > #draft-ietf-mpls-ldp-0x.txt: > # > # When an LSR receives a Label Abort Request message, if it has not > # previously responded to the Label Request being aborted with a Label > # Mapping message or some other Notification message, it must > # acknowledge the abort by responding with a Label Request Aborted > # Notification message. The Notification must include a Label Request > # Message ID TLV that carries the message ID of the aborted Label > # Request message. > # > # > #Bob > > But when we say that the Notification must include > a Label Request Message ID TLV, the normal format of the > Notification message allows for the status TLV and three optional parameters > the extended status, the returned message and returned PDU types. > > so, how do we fit the Request Message ID TLV here? Please note the following from 3.5.1. Notification Message: Optional Parameters ... *** Other Optional Parameters, specific to the particular event being *** signaled by the Notification Messages may appear. These are *** described elsewhere. One such place is Section 3.5.9.1. Label Abort Request Message Procedures. > Do I make the assumption/understand as > > 1) The message id in the Status TLV of the Notification message > is equal to the one received in the Label Abort message. Yes. > 2) The 2 byte message type in the status TLV set to Label Abort > message Yes. > 3) (Looking at the Abort message type), ??? > The info after the status TLV > in the notification message be filled with Label Request Message ID TLV? Yes. Bob > OR Send in an optional parameter TLV with Returned Message type, > Return the Label Abort message itself back. From owner-mpls@UU.NET Sat May 6 18:57: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 SAA24813 for ; Sat, 6 May 2000 18:57: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 QQiobj07199; Sat, 6 May 2000 22:57:31 GMT Received: by mail-control.mail.uu.net id QQiobj24505 for mpls-outgoing; Sat, 6 May 2000 22:57: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 QQiobj24493 for ; Sat, 6 May 2000 22:57: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 QQiobj06866 for ; Sat, 6 May 2000 18:56:43 -0400 (EDT) Received: from mx1out.umbc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.253.51]) id QQiobj06642 for ; Sat, 6 May 2000 22:56:43 GMT Received: from apollo.mctr.umbc.edu (apollo.mctr.umbc.edu [130.85.101.89]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id SAA21775 for ; Sat, 6 May 2000 18:56:42 -0400 (EDT) Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.8.8+Sun/8.8.8) with ESMTP id SAA09075 for ; Sat, 6 May 2000 18:56:41 -0400 (EDT) Received: from localhost (mpls@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id SAA09602 for ; Sat, 6 May 2000 18:59:13 -0400 (EDT) X-Authentication-Warning: mercury.mctr.umbc.edu: mpls owned process doing -bs Date: Sat, 6 May 2000 18:59:12 -0400 (EDT) From: MPLS X-Sender: mpls@mercury.mctr.umbc.edu To: mpls@UU.NET Subject: Best Effort LSP's Bandwidth Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi I am wondering if in a network we are running CR-LDP TE (for traffic having QoS requirements as well as BE traffic), how do we account for the bandwidth used by best effort traffic while doing QoS path computation for flows having QoS requirements. Do we consider bandwidth required by BE traffic as zero or we take average bandwidth used by BE flows into account. If we account BE LSPs having zero bandwidth then how accurate are the QoS path computations if the BE flows account for a substantial portion of the network traffic. Manish From owner-mpls@UU.NET Sat May 6 19:23: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 ESMTP id TAA24969 for ; Sat, 6 May 2000 19:23: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 QQiobl02454; Sat, 6 May 2000 23:23:21 GMT Received: by mail-control.mail.uu.net id QQiobl06719 for mpls-outgoing; Sat, 6 May 2000 23:23: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 QQiobl06707 for ; Sat, 6 May 2000 23:22: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 QQiobl09076; Sat, 6 May 2000 19:22:20 -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 QQiobl01685; Sat, 6 May 2000 23:22:19 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id BAA18962; Sun, 7 May 2000 01:22:18 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id BAA22429; Sun, 7 May 2000 01:22:18 +0200 (MET DST) Date: Sun, 7 May 2000 01:22:18 +0200 (MET DST) To: te-wg@UU.NET, mpls@UU.NET Subject: TEWG framework updates / MPLS-TE drafts X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14612.42804.714266.260861@rasputin.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Dear Sirs, Even though that (AFAIG) there is a new version of the framework document pending to be released i want to ask about some references that seem to become unvalid since draft-ietf-tewg-framework-00.txt: [Li-IGP] T. Li, G. Swallow, and D. Awduche, "IGP Requirements for Traffic Engineering with MPLS," Work in Progress, 1999 [MATE] I. Widjaja and A. Elwalid, "MATE: MPLS Adaptive Traffic Engineering," Work in Progress, 1999. There are a few others but about this two especially I'm wondering if these two above survived in some form. With kind regards, Florian. From owner-mpls@UU.NET Sun May 7 02:04:00 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 CAA06398 for ; Sun, 7 May 2000 02:04:00 -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 QQiocm24996; Sun, 7 May 2000 06:03:56 GMT Received: by mail-control.mail.uu.net id QQiocm26552 for mpls-outgoing; Sun, 7 May 2000 06:03:38 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 QQiocm26513 for ; Sun, 7 May 2000 06:03:24 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 QQiocm14784 for ; Sun, 7 May 2000 02:03:15 -0400 (EDT) Received: from alpha.netvision.net.il by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.netvision.net.il [194.90.1.13]) id QQiocm11154 for ; Sun, 7 May 2000 06:03:14 GMT Received: from localnet.cwnt.co.il (ras3-p165.hfa.netvision.net.il [62.0.147.165]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id JAA19691; Sun, 7 May 2000 09:02:09 +0300 (IDT) Received: from 192.168.0.15 ([192.168.0.15]) by localnet.cwnt.co.il (WinRoute 3.04g) with SMTP; Sun, 7 May 2000 08:35:34 +0300 From: "Yoav Levy" To: "Rajiv Papneja" Cc: Subject: RE: simple question about label encapsulation Date: Sun, 7 May 2000 08:35:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I will try to clarify my question: Is there a contradiction between MPLS Label Stack Encoding Internet Draft section 4 (a) and Multiprotocol Label Switching Architecture Internet Draft section 3.16 ? * In the first one we have - "...the label value at the top of the stack is looked up. As a result of a successful lookup one learns: (a) the next hop to which the packet is to be forwarded ..." * In the second one we have - "... this would require the egress to do TWO lookups, either two label lookups ..." Thanks, Yoav -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Rajiv Papneja Sent: Thursday, May 04, 2000 10:40 PM To: Yoav Levy Cc: mpls@UU.NET Subject: Re: simple question about label encapsulation Hi Please see the insert : On Thu, 4 May 2000, Yoav Levy wrote: > In the MPLS Label Stack Encoding Internet Draft the we have this paragraph > > 4. Label Value > > This 20-bit field carries the actual value of the Label. > > When a labeled packet is received, the label value at the top > of the stack is looked up. As a result of a successful lookup > one learns: > > (a) the next hop to which the packet is to be forwarded; > > (b) the operation to be performed on the label stack before > forwarding; this operation may be to replace the top > label stack entry with another, or to pop an entry off > the label stack, or to replace the top label stack entry > and then to push one or more additional entries on the > label stack. > > My problem is this sentence about the label at the top of the stack - "As a > result of a successful lookup one learns (a) the next hop" > > In case of penultimate LSR that do not supports pop operation the egress LSR > should do lookup according to underlying label / IP header. Comments : if the Penultimate LSR do not support poping then in this scenario, the egress LSR has to do two label lookups or one label lookup and network address lookup. For further reading please refer to the Section 3.16. "Penultimate Hop Popping" (http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-06.txt) Comments Take Care Rajiv > > ******************************** 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 Sun May 7 13:41: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 NAA10486 for ; Sun, 7 May 2000 13:41: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 QQioeg22835; Sun, 7 May 2000 17:41:06 GMT Received: by mail-control.mail.uu.net id QQioeg29910 for mpls-outgoing; Sun, 7 May 2000 17:40: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 QQioeg29905 for ; Sun, 7 May 2000 17:40: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 QQioeg21486 for ; Sun, 7 May 2000 13:40:06 -0400 (EDT) Received: from smtp6.mindspring.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQioeg08436 for ; Sun, 7 May 2000 17:40:06 GMT Received: from mindspring.com (user-33qtk64.dialup.mindspring.com [199.174.208.196]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id NAA01820; Sun, 7 May 2000 13:40:00 -0400 (EDT) Message-ID: <3915AB31.668C6EF4@mindspring.com> Date: Sun, 07 May 2000 10:43:13 -0700 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Yoav Levy CC: Rajiv Papneja , mpls@UU.NET Subject: Re: simple question about label encapsulation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yoav, Perhaps the wording in the encapsulation document could have been a little clearer, but is it really worth it? The meaning is made clearer in the architecture draft where it explicitly states that the "next hop" may be the local LSR (see the note after bullet "f" on page 15). If a second lookup is required, then the logical operation is to show the next hop as "self" and pop the top label. When the packet is logically "forwarded" to "self", the second label (if present) or the higher layer (IP) header is then used to make a forwarding decision. Hence, both documents are consistent - even if the consistency is not crystal clear at first. It is not, of course, necessary to implement this logical operation explicitly. In this respect, implementations will fall into 3 categories: o those that do not support "pop and look again" - this is one very good reason to support penultimate hop pop, o those that support the logical operation exactly and o those that support the logical operation using some proprietary shortcut. Although I use the word "proprietary", at least one such shortcut is really obvious and is very likely in common use. -- Eric Gray Yoav Levy wrote: > Hi, > > I will try to clarify my question: > > Is there a contradiction between MPLS Label Stack Encoding Internet Draft > section 4 (a) and Multiprotocol Label Switching Architecture Internet Draft > section 3.16 ? > > * In the first one we have - "...the label value at the top of the stack is > looked up. As a result of a successful lookup one learns: (a) the next hop > to which the packet is to be forwarded ..." > * In the second one we have - "... this would require the egress to do TWO > lookups, either two label lookups ..." > > Thanks, > Yoav > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Rajiv > Papneja > Sent: Thursday, May 04, 2000 10:40 PM > To: Yoav Levy > Cc: mpls@UU.NET > Subject: Re: simple question about label encapsulation > > Hi > > Please see the insert : > > On Thu, 4 May 2000, Yoav Levy wrote: > > > In the MPLS Label Stack Encoding Internet Draft the we have this > paragraph > > > > 4. Label Value > > > > This 20-bit field carries the actual value of the Label. > > > > When a labeled packet is received, the label value at the top > > of the stack is looked up. As a result of a successful lookup > > one learns: > > > > (a) the next hop to which the packet is to be forwarded; > > > > (b) the operation to be performed on the label stack before > > forwarding; this operation may be to replace the top > > label stack entry with another, or to pop an entry off > > the label stack, or to replace the top label stack entry > > and then to push one or more additional entries on the > > label stack. > > > > My problem is this sentence about the label at the top of the stack - "As > a > > result of a successful lookup one learns (a) the next hop" > > > > In case of penultimate LSR that do not supports pop operation the egress > LSR > > should do lookup according to underlying label / IP header. > > Comments : if the Penultimate LSR do not support poping then > in this scenario, the egress LSR has to do two label lookups > or one label lookup and network address lookup. For further reading please > refer to the Section 3.16. "Penultimate Hop Popping" > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-06.txt) Comments > > Take Care > > Rajiv > > > > > > > ******************************** > 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 Sun May 7 18:14:22 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 SAA13326 for ; Sun, 7 May 2000 18:14:22 -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 QQioey06745; Sun, 7 May 2000 22:14:07 GMT Received: by mail-control.mail.uu.net id QQioey22788 for mpls-outgoing; Sun, 7 May 2000 22:13:20 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 QQioey22783 for ; Sun, 7 May 2000 22:13: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 QQioey20218 for ; Sun, 7 May 2000 18:12:56 -0400 (EDT) Received: from web1303.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web1303.mail.yahoo.com [128.11.23.153]) id QQioey22366 for ; Sun, 7 May 2000 22:12:56 GMT Received: (qmail 12489 invoked by uid 60001); 7 May 2000 22:12:55 -0000 Message-ID: <20000507221255.12488.qmail@web1303.mail.yahoo.com> Received: from [24.4.252.109] by web1303.mail.yahoo.com; Sun, 07 May 2000 15:12:55 PDT Date: Sun, 7 May 2000 15:12:55 -0700 (PDT) From: "Simon G. M. Koo" Reply-To: SimonKoo@IEEE.org Subject: Bandwidth Allocation of LSP To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I would like to know, if a LSP is requested to setup with QoS requirement of certain bandwidth, will the system assign a fraction of the requirement if the full requirement cannot be satsified? Or just reject the setup request? And, if partial requirement can be satisfied, is there any negotiation procedure that the user can accept or reject the assigned amount of bandwidth? How is it working? Rgds, Simon ===== The average Ph.D. thesis is nothing but the transference of bones from one graveyard to another. --Frank J. Dobie __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Mon May 8 01:44: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 ESMTP id BAA23652 for ; Mon, 8 May 2000 01:44: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 QQiogc17178; Mon, 8 May 2000 05:43:54 GMT Received: by mail-control.mail.uu.net id QQiogc10475 for mpls-outgoing; Mon, 8 May 2000 05:43: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 QQiogc10470 for ; Mon, 8 May 2000 05:43: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 QQiogc07639 for ; Mon, 8 May 2000 01:43:01 -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 QQiogc16634 for ; Mon, 8 May 2000 05:42:58 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 08 May 2000 11:22:59 +0530 Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA31832 for ; Mon, 8 May 2000 11:01:26 +0530 Received: by localhost with Microsoft MAPI; Mon, 8 May 2000 11:08:18 +0530 Message-Id: <01BFB8DD.B6E976A0.manis@future.futsoft.com> From: manikantan To: "'mpls@uu.net'" Subject: LSR MIB - Object OIDs Date: Mon, 8 May 2000 11:08:17 +0530 Importance: high X-Priority: 1 (Highest) 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 Hello I noticed that the OID numbers for the following MIB objects in the LSR MIB - MIB 03 (Page 42) have the following values. These values have to be modified to be with the ones shown further below. Sorry if this had been notified earlier itself. Current Values: ---------------------- mplsTrafficParamMaxRate OBJECT-TYPE ::= { mplsTrafficParamEntry 4 } mplsTrafficParamMeanRate OBJECT-TYPE ::= { mplsTrafficParamEntry 5 } mplsTrafficParamMaxBurstSize OBJECT-TYPE ::= { mplsTrafficParamEntry 6 } mplsTrafficParamRowStatus OBJECT-TYPE ::= { mplsTrafficParamEntry 7 } mplsTrafficParamStorageType OBJECT-TYPE ::= { mplsTrafficParamEntry 8 } Values to be modified with -------------------------------------- mplsTrafficParamMaxRate OBJECT-TYPE ::= { mplsTrafficParamEntry 2 } mplsTrafficParamMeanRate OBJECT-TYPE ::= { mplsTrafficParamEntry 3 } mplsTrafficParamMaxBurstSize OBJECT-TYPE ::= { mplsTrafficParamEntry 4 } mplsTrafficParamRowStatus OBJECT-TYPE ::= { mplsTrafficParamEntry 5 } mplsTrafficParamStorageType OBJECT-TYPE ::= { mplsTrafficParamEntry 6 } thanks in advance with best regards mani /*-------------------------------------------------------------------*/ S.Manikantan Future Software Private Limited 480-481, Anna salai, Nandanam, Chennai, Tamil Nadu, 600 035, India. Phone : +91-44-4330550 Fax : +91-44-4344157. Email : manis@future.futsoft.com http://www.futsoft.com /*--------------------------------------------------------------------*/ From owner-mpls@UU.NET Mon May 8 03:14: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 DAA00859 for ; Mon, 8 May 2000 03:14: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 QQiogi05701; Mon, 8 May 2000 07:14:26 GMT Received: by mail-control.mail.uu.net id QQiogi00574 for mpls-outgoing; Mon, 8 May 2000 07:14:07 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 QQiogi00569 for ; Mon, 8 May 2000 07:13: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 QQiogi18910 for ; Mon, 8 May 2000 03:13:49 -0400 (EDT) Received: from hd2.dot.net.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hd2.vsnl.net.in [202.54.30.2]) id QQiogi19857 for ; Mon, 8 May 2000 07:13:35 GMT Received: from hyd.chiplogic.com ([203.197.20.34]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id MAA03216 for ; Mon, 8 May 2000 12:41:39 +0530 (IST) Received: from chiplogic.com ([192.168.2.51]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id LAA29328 for ; Mon, 8 May 2000 11:35:25 +0530 Message-ID: <39165A45.77AA595B@chiplogic.com> Date: Mon, 08 May 2000 11:40:13 +0530 From: phaneesh Organization: Chiplogic (I) Pvt. Ltd. X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "mpls@UU.NET" Subject: LDP Events Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This is with reference to the draft-ietf-mpls-ldp-state-03.txt. I'm working with LDP. I came to know that "Internal Setup" event comes to LDP, when MPLS recognizes a new FEC. I understood that all Internal Events are generated within the LSR itself aiming at local LDP. My doubt is, who will generate that event and how it alerts the LDP ( i mean, what exactly the signaling mechanism used here). Assuming that LDP runs over the Transport layer and MPLS runs below L3 and above L2. Can u please clarify my doubt explaining on the "Internal Setup" event. Thanks, Phani. From owner-mpls@UU.NET Mon May 8 04:28: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 ESMTP id EAA01255 for ; Mon, 8 May 2000 04:28: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 QQiogn14233; Mon, 8 May 2000 08:28:36 GMT Received: by mail-control.mail.uu.net id QQiogn12490 for mpls-outgoing; Mon, 8 May 2000 08:28: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 QQiogn12485 for ; Mon, 8 May 2000 08:28: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 QQiogn24198 for ; Mon, 8 May 2000 04:27:55 -0400 (EDT) From: peter.van_rompu@alcatel.be Received: from relay1.alcatel.be by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQiogn28538 for ; Mon, 8 May 2000 08:27:54 GMT Received: from bemta001.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e488RUf27421; Mon, 8 May 2000 10:27:33 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C12568D9.002E791B ; Mon, 8 May 2000 10:27:36 +0200 X-Lotus-FromDomain: ALCATEL To: "Cucchiara, Joan" cc: mpls@UU.NET Message-ID: Date: Mon, 8 May 2000 10:27:29 +0200 Subject: RE: questions on Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello Joan, Thank you, I do now understand the use of the iFindex. But I still don't understand what is the use of the mplsLdpEntityConfGenericTable and why a SNMP manager would want to configure these actual generic labels. Also the generic labels a LSR uses to forward data, are signalled by a peer LSR (depending on the label distribution method used, these labels might be signalled as a result of a request of the LSR to set up a label to a certain FEC or whenever a peer LSR decides to announce a new label binding). So my point is that there is no need to configure these labels on the LSR, since the LSR will learn them through LDP frm its peer LSRs. My opinion is that it makes more sense to configure in the mplsLdpEntityConfGenericTable generic label ranges. There should be no distinction between configuring label ranges for interface specific labels and configuring label ranges for generic labels. I known platform wide label ranges are not signalled - but at least the LSR need to known the generic label space(s) it can use, as well as it needs to known the interface specific labels ranges. Peter "Cucchiara, Joan" on 05/04/2000 05:08:22 PM To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET cc: Subject: RE: questions on Hello Peter, > > Hello Joan, > > Thank you for your reply - I think part of my confusion is > because I don't understand the mplsLdpEntityConfGenericTable. > > From your reply I understand this table is used to configure > the label range for Generic Labels. (I assumed that if you > use generic labels, it is free to use the full 20bit space > (with some reserved values) and there is no need to configure > a range). This table isn't used to configure label ranges; it is used to configure the actual generic labels. For LDP the generic labels are configured as specified in the encaps doc (draft-ietf-mpls-label-encaps-07.txt). > But I still don't understand how you can configure a label > range using the mplsLdpEntityConfGenericTable. What is the Currently, there is no way in LDP to communicate a label range for generic labels in LDP. That is why the MIB doesn't have a mechanism to configure a generic label range. I don't know why this was not included, perhaps someone could answer? > meaning of the mplsLdpConfGenericLabel object : is it an > upper value for this label range ? From the MIB it seems more no, this table configures actual generic labels (not ranges). > like all label > values within the generic label space need to be configured. yes, the MIB provides a mechanism for configuring the actual generic labels only. There is no mechanism in the current version of LDP for distributing a label range for generic labels. > > I'm also not sure my understanding about the use of ifIndex > in the various LDP MIB tables is correct : > > - About the ifIndex used in the mplsLdpEntityAtmParmsTable : > I assume this is a ifIndex which maps to the vpi/vci defined > in > mplsLdpEntityDefaultControlVpi/mplsLdpEntityDefaultControlVci > and that there is no need to create ifIndices for every ATM label. In practice ATM runs on an interface (in this sense a interface being a physical port). The ifLayering for ATM does not change for LDP. In theory you could have ATM (signalling) and ATM (LDP) running over the same physical port. They could have the same ifStack at the lower layers and differ at the upper layers. > The ifType associated to that ifIndex is = mpls (166). Is > this correct ? This is upto an implementation but for generic labels which get placed in a shim header then that would be the mpls (166). For ATM I think this is the cell layer and there would be an "mpls(166) ifLayer" someplace above within the ifStack. If there were label stacks being configured, and a label stack being pushed and/or popped, then this would also be at an ifLayer whose ifType was 166. > - From your reply I understand there is a ifIndex associated > with a generic label space - what does it model ? (is it a I wouldn't say "generic label space", there are perPlatform or perInterface label spaces. Again, I can only say that once data is forwarded using the label, the value of the ifIndex represents where in the ifLayer that the label was created. For generic labels this would be the mpls layer (with ifType 166). > kind of virtual interface such as the AAL5 interface in the > AtomMib ? can I derive the physical ports on which it is used > through e.g. > the ifStackTable ? can a SNMP Manager create such an interface ?). Yes, that is certainly the intention. For LDP a manager can configure the tables under the "Entity" branch and this would result in LDP running on a specific physical port. In other technologies such as IP over ATM or NHRP, it is also necessary to consult the ifStack to understand which physical port the protocols are running over, we specifically tried to follow those other MIB models. -Joan > > Peter > > > > > > "Cucchiara, Joan" on 05/03/2000 04:35:29 PM > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET > > cc: > > > > Subject: RE: questions on > > > > > > > > > > > -----Original Message----- > > From: peter.van_rompu@alcatel.be [mailto:peter.van_rompu@alcatel.be] > > Sent: Wednesday, May 03, 2000 6:23 AM > > To: mpls@UU.NET > > Subject: questions on > > > > > > > > Hello Peter, > > > > > Hello, > > > > Can somebody help me this the following questions on the use > > of the LDP MIB. > > > > 1) mplsLdpEntityTable > > > > How can a SNMP Manager derive on which interfaces a LDP > entity runs ? > > > > For LDP entities with mplsLdpEntityOptionalParameters set to > > atmParameters(2) or frameRelayParameters(3), my understanding > > is that the SNMP manager can derive this from the ifIndex > > found in the associated entry in the mplsLdpAtmParmsTable or > > mplsLdpFrameRelayParmsTable. Once the SNMP Manager knowns > > the ifIndex , the SNMP Manager can use the ifStackTable to > > figure out on which ATM/FR port this entity runs (am I correct ?) . > > yes. > > > > > But how to do this for a LDP entity using generic labels ? > > This is the same. There is an ifIndex associated with a > generic label also. This ifIndex would have the ifType of > mpls (166). So in effect this would be the mpls interface layer. > > > > > 2) mplsLdpEntityConfGenericTable > > > > I'm confused by the DESCRIPTION field of the > > mplsLdpEntityConfGenericTable definition : why does a SNMP > > Manager need to configure a generic label for LDP ? I thought > > it was sufficient for LDP to known the label pools in order > > to distribute labels ? > > Yes this is correct for ATM and Frame Relay, but for Generic > Labels there is no mechanism in LDP to distribute a > label pool (i.e. label range) for generic labels. > (The last sentence of Section 3.5.3 of the LDP > spec states: "Note that there is > no Generic Session Parameters TLV for sessions which > advertise Generic Labels.") > > > > > > 2) creation of a MPLS interface and activation of LDP on it. > > > > How can a SNMP manager create a MPLS interface using the > > available MIBs and associate a LDP entity to that newly > > created MPLS interface ? > > > > My understanding is that if the SNMP Manager wants LDP to use > > ATM or FrameRelay labels on the MPLS interface, the SNMP > > Manager needs to create an entry in the mplsLdpEntityTable, > > an entry in the mplsLdpEntityAtmParmsTable (which allows to > > configure for > > instance the VPI/VCI to be used by LDP) and one or more > > entries in the mplsLdpEntityConfAtmLabelRangeTable. As a > > result of these row creations, the SNMP agent might create a > > new MPLS interface, associate an ifIndex to it and fill the > > ifIndex for the newly > > created MPLS interface into the mplsLdpEntityTable. (Is this > > correct ?) > > Essentially, yes you are correct. Although how this would > take place exactly, would largely depend on when ifIndices are > created (which is why the LDP MIB uses InterfaceIndexOrZero > and why this is not needed for indexing into these Entity > related tables.) > > In other words, an Entity is created at some point in time. > At some other point in time, LSPs are established. The > LSPs are between MPLS interfaces. It is upto the implementation > on when the ifIndices are assigned, but the LDP MIB does stipulate > that once LSP are established these InterfaceIndexOrZero objects > need to have the value of the InterfaceIndex. > > > > > > But how can a SNMP manager create a new MPLS interface (for > > instance on ATM) using generic labels ? In this case the LDP > > entity might allready be configured - the only thing I would > > exspect to do is to configure somehow a VPI/VCI to be used > by this LDP > > entity. > > I don't think this is correct. If it is an ATM interface then > ATM labels (vpi,vci) would be used, so generic labels would not > be used for this. > > You could have an incoming labelled packet which is from > an ATM interface, forwarded out a PPP interface in which > case you would forward using a generic label (for details > see the draft-ietf-mpls-label-encaps-07.txt). In that > case though, this would be two different labels. > > -Joan > > > > > Best regards, > > > > Peter Van Rompu - Alcatel Telecom > > > > > > > From owner-mpls@UU.NET Mon May 8 06:19: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 GAA02233 for ; Mon, 8 May 2000 06:19: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 QQiogv25239; Mon, 8 May 2000 10:19:05 GMT Received: by mail-control.mail.uu.net id QQiogv03903 for mpls-outgoing; Mon, 8 May 2000 10:18: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 QQiogv03898 for ; Mon, 8 May 2000 10:18: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 QQiogv07053 for ; Mon, 8 May 2000 06:18:33 -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 QQiogv12319 for ; Mon, 8 May 2000 10:18:32 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id MAA24783; Mon, 8 May 2000 12:18:31 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id MAA02851; Mon, 8 May 2000 12:18:31 +0200 (MET DST) Date: Mon, 8 May 2000 12:18:31 +0200 (MET DST) To: neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: RE: OAM functions for MPLS (Was: RE: Comments on draft-owens-te- network-suvivability-00.txt ) In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14614.36445.149865.946095@rasputin.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > Some quick background to bring up up to speed: > 1 The Thiemer ID is mainly a background/requirements paper......but it > does not go anywhere near far enough. Point taken. > 2 When we use relative addressing (ie labels) these are not globally > unique but only interface unique. Note - An IP pkt has an absolute address, > and so is globally unique (save for NAT etc issues). This means that we can > have various forms of misbranching defect affecting MPLS LSPs. These are > well-known defects in ATM (though to be honest the solutions are far from > perfect........it would take too long to explain why here). For example: > - simple break in LSP connectivity > - two LSPs swapped > - one LSP merging into another LSP (with or without the 'offending' > LSP being affected or not) > - self-merging of an LSP (with or without a break on connectivity to > its sink)........this being the classic looping defect of transient IGP > behaviour. > For an operator these are serious defects. Not only do they affect > availability/QoS SLAs per se, be they can have security, censorship and > fraud implications if traffic gets misdelivered. It would not be very good > publicity for any operator to have such defects happening that could not be > (i) detected and (ii) diagnosed/corrected. > 3 To date there has been little work on identifying and then > specifying MPLS level defects.....both in terms of the defect entry/exit > criteria and the consequent actions. MPLs has only been seen so far as an > 'IP booster'......but when one really analyses what is going on (eg with TE > and VPN issues) then one is rapidly forced into the conclusion that MPLS > *must* become a layer network in its own right. And a proper layer network > *must* have certain characteristics......a key one being absolute source > adddesses of trail access points. Ok, now this becomes scary for me. I'm not so advanced about MPLS so far (I'm taking the first steps now, so please take this w/ a grain of salt and don't flame yours truly newbie :) ) but so far for me MPLS is a neat labeling artchitecture. An *IP boost* as you call it. Moreover, AFAIG things are quite settled in the sense that there is already an installed based of MPLS. Turning it into a full-fleged L2 proto in itself..Well, that's far beyond me to judge but my impression is that it will be quite a shake-down if this happens. If ever. > Our current thinking is that 1 bit of the TTL field would be > sufficient noting that: > - a TTL number space of 255 is too big anyway > - TTL is rather a wrong architectural concept for MPLS *if* one is > trying to guess the 'passed IP hops' in an IP client > layer.......architecturally, LSPs are a server layer to IP (or indeed any > client layer......though IP is the only one so far defined) and as such one > should not be using the functions of a client layer within a server layer. > Same would go for any use of ICMP in MPLS, and indeed some of the misguided > debate I have been seeing on the relationships across the full L1/2/3 stack > (esp with optical layer). > - a TTL field would be useful in MPLS but *only* for stopping looping > pkts in that layer (ie irrespective of what the client layer was), and then > only as a back-stop mechanism, ie still need defect indication > - TTL only caters for looping defects, it does not cater for all the > other misbranching defects I mentioned in 2 above. Again, i'm still finding my way through the aprox 70 existing `MPLS drafts`, but IIRC there are at no less then three documents decribing methods for loop avoidance. Ok, TTL is just a simplistic 'back-stop' mechanism, but are that so many intrested in more than this ? > 6 Only a few people have bothered to comment on the 'missing' OAM > perspective for MPLS so far. Though I have had varying degrees of support > for saying we need a payload ID field.......but none strong enough to say > its essential. Though without one, I am struggling to understand how to > progress this area, and I think MPLS will have missed a very big > opportunity. AFAIG there was already a discussion about this kind of field in MPLS and the idea was rejected. Anyway, with the risk of having the 'not this subject again, please' reaction I'm biting the bullet and Cc: this to the MPLS mailing list where i think there are people more competent than me to discuss the matter. As much of a fan i'm to the KISS principle and as much the idea of turning MPLS in a full-flegded L2 proto is scaring to me (not that present state is that simple but still ...) IMHO you raised some points that worth at least to be refuted ;) > Hope that helps Florian. > Regards, Neil With kind regards, Florian. From owner-mpls@UU.NET Mon May 8 06:20: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 GAA02300 for ; Mon, 8 May 2000 06:20: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 QQiogv26410; Mon, 8 May 2000 10:20:33 GMT Received: by mail-control.mail.uu.net id QQiogv03966 for mpls-outgoing; Mon, 8 May 2000 10:20:03 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 QQiogv03960 for ; Mon, 8 May 2000 10:20: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 QQiogv03942 for ; Mon, 8 May 2000 06:19:49 -0400 (EDT) Received: from hd2.dot.net.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hd2.vsnl.net.in [202.54.30.2]) id QQiogv25807 for ; Mon, 8 May 2000 10:19:43 GMT Received: from hyd.chiplogic.com ([203.197.20.34]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id PAA08627 for ; Mon, 8 May 2000 15:47:40 +0530 (IST) Received: from trilok ([192.168.2.58]) by hyd.chiplogic.com (8.8.7/8.8.7) with SMTP id PAA00677 for ; Mon, 8 May 2000 15:41:11 +0530 From: "Trilok Chand" To: Subject: ILM mappings Date: Mon, 8 May 2000 15:55:02 +0530 Message-ID: <01bfb8d7$ab8d0b10$3a02a8c0@trilok> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01BFB905.C5454710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0066_01BFB905.C5454710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Can anybody tell where can i get information about choosing an = ILM mapping when there are multiple NHLFEs existing for an incoming = label? Thanks in advance, TrilokChand ------=_NextPart_000_0066_01BFB905.C5454710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
        Can=20 anybody tell where can i get information about choosing an ILM mapping = when=20 there are multiple NHLFEs existing for an incoming = label? 
 
Thanks in advance,
TrilokChand
 
------=_NextPart_000_0066_01BFB905.C5454710-- From owner-mpls@UU.NET Mon May 8 06:54: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 GAA03051 for ; Mon, 8 May 2000 06:54: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 QQiogx14141; Mon, 8 May 2000 10:54:40 GMT Received: by mail-control.mail.uu.net id QQiogx05532 for mpls-outgoing; Mon, 8 May 2000 10:54: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 QQiogx05527 for ; Mon, 8 May 2000 10:54:13 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 QQiogx10547 for ; Mon, 8 May 2000 06:54:10 -0400 (EDT) Received: from sepahan.iut.ac.ir by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sepahan.iut.ac.ir [194.165.10.30]) id QQiogx00651 for ; Mon, 8 May 2000 10:53:56 GMT Received: from localhost (s7627237@localhost) by sepahan.iut.ac.ir (8.9.3/8.9.3) with ESMTP id PAA15602 for ; Mon, 8 May 2000 15:23:57 +0430 Date: Mon, 8 May 2000 15:23:57 +0430 (IRST) From: Manshaee Mohammad-Hossein To: mpls@UU.NET Subject: A question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi I want to know about the standard of MPLS. If i want to find a final document about MPLS standard, What can I do? Would you please send a Web address for me that I can find this document there. Best, MH Manshaei From owner-mpls@UU.NET Mon May 8 07:23: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 ESMTP id HAA04057 for ; Mon, 8 May 2000 07:23: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 QQiogz17202; Mon, 8 May 2000 11:23:39 GMT Received: by mail-control.mail.uu.net id QQiogz15295 for mpls-outgoing; Mon, 8 May 2000 11:23: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 QQiogz15282 for ; Mon, 8 May 2000 11:23:03 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 QQiogz13729 for ; Mon, 8 May 2000 07:23:00 -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 QQiogz16734 for ; Mon, 8 May 2000 11:22:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA02480 for mpls@uu.net; Mon, 8 May 2000 07:22:58 -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 QQiogz15237 for ; Mon, 8 May 2000 11:22: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 QQiogz10220 for ; Mon, 8 May 2000 07:22:18 -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 QQiogz29356 for ; Mon, 8 May 2000 11:22:18 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA17393; Mon, 8 May 2000 07:22:02 -0400 (EDT) Message-Id: <4.2.2.20000508072414.0444a950@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 08 May 2000 07:25:21 -0400 To: manikantan , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: Re: LSR MIB - Object OIDs Cc: Cheenu Srinivasan , Arun Viswanathan , arun@force10networks.com In-Reply-To: <01BFB8DD.B6E976A0.manis@future.futsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_39302390==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_39302390==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks. Our mistake. It will be fixed at the end of WGLC P2. --Tom >I noticed that the OID numbers for the following MIB objects in >the LSR MIB - MIB 03 (Page 42) have the following values. These >values have to be modified to be with the ones shown further below. > >Sorry if this had been notified earlier itself. > >Current Values: >---------------------- >mplsTrafficParamMaxRate OBJECT-TYPE > > ::= { mplsTrafficParamEntry 4 } > >mplsTrafficParamMeanRate OBJECT-TYPE > > ::= { mplsTrafficParamEntry 5 } > >mplsTrafficParamMaxBurstSize OBJECT-TYPE > > ::= { mplsTrafficParamEntry 6 } > >mplsTrafficParamRowStatus OBJECT-TYPE > > ::= { mplsTrafficParamEntry 7 } > >mplsTrafficParamStorageType OBJECT-TYPE > > ::= { mplsTrafficParamEntry 8 } > > >Values to be modified with >-------------------------------------- >mplsTrafficParamMaxRate OBJECT-TYPE > > ::= { mplsTrafficParamEntry 2 } > >mplsTrafficParamMeanRate OBJECT-TYPE > > ::= { mplsTrafficParamEntry 3 } > >mplsTrafficParamMaxBurstSize OBJECT-TYPE > > ::= { mplsTrafficParamEntry 4 } > >mplsTrafficParamRowStatus OBJECT-TYPE > > ::= { mplsTrafficParamEntry 5 } > >mplsTrafficParamStorageType OBJECT-TYPE > > ::= { mplsTrafficParamEntry 6 } > >thanks in advance >with best regards >mani > >/*-------------------------------------------------------------------*/ >S.Manikantan >Future Software Private Limited >480-481, Anna salai, Nandanam, >Chennai, Tamil Nadu, 600 035, >India. >Phone : +91-44-4330550 >Fax : +91-44-4344157. >Email : manis@future.futsoft.com >http://www.futsoft.com >/*--------------------------------------------------------------------*/ > --=====================_39302390==_.ALT Content-Type: text/html; charset="us-ascii"
        Thanks. Our mistake. It will be fixed at the end of WGLC P2.

        --Tom

I noticed that the OID numbers for the following MIB objects in
the LSR MIB -  MIB 03 (Page 42) have the following values. These
values have to be modified to be with the ones shown further below.

Sorry if this had been notified earlier itself.

Current Values:
----------------------
mplsTrafficParamMaxRate OBJECT-TYPE

   ::= { mplsTrafficParamEntry 4 }

mplsTrafficParamMeanRate OBJECT-TYPE

   ::= { mplsTrafficParamEntry 5 }

mplsTrafficParamMaxBurstSize OBJECT-TYPE

   ::= { mplsTrafficParamEntry 6 }

mplsTrafficParamRowStatus OBJECT-TYPE

   ::= { mplsTrafficParamEntry 7 }
  
mplsTrafficParamStorageType OBJECT-TYPE

   ::= { mplsTrafficParamEntry 8 }


Values to be modified with
--------------------------------------
mplsTrafficParamMaxRate OBJECT-TYPE

   ::= { mplsTrafficParamEntry 2 }

mplsTrafficParamMeanRate OBJECT-TYPE

   ::= { mplsTrafficParamEntry 3 }

mplsTrafficParamMaxBurstSize OBJECT-TYPE

   ::= { mplsTrafficParamEntry 4 }

mplsTrafficParamRowStatus OBJECT-TYPE

   ::= { mplsTrafficParamEntry 5 }
  
mplsTrafficParamStorageType OBJECT-TYPE

   ::= { mplsTrafficParamEntry 6 }

thanks in advance
with best regards
mani
 
/*-------------------------------------------------------------------*/
S.Manikantan
Future Software Private Limited
480-481, Anna salai, Nandanam,
Chennai, Tamil Nadu, 600 035,
India.
Phone   : +91-44-4330550
Fax     : +91-44-4344157.
Email   : manis@future.futsoft.com
http://www.futsoft.com
/*--------------------------------------------------------------------*/

--=====================_39302390==_.ALT-- From owner-mpls@UU.NET Mon May 8 07:41: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 HAA04482 for ; Mon, 8 May 2000 07:41: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 QQioha27270; Mon, 8 May 2000 11:41:06 GMT Received: by mail-control.mail.uu.net id QQioha16082 for mpls-outgoing; Mon, 8 May 2000 11:40: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 QQioha16075 for ; Mon, 8 May 2000 11:40:31 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 QQioha12165 for ; Mon, 8 May 2000 07:40:14 -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 QQioha26574 for ; Mon, 8 May 2000 11:40:14 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Mon, 8 May 2000 07:38:51 -0400 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQHKRMR1; Mon, 8 May 2000 07:38:51 -0400 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJ8TTFS7; Mon, 8 May 2000 07:38:48 -0400 Message-ID: <3916A6A9.CCC415AC@americasm01.nt.com> Date: Mon, 08 May 2000 07:36:09 -0400 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MPLS CC: mpls@UU.NET, "Peter Ashwood-Smith" Subject: Re: Best Effort LSP's Bandwidth References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS wrote: > > Hi > > I am wondering if in a network we are running CR-LDP TE (for traffic > having QoS requirements as well as BE traffic), how do we account for the > bandwidth used by best effort traffic while doing QoS path computation for > flows having QoS requirements. > > Do we consider bandwidth required by BE traffic as zero or we take > average bandwidth used by BE flows into account. If we account BE LSPs > having zero bandwidth then how accurate are the QoS path computations if > the BE flows account for a substantial portion of the network traffic. > > Manish As you yourself implied, it is clearly necessary to make unlabelled traffic into account when setting up LSPs for QoS traffic. If one assumes that QoS traffic is generally more important, then one solution is to make the weights used by the IGP for route computations a function of the unreserved bandwidth on a link. As the bandwidth reserved for QoS LSPs increases, this will force the unlabelled traffic onto other links when possible. Peter Ashwood-Smith's MPLS tutorial at Networld+Interop this week has a short section on this topic. You might wish to attend and/or look at the slides. - Philip From owner-mpls@UU.NET Mon May 8 07:51: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 ESMTP id HAA04811 for ; Mon, 8 May 2000 07:51: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 QQiohb15379; Mon, 8 May 2000 11:51:32 GMT Received: by mail-control.mail.uu.net id QQiohb16732 for mpls-outgoing; Mon, 8 May 2000 11:50:58 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 QQiohb16719 for ; Mon, 8 May 2000 11:50: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 QQiohb13247; Mon, 8 May 2000 07:50:22 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35]) id QQiohb14613; Mon, 8 May 2000 11:50:22 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Mon, 8 May 2000 07:49:58 -0400 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQHRDSQ3; Mon, 8 May 2000 07:49:56 -0400 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJ8TTFTR; Mon, 8 May 2000 07:49:55 -0400 Message-ID: <3916A947.DCD48F5@americasm01.nt.com> Date: Mon, 08 May 2000 07:47:19 -0400 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: otel@ce.chalmers.se CC: te-wg@UU.NET, mpls@UU.NET Subject: Re: TEWG framework updates / MPLS-TE drafts References: <14612.42804.714266.260861@rasputin.ce.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A good site to check for internet-drafts related to MPLS is http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ This site archives drafts going back the the beginings of the MPLS WG, as well as related drafts. Both of the drafts you are looking for are available there. - Philip From owner-mpls@UU.NET Mon May 8 08:21: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 IAA05706 for ; Mon, 8 May 2000 08:21: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 QQiohd02737; Mon, 8 May 2000 12:21:35 GMT Received: by mail-control.mail.uu.net id QQiohd26997 for mpls-outgoing; Mon, 8 May 2000 12:21:12 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 QQiohd26934 for ; Mon, 8 May 2000 12:21: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 QQiohd17694; Mon, 8 May 2000 08:20:52 -0400 (EDT) Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQiohd02174; Mon, 8 May 2000 12:20:51 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id OAA04489; Mon, 8 May 2000 14:20:50 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id OAA03441; Mon, 8 May 2000 14:20:50 +0200 (MET DST) Date: Mon, 8 May 2000 14:20:50 +0200 (MET DST) To: "Philip Matthews" Cc: mpls@UU.NET, te-wg@UU.NET Subject: Re: TEWG framework updates / MPLS-TE drafts In-Reply-To: <3916A947.DCD48F5@americasm01.nt.com> References: <14612.42804.714266.260861@rasputin.ce.chalmers.se> <3916A947.DCD48F5@americasm01.nt.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14614.44626.241758.665317@rasputin.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > A good site to check for internet-drafts related to MPLS is > http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ > This site archives drafts going back the the beginings > of the MPLS WG, as well as related drafts. > Both of the drafts you are looking for are available there. Found the site in the mean time (that draft is also on Dan Awduche web site too) but thanks a lot. Also i was implictly asking about the updated version (i.e. draft-li-mpls-igp-te-01.txt). Anyway, that was not the main intention (and i appologize for not making it clear from the first posting): What I was primarily intrested in was about the continuation of these drafts i.e. were they dropped (if so why ? was there a discussion about this ? where ? archives ?) , there was no interest in them, there is an update planned, they advanced on IETF track, etc. ? Thanks, > - Philip Florian. From owner-mpls@UU.NET Mon May 8 08:23: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 ESMTP id IAA05736 for ; Mon, 8 May 2000 08:23: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 QQiohd04173; Mon, 8 May 2000 12:23:28 GMT Received: by mail-control.mail.uu.net id QQiohd27115 for mpls-outgoing; Mon, 8 May 2000 12:22:51 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 QQiohd27092 for ; Mon, 8 May 2000 12:22: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 QQiohd17963 for ; Mon, 8 May 2000 08:22:26 -0400 (EDT) Received: from sepahan.iut.ac.ir by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sepahan.iut.ac.ir [194.165.10.30]) id QQiohd21712 for ; Mon, 8 May 2000 12:22:09 GMT Received: from localhost (s7627237@localhost) by sepahan.iut.ac.ir (8.9.3/8.9.3) with ESMTP id QAA16860; Mon, 8 May 2000 16:51:30 +0430 Date: Mon, 8 May 2000 16:51:30 +0430 (IRST) From: Manshaee Mohammad-Hossein To: manikantan cc: mpls@UU.NET Subject: RE: A question In-Reply-To: <01BFB90C.6E1FFF00.manis@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk hello and thanks in advanced for your good reply, I saw the paper. I want to know about the implimentation and use of this method in routers nowadays. I think that some Co. Like Cisco and Lucent did something about this subject. Would you please explain about this. Is their product available? And what do you think about the future of MPLS? Best, MH Manshaei On Mon, 8 May 2000, manikantan wrote: > Hello MH Manshaei > > The MPLS Ietf Drafts are inthe stages of becoming Standards > > Please look at these sites for more info > > http://www.ietf.org/html.charters/mpls-charter.html > > > http://www.mplsrc.com/ > > regards > mani > > -----Original Message----- > From: Manshaee Mohammad-Hossein [SMTP:s7627237@sepahan.iut.ac.ir] > Sent: Monday, May 08, 2000 4:24 PM > To: mpls@uu.net > Subject: A question > > > Hi > > I want to know about the standard of MPLS. > If i want to find a final document about MPLS standard, What can I do? > > Would you please send a Web address for me that I can find this document > there. > > Best, > > MH Manshaei > From owner-mpls@UU.NET Mon May 8 08:41: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 IAA06186 for ; Mon, 8 May 2000 08:41: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 QQiohe15263; Mon, 8 May 2000 12:41:04 GMT Received: by mail-control.mail.uu.net id QQiohe28089 for mpls-outgoing; Mon, 8 May 2000 12:40: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 QQiohe28083 for ; Mon, 8 May 2000 12:40:24 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 QQiohe25774 for ; Mon, 8 May 2000 08:40:22 -0400 (EDT) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQiohe14678 for ; Mon, 8 May 2000 12:40:21 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 8 May 2000 07:38:58 -0500 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQHKR4KL; Mon, 8 May 2000 08:38:54 -0400 Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJ8TTFX4; Mon, 8 May 2000 08:38:51 -0400 Message-ID: <3916B55C.A326814C@americasm01.nt.com> Date: Mon, 08 May 2000 08:38:52 -0400 From: "Darek Skalecki" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: SimonKoo@IEEE.org CC: mpls@UU.NET Subject: Re: Bandwidth Allocation of LSP References: <20000507221255.12488.qmail@web1303.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Simon G. M. Koo wrote: > Hi, > > I would like to know, if a LSP is requested to setup > with QoS requirement of certain bandwidth, will the > system assign a fraction of the requirement if the > full requirement cannot be satsified? Or just reject > the setup request? And, if partial requirement can > be satisfied, is there any negotiation procedure that > the user can accept or reject the assigned amount of > bandwidth? How is it working? > > Rgds, > Simon > > ===== > The average Ph.D. thesis is nothing but the transference of bones from one graveyard to another. > > --Frank J. Dobie > > __________________________________________________ > Do You Yahoo!? > Send instant messages & get email alerts with Yahoo! Messenger. > http://im.yahoo.com/ I am not aware of either CR-LDP or RSVP-TE allowing for partial reservations. If the full reservation cannot be made then a reservation failure message is generated towards the originator, eg: RESV_ERR for RSVP or PATH_ERR for RSVP-TE provided reservations are made on PATH messages instead of on RESV messages which I belive is the case for RSVP-TE in order to make "make-before-break" work. The originator then can either request less bandwidth, compute a new route or go to sleep. Darek From owner-mpls@UU.NET Mon May 8 10:04: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 ESMTP id KAA08027 for ; Mon, 8 May 2000 10:04: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 QQiohk26249; Mon, 8 May 2000 14:04:31 GMT Received: by mail-control.mail.uu.net id QQiohk14980 for mpls-outgoing; Mon, 8 May 2000 14:04: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 QQiohk14973 for ; Mon, 8 May 2000 14:04:05 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 QQiohk13521 for ; Mon, 8 May 2000 10:03:50 -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 QQiohk25703 for ; Mon, 8 May 2000 14:03:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA16667 for mpls@uu.net; Mon, 8 May 2000 10:03:48 -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 QQiohk14044 for ; Mon, 8 May 2000 14:02: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 QQiohk05000 for ; Mon, 8 May 2000 10:02:14 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiohk24773 for ; Mon, 8 May 2000 14:02:13 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 10:02:13 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15FAB6@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'peter.van_rompu@alcatel.be'" , "Cucchiara, Joan" Cc: mpls@UU.NET Subject: RE: questions on Date: Mon, 8 May 2000 10:02:10 -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 Peter, > -----Original Message----- > From: peter.van_rompu@alcatel.be [mailto:peter.van_rompu@alcatel.be] > Sent: Monday, May 08, 2000 4:27 AM > To: Cucchiara, Joan > Cc: mpls@UU.NET > Subject: RE: questions on > > > > > Hello Joan, > > Thank you, I do now understand the use of the iFindex. :) > > But I still don't understand what is the use of the > mplsLdpEntityConfGenericTable and why a SNMP manager would > want to configure these actual generic labels. Also the > generic labels a LSR uses to forward data, are signalled by a > peer LSR (depending on > the label distribution method used, these labels might be > signalled as a result of a request of the LSR to set up a > label to a certain FEC or whenever a peer LSR decides to > announce a new label binding). So my point is that there is > no need to configure > these labels on the LSR, since the LSR will learn them > through LDP frm its peer LSRs. The way that we thought of this was that for LDP the generic labels need to be configured. Mostly to keep track of what generic labels are supported by LDP. I agree that these are "learned" through a peer but at some point, we thought that users would want to be able configure these labels. > > My opinion is that it makes more sense to configure in the > mplsLdpEntityConfGenericTable generic label ranges. There > should be no distinction between configuring label ranges for > interface specific labels and configuring label ranges for > generic labels. I > known platform wide label ranges are not signalled - but at > least the LSR need to known the generic label space(s) it can > use, as well as it needs to known the interface specific > labels ranges. The LSR MIB is being used to represent min/max in/out labels on a per Interface as well as perPlatform. Although, this isn't quite the same thing as you are asking for. We could add a generic label range configuration type of mechanism in the LDP MIB, there isn't really this concept in LDP, so hesitate to do so because the only use would be for an NMS (as far as we can see). An NMS could query the existing mplsLdpEntityConfGenericTable and figure out a label ranges for generic labels. Is there any other motivation for having this table, other than for the NMS? Thanks, Joan > > Peter > > > > > > "Cucchiara, Joan" on 05/04/2000 05:08:22 PM > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET > > cc: > > > > Subject: RE: questions on > > > > > > > > > > Hello Peter, > > > > > Hello Joan, > > > > Thank you for your reply - I think part of my confusion is > > because I don't understand the mplsLdpEntityConfGenericTable. > > > > From your reply I understand this table is used to configure > > the label range for Generic Labels. (I assumed that if you > > use generic labels, it is free to use the full 20bit space > > (with some reserved values) and there is no need to configure > > a range). > > > This table isn't used to configure label ranges; it is > used to configure the actual generic labels. > For LDP the generic labels > are configured as specified in the encaps doc > (draft-ietf-mpls-label-encaps-07.txt). > > > > But I still don't understand how you can configure a label > > range using the mplsLdpEntityConfGenericTable. What is the > > Currently, there is no way in LDP to communicate a label range > for generic labels in LDP. That is why > the MIB doesn't have a mechanism to configure a generic > label range. > > I don't know why this was not included, perhaps > someone could answer? > > > meaning of the mplsLdpConfGenericLabel object : is it an > > upper value for this label range ? From the MIB it seems more > > no, this table configures actual generic labels (not ranges). > > > like all label > > values within the generic label space need to be configured. > > yes, the MIB provides a mechanism for configuring the actual > generic labels only. There is no mechanism in the current version > of LDP for distributing a label range for generic labels. > > > > > I'm also not sure my understanding about the use of ifIndex > > in the various LDP MIB tables is correct : > > > > - About the ifIndex used in the mplsLdpEntityAtmParmsTable : > > I assume this is a ifIndex which maps to the vpi/vci defined > > in > > mplsLdpEntityDefaultControlVpi/mplsLdpEntityDefaultControlVci > > and that there is no need to create ifIndices for every ATM label. > > In practice ATM runs on an interface (in this sense a interface > being a physical port). > > The ifLayering for ATM does not > change for LDP. In theory you could have ATM (signalling) and > ATM (LDP) running over the same physical port. They could have > the same ifStack at the lower layers and differ at the upper > layers. > > > The ifType associated to that ifIndex is = mpls (166). Is > > this correct ? > > This is upto an implementation but for generic labels which get > placed in a shim header then that would be the mpls (166). > For ATM I think this is the cell layer and there would be > an "mpls(166) ifLayer" someplace above within the ifStack. > If there were label stacks being configured, and a label stack > being pushed and/or popped, then this would also be at an > ifLayer whose ifType was 166. > > > - From your reply I understand there is a ifIndex associated > > with a generic label space - what does it model ? (is it a > > I wouldn't say "generic label space", there are perPlatform or > perInterface label spaces. > > Again, I can only say that once data is forwarded using the > label, the value of the ifIndex represents where in the ifLayer > that the label was created. For generic labels this would be > the mpls layer (with ifType 166). > > > kind of virtual interface such as the AAL5 interface in the > > AtomMib ? can I derive the physical ports on which it is used > > through e.g. > > the ifStackTable ? can a SNMP Manager create such an interface ?). > > Yes, that is certainly the intention. > > For LDP a manager can configure the tables under the "Entity" > branch and this would result in LDP running on a specific physical > port. In other technologies such as IP over ATM or NHRP, it is > also necessary to consult the ifStack to understand which physical > port the protocols are running over, we specifically tried > to follow those other MIB models. > > -Joan > > > > Peter > > > > > > > > > > > > "Cucchiara, Joan" on 05/03/2000 04:35:29 PM > > > > > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET > > > > cc: > > > > > > > > Subject: RE: questions on > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: peter.van_rompu@alcatel.be > [mailto:peter.van_rompu@alcatel.be] > > > Sent: Wednesday, May 03, 2000 6:23 AM > > > To: mpls@UU.NET > > > Subject: questions on > > > > > > > > > > > > > Hello Peter, > > > > > > > > Hello, > > > > > > Can somebody help me this the following questions on the use > > > of the LDP MIB. > > > > > > 1) mplsLdpEntityTable > > > > > > How can a SNMP Manager derive on which interfaces a LDP > > entity runs ? > > > > > > For LDP entities with mplsLdpEntityOptionalParameters set to > > > atmParameters(2) or frameRelayParameters(3), my understanding > > > is that the SNMP manager can derive this from the ifIndex > > > found in the associated entry in the mplsLdpAtmParmsTable or > > > mplsLdpFrameRelayParmsTable. Once the SNMP Manager knowns > > > the ifIndex , the SNMP Manager can use the ifStackTable to > > > figure out on which ATM/FR port this entity runs (am I > correct ?) . > > > > yes. > > > > > > > > But how to do this for a LDP entity using generic labels ? > > > > This is the same. There is an ifIndex associated with a > > generic label also. This ifIndex would have the ifType of > > mpls (166). So in effect this would be the mpls interface layer. > > > > > > > > 2) mplsLdpEntityConfGenericTable > > > > > > I'm confused by the DESCRIPTION field of the > > > mplsLdpEntityConfGenericTable definition : why does a SNMP > > > Manager need to configure a generic label for LDP ? I thought > > > it was sufficient for LDP to known the label pools in order > > > to distribute labels ? > > > > Yes this is correct for ATM and Frame Relay, but for Generic > > Labels there is no mechanism in LDP to distribute a > > label pool (i.e. label range) for generic labels. > > (The last sentence of Section 3.5.3 of the LDP > > spec states: "Note that there is > > no Generic Session Parameters TLV for sessions which > > advertise Generic Labels.") > > > > > > > > > > 2) creation of a MPLS interface and activation of LDP on it. > > > > > > How can a SNMP manager create a MPLS interface using the > > > available MIBs and associate a LDP entity to that newly > > > created MPLS interface ? > > > > > > My understanding is that if the SNMP Manager wants LDP to use > > > ATM or FrameRelay labels on the MPLS interface, the SNMP > > > Manager needs to create an entry in the mplsLdpEntityTable, > > > an entry in the mplsLdpEntityAtmParmsTable (which allows to > > > configure for > > > instance the VPI/VCI to be used by LDP) and one or more > > > entries in the mplsLdpEntityConfAtmLabelRangeTable. As a > > > result of these row creations, the SNMP agent might create a > > > new MPLS interface, associate an ifIndex to it and fill the > > > ifIndex for the newly > > > created MPLS interface into the mplsLdpEntityTable. (Is this > > > correct ?) > > > > Essentially, yes you are correct. Although how this would > > take place exactly, would largely depend on when ifIndices are > > created (which is why the LDP MIB uses InterfaceIndexOrZero > > and why this is not needed for indexing into these Entity > > related tables.) > > > > In other words, an Entity is created at some point in time. > > At some other point in time, LSPs are established. The > > LSPs are between MPLS interfaces. It is upto the implementation > > on when the ifIndices are assigned, but the LDP MIB does stipulate > > that once LSP are established these InterfaceIndexOrZero objects > > need to have the value of the InterfaceIndex. > > > > > > > > > > But how can a SNMP manager create a new MPLS interface (for > > > instance on ATM) using generic labels ? In this case the LDP > > > entity might allready be configured - the only thing I would > > > exspect to do is to configure somehow a VPI/VCI to be used > > by this LDP > > > entity. > > > > I don't think this is correct. If it is an ATM interface then > > ATM labels (vpi,vci) would be used, so generic labels would not > > be used for this. > > > > You could have an incoming labelled packet which is from > > an ATM interface, forwarded out a PPP interface in which > > case you would forward using a generic label (for details > > see the draft-ietf-mpls-label-encaps-07.txt). In that > > case though, this would be two different labels. > > > > -Joan > > > > > > > > Best regards, > > > > > > Peter Van Rompu - Alcatel Telecom > > > > > > > > > > > > > > > From owner-mpls@UU.NET Mon May 8 10:20: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 KAA08288 for ; Mon, 8 May 2000 10:20: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 QQiohl19728; Mon, 8 May 2000 14:20:02 GMT Received: by mail-control.mail.uu.net id QQiohl19761 for mpls-outgoing; Mon, 8 May 2000 14:19: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 QQiohl19756 for ; Mon, 8 May 2000 14:19:21 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 QQiohl08613 for ; Mon, 8 May 2000 10:18:59 -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 QQiohl18774 for ; Mon, 8 May 2000 14:18:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA18983 for mpls@uu.net; Mon, 8 May 2000 10:18: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 QQiohl19706 for ; Mon, 8 May 2000 14:17: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 QQiohl16766 for ; Mon, 8 May 2000 10:17:33 -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 QQiohl05512 for ; Mon, 8 May 2000 14:17:33 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA16545; Mon, 8 May 2000 07:17:30 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 07:17:30 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40530@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'MPLS'" , mpls@UU.NET Subject: RE: Best Effort LSP's Bandwidth Date: Mon, 8 May 2000 07:14:40 -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, According to Diffserv, some BW MUST be reserved for BE in each hop. This BW may be used during path computation for the QoS LSPs. Currently the BW assigned to each Diffserv class (including the BE) is provisioned and can only be changed by management. The RSVP-TE and CR-LDP only act as admission control in rejecting or accepting LSPs. However, it is quite possible for a node to measure the actual traffic in each class (including BE) and report that in IGP advertisements. Then the RSVP-TE or CR-LDP can use this information to borrow BW from other classes, if during the LSP setup enough BW is not available. Regards, -Shahram >-----Original Message----- >From: MPLS [mailto:mpls@apollo.mctr.umbc.edu] >Sent: Saturday, May 06, 2000 6:59 PM >To: mpls@UU.NET >Subject: Best Effort LSP's Bandwidth > > >Hi > >I am wondering if in a network we are running CR-LDP TE (for traffic >having QoS requirements as well as BE traffic), how do we >account for the >bandwidth used by best effort traffic while doing QoS path >computation for >flows having QoS requirements. > > Do we consider bandwidth required by BE traffic as zero or we take >average bandwidth used by BE flows into account. If we account BE LSPs >having zero bandwidth then how accurate are the QoS path >computations if >the BE flows account for a substantial portion of the network traffic. > >Manish > > From owner-mpls@UU.NET Mon May 8 10:56: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 KAA09034 for ; Mon, 8 May 2000 10:56: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 QQiohn15317; Mon, 8 May 2000 14:56:36 GMT Received: by mail-control.mail.uu.net id QQiohn23210 for mpls-outgoing; Mon, 8 May 2000 14:56:18 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 QQiohn23204 for ; Mon, 8 May 2000 14:56:14 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 QQiohn25784 for ; Mon, 8 May 2000 10:56:01 -0400 (EDT) From: peter.van_rompu@alcatel.be Received: from relay1.alcatel.be by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQiohn01669 for ; Mon, 8 May 2000 14:55:41 GMT Received: from bemta001.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e48Enkf17423; Mon, 8 May 2000 16:49:46 +0200 (MET DST) Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id C12568D9.00517542 ; Mon, 8 May 2000 16:49:44 +0200 X-Lotus-FromDomain: ALCATEL To: "Cucchiara, Joan" cc: mpls@UU.NET Message-ID: Date: Mon, 8 May 2000 16:49:35 +0200 Subject: RE: questions on Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi Joan, Typical, I would not want to configure generic labels in the application I have in mind - so I would not use the mplsLdpEntityConfTableGenericTable. I can indeed use the mplsInterfaceConfTable from the LSR MIB to restrict ranges if required. But if I don't use the mplsLdpEntityConfTableGenericTable how do I known on which interfaces a LDP Entity runs which uses generic labels ? Peter "Cucchiara, Joan" on 05/08/2000 04:02:10 PM To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, "Cucchiara, Joan" cc: mpls@UU.NET Subject: RE: questions on Hi Peter, > -----Original Message----- > From: peter.van_rompu@alcatel.be [mailto:peter.van_rompu@alcatel.be] > Sent: Monday, May 08, 2000 4:27 AM > To: Cucchiara, Joan > Cc: mpls@UU.NET > Subject: RE: questions on > > > > > Hello Joan, > > Thank you, I do now understand the use of the iFindex. :) > > But I still don't understand what is the use of the > mplsLdpEntityConfGenericTable and why a SNMP manager would > want to configure these actual generic labels. Also the > generic labels a LSR uses to forward data, are signalled by a > peer LSR (depending on > the label distribution method used, these labels might be > signalled as a result of a request of the LSR to set up a > label to a certain FEC or whenever a peer LSR decides to > announce a new label binding). So my point is that there is > no need to configure > these labels on the LSR, since the LSR will learn them > through LDP frm its peer LSRs. The way that we thought of this was that for LDP the generic labels need to be configured. Mostly to keep track of what generic labels are supported by LDP. I agree that these are "learned" through a peer but at some point, we thought that users would want to be able configure these labels. > > My opinion is that it makes more sense to configure in the > mplsLdpEntityConfGenericTable generic label ranges. There > should be no distinction between configuring label ranges for > interface specific labels and configuring label ranges for > generic labels. I > known platform wide label ranges are not signalled - but at > least the LSR need to known the generic label space(s) it can > use, as well as it needs to known the interface specific > labels ranges. The LSR MIB is being used to represent min/max in/out labels on a per Interface as well as perPlatform. Although, this isn't quite the same thing as you are asking for. We could add a generic label range configuration type of mechanism in the LDP MIB, there isn't really this concept in LDP, so hesitate to do so because the only use would be for an NMS (as far as we can see). An NMS could query the existing mplsLdpEntityConfGenericTable and figure out a label ranges for generic labels. Is there any other motivation for having this table, other than for the NMS? Thanks, Joan > > Peter > > > > > > "Cucchiara, Joan" on 05/04/2000 05:08:22 PM > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET > > cc: > > > > Subject: RE: questions on > > > > > > > > > > Hello Peter, > > > > > Hello Joan, > > > > Thank you for your reply - I think part of my confusion is > > because I don't understand the mplsLdpEntityConfGenericTable. > > > > From your reply I understand this table is used to configure > > the label range for Generic Labels. (I assumed that if you > > use generic labels, it is free to use the full 20bit space > > (with some reserved values) and there is no need to configure > > a range). > > > This table isn't used to configure label ranges; it is > used to configure the actual generic labels. > For LDP the generic labels > are configured as specified in the encaps doc > (draft-ietf-mpls-label-encaps-07.txt). > > > > But I still don't understand how you can configure a label > > range using the mplsLdpEntityConfGenericTable. What is the > > Currently, there is no way in LDP to communicate a label range > for generic labels in LDP. That is why > the MIB doesn't have a mechanism to configure a generic > label range. > > I don't know why this was not included, perhaps > someone could answer? > > > meaning of the mplsLdpConfGenericLabel object : is it an > > upper value for this label range ? From the MIB it seems more > > no, this table configures actual generic labels (not ranges). > > > like all label > > values within the generic label space need to be configured. > > yes, the MIB provides a mechanism for configuring the actual > generic labels only. There is no mechanism in the current version > of LDP for distributing a label range for generic labels. > > > > > I'm also not sure my understanding about the use of ifIndex > > in the various LDP MIB tables is correct : > > > > - About the ifIndex used in the mplsLdpEntityAtmParmsTable : > > I assume this is a ifIndex which maps to the vpi/vci defined > > in > > mplsLdpEntityDefaultControlVpi/mplsLdpEntityDefaultControlVci > > and that there is no need to create ifIndices for every ATM label. > > In practice ATM runs on an interface (in this sense a interface > being a physical port). > > The ifLayering for ATM does not > change for LDP. In theory you could have ATM (signalling) and > ATM (LDP) running over the same physical port. They could have > the same ifStack at the lower layers and differ at the upper > layers. > > > The ifType associated to that ifIndex is = mpls (166). Is > > this correct ? > > This is upto an implementation but for generic labels which get > placed in a shim header then that would be the mpls (166). > For ATM I think this is the cell layer and there would be > an "mpls(166) ifLayer" someplace above within the ifStack. > If there were label stacks being configured, and a label stack > being pushed and/or popped, then this would also be at an > ifLayer whose ifType was 166. > > > - From your reply I understand there is a ifIndex associated > > with a generic label space - what does it model ? (is it a > > I wouldn't say "generic label space", there are perPlatform or > perInterface label spaces. > > Again, I can only say that once data is forwarded using the > label, the value of the ifIndex represents where in the ifLayer > that the label was created. For generic labels this would be > the mpls layer (with ifType 166). > > > kind of virtual interface such as the AAL5 interface in the > > AtomMib ? can I derive the physical ports on which it is used > > through e.g. > > the ifStackTable ? can a SNMP Manager create such an interface ?). > > Yes, that is certainly the intention. > > For LDP a manager can configure the tables under the "Entity" > branch and this would result in LDP running on a specific physical > port. In other technologies such as IP over ATM or NHRP, it is > also necessary to consult the ifStack to understand which physical > port the protocols are running over, we specifically tried > to follow those other MIB models. > > -Joan > > > > Peter > > > > > > > > > > > > "Cucchiara, Joan" on 05/03/2000 04:35:29 PM > > > > > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET > > > > cc: > > > > > > > > Subject: RE: questions on > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: peter.van_rompu@alcatel.be > [mailto:peter.van_rompu@alcatel.be] > > > Sent: Wednesday, May 03, 2000 6:23 AM > > > To: mpls@UU.NET > > > Subject: questions on > > > > > > > > > > > > > Hello Peter, > > > > > > > > Hello, > > > > > > Can somebody help me this the following questions on the use > > > of the LDP MIB. > > > > > > 1) mplsLdpEntityTable > > > > > > How can a SNMP Manager derive on which interfaces a LDP > > entity runs ? > > > > > > For LDP entities with mplsLdpEntityOptionalParameters set to > > > atmParameters(2) or frameRelayParameters(3), my understanding > > > is that the SNMP manager can derive this from the ifIndex > > > found in the associated entry in the mplsLdpAtmParmsTable or > > > mplsLdpFrameRelayParmsTable. Once the SNMP Manager knowns > > > the ifIndex , the SNMP Manager can use the ifStackTable to > > > figure out on which ATM/FR port this entity runs (am I > correct ?) . > > > > yes. > > > > > > > > But how to do this for a LDP entity using generic labels ? > > > > This is the same. There is an ifIndex associated with a > > generic label also. This ifIndex would have the ifType of > > mpls (166). So in effect this would be the mpls interface layer. > > > > > > > > 2) mplsLdpEntityConfGenericTable > > > > > > I'm confused by the DESCRIPTION field of the > > > mplsLdpEntityConfGenericTable definition : why does a SNMP > > > Manager need to configure a generic label for LDP ? I thought > > > it was sufficient for LDP to known the label pools in order > > > to distribute labels ? > > > > Yes this is correct for ATM and Frame Relay, but for Generic > > Labels there is no mechanism in LDP to distribute a > > label pool (i.e. label range) for generic labels. > > (The last sentence of Section 3.5.3 of the LDP > > spec states: "Note that there is > > no Generic Session Parameters TLV for sessions which > > advertise Generic Labels.") > > > > > > > > > > 2) creation of a MPLS interface and activation of LDP on it. > > > > > > How can a SNMP manager create a MPLS interface using the > > > available MIBs and associate a LDP entity to that newly > > > created MPLS interface ? > > > > > > My understanding is that if the SNMP Manager wants LDP to use > > > ATM or FrameRelay labels on the MPLS interface, the SNMP > > > Manager needs to create an entry in the mplsLdpEntityTable, > > > an entry in the mplsLdpEntityAtmParmsTable (which allows to > > > configure for > > > instance the VPI/VCI to be used by LDP) and one or more > > > entries in the mplsLdpEntityConfAtmLabelRangeTable. As a > > > result of these row creations, the SNMP agent might create a > > > new MPLS interface, associate an ifIndex to it and fill the > > > ifIndex for the newly > > > created MPLS interface into the mplsLdpEntityTable. (Is this > > > correct ?) > > > > Essentially, yes you are correct. Although how this would > > take place exactly, would largely depend on when ifIndices are > > created (which is why the LDP MIB uses InterfaceIndexOrZero > > and why this is not needed for indexing into these Entity > > related tables.) > > > > In other words, an Entity is created at some point in time. > > At some other point in time, LSPs are established. The > > LSPs are between MPLS interfaces. It is upto the implementation > > on when the ifIndices are assigned, but the LDP MIB does stipulate > > that once LSP are established these InterfaceIndexOrZero objects > > need to have the value of the InterfaceIndex. > > > > > > > > > > But how can a SNMP manager create a new MPLS interface (for > > > instance on ATM) using generic labels ? In this case the LDP > > > entity might allready be configured - the only thing I would > > > exspect to do is to configure somehow a VPI/VCI to be used > > by this LDP > > > entity. > > > > I don't think this is correct. If it is an ATM interface then > > ATM labels (vpi,vci) would be used, so generic labels would not > > be used for this. > > > > You could have an incoming labelled packet which is from > > an ATM interface, forwarded out a PPP interface in which > > case you would forward using a generic label (for details > > see the draft-ietf-mpls-label-encaps-07.txt). In that > > case though, this would be two different labels. > > > > -Joan > > > > > > > > Best regards, > > > > > > Peter Van Rompu - Alcatel Telecom > > > > > > > > > > > > > > > From owner-mpls@UU.NET Mon May 8 11:18: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 ESMTP id LAA09451 for ; Mon, 8 May 2000 11:18: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 QQiohp00922; Mon, 8 May 2000 15:17:49 GMT Received: by mail-control.mail.uu.net id QQiohp02795 for mpls-outgoing; Mon, 8 May 2000 15:17:32 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 QQiohp02790 for ; Mon, 8 May 2000 15:17:23 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 QQiohp21185 for ; Mon, 8 May 2000 11:17:10 -0400 (EDT) Received: from mailgate.fore.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQiohp17537 for ; Mon, 8 May 2000 15:17:10 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA04236 for ; Mon, 8 May 2000 11:17:04 -0400 (EDT) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA16175 for ; Mon, 8 May 2000 11:17:05 -0400 (EDT) Message-ID: <3916DA72.E31759FD@fore.com> Date: Mon, 08 May 2000 11:17:06 -0400 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Bandwidth Allocation of LSP References: <20000507221255.12488.qmail@web1303.mail.yahoo.com> <3916B55C.A326814C@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Darek Skalecki wrote: > Simon G. M. Koo wrote: >> >> I would like to know, if a LSP is requested to setup with QoS >> requirement of certain bandwidth, will the system assign a fraction >> of the requirement if the full requirement cannot be satsified? Or >> just reject the setup request? And, if partial requirement can >> be satisfied, is there any negotiation procedure that the user can >> accept or reject the assigned amount of bandwidth? How is it >> working? > > I am not aware of either CR-LDP or RSVP-TE allowing for partial > reservations. If the full reservation cannot be made then a > reservation failure message is generated towards the originator, > eg: RESV_ERR for RSVP or PATH_ERR for RSVP-TE provided reservations > are made on PATH messages instead of on RESV messages which I belive > is the case for RSVP-TE in order to make "make-before-break" work. The > originator then can either request less bandwidth, compute a new > route or go to sleep. RSVP-TE does not have to make resevations on Path message processing in order to implement make before break, although it may make more sense for some hardware architectures to do so. As for partial reservations, RSVP (TE or otherwise) will not automatically grant a partial reservation if full resources are unavailable, however: 1: Since the actual amount reserved is supposed to be a function of the content of the Resv message and not of the Path message (except as an upper limit), it is theoreticlaly possible for an RSVP recipient (an egress node in MPLS) to request a lower reservation if it can't get the full resources. In non-MPLS implementations, where the signalling goes from application to application (and not router to router,) this is a real possibility - out of band application data may tell clients that it is OK to request reservations less than that of the TSPEC in the Path message. In MPLS, I don't think this ability will ever actually be used, because the applications at the TCP destinations are not where the RSVP Paths are terminating. 2: In the case where there are multiple recipients, which are requesting diferent amounts of resources (which can only happen in a multicast scenario), RSVP's merging rules may cause the amount reserved to be less than the total amount requested from all recipients, although it will never be less than the least amount requested from a single recpient. When more resources become available, RSVP will re-merge the requests and try to increase the amount of the reservation - via the "blockade" mechanism. This might come into play at some point in the future, where a multicast MPLS network is deployed, but for now, it's just an interesting footnote. -- David From owner-mpls@UU.NET Mon May 8 11:38:10 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 LAA09911 for ; Mon, 8 May 2000 11:38: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 QQiohq02586; Mon, 8 May 2000 15:38:04 GMT Received: by mail-control.mail.uu.net id QQiohq03881 for mpls-outgoing; Mon, 8 May 2000 15:37:47 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 QQiohq03859 for ; Mon, 8 May 2000 15:37: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 QQiohq24900 for ; Mon, 8 May 2000 11:36:50 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.104.68.2]) id QQiohq01405 for ; Mon, 8 May 2000 15:36:49 GMT Received: by bgslc02.tbg.com with Internet Mail Service (5.5.2448.0) id <27GZKC2P>; Mon, 8 May 2000 09:32:26 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE76F6314@bgslc02.tbg.com> From: Irwin Lazar To: "'Manshaee Mohammad-Hossein'" , manikantan Cc: mpls@UU.NET Subject: RE: A question Date: Mon, 8 May 2000 09:32:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Manshaee, We've got several links to vendor specific information on MPLS on the MPLS Resource Center - http://www.mplsrc.com/ irwin -----Original Message----- From: Manshaee Mohammad-Hossein [mailto:s7627237@sepahan.iut.ac.ir] Sent: Monday, May 08, 2000 8:22 AM To: manikantan Cc: mpls@UU.NET Subject: RE: A question hello and thanks in advanced for your good reply, I saw the paper. I want to know about the implimentation and use of this method in routers nowadays. I think that some Co. Like Cisco and Lucent did something about this subject. Would you please explain about this. Is their product available? And what do you think about the future of MPLS? Best, MH Manshaei On Mon, 8 May 2000, manikantan wrote: > Hello MH Manshaei > > The MPLS Ietf Drafts are inthe stages of becoming Standards > > Please look at these sites for more info > > http://www.ietf.org/html.charters/mpls-charter.html > > > http://www.mplsrc.com/ > > regards > mani > > -----Original Message----- > From: Manshaee Mohammad-Hossein [SMTP:s7627237@sepahan.iut.ac.ir] > Sent: Monday, May 08, 2000 4:24 PM > To: mpls@uu.net > Subject: A question > > > Hi > > I want to know about the standard of MPLS. > If i want to find a final document about MPLS standard, What can I do? > > Would you please send a Web address for me that I can find this document > there. > > Best, > > MH Manshaei > From owner-mpls@UU.NET Mon May 8 12:21: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 ESMTP id MAA11056 for ; Mon, 8 May 2000 12:21: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 QQioht14605; Mon, 8 May 2000 16:21:16 GMT Received: by mail-control.mail.uu.net id QQioht14756 for mpls-outgoing; Mon, 8 May 2000 16:20: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 QQioht14747 for ; Mon, 8 May 2000 16:20: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 QQioht14301 for ; Mon, 8 May 2000 12:20:28 -0400 (EDT) Received: from eleceng4.ee.queensu.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: eleceng4.ee.queensu.ca [130.15.16.15]) id QQioht02079 for ; Mon, 8 May 2000 16:20:27 GMT Received: from htm4.ee.queensu.ca (htm4 [130.15.16.75]) by eleceng4.ee.queensu.ca (8.9.3/8.9.3) with ESMTP id MAA06956 for ; Mon, 8 May 2000 12:20:26 -0400 (EDT) Received: from localhost (songf@localhost) by htm4.ee.queensu.ca (8.9.3/8.9.3) with SMTP id MAA11788 for ; Mon, 8 May 2000 12:20:26 -0400 (EDT) X-Authentication-Warning: htm4.ee.queensu.ca: songf owned process doing -bs Date: Mon, 8 May 2000 12:20:25 -0400 (EDT) From: fan Song X-Sender: songf@htm4 Reply-To: fan Song To: mpls@UU.NET Subject: looking for minutes of MPLS summit (Mar,2000) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am looking for minutes or articles of MPLS summit(Mar,2000). Does anybody know how to find them? Is there proceedings after the meeting? Thank you in advance. fan From owner-mpls@UU.NET Mon May 8 12:25: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 MAA11157 for ; Mon, 8 May 2000 12:25: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 QQioht05507; Mon, 8 May 2000 16:25:05 GMT Received: by mail-control.mail.uu.net id QQioht15097 for mpls-outgoing; Mon, 8 May 2000 16:24: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 QQioht15079 for ; Mon, 8 May 2000 16:24: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 QQioht03629 for ; Mon, 8 May 2000 12:24:09 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQioht04769 for ; Mon, 8 May 2000 16:24:09 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 09:29:04 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7C5C@ICARIAN> From: Eric Gray To: "'phaneesh'" Cc: mpls@UU.NET Subject: RE: LDP Events Date: Mon, 8 May 2000 09:29:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="x-user-defined" Sender: owner-mpls@UU.NET Precedence: bulk Phani, I'm not sure I understand the question, but I will make a stab at answering it. An internal setup event is triggered within the LSR implementation. Where it comes from will depend on the details of the implementation, the event(s) that brought it about and the control mode that applies. It may be driven by a separate routing function within the implementation after the routing function has performed some arbitration and created a new route table entry (and, possibly, found out that either it is the egress or it already has a mapping for a label from a downstream peer corresponding to this entry). It may also be driven by a management imperative. A more in depth understanding of internal events in general would require reading other MPLS documents - including framework, architecture and LDP. The details of internal events are not usually specified as they're internal to the implementation. -- Eric Gray > -----Original Message----- > From: phaneesh [mailto:phaneesh@chiplogic.com] > Sent: Sunday, May 07, 2000 11:10 PM > To: mpls@UU.NET > Subject: LDP Events > > > Hi, > > This is with reference to the draft-ietf-mpls-ldp-state-03.txt. > > I'm working with LDP. I came to know that "Internal Setup" event > comes to LDP, when MPLS recognizes a new FEC. I understood > that all Internal Events are generated within the LSR itself aiming at > local LDP. > > My doubt is, who will generate that event and how it alerts the LDP > ( i mean, what exactly the signaling mechanism used here). Assuming > that LDP runs over the Transport layer and MPLS runs below L3 > and above L2. > > Can u please clarify my doubt explaining on the "Internal > Setup" event. > > Thanks, > Phani. > From owner-mpls@UU.NET Mon May 8 12:41: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 MAA11665 for ; Mon, 8 May 2000 12:41: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 QQiohu28177; Mon, 8 May 2000 16:41:18 GMT Received: by mail-control.mail.uu.net id QQiohu23645 for mpls-outgoing; Mon, 8 May 2000 16:40:46 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 QQiohu23640 for ; Mon, 8 May 2000 16:40: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 QQiohu18064 for ; Mon, 8 May 2000 12:40:37 -0400 (EDT) From: nick.t.davis@bellatlantic.com Received: from emr01.bellatlantic.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: emr01.bellatlantic.com [198.23.5.143]) id QQiohu16042 for ; Mon, 8 May 2000 16:40:37 GMT Received: from imr01.bellatlantic.com (imr01 [141.152.156.12]) by emr01.bellatlantic.COM (8.8.8/8.8.8) with ESMTP id MAA09537; Mon, 8 May 2000 12:40:37 -0400 (EDT) Received: from fhsmtp03.bell-atl.com (is051952.bellatlantic.com [141.152.101.51]) by imr01.bellatlantic.com (8.8.8/8.8.5) with SMTP id MAA13655; Mon, 8 May 2000 12:40:36 -0400 (EDT) Received: by fhsmtp03.bell-atl.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 852568D9.005B994C ; Mon, 8 May 2000 12:40:30 -0400 X-Lotus-FromDomain: BELL-ATL To: "fan Song" cc: mpls@UU.NET Message-ID: <852568D9.005B95F3.00@fhsmtp03.bell-atl.com> Date: Mon, 8 May 2000 12:40:22 -0400 Subject: Re: looking for minutes of MPLS summit (Mar,2000) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk There are a large number of people that are looking for the minutes from the March meeting, myself included. Nick From owner-mpls@UU.NET Mon May 8 12:47: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 MAA11758 for ; Mon, 8 May 2000 12:47: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 QQiohv02307; Mon, 8 May 2000 16:46:58 GMT Received: by mail-control.mail.uu.net id QQiohv24188 for mpls-outgoing; Mon, 8 May 2000 16:46: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 QQiohv24183 for ; Mon, 8 May 2000 16:46: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 QQiohv07412 for ; Mon, 8 May 2000 12:46:05 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQiohv01549 for ; Mon, 8 May 2000 16:46:05 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 09:51:05 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7C5D@ICARIAN> From: Eric Gray To: "'Trilok Chand'" Cc: mpls@UU.NET Subject: RE: ILM mappings Date: Mon, 8 May 2000 09:50:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB90D.995B68A2" 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_01BFB90D.995B68A2 Content-Type: text/plain; charset="iso-8859-1" TrilokChand, An interesting question. How did there get to be multiple NHLFEs for a single incoming label? Suspending disbelief on this for a moment, however, and supposing there was a reason for this to happen - the implementer must have had some plan for demultiplexing the single label to determine which NHLFE would be used. One way might be to pop the label and look at what comes after it - but a pop instruction should be a single NHLFE (with - in this case - a next hop of "self"). Is there a useful application for this scenario? It seems to me that there would not be multiple NHLFE entries for a single label as this will defeat the purpose for having a label. But, even if there was a reason to do this, the implementation that causes this to happen is the same implementation that has to deal with the outcome. If you shoot yourself in the foot, it will hurt. :-) -- Eric Gray -----Original Message----- From: Trilok Chand [mailto:trilok@chiplogic.com] Sent: Monday, May 08, 2000 3:25 AM To: mpls@UU.NET Subject: ILM mappings Hi, Can anybody tell where can i get information about choosing an ILM mapping when there are multiple NHLFEs existing for an incoming label? Thanks in advance, TrilokChand ------_=_NextPart_001_01BFB90D.995B68A2 Content-Type: text/html; charset="iso-8859-1"
TrilokChand,
 
    An interesting question.  How did there get to be multiple
NHLFEs for a single incoming label?  Suspending disbelief
on this for a moment, however, and supposing there was a
reason for this to happen - the implementer must have had
some plan for demultiplexing the single label to determine
which NHLFE would be used.  One way might be to pop the
label and look at what comes after it - but a pop instruction
should be a single NHLFE (with - in this case - a next hop
of "self").  Is there a useful application for this scenario?
 
    It seems to me that there would not be multiple NHLFE
entries for a single label as this will defeat the purpose for
having a label.  But, even if there was a reason to do this,
the implementation that causes this to happen is the same
implementation that has to deal with the outcome.
 
    If you shoot yourself in the foot, it will hurt. :-)
 
--
Eric Gray
-----Original Message-----
From: Trilok Chand [mailto:trilok@chiplogic.com]
Sent: Monday, May 08, 2000 3:25 AM
To: mpls@UU.NET
Subject: ILM mappings

Hi,
        Can anybody tell where can i get information about choosing an ILM mapping when there are multiple NHLFEs existing for an incoming label? 
 
Thanks in advance,
TrilokChand
 
------_=_NextPart_001_01BFB90D.995B68A2-- From owner-mpls@UU.NET Mon May 8 13:48:10 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 NAA13497 for ; Mon, 8 May 2000 13:48: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 QQiohz29600; Mon, 8 May 2000 17:48:06 GMT Received: by mail-control.mail.uu.net id QQiohz14316 for mpls-outgoing; Mon, 8 May 2000 17:47: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 QQiohz14306 for ; Mon, 8 May 2000 17:47:16 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 QQiohz17028; Mon, 8 May 2000 13:46:08 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35]) id QQiohz11322; Mon, 8 May 2000 17:46:08 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Mon, 8 May 2000 12:37:57 -0400 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KQHR15AD; Mon, 8 May 2000 12:37:51 -0400 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJ8TTHYJ; Mon, 8 May 2000 12:37:52 -0400 Message-ID: <3916ECC2.47C4A28A@americasm01.nt.com> Date: Mon, 08 May 2000 12:35:14 -0400 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: otel@ce.chalmers.se CC: mpls@UU.NET, te-wg@UU.NET Subject: Re: TEWG framework updates / MPLS-TE drafts References: <14612.42804.714266.260861@rasputin.ce.chalmers.se> <3916A947.DCD48F5@americasm01.nt.com> <14614.44626.241758.665317@rasputin.ce.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Florian-Daniel Otel wrote: > > > A good site to check for internet-drafts related to MPLS is > > http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ > > This site archives drafts going back the the beginings > > of the MPLS WG, as well as related drafts. > > > Both of the drafts you are looking for are available there. > > Found the site in the mean time (that draft is also on Dan Awduche web > site too) but thanks a lot. Also i was implictly asking about the updated > version (i.e. draft-li-mpls-igp-te-01.txt). > > Anyway, that was not the main intention (and i appologize for not > making it clear from the first posting): What I was primarily > intrested in was about the continuation of these drafts i.e. were they > dropped (if so why ? was there a discussion about this ? where ? > archives ?) , there was no interest in them, there is an update > planned, they advanced on IETF track, etc. ? There are drafts that specify in detail the information to be carried in OSPF and IS-IS for TE purposes. They can be found at the above website. The other questions about the drafts I will leave to the respective authors. - Philip From owner-mpls@UU.NET Mon May 8 13:57: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 ESMTP id NAA13740 for ; Mon, 8 May 2000 13:57: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 QQiohz06352; Mon, 8 May 2000 17:57:47 GMT Received: by mail-control.mail.uu.net id QQiohz15070 for mpls-outgoing; Mon, 8 May 2000 17:57: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 QQiohz15065 for ; Mon, 8 May 2000 17:57: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 QQiohz18772 for ; Mon, 8 May 2000 13:57:04 -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 QQiohz05748 for ; Mon, 8 May 2000 17:57:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA21135 for mpls@uu.net; Mon, 8 May 2000 13:57:02 -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 QQiohz15029 for ; Mon, 8 May 2000 17:56: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 QQiohz18520 for ; Mon, 8 May 2000 13:55:36 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQiohz17643 for ; Mon, 8 May 2000 17:55:35 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA01315; Mon, 8 May 2000 10:55:28 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 10:55:27 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4053A@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Eric Gray'" , "'Trilok Chand'" Cc: mpls@UU.NET Subject: RE: ILM mappings Date: Mon, 8 May 2000 10:52:34 -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 Eric, There are two scenarios that a single label may correspond to multiple NHLFEs: 1) Some part of an LSP is E-LSP and another part is L-LSP 2) In case of Multicast. Regards, Shahram Davari Product Research PMC-Sierra Inc. 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 -----Original Message----- From: Eric Gray [mailto:EGray@zaffire.com] Sent: Monday, May 08, 2000 12:51 PM To: 'Trilok Chand' Cc: mpls@UU.NET Subject: RE: ILM mappings TrilokChand, An interesting question. How did there get to be multiple NHLFEs for a single incoming label? Suspending disbelief on this for a moment, however, and supposing there was a reason for this to happen - the implementer must have had some plan for demultiplexing the single label to determine which NHLFE would be used. One way might be to pop the label and look at what comes after it - but a pop instruction should be a single NHLFE (with - in this case - a next hop of "self"). Is there a useful application for this scenario? It seems to me that there would not be multiple NHLFE entries for a single label as this will defeat the purpose for having a label. But, even if there was a reason to do this, the implementation that causes this to happen is the same implementation that has to deal with the outcome. If you shoot yourself in the foot, it will hurt. :-) -- Eric Gray -----Original Message----- From: Trilok Chand [mailto:trilok@chiplogic.com] Sent: Monday, May 08, 2000 3:25 AM To: mpls@UU.NET Subject: ILM mappings Hi, Can anybody tell where can i get information about choosing an ILM mapping when there are multiple NHLFEs existing for an incoming label? Thanks in advance, TrilokChand From owner-mpls@UU.NET Mon May 8 14:18: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 OAA14211 for ; Mon, 8 May 2000 14:18: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 QQioib04160; Mon, 8 May 2000 18:18:36 GMT Received: by mail-control.mail.uu.net id QQioib24390 for mpls-outgoing; Mon, 8 May 2000 18:18:03 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQioib24377 for ; Mon, 8 May 2000 18:17:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQioib22424 for ; Mon, 8 May 2000 14:17:48 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQioib03405 for ; Mon, 8 May 2000 18:17:48 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 11:22:48 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7C60@ICARIAN> From: Eric Gray To: "'Shahram Davari'" , Eric Gray , "'Trilok Chand'" Cc: mpls@UU.NET Subject: RE: ILM mappings Date: Mon, 8 May 2000 11:22:40 -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 Shahram, I guess I should have said - "If you shoot yourself in the foot, it will hurt - but as long as you don't miss, it isn't my problem." See comments in line. In general, however, as soon as you have an application, you have the answer to the original question. Clearly, you can have a reason to shoot yourself in the foot. :-) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, May 08, 2000 10:53 AM > To: 'Eric Gray'; 'Trilok Chand' > Cc: mpls@UU.NET > Subject: RE: ILM mappings > > > Hi Eric, > > There are two scenarios that a single label may correspond to multiple > NHLFEs: > > 1) Some part of an LSP is E-LSP and another part is L-LSP I think you would have to have at least two labels - one for (each) L-LSP and one for a corresponding E-LSP. It's quite reasonable to use the same NHLFE for all packets using the same label in an E-LSP as long as the next hop information would be the same - since the E-bits are used to determine the queuing behavior relative to forwarding these packets to the next hop. It is also quite reasonable to treat the EXP bits as part of the label (in the E-LSP case) for the purpose of determining the NHLFE that applies. But that's quibbling. I concede that this may be a use for having multiple NHLFEs corresponding to a single incoming label. > 2) In case of Multicast. Conceded. However, in both of these cases, the resolution to be used is built right into the application it is used for. In the first case, the EXP bits are used to differentiate one NHLFE from another. In the second case, all NHLFEs are used. It could be argued that a combination scenario may also occur. This application also has its own built in answer. > > Regards, > Shahram Davari > Product Research > PMC-Sierra Inc. > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > -----Original Message----- > From: Eric Gray [mailto:EGray@zaffire.com] > Sent: Monday, May 08, 2000 12:51 PM > To: 'Trilok Chand' > Cc: mpls@UU.NET > Subject: RE: ILM mappings > > > TrilokChand, > > An interesting question. How did there get to be multiple > NHLFEs for a single incoming label? Suspending disbelief > on this for a moment, however, and supposing there was a > reason for this to happen - the implementer must have had > some plan for demultiplexing the single label to determine > which NHLFE would be used. One way might be to pop the > label and look at what comes after it - but a pop instruction > should be a single NHLFE (with - in this case - a next hop > of "self"). Is there a useful application for this scenario? > > It seems to me that there would not be multiple NHLFE > entries for a single label as this will defeat the purpose for > having a label. But, even if there was a reason to do this, > the implementation that causes this to happen is the same > implementation that has to deal with the outcome. > > If you shoot yourself in the foot, it will hurt. :-) > > -- > Eric Gray > > -----Original Message----- > From: Trilok Chand [mailto:trilok@chiplogic.com] > Sent: Monday, May 08, 2000 3:25 AM > To: mpls@UU.NET > Subject: ILM mappings > > > Hi, > Can anybody tell where can i get information about > choosing an ILM > mapping when there are multiple NHLFEs existing for an > incoming label? > > Thanks in advance, > TrilokChand > > > From owner-mpls@UU.NET Mon May 8 14:28: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 ESMTP id OAA14441 for ; Mon, 8 May 2000 14:28: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 QQioib28406; Mon, 8 May 2000 18:28:33 GMT Received: by mail-control.mail.uu.net id QQioib25043 for mpls-outgoing; Mon, 8 May 2000 18:28:13 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQioib25038 for ; Mon, 8 May 2000 18:28:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQioib23636 for ; Mon, 8 May 2000 14:28:09 -0400 (EDT) Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQioib11100 for ; Mon, 8 May 2000 18:28:09 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id UAA28809; Mon, 8 May 2000 20:28:08 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id UAA06416; Mon, 8 May 2000 20:28:08 +0200 (MET DST) Date: Mon, 8 May 2000 20:28:08 +0200 (MET DST) To: fan Song Cc: mpls@UU.NET Subject: Re: looking for minutes of MPLS summit (Mar,2000) In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14615.1740.371891.285296@rasputin.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > Hi, > I am looking for minutes or articles of MPLS summit(Mar,2000). Does > anybody know how to find them? Is there proceedings after the meeting? > Thank you in advance. In case you didn't knew that already at http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ you have the agenda and the two BOFs. But there are no meeting minutes, and i subscribe to a request for them (if there are any lurking somewhere) > fan Cheers, Florian From owner-mpls@UU.NET Mon May 8 17:53: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 ESMTP id RAA20739 for ; Mon, 8 May 2000 17:53: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 QQioip24204; Mon, 8 May 2000 21:52:44 GMT Received: by mail-control.mail.uu.net id QQioip02416 for mpls-outgoing; Mon, 8 May 2000 21:52:29 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQioip02411 for ; Mon, 8 May 2000 21:52:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQioip20474 for ; Mon, 8 May 2000 17:52:00 -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 QQioip23625 for ; Mon, 8 May 2000 21:51:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA29321 for mpls@uu.net; Mon, 8 May 2000 17:51:59 -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 QQioip02372 for ; Mon, 8 May 2000 21:51: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 QQioip19097 for ; Mon, 8 May 2000 17:51: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 QQioip07947 for ; Mon, 8 May 2000 21:51:32 GMT Received: from stripedbass.cisco.com (stripedbass.cisco.com [161.44.134.83]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA29250; Mon, 8 May 2000 17:51:28 -0400 (EDT) Received: (tnadeau@localhost) by stripedbass.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id RAA06943; Mon, 8 May 2000 17:51:28 -0400 (EDT) Date: Mon, 8 May 2000 17:51:28 -0400 (EDT) Message-Id: <200005082151.RAA06943@stripedbass.cisco.com> From: "Thomas D. Nadeau" To: mpls@UU.NET CC: tnadeau@cisco.com, Cheenu Srinivasan , arun@force10networks.com Subject: MPLS Packet Classifier MIB Sender: owner-mpls@UU.NET Precedence: bulk FYI, we have published a new draft MIB called "Multiprotocol Label Switching Packet Classification Management Information Base Using SMIv2" under the ID: draft-nadeau-mpls-packet-classifier-mib-00.txt I have included the abstract for your reading pleasure. The draft will be available in a day or so on the IETF Web Site. Please direct comments about this draft to the IETF mailing list. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for specifying packet classification rules and corresponding actions for use with Multiprotocol Label Switching (MPLS). From owner-mpls@UU.NET Mon May 8 18:40: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 SAA21705 for ; Mon, 8 May 2000 18:40: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 QQiois25161; Mon, 8 May 2000 22:39:54 GMT Received: by mail-control.mail.uu.net id QQiois13202 for mpls-outgoing; Mon, 8 May 2000 22:39: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 QQiois13197 for ; Mon, 8 May 2000 22:39: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 QQiois24308 for ; Mon, 8 May 2000 18:38:54 -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 QQiois24281 for ; Mon, 8 May 2000 22:38: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 PAA29660 for ; Mon, 8 May 2000 15:38:58 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id SAA18743 for mpls@uu.net; Mon, 8 May 2000 18:38:52 -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 QQioiq11379 for ; Mon, 8 May 2000 22:07: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 QQioiq20931 for ; Mon, 8 May 2000 18:07:51 -0400 (EDT) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.248.148.133]) id QQioiq18475 for ; Mon, 8 May 2000 22:07:49 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 15:07:11 -0700 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Subject: end of last call for draft-ietf-mpls-crlsp-modify-01.txt Date: Mon, 8 May 2000 15:07:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB939.C1B43370" 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_01BFB939.C1B43370 Content-Type: text/plain; charset="iso-8859-1" The last call for draft-ietf-mpls-crlsp-modify-01.txt has closed. Could the authors please update the draft with comments received during the last call and re-issue the draft? Thanks, - Vijay ----Original Message----- From: Vijay Srinivasan [mailto:vsriniva@cosinecom.com] Sent: Monday, April 10, 2000 1:10 AM To: 'mpls@uu.net' Cc: 'swallow@cisco.com'; Ash, Gerald R (Jerry), ALARC Subject: last call for draft-ietf-mpls-crlsp-modify-01.txt The authors of draft-ietf-mpls-crlsp-modify-01.txt have requested that the draft be progressed to WG last call. This e-mail serves as a commencement of last call for this document, ending in two weeks. Please post your comments to the list. Thanks, - Vijay ------_=_NextPart_001_01BFB939.C1B43370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable end of last call for draft-ietf-mpls-crlsp-modify-01.txt =

The last call for draft-ietf-mpls-crlsp-modify-01.txt = has closed.  Could the authors please update the draft with = comments received during the last call and re-issue the = draft?

Thanks,
- Vijay

----Original Message-----
From: Vijay Srinivasan [mailto:vsriniva@cosinecom.com= ]
Sent: Monday, April 10, 2000 1:10 AM
To: 'mpls@uu.net'
Cc: 'swallow@cisco.com'; Ash, Gerald R (Jerry), = ALARC
Subject: last call for = draft-ietf-mpls-crlsp-modify-01.txt



The authors of draft-ietf-mpls-crlsp-modify-01.txt = have requested that the
draft be progressed to WG last call.  This = e-mail serves as a commencement
of last call for this document, ending in two = weeks.  Please post your
comments to the list.

Thanks,
- Vijay

------_=_NextPart_001_01BFB939.C1B43370-- From owner-mpls@UU.NET Mon May 8 20:22: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 UAA23770 for ; Mon, 8 May 2000 20:22: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 QQioiz10739; Tue, 9 May 2000 00:22:21 GMT Received: by mail-control.mail.uu.net id QQioiz05112 for mpls-outgoing; Tue, 9 May 2000 00:21: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 QQioiz05107 for ; Tue, 9 May 2000 00:21:53 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 QQioiz05202 for ; Mon, 8 May 2000 20:21:45 -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 QQioiz25892 for ; Tue, 9 May 2000 00:21:45 GMT Message-ID: <08cae0df3e52932fa1af385a27561eeb39175a4b@force10networks.com> From: Arun Viswanathan To: "'mpls@UU.NET'" Subject: RE: Second WG last call on LSR MIB Date: Mon, 8 May 2000 17:21:44 -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 Based on a few comments we would like to make the following changes to the draft in the next rev (at the close of this call). 1. Removing mplsInSegmentAdminStatus, mplsInSegmentOperStatus, mplsOutSegmentAdminStatus, and mplsOutSegmentOperStatus from MplsInSegmentEntry and MplsOutSegmentEntry respectively. They seem to serve no purpose. Similar objects in MplsXCEntry subsumes their functionality. 2. Removing mplsInterfaceInPackets, mplsInterfaceInDiscards, mplsInterfaceOutPackets, and mplsInterfaceOutDiscards from the MplsInterfacePerfEntry. If you have any objection to these changes please speak up now. -arun > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of George > Swallow > Sent: Thursday, May 04, 2000 2:09 PM > To: mpls@UU.NET > Subject: Second WG last call on LSR MIB > > > Folks - > > The previous last call resulted in enough changes that a second WG > last call is in order. The purpose of this last call is not to raise > new issues, but to insure that the issues raised in the previous last > call have been satisfactorily addressed. As always, things that are > just plain broken are always fair game. > > The last call will end Thurday, May 11, 5 pm edt. > > The draft is: > > MPLS Label Switch Router Management Information Base Using SMIv2 > > draft-ietf-mpls-lsr-mib-04.txt > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > > > From owner-mpls@UU.NET Mon May 8 20:31: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 UAA23967 for ; Mon, 8 May 2000 20:31: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 QQioja15900; Tue, 9 May 2000 00:30:46 GMT Received: by mail-control.mail.uu.net id QQioja05551 for mpls-outgoing; Tue, 9 May 2000 00:30: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 QQioiz05515 for ; Tue, 9 May 2000 00:29:57 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 QQioiz05925 for ; Mon, 8 May 2000 20:29: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 QQioiz15145 for ; Tue, 9 May 2000 00:29:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA16329 for mpls@uu.net; Mon, 8 May 2000 20:29:51 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQioiz05500 for ; Tue, 9 May 2000 00:29:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQioiz05014; Mon, 8 May 2000 20:29:22 -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 QQioiz14903; Tue, 9 May 2000 00:29:22 GMT Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id TAA07120; Mon, 8 May 2000 19:29:06 -0500 (CDT) Received: from tddny.fujitsu.com (pc183.tddny.fujitsu.com [167.254.242.183]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJ6F0LB8; Mon, 8 May 2000 19:29:08 -0500 Message-ID: <39175BD0.523453AA@tddny.fujitsu.com> Date: Mon, 08 May 2000 20:29:04 -0400 From: "Indra.Widjaja" X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: otel@ce.chalmers.se CC: Philip Matthews , mpls@UU.NET, te-wg@UU.NET Subject: Re: TEWG framework updates / MPLS-TE drafts References: <14612.42804.714266.260861@rasputin.ce.chalmers.se> <3916A947.DCD48F5@americasm01.nt.com> <14614.44626.241758.665317@rasputin.ce.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Florian: As to the MATE draft, it's still incomplete and waiting for new results. The most critical and difficult aspect of any adaptive load balancing is to ensure the stability of the network and be simultaneously responsive. It's not clear if adaptive load balancing (operating in a relatively short time scale) in general is ready for prime time yet. indra Florian-Daniel Otel wrote: > > A good site to check for internet-drafts related to MPLS is > > http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ > > This site archives drafts going back the the beginings > > of the MPLS WG, as well as related drafts. > > > Both of the drafts you are looking for are available there. > > Found the site in the mean time (that draft is also on Dan Awduche web > site too) but thanks a lot. Also i was implictly asking about the updated > version (i.e. draft-li-mpls-igp-te-01.txt). > > Anyway, that was not the main intention (and i appologize for not > making it clear from the first posting): What I was primarily > intrested in was about the continuation of these drafts i.e. were they > dropped (if so why ? was there a discussion about this ? where ? > archives ?) , there was no interest in them, there is an update > planned, they advanced on IETF track, etc. ? > > Thanks, > > > - Philip > > Florian. From owner-mpls@UU.NET Mon May 8 21:52: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 VAA26018 for ; Mon, 8 May 2000 21:52: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 QQiojf18441; Tue, 9 May 2000 01:52:43 GMT Received: by mail-control.mail.uu.net id QQiojf17781 for mpls-outgoing; Tue, 9 May 2000 01:52:23 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiojf17775 for ; Tue, 9 May 2000 01:52:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiojf12365 for ; Mon, 8 May 2000 21:52: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 QQiojf18015 for ; Tue, 9 May 2000 01:52:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA21842 for mpls@uu.net; Mon, 8 May 2000 21:52:09 -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 QQiojf17725 for ; Tue, 9 May 2000 01:51: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 QQiojf11026 for ; Mon, 8 May 2000 21:50:53 -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 QQiojf01874 for ; Tue, 9 May 2000 01:50:52 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 21:50:52 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15FAC3@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'arun@force10networks.com'" , "'csrinivasan@tachion.com'" , "'tnadeau@cisco.com'" Cc: "'mpls@uu.net'" Subject: LSR MIB last call comments Date: Mon, 8 May 2000 21:50:48 -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 Tom, Arun and Cheenu, The first part of these comments are regarding changes to the MplsObjectOwner which were made. The second part of these comments are based on comments made during the prior last call. I was under the impression that we had reached some agreement but did not see the updates in the latest version of the MIB. The third part are comments which are editorial in nature. -Joan First Part =========== * MplsObjectOwner TC, 'crldp' should definitely be added -- it appeared in early versions of the MIB, so must have been mistakenly removed. 'unknown' appears here, it would seem that the agent would always know where the data to create a row originated from, so am wondering why this was added. I still don't understand why other possibilities here such as config file, cli, web-interface, etc. were not added for completeness sake. If there is a reason to omit these from the TC then that would be important to understand. What is the reason for singling out this particular subset? Second Part: =========== * mplsInterfaceTotalBuffer and mplsInterfaceAvailableBuffer was expecting that more description for these objects would be given (what these values mean with regard to an mpls interface). Even a reference would be helpful because the framework documents talks about buffering as related to merge issues so if this is what is meant, that is not clear from the description. * mplsInterfacePerfEntry AUGMENTS the mplsInterfaceConfEntry. More description was supposed to be given as to counting for Interfaces which participate in both the perInterface and perPlatform situation. For example, you could count these things twice (for the situation of the 0 index, and for a perInteface non-zero ifIndex), or you could count things once and only increment one of the row's counters. * mplsInSegment Table has no "IndexNext" object and one was supposed to be added. * individual trap/enable objects still appear glumped together at the end of the MIB, these were supposed to be distributed closer to their relevant objects. * MIB heirarchy -- there was supposed to be some reorganization so that things would be grouped under branches instead of everything appearing under mpslLsrObjects. Third Part (editorial) ====================== * Section 7. "The objects described in Sections 7.3-7.8, when considered together, are equivalent to the tables described in the MPLS architecture document [MPLSArch], that is, the Incoming Label Map (ILM) and the Next Hop Label Forwarding Entry (NHLFE) tables." there aren't any ILM or NHLFE tables, so this appears to be an outdated reference. * mplsLsrMIB MODULE-IDENTITY DESCRIPTION "This MIB contains managed object definitions for the Multiprotocol Label Switching (MPLS) Router as defined in: Rosen, E., Viswanathan, A., and R. Callon, Multiprotocol Label Switching Architecture, Internet Draft , February 2000." * the date of the draft-ietf-mpls-arch-06.txt is August 1999. * Revision History is not in reverse chronological order and it should be. ------------------ From owner-mpls@UU.NET Mon May 8 22:09: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 WAA26275 for ; Mon, 8 May 2000 22:09: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 QQiojg27424; Tue, 9 May 2000 02:08:09 GMT Received: by mail-control.mail.uu.net id QQiojg26518 for mpls-outgoing; Tue, 9 May 2000 02:07: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 QQiojg26513 for ; Tue, 9 May 2000 02:07: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 QQiojg12362 for ; Mon, 8 May 2000 22:07:35 -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 QQiojg11022 for ; Tue, 9 May 2000 02:07:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA23145 for mpls@uu.net; Mon, 8 May 2000 22:07:33 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiojg26496 for ; Tue, 9 May 2000 02:07:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiojg13431 for ; Mon, 8 May 2000 22:07:02 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiojg26681 for ; Tue, 9 May 2000 02:07:02 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 May 2000 22:07:02 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15FAC4@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'peter.van_rompu@alcatel.be'" , "Cucchiara, Joan" Cc: mpls@UU.NET Subject: RE: questions on Date: Mon, 8 May 2000 22:06:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: peter.van_rompu@alcatel.be [mailto:peter.van_rompu@alcatel.be] > Sent: Monday, May 08, 2000 10:50 AM > To: Cucchiara, Joan > Cc: mpls@UU.NET > Subject: RE: questions on > > > > > Hi Joan, > > Typical, I would not want to configure generic labels in the > application I have in mind - so I would not use the > mplsLdpEntityConfTableGenericTable. I can indeed use the > mplsInterfaceConfTable from the LSR MIB to restrict ranges if > required. But if I don't > use the mplsLdpEntityConfTableGenericTable how do I known on > which interfaces a LDP Entity runs which uses generic labels ? I can see your point. It seems reasonable to set up a generic label range for an interface, regardless of whether generic labels are ever really configured. We will add this. -Joan > > Peter > > > > > > "Cucchiara, Joan" on 05/08/2000 04:02:10 PM > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, "Cucchiara, > Joan" > > cc: mpls@UU.NET > > > > Subject: RE: questions on > > > > > > > > > Hi Peter, > > > -----Original Message----- > > From: peter.van_rompu@alcatel.be [mailto:peter.van_rompu@alcatel.be] > > Sent: Monday, May 08, 2000 4:27 AM > > To: Cucchiara, Joan > > Cc: mpls@UU.NET > > Subject: RE: questions on > > > > > > > > > > Hello Joan, > > > > Thank you, I do now understand the use of the iFindex. > > :) > > > > > But I still don't understand what is the use of the > > mplsLdpEntityConfGenericTable and why a SNMP manager would > > want to configure these actual generic labels. Also the > > generic labels a LSR uses to forward data, are signalled by a > > peer LSR (depending on > > the label distribution method used, these labels might be > > signalled as a result of a request of the LSR to set up a > > label to a certain FEC or whenever a peer LSR decides to > > announce a new label binding). So my point is that there is > > no need to configure > > these labels on the LSR, since the LSR will learn them > > through LDP frm its peer LSRs. > > The way that we thought of this was that for LDP the generic > labels need to be configured. Mostly to keep track of > what generic labels are supported by LDP. > > I agree that these are "learned" through a peer but at some point, > we thought that users would want to be able configure these labels. > > > > > My opinion is that it makes more sense to configure in the > > mplsLdpEntityConfGenericTable generic label ranges. There > > should be no distinction between configuring label ranges for > > interface specific labels and configuring label ranges for > > generic labels. I > > known platform wide label ranges are not signalled - but at > > least the LSR need to known the generic label space(s) it can > > use, as well as it needs to known the interface specific > > labels ranges. > > The LSR MIB is being used to represent min/max in/out labels > on a per Interface as well as perPlatform. Although, this isn't > quite the same thing as you are asking for. > > We could add a generic label range configuration type > of mechanism in the LDP MIB, there isn't really this concept > in LDP, so hesitate to do so because the only use would be > for an NMS (as far as we can see). An NMS could query the existing > mplsLdpEntityConfGenericTable and figure out a label ranges for > generic labels. Is there any other motivation for having > this table, other than for the NMS? > > Thanks, Joan > > > > > Peter > > > > > > > > > > > > "Cucchiara, Joan" on 05/04/2000 05:08:22 PM > > > > > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET > > > > cc: > > > > > > > > Subject: RE: questions on > > > > > > > > > > > > > > > > > > > > Hello Peter, > > > > > > > > Hello Joan, > > > > > > Thank you for your reply - I think part of my confusion is > > > because I don't understand the mplsLdpEntityConfGenericTable. > > > > > > From your reply I understand this table is used to configure > > > the label range for Generic Labels. (I assumed that if you > > > use generic labels, it is free to use the full 20bit space > > > (with some reserved values) and there is no need to configure > > > a range). > > > > > > This table isn't used to configure label ranges; it is > > used to configure the actual generic labels. > > For LDP the generic labels > > are configured as specified in the encaps doc > > (draft-ietf-mpls-label-encaps-07.txt). > > > > > > > But I still don't understand how you can configure a label > > > range using the mplsLdpEntityConfGenericTable. What is the > > > > Currently, there is no way in LDP to communicate a label range > > for generic labels in LDP. That is why > > the MIB doesn't have a mechanism to configure a generic > > label range. > > > > I don't know why this was not included, perhaps > > someone could answer? > > > > > meaning of the mplsLdpConfGenericLabel object : is it an > > > upper value for this label range ? From the MIB it seems more > > > > no, this table configures actual generic labels (not ranges). > > > > > like all label > > > values within the generic label space need to be configured. > > > > yes, the MIB provides a mechanism for configuring the actual > > generic labels only. There is no mechanism in the current version > > of LDP for distributing a label range for generic labels. > > > > > > > > I'm also not sure my understanding about the use of ifIndex > > > in the various LDP MIB tables is correct : > > > > > > - About the ifIndex used in the mplsLdpEntityAtmParmsTable : > > > I assume this is a ifIndex which maps to the vpi/vci defined > > > in > > > mplsLdpEntityDefaultControlVpi/mplsLdpEntityDefaultControlVci > > > and that there is no need to create ifIndices for every ATM label. > > > > In practice ATM runs on an interface (in this sense a interface > > being a physical port). > > > > The ifLayering for ATM does not > > change for LDP. In theory you could have ATM (signalling) and > > ATM (LDP) running over the same physical port. They could have > > the same ifStack at the lower layers and differ at the upper > > layers. > > > > > The ifType associated to that ifIndex is = mpls (166). Is > > > this correct ? > > > > This is upto an implementation but for generic labels which get > > placed in a shim header then that would be the mpls (166). > > For ATM I think this is the cell layer and there would be > > an "mpls(166) ifLayer" someplace above within the ifStack. > > If there were label stacks being configured, and a label stack > > being pushed and/or popped, then this would also be at an > > ifLayer whose ifType was 166. > > > > > - From your reply I understand there is a ifIndex associated > > > with a generic label space - what does it model ? (is it a > > > > I wouldn't say "generic label space", there are perPlatform or > > perInterface label spaces. > > > > Again, I can only say that once data is forwarded using the > > label, the value of the ifIndex represents where in the ifLayer > > that the label was created. For generic labels this would be > > the mpls layer (with ifType 166). > > > > > kind of virtual interface such as the AAL5 interface in the > > > AtomMib ? can I derive the physical ports on which it is used > > > through e.g. > > > the ifStackTable ? can a SNMP Manager create such an interface ?). > > > > Yes, that is certainly the intention. > > > > For LDP a manager can configure the tables under the "Entity" > > branch and this would result in LDP running on a specific physical > > port. In other technologies such as IP over ATM or NHRP, it is > > also necessary to consult the ifStack to understand which physical > > port the protocols are running over, we specifically tried > > to follow those other MIB models. > > > > -Joan > > > > > > Peter > > > > > > > > > > > > > > > > > > "Cucchiara, Joan" on 05/03/2000 > 04:35:29 PM > > > > > > > > > > > > To: Peter VAN ROMPU/BE/ALCATEL@ALCATEL, mpls@UU.NET > > > > > > cc: > > > > > > > > > > > > Subject: RE: questions on > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: peter.van_rompu@alcatel.be > > [mailto:peter.van_rompu@alcatel.be] > > > > Sent: Wednesday, May 03, 2000 6:23 AM > > > > To: mpls@UU.NET > > > > Subject: questions on > > > > > > > > > > > > > > > > > > Hello Peter, > > > > > > > > > > > Hello, > > > > > > > > Can somebody help me this the following questions on the use > > > > of the LDP MIB. > > > > > > > > 1) mplsLdpEntityTable > > > > > > > > How can a SNMP Manager derive on which interfaces a LDP > > > entity runs ? > > > > > > > > For LDP entities with mplsLdpEntityOptionalParameters set to > > > > atmParameters(2) or frameRelayParameters(3), my understanding > > > > is that the SNMP manager can derive this from the ifIndex > > > > found in the associated entry in the mplsLdpAtmParmsTable or > > > > mplsLdpFrameRelayParmsTable. Once the SNMP Manager knowns > > > > the ifIndex , the SNMP Manager can use the ifStackTable to > > > > figure out on which ATM/FR port this entity runs (am I > > correct ?) . > > > > > > yes. > > > > > > > > > > > But how to do this for a LDP entity using generic labels ? > > > > > > This is the same. There is an ifIndex associated with a > > > generic label also. This ifIndex would have the ifType of > > > mpls (166). So in effect this would be the mpls interface layer. > > > > > > > > > > > 2) mplsLdpEntityConfGenericTable > > > > > > > > I'm confused by the DESCRIPTION field of the > > > > mplsLdpEntityConfGenericTable definition : why does a SNMP > > > > Manager need to configure a generic label for LDP ? I thought > > > > it was sufficient for LDP to known the label pools in order > > > > to distribute labels ? > > > > > > Yes this is correct for ATM and Frame Relay, but for Generic > > > Labels there is no mechanism in LDP to distribute a > > > label pool (i.e. label range) for generic labels. > > > (The last sentence of Section 3.5.3 of the LDP > > > spec states: "Note that there is > > > no Generic Session Parameters TLV for sessions which > > > advertise Generic Labels.") > > > > > > > > > > > > > > 2) creation of a MPLS interface and activation of LDP on it. > > > > > > > > How can a SNMP manager create a MPLS interface using the > > > > available MIBs and associate a LDP entity to that newly > > > > created MPLS interface ? > > > > > > > > My understanding is that if the SNMP Manager wants LDP to use > > > > ATM or FrameRelay labels on the MPLS interface, the SNMP > > > > Manager needs to create an entry in the mplsLdpEntityTable, > > > > an entry in the mplsLdpEntityAtmParmsTable (which allows to > > > > configure for > > > > instance the VPI/VCI to be used by LDP) and one or more > > > > entries in the mplsLdpEntityConfAtmLabelRangeTable. As a > > > > result of these row creations, the SNMP agent might create a > > > > new MPLS interface, associate an ifIndex to it and fill the > > > > ifIndex for the newly > > > > created MPLS interface into the mplsLdpEntityTable. (Is this > > > > correct ?) > > > > > > Essentially, yes you are correct. Although how this would > > > take place exactly, would largely depend on when ifIndices are > > > created (which is why the LDP MIB uses InterfaceIndexOrZero > > > and why this is not needed for indexing into these Entity > > > related tables.) > > > > > > In other words, an Entity is created at some point in time. > > > At some other point in time, LSPs are established. The > > > LSPs are between MPLS interfaces. It is upto the implementation > > > on when the ifIndices are assigned, but the LDP MIB does stipulate > > > that once LSP are established these InterfaceIndexOrZero objects > > > need to have the value of the InterfaceIndex. > > > > > > > > > > > > > > But how can a SNMP manager create a new MPLS interface (for > > > > instance on ATM) using generic labels ? In this case the LDP > > > > entity might allready be configured - the only thing I would > > > > exspect to do is to configure somehow a VPI/VCI to be used > > > by this LDP > > > > entity. > > > > > > I don't think this is correct. If it is an ATM interface then > > > ATM labels (vpi,vci) would be used, so generic labels would not > > > be used for this. > > > > > > You could have an incoming labelled packet which is from > > > an ATM interface, forwarded out a PPP interface in which > > > case you would forward using a generic label (for details > > > see the draft-ietf-mpls-label-encaps-07.txt). In that > > > case though, this would be two different labels. > > > > > > -Joan > > > > > > > > > > > Best regards, > > > > > > > > Peter Van Rompu - Alcatel Telecom > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Mon May 8 23:39:02 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 XAA28837 for ; Mon, 8 May 2000 23:39:02 -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 QQiojm02928; Tue, 9 May 2000 03:38:59 GMT Received: by mail-control.mail.uu.net id QQiojm09255 for mpls-outgoing; Tue, 9 May 2000 03:38:27 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiojm09250 for ; Tue, 9 May 2000 03:38:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiojm20784 for ; Mon, 8 May 2000 23:38:22 -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 QQiojm02375 for ; Tue, 9 May 2000 03:38:19 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 09 May 2000 09:18:09 +0530 Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id IAA18877; Tue, 9 May 2000 08:56:33 +0530 Received: by localhost with Microsoft MAPI; Tue, 9 May 2000 09:03:28 +0530 Message-Id: <01BFB995.70A9B8E0.manis@future.futsoft.com> From: manikantan To: "'Cucchiara, Joan'" , "'arun@force10networks.com'" , "'csrinivasan@tachion.com'" , "'tnadeau@cisco.com'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB last call comments Date: Tue, 9 May 2000 09:03:26 +0530 Importance: high X-Priority: 1 (Highest) 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 Hello I have a doubt. This is regarding the Type value that is to be assigned to the ifType in the ifTable (RFC 2233) The following reference is from draft-ietf-mpls-te-mib-03.txt mplsTunnelEntry OBJECT-TYPE SYNTAX MplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents an MPLS tunnel. An entry can be created by a network administrator or by an SNMP agent as instructed by an MPLS signaling protocol. Whenever a new entry is created with mplsTunnelIsIf set to true(1), then a corresponding entry is created in ifTable as well (see RFC 2233). The ifType of this entry is mplsTunnel(150)." REFERENCE "1. RFC 2233 - The Interfaces Group MIB using SMIv2, McCloghrie, K., and F. Kastenholtz, Nov. 1997 2. RFC 1700 - Assigned Numbers, Reynolds, J. and J. Postel, Oct. 1994" INDEX { mplsTunnelIndex, mplsTunnelInstance } ::= { mplsTunnelTable 1 } From this I understand if the IfType is mplsTunnel, the number to be assigned is 150. The following reference is from draft-ietf-mpls-lsr-mib-04.txt When using MPLS interfaces, the interface stack table might appear as follows: +----------------------------------------+ | MPLS-interface ifType = mpls(166) + +----------------------------------------+ | Underlying Layer... + +----------------------------------------+ In the above diagram, "Underlying Layer..." refers to the ifIndex of any interface type, which has been defined for MPLS interworking. Examples include ATM, Frame Relay, Ethernet, etc. .... ifType The value that is allocated for MPLS is 166. From this I understand if the IfType is mpls, the number to be assigned is 166. My doubt is the interface type being "mpls" and "mplsTunnel" different? if so can this be explained. If these are same then the values in the two MIBs are to be synced. thanks in advance with best regards mani From owner-mpls@UU.NET Tue May 9 00:10: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 AAA29276 for ; Tue, 9 May 2000 00:10: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 QQiojo20223; Tue, 9 May 2000 04:10:14 GMT Received: by mail-control.mail.uu.net id QQiojo18754 for mpls-outgoing; Tue, 9 May 2000 04:09:50 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 QQiojo18749 for ; Tue, 9 May 2000 04:09:38 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 QQiojo26056 for ; Tue, 9 May 2000 00:09:33 -0400 (EDT) Received: from hd2.dot.net.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hd2.vsnl.net.in [202.54.30.2]) id QQiojo03572 for ; Tue, 9 May 2000 04:09:02 GMT Received: from hyd.chiplogic.com ([203.197.20.22]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id JAA31107; Tue, 9 May 2000 09:36:34 +0530 (IST) Received: from chiplogic.com ([192.168.2.59]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id JAA13032; Tue, 9 May 2000 09:27:53 +0530 Message-ID: <39179076.FE4BD8B8@chiplogic.com> Date: Tue, 09 May 2000 09:43:42 +0530 From: ksreeni X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari , mpls Subject: Re: ILM mappings References: <336ECDAFDF7DD311B9E30090277AEE4101B4053A@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 Hi Sharam, The first scenario you mentioned is diffserv supported LSP. In the constraint based routing an LSR can maintain more than one LSP ( more than one NHLFE ) for backup path . This is also one more case we can consider. Sreeni. Shahram Davari wrote: > Hi Eric, > > There are two scenarios that a single label may correspond to multiple > NHLFEs: > > 1) Some part of an LSP is E-LSP and another part is L-LSP > 2) In case of Multicast. > > Regards, > Shahram Davari > Product Research > PMC-Sierra Inc. > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > -----Original Message----- > From: Eric Gray [mailto:EGray@zaffire.com] > Sent: Monday, May 08, 2000 12:51 PM > To: 'Trilok Chand' > Cc: mpls@UU.NET > Subject: RE: ILM mappings > > TrilokChand, > > An interesting question. How did there get to be multiple > NHLFEs for a single incoming label? Suspending disbelief > on this for a moment, however, and supposing there was a > reason for this to happen - the implementer must have had > some plan for demultiplexing the single label to determine > which NHLFE would be used. One way might be to pop the > label and look at what comes after it - but a pop instruction > should be a single NHLFE (with - in this case - a next hop > of "self"). Is there a useful application for this scenario? > > It seems to me that there would not be multiple NHLFE > entries for a single label as this will defeat the purpose for > having a label. But, even if there was a reason to do this, > the implementation that causes this to happen is the same > implementation that has to deal with the outcome. > > If you shoot yourself in the foot, it will hurt. :-) > > -- > Eric Gray > > -----Original Message----- > From: Trilok Chand [mailto:trilok@chiplogic.com] > Sent: Monday, May 08, 2000 3:25 AM > To: mpls@UU.NET > Subject: ILM mappings > > Hi, > Can anybody tell where can i get information about choosing an ILM > mapping when there are multiple NHLFEs existing for an incoming label? > > Thanks in advance, > TrilokChand > From owner-mpls@UU.NET Tue May 9 01:06: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 ESMTP id BAA00046 for ; Tue, 9 May 2000 01:06: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 QQiojs04852; Tue, 9 May 2000 05:05:34 GMT Received: by mail-control.mail.uu.net id QQiojs29438 for mpls-outgoing; Tue, 9 May 2000 05:04:57 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 QQiojs29433 for ; Tue, 9 May 2000 05:04:49 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 QQiojs26065 for ; Tue, 9 May 2000 01:04:39 -0400 (EDT) Received: from smtp6.mindspring.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQiojs20721 for ; Tue, 9 May 2000 05:04:38 GMT Received: from mindspring.com (user-33qtgds.dialup.mindspring.com [199.174.193.188]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id BAA05502; Tue, 9 May 2000 01:04:30 -0400 (EDT) Message-ID: <39179D21.498A3044@mindspring.com> Date: Mon, 08 May 2000 22:07:45 -0700 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ksreeni CC: Shahram Davari , mpls Subject: Re: ILM mappings References: <336ECDAFDF7DD311B9E30090277AEE4101B4053A@nt-exchange-bby.pmc-sierra.bc.ca> <39179076.FE4BD8B8@chiplogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sreeni, To save someone else the trouble of pointing it out, the architecture draft specifically mentions load balancing as an application for more than one NHLFE. You could stretch a point and say that - when using liberal retention - you have a veritable horde of NHLFEs for each ILM. This assumes that you actually store an entire NHLFE for each redundant Label Mapping (rather than just the peer-label-FEC tuple) - but this is the same assumption made in the redundant path example you mentioned. So you have multicast, multipath, E-LSP DiffServ, redundancy and possibly other uses for having more than one NHLFE for any given ILM. The point is that you would need to ensure - within your implementation - that the LSR is able to determine what NHLFE is to be used for any ILM. The architecture draft punts on how this is to be done, but the only case I can come up with where the LSR may not be able to correctly determine which NHLFE to pick is the case where the implementation allows more than one NHLFE to be associated with a single ILM (for example, via configuration) with out requiring a context within which to interpret this association (e.g. - load balancing, multicast, redundancy, etc.). This is probably a mildly pathological case. Even in this case, you can simply document what the implementation will do (since it must chose exactly one NHLFE for every individual packet) and let the user figure out whether or not that is what they want to happen. Maybe the implementation always picks the first one configured, maybe it picks the one associated with the lowest interface ID or maybe it round robins all associated NHLFEs. In other cases mentioned so far, you won't get to the point where you have more than one NHLFE per ILM without being able to deal with it. So the question is an interesting one and it still comes down to "how did there get to be multiple NHLFEs for a single incoming label?" And the discussion comes full circle and I sit out the next few dances. -- Eric Gray ksreeni wrote: > Hi Sharam, > The first scenario you mentioned is diffserv supported LSP. In > the constraint based routing an LSR can maintain more than one LSP ( more than > one NHLFE ) for backup path . This is also one more case we can consider. > > Sreeni. > > Shahram Davari wrote: > > > Hi Eric, > > > > There are two scenarios that a single label may correspond to multiple > > NHLFEs: > > > > 1) Some part of an LSP is E-LSP and another part is L-LSP > > 2) In case of Multicast. > > > > Regards, > > Shahram Davari > > Product Research > > PMC-Sierra Inc. > > 555 Legget drive, > > Suit 834, Tower B, > > Ottawa, ON K2K 2X3, Canada > > Phone: +1 (613) 271-4018 > > Fax : +1 (613) 271-7007 > > > > > > -----Original Message----- > > From: Eric Gray [mailto:EGray@zaffire.com] > > Sent: Monday, May 08, 2000 12:51 PM > > To: 'Trilok Chand' > > Cc: mpls@UU.NET > > Subject: RE: ILM mappings > > > > TrilokChand, > > > > An interesting question. How did there get to be multiple > > NHLFEs for a single incoming label? Suspending disbelief > > on this for a moment, however, and supposing there was a > > reason for this to happen - the implementer must have had > > some plan for demultiplexing the single label to determine > > which NHLFE would be used. One way might be to pop the > > label and look at what comes after it - but a pop instruction > > should be a single NHLFE (with - in this case - a next hop > > of "self"). Is there a useful application for this scenario? > > > > It seems to me that there would not be multiple NHLFE > > entries for a single label as this will defeat the purpose for > > having a label. But, even if there was a reason to do this, > > the implementation that causes this to happen is the same > > implementation that has to deal with the outcome. > > > > If you shoot yourself in the foot, it will hurt. :-) > > > > -- > > Eric Gray > > > > -----Original Message----- > > From: Trilok Chand [mailto:trilok@chiplogic.com] > > Sent: Monday, May 08, 2000 3:25 AM > > To: mpls@UU.NET > > Subject: ILM mappings > > > > Hi, > > Can anybody tell where can i get information about choosing an ILM > > mapping when there are multiple NHLFEs existing for an incoming label? > > > > Thanks in advance, > > TrilokChand > > From owner-mpls@UU.NET Tue May 9 01:19: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 ESMTP id BAA01722 for ; Tue, 9 May 2000 01:19: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 QQiojt29372; Tue, 9 May 2000 05:19:50 GMT Received: by mail-control.mail.uu.net id QQiojt00473 for mpls-outgoing; Tue, 9 May 2000 05:19:37 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiojt00464 for ; Tue, 9 May 2000 05:19:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiojt28895 for ; Tue, 9 May 2000 01:19:22 -0400 (EDT) Received: from hd2.dot.net.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hd2.vsnl.net.in [202.54.30.2]) id QQiojt28866 for ; Tue, 9 May 2000 05:19:21 GMT Received: from hyd.chiplogic.com ([203.197.20.22]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id KAA16960 for ; Tue, 9 May 2000 10:46:07 +0530 (IST) Received: from chiplogic.com ([192.168.2.59]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id KAA13751 for ; Tue, 9 May 2000 10:03:45 +0530 Message-ID: <391798DE.894A24A9@chiplogic.com> Date: Tue, 09 May 2000 10:19:34 +0530 From: ksreeni X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls Subject: basic questions 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 some basic questions on the deployment of MPLS in LAN and QOS . Can somebody resolve the following questions? There is one router at customer place having 3 hosts in the subnet and it is connected to ISP through WAN link. And ISP is an LER in the MPLS domain. (1) Do I need to deploy MPLS on my router? If yes, what are the benifits? (2) As per my knowledge , I am not finding any necessity of MPLS & LDP on end Host. Is that correct? (3) If ISP provides QOS based on the COS field in the SHIM header and the customer subscribed some BW at ISP. Then , Is that possible for ISP to policy the customer traffic at MPLS layer itself? Thanks, Sreeni. From owner-mpls@UU.NET Tue May 9 04:31: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 ESMTP id EAA12761 for ; Tue, 9 May 2000 04: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 QQiokg27710; Tue, 9 May 2000 08:30:29 GMT Received: by mail-control.mail.uu.net id QQiokg03713 for mpls-outgoing; Tue, 9 May 2000 08:30: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 QQiokf03685 for ; Tue, 9 May 2000 08:29: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 QQiokf19046 for ; Tue, 9 May 2000 04:29:50 -0400 (EDT) Received: from relay1.alcatel.be by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQiokf15066 for ; Tue, 9 May 2000 08:29:49 GMT Received: from btmp80.sebb.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e498Td911040; Tue, 9 May 2000 10:29:39 +0200 (MET DST) Received: from sebb.bel.alcatel.be (ktpc939 [138.203.171.174]) by btmp80.sebb.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id KAA04607; Tue, 9 May 2000 10:29:06 +0200 (MET DST) Message-ID: <3917E851.4494AEF2@sebb.bel.alcatel.be> Date: Tue, 09 May 2000 12:28:33 +0200 From: Tony Van Kerckhove Reply-To: Tony.Van_Kerckhove@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: manikantan CC: "'mpls@uu.net'" Subject: Re: LSR MIB last call comments References: <01BFB995.70A9B8E0.manis@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 Hello, Manikantan, The way I understood it, is: - the ifType 166 is associated with an MPLS layer (something that can transmit/receive MPLS-encapsulated packets and can be associated with a label distribution protocol) - the ifType 150 is associated with a single LSP Hence, an mpls interface (166) can be the underlying layer for multiple mplsTunnels (150). Regards, Tony Van Kerckhove Alcatel manikantan wrote: > > Hello > > I have a doubt. > > This is regarding the Type value that is to be assigned to the > ifType in the ifTable (RFC 2233) > > The following reference is from draft-ietf-mpls-te-mib-03.txt > > mplsTunnelEntry OBJECT-TYPE > SYNTAX MplsTunnelEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents an MPLS > tunnel. An entry can be created by a network > administrator or by an SNMP agent as instructed > by an MPLS signaling protocol. Whenever a new > entry is created with mplsTunnelIsIf set to > true(1), then a corresponding entry is created > in ifTable as well (see RFC 2233). The ifType of > this entry is mplsTunnel(150)." > REFERENCE > "1. RFC 2233 - The Interfaces Group MIB using > SMIv2, McCloghrie, K., and F. Kastenholtz, Nov. > 1997 > 2. RFC 1700 - Assigned Numbers, Reynolds, J. and > J. Postel, Oct. 1994" > INDEX { mplsTunnelIndex, mplsTunnelInstance } > ::= { mplsTunnelTable 1 } > > >From this I understand if the IfType is mplsTunnel, the number to > be assigned is 150. > > The following reference is from draft-ietf-mpls-lsr-mib-04.txt > > When using MPLS interfaces, the interface stack table might appear > as follows: > > +----------------------------------------+ > | MPLS-interface ifType = mpls(166) + > +----------------------------------------+ > | Underlying Layer... + > +----------------------------------------+ > > In the above diagram, "Underlying Layer..." refers to the ifIndex > of any interface type, which has been defined for MPLS > interworking. Examples include ATM, Frame Relay, Ethernet, etc. > > .... > > ifType The value that is allocated for MPLS is 166. > > >From this I understand if the IfType is mpls, the number to > be assigned is 166. > > My doubt is the interface type being "mpls" and "mplsTunnel" different? > if so can this be explained. > > If these are same then the values in the two MIBs are to be synced. > > thanks in advance > with best regards > mani From owner-mpls@UU.NET Tue May 9 04:55: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 EAA12938 for ; Tue, 9 May 2000 04:55: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 QQiokh28393; Tue, 9 May 2000 08:55:35 GMT Received: by mail-control.mail.uu.net id QQiokh04837 for mpls-outgoing; Tue, 9 May 2000 08:55:07 GMT Received: from neserve0.corp.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQiokh04829 for ; Tue, 9 May 2000 08:55:04 GMT Received: by neserve0.corp.us.uu.net id QQiokh15837; Tue, 9 May 2000 04:54:59 -0400 (EDT) Date: Tue, 9 May 2000 04:54:59 -0400 From: Daniel Awduche To: Florian-Daniel Otel Cc: Philip Matthews , mpls@UU.NET, te-wg@UU.NET, Daniel Awduche Subject: Re: TEWG framework updates / MPLS-TE drafts Message-ID: <20000509045459.A1708@uu.net> References: <14612.42804.714266.260861@rasputin.ce.chalmers.se> <3916A947.DCD48F5@americasm01.nt.com> <14614.44626.241758.665317@rasputin.ce.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <14614.44626.241758.665317@rasputin.ce.chalmers.se>; from otel@ce.chalmers.se on Mon, May 08, 2000 at 02:20:50PM +0200 Sender: owner-mpls@UU.NET Precedence: bulk Regarding draft-li-mpls-igp-te-00.txt, this work was presented at the MPLS WG meeting in March, 1999 (44th IETF, Minneapolis, MN). At that time, the TEWG did not exist, however discussions/negotiations to establish it were already in progress. The consensus at the MPLS WG meeting was that draft-li-mpls-igp-te-00.txt rightly belongs to the TEWG, when the new WG becomes operational. Essentially, draft-li-mpls-igp-te-00.txt ("IGP Requirements for Traffic Engineering with MPLS") describes the 'functional requirements' for a conventional IGP to support Traffic Engineering. Two complementary drafts detail the protocol extensions needed to address these functional requirements. These are (1) D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF" and (2) H. Smit and T. Li, "IS-IS extensions for Traffic Engineering." Implementations based on these specifications are currently shipping are being deployed, even though the supporting documents are still in draft form. Back to the question, draft-li-mpls-igp-te-00.txt has expired and the -01- version does not exist, but we can certainly update and re-issue it if there's sufficient WG interest. Cheers, /Dan On Mon, May 08, 2000 at 02:20:50PM +0200, Florian-Daniel Otel wrote: > > > A good site to check for internet-drafts related to MPLS is > > http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ > > This site archives drafts going back the the beginings > > of the MPLS WG, as well as related drafts. > > > Both of the drafts you are looking for are available there. > > > Found the site in the mean time (that draft is also on Dan Awduche web > site too) but thanks a lot. Also i was implictly asking about the updated > version (i.e. draft-li-mpls-igp-te-01.txt). > > Anyway, that was not the main intention (and i appologize for not > making it clear from the first posting): What I was primarily > intrested in was about the continuation of these drafts i.e. were they > dropped (if so why ? was there a discussion about this ? where ? > archives ?) , there was no interest in them, there is an update > planned, they advanced on IETF track, etc. ? > > Thanks, > > > - Philip > > Florian. From owner-mpls@UU.NET Tue May 9 07:59:12 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 HAA15991 for ; Tue, 9 May 2000 07:59:12 -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 QQiokt26451; Tue, 9 May 2000 11:58:05 GMT Received: by mail-control.mail.uu.net id QQiokt08836 for mpls-outgoing; Tue, 9 May 2000 11:57: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 QQiokt08829 for ; Tue, 9 May 2000 11:57: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 QQiokt06896 for ; Tue, 9 May 2000 07:57:01 -0400 (EDT) Received: from blsmsgims02.bls.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: iocfirewall2ext.bls.com [139.76.64.4]) id QQiokt25682 for ; Tue, 9 May 2000 11:57:01 GMT Received: from SMTP (blsmsgims02.bls.com [139.76.86.32]) by blsmsgims02.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KLHYZ6V9; Tue, 9 May 2000 07:57:01 -0400 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 09 May 2000 11:57:01 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 HAA02878; Tue, 9 May 2000 07:56:48 -0400 (EDT) From: "Steven Wright" To: Cc: "Thomas D. Nadeau (E-mail)" Date: Tue, 9 May 2000 07:54:51 -0400 Message-ID: <000c01bfb9ad$62d06ad0$46d61e5a@gf5142_gxsmlg.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 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tom, Firstly, thankyou for pulling this together. I had been scrambling through the other published MPLS mibs trying to find where the FEC controls were. My main interest is in the policies related to MPLS and eventually an MPLS PIB, but such a PIB obviously depends on the underlying capabilities of MIBs such as this. A couple of questions though... 1. You mention in the motivation section (4) that there are other classification processes ( diffserv comes to mind ). Are there existing MIBs (e.g. Diffserv) that this document should be compared against? or is this intended to be a common document for a variety of technologies ? 2. The packet header tuple used for classification here seems to be missing a few items that might be useful e.g classifications based on: -packet size ( for some QoS applications ) -ToS Bits / DSCP ( for MPLS /Diffserv interoperation ) 3. There are some other bases for classification that are not based on the packet header, but on other information that may be available in the router - e.g. the source interface, MTU size, traffic marking/measurement/policing metrics etc. 4. I'd like some more background on the options available under mplsMplsPacketClassifierActionMask. I'm not sure of the difference between redirect(2) and redirectLsp (3). If you use the settos(4) option, don't you need some other parameter to identify which tos codepoint to use ? I'm also not sure where this list of actions came from - Is it intended to be complete, or just a starting point ?. regards Steven Wright -----Original Message----- From: Thomas D. Nadeau [] Sent: Thursday, May 04, 2000 10:41 AM To: Steven Wright Subject: Re: status of MPLS packet classifier mib Hi Steve, The MIB was not presented due to a packed schedule. The MIB was actually never submitted as a draft because it was submitted late. We will be republishing it soon. You can find it at ftp-eng.cisco.com/tnadeau in the meantime. Please send me your comments. --Tom What is the status of the MPLS packet classifier MIB - draft-nadeau-mpls-packet-classifier-mib-00.txt ? was this presented in Adelaide ? Is there now a WG document version ( draft-ietf-....) regards Steven Wright, Ph.D. Network Architecture Science and Technology BellSouth Telecommunications phone (404) 332-2194 fax (404) 529-8025 From owner-mpls@UU.NET Tue May 9 08:34: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 ESMTP id IAA17146 for ; Tue, 9 May 2000 08:34: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 QQiokw19595; Tue, 9 May 2000 12:34:02 GMT Received: by mail-control.mail.uu.net id QQiokw19395 for mpls-outgoing; Tue, 9 May 2000 12:33:41 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiokw19386 for ; Tue, 9 May 2000 12:33:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiokw04699 for ; Tue, 9 May 2000 08:33:32 -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 QQiokw19145 for ; Tue, 9 May 2000 12:33:31 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 9 May 2000 13:33:26 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E140917@monk.datcon.co.uk> From: Adrian Farrel To: Arun Viswanathan , "'mpls@UU.NET'" Subject: RE: Second WG last call on LSR MIB Date: Tue, 9 May 2000 13:33:24 +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 Arun, >2. Removing mplsInterfaceInPackets, mplsInterfaceInDiscards, > mplsInterfaceOutPackets, and mplsInterfaceOutDiscards from > the MplsInterfacePerfEntry. You didn't say why you think these should go. Is it because these are really interface statistics that should be collected by elsewhere (e.g. ifInUcastPkts etc.)? 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 Tue May 9 08:54: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 IAA17731 for ; Tue, 9 May 2000 08:54: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 QQiokx16057; Tue, 9 May 2000 12:53:57 GMT Received: by mail-control.mail.uu.net id QQiokx20883 for mpls-outgoing; Tue, 9 May 2000 12:53:20 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiokx20874 for ; Tue, 9 May 2000 12:53:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiokx06836 for ; Tue, 9 May 2000 08:52:45 -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 QQiokx15312 for ; Tue, 9 May 2000 12:52:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA28155 for mpls@uu.net; Tue, 9 May 2000 08:52:44 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiokx20854 for ; Tue, 9 May 2000 12:52:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiokx06762 for ; Tue, 9 May 2000 08:51:48 -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 QQiokx00829 for ; Tue, 9 May 2000 12:51:48 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA02111; Tue, 9 May 2000 08:51:36 -0400 (EDT) Message-Id: <4.2.2.20000509083405.03de17f0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 09 May 2000 08:49:33 -0400 To: Adrian Farrel , Arun Viswanathan , "'mpls@UU.NET'" From: "Thomas D. Nadeau" Subject: RE: Second WG last call on LSR MIB In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E140917@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_43053599==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_43053599==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed We wanted to remove these because these counters are covered by the interface (2233) statistics. Joan C. pointed this out in a previous email a little while ago. --Tom > >2. Removing mplsInterfaceInPackets, mplsInterfaceInDiscards, > > mplsInterfaceOutPackets, and mplsInterfaceOutDiscards from > > the MplsInterfacePerfEntry. > >You didn't say why you think these should go. Is it because these are >really interface statistics that should be collected by elsewhere (e.g. >ifInUcastPkts etc.)? > >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 --=====================_43053599==_.ALT Content-Type: text/html; charset="us-ascii"
        We wanted to remove these because these
counters are covered by the interface (2233)
statistics.  Joan C. pointed this out in a previous
email a little while ago.

        --Tom


>2. Removing mplsInterfaceInPackets, mplsInterfaceInDiscards,
>   mplsInterfaceOutPackets, and mplsInterfaceOutDiscards from
>   the MplsInterfacePerfEntry.

You didn't say why you think these should go.  Is it because these are
really interface statistics that should be collected by elsewhere (e.g.
ifInUcastPkts etc.)?

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
--=====================_43053599==_.ALT-- From owner-mpls@UU.NET Tue May 9 09:50: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 JAA19760 for ; Tue, 9 May 2000 09:50: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 QQiolb22798; Tue, 9 May 2000 13:49:37 GMT Received: by mail-control.mail.uu.net id QQiolb02633 for mpls-outgoing; Tue, 9 May 2000 13:49:15 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 QQiolb02628 for ; Tue, 9 May 2000 13:49: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 QQiolb09626 for ; Tue, 9 May 2000 09:49:09 -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 QQiolb09736 for ; Tue, 9 May 2000 13:49:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA04702 for mpls@uu.net; Tue, 9 May 2000 09:49:07 -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 QQiolb02601 for ; Tue, 9 May 2000 13:48: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 QQiolb22611; Tue, 9 May 2000 09:48:36 -0400 (EDT) Received: from blv-smtpout-01.boeing.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: blv-smtpout-01.boeing.com [192.161.36.5]) id QQiolb09249; Tue, 9 May 2000 13:48:35 GMT Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id GAA21745; Tue, 9 May 2000 06:48:34 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id GAA26252; Tue, 9 May 2000 06:48:25 -0700 (PDT) Received: from xch-phlbh-01.he.boeing.com by blv-hub-01.boeing.com with ESMTP; Tue, 9 May 2000 06:49:17 -0700 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 May 2000 09:48:08 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBB73@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Daniel Awduche'" Cc: mpls@UU.NET, te-wg@UU.NET Subject: RE: TEWG framework updates / MPLS-TE drafts Date: Tue, 9 May 2000 09:48:01 -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: Daniel Awduche [mailto:awduche@UU.NET] > > Regarding draft-li-mpls-igp-te-00.txt, this work was presented > at the MPLS WG meeting in March, 1999 (44th IETF, Minneapolis, MN). [ ... ] > Essentially, draft-li-mpls-igp-te-00.txt ("IGP Requirements for > Traffic Engineering with MPLS") describes the 'functional > requirements' for a conventional IGP to support Traffic > Engineering. Two complementary drafts detail the protocol extensions > needed to address these functional requirements. These are (1) > D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF" > and (2) H. Smit and T. Li, "IS-IS extensions for Traffic > Engineering." > > Implementations based on these specifications are currently shipping > are being deployed, even though the supporting documents are still in > draft form. > > Back to the question, draft-li-mpls-igp-te-00.txt has expired > and the -01- version does not exist, but we can certainly update > and re-issue it if there's sufficient WG interest. I'm not sure how this would be handled. If implementations are shipping now, does the IETF view these implementations to be (or soon to be) an Internet standard, or are they viewed as proprietary solutions? If the former, then wouldn't the drafts naturally proceed on a standards track? Is this situation similar to the PIM-SM version 1 vs version 2 sort of thing, where version 2 is the standard and version 1 is largely proprietary? Thanks. Bert albert.e.manfredi@boeing.com From owner-mpls@UU.NET Tue May 9 11:47: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 LAA22987 for ; Tue, 9 May 2000 11:47: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 QQiolj19906; Tue, 9 May 2000 15:46:06 GMT Received: by mail-control.mail.uu.net id QQiolj26100 for mpls-outgoing; Tue, 9 May 2000 15:45:15 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 QQiolj26041 for ; Tue, 9 May 2000 15:45: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 QQioli26649 for ; Tue, 9 May 2000 11:44:50 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQioli18940 for ; Tue, 9 May 2000 15:44:49 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e49FWnS23262 for ; Tue, 9 May 2000 17:32:49 +0200 (MET DST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e49Fc3p22736 for ; Tue, 9 May 2000 17:38:04 +0200 (MET DST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FUA00M01U3F52@mbb1.ericsson.se> for mpls@uu.net; Tue, 9 May 2000 17:38:03 +0200 (MET DST) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FUA00KAHU3FTF@mbb1.ericsson.se> for mpls@uu.net; Tue, 09 May 2000 17:38:03 +0200 (MET DST) Date: Tue, 09 May 2000 17:37:12 +0200 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: owner object in LSR MIB To: mpls@UU.NET Message-id: <391830A8.389F6E42@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This has been discussed to some degree off line previously but is now part of the LSR last call comments so I post it on the list. LSR MIB authers, sorry to reiterate a little. The LDP mib has been updated to use the LIB tables in the LSR MIB to meet the last call comments. In order to fully align the LDP and LSR MIBs in a good way we would like you to consider the following proposal. To transform the owner object in the inSegment/outSegment/XC tables into something more loosly defined e.g just a OCTET STRING. THe object description could be something like (just off my head, it should be frased better) DESCRIPTION "Denotes the name of the entity that created and is responsible for managing this segment. This object could be provisioned by the manager or it could be generated by the agent." This will take care of some shortcomings of the LSR LIB and also address some last call concerns on the objects. - It gives LDP the chance to tie the session to the LSP. I.e in the LDP MIB we will qualify the use of the owner attribute to identify the session responsible for managing it. - It takes away the slightly bad practice to have an enumerated value which qickly is outdated, e.g GSMP which are being defined for the purpuse of establishing LSPs. - Other advantages could be build in the change. This requires minimal change in the LSR MIB (only a small syntactic change, no new object or anything. This takes care of one of our main obstacles in just using the LSR MIB LIB, being what session to tie an LSPs to. This is important for a number of reasonsto LDP. Regards /// Hasse From owner-mpls@UU.NET Tue May 9 11:58: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 LAA23346 for ; Tue, 9 May 2000 11:58: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 QQiolj11607; Tue, 9 May 2000 15:56:04 GMT Received: by mail-control.mail.uu.net id QQiolj26680 for mpls-outgoing; Tue, 9 May 2000 15:55:34 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiolj26671 for ; Tue, 9 May 2000 15:55:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiolj03119; Tue, 9 May 2000 11:54:39 -0400 (EDT) Received: from mta6.snfc21.pbi.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mta6.snfc21.pbi.net [206.13.28.240]) id QQiolj26046; Tue, 9 May 2000 15:54:39 GMT Received: from siara.com ([63.200.50.18]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FUA001E3U8N49@mta6.snfc21.pbi.net>; Tue, 9 May 2000 08:41:16 -0700 (PDT) Date: Tue, 09 May 2000 09:35:12 -0700 From: Tony Przygienda Subject: Re: TEWG framework updates / MPLS-TE drafts To: "Manfredi, Albert E" Cc: "'Daniel Awduche'" , mpls@UU.NET, te-wg@UU.NET Reply-to: prz@siara.com Message-id: <39183E40.863DEFD8@siara.com> Organization: Siara Systems MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <4102273CEB77D211869200805FE6F5939EBB73@xch-phl-01.he.boeing.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Manfredi, Albert E" wrote: > > -----Original Message----- > > From: Daniel Awduche [mailto:awduche@UU.NET] > > > > Regarding draft-li-mpls-igp-te-00.txt, this work was presented > > at the MPLS WG meeting in March, 1999 (44th IETF, Minneapolis, MN). > > [ ... ] > > > Essentially, draft-li-mpls-igp-te-00.txt ("IGP Requirements for > > Traffic Engineering with MPLS") describes the 'functional > > requirements' for a conventional IGP to support Traffic > > Engineering. Two complementary drafts detail the protocol extensions > > needed to address these functional requirements. These are (1) > > D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF" > > and (2) H. Smit and T. Li, "IS-IS extensions for Traffic > > Engineering." > > > > Implementations based on these specifications are currently shipping > > are being deployed, even though the supporting documents are still in > > draft form. > > > > Back to the question, draft-li-mpls-igp-te-00.txt has expired > > and the -01- version does not exist, but we can certainly update > > and re-issue it if there's sufficient WG interest. > > I'm not sure how this would be handled. If implementations are shipping now, > does the IETF view these implementations to be (or soon to be) an Internet > standard, or are they viewed as proprietary solutions? If the former, then > wouldn't the drafts naturally proceed on a standards track? > > Is this situation similar to the PIM-SM version 1 vs version 2 sort of > thing, where version 2 is the standard and version 1 is largely proprietary? > > Thanks. > > Bert > albert.e.manfredi@boeing.com John can comment on the OSPF side but for ISIS the intention is to make things informational (Henk is in process of submitting new version of the ISIS TE extensions and it's supposed to go into last call then). That's in the spirit of OSPF being the IGP-PS but ISIS needing maintainance for the selective group (however growing ;-) of large ISPs deploying ISIS. Informational is good enough for the small group of people building the implementations to make things interoperable. In this sense it's not proprietary but the discussion whether it's informational, experimental or any standard track from ISIS WG point of view would be just hair-splitting. -- tony From owner-mpls@UU.NET Tue May 9 12:09: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 ESMTP id MAA23610 for ; Tue, 9 May 2000 12:09: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 QQiolk20497; Tue, 9 May 2000 16:07:09 GMT Received: by mail-control.mail.uu.net id QQiolk05217 for mpls-outgoing; Tue, 9 May 2000 16:06:23 GMT Received: from neserve0.corp.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQiolk05198 for ; Tue, 9 May 2000 16:06:15 GMT Received: by neserve0.corp.us.uu.net id QQiolk08237; Tue, 9 May 2000 12:06:08 -0400 (EDT) Date: Tue, 9 May 2000 12:06:08 -0400 From: Daniel Awduche To: "Manfredi, Albert E" Cc: mpls@UU.NET, te-wg@UU.NET, Daniel Awduche Subject: Re: TEWG framework updates / MPLS-TE drafts Message-ID: <20000509120608.A6535@uu.net> References: <4102273CEB77D211869200805FE6F5939EBB73@xch-phl-01.he.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4102273CEB77D211869200805FE6F5939EBB73@xch-phl-01.he.boeing.com>; from Albert.Manfredi@PHL.Boeing.com on Tue, May 09, 2000 at 09:48:01AM -0400 Sender: owner-mpls@UU.NET Precedence: bulk Bert, Thanks for the comments. The referenced documents are Internet drafts. They are not standards at all. The process for developing and adopting Internet standards is described in RFC-2026 (Bradner, "The Internet Standards Process -- Revision 3"). Do you see a need to depart from that methodology? The following paragraph from RFC-2026 is, however, pertinent: "In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet." Thus, specifications that enjoy interoperable implementations from multiple sources and have demonstrated utility in operational contexts (e.g., the referenced documents) should clearly stand a better chance of progressing through the standards process than those that do not exhibit such attributes. One of the issues then would be to determine the appropriate categories for such specifications (ie, informational, experimental, BCP, standards track, etc) Cheers, /Dan On Tue, May 09, 2000 at 09:48:01AM -0400, Manfredi, Albert E wrote: > > -----Original Message----- > > From: Daniel Awduche [mailto:awduche@UU.NET] > > > > Regarding draft-li-mpls-igp-te-00.txt, this work was presented > > at the MPLS WG meeting in March, 1999 (44th IETF, Minneapolis, MN). > > [ ... ] > > > > > Implementations based on these specifications are currently shipping > > are being deployed, even though the supporting documents are still in > > draft form. > > > > Back to the question, draft-li-mpls-igp-te-00.txt has expired > > and the -01- version does not exist, but we can certainly update > > and re-issue it if there's sufficient WG interest. > > I'm not sure how this would be handled. If implementations are shipping now, > does the IETF view these implementations to be (or soon to be) an Internet > standard, or are they viewed as proprietary solutions? If the former, then > wouldn't the drafts naturally proceed on a standards track? > > Is this situation similar to the PIM-SM version 1 vs version 2 sort of > thing, where version 2 is the standard and version 1 is largely proprietary? > > Thanks. > > Bert > albert.e.manfredi@boeing.com From owner-mpls@UU.NET Tue May 9 12:14: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 MAA23725 for ; Tue, 9 May 2000 12:14: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 QQiolk24310; Tue, 9 May 2000 16:11:45 GMT Received: by mail-control.mail.uu.net id QQiolk05754 for mpls-outgoing; Tue, 9 May 2000 16:11: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 QQiolk05712 for ; Tue, 9 May 2000 16:11: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 QQiolk16169 for ; Tue, 9 May 2000 12:09:57 -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 QQiolk22737 for ; Tue, 9 May 2000 16:09:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA27030 for mpls@uu.net; Tue, 9 May 2000 12:09:55 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiolk05517 for ; Tue, 9 May 2000 16:09:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiolk05168 for ; Tue, 9 May 2000 12:08:18 -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 QQiolk06093 for ; Tue, 9 May 2000 16:08:18 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23530; Tue, 9 May 2000 12:08:08 -0400 (EDT) Message-Id: <4.2.2.20000509120435.03e83470@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 09 May 2000 12:05:30 -0400 To: Hans =?iso-8859-1?Q?Sj=F6strand?= , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: owner object in LSR MIB Cc: arun@force10networks.com, cheenu Srinivasan In-Reply-To: <391830A8.389F6E42@etx.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_54811889==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_54811889==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hans, Can you please ready our comments from yesterday and see if they resolve your problems? The thread you are posting here is post our reply from yesterday. --Tom >This has been discussed to some degree off line previously but is now >part of the LSR last call comments so I post it on the list. LSR MIB >authers, sorry to reiterate a little. > >The LDP mib has been updated to use the LIB tables in the LSR MIB to >meet the last call comments. In order to fully align the LDP and LSR >MIBs in a good way we would like you to consider the following proposal. > >To transform the owner object in the inSegment/outSegment/XC tables >into something more loosly defined e.g just a OCTET STRING. THe object >description could be something like (just off my head, it should be >frased better) > > DESCRIPTION > "Denotes the name of the entity that created and is responsible > for managing this segment. This object could be provisioned > by the manager or it could be generated by the agent." > >This will take care of some shortcomings of the LSR LIB and also >address some last call concerns on the objects. > >- It gives LDP the chance to tie the session to the LSP. >I.e in the LDP MIB we will qualify the use of the owner attribute to >identify the session responsible for managing it. >- It takes away the slightly bad practice to have an enumerated value >which qickly is outdated, e.g GSMP which are being defined for the >purpuse of establishing LSPs. >- Other advantages could be build in the change. > >This requires minimal change in the LSR MIB (only a small syntactic >change, no new object or anything. This takes care of one of our >main obstacles in just using the LSR MIB LIB, being what session >to tie an LSPs to. This is important for a number of reasonsto LDP. > >Regards >/// Hasse --=====================_54811889==_.ALT Content-Type: text/html; charset="us-ascii"

        Hans,

        Can you please ready our comments from
yesterday and see if they resolve your problems?
The thread you are posting here is post our
reply from yesterday.

        --Tom




This has been discussed to some degree off line previously but is now
part of the LSR last call comments so I post it on the list. LSR MIB
authers, sorry to reiterate a little.

The LDP mib has been updated to use the LIB tables in the LSR MIB to
meet the last call comments. In order to fully align the LDP and LSR
MIBs in a good way we would like you to consider the following proposal.

To transform the owner object in the inSegment/outSegment/XC tables
into something more loosly defined e.g just a OCTET STRING. THe object
description could be something like (just off my head, it should be
frased better)

   DESCRIPTION
       "Denotes the name of the entity that created and is responsible
        for managing this segment. This object could be provisioned
        by the manager or it could be generated by the agent."

This will take care of some shortcomings of the LSR LIB and also
address some last call concerns on the objects.

- It gives LDP the chance to tie the session to the LSP.
I.e in the LDP MIB we will qualify the use of the owner attribute to
identify the session responsible for managing it.
- It takes away the slightly bad practice to have an enumerated value
which qickly is outdated, e.g GSMP which are being defined for the
purpuse of establishing LSPs.
- Other advantages could be build in the change.

This requires minimal change in the LSR MIB (only a small syntactic
change,  no new object or anything. This takes care of one of our
main obstacles in just using the LSR MIB LIB, being what session
to tie an LSPs to. This is important for a number of reasonsto LDP.

Regards
/// Hasse
--=====================_54811889==_.ALT-- From owner-mpls@UU.NET Tue May 9 12:45: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 ESMTP id MAA24946 for ; Tue, 9 May 2000 12:45: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 QQiolm16644; Tue, 9 May 2000 16:44:22 GMT Received: by mail-control.mail.uu.net id QQiolm07743 for mpls-outgoing; Tue, 9 May 2000 16:43: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 QQiolm07738 for ; Tue, 9 May 2000 16:43:49 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 QQiolm04157 for ; Tue, 9 May 2000 12:43: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 QQiolm01136 for ; Tue, 9 May 2000 16:43:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA02383 for mpls@uu.net; Tue, 9 May 2000 12:43:32 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiolm07723 for ; Tue, 9 May 2000 16:43:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiolm09837 for ; Tue, 9 May 2000 12:43:00 -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 QQiolm15824 for ; Tue, 9 May 2000 16:42:59 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA21514; Tue, 9 May 2000 09:42:55 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 9 May 2000 09:42:56 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40541@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: SimonKoo@IEEE.org Cc: mpls@UU.NET Subject: RE: Bandwidth Allocation of LSP Date: Tue, 9 May 2000 09:40:10 -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 Simon, According to CR-LDP, there are negotiation flags for traffic parameters (CDR, PDR, ...). In a label request message, if the flag for a specific traffic parameter is set and the node can't support it, the the node may replace that parameter with a smaller value. In the return path the Label mapping message will have the negotiated values, for the nodes to reserve. Regards, Shahram Davari Product Research PMC-Sierra, Inc. (Ottawa) 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 >-----Original Message----- >From: Darek Skalecki [mailto:dareks@nortelnetworks.com] >Sent: Monday, May 08, 2000 8:39 AM >To: SimonKoo@IEEE.org >Cc: mpls@UU.NET >Subject: Re: Bandwidth Allocation of LSP > > >Simon G. M. Koo wrote: > >> Hi, >> >> I would like to know, if a LSP is requested to setup >> with QoS requirement of certain bandwidth, will the >> system assign a fraction of the requirement if the >> full requirement cannot be satsified? Or just reject >> the setup request? And, if partial requirement can >> be satisfied, is there any negotiation procedure that >> the user can accept or reject the assigned amount of >> bandwidth? How is it working? >> >> Rgds, >> Simon >> >> ===== >> The average Ph.D. thesis is nothing but the transference of >bones from one graveyard to another. >> >> --Frank J. Dobie >> >> __________________________________________________ >> Do You Yahoo!? >> Send instant messages & get email alerts with Yahoo! Messenger. >> http://im.yahoo.com/ > >I am not aware of either CR-LDP or RSVP-TE allowing for >partial reservations. If the full >reservation cannot be made then a reservation failure message >is generated towards the originator, >eg: RESV_ERR for RSVP or PATH_ERR for RSVP-TE provided >reservations are made on PATH messages >instead of on RESV messages which I belive is the case for >RSVP-TE in order to make >"make-before-break" work. The originator then can either >request less bandwidth, compute a new >route or go to sleep. > >Darek > From owner-mpls@UU.NET Tue May 9 12:46:12 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 MAA24968 for ; Tue, 9 May 2000 12:46:12 -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 QQioln17355; Tue, 9 May 2000 16:45:04 GMT Received: by mail-control.mail.uu.net id QQiolm07766 for mpls-outgoing; Tue, 9 May 2000 16:44: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 QQiolm07755 for ; Tue, 9 May 2000 16:44: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 QQiolm04215 for ; Tue, 9 May 2000 12:44:16 -0400 (EDT) Received: from kcmso1.proxy.att.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso1.att.com [192.128.133.69]) id QQiolm16556 for ; Tue, 9 May 2000 16:44:15 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id MAA08632 for ; Tue, 9 May 2000 12:44:15 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id MAA26801; Tue, 9 May 2000 12:43:17 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 May 2000 12:44:14 -0400 Message-ID: <1B08859602C8D211B66F0000C0769CFA01BBD8E7@njc240po03.mt.att.com> From: "Ash, Gerald R (Jerry), ALARC" To: "'Vijay Srinivasan'" Cc: "'mpls@uu.net'" Subject: RE: end of last call for draft-ietf-mpls-crlsp-modify-01.txt Date: Tue, 9 May 2000 12:44:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Vijay, There were no further comments received during the last call against the current version of the draft. Unless there is some another need, I do not believe the draft needs to be re-issued. Thanks, Jerry -----Original Message----- From: Vijay Srinivasan [mailto:Vijay.Srinivasan@cosinecom.com] Sent: Monday, May 08, 2000 6:07 PM To: 'mpls@uu.net' Subject: end of last call for draft-ietf-mpls-crlsp-modify-01.txt The last call for draft-ietf-mpls-crlsp-modify-01.txt has closed. Could the authors please update the draft with comments received during the last call and re-issue the draft? Thanks, - Vijay ----Original Message----- From: Vijay Srinivasan [ mailto:vsriniva@cosinecom.com ] Sent: Monday, April 10, 2000 1:10 AM To: 'mpls@uu.net' Cc: 'swallow@cisco.com'; Ash, Gerald R (Jerry), ALARC Subject: last call for draft-ietf-mpls-crlsp-modify-01.txt The authors of draft-ietf-mpls-crlsp-modify-01.txt have requested that the draft be progressed to WG last call. This e-mail serves as a commencement of last call for this document, ending in two weeks. Please post your comments to the list. Thanks, - Vijay From owner-mpls@UU.NET Tue May 9 13:10: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 ESMTP id NAA25568 for ; Tue, 9 May 2000 13:10: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 QQiolo20416; Tue, 9 May 2000 17:10:05 GMT Received: by mail-control.mail.uu.net id QQiolo17319 for mpls-outgoing; Tue, 9 May 2000 17:09: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 QQiolo17303 for ; Tue, 9 May 2000 17:09:21 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 QQiolo07211 for ; Tue, 9 May 2000 13:08:50 -0400 (EDT) Received: from smtp2.cluster.oleane.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQiolo19278 for ; Tue, 9 May 2000 17:08:49 GMT Received: from oleane (dyn-1-1-224.Vin.dialup.oleane.fr [195.25.4.224]) by smtp2.cluster.oleane.net with SMTP id TAA89203; Tue, 9 May 2000 19:07:58 +0200 (CEST) Message-ID: <001f01bfb9d8$617cb320$0401a8c0@oleane.com> From: "Peter Lewis" To: "fan Song" , References: Subject: Re: looking for minutes of MPLS summit (Mar,2000) Date: Tue, 9 May 2000 19:02:37 +0200 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 Hi Mr Fan Song, We are the organizer of the MPLS'2000 conference and you can order the lecture notes +CD Rom from this conference directly to us. The price for the binder + CD Rom is 550 UDS/or Euros (shipping included). To order you just have to send us an email with your name, the delivery address and the address for invoicing /or your credit card informations. Thanks in advance. Feel free to contact us again if you should need some more information. Kind regards Iben iben@upperside.fr Upper Side 54, rue du Faubourg Saint Antoine 75012 Paris - FRANCE Tel: 33 1 53 46 63 80 Fax: 33 1 53 46 63 85 www.upperside.fr ----- Original Message ----- From owner-mpls@UU.NET Tue May 9 14:29: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 ESMTP id OAA27384 for ; Tue, 9 May 2000 14:29: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 QQiolt00074; Tue, 9 May 2000 18:29:07 GMT Received: by mail-control.mail.uu.net id QQiolt00281 for mpls-outgoing; Tue, 9 May 2000 18:28: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 QQiolt00276 for ; Tue, 9 May 2000 18:28: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 QQiolt06504 for ; Tue, 9 May 2000 14:28: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 QQiolt15962 for ; Tue, 9 May 2000 18:28:07 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA17490 for mpls@uu.net; Tue, 9 May 2000 14:28:06 -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 QQiolt00236 for ; Tue, 9 May 2000 18:27: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 QQiolt17474 for ; Tue, 9 May 2000 14:27:15 -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 QQiolt15420 for ; Tue, 9 May 2000 18:27:15 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA08996; Tue, 9 May 2000 14:27:02 -0400 (EDT) Message-Id: <4.2.2.20000509142250.03debc90@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 09 May 2000 14:26:06 -0400 To: manikantan , "'arun@force10networks.com'" , "'csrinivasan@tachion.com'" From: "Thomas D. Nadeau" Subject: RE: LSR MIB last call comments Cc: "'mpls@uu.net'" In-Reply-To: <01BFB995.70A9B8E0.manis@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, There are actually two different ifTypes, one an LSP and one for a tunnel interface, both of which have different and distinct ifType numbers (166, 150). We will add some descriptive text in the next version of the TE MIB to illustrate more clearly the fact that a tunnel may or may not be an interface. --Tom >My doubt is the interface type being "mpls" and "mplsTunnel" different? >if so can this be explained. > >If these are same then the values in the two MIBs are to be synced. > >thanks in advance >with best regards >mani From owner-mpls@UU.NET Tue May 9 16:58: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 QAA00775 for ; Tue, 9 May 2000 16:58: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 QQiomd12703; Tue, 9 May 2000 20:58:03 GMT Received: by mail-control.mail.uu.net id QQiomd25195 for mpls-outgoing; Tue, 9 May 2000 20:57:45 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiomd25190 for ; Tue, 9 May 2000 20:57:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiomd18274 for ; Tue, 9 May 2000 16:57:40 -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 QQiomd12294 for ; Tue, 9 May 2000 20:57:40 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id QAA18151; Tue, 9 May 2000 16:56:18 -0400 (EDT) Date: Tue, 9 May 2000 16:56:18 -0400 (EDT) From: Rajiv Papneja To: Peter Lewis cc: fan Song , mpls@UU.NET Subject: Re: looking for minutes of MPLS summit (Mar,2000) In-Reply-To: <001f01bfb9d8$617cb320$0401a8c0@oleane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Peter and Fan, I believe what is being referred here is the MPLS summit (Mar 2000) and not MPLS 2000 conference. MPLS 2000 Annual International Conference is yet to take place on October 22-24, 2000 at George Mason University, Center for the Arts, Fairfax, Virginia, USA. This event is jointly hosted by UUNET Technologies and Advanced Internet Lab of George Mason University. This event is third in series of the highly successful annual event on MPLS. MPLS 98, hosted by UUNET and GMU, which took place in the Washington DC area was the first conference focused on MPLS. MPLS 99, additionally, had sponsorship from major MPLS router vendors. MPLS 2000 will focus on the conceptual, implementation, and operational issues related to MPLS and MPL(ambda)S. This premier conference will include representation from major service providers, equipment manufacturers, and research institutions. It will also provide an opportunity for those who wish to exhibit their product and have bake-off testing. If you are interested in securing the Exhibit space at MPLS 2000 Conference and getting further information on this event, please visit http://ail.gmu.edu/. There are three categories of conference sponsorships available. Regards Rajiv Papneja On Tue, 9 May 2000, Peter Lewis wrote: > Hi Mr Fan Song, > > We are the organizer of the MPLS'2000 conference and you can order the > lecture notes +CD Rom from this conference directly to us. The price for the > binder + CD Rom is 550 UDS/or Euros (shipping included). > > To order you just have to send us an email with your name, the delivery > address and the address for invoicing /or your credit card informations. > Thanks in advance. > > Feel free to contact us again if you should need some more information. > > Kind regards > Iben > iben@upperside.fr > > Upper Side > 54, rue du Faubourg Saint Antoine > 75012 Paris - FRANCE > Tel: 33 1 53 46 63 80 > Fax: 33 1 53 46 63 85 > www.upperside.fr > ----- Original Message ----- > > > From owner-mpls@UU.NET Wed May 10 00:30: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 ESMTP id AAA07606 for ; Wed, 10 May 2000 00:30: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 QQionh22015; Wed, 10 May 2000 04:29:41 GMT Received: by mail-control.mail.uu.net id QQionh22841 for mpls-outgoing; Wed, 10 May 2000 04:29: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 QQionh22835 for ; Wed, 10 May 2000 04:29:17 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 QQionh19181 for ; Wed, 10 May 2000 00:29:09 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQionh21099 for ; Wed, 10 May 2000 04:28:25 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id JAA13201 for ; Wed, 10 May 2000 09:53:41 -0600 (GMT) Message-ID: <005801bfa2a5$714ae320$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: MPLS Interworking Date: Mon, 10 Apr 2000 10:00:01 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01BFA2D3.894EB860" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0055_01BFA2D3.894EB860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have a question on Interworking between non MPLS and MPLS domain. = The scenario is as depicted below=20 Non MPLS MPLS domain | A | B | Suppose router B is in the MPLS domain and A is the router in nonMPLS = domain. The data is to be sent from A to B and we wish to have the data = coming on ATM switch. Now A being in non MPLS router is having Ethernet = interface on 1 side and ATM interface on the interface to B. For all = data coming on A at ethernet interface, it is passed on to B thru the = ATM interface. Now the problem is how to inform A as to which label = (VPI/VCI) should be to send data to B ?=20 There are 2 options to this: 1. Run some Label Distribution Protocol on A also so that they can = exchange Labels and the data goes as it goes normally with some mapping = for CoS parameters in the two domains. 2. Statically configure labels (PVC) between A and B thru SLA. In this = there would be "n" PVCs set between A and B where "n" is the no. of = Class of Services supported by the MPLS domain. When data comes to A = (say on ethernet i/f) it is mapped to one of the PVCs depending on the = CoS byte. And the data goes to B. The data would come upto the layer 3 = in B and then FEC to Label mapping would be done for the data to go thru = the MPLS domain. Taking case 2 : Is it possible for such a scenario to work if I dont = want to run any MPLS protocol on A ? If yes then who ( which protocol ) = does this FEC to Label mapping on A before pasing on the data to B. Is there any way out so that I could have SVCs between A and B and still = not run any MPLS protocol on A. santosh ------=_NextPart_000_0055_01BFA2D3.894EB860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
    I have a question on Interworking between = non MPLS=20 and MPLS domain. The scenario is as depicted below
 
 Non=20 MPLS            = MPLS=20 domain
          &nb= sp;       =20 |
           &n= bsp;=20 A    |   =20 B
           &n= bsp;      =20 |
Suppose router B is in the MPLS domain and A is the router in = nonMPLS=20 domain. The data is to be sent from A to B and we wish to have the = data=20 coming on ATM switch. Now A being in non MPLS router is having=20 Ethernet interface on 1 side and ATM interface on the interface to = B. For=20 all data coming on A at ethernet interface, it is passed on to B = thru=20 the ATM interface. Now the problem is how to inform A as to which=20 label (VPI/VCI) should be to send data to B ?
There are 2 options to this:
1. Run some Label Distribution Protocol on A also so that they can = exchange=20 Labels and the data goes as it goes normally with some mapping for CoS=20 parameters in the     two domains.
2. Statically configure labels (PVC) between A and B thru SLA. In = this=20 there would be "n" PVCs set between A and B where "n" is the no. of = Class=20 of Services     supported by the MPLS domain. When data = comes to=20 A (say on ethernet i/f) it is mapped to one of the PVCs depending on the = CoS=20 byte. And the data goes to B. The data would come upto the layer 3 in B = and then=20 FEC to Label mapping would be done for the data to go thru the MPLS=20 domain.
 
Taking case 2 : Is it possible for such a scenario to work if I = dont want=20 to run any MPLS protocol on A ? If yes then who ( which protocol ) does = this FEC=20 to Label mapping on A before pasing on the data to B.
Is there any way out so that I could have SVCs between A and B and = still=20 not run any MPLS protocol on A.

santosh
 
 
------=_NextPart_000_0055_01BFA2D3.894EB860-- From owner-mpls@UU.NET Wed May 10 08:48: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 ESMTP id IAA24776 for ; Wed, 10 May 2000 08:48: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 QQioop23757; Wed, 10 May 2000 12:45:38 GMT Received: by mail-control.mail.uu.net id QQioop23600 for mpls-outgoing; Wed, 10 May 2000 12:45:01 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 QQiooo23531 for ; Wed, 10 May 2000 12:44: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 QQiooo28128 for ; Wed, 10 May 2000 08:44:36 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQiooo08695 for ; Wed, 10 May 2000 12:44:35 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4ACWRS01033 for ; Wed, 10 May 2000 14:32:28 +0200 (MET DST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4ACbgp25703 for ; Wed, 10 May 2000 14:37:43 +0200 (MET DST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FUC00J01GEUY6@mbb1.ericsson.se> for mpls@UU.NET; Wed, 10 May 2000 14:37:42 +0200 (MET DST) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FUC00EJ3GETMM@mbb1.ericsson.se>; Wed, 10 May 2000 14:37:41 +0200 (MET DST) Date: Wed, 10 May 2000 14:36:43 +0200 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: owner object in LSR MIB To: "Thomas D. Nadeau" Cc: mpls@UU.NET, arun@force10networks.com, cheenu Srinivasan Message-id: <391957DB.39330DAE@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <4.2.2.20000509120435.03e83470@funnel.cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8BIT > Subject: LSR MIB Comments From Earlier > Date: Thu, 04 May 2000 17:19:37 -0400 > From:"Thomas D. Nadeau" > To:"Cucchiara, Joan" , > Hans Sjöstrand > > Hi, > > Could you guys please re-state your > questions for the larger mailing list? Now > that we have a second last call, those > comments should be voiced on the public forum > to make sure that others can be aware of them > and that they are on record in the archives. > > --Tom Thats what I did, and I think that other people should be given the oppertunity to see the response and voice their opinion about this. Thats the whole idea with a last call isn't it. Here is a previous response from Tom on the issue, comments inline > Hi, > > > To repeat, LDP LSPs needs to be mapped to the session that manages them. > > I don't see how these object do that. But my proposal about using > > the owner object for this fixes this. > > > Let me reiterate how we have addressed this too. We feel > that it will suffice for the LDP Session to point to the LSP > via the XCIndex. The LDP Session should then delete the LDP > *before* deleting the session. We think that this will solve > your problem. If you look at it this way, then the issue > with the sessionOwner string (see below) is really orthogonal. In the process of aligning the two mibs we agreed to take out our LDP adjusted LIB and refer to the one in LSR MIB even though it's less suitable for LDP. One requirement we had on that LIB was to be able to tell what session an LSP belonged to. We asked you to add this feature to the LSR MIB in a flexible and protocool-independant way. You seam to think that this is useless requiremnt and don't want to add the feature. Two different opinions! What does the list think, is it a viable requirement to have information about what LDP session created the LSP stored with the LSP? I see applications such as accounting, troubleshooting and simple management. > > > Could I propose to transform this into something useful by having a > > loosly defined owner type, e.g just a OCTET STRING. The object > > description could be something like (just off my head) > > > The problem with making this value a free-form octet > string is that its definition is not standard, and hence > may not be inter-operable. An object is not defined solely by it's type, it also have it's DESCRIPTION clause which could contain information. My proposal was to open the object, make it protocool independant so it could be qualified in other protocool specific MIBs. I was clear that the proposed DESCRIPTION should be improved. I could happily work togehter with you to get that right one it's agreed that is the path to take. Regards /// Hasse > > --Tom > Hans Sjöstrand wrote: > > This has been discussed to some degree off line previously but is > > now > > part of the LSR last call comments so I post it on the list. LSR MIB > > authers, sorry to reiterate a little. > > > > The LDP mib has been updated to use the LIB tables in the LSR MIB to > > meet the last call comments. In order to fully align the LDP and LSR > > MIBs in a good way we would like you to consider the following > > proposal. > > > > To transform the owner object in the inSegment/outSegment/XC tables > > into something more loosly defined e.g just a OCTET STRING. THe > > object > > description could be something like (just off my head, it should be > > frased better) > > > > DESCRIPTION > > "Denotes the name of the entity that created and is > > responsible > > for managing this segment. This object could be provisioned > > by the manager or it could be generated by the agent." > > > > This will take care of some shortcomings of the LSR LIB and also > > address some last call concerns on the objects. > > > > - It gives LDP the chance to tie the session to the LSP. > > I.e in the LDP MIB we will qualify the use of the owner attribute to > > > > identify the session responsible for managing it. > > - It takes away the slightly bad practice to have an enumerated > > value > > which qickly is outdated, e.g GSMP which are being defined for the > > purpuse of establishing LSPs. > > - Other advantages could be build in the change. > > > > This requires minimal change in the LSR MIB (only a small syntactic > > change, no new object or anything. This takes care of one of our > > main obstacles in just using the LSR MIB LIB, being what session > > to tie an LSPs to. This is important for a number of reasonsto LDP. > > > > Regards > > /// Hasse > > From owner-mpls@UU.NET Wed May 10 09:08: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 JAA25186 for ; Wed, 10 May 2000 09:08: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 QQiooq23559; Wed, 10 May 2000 13:07:33 GMT Received: by mail-control.mail.uu.net id QQiooq01396 for mpls-outgoing; Wed, 10 May 2000 13:07: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 QQiooq01173 for ; Wed, 10 May 2000 13:06: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 QQiooq00582 for ; Wed, 10 May 2000 09:06:27 -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 QQiooq22724 for ; Wed, 10 May 2000 13:06:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA01487 for mpls@uu.net; Wed, 10 May 2000 09:06:25 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiooq00213 for ; Wed, 10 May 2000 13:05:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiooq11453 for ; Wed, 10 May 2000 09:05:39 -0400 (EDT) Received: from tnnt3.tachion.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQiooq07243 for ; Wed, 10 May 2000 13:05:35 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Wed, 10 May 2000 09:07:36 -0400 Message-ID: From: Cheenu Srinivasan To: =?iso-8859-1?Q?=27Hans_Sj=F6strand=27?= , "Thomas D. Nadeau" Cc: mpls@UU.NET, arun@force10networks.com Subject: RE: owner object in LSR MIB Date: Wed, 10 May 2000 09:07:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBA80.B57D3488" 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_01BFBA80.B57D3488 Content-Type: text/plain; charset="iso-8859-1" Hans, Let me summarize the response Tom is referring to which we sent to you yesterday. I agree that this is something the group at large needs to consider. We believe that the purpose your were trying to achieve in the context of the discussion about the owner object is the following: When a LDP session is torn down, you want to identify and remove the associated cross-connections. In order to do that what is required is a table that given the session identifier enables us to locate all the associated LSPs. Having a back pointer to the session in the LSR MIB doesn't not achieve your purpose, because given a session id you would have to walk the entire cross-connect table to identify all the LSPs associated with that session. It seems that the only solution to the above problem is to create a separate table in the LDP MIB indexed by the session identifier which will return a list of cross-connects associated with that session. One way to achieve this is to make a row pointer to a cross-connect entry the secondary index of such a table. Given this understanding, the discussion about the owner object or a new object in the LSR MIB is moot. As you can see, this is not an issue that comes about because you are trying to align the LDP MIB with the LSR MIB, rather this is an issue inherent in the LDP MIB that needs to be addressed there. Thanks, Cheenu ------_=_NextPart_001_01BFBA80.B57D3488 Content-Type: text/html; charset="iso-8859-1" RE: owner object in LSR MIB

Hans,

Let me summarize the response Tom is referring to which we sent to
you yesterday. I agree that this is something the group at large needs
to consider.

We believe that the purpose your were trying to achieve in the context of
the discussion about the owner object is the following:
When a LDP session is torn down, you want to identify and remove the
associated cross-connections.

In order to do that what is required is a table that given the
session identifier enables us to locate all the associated LSPs. Having a
back pointer to the session in the LSR MIB doesn't not achieve
your purpose, because given a session id you would have to walk the
entire cross-connect table to identify all the LSPs associated
with that session.

It seems that the only solution to the above problem is to create
a separate table in the LDP MIB indexed by the session identifier
which will return a list of cross-connects associated with that session.

One way to achieve this is to make a row pointer to a cross-connect
entry the secondary index of such a table.

Given this understanding, the discussion about the owner object or
a new object in the LSR MIB is moot. As you can see, this is not
an issue that comes about because you are trying to align the LDP
MIB with the LSR MIB, rather this is an issue inherent in the LDP
MIB that needs to be addressed there.

Thanks,
Cheenu

------_=_NextPart_001_01BFBA80.B57D3488-- From owner-mpls@UU.NET Wed May 10 10:20: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 ESMTP id KAA26627 for ; Wed, 10 May 2000 10:20: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 QQioov12264; Wed, 10 May 2000 14:19:34 GMT Received: by mail-control.mail.uu.net id QQioov15875 for mpls-outgoing; Wed, 10 May 2000 14:19: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 QQioov15867 for ; Wed, 10 May 2000 14:19: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 QQioov13753 for ; Wed, 10 May 2000 10:18:55 -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 QQioov11673 for ; Wed, 10 May 2000 14:18:55 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 HAA20484 for ; Wed, 10 May 2000 07:19:00 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA25217 for mpls@uu.net; Wed, 10 May 2000 10:18:53 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQioos05454 for ; Wed, 10 May 2000 13:43:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQioos15903 for ; Wed, 10 May 2000 09:42:46 -0400 (EDT) Received: from phoenix.ficon-tech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: phoenix.ficon-tech.com [209.125.90.2]) id QQioos16835 for ; Wed, 10 May 2000 13:42:46 GMT Received: from globespan.net (192.168.137.202) by phoenix.ficon-tech.com (Worldmail 1.3.167); 10 May 2000 09:53:27 -0400 Message-ID: <3919674E.62050D0E@globespan.net> Date: Wed, 10 May 2000 09:42:38 -0400 From: Rohit Chhapolia Organization: Globespan, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Gupta CC: mpls@UU.NET Subject: Re: MPLS Interworking References: <005801bfa2a5$714ae320$100d85a5@dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Santosh, Please see the comments below. Santosh Gupta wrote: > > Hi > I have a question on Interworking between non MPLS and MPLS domain. The scenario is as depicted below > > Non MPLS MPLS domain > | > A | B > | > Suppose router B is in the MPLS domain and A is the router in nonMPLS domain. The data is to be sent from A to B and we wish to have the data coming on ATM > switch. Now A being in non MPLS router is having Ethernet interface on 1 side and ATM interface on the interface to B. For all data coming on A at ethernet > interface, it is passed on to B thru the ATM interface. Now the problem is how to inform A as to which label (VPI/VCI) should be to send data to B ? > There are 2 options to this: > 1. Run some Label Distribution Protocol on A also so that they can exchange Labels and the data goes as it goes normally with some mapping for CoS parameters > in the two domains. > 2. Statically configure labels (PVC) between A and B thru SLA. In this there would be "n" PVCs set between A and B where "n" is the no. of Class of Services > supported by the MPLS domain. When data comes to A (say on ethernet i/f) it is mapped to one of the PVCs depending on the CoS byte. And the data goes to By CoS byte, do you mean DSCP in the IP header? > B. The data would come upto the layer 3 in B and then FEC to Label mapping would be done for the data to go thru the MPLS domain. In the diff-serv model, you may need to consider the incoming CoS also to decide the outgoing label. If the outgoing interface is ATM, it supports only L-LSPs and there should be different L-LSPs for different CoS. > > Taking case 2 : Is it possible for such a scenario to work if I dont want to run any MPLS protocol on A ? If yes then who ( which protocol ) does this FEC to > Label mapping on A before pasing on the data to B. As I understand, there is no such mapping on A for this case. > Is there any way out so that I could have SVCs between A and B and still not run any MPLS protocol on A. > > santosh > > Rohit -- Rohit Chhapolia Globespan, Inc. mailto:rohit@globespan.net http://www.globespan.net From owner-mpls@UU.NET Wed May 10 12:00: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 MAA28840 for ; Wed, 10 May 2000 12:00: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 QQiopb07622; Wed, 10 May 2000 15:59:34 GMT Received: by mail-control.mail.uu.net id QQiopb00140 for mpls-outgoing; Wed, 10 May 2000 15:59: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 QQiopb00134 for ; Wed, 10 May 2000 15:59:00 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 QQiopb22720 for ; Wed, 10 May 2000 11:58:39 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQiopb06874 for ; Wed, 10 May 2000 15:58:38 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4AFkZS07998 for ; Wed, 10 May 2000 17:46:35 +0200 (MET DST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4AFpqp23157 for ; Wed, 10 May 2000 17:51:52 +0200 (MET DST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FUC00101PEFIB@mbb1.ericsson.se> for mpls@UU.NET; Wed, 10 May 2000 17:51:51 +0200 (MET DST) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FUC003BIPEF0I@mbb1.ericsson.se>; Wed, 10 May 2000 17:51:51 +0200 (MET DST) Date: Wed, 10 May 2000 17:50:51 +0200 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: owner object in LSR MIB To: Cheenu Srinivasan Cc: "Thomas D. Nadeau" , mpls@UU.NET, arun@force10networks.com Message-id: <3919855B.4A8F69F@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Cheenu Srinivasan wrote: > > Hans, > > Let me summarize the response Tom is referring to which we sent to > you yesterday. I agree that this is something the group at large needs > to consider. > > We believe that the purpose your were trying to achieve in the context > of > the discussion about the owner object is the following: > When a LDP session is torn down, you want to identify and remove the > associated cross-connections. If a session is torn down, the LSPs will have to be released. This is part of the protocool and it's impossible to rely on the management system to do the cleaning. so this isn't the use and I never stated that. > > In order to do that what is required is a table that given the > session identifier enables us to locate all the associated LSPs. > Having a > back pointer to the session in the LSR MIB doesn't not achieve > your purpose, because given a session id you would have to walk the > entire cross-connect table to identify all the LSPs associated > with that session. > > It seems that the only solution to the above problem is to create > a separate table in the LDP MIB indexed by the session identifier > which will return a list of cross-connects associated with that > session. > > One way to achieve this is to make a row pointer to a cross-connect > entry the secondary index of such a table. I agree that thi sis the best solution to the specific problem, but I don't regard this as the application. > > Given this understanding, the discussion about the owner object or > a new object in the LSR MIB is moot. As you can see, this is not > an issue that comes about because you are trying to align the LDP > MIB with the LSR MIB, rather this is an issue inherent in the LDP > MIB that needs to be addressed there. When we did the modelling we regarded this as a requirement and modelled it in. Poosible applications are e.g - Network Management operation to clean up hanging resourses. This could be a way to find LSP segments that due to network errors are hanging. Not an everyday job but useful anyway. - In my opinion the session pointer is one of the properties of an LSP and therefore one of an LSPs objects. This could be for simple management or troubleshooting or whatever management task. I don't want to think out all future users, just provide the tools for efective managemetn. Thats what mib design is about. The simple fact that it was in when it was in the LDP MIB and it's out and proposed to be in the LSR MIB makes it in my mind an alignemnet issue. regards /// Hasse > > Thanks, > Cheenu From owner-mpls@UU.NET Wed May 10 12:20: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 ESMTP id MAA29277 for ; Wed, 10 May 2000 12:20: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 QQiopd21349; Wed, 10 May 2000 16:19:35 GMT Received: by mail-control.mail.uu.net id QQiopd09459 for mpls-outgoing; Wed, 10 May 2000 16:18: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 QQiopd09444 for ; Wed, 10 May 2000 16:18: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 QQiopd02738 for ; Wed, 10 May 2000 12:18: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 QQiopd20507 for ; Wed, 10 May 2000 16:18:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA26736 for mpls@uu.net; Wed, 10 May 2000 12:18:24 -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 QQiopd09414 for ; Wed, 10 May 2000 16:17:27 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 QQiopd02559 for ; Wed, 10 May 2000 12:17:03 -0400 (EDT) Received: from tnnt3.tachion.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQiopd19724 for ; Wed, 10 May 2000 16:17:01 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Wed, 10 May 2000 12:19:02 -0400 Message-ID: From: Cheenu Srinivasan To: =?iso-8859-1?Q?=27Hans_Sj=F6strand=27?= Cc: "Thomas D. Nadeau" , mpls@UU.NET, arun@force10networks.com Subject: RE: owner object in LSR MIB Date: Wed, 10 May 2000 12:18:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBA9B.73D63F82" 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_01BFBA9B.73D63F82 Content-Type: text/plain; charset="iso-8859-1" > > Let me summarize the response Tom is referring to which we sent to > > you yesterday. I agree that this is something the group at > large needs > > to consider. > > > > We believe that the purpose your were trying to achieve in > the context > > of > > the discussion about the owner object is the following: > > When a LDP session is torn down, you want to identify and remove the > > associated cross-connections. > > If a session is torn down, the LSPs will have to be released. This > is part of the protocool and it's impossible to rely on the > management > system to do the cleaning. so this isn't the use and I never stated > that. Maybe not you but it was certainly the use that was stated by one of the coauthors of the LDP MIB. And, I think, in order to be able to remove LSPs associated with a session from a management application you should add this table to the LDP MIB. The other points you make, while mildly interesting, are not nearly reason enough to add new objects to the LSR MIB at this stage. Certainly it has nothing to do with aligning the LDP and LSR MIBs. As we have tried to explain before, the approach is top down. Pointers go from the session (be it LDP or RSVP or ...) or tunnel to the underlying LSP (cross-connect in the LSR MIB) and not the other way around. There is no purpose in putting back pointers to all kinds of protocol specific objects. Regards, Cheenu ------_=_NextPart_001_01BFBA9B.73D63F82 Content-Type: text/html; charset="iso-8859-1" RE: owner object in LSR MIB

> > Let me summarize the response Tom is referring to which we sent to
> > you yesterday. I agree that this is something the group at
> large needs
> > to consider.
> >
> > We believe that the purpose your were trying to achieve in
> the context
> > of
> > the discussion about the owner object is the following:
> > When a LDP session is torn down, you want to identify and remove the
> > associated cross-connections.
>
> If a session is torn down, the LSPs will have to be released. This
> is part of the protocool and it's impossible to rely on the
> management
> system to do the cleaning. so this isn't the use and I never stated
> that.

Maybe not you but it was certainly the use that was stated by one of
the coauthors of the LDP MIB. And, I think, in order to be able to
remove LSPs associated with a session from a management application you
should add this table to the LDP MIB.

The other points you make, while mildly
interesting, are not nearly reason enough to add new objects to the LSR
MIB at this stage. Certainly it has nothing to do with aligning the
LDP and LSR MIBs. As we have tried to explain before, the approach is
top down. Pointers go from the session (be it LDP or RSVP or ...) or
tunnel to the underlying LSP (cross-connect in the LSR MIB) and not
the other way around. There is no purpose in putting back pointers
to all kinds of protocol specific objects.

Regards,
Cheenu

------_=_NextPart_001_01BFBA9B.73D63F82-- From owner-mpls@UU.NET Wed May 10 13:45:00 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 NAA00766 for ; Wed, 10 May 2000 13:44: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 QQiopi15119; Wed, 10 May 2000 17:44:16 GMT Received: by mail-control.mail.uu.net id QQiopi23432 for mpls-outgoing; Wed, 10 May 2000 17: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 QQiopi23423 for ; Wed, 10 May 2000 17:43: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 QQiopi04783 for ; Wed, 10 May 2000 13:43:15 -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 QQiopi00376 for ; Wed, 10 May 2000 17:43:14 GMT Message-ID: <5909c1e701d9d1ff97c1637d511287d239199fe9@force10networks.com> From: Arun Viswanathan To: =?iso-8859-1?Q?=27Hans_Sj=F6strand=27?= , Cheenu Srinivasan Cc: "Thomas D. Nadeau" , mpls@UU.NET, arun@force10networks.com Subject: RE: owner object in LSR MIB Date: Wed, 10 May 2000 10:42:41 -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 Hans, > When we did the modelling we regarded this as a requirement > and modelled > it in. Poosible applications are e.g > - Network Management operation to clean up hanging resourses. > This could > be a way to find LSP segments that due to network errors are hanging. > Not > an everyday job but useful anyway. For the scenario you mention, once hanging resources are identified belonging to a protocol, further trouble-shooting must be done in the protocol context. This support is provided by the owner object. If you need further trouble-shooting support it must be provided by the protocol, IMHO. LSR MIB is not the right place for such support. > - In my opinion the session pointer is one of the properties of an LSP > and therefore one of an LSPs objects. This could be for simple > management > or troubleshooting or whatever management task. I don't want to think > out > all future users, just provide the tools for efective > managemetn. Thats > what mib design is about. > > The simple fact that it was in when it was in the LDP MIB and it's out > and > proposed to be in the LSR MIB makes it in my mind an > alignemnet issue. > Can you please be specific? Which object are you refering to? Which LDP MIB version? -arun From owner-mpls@UU.NET Wed May 10 13:57: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 NAA00872 for ; Wed, 10 May 2000 13:57: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 QQiopj23239; Wed, 10 May 2000 17:56:53 GMT Received: by mail-control.mail.uu.net id QQiopj24193 for mpls-outgoing; Wed, 10 May 2000 17:56: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 QQiopj24188 for ; Wed, 10 May 2000 17:56: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 QQiopj15722 for ; Wed, 10 May 2000 13:56:04 -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 QQiopj09054 for ; Wed, 10 May 2000 17:56:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA10958 for mpls@uu.net; Wed, 10 May 2000 13:55:59 -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 QQiopj24079 for ; Wed, 10 May 2000 17:55: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 QQiopj15622 for ; Wed, 10 May 2000 13:55:21 -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 QQiopj22083 for ; Wed, 10 May 2000 17:55:20 GMT Received: from tnadeau-pc02 (ch2-dhcp134-234.cisco.com [161.44.134.234]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13331; Wed, 10 May 2000 13:55:16 -0400 (EDT) Message-Id: <4.2.2.20000510135315.03dfd390@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 10 May 2000 13:55:14 -0400 To: mpls@UU.NET, cheenu Srinivasan , arun@force10networks.com From: "Thomas D. Nadeau" Subject: Removal of oper/adminStatus for LSR MIB in/out segments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, We would like to ask if there is any objection to the removal of the admin/operStatus objects on the in/outSegment objects in the LSR MIB. Some folks had asked to have them removed, and we had intended to do this in the last WG Last Call version, but did not make the changes then. We would like to ask if anyone would object to their being removed in the second last call version. --Tom, Cheenu, Arun From owner-mpls@UU.NET Wed May 10 14:56: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 OAA02226 for ; Wed, 10 May 2000 14:56: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 QQiopn20440; Wed, 10 May 2000 18:56:10 GMT Received: by mail-control.mail.uu.net id QQiopn05532 for mpls-outgoing; Wed, 10 May 2000 18:55:50 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 QQiopn05527 for ; Wed, 10 May 2000 18:55: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 QQiopn24661 for ; Wed, 10 May 2000 14:55:23 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQiopn19728 for ; Wed, 10 May 2000 18:55:23 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 May 2000 14:54:02 -0400 Message-ID: From: "Kullberg, Alan" To: "'mpls@UU.NET'" Subject: RE: Second WG last call on LSR MIB Date: Wed, 10 May 2000 14:53:55 -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 The MplsLSPID is described as "This value is piggybacked by the signaling protocol when the LSP is signaled within the network." However, this is only true for CR-LDP and RSVP, since LDP does not have any TLV containing the LSPID to pass along. The question is what value should we have for the mplsXCLspId object for a LDP LSP ? Alan From owner-mpls@UU.NET Wed May 10 21:34: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 ESMTP id VAA05958 for ; Wed, 10 May 2000 21:34: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 QQioqo01824; Thu, 11 May 2000 01:33:15 GMT Received: by mail-control.mail.uu.net id QQioqo29527 for mpls-outgoing; Thu, 11 May 2000 01:32: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 QQioqo29518 for ; Thu, 11 May 2000 01:32: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 QQioqo26479 for ; Wed, 10 May 2000 21:32:17 -0400 (EDT) Received: from mail.edu.cn by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [202.202.32.39]) id QQioqo01036 for ; Thu, 11 May 2000 01:32:03 GMT Received: from guojn ([202.202.42.67]) by mail.edu.cn (8.9.1b+Sun/8.9.1) with SMTP id JAA07607 for ; Thu, 11 May 2000 09:30:36 +0800 (CST) Message-ID: <003501bfbae9$5f3f6640$432acaca@guojn.cqupt.edu.cn> From: "Guo Junneng" To: Subject: RFC2117.ps Date: Thu, 11 May 2000 09:36:12 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01BFBB2C.58986240" 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_002C_01BFBB2C.58986240 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, Is there anyone can tell me how to get the Postscipt Version of = RFC2117? Thanks, =20 Stone ------=_NextPart_000_002C_01BFBB2C.58986240 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
    Is there anyone can tell me how = to get the=20 Postscipt Version of RFC2117?
    Thanks,
   
    Stone
------=_NextPart_000_002C_01BFBB2C.58986240-- From owner-mpls@UU.NET Wed May 10 23:30: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 ESMTP id XAA08624 for ; Wed, 10 May 2000 23:30: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 QQioqv21838; Thu, 11 May 2000 03:29:30 GMT Received: by mail-control.mail.uu.net id QQioqv22985 for mpls-outgoing; Thu, 11 May 2000 03:29: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 QQioqv22980 for ; Thu, 11 May 2000 03:28: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 QQioqv05799 for ; Wed, 10 May 2000 23:28:41 -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 QQioqv08102 for ; Thu, 11 May 2000 03:28:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA06005 for mpls@uu.net; Wed, 10 May 2000 23:28:40 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQioqv22965 for ; Thu, 11 May 2000 03:28:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQioqv21420 for ; Wed, 10 May 2000 23:28:11 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQioqv20929 for ; Thu, 11 May 2000 03:28:10 GMT Received: from jlawrenc-pc.cisco.com (tky-vpdn-client-30.cisco.com [144.254.191.31]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id UAA23058; Wed, 10 May 2000 20:26:23 -0700 (PDT) Message-Id: <4.2.2.20000511105413.00a7f5f0@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 11 May 2000 11:07:42 +1000 To: "Santosh Gupta" From: Jeremy Lawrence Subject: Re: MPLS Interworking Cc: In-Reply-To: <005801bfa2a5$714ae320$100d85a5@dti.daewoo.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Santosh, At 10:00 04/10/2000 +0530, Santosh Gupta wrote: >Hi > I have a question on Interworking between non MPLS and MPLS domain. The scenario is as depicted below > > Non MPLS MPLS domain > | > A | B > | >Suppose router B is in the MPLS domain and A is the router in nonMPLS domain. That's not possible. An MPLS domain must end at a router, called an edge Label Switch Router (LSR). An edge LSR has both MPLS and ordinary IP interfaces. >The data is to be sent from A to B and we wish to have the data coming on ATM switch. Now A being in non MPLS router is having Ethernet interface on 1 side and ATM interface on the interface to B. For all data coming on A at ethernet interface, it is passed on to B thru the ATM interface. Now the problem is how to inform A as to which label (VPI/VCI) should be to send data to B ? >There are 2 options to this: >1. Run some Label Distribution Protocol on A also so that they can exchange Labels and the data goes as it goes normally with some mapping for CoS parameters in the two domains. This makes router A into an edge LSR, and part of the MPLS domain. >2. Statically configure labels (PVC) A PVC is not really a label. A PVC carrying RFC 1483 (or the sucessor RFC, whatever it is) IP-over-ATM is not an MPLS link at all, just another IP link. In this case, B becomes the edge LSR, and A is not running MPLS at all. >between A and B thru SLA. In this there would be "n" PVCs set between A and B where "n" is the no. of Class of Services supported by the MPLS domain. At least one vendor supports use of multiple, bundled, PVCs to support multiple IP classes of service. However this is somewhat different to MPLS+Diffserv using multiple label VCs (LVCs) for different classes. >When data comes to A (say on ethernet i/f) it is mapped to one of the PVCs depending on the CoS byte. And the data goes to B. The data would come upto the layer 3 in B and then FEC to Label mapping would be done for the data to go thru the MPLS domain. > >Taking case 2 : Is it possible for such a scenario to work if I dont want to run any MPLS protocol on A ? Yes. >If yes then who ( which protocol ) does this FEC to Label mapping on A before pasing on the data to B. Ordinary IP forwarding forwards packets on the PVC link to B. The PVC link is just another IP link. >Is there any way out so that I could have SVCs between A and B and still not run any MPLS protocol on A. If you really wanted to, you could run NHRP & SVCs between A and B, but it is not clear that this adds anything except complexity. It's probably easier to have PVCs between A & B. Hope this helps, Jeremy Lawrence From owner-mpls@UU.NET Thu May 11 06:21: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 GAA23286 for ; Thu, 11 May 2000 06:21: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 QQiorx26826; Thu, 11 May 2000 10:20:16 GMT Received: by mail-control.mail.uu.net id QQiorx14378 for mpls-outgoing; Thu, 11 May 2000 10:19: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 QQiorx14363 for ; Thu, 11 May 2000 10:19: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 QQiorx09274 for ; Thu, 11 May 2000 06:19:17 -0400 (EDT) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQiorx15680 for ; Thu, 11 May 2000 10:19:16 GMT Received: by smtp2.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 11:19:04 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E140981@monk.datcon.co.uk> From: Adrian Farrel To: "Thomas D. Nadeau" , mpls@UU.NET, cheenu Srinivasan , arun@force10networks.com Subject: RE: Removal of oper/adminStatus for LSR MIB in/out segments Date: Thu, 11 May 2000 11:18:56 +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 I support this proposal. 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: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Wednesday, May 10, 2000 6:55 PM >To: mpls@UU.NET; cheenu Srinivasan; arun@force10networks.com >Subject: Removal of oper/adminStatus for LSR MIB in/out segments > > > > Hi, > > We would like to ask if there is any >objection to the removal of the admin/operStatus >objects on the in/outSegment objects in the >LSR MIB. Some folks had asked to have them removed, and >we had intended to do this in the last WG Last Call >version, but did not make the changes then. We would >like to ask if anyone would object to their being >removed in the second last call version. > > --Tom, Cheenu, Arun > > From owner-mpls@UU.NET Thu May 11 07:58: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 ESMTP id HAA24750 for ; Thu, 11 May 2000 07:58: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 QQiosd08105; Thu, 11 May 2000 11:56:26 GMT Received: by mail-control.mail.uu.net id QQiosd28819 for mpls-outgoing; Thu, 11 May 2000 11:55:51 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 QQiosd28814 for ; Thu, 11 May 2000 11:55:49 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 QQiosd11357 for ; Thu, 11 May 2000 07:55:40 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiosd16558 for ; Thu, 11 May 2000 11:55:02 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id RAA28597; Thu, 11 May 2000 17:18:29 -0600 (GMT) Message-ID: <00b801bfa3ac$bd66da40$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: "Jeremy Lawrence" Cc: References: <4.2.2.20000511105413.00a7f5f0@bulkrate.cisco.com> Subject: Re: MPLS Interworking Date: Tue, 11 Apr 2000 17:24:41 +0530 Organization: Daewoo Telecom 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 Hello Lawrence Please see the comments embedded. > Santosh, > > At 10:00 04/10/2000 +0530, Santosh Gupta wrote: > >Hi > > I have a question on Interworking between non MPLS and MPLS domain. The scenario is as depicted below > > > > Non MPLS MPLS domain > > | > > A | B > > | > >Suppose router B is in the MPLS domain and A is the router in nonMPLS domain. > > That's not possible. An MPLS domain must end at a router, called > an edge Label Switch Router (LSR). An edge LSR has both MPLS and > ordinary IP interfaces. > OK fine, no MPLS protocol should run on A as it is outside MPLS domain. > > >The data is to be sent from A to B and we wish to have the data coming on ATM switch. Now A being in non MPLS router is having Ethernet interface on 1 side and ATM interface on the interface to B. For all data coming on A at ethernet interface, it is passed on to B thru the ATM interface. Now the problem is how to inform A as to which label (VPI/VCI) should be to send data to B ? > >There are 2 options to this: > >1. Run some Label Distribution Protocol on A also so that they can exchange Labels and the data goes as it goes normally with some mapping for CoS parameters in the two domains. > > This makes router A into an edge LSR, and part of the MPLS domain. > > >2. Statically configure labels (PVC) > > A PVC is not really a label. A PVC carrying RFC 1483 (or the sucessor > RFC, whatever it is) IP-over-ATM is not an MPLS link at all, just > another IP link. In this case, B becomes the edge LSR, and A is not > running MPLS at all. > > >between A and B thru SLA. In this there would be "n" PVCs set between A and B where "n" is the no. of Class of Services supported by the MPLS domain. > > At least one vendor supports use of multiple, bundled, PVCs to support > multiple IP classes of service. However this is somewhat different > to MPLS+Diffserv using multiple label VCs (LVCs) for different classes. I am also proposing the same thing. I am supporting "n" class of service for which there are "n" PVCs opened. that way it is possible to police on the amount of data sent by the customer for different class of service at the edge LSR. > > >When data comes to A (say on ethernet i/f) it is mapped to one of the PVCs depending on the CoS byte. And the data goes to B. The data would come upto the layer 3 in B and then FEC to Label mapping would be done for the data to go thru the MPLS domain. > > > >Taking case 2 : Is it possible for such a scenario to work if I dont want to run any MPLS protocol on A ? > > Yes. > > >If yes then who ( which protocol ) does this FEC to Label mapping on A before pasing on the data to B. > > Ordinary IP forwarding forwards packets on the PVC link to B. The PVC > link is just another IP link. > > >Is there any way out so that I could have SVCs between A and B and still not run any MPLS protocol on A. > > If you really wanted to, you could run NHRP & SVCs between A and B, > but it is not clear that this adds anything except complexity. It's > probably easier to have PVCs between A & B. > > Hope this helps, > > Jeremy Lawrence > > From owner-mpls@UU.NET Thu May 11 08:22:47 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 IAA25411 for ; Thu, 11 May 2000 08:22: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 QQiosf01885; Thu, 11 May 2000 12:21:33 GMT Received: by mail-control.mail.uu.net id QQiosf09375 for mpls-outgoing; Thu, 11 May 2000 12:21: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 QQiosf09323 for ; Thu, 11 May 2000 12:21: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 QQiosf18170 for ; Thu, 11 May 2000 08:20:53 -0400 (EDT) Received: from alu-etsetb.upc.es by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alu-etsetb.upc.es [147.83.68.11]) id QQiosf01229 for ; Thu, 11 May 2000 12:20:47 GMT Received: from alu-etsetb.upc.es (a2s104a-14.upc.es [147.83.68.214]) by alu-etsetb.upc.es (Postfix) with ESMTP id 32FCECF9067 for ; Thu, 11 May 2000 14:20:23 +0200 (CEST) Message-ID: <391AA586.A520BBD1@alu-etsetb.upc.es> Date: Thu, 11 May 2000 14:20:23 +0200 From: Juan Diego Otero X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: mpls@UU.NET Subject: Looking for MPLS-VPN drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm looking for these documents. I'll be glad if somebody tells me where I can find them. - Casey, L. et al "IP VPN Realization using MPLS Tunnels." - Li, T. "CPE based VPNs using MPLS." Thanks a lot, Diego Otero From owner-mpls@UU.NET Thu May 11 08:44: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 IAA26172 for ; Thu, 11 May 2000 08:44: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 QQiosg05296; Thu, 11 May 2000 12:42:23 GMT Received: by mail-control.mail.uu.net id QQiosg11082 for mpls-outgoing; Thu, 11 May 2000 12:41:51 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiosg11077 for ; Thu, 11 May 2000 12:41:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiosg08352 for ; Thu, 11 May 2000 08:41:24 -0400 (EDT) Received: from tenornetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQiosg13669 for ; Thu, 11 May 2000 12:41:24 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id IAA02754; Thu, 11 May 2000 08:41:17 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; THU, 11 May 2000 08:39:09 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 08:39:09 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E5609EC2D@newman.tenornet.com> From: "Mancour, Tim" To: "'Thomas D. Nadeau'" , mpls@UU.NET, cheenu Srinivasan , arun@force10networks.com Subject: RE: Removal of oper/adminStatus for LSR MIB in/out segments Date: Thu, 11 May 2000 08:39:06 -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, I fully support removing the adminStatus, and associated notifications and notification controls for both the in-segment and out-segment. In the following cases, however, the segment's operStatus will not simply reflect the operStatus of the underlying interface: 1. The segment's rowStatus is set to notInService. 2. The underlying interface for an out-segment is missing. 3. An in-segment whose label is out-of-range. I'm aware that the above won't occur for LSP's that are created via signalling, but all three are possible (according to my interpretation of the current MIB) for manually configured LSPs. Therefore, I vote that the operStatus objects remain - although it might be wise to more clearly define their return values. TimM -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, May 10, 2000 1:55 PM To: mpls@UU.NET; cheenu Srinivasan; arun@force10networks.com Subject: Removal of oper/adminStatus for LSR MIB in/out segments Hi, We would like to ask if there is any objection to the removal of the admin/operStatus objects on the in/outSegment objects in the LSR MIB. Some folks had asked to have them removed, and we had intended to do this in the last WG Last Call version, but did not make the changes then. We would like to ask if anyone would object to their being removed in the second last call version. --Tom, Cheenu, Arun From owner-mpls@UU.NET Thu May 11 09:07: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 JAA26850 for ; Thu, 11 May 2000 09:07: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 QQiosi29599; Thu, 11 May 2000 13:05:46 GMT Received: by mail-control.mail.uu.net id QQiosi17129 for mpls-outgoing; Thu, 11 May 2000 13:05: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 QQiosi17079 for ; Thu, 11 May 2000 13:05: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 QQiosi23018 for ; Thu, 11 May 2000 09:05:04 -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 QQiosi20423 for ; Thu, 11 May 2000 13:05:04 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Thu, 11 May 2000 09:04:33 -0400 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K4DZW24Y; Thu, 11 May 2000 09:04:28 -0400 Received: from nortelnetworks.com (H9704002 [47.221.35.122]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KWF00AAS; Thu, 11 May 2000 09:04:29 -0400 Message-ID: <391AAF01.A7A68E76@nortelnetworks.com> Date: Thu, 11 May 2000 09:00:49 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Hamid Ould-Brahim" X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Juan Diego Otero CC: mpls@UU.NET Subject: Re: Looking for MPLS-VPN drafts References: <391AA586.A520BBD1@alu-etsetb.upc.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Try this site: http://infonet.aist-nara.ac.jp/member/nori-d/mlr/#mpls-vpn Regards Hamid Ould-Brahim Juan Diego Otero wrote: > > Hi, > > I'm looking for these documents. I'll be glad if somebody tells me > where I can find them. > > - Casey, L. et al "IP VPN Realization using MPLS Tunnels." > > - Li, T. "CPE based VPNs using MPLS." > > Thanks a lot, > > Diego Otero From owner-mpls@UU.NET Thu May 11 13:34:31 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 NAA03972 for ; Thu, 11 May 2000 13:34: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 QQiota12247; Thu, 11 May 2000 17:33:15 GMT Received: by mail-control.mail.uu.net id QQiota13420 for mpls-outgoing; Thu, 11 May 2000 17:32:59 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 QQiota13413 for ; Thu, 11 May 2000 17:32: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 QQiota24671 for ; Thu, 11 May 2000 13:32:24 -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 QQiota13356 for ; Thu, 11 May 2000 17:32:24 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id NAA10856; Thu, 11 May 2000 13:32:23 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA25093; Thu, 11 May 2000 13:31:27 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 13:32:22 -0400 Message-ID: <15BF137B61C7D211BAF50000C0589CFA0216D2F4@njc240po02.mt.att.com> From: "Chase, Christopher J (Chris), ALNTK" To: "'nick.t.davis@bellatlantic.com'" , fan Song Cc: mpls@UU.NET Subject: RE: looking for minutes of MPLS summit (Mar,2000) Date: Thu, 11 May 2000 13:32:20 -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 attended the conference MPLS summit meeting organized by ICM (International Communications For Management Group), in San Diego. It was disappointing. I will not be attending another of their conferences. Many of the lecture notes were never made available. Many of the scheduled speakers did not show and inadequate substitues were made. The organizers were completely indifferent to complaints. Perhaps you are refering to the MPLS Forum meeting held the same month in France? It was a far superior meeting. The MPLS Conference held jointly between UUNET and GMU was also a much better conference. Chris Chase AT&T Labs Network Architect IP Enabled Frame Relay and Frame Relay > -----Original Message----- > From: nick.t.davis@bellatlantic.com > [mailto:nick.t.davis@bellatlantic.com] > Sent: Monday, May 08, 2000 12:40 PM > To: fan Song > Cc: mpls@UU.NET > Subject: Re: looking for minutes of MPLS summit (Mar,2000) > > > > > There are a large number of people that are looking for the > minutes from the > March meeting, myself included. > > Nick > > From owner-mpls@UU.NET Thu May 11 16:48: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 QAA07987 for ; Thu, 11 May 2000 16:48: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 QQiotn15269; Thu, 11 May 2000 20:46:38 GMT Received: by mail-control.mail.uu.net id QQiotn20900 for mpls-outgoing; Thu, 11 May 2000 20:46: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 QQiotn20895 for ; Thu, 11 May 2000 20:45: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 QQiotn23146 for ; Thu, 11 May 2000 16:45:26 -0400 (EDT) Received: from smtprch2.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15]) id QQiotn14300 for ; Thu, 11 May 2000 20:45:26 GMT Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 11 May 2000 15:38:40 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 May 2000 15:41:28 -0500 Message-ID: From: "Badri Devalla" To: "'Chase, Christopher J (Chris), ALNTK'" , "'nick.t.davis@bellatlantic.com'" , fan Song Cc: mpls@UU.NET Subject: RE: looking for minutes of MPLS summit (Mar,2000) Date: Thu, 11 May 2000 15:41:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBB89.47A10C96" X-Orig: 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_01BFBB89.47A10C96 Content-Type: text/plain Howdy! Just wanted to join the chorus in expressing my frustration dealing with "ICM - GBC Conference Division" the organizers of MPLS Summit held Mar 20-22 in San Diego. I have made several requests to ICM for copies of presentation and still have not received a word (This after paying $2,800 for the 2.5 day event). Watch out for these guys badri ----- Badri Devalla IP & ATM Network Planning Business & Network Consulting, Richardson bdevalla@nortelnetworks.com Tel: (972) 685 5174 (W), (972) 747 1194 (H) > -----Original Message----- > From: Chase, Christopher J (Chris), ALNTK [SMTP:chase@att.com] > Sent: Thursday, May 11, 2000 12:32 PM > To: 'nick.t.davis@bellatlantic.com'; fan Song > Cc: mpls@UU.NET > Subject: RE: looking for minutes of MPLS summit (Mar,2000) > > I attended the conference MPLS summit meeting organized by ICM > (International Communications For Management Group), in San Diego. It was > disappointing. I will not be attending another of their conferences. > Many > of the lecture notes were never made available. Many of the scheduled > speakers did not show and inadequate substitues were made. The organizers > were completely indifferent to complaints. > > Perhaps you are refering to the MPLS Forum meeting held the same month in > France? It was a far superior meeting. The MPLS Conference held jointly > between UUNET and GMU was also a much better conference. > > Chris Chase > AT&T Labs > Network Architect > IP Enabled Frame Relay and Frame Relay > > > > -----Original Message----- > > From: nick.t.davis@bellatlantic.com > > [mailto:nick.t.davis@bellatlantic.com] > > Sent: Monday, May 08, 2000 12:40 PM > > To: fan Song > > Cc: mpls@UU.NET > > Subject: Re: looking for minutes of MPLS summit (Mar,2000) > > > > > > > > > > There are a large number of people that are looking for the > > minutes from the > > March meeting, myself included. > > > > Nick > > > > ------_=_NextPart_001_01BFBB89.47A10C96 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: looking for minutes of MPLS summit (Mar,2000)

Howdy!
Just wanted to = join the chorus in expressing my frustration dealing with "ICM - = GBC Conference Division" the organizers of MPLS Summit held Mar = 20-22 in San Diego. I have made several requests to ICM for copies of = presentation and still have not received a word (This after paying = $2,800 for the 2.5 day event).

Watch out for = these guys
badri
-----
Badri Devalla
IP & ATM Network Planning
Business & Network Consulting, = Richardson
bdevalla@nortelnetworks.com
Tel: (972) 685 5174 (W), (972) 747 = 1194 (H)


    -----Original Message-----
    From:   Chase, Christopher J (Chris), ALNTK = [SMTP:chase@att.com]
    Sent:   Thursday, May 11, 2000 12:32 PM
    To:     'nick.t.davis@bellatlantic.com'; fan Song
    Cc:     mpls@UU.NET
    Subject:       = RE: looking for minutes of MPLS = summit (Mar,2000)

    I attended the conference MPLS summit = meeting organized by ICM
    (International Communications For = Management Group), in San Diego.  It was
    disappointing.  I will not be = attending another of their conferences.  Many
    of the lecture notes were never made = available.  Many of the scheduled
    speakers did not show and inadequate = substitues were made.  The organizers
    were completely indifferent to = complaints. 

    Perhaps you are refering to the MPLS = Forum meeting held the same month in
    France?  It was a far superior = meeting.  The MPLS Conference held jointly
    between UUNET and GMU was also a much = better conference.

    Chris Chase
    AT&T Labs
    Network Architect
    IP Enabled Frame Relay and Frame = Relay


    > -----Original Message-----
    > From: = nick.t.davis@bellatlantic.com
    > [mailto:nick.t.davis@bellat= lantic.com]
    > Sent: Monday, May 08, 2000 12:40 = PM
    > To: fan Song
    > Cc: mpls@UU.NET
    > Subject: Re: looking for minutes = of MPLS summit (Mar,2000)
    >
    >
    >
    >
    > There are a large number of = people that are looking for the
    > minutes from the
    > March meeting, myself = included.
    >
    > Nick
    >
    >

------_=_NextPart_001_01BFBB89.47A10C96-- From owner-mpls@UU.NET Thu May 11 17:31: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 ESMTP id RAA08562 for ; Thu, 11 May 2000 17:31: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 QQiotq29957; Thu, 11 May 2000 21:31:10 GMT Received: by mail-control.mail.uu.net id QQiotq02124 for mpls-outgoing; Thu, 11 May 2000 21:30:43 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiotq02116 for ; Thu, 11 May 2000 21:30:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiotp26440 for ; Thu, 11 May 2000 17:29:52 -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 QQiotp27892 for ; Thu, 11 May 2000 21:29:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA17166 for mpls@uu.net; Thu, 11 May 2000 17:29:48 -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 QQiotp02008 for ; Thu, 11 May 2000 21:29: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 QQiotp12990 for ; Thu, 11 May 2000 17:29:02 -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 QQiotp26305 for ; Thu, 11 May 2000 21:29:00 GMT Received: from tnadeau-pc02 (ch2-dhcp134-234.cisco.com [161.44.134.234]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA19186; Thu, 11 May 2000 17:28:48 -0400 (EDT) Message-Id: <4.2.2.20000509143330.03de9c90@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 11 May 2000 17:28:46 -0400 To: "Cucchiara, Joan" , "'arun@force10networks.com'" , "'csrinivasan@tachion.com'" From: "Thomas D. Nadeau" Subject: Re: LSR MIB last call comments Cc: "'mpls@uu.net'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15FAC3@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1850515==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_1850515==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Joan, >First Part >=========== > >* MplsObjectOwner TC, > > 'crldp' should definitely be added -- it appeared in early > versions of the MIB, so must have been mistakenly removed. We thought that the 'ldp' option would cover it. We will add 'cdldp' as requested as long as there are no objections. > 'unknown' appears here, it would seem that the agent > would always know where the data to create a row > originated from, so am wondering why this was added. This option was chosen to present the agent with a reasonable default value, as well as a choice if it did not want to support this value. > I still don't understand why other possibilities > here such as config file, cli, web-interface, etc. were not > added for completeness sake. The enumerations have always included 5 catagories: management (snmp), the signaling protocols (ldp/rsvp), provisioning (cops), unknown (a reasonable default or a choice for agents which do not support this object) and other. We think that the choices that you suggest fall under the "management" category. >Second Part: >=========== >* mplsInterfaceTotalBuffer and mplsInterfaceAvailableBuffer > > was expecting that more description for these objects > would be given (what these values mean with regard to > an mpls interface). > > Even a reference would be helpful because the framework > documents talks about buffering as related to merge issues > so if this is what is meant, that is not clear from the > description. These objects are remnants from previous versions of the MIB. We propose to remove these. If there is no objection, these will be removed. >* mplsInterfacePerfEntry AUGMENTS the > mplsInterfaceConfEntry. More description was > supposed to be given as to counting for > Interfaces which participate in both the > perInterface and perPlatform situation. > > For example, you could count these things > twice (for the situation of the 0 index, > and for a perInteface non-zero ifIndex), or > you could count things once and only increment > one of the row's counters. mplsInterfaceInLabelsUsed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the specific number of labels that are in use at this point in time on this interface in the incoming direction. If the interface participates in the perPlatform label space only, then this instance of this object MUST be identical with the object instance with index 0. If the interface participates in the perInterface label space, then this instance of this object MUST only represent the number of per-interface labels that are in use at this point in time on this interface. " ::= { mplsInterfacePerfEntry 1 } mplsInterfaceFailedLabelLookup OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the number of labeled packets that have been received on this interface and were discarded because there were no matching entries found for them in mplsInSegmentTable. This value always MUST count on a per-interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 4 } mplsInterfaceOutLabelsUsed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of top-most labels in the outgoing label stacks that are in use at this point in time on this interface. This value always MUST count on a per-interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 5 } mplsInterfaceOutFragments OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the number of outgoing MPLS packets that required fragmentation before transmission on this interface. This value always MUST count on a per-interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 8 } >* mplsInSegment Table has no "IndexNext" object and > one was supposed to be added. We removed this object (based on comments from the list) because it did not make sense in the context of this table. >* individual trap/enable objects still appear glumped > together at the end of the MIB, these were supposed > to be distributed closer to their relevant objects. We chose to locate these objects close to the objects which they affected. >* MIB heirarchy -- there was supposed to be some > reorganization so that things would be grouped under > branches instead of everything appearing under mpslLsrObjects. We have followed the hierarchy used in other existing standard RFC MIBs (1604, 2515, 2496, ...). >Third Part (editorial) >====================== > >* Section 7. > > "The objects described in Sections 7.3-7.8, > when considered together, are equivalent to the tables described > in the MPLS architecture document [MPLSArch], that is, the > Incoming Label Map (ILM) and the Next Hop Label Forwarding Entry > (NHLFE) tables." > > there aren't any ILM or NHLFE tables, so this appears to be > an outdated reference. We specifically stated that objects _equivalent_ to the ILM or NHLFE tables exist in this MIB. The section numbers will be updated to 7.4-7.8. >* mplsLsrMIB MODULE-IDENTITY > DESCRIPTION > "This MIB contains managed object definitions for the > Multiprotocol Label Switching (MPLS) Router as > defined in: Rosen, E., Viswanathan, A., and R. > Callon, Multiprotocol Label Switching Architecture, > Internet Draft , > February 2000." > > * the date of the draft-ietf-mpls-arch-06.txt is > August 1999. We will fix this. >* Revision History is not in reverse chronological order and it > should be. Yes, this will be fixed. --Tom --=====================_1850515==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Joan,

First Part
===========

* MplsObjectOwner TC,

 'crldp' should definitely be added -- it appeared in early
         versions of the MIB, so must have been mistakenly removed.

        We thought that the 'ldp' option would cover it. We will
add 'cdldp' as requested as long as there are no objections.

 'unknown' appears here, it would seem that the agent
           would always know where the data to create a row
           originated from, so am wondering why this was added. 

        This option was chosen to present the agent with a
reasonable default value, as well as a choice if it did not
want to support this value.

  I still don't understand why other possibilities
  here such as config file, cli, web-interface, etc. were not
  added for completeness sake.

        The enumerations have always included 5 catagories:
management (snmp), the signaling protocols (ldp/rsvp),
provisioning (cops), unknown (a reasonable default or a choice
for agents which do not support this object) and other. We think
that the choices that you suggest fall under the "management"
category.


Second Part:
===========
* mplsInterfaceTotalBuffer and mplsInterfaceAvailableBuffer

  was expecting that more description for these objects
  would be given (what these values mean with regard to
  an mpls interface). 

  Even a reference would be helpful because the framework
  documents talks about buffering as related to merge issues
  so if this is what is meant, that is not clear from the
  description.

        These objects are remnants from previous versions
of the MIB. We propose to remove these. If there is no
objection, these will be removed.

* mplsInterfacePerfEntry AUGMENTS the
  mplsInterfaceConfEntry.  More description was
  supposed to be given as to counting for
  Interfaces which participate in both the
  perInterface and perPlatform situation.

  For example, you could count these things
  twice (for the situation of the 0 index,
  and for a perInteface non-zero ifIndex), or
  you could count things once and only increment
  one of the row's counters.


mplsInterfaceInLabelsUsed OBJECT-TYPE
   SYNTAX        Gauge32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This value indicates the specific number of labels
        that are in use at this point in time on this
        interface in the incoming direction. If the interface
          participates in the perPlatform label space only,
         then this instance of this object MUST be identical
         with the object instance with index 0. If the interface
         participates in the perInterface label space, then this
         instance of this object MUST only represent the number of
         per-interface labels that are in use at this point in
         time on this interface. "
   ::= { mplsInterfacePerfEntry 1 }

mplsInterfaceFailedLabelLookup OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This value indicates the number of labeled packets
        that have been received on this interface and were
        discarded because there were no matching entries
        found for them in mplsInSegmentTable. This value always
          MUST count on a per-interface basis regardless of which
        label space the interface participates in."
   ::= { mplsInterfacePerfEntry 4 }

mplsInterfaceOutLabelsUsed OBJECT-TYPE
   SYNTAX        Gauge32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "Indicates the number of top-most labels in the
        outgoing label stacks that are in use at this point
        in time on this interface. This value always
          MUST count on a per-interface basis regardless of
         which label space the interface participates in."
   ::= { mplsInterfacePerfEntry 5 }

mplsInterfaceOutFragments OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This variable indicates the number of outgoing MPLS
        packets that required fragmentation before
        transmission on this interface. This value always
          MUST count on a per-interface basis regardless of which
        label space the interface participates in."
::= { mplsInterfacePerfEntry 8 }
                        

* mplsInSegment Table has no "IndexNext" object and
  one was supposed to be added.

        We removed this object (based on comments from the list)
because it did not make sense in the context of this table.

* individual trap/enable objects still appear glumped
  together at the end of the MIB, these were supposed
  to be distributed closer to their relevant objects.

        We chose to locate these objects close to the
objects which they affected.

* MIB heirarchy -- there was supposed to be some
  reorganization so that things would be grouped under
  branches instead of everything appearing under mpslLsrObjects.

        We have followed the hierarchy used in other existing
standard RFC MIBs (1604, 2515, 2496, ...).


Third Part (editorial)
======================

* Section 7.

   "The objects described in Sections 7.3-7.8,
   when considered together, are equivalent to the tables described
   in the MPLS architecture document [MPLSArch], that is, the
   Incoming Label Map (ILM) and the Next Hop Label Forwarding Entry
   (NHLFE) tables." 

   there aren't any ILM or NHLFE tables, so this appears to be
   an outdated reference.

        We specifically stated that objects _equivalent_ to the
ILM or NHLFE tables exist in this MIB. The section numbers
will be updated to 7.4-7.8.

*  mplsLsrMIB MODULE-IDENTITY
   DESCRIPTION
       "This MIB contains managed object definitions for the
        Multiprotocol Label Switching (MPLS) Router as
        defined in: Rosen, E., Viswanathan, A., and R.
        Callon, Multiprotocol Label Switching Architecture,
        Internet Draft <draft-ietf-mpls-arch-06.txt>,
        February 2000."

   * the date of the draft-ietf-mpls-arch-06.txt is
     August 1999.

        We will fix this.

* Revision History is not in reverse chronological order and it
  should be.

        Yes, this will be fixed.


        --Tom


--=====================_1850515==_.ALT-- From owner-mpls@UU.NET Thu May 11 17:40: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 ESMTP id RAA08631 for ; Thu, 11 May 2000 17:40: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 QQiotq01492; Thu, 11 May 2000 21:39:35 GMT Received: by mail-control.mail.uu.net id QQiotq02624 for mpls-outgoing; Thu, 11 May 2000 21:39: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 QQiotq02617 for ; Thu, 11 May 2000 21:39: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 QQiotq16639 for ; Thu, 11 May 2000 17:39:03 -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 QQiotq00253 for ; Thu, 11 May 2000 21:39:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA18555 for mpls@uu.net; Thu, 11 May 2000 17:39:01 -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 QQiotq02600 for ; Thu, 11 May 2000 21:38: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 QQiotq01731 for ; Thu, 11 May 2000 17:38:01 -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 QQiotq10878 for ; Thu, 11 May 2000 21:38:00 GMT Received: from tnadeau-pc02 (ch2-dhcp134-234.cisco.com [161.44.134.234]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20586; Thu, 11 May 2000 17:37:20 -0400 (EDT) Message-Id: <4.2.2.20000511173239.03e07c80@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 11 May 2000 17:37:18 -0400 To: "Mancour, Tim" , cheenu Srinivasan , arun@force10networks.com, mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: Removal of oper/adminStatus for LSR MIB in/out segments In-Reply-To: <6B190B34070BD411ACA000B0D0214E5609EC2D@newman.tenornet.com > Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2362180==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_2362180==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Tim, >I fully support removing the adminStatus, and associated notifications and >notification controls for both the in-segment and out-segment. > >In the following cases, however, the segment's operStatus will not simply >reflect the operStatus of the underlying interface: > 1. The segment's rowStatus is set to notInService. > 2. The underlying interface for an out-segment is missing. An inSegmentEntry in the active state simply represents an installed label. It has nothing to do with the underlying interface per se. What you are asking for is done by the XC's operStatus. > 3. An in-segment whose label is out-of-range. The agent should reject such a SET request (the label should never be installed). --Tom --=====================_2362180==_.ALT Content-Type: text/html; charset="us-ascii"

        Hi Tim,

I fully support removing the adminStatus, and associated notifications and
notification controls for both the in-segment and out-segment.

In the following cases, however, the segment's operStatus will not simply
reflect the operStatus of the underlying interface:
        1. The segment's rowStatus is set to notInService.
        2. The underlying interface for an out-segment is missing.

        An inSegmentEntry in the active state simply represents an
installed label. It has nothing to do with the underlying interface
per se. What you are asking for is done by the XC's operStatus.

        3. An in-segment whose label is out-of-range.

        The agent should reject such a SET request (the label
should never be installed).

        --Tom

--=====================_2362180==_.ALT-- From owner-mpls@UU.NET Thu May 11 18:31: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 ESMTP id SAA09395 for ; Thu, 11 May 2000 18:31: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 QQiotu16070; Thu, 11 May 2000 22:30:48 GMT Received: by mail-control.mail.uu.net id QQiotu14191 for mpls-outgoing; Thu, 11 May 2000 22:30:11 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 QQiotu14186 for ; Thu, 11 May 2000 22:30:01 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 QQiott22786 for ; Thu, 11 May 2000 18:29:57 -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 QQiott15360 for ; Thu, 11 May 2000 22:29:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA24291 for mpls@uu.net; Thu, 11 May 2000 18:29:56 -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 QQiott14150 for ; Thu, 11 May 2000 22:29: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 QQiott22616 for ; Thu, 11 May 2000 18:29:12 -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 QQiott14791 for ; Thu, 11 May 2000 22:29:12 GMT Received: from tnadeau-pc02 (ch2-dhcp134-234.cisco.com [161.44.134.234]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA28643; Thu, 11 May 2000 18:29:08 -0400 (EDT) Message-Id: <4.2.2.20000511175324.03e11b10@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 11 May 2000 18:29:06 -0400 To: "Steven Wright" , From: "Thomas D. Nadeau" Subject: Re: Cc: cheenu Srinivasan , arun@force10networks.com In-Reply-To: <000c01bfb9ad$62d06ad0$46d61e5a@gf5142_gxsmlg.bst.bls.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5470686==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_5470686==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, >1. You mention in the motivation section (4) that there are other >classification processes ( diffserv comes to mind ). Are there existing MIBs >(e.g. Diffserv) that this document should be compared against? or is this >intended to be a common document for a variety of technologies ? >2. The packet header tuple used for classification here seems to be missing >a few items that might be useful e.g classifications based on: >-packet size ( for some QoS applications ) >-ToS Bits / DSCP ( for MPLS /Diffserv interoperation ) >3. There are some other bases for classification that are not based on the >packet header, but on other information that may be available in the >router - e.g. the source interface, MTU size, traffic >marking/measurement/policing metrics etc. We intended this MIB to specifically address the FTN functionality for MPLS. There does exist a DiffServ Packet Classifier MIB, which does not however, address the FTN requirements for MPLS. In particular, the DiffServ MIB does not allow for the forwarding of packets onto LSPs or Tunnels. We do however, welcome comments and suggestions on our draft. >4. I'd like some more background on the options available under >mplsMplsPacketClassifierActionMask. I'm not sure of the difference between >redirect(2) and redirectLsp (3). First, it is clear that the BITS defined need more clarification in their DESCRIPTION clause. SYNTAX BITS { drop(0), pass(1), redirect(2), redirectLsp(3), settos(4), assignTSpec(5) } Second, the intent for redirect was to allow forwarding onto a regular interface. The redirectLsp(3) was intended to allow for the forwarding of packets onto LSPs. We intend to delete drop(0), settos(4), assignTSpec(5) and redirect(2). We also indent to add redirectTunnel to allow for the fowarding of packets onto MPLS Tunnels. Also, we would like to point out that the current version was a re-posting of an earlier failed posting before the Adelaide, SA meeting. We will be reissuing this draft shortly to align it more closely with our goals of being very specific to MPLS FTNs as well as to include comments from the WG. --Tom --=====================_5470686==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

1. You mention in the motivation section (4) that there are other
classification processes ( diffserv comes to mind ). Are there existing MIBs
(e.g. Diffserv) that this document should be compared against? or is this
intended to be a common document for a variety of technologies ?
2. The packet header tuple used for classification here seems to be missing
a few items that might be useful e.g classifications based on:
-packet size ( for some QoS applications )
-ToS Bits / DSCP ( for MPLS /Diffserv interoperation )
3. There are some other bases for classification that are not based on the
packet header, but on other information that may be available in the
router - e.g. the source interface, MTU size, traffic
marking/measurement/policing metrics etc.

        We intended this MIB to specifically address the
FTN functionality for MPLS. There does exist a DiffServ Packet
Classifier MIB, which does not however, address the FTN
requirements for MPLS.  In particular, the DiffServ MIB does
not allow for the forwarding of packets onto LSPs or Tunnels.
We do however, welcome comments and suggestions on our draft.

4. I'd like some more background on the options available under
mplsMplsPacketClassifierActionMask. I'm not sure of the difference between
redirect(2) and redirectLsp (3).

        First, it is clear that the BITS defined need more clarification
in their DESCRIPTION clause.

   SYNTAX          BITS {
                  drop(0),
                  pass(1),
                  redirect(2),
                  redirectLsp(3),
                  settos(4),
                  assignTSpec(5)
                }

        Second, the intent for redirect was to allow forwarding
onto a regular interface. The redirectLsp(3) was intended to
allow for the forwarding of packets onto LSPs. We intend to
delete drop(0), settos(4), assignTSpec(5) and redirect(2). We
also indent to add redirectTunnel to allow for the fowarding
of packets onto MPLS Tunnels.

        Also, we would like to point out that the current
version was a re-posting of an earlier failed posting
before the Adelaide, SA meeting. We will be reissuing this
draft shortly to align it more closely with our goals of
being very specific to MPLS FTNs as well as to include
comments from the WG.

        --Tom

--=====================_5470686==_.ALT-- From owner-mpls@UU.NET Fri May 12 00:03: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 AAA15926 for ; Fri, 12 May 2000 00:03: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 QQiouq21480; Fri, 12 May 2000 04:03:05 GMT Received: by mail-control.mail.uu.net id QQiouq22631 for mpls-outgoing; Fri, 12 May 2000 04:02: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 QQiouq22519 for ; Fri, 12 May 2000 04:02: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 QQiouq26872 for ; Fri, 12 May 2000 00:02: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 QQiouq20809 for ; Fri, 12 May 2000 04:01:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA15593 for mpls@uu.net; Fri, 12 May 2000 00:01:59 -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 QQiolt00321 for ; Tue, 9 May 2000 18:29: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 QQiolt06728 for ; Tue, 9 May 2000 14:29:20 -0400 (EDT) Received: from tnnt3.tachion.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQiolt00295 for ; Tue, 9 May 2000 18:29:15 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Tue, 9 May 2000 14:31:15 -0400 Message-ID: From: Cheenu Srinivasan To: "'Thomas D. Nadeau'" , manikantan , "'arun@force10networks.com'" , Cheenu Srinivasan Cc: "'mpls@uu.net'" Subject: RE: LSR MIB last call comments Date: Tue, 9 May 2000 14:31:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB9E4.C19BDC84" 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_01BFB9E4.C19BDC84 Content-Type: text/plain; charset="iso-8859-1" > There are actually two different ifTypes, one an > LSP and one for a tunnel interface, both of which have Tom made a typo - the two ifTypes are one for the MPLS layer (166) and one for those MPLS tunnels that are to be represented as interfaces (150). Cheenu > different and distinct ifType numbers (166, 150). We will > add some descriptive text in the next version of the TE MIB > to illustrate more clearly the fact that a tunnel may or may > not be an interface. > > --Tom > > > >My doubt is the interface type being "mpls" and "mplsTunnel" > different? > >if so can this be explained. > > > >If these are same then the values in the two MIBs are to be synced. > > > >thanks in advance > >with best regards > >mani > ------_=_NextPart_001_01BFB9E4.C19BDC84 Content-Type: text/html; charset="iso-8859-1" RE: LSR MIB last call comments

 
>          There are actually two different ifTypes, one an
> LSP and one for a tunnel interface, both of which have

Tom made a typo - the two ifTypes are one for the MPLS layer (166)
and one for those MPLS tunnels that are to be represented as
interfaces (150).

Cheenu

> different and distinct ifType numbers (166, 150). We will
> add some descriptive text in the next version of the TE MIB
> to illustrate more clearly the fact that a tunnel may or may
> not be an interface.
>
>          --Tom
>
>
> >My doubt is the interface type being "mpls" and "mplsTunnel"
> different?
> >if so can this be explained.
> >
> >If these are same then the values in the two MIBs are to be synced.
> >
> >thanks in advance
> >with best regards
> >mani
>

------_=_NextPart_001_01BFB9E4.C19BDC84-- From owner-mpls@UU.NET Fri May 12 11:13: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 LAA03821 for ; Fri, 12 May 2000 11:13: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 QQiowi28221; Fri, 12 May 2000 15:12:48 GMT Received: by mail-control.mail.uu.net id QQiowi07496 for mpls-outgoing; Fri, 12 May 2000 15:12:29 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiowi07490 for ; Fri, 12 May 2000 15:12:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiowi08277 for ; Fri, 12 May 2000 11:12: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 QQiowi07210 for ; Fri, 12 May 2000 15:12:04 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA02032 for mpls@uu.net; Fri, 12 May 2000 11:12:03 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiowi07381 for ; Fri, 12 May 2000 15:11:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiowi08151 for ; Fri, 12 May 2000 11:11:17 -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 QQiowi26986 for ; Fri, 12 May 2000 15:11:16 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA23757; Fri, 12 May 2000 08:11:09 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 08:11:09 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4055B@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , mpls@UU.NET Subject: MPLS header compression Date: Fri, 12 May 2000 08:08:19 -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 George, Do you have any paper on you MPLS header compression proposal? Thanks, -Shahram From owner-mpls@UU.NET Fri May 12 13:36: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 NAA08132 for ; Fri, 12 May 2000 13:36: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 QQiows05057; Fri, 12 May 2000 17:35:25 GMT Received: by mail-control.mail.uu.net id QQiows04551 for mpls-outgoing; Fri, 12 May 2000 17:34: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 QQiows04544 for ; Fri, 12 May 2000 17:34: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 QQiows23753 for ; Fri, 12 May 2000 13:34:33 -0400 (EDT) Received: from cis.ohio-state.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cis.ohio-state.edu [164.107.115.5]) id QQiows14426 for ; Fri, 12 May 2000 17:34:33 GMT Received: from theta.cis.ohio-state.edu (chandhok@theta.cis.ohio-state.edu [164.107.112.63]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id NAA21513 for ; Fri, 12 May 2000 13:34:33 -0400 (EDT) Received: from localhost (chandhok@localhost) by theta.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id NAA00184 for ; Fri, 12 May 2000 13:34:32 -0400 (EDT) X-Authentication-Warning: theta.cis.ohio-state.edu: chandhok owned process doing -bs Date: Fri, 12 May 2000 13:34:32 -0400 (EDT) From: Nikhil Chandhok To: mpls@UU.NET Subject: IP over Optical Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi , I am new to this mailing list . I would just like to enquire if the IP over Optical working group got formed in the 47th IETF meeting or is the IP over Optical discussion is being continued on this mailing list ? Thank you , Nikhil Chandhok From owner-mpls@UU.NET Sat May 13 06:59: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 GAA07598 for ; Sat, 13 May 2000 06:59: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 QQiozj20519; Sat, 13 May 2000 10:59:03 GMT Received: by mail-control.mail.uu.net id QQiozj26705 for mpls-outgoing; Sat, 13 May 2000 10:58:47 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiozj26700 for ; Sat, 13 May 2000 10:58:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiozj21427 for ; Sat, 13 May 2000 06:58:13 -0400 (EDT) Received: from sepahan.iut.ac.ir by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sepahan.iut.ac.ir [194.165.10.30]) id QQiozj26386 for ; Sat, 13 May 2000 10:58:09 GMT Received: from localhost (s7627237@localhost) by sepahan.iut.ac.ir (8.9.3/8.9.3) with ESMTP id PAA25774 for ; Sat, 13 May 2000 15:27:26 +0430 Date: Sat, 13 May 2000 15:27:26 +0430 (IRST) From: Manshaee Mohammad-Hossein To: mpls@UU.NET Subject: A question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Many documents that I found in the (www.ietf.cnri.reston.va.us) has a label "Expire March 2000" Are there any news? I can't pay attention to them!!!?? Are they old! Somebody help me! Best regards, MH Manshaei From owner-mpls@UU.NET Sat May 13 08:44: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 IAA08244 for ; Sat, 13 May 2000 08:44: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 QQiozq14703; Sat, 13 May 2000 12:43:16 GMT Received: by mail-control.mail.uu.net id QQiozq20724 for mpls-outgoing; Sat, 13 May 2000 12:42:46 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 QQiozq20717 for ; Sat, 13 May 2000 12:42: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 QQiozq07989 for ; Sat, 13 May 2000 08:42:14 -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 QQiozq14017 for ; Sat, 13 May 2000 12:42:11 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sat, 13 May 2000 18:22:50 +0530 Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id SAA20395 for ; Sat, 13 May 2000 18:00:13 +0530 Received: by localhost with Microsoft MAPI; Sat, 13 May 2000 18:06:53 +0530 Message-Id: <01BFBD06.04B9C480.manis@future.futsoft.com> From: manikantan To: "'mpls@uu.net'" Subject: MPLS Traffic Engineering MIB - draft-ietf-mpls-te-mib-03.txt Date: Sat, 13 May 2000 18:06:52 +0530 Importance: high X-Priority: 1 (Highest) 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 Hello I have a doubt and some comments in the MPLS Traffic Engineering MIB. draft-ietf-mpls-te-mib-03.txt Can some one clarify me. thanks in advance. I am sorry if the comments mentioned in this mail had already been indicated. Doubt: mplsTunnelOperStatus: When will this field get a value "up"? My understanding is that after the Tunnel is created using the mplsTunnelRowStatus object and the Admin Status is set to up, the LSP establishments will be initiated. i.e., either RSVP Path message will be sent down or CRLSP label request message will be sent to the next hop. My question is will the mplsTunnelOperStatus be marked/set to "up" after the successful reception of the Resv message or Lbl Mapping message? Comments: 1) In the Tunnel setup example provided in page 12 reproduced below for reference: In mplsTunnelHopTable: { mplsTunnelHopIndex = 1, mplsTunnelHopAddrType = 1, mplsTunnelHopIpv4Addr = 123.123.125.1, mplsTunnelHopIpv4PrefixLen = 9, mplsTunnelHopStrictOrLoose = loose (2), mplsTunnelHopRowStatus = createAndGo (4) } The following denotes the end of the network, or the last hop in our example. We have used the fictitious LSR identified by "123.123.126.1" as our end router. In mplsTunnelHopTable: { mplsTunnelHopIndex = 2, mplsTunnelHopAddrType = 1, mplsTunnelHopIpv4Addr = 123.123.126.1, mplsTunnelHopIpv4PrefixLen = 9, mplsTunnelHopStrictOrLoose = loose (2), mplsTunnelHopOwner = snmp (1), mplsTunnelHopRowStatus = createAndGo (4) } My questions are a) The mplsTunnelHopIpv4Prefix Len has been set to 9 in both cases. The resultant network will be 123.0.0.0 in both cases and there results no difference in the ER Hop. Am I correct or missing something. b) The example includes mplsTunnelHopOwner, This does not exist in this draft. Does this needs to be removed? 2) In the Description of the mplsTunnelSessionAttributes object in Page 28, the first para starts with "fastReroute". should this be "ingressMayReroute"? 3) A minor typo in the first line of page 29. "det4ected" should be made "detected" thanks in advance with best regards mani /*-------------------------------------------------------------------*/ S.Manikantan Future Software Private Limited 480-481, Anna salai, Nandanam, Chennai, Tamil Nadu, 600 035, India. Phone : +91-44-4330550 Fax : +91-44-4344157. Email : manis@future.futsoft.com http://www.futsoft.com /*--------------------------------------------------------------------*/ From owner-mpls@UU.NET Mon May 15 03:28: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 DAA29024 for ; Mon, 15 May 2000 03:28: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 QQipgf25164; Mon, 15 May 2000 07:27:32 GMT Received: by mail-control.mail.uu.net id QQipgf10995 for mpls-outgoing; Mon, 15 May 2000 07:27:11 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipgf10990 for ; Mon, 15 May 2000 07:27:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipgf23776 for ; Mon, 15 May 2000 03:26:59 -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 QQipgf24738 for ; Mon, 15 May 2000 07:26:51 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 15 May 2000 13:07:13 +0530 Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA26665 for ; Mon, 15 May 2000 12:44:36 +0530 Received: by localhost with Microsoft MAPI; Mon, 15 May 2000 12:51:33 +0530 Message-Id: <01BFBE6C.4C0366E0.manis@future.futsoft.com> From: manikantan To: "'mpls@uu.net'" Subject: MPLS TE MIB - Doubts Date: Mon, 15 May 2000 12:51:31 +0530 Importance: high X-Priority: 1 (Highest) 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 Hello I have some doubts and I would really appreciate if some one can help me in this. 1) Local Cookie, Remote Cookie. - How do I get this value, Do I get this value by concatenating a) Extended Tunnel Id and Tunnel ID field values in case of RSVP path messages? b) Ingress LSR Router ID and Local CRLS- Id in case of CRLDP Lbl Req messages? 2) What is the significant difference between the MIB objects "mplsTunnelOwner" and "mplsTunnelSignallingProto"? and how are these fields to be used? a) If the field "mplsTunnelOwner" is set to snmp(1) and the "mplsTunnel SignallingProto" is set to "ldp" / "rsvp", does this mean once the row status is made up, the tunnel must be established using CRLDP or RSVP respectively? b) If the filed "mplsTunnelOwner" indicates "ldp" or "rsvp" does it mean that the tunnel is dynamically established using IGP (routing info) information? If so will the "mplsTunnelSignallingProto" have value "ldp" or "rsvp" respectively? thanks in advance with best regards mani /*-------------------------------------------------------------------*/ S.Manikantan Future Software Private Limited 480-481, Anna salai, Nandanam, Chennai, Tamil Nadu, 600 035, India. Phone : +91-44-4330550 Fax : +91-44-4344157. Email : manis@future.futsoft.com http://www.futsoft.com /*--------------------------------------------------------------------*/ From owner-mpls@UU.NET Mon May 15 06:37:12 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 GAA00421 for ; Mon, 15 May 2000 06:37:12 -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 QQipgs06286; Mon, 15 May 2000 10:35:03 GMT Received: by mail-control.mail.uu.net id QQipgs16534 for mpls-outgoing; Mon, 15 May 2000 10:34:32 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 QQipgs16527 for ; Mon, 15 May 2000 10:34: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 QQipgs00796 for ; Mon, 15 May 2000 06:34:17 -0400 (EDT) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQipgs03346 for ; Mon, 15 May 2000 10:34:16 GMT Received: by smtp2.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 15 May 2000 11:34:04 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1409E5@monk.datcon.co.uk> From: Adrian Farrel To: manikantan , "'mpls@uu.net'" Subject: RE: MPLS Traffic Engineering MIB - draft-ietf-mpls-te-mib-03.txt Date: Mon, 15 May 2000 11:33: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 Hi Mani, I'm sure Tom will want to jump in, but here are a couple of answers to be going on with. >Hello > >I have a doubt and some comments in the MPLS Traffic Engineering MIB. >draft-ietf-mpls-te-mib-03.txt > >Can some one clarify me. > >thanks in advance. > >I am sorry if the comments mentioned in this mail had already >been indicated. > >Doubt: mplsTunnelOperStatus: When will this field get a value "up"? > >My understanding is that after the Tunnel is created using the >mplsTunnelRowStatus object and the Admin Status is set to up, >the LSP establishments will be initiated. i.e., either RSVP Path >message will be sent down or CRLSP label request message will >be sent to the next hop. > >My question is will the mplsTunnelOperStatus be marked/set >to "up" after the successful reception of the Resv message or >Lbl Mapping message? This would appear to be the intention. It is generally the purpose of operStatus to indicate the operational status of the resource described by the MIB row. In this case, signaling would be complete and all of the cross-connects would be programmed before operStatus showed 'up'. > >Comments: >1) In the Tunnel setup example provided in page 12 reproduced >below for reference: > > In mplsTunnelHopTable: > { > mplsTunnelHopIndex = 1, > mplsTunnelHopAddrType = 1, > mplsTunnelHopIpv4Addr = 123.123.125.1, > mplsTunnelHopIpv4PrefixLen = 9, > mplsTunnelHopStrictOrLoose = loose (2), > mplsTunnelHopRowStatus = createAndGo (4) > } > > The following denotes the end of the network, or the > last hop in our example. We have used the fictitious > LSR identified by "123.123.126.1" as our end router. > > In mplsTunnelHopTable: > { > mplsTunnelHopIndex = 2, > mplsTunnelHopAddrType = 1, > mplsTunnelHopIpv4Addr = 123.123.126.1, > mplsTunnelHopIpv4PrefixLen = 9, > mplsTunnelHopStrictOrLoose = loose (2), > mplsTunnelHopOwner = snmp (1), > mplsTunnelHopRowStatus = createAndGo (4) > } >My questions are > a) The mplsTunnelHopIpv4Prefix Len has been set to 9 in > both cases. The resultant network will be 123.0.0.0 in > both cases and there results no difference in the ER Hop. > Am I correct or missing something. Yes. The example is not helpful. In use, the second hop would be stripped from the explicit route when the Path/Label_Request reached an LSR satisfying the first hop. > b) The example includes mplsTunnelHopOwner, This does not > exist in this draft. Does this needs to be removed? Unclear what the authors were trying to do here. This function should probably be provided totally by mplsTunnelOwner, although there is scope for distinguishing configured hops from those determined through routing in a pinned ER. >2) In the Description of the mplsTunnelSessionAttributes object > in Page 28, the first para starts with "fastReroute". > should this be "ingressMayReroute"? Yes. See my email of 20th March. >3) A minor typo in the first line of page 29. "det4ected" > should be made "detected" ditto. 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 From owner-mpls@UU.NET Mon May 15 06:54: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 GAA00629 for ; Mon, 15 May 2000 06:54: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 QQipgt16778; Mon, 15 May 2000 10:53:04 GMT Received: by mail-control.mail.uu.net id QQipgt17608 for mpls-outgoing; Mon, 15 May 2000 10: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 QQipgt17599 for ; Mon, 15 May 2000 10:52:34 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 QQipgt02196 for ; Mon, 15 May 2000 06:52:32 -0400 (EDT) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQipgt13248 for ; Mon, 15 May 2000 10:52:32 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 15 May 2000 11:52:20 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1409EB@monk.datcon.co.uk> From: Adrian Farrel To: manikantan , "'mpls@uu.net'" Subject: RE: MPLS TE MIB - Doubts Date: Mon, 15 May 2000 11:52:15 +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 Mani (again), I'm sure Tom will want to comment again. >1) Local Cookie, Remote Cookie. - How do I get this value, Do >I get this value by concatenating > a) Extended Tunnel Id and Tunnel ID field values in case of > RSVP path messages? > b) Ingress LSR Router ID and Local CRLS- Id in case of > CRLDP Lbl Req messages? Yes, the issues are - how to "piggyback" the cookie on signaling so that the remote end can re-assemble it - what to do for CR-LSP This is fundamentally an interop issue. Both of your recommendations seem good to me. >2) What is the significant difference between the MIB objects >"mplsTunnelOwner" and "mplsTunnelSignallingProto"? and how are >these fields to be used? > > a) If the field "mplsTunnelOwner" is set to snmp(1) and the > "mplsTunnel SignallingProto" is set to "ldp" / "rsvp", > does this mean once the row status is made up, the tunnel > must be established using CRLDP or RSVP respectively? That is my interpretation (except I would say once rowStatus and adminStatus are made 'up'). 'none' denotes that the tunnel is statically configured through the LSR MIB at each hop and should not be signaled. I think we should consider a new value of 'any' to allow the MPLS code to choose a route through RSVP, CR-LDP or whatever based on its own routing tables. > b) If the filed "mplsTunnelOwner" indicates "ldp" or "rsvp" > does it mean that the tunnel is dynamically established > using IGP (routing info) information? If so will the > "mplsTunnelSignallingProto" have value "ldp" or "rsvp" > respectively? I interpreted these settings of mplsTunnelOwner to refer to egress tunnels. In this case mplsTunnelSignallingProto is somewhat redundant. 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 From owner-mpls@UU.NET Mon May 15 10:18: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 ESMTP id KAA04545 for ; Mon, 15 May 2000 10:18: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 QQiphg17315; Mon, 15 May 2000 14:10:35 GMT Received: by mail-control.mail.uu.net id QQiphg06020 for mpls-outgoing; Mon, 15 May 2000 14:10: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 QQiphg05980 for ; Mon, 15 May 2000 14:09:49 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 QQiphg26538 for ; Mon, 15 May 2000 10:09:45 -0400 (EDT) Received: from atwav002.atlanta.concert.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [12.6.145.17]) id QQiphg16565 for ; Mon, 15 May 2000 14:09:45 GMT Received: from ataexconn01.atlanta.concert.com (unverified) by atwav002.atlanta.concert.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 15 May 2000 10:03:49 -0400 Received: by ataexconn01.atlanta.concert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 May 2000 10:03:59 -0400 Message-Id: From: "Nelson, Jim (CRTATL)" To: "'George Swallow'" Cc: "'Shahram Davari'" , mpls@UU.NET Subject: RE: MPLS header compression Date: Mon, 15 May 2000 10:03:52 -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 George, A couple of us extensively searched IETF, including individual submissions, unsuccessfully for your draft (draft-swallow-mpls-simple-hdr-compress-00.txt). Any help would be appreciated ! Regards, Jim James W (Jim) Nelson Concert Strategic Network Architecture and Technology jim.nelson@concert.com 1+ 770 333 4863 -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Friday, May 12, 2000 11:08 AM To: 'George Swallow'; mpls@UU.NET Subject: MPLS header compression Hi George, Do you have any paper on you MPLS header compression proposal? Thanks, -Shahram ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by Antigen for the presence of computer viruses. http://www.concert.com ********************************************************************** From owner-mpls@UU.NET Mon May 15 10:40: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 ESMTP id KAA04879 for ; Mon, 15 May 2000 10:40: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 QQiphi13008; Mon, 15 May 2000 14:38:45 GMT Received: by mail-control.mail.uu.net id QQiphi07963 for mpls-outgoing; Mon, 15 May 2000 14:38:13 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiphi07958 for ; Mon, 15 May 2000 14:38:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiphi03655 for ; Mon, 15 May 2000 10:38:01 -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 QQiphi12311 for ; Mon, 15 May 2000 14:37:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA03644 for mpls@uu.net; Mon, 15 May 2000 10:37:58 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiphi07926 for ; Mon, 15 May 2000 14:37:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiphi03580 for ; Mon, 15 May 2000 10:37:14 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiphi11807 for ; Mon, 15 May 2000 14:37:14 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 May 2000 10:37:13 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEAD0@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Kullberg, Alan'" , "'mpls@UU.NET'" Subject: RE: Second WG last call on LSR MIB Date: Mon, 15 May 2000 10:37:13 -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 Alan, You make a good point here. Probably the right thing to do would be to make this object optional such that if the LSP is created as a result of LDP or management then the object is not supported (because it cannot be). Otherwise, if it is created by a protocol which support LSPIds (such as crldp, or rsvp) then this object has meaning. A description could be tied to the description of the Owner object in the row. I don't understand why the LSP ID currently varies in size from 0..31 octets. Could an LSP ID be 1 or 2 octets? -Joan > -----Original Message----- > From: Kullberg, Alan [mailto:akullber@hjinc.com] > Sent: Wednesday, May 10, 2000 2:54 PM > To: 'mpls@UU.NET' > Subject: RE: Second WG last call on LSR MIB > > > The MplsLSPID is described as "This value is piggybacked > by the signaling protocol when the LSP is signaled within > the network." However, this is only true for CR-LDP and > RSVP, since LDP does not have any TLV containing the LSPID > to pass along. > > The question is what value should we have for the mplsXCLspId > object for a LDP LSP ? > > Alan > From owner-mpls@UU.NET Mon May 15 10:49:22 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 KAA05003 for ; Mon, 15 May 2000 10:49: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 QQiphj15441; Mon, 15 May 2000 14:48:14 GMT Received: by mail-control.mail.uu.net id QQiphj08880 for mpls-outgoing; Mon, 15 May 2000 14:47: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 QQiphj08869 for ; Mon, 15 May 2000 14:47:50 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 QQiphj02934 for ; Mon, 15 May 2000 10:47:40 -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 QQiphj14898 for ; Mon, 15 May 2000 14:47:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA05247 for mpls@uu.net; Mon, 15 May 2000 10:47:38 -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 QQiphj08844 for ; Mon, 15 May 2000 14:47: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 QQiphj02857 for ; Mon, 15 May 2000 10:47:06 -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 QQiphj14431 for ; Mon, 15 May 2000 14:47:05 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 KAA04652; Mon, 15 May 2000 10:47:04 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA09040; Mon, 15 May 2000 10:47:03 -0400 (EDT) Message-Id: <200005151447.KAA09040@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Nelson, Jim (CRTATL)" cc: "'George Swallow'" , "'Shahram Davari'" , mpls@UU.NET, swallow@cisco.com Subject: Re: MPLS header compression In-reply-to: Your message of "Mon, 15 May 2000 10:03:52 EDT." Date: Mon, 15 May 2000 10:47:03 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Jim - Try - http://www.ietf.org/internet-drafts/draft-swallow-mpls-simple-hdr-compress-00.txt the problem is that it was put in with some blanks in the URL. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon May 15 10:52: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 KAA05025 for ; Mon, 15 May 2000 10:52: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 QQiphj22954; Mon, 15 May 2000 14:51:04 GMT Received: by mail-control.mail.uu.net id QQiphj09003 for mpls-outgoing; Mon, 15 May 2000 14:50:50 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 QQiphj08995 for ; Mon, 15 May 2000 14:50: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 QQiphj03460 for ; Mon, 15 May 2000 10:50: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 QQiphj17482 for ; Mon, 15 May 2000 14:50:31 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id JAA12828; Mon, 15 May 2000 09:50:18 -0500 Message-Id: <4.3.1.2.20000515104721.00b7aef0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 15 May 2000 10:50:31 -0400 To: "Nelson, Jim (CRTATL)" From: Lou Berger Subject: RE: MPLS header compression Cc: "'George Swallow'" , "'Shahram Davari'" , mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk see: http://www.ietf.org/internet-drafts/draft-swallow-mpls-simple-hdr-compress-00.txt and http://www.ietf.org/internet-drafts/draft-berger-mpls-hdr-comp-00.txt These drafts address different problem spaces... Lou At 10:03 AM 5/15/00 -0400, Nelson, Jim (CRTATL) wrote: >George, > >A couple of us extensively searched IETF, including individual submissions, >unsuccessfully for your draft >(draft-swallow-mpls-simple-hdr-compress-00.txt). Any help would be >appreciated ! > >Regards, >Jim > >James W (Jim) Nelson >Concert Strategic Network Architecture and Technology >jim.nelson@concert.com >1+ 770 333 4863 > > >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Friday, May 12, 2000 11:08 AM >To: 'George Swallow'; mpls@UU.NET >Subject: MPLS header compression > > >Hi George, > >Do you have any paper on you MPLS header compression proposal? > >Thanks, >-Shahram >********************************************************************** >This email and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they >are addressed. If you have received this email in error please notify >the system manager. > >This footnote also confirms that this email message has been swept by >Antigen for the presence of computer viruses. > >http://www.concert.com >********************************************************************** From owner-mpls@UU.NET Mon May 15 22:16: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 WAA14011 for ; Mon, 15 May 2000 22:16: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 QQipjd22576; Tue, 16 May 2000 02:15:24 GMT Received: by mail-control.mail.uu.net id QQipjd12085 for mpls-outgoing; Tue, 16 May 2000 02:15: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 QQipjd11990 for ; Tue, 16 May 2000 02:15:01 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 QQipjc07888 for ; Mon, 15 May 2000 22:14:58 -0400 (EDT) Received: from turin.trillium.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: turin.trillium.com [206.216.108.218]) id QQipjc21854 for ; Tue, 16 May 2000 02:14:57 GMT Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Mon, 15 May 2000 19:26:05 -0700 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 TAA21423 for ; Mon, 15 May 2000 19:14:48 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Mon, 15 May 2000 19:14:48 -0700 Message-ID: <8BBD33A986C5D311804000902719FF5D342237@aega.trillium.com> From: Prem Shankar Sharma To: "'mpls@uu.net'" Cc: Prem Shankar Sharma Subject: DU mode:Label Advt. Date: Mon, 15 May 2000 19:14:47 -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, It seems there is some difference in the opinion about the broadcast the labels to the neighbours in the DU mode. (Please have a look at the following mails). Please clarify!!! Regards. Prem <1st Mail> Question about interfacing Routing and LDP in MPLS systems? From: Eric Gray Date: Fri, 10 Dec 1999 07:57:10 -0500 CC: Zhong Hu , mpls@UU.NET References: <6342F12F9359D311990B009027A1B9B603E783@monterey.pluris.com> X-Accept-Language: en ... In the DU mode, it's quite a bit simpler. Any time such an implementation derives a new route table entry, it sends a Label Mapping to all but the next hop for that route entry. ... <2nd Mail> Sending mapping for REC-NEW-FEC From: Bob Thomas Date: Thu, 27 Jan 2000 06:31:53 -0500 cc: mpls@UU.NET In-reply-to: Your message of "Thu, 27 Jan 2000 09:33:10 +0530." <200001270356.JAA24637@blaze.hcltech.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs Sree, ... > In the Recognise New FEC in the Label Distribution Procedures in > ldp-06.txt (Appendix A.1.6), according to FEC.1, for downstream > unsolicited independent control, for each peer we are supposed to > send a label mapping. No distinction is made for the next hop. Are > we supposed to send it to the next hop also ? Yes. Bob From owner-mpls@UU.NET Mon May 15 23:56:31 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 XAA15887 for ; Mon, 15 May 2000 23:56: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 QQipjj17617; Tue, 16 May 2000 03:54:32 GMT Received: by mail-control.mail.uu.net id QQipjj25920 for mpls-outgoing; Tue, 16 May 2000 03:54: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 QQipjj25915 for ; Tue, 16 May 2000 03:53: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 QQipjj16510 for ; Mon, 15 May 2000 23:53:37 -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 QQipjj24515 for ; Tue, 16 May 2000 03:53:34 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 16 May 2000 09:33:57 +0530 Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA10905; Tue, 16 May 2000 09:11:20 +0530 Received: by localhost with Microsoft MAPI; Tue, 16 May 2000 09:18:21 +0530 Message-Id: <01BFBF17.AE43DFA0.manis@future.futsoft.com> From: manikantan To: "'Prem Shankar Sharma'" , "'mpls@uu.net'" Subject: RE: DU mode:Label Advt. Date: Tue, 16 May 2000 09:18:20 +0530 Importance: high X-Priority: 1 (Highest) 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 Hello Prem I agree with Bob's Yes, and my understanding is as follows. I am Referring to the section 2.6.2.2 from LDP draft 06.txt - "Liberal Label Retention Mode" as basis for my explanation. Generally DU mode of advertisement goes along with the Liberal Label Retention mode. Now if an LSR Ru detects a network N and advertises a label L for that FEC F (N and prefix), to all its peers including its next hop Rd, it is fine. Rd will store the label ( since liberal mode supported) but will not use it. If after some time Ru happens to the next hop of for the Network N w.r.to Rd, then Rd can make use of the label L advertised earlier. In case of Ru not having advertised the Label L to Rd, then when the next hop changes, Rd has to make an explicit label request. Hence advertising label to all peers including the next hop in DU mode (Liberal Label retention) is helpful. thanks in advance with best regards mani /*-------------------------------------------------------------------*/ S.Manikantan Future Software Private Limited 480-481, Anna salai, Nandanam, Chennai, Tamil Nadu, 600 035, India. Phone : +91-44-4330550 Fax : +91-44-4344157. Email : manis@future.futsoft.com http://www.futsoft.com /*--------------------------------------------------------------------*/ -----Original Message----- From: Prem Shankar Sharma [SMTP:prem@trillium.com] Sent: Tuesday, May 16, 2000 7:45 AM To: 'mpls@uu.net' Cc: Prem Shankar Sharma Subject: DU mode:Label Advt. Hi, It seems there is some difference in the opinion about the broadcast the labels to the neighbours in the DU mode. (Please have a look at the following mails). Please clarify!!! Regards. Prem <1st Mail> Question about interfacing Routing and LDP in MPLS systems? From: Eric Gray Date: Fri, 10 Dec 1999 07:57:10 -0500 CC: Zhong Hu , mpls@UU.NET References: <6342F12F9359D311990B009027A1B9B603E783@monterey.pluris.com> X-Accept-Language: en ... In the DU mode, it's quite a bit simpler. Any time such an implementation derives a new route table entry, it sends a Label Mapping to all but the next hop for that route entry. ... <2nd Mail> Sending mapping for REC-NEW-FEC From: Bob Thomas Date: Thu, 27 Jan 2000 06:31:53 -0500 cc: mpls@UU.NET In-reply-to: Your message of "Thu, 27 Jan 2000 09:33:10 +0530." <200001270356.JAA24637@blaze.hcltech.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs Sree, ... > In the Recognise New FEC in the Label Distribution Procedures in > ldp-06.txt (Appendix A.1.6), according to FEC.1, for downstream > unsolicited independent control, for each peer we are supposed to > send a label mapping. No distinction is made for the next hop. Are > we supposed to send it to the next hop also ? Yes. Bob From owner-mpls@UU.NET Tue May 16 05:17: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 ESMTP id FAA00048 for ; Tue, 16 May 2000 05:17: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 QQipkf06136; Tue, 16 May 2000 09:16:20 GMT Received: by mail-control.mail.uu.net id QQipkf04089 for mpls-outgoing; Tue, 16 May 2000 09:15: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 QQipkf04084 for ; Tue, 16 May 2000 09:15: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 QQipkf09563 for ; Tue, 16 May 2000 05:15:31 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQipkf05558 for ; Tue, 16 May 2000 09:15:29 GMT Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id SAA25227 for ; Tue, 16 May 2000 18:15:28 +0900 (JST) (envelope-from ohta.hiroshi@nslab.ntt.co.jp) Received: from ns.nslab.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/18/00) with SMTP id SAA11491 for ; Tue, 16 May 2000 18:15:24 +0900 (JST) (envelope-from ohta.hiroshi@nslab.ntt.co.jp) Received: (qmail 7541 invoked from network); 16 May 2000 18:15:23 +0900 Received: from mx.yk.nslab.ntt.co.jp (129.60.229.2) by ns.nslab.ntt.co.jp with SMTP; 16 May 2000 18:15:23 +0900 Received: by mx.yk.nslab.ntt.co.jp (8.8.8+3.0Wbeta13/3.5Wpl4/yk+mx) with SMTP id SAA03320; Tue, 16 May 2000 18:17:21 +0900 (JST) Message-Id: <200005160917.SAA03320@mx.yk.nslab.ntt.co.jp> X-Sender: ohta.hiroshi@nslab.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5-J (32) Date: Tue, 16 May 2000 18:11:07 +0900 To: mpls@UU.NET From: Hiroshi Ohta Subject: ITU-T SG13 meeting on IP OAM and protection switching Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello all, My name is Hiroshi Ohta, the rapporteur on Q.6 of ITU-T SG13 which is responsible for OAM and protection switching. I would like to inform you that ITU-T Q.6/SG13 started to draft a new Recommendation on OAM and protection switching for IP-based networks. It was provisionally numbered Y.17oam. Please see the attached initial draft. To progress the work on this issue, a meeting is planned as below. Date: June 26 - June 30, 2000 Place: Ottawa, Canada Objectives: The main objective is to progress the work on the new Recommendation on OAM and protection switching for IP-based networks (Y.17oam). Work on next release of Recs. I.610 (OAM for ATM) and I.630 (ATM protection switching) will be done if time permits. If you intend to attend this meeting, please send me an e-mail. If you intend to submit contributions, please send me the titles and abstracts. Please note that the meeting will be held only if there are sufficient number of participants and contributions. I need to report the situation to ITU to confirm the meeting four weeks before the meeting (i.e., May 29). So, please send me your intention to attend or titles and abstracts of your contributions as soon as possible but not later than May 29. I hope the meeting will be held and look forward to seeing you in Ottawa. Best regards, Hiroshi Ohta ----------------------------------- Draft Recommendation Y.17oam OAM and protection switching for IP-based networks (Geneva, 200?) 1 Scope This Recommendation provides requirements and mechanisms for OAM functions and protection switching for IP-based networks. It is recognized that OAM (Operation and Maintenance) functionality is important in public networks for ease of network operation, for verifying network performance and to reduce network operating costs. OAM functionality is especially important for networks in which Quality of Service is an important issue. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of currently valid ITU-T Recommendations is regularly published. [References are to be added (contributions are invited).] 3. Definitions to be added (contributions are invited) 4. Symbols and abbreviations to be added (contributions are invited) 5. Requirements for OAM functions and protection switching 5.1 General requirements for IP-based networks for further study (contributions are invited) 5.2 Requirements for MPLS OAM It is to be noted that MPLS OAM functionality is not seen as a substitute for physical layer (e.g. SONET/SDH) OAM functionality. However, MPLS layer OAM functions may nevertheless be seen as desirable in addition to physical layer OAM: They will be required whenever OAM functionality is needed that permits differentiation per individual LSP. OAM functionality is useful because - it allows the Operator to verify whether Quality of Service guarantees given in SLAs (Service Level Agreements) are in fact being met by the connection, - it allows the Operator to reduce network operating costs. Long term statistics show that the costs of operating a public network are higher than the initial installation costs, - it allows the Operator to improve traffic flow/distribution through the network, and - it gives support for improved accounting/billing procedures. The following is a preliminary list of possible requirements. 1. in-service verification of connection availability (whether a connection is "up" or "down") and error performance (counting of lost frames) 2. in-service verification of delay and delay variation 3. in-service verification of connection throughput guarantees. 4. tools for fast and efficient fault detection and fault localization 5. tools for efficient network setup and configuration. 6. Traffic Engineering functionality for load-dependent route selection of traffic. 7. measurement of throughput per connection for throughput based billing 8. detection of violations to a SLA traffic contract that can be given consideration for billing. 5.3 Requirements for MPLS protection switching Protection switching for MPLS is useful because it allows the operator to improve network reliability. Details are for further study (contributions are invited). 6 Mechanisms of OAM functions and protection switching 6.1 General mechanisms for IP-based networks For further study (contributions are invited). 6.2 Mechanisms of MPLS OAM Examples of MPLS OAM functionalities are the followings: - Fault management and continuity check - Loopbacks - Performance monitoring These examples are oriented towards OAM functions defined for ATM networks. Note, however, that in defining OAM functions for MPLS networks, the intention is not necessarily to reapply ATM mechanisms without modifications. Different functions may be defined as necessary. An OAM indicator in the MPLS header could enable a simple differentiation between user packets and OAM packets in equipment supporting MPLS. Further study is required to clarify the need for such an OAM indicator and to identify a suitable encoding. 6.3 Mechanisms of MPLS protection switching For further study (contributions are invited). ---------- end of draft Y.17oam ----------- Hiroshi OHTA NTT Network Service Systems Laboratories Tel: +81 468 59 8840 Fax: +81 468 59 8569 E-mail: ohta.hiroshi@nslab.ntt.co.jp From owner-mpls@UU.NET Tue May 16 05:40: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 FAA00233 for ; Tue, 16 May 2000 05:40: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 QQipkg12829; Tue, 16 May 2000 09:37:30 GMT Received: by mail-control.mail.uu.net id QQipkg05121 for mpls-outgoing; Tue, 16 May 2000 09:36: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 QQipkg05116 for ; Tue, 16 May 2000 09:36: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 QQipkg10933 for ; Tue, 16 May 2000 05:36:41 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQipkg11699 for ; Tue, 16 May 2000 09:35:46 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id PAA13689 for ; Tue, 16 May 2000 15:00:58 -0600 (GMT) Message-ID: <005101bfa787$4db9a9a0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: Control Channel Date: Sun, 16 Apr 2000 15:06:55 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01BFA7B5.674111A0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_004E_01BFA7B5.674111A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have the following question regarding Control Channel for ATM = switches running MPLS and ATM switches which dont run MPLS protocols. = Suppose the scenario is the following: non MPLS | MPLS | =20 edge router | LER1 | data is coming from a non MPLS domain into MPLS domain and there is an = ATM switch at the edge router in non MPLS domain. For interworking = between domains "n" PVCs have been statically configured between edge = router and LER1 through SLA where "n" is the no. of class of services = supported. Data belonging to different class of service comes onto the = specified PVC.=20 Now my question is do we need to have a seperate "Control Channel" = between edge router in non MPLS domain and LER1 in MPLS domain. If yes, = then how does the driver on edge router make out that this packet is = "control data" and needs to be sent onto a particular "control channel". = One solution which can work temporarily could be that the driver looks = onto the "Protocol ID" in IP header of the packet and then distinguishes = between control packets and data packets. But this means driver can = identify only those protocols for which it knows the "protocol ID". Any = suggestions. Thanx in advance. santosh ------=_NextPart_000_004E_01BFA7B5.674111A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
    I have the following question regarding Control = Channel=20 for ATM switches running MPLS and ATM switches which dont run MPLS = protocols.=20 Suppose the scenario is the following:
 
non MPLS            =20 |        MPLS
           &n= bsp;           &nb= sp;    |   =20    
    edge router =       =20 |        LER1
            =    =20             |
 
data is coming from a non MPLS domain into MPLS domain and there is = an ATM=20 switch at the edge router in non MPLS domain. For interworking between = domains=20 "n" PVCs have been statically configured between edge router and LER1 = through=20 SLA  where "n" is the no. of class of services supported. Data = belonging to=20 different class of service comes onto the specified PVC.
 
Now my question is do we need to have a seperate "Control=20 Channel" between edge router in non MPLS domain and LER1  = in MPLS=20 domain. If yes, then how does the driver on edge router make out that = this=20 packet is "control data" and needs to be sent onto a particular "control = channel".
 
One solution which can work temporarily could be that the driver = looks onto=20 the "Protocol ID" in IP header of the packet and then distinguishes = between=20 control packets and data packets. But this means driver can identify = only those=20 protocols for which it knows the "protocol ID". Any suggestions.
 
Thanx in advance.

santosh
 
------=_NextPart_000_004E_01BFA7B5.674111A0-- From owner-mpls@UU.NET Tue May 16 06:35: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 ESMTP id GAA00775 for ; Tue, 16 May 2000 06:35: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 QQipkk16278; Tue, 16 May 2000 10:33:08 GMT Received: by mail-control.mail.uu.net id QQipkk16917 for mpls-outgoing; Tue, 16 May 2000 10:32:37 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipkk16910 for ; Tue, 16 May 2000 10:32:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipkk06051 for ; Tue, 16 May 2000 06:32: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 QQipkk15731 for ; Tue, 16 May 2000 10:32:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA20786 for mpls@uu.net; Tue, 16 May 2000 06:32:19 -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 QQipkk16897 for ; Tue, 16 May 2000 10:31: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 QQipkk17537 for ; Tue, 16 May 2000 06:31:39 -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 QQipkk15352 for ; Tue, 16 May 2000 10:31:39 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00747; Tue, 16 May 2000 06:31:39 -0400 (EDT) Message-Id: <200005161031.GAA00747@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-atm-03.txt Date: Tue, 16 May 2000 06:31:38 -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 : MPLS using LDP and ATM VC Switching Author(s) : B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. Swallow, P. Doolan Filename : draft-ietf-mpls-atm-03.txt Pages : 21 Date : 15-May-00 The MPLS Architecture [1] discusses a way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-atm-03.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-atm-03.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-atm-03.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: <20000515112907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-atm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-atm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000515112907.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue May 16 06:56: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 GAA01097 for ; Tue, 16 May 2000 06:56: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 QQipkl00688; Tue, 16 May 2000 10:56:44 GMT Received: by mail-control.mail.uu.net id QQipkl18168 for mpls-outgoing; Tue, 16 May 2000 10:56:18 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 QQipkl18163 for ; Tue, 16 May 2000 10:56:14 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 QQipkl20690 for ; Tue, 16 May 2000 06:56:07 -0400 (EDT) Received: from blaze.hcltech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [204.160.253.201]) id QQipkl02319 for ; Tue, 16 May 2000 10:51:49 GMT Received: from netlab.hcltech.com ([192.168.201.56]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id QAA01149; Tue, 16 May 2000 16:22:14 +0530 Message-ID: <39212866.2D2C0B57@netlab.hcltech.com> Date: Tue, 16 May 2000 16:22:22 +0530 From: Pathangi N Janardhanan Organization: Hcl Technologies India Ltd. X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Gupta CC: mpls@UU.NET Subject: Re: Control Channel References: <005101bfa787$4db9a9a0$100d85a5@dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Santhosh, > I have the following question regarding Control Channel for ATM > switches running MPLS and ATM switches which dont run MPLS protocols. > Suppose the scenario is the following: > > non MPLS | MPLS > | > edge router | LER1 > | > > data is coming from a non MPLS domain into MPLS domain and there is an > ATM switch at the edge router in non MPLS domain. For interworking > between domains "n" PVCs have been statically configured between edge > router and LER1 through SLA where "n" is the no. of class of services > supported. Data belonging to different class of service comes onto the > specified PVC. > > Now my question is do we need to have a seperate "Control Channel" > between edge router in non MPLS domain and LER1 in MPLS domain. If > yes, then how does the driver on edge router make out that this packet > is "control data" and needs to be sent onto a particular "control > channel". What is the need for having a separate control channel? The non MPLS router talks IP to the MPLS LER using the PVCs and the MPLS LER would then send the packets on an LSP to the MPLS domain and convert from MPLS to IP on the other side. Thanks Jana From owner-mpls@UU.NET Tue May 16 08:25: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 ESMTP id IAA03457 for ; Tue, 16 May 2000 08:25: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 QQipkr25867; Tue, 16 May 2000 12:25:29 GMT Received: by mail-control.mail.uu.net id QQipkr11501 for mpls-outgoing; Tue, 16 May 2000 12:24: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 QQipkr11495 for ; Tue, 16 May 2000 12:24: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 QQipkr29075 for ; Tue, 16 May 2000 08:24:53 -0400 (EDT) Received: from ns01.newbridge.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQipkr29464 for ; Tue, 16 May 2000 12:24:53 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id IAA11138 for ; Tue, 16 May 2000 08:18:42 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAAUq.tw_; Tue May 16 08:18:38 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Tue, 16 May 2000 08:24:48 -0400 Received: from newbridge.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA3EB1 for ; Tue, 16 May 2000 08:24:54 -0400 Message-Id: <39213D6D.10AAFFC3@newbridge.com> Date: Tue, 16 May 2000 08:22:05 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS and IS-IS References: <200005160917.SAA03320@mx.yk.nslab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have been hearing IS-IS is a better protocol to be used than OSPF in a MPLS network for TE application. Is that a fair statement? What are the technical reasons? Appreciate if someone can shed some light on this subject. Thanks, Hansen From owner-mpls@UU.NET Tue May 16 08:48: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 ESMTP id IAA04143 for ; Tue, 16 May 2000 08:48: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 QQipkt11528; Tue, 16 May 2000 12:48:26 GMT Received: by mail-control.mail.uu.net id QQipkt13135 for mpls-outgoing; Tue, 16 May 2000 12:48:02 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipkt13120 for ; Tue, 16 May 2000 12:48:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipkt18412 for ; Tue, 16 May 2000 08:47:55 -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 QQipkt14979 for ; Tue, 16 May 2000 12:47:54 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id OAA22743; Tue, 16 May 2000 14:47:53 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id OAA16356; Tue, 16 May 2000 14:47:53 +0200 (MET DST) Date: Tue, 16 May 2000 14:47:53 +0200 (MET DST) Cc: otel@ce.chalmers.se To: mpls@UU.NET Subject: (Off-topic?) MPLS cisco support X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14625.16762.247041.891207@rasputin.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello all, [This might be a bit off-topic (in that case appologies) ] I'm part of a project aimed at building an MPLS core network. We are intrested if anyone knows if (or where to ask about) MPLS support in cisco IOS. We are thinking about 3600 series machines. Anyone has any experience, feedback, what is supported and what not, etc ? Ideas where i can find more information or how to contact about this capabilities (except the local cisco dealer of course which invaribaly answers with "We think that is rather supported" ;) ) ? With kind regards, Florian P.S. Now this is really off-topic :) Same goes for DiffServ and IntServ/RSVP. From owner-mpls@UU.NET Tue May 16 09:09: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 JAA04707 for ; Tue, 16 May 2000 09:09: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 QQipku00426; Tue, 16 May 2000 13:08:59 GMT Received: by mail-control.mail.uu.net id QQipku21152 for mpls-outgoing; Tue, 16 May 2000 13:08:41 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipku21027 for ; Tue, 16 May 2000 13:08:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipku20881 for ; Tue, 16 May 2000 09:08: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 QQipku29761 for ; Tue, 16 May 2000 13:08:24 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 GAA01743 for ; Tue, 16 May 2000 06:08:30 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA14044 for mpls@uu.net; Tue, 16 May 2000 09:08:22 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipkb22939 for ; Tue, 16 May 2000 08:22:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipkb27138 for ; Tue, 16 May 2000 04:22:28 -0400 (EDT) Received: from cad.zju.edu.cn by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [210.32.131.2]) id QQipkb04815 for ; Tue, 16 May 2000 08:22:16 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 563 for ; Tue, 16 May 2000 15:21:10 +0800 Message-ID: <3920E8DA.BE117F3D@cad.zju.edu.cn> Date: Tue, 16 May 2000 15:21:14 +0900 From: jing shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Newcomer's question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: I am a newcomer of MPLS , please forgive my stupid question on MPLS. We are trying to develop a communication system for multimedia in our LAN, which contains a ATM part and Ethernet part. In order to support of QoS in network transmission, We want to employ IP Qos technology in the system we built . Because I think DiffServ is a WAN technology, I think it should be MPLS+RSVP to be employed in LAN. The PCs in the LAN are all installed with Linux. My question is : 1. If we want to guarantee network service between any two computer, is it needed to build up MPLS service on each Linux box ( those in ATM LAN and Ethernet ) ? 2. If we build up one Linux Host as edge LSR and we build up MPLS in each Linux box, Is it demanded to covert lable in edge LSR? 3. Are there any Software available to build up MPLS+RSVP in Linux ? 4. Is there a book or tutorial material on MPLS ? Thanks in advance. James Shen From owner-mpls@UU.NET Tue May 16 12:24:00 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 MAA08385 for ; Tue, 16 May 2000 12:24:00 -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 QQiplh06448; Tue, 16 May 2000 16:23:14 GMT Received: by mail-control.mail.uu.net id QQiplh00376 for mpls-outgoing; Tue, 16 May 2000 16:22:41 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 QQiplh00362 for ; Tue, 16 May 2000 16:22: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 QQiplh05162 for ; Tue, 16 May 2000 12:22:14 -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 QQiplh11254 for ; Tue, 16 May 2000 16:22:14 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 JAA21836 for ; Tue, 16 May 2000 09:22:20 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA15228 for mpls@uu.net; Tue, 16 May 2000 12:22:12 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiple19314 for ; Tue, 16 May 2000 15:41:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiple12612 for ; Tue, 16 May 2000 11:41:51 -0400 (EDT) Received: from pmesmtp02.wcom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pmesmtp02.wcom.com [199.249.20.2]) id QQiple07729 for ; Tue, 16 May 2000 15:41:50 GMT Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FUN00401SXM5J@firewall.mcit.com> for mpls@uu.net; Tue, 16 May 2000 15:41:46 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FUN00417SXM3N@firewall.mcit.com> for mpls@uu.net; Tue, 16 May 2000 15:41:46 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FUN00901SQS5W@pmismtp04.wcomnet.com> for mpls@uu.net; Tue, 16 May 2000 15:37:40 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FUN00901SQI3Z@pmismtp04.wcomnet.com> for mpls@uu.net; Tue, 16 May 2000 15:37:39 +0000 (GMT) Received: from omzmta03.mcit.com ([166.37.214.9]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FUN005GOSQB5D@pmismtp04.wcomnet.com> for mpls@uu.net; Tue, 16 May 2000 15:37:24 +0000 (GMT) Received: from COMPAQ ([166.35.42.226]) by omzmta03.mcit.com (InterMail v03.02.07 118-124-101) with SMTP id <20000516154129.VVT24734@COMPAQ>; Tue, 16 May 2000 15:41:29 +0000 Date: Tue, 16 May 2000 11:46:41 -0400 From: Mario Campuzano Subject: SNA over MPLS To: mpls@UU.NET Cc: mark.mahan@wcom.com Reply-to: Mario.Campuzano@wcom.com Message-id: <000701bfbf4d$eef9d280$e22a23a6@COMPAQ.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit To Whom it May Concern: Would you please be so kind as to let me know if we have any information or there are any issues for carrying SNA over MPLS. Thanks for your attention. Mario Campuzano Global Technical Consultant Global and Corporate National Accounts WorldCom 8750 Doral Blvd Suite 300 Miami, FL 33178 Direct:305-507-2268 Toll Free:800-888-8988 ext.2268 Pager:800-229-3891 Vnet:8-946-2268 IP ID:mario.campuzano@wcom.com From owner-mpls@UU.NET Tue May 16 12: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 ESMTP id MAA08845 for ; Tue, 16 May 2000 12: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 QQiplj26838; Tue, 16 May 2000 16:51:12 GMT Received: by mail-control.mail.uu.net id QQiplj01826 for mpls-outgoing; Tue, 16 May 2000 16:50: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 QQiplj01820 for ; Tue, 16 May 2000 16:50: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 QQiplj10018 for ; Tue, 16 May 2000 12:50: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 QQiplj01273 for ; Tue, 16 May 2000 16:50:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA06431 for mpls@uu.net; Tue, 16 May 2000 12:50:21 -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 QQiplj01791 for ; Tue, 16 May 2000 16:49: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 QQiplj09744 for ; Tue, 16 May 2000 12:49:21 -0400 (EDT) Received: from uniwest1.redstonecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.105.223.130]) id QQiplj00412 for ; Tue, 16 May 2000 16:49:20 GMT Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 May 2000 12:52:13 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C67F1E9@uniwest1.redstonecom.com> From: "Wadhwa, Sanjay" To: ospf@discuss.microsoft.com Cc: mpls@UU.NET Subject: Tunnel endpoints... Date: Tue, 16 May 2000 12:52:05 -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 This is in reference to draft-hsmit-mpls-igp-spf-00.txt (SPF modification to install routes downstream of existing tunnels to use the tunnels) as applied to OSPF. Consider the following : Ia Ib L0 Ra ------------ Rb --------------------- Rc ----------------------- Assume this to be the topology in an ospf area. Ra is the calculating router. Rb and Rc have a numbered p2p link with Ia and Ib being their respective interface ip addresses. Let router-id of Rc be ip address of a loopback interface (L0) configured on Rc. Lets say Ra is a tunnel head-end and Rc is the tunnel tail-end. Tunnel endpoint could be configured to be either Ib or the router-id on Rc. While deriving nexthop for Rc, it is easier/cheaper to figure out the nexthop should be a tunnel if the tunnel terminates on the router-id as opposed to interface Ib. One could make an assumption that tunnels (shortcuts) used for IGP routes are configured to terminate on router-id of the tail-end router (which could possibly be an ip address of an existing interface on the router) and not interface addresses (other than the router-id) i.e. in ospf case say the router-id of the ABR as opposed to an interface address. Any thoughts on the operational validity of this assumption... thanks -Sanjay From owner-mpls@UU.NET Tue May 16 19:04: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 TAA14073 for ; Tue, 16 May 2000 19:04: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 QQipmi07818; Tue, 16 May 2000 23:04:22 GMT Received: by mail-control.mail.uu.net id QQipmi26743 for mpls-outgoing; Tue, 16 May 2000 23:03:52 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipmi26734 for ; Tue, 16 May 2000 23:03:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipmi10616 for ; Tue, 16 May 2000 19:03:41 -0400 (EDT) Received: from hawk.crescentnets.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.177.194.54]) id QQipmi10821 for ; Tue, 16 May 2000 23:03:40 GMT Received: from crescentnets.com (langille.in.crescentnets.com [192.168.29.105]) by hawk.crescentnets.com (8.9.3/8.9.3) with ESMTP id TAA03653; Tue, 16 May 2000 19:03:40 -0400 (EDT) Message-ID: <3921D44C.B1C0D0DC@crescentnets.com> Date: Tue, 16 May 2000 19:05:48 -0400 From: Paul Langille Organization: Crescent Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: tnadeau@cisco.com, arun@force10networks.com, cheenu@tachion.com Subject: Two minor comments on draft-ietf-mpls-te-mib-03.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, Arun, Cheenu. Here are two minor comments on draft-ietf-mpls-te-mib-03.txt. 1) Some more text around the MplsTunnelIndex and MplsTunnelInstance would be helpful. For example, the description in the 'Textual Conventions' is accurate but brief. The description in the MplsTunnelIndex object ("Uniquely identifies this row.") is confusing. Some examples would also help. (This is probably the same thing that Adrian Farrel was requesting in his message.) If I get sometime 'spare' time I will send you some text but don't hold your breath! 2) The syntax for the MplsTunnelInstance object is "MplsTunnelIndex" and it should be "MplsTunnelInstance". (Looks like a cut and paste error.) Paul -- Paul Langille e-mail: langille@crescentnets.com Crescent Networks phone: (978) 244-9002 x244 201 Riverneck Road fax: (978) 244-9211 Chelmsford, MA 01824 From owner-mpls@UU.NET Tue May 16 20:01: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 UAA14394 for ; Tue, 16 May 2000 20:01: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 QQipmm16255; Wed, 17 May 2000 00:01:32 GMT Received: by mail-control.mail.uu.net id QQipmm04740 for mpls-outgoing; Wed, 17 May 2000 00:01: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 QQipmm04616 for ; Wed, 17 May 2000 00:01: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 QQipmm17704 for ; Tue, 16 May 2000 20:01:02 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.104.68.2]) id QQipmm13782 for ; Wed, 17 May 2000 00:01:01 GMT Received: by bgslc02.tbg.com with Internet Mail Service (5.5.2448.0) id <27GZKP5S>; Tue, 16 May 2000 17:55:59 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE76F633E@bgslc02.tbg.com> From: Irwin Lazar To: "'otel@ce.chalmers.se'" , mpls@UU.NET Subject: RE: (Off-topic?) MPLS cisco support Date: Tue, 16 May 2000 17:55:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Hi, There are several links to information on Cisco's MPLS support on the MPLS Resource Center - http://www.mplsrc.com/ . See the Vendor Information page. Irwin -----Original Message----- From: Florian-Daniel Otel [mailto:otel@ce.chalmers.se] Sent: Tuesday, May 16, 2000 8:48 AM To: mpls@UU.NET Cc: otel@ce.chalmers.se Subject: (Off-topic?) MPLS cisco support Hello all, [This might be a bit off-topic (in that case appologies) ] I'm part of a project aimed at building an MPLS core network. We are intrested if anyone knows if (or where to ask about) MPLS support in cisco IOS. We are thinking about 3600 series machines. Anyone has any experience, feedback, what is supported and what not, etc ? Ideas where i can find more information or how to contact about this capabilities (except the local cisco dealer of course which invaribaly answers with "We think that is rather supported" ;) ) ? With kind regards, Florian P.S. Now this is really off-topic :) Same goes for DiffServ and IntServ/RSVP. From owner-mpls@UU.NET Tue May 16 21:32: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 ESMTP id VAA15009 for ; Tue, 16 May 2000 21:32: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 QQipms12394; Wed, 17 May 2000 01:32:28 GMT Received: by mail-control.mail.uu.net id QQipms21855 for mpls-outgoing; Wed, 17 May 2000 01:32: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 QQipms21850 for ; Wed, 17 May 2000 01:32: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 QQipms25458 for ; Tue, 16 May 2000 21:32: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 QQipms09622 for ; Wed, 17 May 2000 01:32:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA09927 for mpls@uu.net; Tue, 16 May 2000 21:31: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 QQipms21838 for ; Wed, 17 May 2000 01:31: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 QQipms28819 for ; Tue, 16 May 2000 21:31:24 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQipms09279 for ; Wed, 17 May 2000 01:31:23 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-5.cisco.com [144.254.139.5]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id SAA15832; Tue, 16 May 2000 18:30:48 -0700 (PDT) Message-Id: <4.2.2.20000517111834.00a88ce0@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 17 May 2000 11:30:35 +1000 To: Santosh Gupta From: Jeremy Lawrence Subject: Re: Control Channel Cc: mpls@UU.NET, Pathangi N Janardhanan In-Reply-To: <39212866.2D2C0B57@netlab.hcltech.com> References: <005101bfa787$4db9a9a0$100d85a5@dti.daewoo.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 16:22 05/16/2000 +0530, Pathangi N Janardhanan wrote: >Hi Santhosh, > > > I have the following question regarding Control Channel for ATM > > switches running MPLS and ATM switches which dont run MPLS protocols. > > Suppose the scenario is the following: > > > > non MPLS | MPLS > > | > > edge router | LER1 > > | > > > > data is coming from a non MPLS domain into MPLS domain and there is an > > ATM switch at the edge router in non MPLS domain. For interworking > > between domains "n" PVCs have been statically configured between edge > > router and LER1 through SLA where "n" is the no. of class of services > > supported. Data belonging to different class of service comes onto the > > specified PVC. > > > > Now my question is do we need to have a seperate "Control Channel" > > between edge router in non MPLS domain and LER1 in MPLS domain. If > > yes, then how does the driver on edge router make out that this packet > > is "control data" and needs to be sent onto a particular "control > > channel". > > What is the need for having a separate control channel? > > The non MPLS router talks IP to the MPLS LER using the PVCs >and the MPLS LER would then send the packets on an LSP to the >MPLS domain and convert from MPLS to IP on the other side. That's correct. Note that the "MPLS domain" must start in the middle of a edge LSR (LER), not in the middle of a link. So: - The edge LSR is in both the MPLS domain and the non-MPLS domain, as it deals with both unlabelled IP packets and MPLS packets. An implication is that an edge LSR must be a router, or a similar device with capability to do non-trivial amounts of manipulation of packet headers. - Some links (the PVCs described above) carry unlabelled IP traffic without using MPLS control. Note that MPLS control is _not_ necessary to have parallel PVCs carry different classes of traffic. - The other links carry labelled traffic with MPLS control. - No links carry unlabelled IP traffic with MPLS control. Regards, Jeremy Lawrence From owner-mpls@UU.NET Tue May 16 21:56:48 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 VAA16028 for ; Tue, 16 May 2000 21:56:48 -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 QQipmt24723; Wed, 17 May 2000 01:56:47 GMT Received: by mail-control.mail.uu.net id QQipmt23114 for mpls-outgoing; Wed, 17 May 2000 01:56: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 QQipmt23109 for ; Wed, 17 May 2000 01:56: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 QQipmt00284 for ; Tue, 16 May 2000 21:55: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 QQipmt26840 for ; Wed, 17 May 2000 01:55:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA11727 for mpls@uu.net; Tue, 16 May 2000 21:55:57 -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 QQipmt23006 for ; Wed, 17 May 2000 01:55: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 QQipmt00264 for ; Tue, 16 May 2000 21:55:21 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQipmt23605 for ; Wed, 17 May 2000 01:55:20 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-5.cisco.com [144.254.139.5]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id SAA20665; Tue, 16 May 2000 18:55:17 -0700 (PDT) Message-Id: <4.2.2.20000517113237.00a84a60@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 17 May 2000 11:54:19 +1000 To: "HANSEN CHAN" From: Jeremy Lawrence Subject: Re: MPLS and IS-IS Cc: mpls@UU.NET In-Reply-To: <39213D6D.10AAFFC3@newbridge.com> References: <200005160917.SAA03320@mx.yk.nslab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hansen, At 08:22 05/16/2000 -0400, HANSEN CHAN wrote: >Hi all, > >I have been hearing IS-IS is a better protocol to be used than OSPF in a MPLS >network for TE application. Is that a fair statement? What are the technical >reasons? IS-IS has some advantages over OSPF in general. These are at least as relevant in MPLS networks doing traffic engineering as they are in networks not doing TE or MPLS: - In practice, IS-IS has been shown to support larger Areas than OSPF. This is of particular relevance to TE as it extends the regions over which a router can have detailed knowledge of link state, and hence knowledge of optimal routing of TE paths. - In practice, IS-IS has proved to be more stable than OSPF due to features like the pacing of LSP distribution (at least one OSPF implementation has caught up in this regard). Regards, Jeremy Lawrence From owner-mpls@UU.NET Tue May 16 22:24: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 WAA16175 for ; Tue, 16 May 2000 22:24: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 QQipmv11964; Wed, 17 May 2000 02:24:01 GMT Received: by mail-control.mail.uu.net id QQipmv03240 for mpls-outgoing; Wed, 17 May 2000 02:23:44 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipmv03235 for ; Wed, 17 May 2000 02:23:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipmv25775 for ; Tue, 16 May 2000 22:23:21 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQipmv11437 for ; Wed, 17 May 2000 02:23:21 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA24360; Tue, 16 May 2000 19:23:09 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id TAA04112; Tue, 16 May 2000 19:23:09 -0700 (PDT) Date: Tue, 16 May 2000 19:23:09 -0700 (PDT) Message-Id: <200005170223.TAA04112@cirrus.juniper.net> From: Dave Katz To: jlawrenc@cisco.com CC: hchan@newbridge.com, mpls@UU.NET In-reply-to: <4.2.2.20000517113237.00a84a60@bulkrate.cisco.com> (message from Jeremy Lawrence on Wed, 17 May 2000 11:54:19 +1000) Subject: Re: MPLS and IS-IS Sender: owner-mpls@UU.NET Precedence: bulk One should note that these "advantages" are artifacts of the state of a particular vendor's implementations, and does not reflect on any inherent scaling or stability issues in the protocols themselves. Probably the bigger issue as far as TE, or extensions in general, is that they tend to happen faster in IS-IS because the largest customers of the dominant vendors tend to use it, so it is the first target of implementation. --Dave IS-IS has some advantages over OSPF in general. These are at least as relevant in MPLS networks doing traffic engineering as they are in networks not doing TE or MPLS: - In practice, IS-IS has been shown to support larger Areas than OSPF. This is of particular relevance to TE as it extends the regions over which a router can have detailed knowledge of link state, and hence knowledge of optimal routing of TE paths. - In practice, IS-IS has proved to be more stable than OSPF due to features like the pacing of LSP distribution (at least one OSPF implementation has caught up in this regard). From owner-mpls@UU.NET Tue May 16 22:25: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 ESMTP id WAA16189 for ; Tue, 16 May 2000 22:25: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 QQipmv13289; Wed, 17 May 2000 02:25:52 GMT Received: by mail-control.mail.uu.net id QQipmv03313 for mpls-outgoing; Wed, 17 May 2000 02:25: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 QQipmv03304 for ; Wed, 17 May 2000 02:25: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 QQipmv02476 for ; Tue, 16 May 2000 22:25:01 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQipmv12715 for ; Wed, 17 May 2000 02:25:01 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id WAA11223; Tue, 16 May 2000 22:25:00 -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 WAA10736; Tue, 16 May 2000 22:24:51 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200005170224.WAA10736@curtis-lt.avici.com> To: Jeremy Lawrence cc: "HANSEN CHAN" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS and IS-IS In-reply-to: Your message of "Wed, 17 May 2000 11:54:19 +1000." <4.2.2.20000517113237.00a84a60@bulkrate.cisco.com> Date: Tue, 16 May 2000 22:24:51 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4.2.2.20000517113237.00a84a60@bulkrate.cisco.com>, Jeremy Lawrence writes: > Hansen, > > At 08:22 05/16/2000 -0400, HANSEN CHAN wrote: > >Hi all, > > > >I have been hearing IS-IS is a better protocol to be used than OSPF in a MPL > S > >network for TE application. Is that a fair statement? What are the technical > >reasons? > > IS-IS has some advantages over OSPF in general. These are at > least as relevant in MPLS networks doing traffic engineering as > they are in networks not doing TE or MPLS: > - In practice, IS-IS has been shown to support larger Areas > than OSPF. This is of particular relevance to TE as it > extends the regions over which a router can have detailed > knowledge of link state, and hence knowledge of optimal > routing of TE paths. > - In practice, IS-IS has proved to be more stable than OSPF > due to features like the pacing of LSP distribution (at > least one OSPF implementation has caught up in this regard). > > Regards, > > Jeremy Lawrence Jeremy, IMHO both ISIS and OSPF are well suited for TE. The two protocols each have minor advantages and disadvantages. For example, OSPF area support works, and ISIS level support offers limited capability (as now defined). OSPF is an IETF Full Standard while ISIS is defined by an ISO document that doesn't reflect what implementations actually do, one somewhat outdated RFC-1195, and a patchwork of internet-drafts, most of which are still being argued over in the WG. Still ISIS works quite well and the one timer for a one big ISIS-LSP is much friendlier to naive timer implementations (such as linked lists of timer events) than a timer for each OSPF-LSA. Curtis btw- I always thought ISIS became widely used only because during the mid-1990s one widely used router had a very poor OSPF implementation which was inefficient and buggy and preferred to blame the protocol. Must be just some old Internet folklore. ;-) From owner-mpls@UU.NET Tue May 16 22:38:22 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 WAA17178 for ; Tue, 16 May 2000 22:38: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 QQipmw21657; Wed, 17 May 2000 02:38:14 GMT Received: by mail-control.mail.uu.net id QQipmw04197 for mpls-outgoing; Wed, 17 May 2000 02:37:51 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 QQipmw04192 for ; Wed, 17 May 2000 02:37: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 QQipmw03411 for ; Tue, 16 May 2000 22:37:28 -0400 (EDT) Received: from baynet.baynetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQipmw21969 for ; Wed, 17 May 2000 02:37:27 GMT Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id TAA11429; Tue, 16 May 2000 19:35:59 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id TAA02230; Tue, 16 May 2000 19:35:55 -0700 (PDT) Received: from bubba.engeast (bubba [192.168.136.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id WAA19179; Tue, 16 May 2000 22:37:25 -0400 for Received: by bubba.engeast (SMI-8.6/SMI-SVR4) id WAA24215; Tue, 16 May 2000 22:37:25 -0400 Date: Tue, 16 May 2000 22:37:25 -0400 From: dwilder@baynetworks.com (David Wilder) Message-Id: <200005170237.WAA24215@bubba.engeast> To: hchan@newbridge.com, jlawrenc@cisco.com Subject: Re: MPLS and IS-IS Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Jeremy, When you say "In practice" and "has been shown", are you referring to internal comparison lab testing or at customer networks? I have not observed anything conclusive on the advantages of either one for MPLS or otherwise, so I am curious. Thanks, Dave Wilder ************* Hansen, At 08:22 05/16/2000 -0400, HANSEN CHAN wrote: >Hi all, > >I have been hearing IS-IS is a better protocol to be used than OSPF in a MPLS >network for TE application. Is that a fair statement? What are the technical >reasons? IS-IS has some advantages over OSPF in general. These are at least as relevant in MPLS networks doing traffic engineering as they are in networks not doing TE or MPLS: - In practice, IS-IS has been shown to support larger Areas than OSPF. This is of particular relevance to TE as it extends the regions over which a router can have detailed knowledge of link state, and hence knowledge of optimal routing of TE paths. - In practice, IS-IS has proved to be more stable than OSPF due to features like the pacing of LSP distribution (at least one OSPF implementation has caught up in this regard). Regards, Jeremy Lawrence From owner-mpls@UU.NET Tue May 16 23:01: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 XAA17317 for ; Tue, 16 May 2000 23:01: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 QQipmy06288; Wed, 17 May 2000 03:01:41 GMT Received: by mail-control.mail.uu.net id QQipmy10043 for mpls-outgoing; Wed, 17 May 2000 03:01: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 QQipmy09552 for ; Wed, 17 May 2000 03:01: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 QQipmy02681 for ; Tue, 16 May 2000 23:00:43 -0400 (EDT) Received: from tcb.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQipmy06400 for ; Wed, 17 May 2000 03:00:42 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id VAA05906 for ; Tue, 16 May 2000 21:02:04 -0600 Message-Id: <200005170302.VAA05906@tcb.net> To: mpls@UU.NET From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MPLS and IS-IS Date: Tue, 16 May 2000 21:02:03 -0600 Sender: owner-mpls@UU.NET Precedence: bulk Indeed the largest customers using IS-IS (and debugging it in the largest, most complex networks) have significantly contributed to this perceived OSPF-is-superior-to-ISIS scalability issue. When, in reality, they're basing the assumption on a specific implementation and not the protocols themselves. -danny > > IMHO both ISIS and OSPF are well suited for TE. > > The two protocols each have minor advantages and disadvantages. For > example, OSPF area support works, and ISIS level support offers > limited capability (as now defined). OSPF is an IETF Full Standard > while ISIS is defined by an ISO document that doesn't reflect what > implementations actually do, one somewhat outdated RFC-1195, and a > patchwork of internet-drafts, most of which are still being argued > over in the WG. Still ISIS works quite well and the one timer for a > one big ISIS-LSP is much friendlier to naive timer implementations > (such as linked lists of timer events) than a timer for each OSPF-LSA. > > Curtis > > btw- I always thought ISIS became widely used only because during the > mid-1990s one widely used router had a very poor OSPF implementation > which was inefficient and buggy and preferred to blame the protocol. > Must be just some old Internet folklore. ;-) From owner-mpls@UU.NET Tue May 16 23:11: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 XAA17350 for ; Tue, 16 May 2000 23:11: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 QQipmy13326; Wed, 17 May 2000 03:11:30 GMT Received: by mail-control.mail.uu.net id QQipmy14576 for mpls-outgoing; Wed, 17 May 2000 03:11:12 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 QQipmy14529 for ; Wed, 17 May 2000 03:11: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 QQipmy05796 for ; Tue, 16 May 2000 23:10: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 QQipmy12846 for ; Wed, 17 May 2000 03:10:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA17694 for mpls@uu.net; Tue, 16 May 2000 23:10:57 -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 QQipmy14451 for ; Wed, 17 May 2000 03:10: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 QQipmy03381 for ; Tue, 16 May 2000 23:10:08 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQipmy11178 for ; Wed, 17 May 2000 03:10:08 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-5.cisco.com [144.254.139.5]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id UAA00403; Tue, 16 May 2000 20:07:36 -0700 (PDT) Message-Id: <4.2.2.20000517130654.00a96ae0@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 17 May 2000 13:07:22 +1000 To: dwilder@baynetworks.com (David Wilder) From: Jeremy Lawrence Subject: Re: MPLS and IS-IS Cc: hchan@newbridge.com, mpls@UU.NET In-Reply-To: <200005170237.WAA24215@bubba.engeast> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 22:37 05/16/2000 -0400, David Wilder wrote: >Hi Jeremy, > >When you say "In practice" and "has been shown", are you referring to internal >comparison lab testing or at customer networks? Customer networks. Jeremy From owner-mpls@UU.NET Wed May 17 01:32: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 ESMTP id BAA21978 for ; Wed, 17 May 2000 01:32: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 QQipni10632; Wed, 17 May 2000 05:32:22 GMT Received: by mail-control.mail.uu.net id QQipni09049 for mpls-outgoing; Wed, 17 May 2000 05:31:55 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 QQipni09044 for ; Wed, 17 May 2000 05:31:52 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 QQipni15754 for ; Wed, 17 May 2000 01:31:45 -0400 (EDT) Received: from mta6.snfc21.pbi.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mta6.snfc21.pbi.net [206.13.28.240]) id QQipni10078 for ; Wed, 17 May 2000 05:31:45 GMT Received: from siara.com ([63.200.50.218]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FUO00JJFV4PD3@mta6.snfc21.pbi.net> for mpls@UU.NET; Tue, 16 May 2000 22:26:50 -0700 (PDT) Date: Tue, 16 May 2000 23:20:15 -0700 From: Tony Przygienda Subject: Re: MPLS and IS-IS To: curtis@avici.com Cc: Jeremy Lawrence , HANSEN CHAN , mpls@UU.NET Reply-to: prz@siara.com Message-id: <39223A1E.9C530DD6@siara.com> Organization: Siara Systems MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200005170224.WAA10736@curtis-lt.avici.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > > IMHO both ISIS and OSPF are well suited for TE. > > The two protocols each have minor advantages and disadvantages. For > example, OSPF area support works, and ISIS level support offers > limited capability (as now defined). unless you're dying for things like NSSA, everything that is relevant (==deploying folks asked for) is there. Further _real_ requirements are welcome and will be incorporated. > OSPF is an IETF Full Standard > while ISIS is defined by an ISO document that doesn't reflect what > implementations actually do, one somewhat outdated RFC-1195, and a > patchwork of internet-drafts, most of which are still being argued > over in the WG. that's what Internet backbone is all about. "Patchwork" of drafts under discussion has the advantage of flexibility ;-) Monolithic, coherent draft has the advantage of understandability and coherence. Internet @ ISP level has some way to go to be monolithic and understandable and that's why we are where we are whereas @ the level of campus things are pretty well understood I'd dare venture to say. > Still ISIS works quite well and the one timer for a > one big ISIS-LSP is much friendlier to naive timer implementations > (such as linked lists of timer events) than a timer for each OSPF-LSA. at sizes ISIS is being used today in the backbones, this is a a dated statement at compiler & data-structure level ;-) thanks -- tony From owner-mpls@UU.NET Wed May 17 01:42:33 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 BAA23264 for ; Wed, 17 May 2000 01:42: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 QQipni16850; Wed, 17 May 2000 05:42:32 GMT Received: by mail-control.mail.uu.net id QQipni09518 for mpls-outgoing; Wed, 17 May 2000 05:42:05 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipni09513 for ; Wed, 17 May 2000 05:41:59 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipni10232 for ; Wed, 17 May 2000 01:41:54 -0400 (EDT) Received: from mta6.snfc21.pbi.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mta6.snfc21.pbi.net [206.13.28.240]) id QQipni16243 for ; Wed, 17 May 2000 05:41:49 GMT Received: from siara.com ([63.200.50.218]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FUO00JWPVJZSW@mta6.snfc21.pbi.net> for mpls@UU.NET; Tue, 16 May 2000 22:36:11 -0700 (PDT) Date: Tue, 16 May 2000 23:29:25 -0700 From: Tony Przygienda Subject: Re: MPLS and IS-IS To: Dave Katz Cc: jlawrenc@cisco.com, hchan@newbridge.com, mpls@UU.NET Message-id: <39223C45.2717365B@siara.com> Organization: Siara Systems MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200005170223.TAA04112@cirrus.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dave Katz wrote: > One should note that these "advantages" are artifacts of the state of > a particular vendor's implementations, and does not reflect on any > inherent scaling or stability issues in the protocols themselves. > > Probably the bigger issue as far as TE, or extensions in general, is that > they tend to happen faster in IS-IS because the largest customers of > the dominant vendors tend to use it, so it is the first target of > implementation. got to agree with the assesement from the horse's mouth ;-)) The way we're going, ISIS will be there to stay for quite some time since it's ultimately boiling down to avaialble implementations and who's bending over more to keep the large ISPs happy as said above ... There have been at least one very successfull modified OSPF implementations in the backbone by a well known guy from a well-known company ;-) just not @ layer 3. having done both to some extent, I think that either one done _cluefully_ can do the job. -- tony From owner-mpls@UU.NET Wed May 17 02:37:22 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 CAA00467 for ; Wed, 17 May 2000 02:37: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 QQipnm15457; Wed, 17 May 2000 06:37:17 GMT Received: by mail-control.mail.uu.net id QQipnm21060 for mpls-outgoing; Wed, 17 May 2000 06:36: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 QQipnm21055 for ; Wed, 17 May 2000 06:36:54 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 QQipnm20470 for ; Wed, 17 May 2000 02:36: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 QQipnm15044 for ; Wed, 17 May 2000 06:36:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA01826 for mpls@uu.net; Wed, 17 May 2000 02:36:47 -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 QQipnm21046 for ; Wed, 17 May 2000 06:36: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 QQipnm20503 for ; Wed, 17 May 2000 02:36:21 -0400 (EDT) Received: from frogger.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: frogger.cisco.com [171.71.161.88]) id QQipnm17470 for ; Wed, 17 May 2000 06:36:21 GMT Received: from cwhytent2 (cwhyte-isdn1.cisco.com [10.19.229.234]) by frogger.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id XAA03812; Tue, 16 May 2000 23:35:47 -0700 (PDT) Message-ID: <032901bfbfca$613dc3c0$eae5130a@cisco.com> Reply-To: "Chris Whyte" From: "Chris Whyte" To: , References: <200005170302.VAA05906@tcb.net> Subject: Re: MPLS and IS-IS Date: Tue, 16 May 2000 23:37:30 -0700 Organization: cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > Indeed the largest customers using IS-IS (and debugging it in the > largest, most complex networks) have significantly contributed to > this perceived OSPF-is-superior-to-ISIS scalability issue. When, > in reality, they're basing the assumption on a specific > implementation and not the protocols themselves. > So what about the fact that the underlying protocol of one, OSPF, has a tendency to be bit more complex (eg feature rich) than the other (I'm being kind)? I find that companies building products that support both protocols have to spend more time on bringing OSPF up to RFC compliancy (eg adding yet another LSA type), because it's so well defined and attempts to solve so many problems, rather than focusing on code and protocol optimizations that can solve more pressing customer problems. I do believe the "perception" goes a little bit beyond implementation only issues. Thanks, Chris > -danny > > > > > IMHO both ISIS and OSPF are well suited for TE. > > > > The two protocols each have minor advantages and disadvantages. For > > example, OSPF area support works, and ISIS level support offers > > limited capability (as now defined). OSPF is an IETF Full Standard > > while ISIS is defined by an ISO document that doesn't reflect what > > implementations actually do, one somewhat outdated RFC-1195, and a > > patchwork of internet-drafts, most of which are still being argued > > over in the WG. Still ISIS works quite well and the one timer for a > > one big ISIS-LSP is much friendlier to naive timer implementations > > (such as linked lists of timer events) than a timer for each OSPF-LSA. > > > > Curtis > > > > btw- I always thought ISIS became widely used only because during the > > mid-1990s one widely used router had a very poor OSPF implementation > > which was inefficient and buggy and preferred to blame the protocol. > > Must be just some old Internet folklore. ;-) > > > From owner-mpls@UU.NET Wed May 17 04:27: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 ESMTP id EAA01214 for ; Wed, 17 May 2000 04:27: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 QQipnt21951; Wed, 17 May 2000 08:27:38 GMT Received: by mail-control.mail.uu.net id QQipnt14321 for mpls-outgoing; Wed, 17 May 2000 08:27:17 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 QQipnt14316 for ; Wed, 17 May 2000 08:27: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 QQipnt28186 for ; Wed, 17 May 2000 04:27:06 -0400 (EDT) Received: from neptune.telecomm.tadiran.co.il by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tadiran.co.il [194.90.248.2]) id QQipnt21441 for ; Wed, 17 May 2000 08:27:02 GMT Received: from oranus.tadirantele.com (oranus [10.115.11.180]) by neptune.telecomm.tadiran.co.il (8.9.3/8.9.3) with ESMTP id KAA29717 for ; Wed, 17 May 2000 10:24:12 +0200 (IST) Received: by oranus.tadirantele.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 11:24:25 +0300 Message-ID: From: Levi Daphna To: "'mpls@UU.NET'" Subject: Question:draft-ietf-mpls-atm-03.txt Date: Wed, 17 May 2000 11:23:45 +0300 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 I have a question concerning the MPLS-ATM draft. In paragraph 7.2 we deal with the scenario of ATM-LSRs which are connected via an ATM VP cloud. (to my understanding this is an overlay model ) 7.2. Connections via an ATM VP Sometimes it can be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them is made through an ATM "cloud" via an ATM Virtual Path. In this case, the VPI field is not available to MPLS, and the label MUST be encoded entirely within the VCI field. In this case, the default VCI value of the non-MPLS connection between the LSRs is 32. Other values can be configured, as long as both parties are aware of the configured value. The VPI is set to whatever is required to make use of the Virtual Path. My question is: How do we set the VPI value, is it through a management system or is there some signaling between the ATM-LSR and the VP switch. Thanks in advance, Daphna From owner-mpls@UU.NET Wed May 17 06:03: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 ESMTP id GAA01914 for ; Wed, 17 May 2000 06:03: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 QQipoa20082; Wed, 17 May 2000 10:03:08 GMT Received: by mail-control.mail.uu.net id QQipoa01129 for mpls-outgoing; Wed, 17 May 2000 10:02: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 QQipoa01026 for ; Wed, 17 May 2000 10:02:28 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 QQipoa04574 for ; Wed, 17 May 2000 06:02: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 QQipoa19148 for ; Wed, 17 May 2000 10:02:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA11559 for mpls@uu.net; Wed, 17 May 2000 06:02:17 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipoa00243 for ; Wed, 17 May 2000 10:01:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipoa28660 for ; Wed, 17 May 2000 06:01:41 -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 QQipoa19118 for ; Wed, 17 May 2000 10:01:40 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA02214; Wed, 17 May 2000 12:01:07 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA24121; Wed, 17 May 2000 12:01:25 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id ; Wed, 17 May 2000 12:03:38 +0200 Message-ID: <3B59676F9ADBD211B5360060086E64EECC00BD@MCHH237E> From: Theimer Thomas To: "'Levi Daphna'" Cc: "'mpls@UU.NET'" Subject: RE: Question:draft-ietf-mpls-atm-03.txt Date: Wed, 17 May 2000 12:03:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk In most cases the VPI must be configured through a management system. It may be possible to use ILMI to obtain the VPI value, in which case it must be configured at the directly attached VP crossconnect. If both switches are under common administrative control, there is no advantage in using ILMI. I am also not sure if MPLS capable switches support ILMI for setting the VPI. Thomas Theimer > -----Original Message----- > From: Levi Daphna [SMTP:Daphna.Levi@ecitele.com] > Sent: Wednesday, May 17, 2000 10:24 AM > To: 'mpls@UU.NET' > Subject: Question:draft-ietf-mpls-atm-03.txt > > Hi > > I have a question concerning the MPLS-ATM draft. > In paragraph 7.2 we deal with the scenario of ATM-LSRs which are connected > via an ATM VP cloud. (to my understanding this is an overlay model ) > 7.2. Connections via an ATM VP > Sometimes it can be useful to treat two LSRs as adjacent (in some LSP) > across an LC-ATM interface, even though the connection between them is > made > through an ATM "cloud" via an ATM Virtual Path. In this case, the VPI > field > is not available to MPLS, and the label MUST be encoded entirely within > the > VCI field. > In this case, the default VCI value of the non-MPLS connection between the > LSRs is 32. Other values can be configured, as long as both parties are > aware of the configured value. The VPI is set to whatever is required to > make use of the Virtual Path. > > My question is: How do we set the VPI value, is it through a management > system or is there some signaling between the ATM-LSR and the VP switch. > > Thanks in advance, > Daphna > From owner-mpls@UU.NET Wed May 17 07:05: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 HAA02351 for ; Wed, 17 May 2000 07:05: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 QQipoe27611; Wed, 17 May 2000 11:05:41 GMT Received: by mail-control.mail.uu.net id QQipoe14786 for mpls-outgoing; Wed, 17 May 2000 11:05:18 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipoe14761 for ; Wed, 17 May 2000 11:05:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipoe02950 for ; Wed, 17 May 2000 07:05:12 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQipoe27226 for ; Wed, 17 May 2000 11:05:11 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4HAqdH14171 for ; Wed, 17 May 2000 12:52:40 +0200 (MET DST) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4H8sL210083 for ; Wed, 17 May 2000 10:54:24 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Wed, 17 May 2000 10:52:23 +0200 Received: from esealnt406-in.al.sw.ericsson.se ([153.88.251.29]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 17 May 2000 08:52:22 0000 (GMT) Received: from esealnt172.ericsson.se ([130.100.184.165]) by esealnt406-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Wed, 17 May 2000 10:50:46 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Wed, 17 May 2000 10:54:16 +0200 Message-ID: From: "Gabor Korossy (ETH)" To: HANSEN CHAN Cc: mpls@UU.NET Subject: RE: MPLS and IS-IS Date: Wed, 17 May 2000 10:54:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 17 May 2000 08:50:46.0406 (UTC) FILETIME=[FDF4EA60:01BFBFDC] Sender: owner-mpls@UU.NET Precedence: bulk Hi, to answer your question finally: both protocols have TE extensions defined and those extensions have the same fields. So, from MPLS TE point of view they are equally good. btw.: the IS-IS extensions for Traffic Engineering," Internet Draft, draft-ietf-isis-traffic-01.txt, May 1999 is expired. Anyone updating it? Where could it be found? regards - Gabor At 08:22 05/16/2000 -0400, HANSEN CHAN wrote: >Hi all, > >I have been hearing IS-IS is a better protocol to be used than OSPF in a MPLS >network for TE application. Is that a fair statement? What are the technical >reasons? From owner-mpls@UU.NET Wed May 17 08:07: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 ESMTP id IAA03499 for ; Wed, 17 May 2000 08:07: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 QQipoi06173; Wed, 17 May 2000 12:07:30 GMT Received: by mail-control.mail.uu.net id QQipoi27326 for mpls-outgoing; Wed, 17 May 2000 12:06:57 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 QQipoi27293 for ; Wed, 17 May 2000 12:06:54 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 QQipoi13274 for ; Wed, 17 May 2000 08:06:53 -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 QQipoi05650 for ; Wed, 17 May 2000 12:06:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA19659 for mpls@uu.net; Wed, 17 May 2000 08:06:46 -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 QQipoi26972 for ; Wed, 17 May 2000 12:06: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 QQipoi13211 for ; Wed, 17 May 2000 08:06:11 -0400 (EDT) Received: from pentagon.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pentagon.cisco.com [161.44.197.12]) id QQipoi05783 for ; Wed, 17 May 2000 12:06:10 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA09306; Wed, 17 May 2000 08:05:29 -0400 (EDT) Message-Id: <4.2.2.20000517080453.071b4a40@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 17 May 2000 08:05:27 -0400 To: Paul Langille , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Two minor comments on draft-ietf-mpls-te-mib-03.txt Cc: arun@force10networks.com, cheenu@tachion.com In-Reply-To: <3921D44C.B1C0D0DC@crescentnets.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1081963==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_1081963==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks Paul. We will incorporate these comments into the edits we are now doing for the current version. --Tom > Tom, Arun, Cheenu. Here are two minor comments on >draft-ietf-mpls-te-mib-03.txt. > >1) Some more text around the MplsTunnelIndex and MplsTunnelInstance >would be helpful. For example, the description in the 'Textual >Conventions' is accurate but brief. The description in the >MplsTunnelIndex object ("Uniquely identifies this row.") is confusing. >Some examples would also help. (This is probably the same thing that >Adrian Farrel was requesting in his message.) If I get sometime 'spare' >time I will send you some text but don't hold your breath! > >2) The syntax for the MplsTunnelInstance object is "MplsTunnelIndex" and >it should be "MplsTunnelInstance". (Looks like a cut and paste error.) > > Paul > > > >-- >Paul Langille e-mail: langille@crescentnets.com >Crescent Networks phone: (978) 244-9002 x244 >201 Riverneck Road fax: (978) 244-9211 >Chelmsford, MA 01824 > > --=====================_1081963==_.ALT Content-Type: text/html; charset="us-ascii"
        Thanks Paul. We will incorporate these comments
into the edits we are now doing for the current version.

        --Tom



    Tom, Arun, Cheenu. Here are two minor comments on
draft-ietf-mpls-te-mib-03.txt.

1) Some more text around the MplsTunnelIndex and MplsTunnelInstance
would be helpful. For example, the description in the 'Textual
Conventions' is accurate but brief. The description in the
MplsTunnelIndex object ("Uniquely identifies this row.") is confusing.
Some examples would also help. (This is probably the same thing that
Adrian Farrel was requesting in his message.) If I get sometime 'spare'
time I will send you some text but don't hold your breath!

2) The syntax for the MplsTunnelInstance object is "MplsTunnelIndex" and
it should be "MplsTunnelInstance". (Looks like a cut and paste error.)

        Paul



--
Paul Langille                e-mail: langille@crescentnets.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824


--=====================_1081963==_.ALT-- From owner-mpls@UU.NET Wed May 17 08:07: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 IAA03510 for ; Wed, 17 May 2000 08:07: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 QQipoi06854; Wed, 17 May 2000 12:07:34 GMT Received: by mail-control.mail.uu.net id QQipoi27394 for mpls-outgoing; Wed, 17 May 2000 12:07: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 QQipoi27358 for ; Wed, 17 May 2000 12:07: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 QQipoi16983 for ; Wed, 17 May 2000 08:06:58 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQipoi06377 for ; Wed, 17 May 2000 12:06:57 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4HBsZH19962 for ; Wed, 17 May 2000 13:54:35 +0200 (MET DST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4HC06n22235 for ; Wed, 17 May 2000 14:00:06 +0200 (MET DST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FUP00C01AX336@mbb1.ericsson.se> for mpls@UU.NET; Wed, 17 May 2000 13:07:51 +0200 (MET DST) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FUP00OH5AX25Z@mbb1.ericsson.se>; Wed, 17 May 2000 13:07:51 +0200 (MET DST) Date: Wed, 17 May 2000 13:06:48 +0200 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: Question:draft-ietf-mpls-atm-03.txt To: Levi Daphna Cc: "'mpls@UU.NET'" Message-id: <39227D48.A1F230D@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Via management system, e.g in the LDP case you use the following object in the LDP MIB mplsLdpEntityDefaultControlVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The default VPI value for the non-MPLS connection. The default value of this is 0 (zero) but other values may be configured. This object allows a different value to be configured." REFERENCE "draft-ietf-mpls-atm-02.txt, Section 7.1" DEFVAL { 0 } ::= { mplsLdpEntityAtmParmsEntry 6 } Regards /// Hasse Levi Daphna wrote: > > Hi > > I have a question concerning the MPLS-ATM draft. > In paragraph 7.2 we deal with the scenario of ATM-LSRs which are connected > via an ATM VP cloud. (to my understanding this is an overlay model ) > 7.2. Connections via an ATM VP > Sometimes it can be useful to treat two LSRs as adjacent (in some LSP) > across an LC-ATM interface, even though the connection between them is made > through an ATM "cloud" via an ATM Virtual Path. In this case, the VPI field > is not available to MPLS, and the label MUST be encoded entirely within the > VCI field. > In this case, the default VCI value of the non-MPLS connection between the > LSRs is 32. Other values can be configured, as long as both parties are > aware of the configured value. The VPI is set to whatever is required to > make use of the Virtual Path. > > My question is: How do we set the VPI value, is it through a management > system or is there some signaling between the ATM-LSR and the VP switch. > > Thanks in advance, > Daphna From owner-mpls@UU.NET Wed May 17 08:28: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 IAA03934 for ; Wed, 17 May 2000 08:28: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 QQipoj21059; Wed, 17 May 2000 12:28:33 GMT Received: by mail-control.mail.uu.net id QQipoj03516 for mpls-outgoing; Wed, 17 May 2000 12:27:57 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 QQipoj03511 for ; Wed, 17 May 2000 12: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 QQipoj15084 for ; Wed, 17 May 2000 08:27:28 -0400 (EDT) Received: from blsmsgims02.bls.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: iocfirewall2ext.bls.com [139.76.64.4]) id QQipoj19831 for ; Wed, 17 May 2000 12:27:27 GMT Received: from SMTP (blsmsgims02.bls.com [139.76.86.32]) by blsmsgims02.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KLHZNZF5; Wed, 17 May 2000 08:27:27 -0400 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 17 May 2000 12:27:27 0000 (GMT) Received: from gf5142_gxsmlg (bos13564.ga.bst.bls.com [90.132.7.141]) by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id IAA18781; Wed, 17 May 2000 08:27:13 -0400 (EDT) From: "Steven Wright" To: , "'ksreeni'" Cc: "'Shahram Davari'" , "'mpls'" Subject: RE: ILM mappings Date: Wed, 17 May 2000 08:25:02 -0400 Message-ID: <000401bfbffa$ed5df430$320f2357@gf5142_gxsmlg.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 In-Reply-To: <39179D21.498A3044@mindspring.com> X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric,Sreeni, While the architecture draft does mention load balance as an example application of multiple NHLFEs, this seems more of an aside than a specification. As Eric notes the Architecture spec does not specify how to do this. If we leave multicast and Load balance as both applications that use this, I think we are confusing the semantics of this table. It seems to me that a replicated entry in the NHLFE corresponds to replication i.e.. multicast, but not to load balance, which perhaps should be treated in other ways. Does anyone know whether there was extensive discussion on this by the architecture team ? regards Steven Wright > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Eric Gray > Sent: Tuesday, May 09, 2000 1:08 AM > To: ksreeni > Cc: Shahram Davari; mpls > Subject: Re: ILM mappings > > > Sreeni, > > To save someone else the trouble of pointing it out, > the architecture draft specifically mentions load balancing > as an application for more than one NHLFE. You could > stretch a point and say that - when using liberal retention > - you have a veritable horde of NHLFEs for each ILM. > This assumes that you actually store an entire NHLFE > for each redundant Label Mapping (rather than just the > peer-label-FEC tuple) - but this is the same assumption > made in the redundant path example you mentioned. > > So you have multicast, multipath, E-LSP DiffServ, > redundancy and possibly other uses for having more > than one NHLFE for any given ILM. The point is that > you would need to ensure - within your implementation - > that the LSR is able to determine what NHLFE is to be > used for any ILM. > > The architecture draft punts on how this is to be done, > but the only case I can come up with where the LSR may > not be able to correctly determine which NHLFE to pick > is the case where the implementation allows more than one > NHLFE to be associated with a single ILM (for example, > via configuration) with out requiring a context within which > to interpret this association (e.g. - load balancing, multicast, > redundancy, etc.). > > This is probably a mildly pathological case. Even in this > case, you can simply document what the implementation > will do (since it must chose exactly one NHLFE for every > individual packet) and let the user figure out whether or not > that is what they want to happen. Maybe the implementation > always picks the first one configured, maybe it picks the one > associated with the lowest interface ID or maybe it round > robins all associated NHLFEs. In other cases mentioned > so far, you won't get to the point where you have more than > one NHLFE per ILM without being able to deal with it. > > So the question is an interesting one and it still comes down > to "how did there get to be multiple NHLFEs for a single > incoming label?" And the discussion comes full circle and I > sit out the next few dances. > > -- > Eric Gray > > ksreeni wrote: > > > Hi Sharam, > > The first scenario you mentioned is > diffserv supported LSP. In > > the constraint based routing an LSR can maintain more than > one LSP ( more than > > one NHLFE ) for backup path . This is also one more case we > can consider. > > > > Sreeni. > > > > Shahram Davari wrote: > > > > > Hi Eric, > > > > > > There are two scenarios that a single label may > correspond to multiple > > > NHLFEs: > > > > > > 1) Some part of an LSP is E-LSP and another part is L-LSP > > > 2) In case of Multicast. > > > > > > Regards, > > > Shahram Davari > > > Product Research > > > PMC-Sierra Inc. > > > 555 Legget drive, > > > Suit 834, Tower B, > > > Ottawa, ON K2K 2X3, Canada > > > Phone: +1 (613) 271-4018 > > > Fax : +1 (613) 271-7007 > > > > > > > > > -----Original Message----- > > > From: Eric Gray [mailto:EGray@zaffire.com] > > > Sent: Monday, May 08, 2000 12:51 PM > > > To: 'Trilok Chand' > > > Cc: mpls@UU.NET > > > Subject: RE: ILM mappings > > > > > > TrilokChand, > > > > > > An interesting question. How did there get to be multiple > > > NHLFEs for a single incoming label? Suspending disbelief > > > on this for a moment, however, and supposing there was a > > > reason for this to happen - the implementer must have had > > > some plan for demultiplexing the single label to determine > > > which NHLFE would be used. One way might be to pop the > > > label and look at what comes after it - but a pop instruction > > > should be a single NHLFE (with - in this case - a next hop > > > of "self"). Is there a useful application for this scenario? > > > > > > It seems to me that there would not be multiple NHLFE > > > entries for a single label as this will defeat the purpose for > > > having a label. But, even if there was a reason to do this, > > > the implementation that causes this to happen is the same > > > implementation that has to deal with the outcome. > > > > > > If you shoot yourself in the foot, it will hurt. :-) > > > > > > -- > > > Eric Gray > > > > > > -----Original Message----- > > > From: Trilok Chand [mailto:trilok@chiplogic.com] > > > Sent: Monday, May 08, 2000 3:25 AM > > > To: mpls@UU.NET > > > Subject: ILM mappings > > > > > > Hi, > > > Can anybody tell where can i get information > about choosing an ILM > > > mapping when there are multiple NHLFEs existing for an > incoming label? > > > > > > Thanks in advance, > > > TrilokChand > > > > > > From owner-mpls@UU.NET Wed May 17 08:33: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 IAA04140 for ; Wed, 17 May 2000 08:33: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 QQipok24551; Wed, 17 May 2000 12:33:10 GMT Received: by mail-control.mail.uu.net id QQipok03834 for mpls-outgoing; Wed, 17 May 2000 12:32: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 QQipok03818 for ; Wed, 17 May 2000 12:32:23 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 QQipok15680 for ; Wed, 17 May 2000 08:32:07 -0400 (EDT) Received: from blsmsgims02.bls.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: iocfirewall2ext.bls.com [139.76.64.4]) id QQipok23291 for ; Wed, 17 May 2000 12:32:07 GMT Received: from SMTP (blsmsgims02.bls.com [139.76.86.32]) by blsmsgims02.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KLHZN5CC; Wed, 17 May 2000 08:32:07 -0400 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 17 May 2000 12:32:07 0000 (GMT) Received: from gf5142_gxsmlg (bos13564.ga.bst.bls.com [90.132.7.141]) by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id IAA18874; Wed, 17 May 2000 08:31:55 -0400 (EDT) From: "Steven Wright" To: "'ksreeni'" , "'mpls'" Subject: RE: basic questions Date: Wed, 17 May 2000 08:29:45 -0400 Message-ID: <000501bfbffb$95d7d630$320f2357@gf5142_gxsmlg.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 In-Reply-To: <391798DE.894A24A9@chiplogic.com> X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 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 ksreeni > Sent: Tuesday, May 09, 2000 12:50 AM > To: mpls > Subject: basic questions > > > Hi, > I have some basic questions on the deployment of MPLS > in LAN and > QOS . Can somebody resolve the following questions? > > There is one router at customer place having 3 hosts in > the subnet > and it is connected to ISP through WAN > link. And ISP is an LER in the MPLS domain. > (1) Do I need to deploy MPLS on my router? If yes, > what are the > > benifits? MPLS provides an explicit routing mechanism. If you need to segregate you traffic into different routes ( e.g. to support VPNs ) then there may be some application for mpls at the router and/or hosts. that does not mean you could not do it any other way ... > (2) As per my knowledge , I am not finding any > necessity of MPLS > > & LDP on end Host. Is that correct? Unless your end hosts have to support multiple E-R VPNs ( which seems unlikley in the short term ?) > (3) If ISP provides QOS based on the COS field in the SHIM > header and the customer subscribed some BW at ISP. Then , Is that > possible for ISP to policy the customer traffic at MPLS layer itself? > > Thanks, > Sreeni. > > > > From owner-mpls@UU.NET Wed May 17 09:19: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 ESMTP id JAA04725 for ; Wed, 17 May 2000 09:19: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 QQipon27670; Wed, 17 May 2000 13:19:43 GMT Received: by mail-control.mail.uu.net id QQipon15536 for mpls-outgoing; Wed, 17 May 2000 13:19: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 QQipon15531 for ; Wed, 17 May 2000 13:18:55 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 QQipon20696 for ; Wed, 17 May 2000 09:18:48 -0400 (EDT) Received: from smtp10.atl.mindspring.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp10.atl.mindspring.net [207.69.200.246]) id QQipon26241 for ; Wed, 17 May 2000 13:18:48 GMT Received: from mindspring.com (user-33qtk2d.dialup.mindspring.com [199.174.208.77]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id JAA25363; Wed, 17 May 2000 09:18:35 -0400 (EDT) Message-ID: <39229CE7.6FE11B98@mindspring.com> Date: Wed, 17 May 2000 06:21:43 -0700 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Steven Wright CC: ksreeni@chiplogic.com, Shahram Davari , MPLS List Subject: Re: ILM mappings References: <000401bfbffa$ed5df430$320f2357@gf5142_gxsmlg.bst.bls.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Steven, Oh dear, must be my turn again. :-) Multiple NHLFEs for a single ILM does not necessarily mean that the entries are replicated. They could be spares or alternatives. I guess that one reason why the question of what to do when there are multiple NHLFEs comes up is based on an assumption that the implementation just sort of woke up and found them there. I can't say that this is necessarily a bad assumption. So I think the answer has to be that there is an implied field in each NHLFE that defines the action to be taken if the NHLFE is one of many. That does not mean that a specific implementation has to do it that way. If you assume that an NHLFE cannot be created without some value being plugged into this implied field, then the ambiguity is diminished, right? However, it's not so simple that the ambiguity goes away with just this piece. What do you do if the value in this implied field is not consistent for all NHLFE matched by any particular ILM? Stuff that helps is that there are other ways to determine what to do. For example, the encapsulation draft defines specific code points to be used for unicast and multicast for PPP and Ethernet. Frame Relay and ATM assume that labels are assigned such that unicast and multicast use distinct labels (implying that ILM to NHLFE mappings for ATM/FR cannot have unicast/multicast ambiguity, further implying that the implementation must enforce this restriction). Thus, at least the unicast/multicast issue was finessed some time back. The implementation can work out what to do in some of the other cases, but not all of them. So, an implementation either has a means to resolve ambiguous ILM to NHLFE mappings, it explicitly prevents them from being created or it is headed for a nervous break-down. -- Eric Gray Steven Wright wrote: > Eric,Sreeni, > While the architecture draft does mention load balance as an example > application of multiple NHLFEs, this seems more of an aside than a > specification. As Eric notes the Architecture spec does not specify how to > do this. > If we leave multicast and Load balance as both applications that use this, I > think we are confusing the semantics of this table. It seems to me that a > replicated entry in the NHLFE corresponds to replication i.e.. multicast, > but not to load balance, which perhaps should be treated in other ways. > Does anyone know whether there was extensive discussion on this by the > architecture team ? > regards > Steven Wright > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > > Of Eric Gray > > Sent: Tuesday, May 09, 2000 1:08 AM > > To: ksreeni > > Cc: Shahram Davari; mpls > > Subject: Re: ILM mappings > > > > > > Sreeni, > > > > To save someone else the trouble of pointing it out, > > the architecture draft specifically mentions load balancing > > as an application for more than one NHLFE. You could > > stretch a point and say that - when using liberal retention > > - you have a veritable horde of NHLFEs for each ILM. > > This assumes that you actually store an entire NHLFE > > for each redundant Label Mapping (rather than just the > > peer-label-FEC tuple) - but this is the same assumption > > made in the redundant path example you mentioned. > > > > So you have multicast, multipath, E-LSP DiffServ, > > redundancy and possibly other uses for having more > > than one NHLFE for any given ILM. The point is that > > you would need to ensure - within your implementation - > > that the LSR is able to determine what NHLFE is to be > > used for any ILM. > > > > The architecture draft punts on how this is to be done, > > but the only case I can come up with where the LSR may > > not be able to correctly determine which NHLFE to pick > > is the case where the implementation allows more than one > > NHLFE to be associated with a single ILM (for example, > > via configuration) with out requiring a context within which > > to interpret this association (e.g. - load balancing, multicast, > > redundancy, etc.). > > > > This is probably a mildly pathological case. Even in this > > case, you can simply document what the implementation > > will do (since it must chose exactly one NHLFE for every > > individual packet) and let the user figure out whether or not > > that is what they want to happen. Maybe the implementation > > always picks the first one configured, maybe it picks the one > > associated with the lowest interface ID or maybe it round > > robins all associated NHLFEs. In other cases mentioned > > so far, you won't get to the point where you have more than > > one NHLFE per ILM without being able to deal with it. > > > > So the question is an interesting one and it still comes down > > to "how did there get to be multiple NHLFEs for a single > > incoming label?" And the discussion comes full circle and I > > sit out the next few dances. > > > > -- > > Eric Gray > > > > ksreeni wrote: > > > > > Hi Sharam, > > > The first scenario you mentioned is > > diffserv supported LSP. In > > > the constraint based routing an LSR can maintain more than > > one LSP ( more than > > > one NHLFE ) for backup path . This is also one more case we > > can consider. > > > > > > Sreeni. > > > > > > Shahram Davari wrote: > > > > > > > Hi Eric, > > > > > > > > There are two scenarios that a single label may > > correspond to multiple > > > > NHLFEs: > > > > > > > > 1) Some part of an LSP is E-LSP and another part is L-LSP > > > > 2) In case of Multicast. > > > > > > > > Regards, > > > > Shahram Davari > > > > Product Research > > > > PMC-Sierra Inc. > > > > 555 Legget drive, > > > > Suit 834, Tower B, > > > > Ottawa, ON K2K 2X3, Canada > > > > Phone: +1 (613) 271-4018 > > > > Fax : +1 (613) 271-7007 > > > > > > > > > > > > -----Original Message----- > > > > From: Eric Gray [mailto:EGray@zaffire.com] > > > > Sent: Monday, May 08, 2000 12:51 PM > > > > To: 'Trilok Chand' > > > > Cc: mpls@UU.NET > > > > Subject: RE: ILM mappings > > > > > > > > TrilokChand, > > > > > > > > An interesting question. How did there get to be multiple > > > > NHLFEs for a single incoming label? Suspending disbelief > > > > on this for a moment, however, and supposing there was a > > > > reason for this to happen - the implementer must have had > > > > some plan for demultiplexing the single label to determine > > > > which NHLFE would be used. One way might be to pop the > > > > label and look at what comes after it - but a pop instruction > > > > should be a single NHLFE (with - in this case - a next hop > > > > of "self"). Is there a useful application for this scenario? > > > > > > > > It seems to me that there would not be multiple NHLFE > > > > entries for a single label as this will defeat the purpose for > > > > having a label. But, even if there was a reason to do this, > > > > the implementation that causes this to happen is the same > > > > implementation that has to deal with the outcome. > > > > > > > > If you shoot yourself in the foot, it will hurt. :-) > > > > > > > > -- > > > > Eric Gray > > > > > > > > -----Original Message----- > > > > From: Trilok Chand [mailto:trilok@chiplogic.com] > > > > Sent: Monday, May 08, 2000 3:25 AM > > > > To: mpls@UU.NET > > > > Subject: ILM mappings > > > > > > > > Hi, > > > > Can anybody tell where can i get information > > about choosing an ILM > > > > mapping when there are multiple NHLFEs existing for an > > incoming label? > > > > > > > > Thanks in advance, > > > > TrilokChand > > > > > > > > > > From owner-mpls@UU.NET Wed May 17 09:38: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 ESMTP id JAA04989 for ; Wed, 17 May 2000 09:38:36 -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 QQipoo11981; Wed, 17 May 2000 13:38:31 GMT Received: by mail-control.mail.uu.net id QQipoo16638 for mpls-outgoing; Wed, 17 May 2000 13:38:06 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 QQipoo16631 for ; Wed, 17 May 2000 13:37: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 QQipoo28777 for ; Wed, 17 May 2000 09:37:38 -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 QQipoo11210 for ; Wed, 17 May 2000 13:37:37 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 KK6NBD85; Wed, 17 May 2000 09:40:04 -0400 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.35 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 17 May 2000 13:40:04 0000 (GMT) Received: from gf5142_gxsmlg (bos13564.ga.bst.bls.com [90.132.7.141]) by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id JAA20208; Wed, 17 May 2000 09:37:22 -0400 (EDT) From: "Steven Wright" To: Cc: , "'Shahram Davari'" , "'MPLS List'" Subject: RE: ILM mappings Date: Wed, 17 May 2000 09:35:10 -0400 Message-ID: <000601bfc004$b9fa8b30$320f2357@gf5142_gxsmlg.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 In-Reply-To: <39229CE7.6FE11B98@mindspring.com> X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit My turn 8^} I agree multiple NHLFEs is somewhat unusual. I agree the router can find a way to resolve the ambiguity, but that was not my concern. I have two questions... 1) I think the netwok management must be able to understand what is happening in this case and this implies that the "implicit" NHLFE entry should be made explicit in some device MIB.If this is standard behavior then this should be a standard MIB. 2)Even though the router may be constructed do it this way, is it the right thing to do? Was there a rationale for the architecture team to mix replication and load balancing in this way ? I think there are other approaches for load balancing that are more intuitive and avoid having these multiple NHLFE entries in the first place... regards Steven Wright > -----Original Message----- > From: Eric Gray [mailto:ewgray@mindspring.com] > Sent: Wednesday, May 17, 2000 9:22 AM > To: Steven Wright > Cc: ksreeni@chiplogic.com; Shahram Davari; MPLS List > Subject: Re: ILM mappings > > > Steven, > > Oh dear, must be my turn again. :-) > > Multiple NHLFEs for a single ILM does not necessarily > mean that the entries are replicated. They could be spares > or alternatives. > > I guess that one reason why the question of what to do > when there are multiple NHLFEs comes up is based on an > assumption that the implementation just sort of woke up > and found them there. I can't say that this is necessarily a > bad assumption. > > So I think the answer has to be that there is an implied > field in each NHLFE that defines the action to be taken if > the NHLFE is one of many. That does not mean that a > specific implementation has to do it that way. > > If you assume that an NHLFE cannot be created without > some value being plugged into this implied field, then the > ambiguity is diminished, right? However, it's not so simple > that the ambiguity goes away with just this piece. What do > you do if the value in this implied field is not consistent for > all NHLFE matched by any particular ILM? > > Stuff that helps is that there are other ways to determine > what to do. For example, the encapsulation draft defines > specific code points to be used for unicast and multicast for > PPP and Ethernet. Frame Relay and ATM assume that labels > are assigned such that unicast and multicast use distinct labels > (implying that ILM to NHLFE mappings for ATM/FR cannot > have unicast/multicast ambiguity, further implying that the > implementation must enforce this restriction). Thus, at least > the unicast/multicast issue was finessed some time back. > > The implementation can work out what to do in some of > the other cases, but not all of them. So, an implementation > either has a means to resolve ambiguous ILM to NHLFE > mappings, it explicitly prevents them from being created or > it is headed for a nervous break-down. > > -- > Eric Gray > > Steven Wright wrote: > > > Eric,Sreeni, > > While the architecture draft does mention load balance as an example > > application of multiple NHLFEs, this seems more of an aside than a > > specification. As Eric notes the Architecture spec does not > specify how to > > do this. > > If we leave multicast and Load balance as both applications > that use this, I > > think we are confusing the semantics of this table. It > seems to me that a > > replicated entry in the NHLFE corresponds to replication > i.e.. multicast, > > but not to load balance, which perhaps should be treated in > other ways. > > Does anyone know whether there was extensive discussion on > this by the > > architecture team ? > > regards > > Steven Wright > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > > > Of Eric Gray > > > Sent: Tuesday, May 09, 2000 1:08 AM > > > To: ksreeni > > > Cc: Shahram Davari; mpls > > > Subject: Re: ILM mappings > > > > > > > > > Sreeni, > > > > > > To save someone else the trouble of pointing it out, > > > the architecture draft specifically mentions load balancing > > > as an application for more than one NHLFE. You could > > > stretch a point and say that - when using liberal retention > > > - you have a veritable horde of NHLFEs for each ILM. > > > This assumes that you actually store an entire NHLFE > > > for each redundant Label Mapping (rather than just the > > > peer-label-FEC tuple) - but this is the same assumption > > > made in the redundant path example you mentioned. > > > > > > So you have multicast, multipath, E-LSP DiffServ, > > > redundancy and possibly other uses for having more > > > than one NHLFE for any given ILM. The point is that > > > you would need to ensure - within your implementation - > > > that the LSR is able to determine what NHLFE is to be > > > used for any ILM. > > > > > > The architecture draft punts on how this is to be done, > > > but the only case I can come up with where the LSR may > > > not be able to correctly determine which NHLFE to pick > > > is the case where the implementation allows more than one > > > NHLFE to be associated with a single ILM (for example, > > > via configuration) with out requiring a context within which > > > to interpret this association (e.g. - load balancing, multicast, > > > redundancy, etc.). > > > > > > This is probably a mildly pathological case. Even in this > > > case, you can simply document what the implementation > > > will do (since it must chose exactly one NHLFE for every > > > individual packet) and let the user figure out whether or not > > > that is what they want to happen. Maybe the implementation > > > always picks the first one configured, maybe it picks the one > > > associated with the lowest interface ID or maybe it round > > > robins all associated NHLFEs. In other cases mentioned > > > so far, you won't get to the point where you have more than > > > one NHLFE per ILM without being able to deal with it. > > > > > > So the question is an interesting one and it still comes down > > > to "how did there get to be multiple NHLFEs for a single > > > incoming label?" And the discussion comes full circle and I > > > sit out the next few dances. > > > > > > -- > > > Eric Gray > > > > > > ksreeni wrote: > > > > > > > Hi Sharam, > > > > The first scenario you mentioned is > > > diffserv supported LSP. In > > > > the constraint based routing an LSR can maintain more than > > > one LSP ( more than > > > > one NHLFE ) for backup path . This is also one more case we > > > can consider. > > > > > > > > Sreeni. > > > > > > > > Shahram Davari wrote: > > > > > > > > > Hi Eric, > > > > > > > > > > There are two scenarios that a single label may > > > correspond to multiple > > > > > NHLFEs: > > > > > > > > > > 1) Some part of an LSP is E-LSP and another part is L-LSP > > > > > 2) In case of Multicast. > > > > > > > > > > Regards, > > > > > Shahram Davari > > > > > Product Research > > > > > PMC-Sierra Inc. > > > > > 555 Legget drive, > > > > > Suit 834, Tower B, > > > > > Ottawa, ON K2K 2X3, Canada > > > > > Phone: +1 (613) 271-4018 > > > > > Fax : +1 (613) 271-7007 > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Eric Gray [mailto:EGray@zaffire.com] > > > > > Sent: Monday, May 08, 2000 12:51 PM > > > > > To: 'Trilok Chand' > > > > > Cc: mpls@UU.NET > > > > > Subject: RE: ILM mappings > > > > > > > > > > TrilokChand, > > > > > > > > > > An interesting question. How did there get to be multiple > > > > > NHLFEs for a single incoming label? Suspending disbelief > > > > > on this for a moment, however, and supposing there was a > > > > > reason for this to happen - the implementer must have had > > > > > some plan for demultiplexing the single label to determine > > > > > which NHLFE would be used. One way might be to pop the > > > > > label and look at what comes after it - but a pop instruction > > > > > should be a single NHLFE (with - in this case - a next hop > > > > > of "self"). Is there a useful application for this scenario? > > > > > > > > > > It seems to me that there would not be multiple NHLFE > > > > > entries for a single label as this will defeat the purpose for > > > > > having a label. But, even if there was a reason to do this, > > > > > the implementation that causes this to happen is the same > > > > > implementation that has to deal with the outcome. > > > > > > > > > > If you shoot yourself in the foot, it will hurt. :-) > > > > > > > > > > -- > > > > > Eric Gray > > > > > > > > > > -----Original Message----- > > > > > From: Trilok Chand [mailto:trilok@chiplogic.com] > > > > > Sent: Monday, May 08, 2000 3:25 AM > > > > > To: mpls@UU.NET > > > > > Subject: ILM mappings > > > > > > > > > > Hi, > > > > > Can anybody tell where can i get information > > > about choosing an ILM > > > > > mapping when there are multiple NHLFEs existing for an > > > incoming label? > > > > > > > > > > Thanks in advance, > > > > > TrilokChand > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Wed May 17 11:58: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 ESMTP id LAA06775 for ; Wed, 17 May 2000 11:58: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 QQipox02114; Wed, 17 May 2000 15:58:25 GMT Received: by mail-control.mail.uu.net id QQipox13342 for mpls-outgoing; Wed, 17 May 2000 15:58: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 QQipox13337 for ; Wed, 17 May 2000 15:57: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 QQipox21834 for ; Wed, 17 May 2000 11:57:52 -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 QQipox01490 for ; Wed, 17 May 2000 15:57:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA21271 for mpls@uu.net; Wed, 17 May 2000 11:57:51 -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 QQipox13280 for ; Wed, 17 May 2000 15:57: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 QQipox21712 for ; Wed, 17 May 2000 11:57:06 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQipox29274 for ; Wed, 17 May 2000 15:57:05 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA23297; Wed, 17 May 2000 08:55:12 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 08:55:12 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4057C@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Levi Daphna'" , "'mpls@UU.NET'" Subject: RE: Question:draft-ietf-mpls-atm-03.txt Date: Wed, 17 May 2000 08:52:24 -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, LDP is used for this purpose between ATM-LSRs. LDP uses "ATM Label Range component", which is used during LDP initialization. The ATM switches in the cloud do not need to know anything about MPLS. They pass MPLS or non-MPLS traffic transparently. Regards -Shahram >-----Original Message----- >From: Levi Daphna [mailto:Daphna.Levi@ecitele.com] >Sent: Wednesday, May 17, 2000 4:24 AM >To: 'mpls@UU.NET' >Subject: Question:draft-ietf-mpls-atm-03.txt > > >Hi > >I have a question concerning the MPLS-ATM draft. >In paragraph 7.2 we deal with the scenario of ATM-LSRs which >are connected >via an ATM VP cloud. (to my understanding this is an overlay model ) >7.2. Connections via an ATM VP >Sometimes it can be useful to treat two LSRs as adjacent (in some LSP) >across an LC-ATM interface, even though the connection between >them is made >through an ATM "cloud" via an ATM Virtual Path. In this case, >the VPI field >is not available to MPLS, and the label MUST be encoded >entirely within the >VCI field. >In this case, the default VCI value of the non-MPLS connection >between the >LSRs is 32. Other values can be configured, as long as both parties are >aware of the configured value. The VPI is set to whatever is >required to >make use of the Virtual Path. > >My question is: How do we set the VPI value, is it through a management >system or is there some signaling between the ATM-LSR and the >VP switch. > >Thanks in advance, >Daphna > > From owner-mpls@UU.NET Wed May 17 12:14: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 MAA07682 for ; Wed, 17 May 2000 12:14: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 QQipoy13192; Wed, 17 May 2000 16:13:58 GMT Received: by mail-control.mail.uu.net id QQipoy22890 for mpls-outgoing; Wed, 17 May 2000 16: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 QQipoy22877 for ; Wed, 17 May 2000 16:13: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 QQipoy24024 for ; Wed, 17 May 2000 12:12:56 -0400 (EDT) Received: from neptun.sns-felb.debis.de by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: neptun.sns-felb.debis.de [53.122.101.2]) id QQipoy10452 for ; Wed, 17 May 2000 16:12:55 GMT Received: by neptun.sns-felb.debis.de; id SAA01746; Wed, 17 May 2000 18:15:18 +0200 Received: from unknown(53.47.15.3) by neptun.sns-felb.debis.de via smap (V5.0) id xma001716; Wed, 17 May 00 18:15:08 +0200 Received: from debis.com (localhost [127.0.0.1]) by dshmail.dsh.de (8.8.7/8.8.7) with ESMTP id SAA12393; Wed, 17 May 2000 18:11:36 +0200 (MET DST) Message-ID: <3922C500.86F2BF9B@debis.com> Date: Wed, 17 May 2000 18:12:49 +0200 From: Klaus-Dieter Lehle X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: MPLS List Subject: Networkmanagementapplication for Cisco Content-Type: multipart/mixed; boundary="------------A91172977123CC860AFCC92D" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------A91172977123CC860AFCC92D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo all, we want to bring up an MPLS-network with Ciscoequipment. Know we are looking for an Managementtool. Does anybody know other tools than the Cisco VPN-Solution-Center??? Thank you Klaus-Dieter --------------A91172977123CC860AFCC92D Content-Type: text/x-vcard; charset=us-ascii; name="klehle.vcf" Content-Description: Card for Klaus-Dieter Lehle Content-Disposition: attachment; filename="klehle.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Lehle;Klaus-Dieter x-mozilla-html:FALSE org:debis Systemhaus GmbH version:2.1 email;internet:lehle@str.daimler-benz.com tel;fax:++49/711/17-49371 tel;work:++49/711/17-40314 adr;quoted-printable:;;Abteilung TKS/PP=0D=0AErich-Herion-Str. 13;70736 Fellbach;;;Germany x-mozilla-cpt:;52896 fn:Klaus-Dieter Lehle end:vcard --------------A91172977123CC860AFCC92D-- From owner-mpls@UU.NET Wed May 17 12:28: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 MAA07971 for ; Wed, 17 May 2000 12:28: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 QQipoz23604; Wed, 17 May 2000 16:27:52 GMT Received: by mail-control.mail.uu.net id QQipoz23804 for mpls-outgoing; Wed, 17 May 2000 16:27: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 QQipoz23792 for ; Wed, 17 May 2000 16:27: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 QQipoz26055 for ; Wed, 17 May 2000 12:27:13 -0400 (EDT) Received: from tcb.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQipoz22854 for ; Wed, 17 May 2000 16:27:13 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA12003 for ; Wed, 17 May 2000 10:28:34 -0600 Message-Id: <200005171628.KAA12003@tcb.net> To: mpls@UU.NET From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MPLS and IS-IS Date: Wed, 17 May 2000 10:28:34 -0600 Sender: owner-mpls@UU.NET Precedence: bulk > I find that companies building products that support both protocols have to > spend more time on bringing OSPF up to RFC compliancy (eg adding yet another > LSA type), because it's so well defined and attempts to solve so many > problems, rather than focusing on code and protocol optimizations that can > solve more pressing customer problems. I find that initially these companies first implement and stabilize the feature sets they're customers are asking for and *deploying*, then worry about the 'kitchen sink'. > I do believe the "perception" goes a little bit beyond implementation only > issues. I don't completely follow you here. Are you suggesting that implementation difficulty alone makes the OSPF routing protocol itself less scalable? While they're indeed related, they're still very separate things. -danny From owner-mpls@UU.NET Wed May 17 13: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 NAA09187 for ; Wed, 17 May 2000 13: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 QQippe13126; Wed, 17 May 2000 17:35:58 GMT Received: by mail-control.mail.uu.net id QQippe06005 for mpls-outgoing; Wed, 17 May 2000 17:35: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 QQippe05995 for ; Wed, 17 May 2000 17:35: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 QQippe05765 for ; Wed, 17 May 2000 13:35:09 -0400 (EDT) Received: from mailhost.metro-optix.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.metro-optix.com [63.91.47.254]) id QQippe11218 for ; Wed, 17 May 2000 17:35:09 GMT Received: by MAILHOST with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 12:36:09 -0500 Message-ID: From: David Wang To: "'HANSEN CHAN'" , mpls@UU.NET Subject: RE: MPLS and IS-IS Date: Wed, 17 May 2000 12:36:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi all, IS-IS is defined to work with CLNP not for IP originally. Until today a lot of SONET and telecommunication equipment vendors still use IS-IS to route CLNP packets through the SONET Data communication channel(DCC) to carry management information and there is a great pressure to change this to OSPF and IP. I also know that UUNET runs IS-IS on their network. I never heard any other networks run IS-IS. Seems I am wrong. My questions are. 1. You guys are talking about using IS-IS in a IP networks not in CLNP networks. The IS-IS has been modified according to RFC 1195 (Use of OSI IS-IS for Routing in TCP/IP and Dual Environments) or some other standard. Is this correct? 2. Besides UUNET, which ISPs run IS-IS protocol? Can you name a few? or what percentage of networks run IS-IS instead of OSPF? Thanks David -----Original Message----- From: HANSEN CHAN [mailto:hchan@newbridge.com] Sent: Tuesday, May 16, 2000 7:22 AM To: mpls@UU.NET Subject: MPLS and IS-IS Hi all, I have been hearing IS-IS is a better protocol to be used than OSPF in a MPLS network for TE application. Is that a fair statement? What are the technical reasons? Appreciate if someone can shed some light on this subject. Thanks, Hansen From owner-mpls@UU.NET Wed May 17 14:00: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 ESMTP id OAA09423 for ; Wed, 17 May 2000 14:00: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 QQippg01200; Wed, 17 May 2000 18:00:23 GMT Received: by mail-control.mail.uu.net id QQippg07464 for mpls-outgoing; Wed, 17 May 2000 18:00:01 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippf07373 for ; Wed, 17 May 2000 17:59:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippf18313 for ; Wed, 17 May 2000 13:59:51 -0400 (EDT) Received: from tcb.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQippf00520 for ; Wed, 17 May 2000 17:59:51 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id MAA13428 for ; Wed, 17 May 2000 12:01:12 -0600 Message-Id: <200005171801.MAA13428@tcb.net> To: mpls@UU.NET From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MPLS and IS-IS Date: Wed, 17 May 2000 12:01:12 -0600 Sender: owner-mpls@UU.NET Precedence: bulk > An overly complex design will almost certainly result in more difficult > implementation. More difficult implementations generally give rise to > more bugs. I believe there is a strong correlation between protocol > design quality and implementation quality and simply dismissing that > relationship seems rather ivory towerish. I'm not simply dismissing it, I'm dismissing the presumption that "ISIS scales better than OSPF, simply because a single implementation appears as such". Obviously, if something is more difficult to implement it's more bug-prone. However, that doesn't mean that it's a broken by design or will scale poorly. -danny From owner-mpls@UU.NET Wed May 17 14:15: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 OAA09584 for ; Wed, 17 May 2000 14:15: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 QQipph13005; Wed, 17 May 2000 18:15:29 GMT Received: by mail-control.mail.uu.net id QQipph17110 for mpls-outgoing; Wed, 17 May 2000 18:15:04 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipph17037 for ; Wed, 17 May 2000 18:15:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippg20292 for ; Wed, 17 May 2000 14:14:46 -0400 (EDT) Received: from tcb.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQippg12182 for ; Wed, 17 May 2000 18:14:42 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id MAA13851 for ; Wed, 17 May 2000 12:16:03 -0600 Message-Id: <200005171816.MAA13851@tcb.net> To: mpls@UU.NET From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MPLS and IS-IS Date: Wed, 17 May 2000 12:16:03 -0600 Sender: owner-mpls@UU.NET Precedence: bulk > IS-IS is defined to work with CLNP not for IP originally. Until today a lot > of SONET and telecommunication equipment vendors still use IS-IS to route > CLNP packets through the SONET Data communication channel(DCC) to carry > management information and there is a great pressure to change this to OSPF > and IP. I also know that UUNET runs IS-IS on their network. I never heard > any other networks run IS-IS. Seems I am wrong. My questions are. Note also that besides what Curtis/Dave mentioned wrt the state of a particular vendors implementation having an impact on which IGP legacy providers deployed, the capability of IS-IS to support both CLNP and IP should be considered. After all, a lot of the legacy ISP networks wanted to pickup NSF contracts at the time, contracts based on solicitations that required support of both IP and CLNP. Their desire to avoid a "ships in the night" approach, coupled with seemingly more stable IS-IS suuport, lead to an obvious outcome. > 1. You guys are talking about using IS-IS in a IP networks not in CLNP > networks. The IS-IS has been modified according to RFC 1195 (Use of OSI > IS-IS for Routing in TCP/IP and Dual Environments) or some other standard. > Is this correct? Yes. > 2. Besides UUNET, which ISPs run IS-IS protocol? Can you name a few? or > what percentage of networks run IS-IS instead of OSPF? Of the 7 largest US ISP networks (in my mind), 5 run IS-IS. -danny From owner-mpls@UU.NET Wed May 17 14:22: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 ESMTP id OAA09618 for ; Wed, 17 May 2000 14:22: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 QQipph17219; Wed, 17 May 2000 18:22:44 GMT Received: by mail-control.mail.uu.net id QQipph17655 for mpls-outgoing; Wed, 17 May 2000 18:22:23 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipph17649 for ; Wed, 17 May 2000 18:22:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipph21368 for ; Wed, 17 May 2000 14:22:19 -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 QQipph16800 for ; Wed, 17 May 2000 18:22:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA14613 for mpls@uu.net; Wed, 17 May 2000 14:22:18 -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 QQipph17584 for ; Wed, 17 May 2000 18:21: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 QQipph12910 for ; Wed, 17 May 2000 14:21:41 -0400 (EDT) Received: from ns01.newbridge.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQipph17757 for ; Wed, 17 May 2000 18:21:40 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id OAA04161 for ; Wed, 17 May 2000 14:15:28 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdDAA0ZDd1Y; Wed May 17 14:15:28 2000 Received: from hkmail01.ap.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@uu.net; Wed, 17 May 2000 14:21:41 -0400 Received: from newbridge.com ([138.120.44.36]) by hkmail01.ap.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA67F7 for ; Thu, 18 May 2000 02:21:33 +0800 Message-Id: <3922E261.69398441@newbridge.com> Date: Thu, 18 May 2000 02:18:09 +0800 From: "ABDUL RAZAQUE" Reply-To: armemon@newbridge.com Organization: Internal X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Subscribe Content-Type: multipart/mixed; boundary="------------F9D3AC4FEE9DE6163F04E79C" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------F9D3AC4FEE9DE6163F04E79C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------F9D3AC4FEE9DE6163F04E79C Content-Type: text/x-vcard; charset=us-ascii; name="armemon.vcf" Content-Description: Card for Abdul Razaque Memon Content-Disposition: attachment; filename="armemon.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:RAZAQUE;MEMON ABDUL tel;fax:+852-28072570 tel;work:+852-21048335 x-mozilla-html:FALSE url:http://www.newbridge.com org:Newbridge Learning services;Newbridge Networks Asia Ltd. adr:;;;HONG KONG;;; version:2.1 email;internet:armemon@newbridge.com title:Manager Customer Learning x-mozilla-cpt:;26352 fn:ABDUL RAZAQUE end:vcard --------------F9D3AC4FEE9DE6163F04E79C-- From owner-mpls@UU.NET Wed May 17 14:27: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 OAA09666 for ; Wed, 17 May 2000 14:27: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 QQipph20983; Wed, 17 May 2000 18:27:37 GMT Received: by mail-control.mail.uu.net id QQipph17975 for mpls-outgoing; Wed, 17 May 2000 18:27: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 QQipph17967 for ; Wed, 17 May 2000 18:26:45 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 QQipph13550 for ; Wed, 17 May 2000 14:26:35 -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 QQipph20125 for ; Wed, 17 May 2000 18:26:31 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 LAA09063 for ; Wed, 17 May 2000 11:26:37 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA19761 for mpls@uu.net; Wed, 17 May 2000 14:26: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 QQippe05993 for ; Wed, 17 May 2000 17:35:18 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 QQippe05742 for ; Wed, 17 May 2000 13:35:03 -0400 (EDT) Received: from tristero.cryptocourier.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQippe12422 for ; Wed, 17 May 2000 17:35:03 GMT Received: (qmail 16504 invoked from network); 17 May 2000 17:36:56 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 17 May 2000 17:36:56 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Wed, 17 May 2000 10:30:19 -0700 Date: Wed, 17 May 2000 10:30:19 -0700 From: Ben Black To: Danny McPherson Cc: mpls@UU.NET Subject: Re: MPLS and IS-IS Message-ID: <20000517103019.A1590@layer8.net> References: <200005171628.KAA12003@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.3i In-Reply-To: <200005171628.KAA12003@tcb.net>; from danny@tcb.net on Wed, May 17, 2000 at 10:28:34AM -0600 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, May 17, 2000 at 10:28:34AM -0600, Danny McPherson wrote: > > > I do believe the "perception" goes a little bit beyond implementation only > > issues. > > I don't completely follow you here. Are you suggesting that implementation > difficulty alone makes the OSPF routing protocol itself less scalable? While > they're indeed related, they're still very separate things. > An overly complex design will almost certainly result in more difficult implementation. More difficult implementations generally give rise to more bugs. I believe there is a strong correlation between protocol design quality and implementation quality and simply dismissing that relationship seems rather ivory towerish. Ben From owner-mpls@UU.NET Wed May 17 14:28: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 OAA09680 for ; Wed, 17 May 2000 14:28: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 QQipph22226; Wed, 17 May 2000 18:28:00 GMT Received: by mail-control.mail.uu.net id QQipph17984 for mpls-outgoing; Wed, 17 May 2000 18:27:23 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipph17979 for ; Wed, 17 May 2000 18:27:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipph21891 for ; Wed, 17 May 2000 14:26:54 -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 QQipph21295 for ; Wed, 17 May 2000 18:26:54 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 LAA06198 for ; Wed, 17 May 2000 11:27:00 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA19765 for mpls@uu.net; Wed, 17 May 2000 14:26: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 QQippf06891 for ; Wed, 17 May 2000 17:47: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 QQippf23985 for ; Wed, 17 May 2000 13:47:08 -0400 (EDT) Received: from tower.partan.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tower.partan.com [198.6.255.248]) id QQippf20209 for ; Wed, 17 May 2000 17:47:08 GMT Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id NAA22195; Wed, 17 May 2000 13:40:51 -0400 (EDT) From: Andrew Partan Message-Id: <200005171740.NAA22195@tower.partan.com> Subject: Re: MPLS and IS-IS To: david.wang@metro-optix.com (David Wang) Date: Wed, 17 May 2000 13:40:51 -0400 (EDT) Cc: hchan@newbridge.com, mpls@UU.NET In-Reply-To: from "David Wang" at May 17, 0 12:36:08 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-mpls@UU.NET Precedence: bulk > 2. Besides UUNET, which ISPs run IS-IS protocol? Can you name a few? or > what percentage of networks run IS-IS instead of OSPF? UUNET, Sprint, ICM, Digex, Verio, MIBH. There are more. --asp@partan.com (Andrew Partan) From owner-mpls@UU.NET Wed May 17 14:46:11 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 OAA09936 for ; Wed, 17 May 2000 14:46:11 -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 QQippj05124; Wed, 17 May 2000 18:46:02 GMT Received: by mail-control.mail.uu.net id QQippj18871 for mpls-outgoing; Wed, 17 May 2000 18:45:20 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 QQippj18866 for ; Wed, 17 May 2000 18:45: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 QQippi01236 for ; Wed, 17 May 2000 14:44:45 -0400 (EDT) Received: from vesuve.globetrotter.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: vesuve.globetrotter.net [142.169.1.81]) id QQippi03916 for ; Wed, 17 May 2000 18:44:44 GMT Received: from MartinPicard ([142.169.121.50]) by vesuve.globetrotter.net (8.9.3/8.9.3) with SMTP id OAA15998; Wed, 17 May 2000 14:36:24 -0400 (EDT) Message-ID: <012401bfc02e$2aa2bc80$3279a98e@MartinPicard> From: "Martin Picard" To: "David Wang" Cc: "'HANSEN CHAN'" , References: Subject: Re: MPLS and IS-IS Date: Wed, 17 May 2000 14:31:49 -0400 Organization: SINC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit ----- Message d'origine ----- De : "David Wang" À : "'HANSEN CHAN'" ; Envoyé : 17 mai, 2000 13:36 Objet : RE: MPLS and IS-IS > Hi all, > > IS-IS is defined to work with CLNP not for IP originally. Until today a lot > of SONET and telecommunication equipment vendors still use IS-IS to route > CLNP packets through the SONET Data communication channel(DCC) to carry > management information and there is a great pressure to change this to OSPF > and IP. I also know that UUNET runs IS-IS on their network. I never heard > any other networks run IS-IS. Seems I am wrong. My questions are. > > 1. You guys are talking about using IS-IS in a IP networks not in CLNP > networks. The IS-IS has been modified according to RFC 1195 (Use of OSI > IS-IS for Routing in TCP/IP and Dual Environments) or some other standard. > Is this correct? > > 2. Besides UUNET, which ISPs run IS-IS protocol? Can you name a few? or > what percentage of networks run IS-IS instead of OSPF? > GlobalCenter uses IS-IS as described here http://www.americasnetwork.com/issues/99issues/991115/991115_traffic.htm > Thanks > David > > > -----Original Message----- > From: HANSEN CHAN [mailto:hchan@newbridge.com] > Sent: Tuesday, May 16, 2000 7:22 AM > To: mpls@UU.NET > Subject: MPLS and IS-IS > > > Hi all, > > I have been hearing IS-IS is a better protocol to be used than OSPF in a > MPLS > network for TE application. Is that a fair statement? What are the technical > reasons? > > Appreciate if someone can shed some light on this subject. > > Thanks, > Hansen > From owner-mpls@UU.NET Wed May 17 14:56: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 ESMTP id OAA10014 for ; Wed, 17 May 2000 14:56: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 QQippj12619; Wed, 17 May 2000 18:56:08 GMT Received: by mail-control.mail.uu.net id QQippj19330 for mpls-outgoing; Wed, 17 May 2000 18:55:38 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 QQippj19325 for ; Wed, 17 May 2000 18:55: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 QQippj17511 for ; Wed, 17 May 2000 14:53:53 -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 QQippj11015 for ; Wed, 17 May 2000 18:53:52 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 LAA25389 for ; Wed, 17 May 2000 11:53:58 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA19926 for mpls@uu.net; Wed, 17 May 2000 14:53:51 -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 QQippj19080 for ; Wed, 17 May 2000 18:49: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 QQippj16749 for ; Wed, 17 May 2000 14:49:24 -0400 (EDT) From: Chris.Flores@broadwing.com Received: from cvconnect.ixc-comm.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [216.140.58.165]) id QQippj08743 for ; Wed, 17 May 2000 18:49:23 GMT Received: by cvconnect.ixc-comm.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 13:48:06 -0500 Message-ID: <83D3AE577F81D31196B10008C7DFB055AFABF7@metexch4.ixc-comm.com> To: mpls@UU.NET Subject: FW: MPLS and IS-IS Date: Wed, 17 May 2000 13:47:59 -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 David - Most large ISPs in the US use ISIS: UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. It also seems like more and more european ISPs are starting to use ISIS: EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. Chris -----Original Message----- From: David Wang [mailto:david.wang@metro-optix.com] Sent: Wednesday, May 17, 2000 12:36 PM To: 'HANSEN CHAN'; mpls@UU.NET Subject: RE: MPLS and IS-IS Hi all, IS-IS is defined to work with CLNP not for IP originally. Until today a lot of SONET and telecommunication equipment vendors still use IS-IS to route CLNP packets through the SONET Data communication channel(DCC) to carry management information and there is a great pressure to change this to OSPF and IP. I also know that UUNET runs IS-IS on their network. I never heard any other networks run IS-IS. Seems I am wrong. My questions are. 1. You guys are talking about using IS-IS in a IP networks not in CLNP networks. The IS-IS has been modified according to RFC 1195 (Use of OSI IS-IS for Routing in TCP/IP and Dual Environments) or some other standard. Is this correct? 2. Besides UUNET, which ISPs run IS-IS protocol? Can you name a few? or what percentage of networks run IS-IS instead of OSPF? Thanks David -----Original Message----- From: HANSEN CHAN [mailto:hchan@newbridge.com] Sent: Tuesday, May 16, 2000 7:22 AM To: mpls@UU.NET Subject: MPLS and IS-IS Hi all, I have been hearing IS-IS is a better protocol to be used than OSPF in a MPLS network for TE application. Is that a fair statement? What are the technical reasons? Appreciate if someone can shed some light on this subject. Thanks, Hansen From owner-mpls@UU.NET Wed May 17 14:57: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 OAA10030 for ; Wed, 17 May 2000 14:57: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 QQippj14806; Wed, 17 May 2000 18:57:47 GMT Received: by mail-control.mail.uu.net id QQippj19422 for mpls-outgoing; Wed, 17 May 2000 18:57:10 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 QQippj19404 for ; Wed, 17 May 2000 18:56: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 QQippj02541 for ; Wed, 17 May 2000 14:55:37 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQippj13168 for ; Wed, 17 May 2000 18:55:37 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA23922; Wed, 17 May 2000 11:55:03 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id LAA06404; Wed, 17 May 2000 11:55:03 -0700 (PDT) Date: Wed, 17 May 2000 11:55:03 -0700 (PDT) Message-Id: <200005171855.LAA06404@cirrus.juniper.net> From: Dave Katz To: ben@layer8.net CC: danny@tcb.net, mpls@UU.NET In-reply-to: <20000517103019.A1590@layer8.net> (message from Ben Black on Wed, 17 May 2000 10:30:19 -0700) Subject: Re: MPLS and IS-IS Sender: owner-mpls@UU.NET Precedence: bulk An overly complex design will almost certainly result in more difficult implementation. More difficult implementations generally give rise to more bugs. I believe there is a strong correlation between protocol design quality and implementation quality and simply dismissing that relationship seems rather ivory towerish. It is certainly true that a more complex design leads to more complex code, which in turn leads to more bugs, particularly early in the life cycle of the implementation. However, keep in mind that both of these protocols have been around for over ten years now. Cisco's OSPF implementation is nearly ten years old, their IS-IS implementation was rewritten about six years ago. Juniper's implementations are both about three years old. All have seen enough service to shake out most of the bugs, effectively negating the impact of complexity on bug counts. While complexity impacts implementation quality, the biggest factors are a combination of the skill of implementor and the amount of real-world use that the code gets. I've seen astonishingly awful implementations of simple things, as well as very nice implementations of complex things. I've also seen very nice implementations with head-slapping day-one bugs that don't turn up for months because of a lag in deployment. At the end of the day, while OSPF is more complex than IS-IS, it is not *that* much more complex. The stuff that is hard to do well is, for the most part, common to the two protocols. Each has its peculiar challenges. --Dave From owner-mpls@UU.NET Wed May 17 15:01: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 PAA10116 for ; Wed, 17 May 2000 15:01: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 QQippk17801; Wed, 17 May 2000 19:01:19 GMT Received: by mail-control.mail.uu.net id QQippk23045 for mpls-outgoing; Wed, 17 May 2000 19:00:51 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 QQippk22290 for ; Wed, 17 May 2000 19:00: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 QQippj02703 for ; Wed, 17 May 2000 14:56:38 -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 QQippj13890 for ; Wed, 17 May 2000 18:56:36 GMT Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 11:56:34 -0700 Message-ID: <12bf3f2395d9a9dbd0c7a02138d9870a3922eb86@force10networks.com> From: Arun Viswanathan To: "'Cucchiara, Joan'" , "'Kullberg, Alan'" , "'mpls@UU.NET'" Subject: RE: Second WG last call on LSR MIB Date: Wed, 17 May 2000 11:56:30 -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 > -----Original Message----- > From: Cucchiara, Joan [mailto:JCucchiara@Brixnet.com] > Sent: Monday, May 15, 2000 7:37 AM > To: 'Kullberg, Alan'; 'mpls@UU.NET' > Subject: RE: Second WG last call on LSR MIB > > > > Hi Alan, > > You make a good point here. Probably the > right thing to do would be to make this > object optional such that if the LSP is created > as a result of LDP or management then the > object is not supported (because it cannot be). > Otherwise, if it is created by a protocol which > support LSPIds (such as crldp, or rsvp) > then this object has meaning. A description could > be tied to the description of the Owner object > in the row. > > I don't understand why the LSP ID currently varies > in size from 0..31 octets. Could an LSP ID be > 1 or 2 octets? > We agree that this is something that needs to be addressed. We will creaste a new group in the manadatory group section, and make group not part of the madatory group section. If we hear no objection for this change, we will add this in the next rev. -arun From owner-mpls@UU.NET Wed May 17 15:04: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 PAA10137 for ; Wed, 17 May 2000 15:04: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 QQippk18377; Wed, 17 May 2000 19:04:23 GMT Received: by mail-control.mail.uu.net id QQippk28352 for mpls-outgoing; Wed, 17 May 2000 19:03:30 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQippk28343 for ; Wed, 17 May 2000 19:03:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQippk26105 for ; Wed, 17 May 2000 15:02:14 -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 QQippk16935 for ; Wed, 17 May 2000 19:02:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA23108 for mpls@uu.net; Wed, 17 May 2000 15:02:13 -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 QQippk24612 for ; Wed, 17 May 2000 19:01:49 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 QQippj02707 for ; Wed, 17 May 2000 14:56:41 -0400 (EDT) Received: from pentagon.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pentagon.cisco.com [161.44.197.12]) id QQippj13127 for ; Wed, 17 May 2000 18:56:40 GMT Received: from tnadeau-pc02 (ch2-dhcp134-211.cisco.com [161.44.134.211]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA16038; Wed, 17 May 2000 14:56:32 -0400 (EDT) Message-Id: <4.2.2.20000517144316.03e13880@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 17 May 2000 14:56:30 -0400 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: LSR MIB Last Call part 2 changes Cc: cheenu Srinivasan , arun@force10networks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk The following is a summary of changes which we have been asked to and have agreed to make during the WG Last Call part 2 period to the current version of the LSR MIB. 1) Add 'crldp' to the MplsObjectOwner TC 2) Delete mplsInterfaceTotalBuffer and mplsInterfaceAvailableBuffer objects 3) We will change the DESCRIPTION of mplsInterfacePerfEntry to mplsInterfaceInLabelsUsed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of labels that are in use at this point in time on this interface in the incoming direction. If the interface participates in the perPlatform label space only, then this instance of this object MUST be identical with the instance with index 0. If the interface participates in the per-interface label space, then this this instance of this object MUST represent the number of of per-interface labels that are in use at this point in time on this interface." ::= { mplsInterfacePerfEntry 1 } mplsInterfaceFailedLabelLookup OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of labeled packets that have been received on this interface and were discarded because there was no matching cross-connect entry. This object MUST count on a per-interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 4 } mplsInterfaceOutLabelsUsed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of top-most labels in the outgoing label stacks that are in use at this point in time on this interface. This object MUST count on a per-interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 5 } mplsInterfaceOutFragments OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of outgoing MPLS packets that required fragmentation before transmission on this interface. This object transmission on this interface. This object MUST count on a per-interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 8 } 4) Update Table of Contents 5) Update this sentence to reference the right section: "The objects described in Sections 7.3-7.8, when considered together, are equivalent to the tables described in the MPLS architecture document [MPLSArch], that is, the Incoming Label Map (ILM) and the Next Hop Label Forwarding Entry (NHLFE) tables." 6) Update all references, and specifically: draft-ietf-mpls-arch-06.txt 7) Make Revision History in reverse chronological order 8) Remove admin/operStatus objects on mplsInSegmentEntry and mplsOutSegmentEntry 9) Due to the removal of mplsInSegmentEntry admin/OperStatus objects and mplsOutSegmentEntry admin/OperStatus objects the following traps will be deleted: mplsInsegmentTrapEnable mplsOutSegmentTrapEnable mplsInSegmentUp mplsInSegmentDown mplsOutSegmentUp mplsOutSegmentDown 9) Remove the above traps from the mplsLsrNotificationGroup 10) Remove the following objects from MplsInInterfacePerfEntry: mplsInterfaceInPackets mplsInterfaceInDiscards mplsInterfaceOutPackets mplsInterfaceOutDiscards 11) Renumber objects in the same group of mplsTrafficParamMaxRate starting at this object. 12) BITS should not be imported. 13) Change MAX-ACCESS for mplsXCIndex to accessible-for-notify: mplsXCIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Primary index for the row identifying a group of cross-connect segments." ::= { mplsXCEntry 1 } 14) All the NOTIFICATION-TYPE identifiers are missing a zero value "arc" as the next-to-last sub-identifier. (See clause 8.5), so we will add mplsLsrNotifyPrefix OBJECT IDENTIFIER ::= { mplsLsrNotifications 0 } and change all: ::= { mplsLsrNotifications xxx } to ::= { mplsLsrNotifyPrefix xxx } 15) Add a new group called mplsXCOptionalGroup and move mplsXCLspId from the mplsXCgroup into this new group. This new group will not be part of the MANDATORY-GROUPS clause. From owner-mpls@UU.NET Wed May 17 15:17: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 PAA10196 for ; Wed, 17 May 2000 15:17: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 QQippl29146; Wed, 17 May 2000 19:17:34 GMT Received: by mail-control.mail.uu.net id QQippl29507 for mpls-outgoing; Wed, 17 May 2000 19:17:02 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippl29499 for ; Wed, 17 May 2000 19:16:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippl27696 for ; Wed, 17 May 2000 15:16:43 -0400 (EDT) Received: from hoemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQippl28348 for ; Wed, 17 May 2000 19:16:42 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA24666 for ; Wed, 17 May 2000 15:16:42 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA24657; Wed, 17 May 2000 15:16:41 -0400 (EDT) Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA09604; Wed, 17 May 2000 15:16:40 -0400 (EDT) Message-ID: <3922F006.FD1A7A36@lucent.com> Date: Wed, 17 May 2000 15:16:22 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris.Flores@broadwing.com CC: mpls@UU.NET Subject: Re: FW: MPLS and IS-IS References: <83D3AE577F81D31196B10008C7DFB055AFABF7@metexch4.ixc-comm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > Most large ISPs in the US use ISIS: > > UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. > > It also seems like more and more european ISPs are starting to use ISIS: > EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. > Do they "only" use IS-IS for IGP, or IS-IS and OSPF together? Thanks, Yangguang From owner-mpls@UU.NET Wed May 17 15:27: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 PAA10253 for ; Wed, 17 May 2000 15:27: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 QQippl06463; Wed, 17 May 2000 19:27:24 GMT Received: by mail-control.mail.uu.net id QQippl00104 for mpls-outgoing; Wed, 17 May 2000 19:26:43 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 QQippl00099 for ; Wed, 17 May 2000 19:26: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 QQippl22117 for ; Wed, 17 May 2000 15:26:21 -0400 (EDT) Received: from mailcarrier.snv1.gctr.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailcarrier.snv1.gctr.net [206.251.8.19]) id QQippl05688 for ; Wed, 17 May 2000 19:26:21 GMT Received: from pobox.snv1.gctr.net (pobox.snv1.gctr.net [204.71.194.242]) by mailcarrier.snv1.gctr.net (8.9.3/8.9.0) with ESMTP id TAA17352; Wed, 17 May 2000 19:26:20 GMT Received: (from dcooper@localhost) by pobox.snv1.gctr.net (8.9.3/8.9.3) id TAA15074; Wed, 17 May 2000 19:24:36 GMT Date: Wed, 17 May 2000 19:24:36 +0000 From: Dave Cooper To: Yangguang Xu Cc: Chris.Flores@broadwing.com, mpls@UU.NET Subject: Re: FW: MPLS and IS-IS Message-ID: <20000517192436.A12923@globalcenter.net> References: <83D3AE577F81D31196B10008C7DFB055AFABF7@metexch4.ixc-comm.com> <3922F006.FD1A7A36@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: Yangguang Xu's message from Wed, May 17, 2000 at 03:16:22PM - ID <3922F006.FD1A7A36@lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk We (frontier/gctr/gblx) use ISIS w/ wide tlvs for MPLS TE support. -dave -dave Yangguang Xu wrote: > > > > > Most large ISPs in the US use ISIS: > > > > UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. > > > > It also seems like more and more european ISPs are starting to use ISIS: > > EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. > > > > Do they "only" use IS-IS for IGP, or IS-IS and OSPF together? > > Thanks, > > Yangguang From owner-mpls@UU.NET Wed May 17 15:28: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 ESMTP id PAA10265 for ; Wed, 17 May 2000 15:28: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 QQippl07121; Wed, 17 May 2000 19:27:54 GMT Received: by mail-control.mail.uu.net id QQippl00114 for mpls-outgoing; Wed, 17 May 2000 19:26: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 QQippl00106 for ; Wed, 17 May 2000 19:26: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 QQippl22152 for ; Wed, 17 May 2000 15:26:30 -0400 (EDT) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQippl05764 for ; Wed, 17 May 2000 19:26:29 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id PAA13431; Wed, 17 May 2000 15:26:28 -0400 Date: Wed, 17 May 2000 15:26:28 -0400 From: "J. Noel Chiappa" Message-Id: <200005171926.PAA13431@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: MPLS and IS-IS Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Danny McPherson > Note also that besides what Curtis/Dave mentioned wrt the state of a > particular vendors implementation having an impact on which IGP legacy > providers deployed ... seemingly more stable IS-IS suuport My dim recollection is that for a variety of reasons, the major vendor had a better IS-IS implementation, and that led to a lot of people starting off with IS-IS, and of course once something's deployed, people tend to stick with it. Irrespective of who's running what, I'd be interested in hearing someone compare the technical aspects of the *protocols* (although of course the quality of the available implementation is a factor in any operational choice) - I used to be able to do this, but it's been years since I looked at the two of them in detail. Noel From owner-mpls@UU.NET Wed May 17 15:33: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 PAA10369 for ; Wed, 17 May 2000 15:33: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 QQippm11564; Wed, 17 May 2000 19:33:26 GMT Received: by mail-control.mail.uu.net id QQippm00503 for mpls-outgoing; Wed, 17 May 2000 19:33:07 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQippm00495 for ; Wed, 17 May 2000 19:32:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQippm29647 for ; Wed, 17 May 2000 15:32:40 -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 QQippm08941 for ; Wed, 17 May 2000 19:32:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA28945 for mpls@uu.net; Wed, 17 May 2000 15:32:34 -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 QQippm00466 for ; Wed, 17 May 2000 19:31: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 QQippm06797 for ; Wed, 17 May 2000 15:31:36 -0400 (EDT) Received: from pentagon.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pentagon.cisco.com [161.44.197.12]) id QQippm08292 for ; Wed, 17 May 2000 19:31:35 GMT Received: from tnadeau-pc02 (ch2-dhcp134-211.cisco.com [161.44.134.211]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA16442; Wed, 17 May 2000 15:31:22 -0400 (EDT) Message-Id: <4.2.2.20000517151846.06baabc0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 17 May 2000 15:31:20 -0400 To: manikantan , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: Re: MPLS TE MIB - Doubts Cc: cheenu Srinivasan , arun@force10networks.com In-Reply-To: <01BFBE6C.4C0366E0.manis@future.futsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_19390993==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_19390993==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, >I have some doubts and I would really appreciate if some one can help me >in this. > >1) Local Cookie, Remote Cookie. - How do I get this value, Do I get this value >by concatenating > a) Extended Tunnel Id and Tunnel ID field values in case of RSVP path > messages? > b) Ingress LSR Router ID and Local CRLS- Id in case of CRLDP Lbl Req > messages? See last email to Adrian Farrel. >2) What is the significant difference between the MIB objects >"mplsTunnelOwner" >and "mplsTunnelSignallingProto"? and how are these fields to be used? The main difference between these is the TunnelOwner is the entity that created the tunnel. The signaling protocol is the signaling protocol that was used to signal the tunnel. > a) If the field "mplsTunnelOwner" is set to snmp(1) and the "mplsTunnel > SignallingProto" is set to "ldp" / "rsvp", does this mean once the row > status is made up, the tunnel must be established using CRLDP or > RSVP respectively? Yes. > b) If the filed "mplsTunnelOwner" indicates "ldp" or "rsvp" does it mean > that the tunnel is dynamically established using IGP (routing info) > information? If so will the "mplsTunnelSignallingProto" have value > "ldp" or "rsvp" respectively? No. It depends on the ERO. --Tom --=====================_19390993==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

I have some doubts and I would really appreciate if some one can help me in this.

1) Local Cookie, Remote Cookie. - How do I get this value, Do I get this value
by concatenating
   a) Extended Tunnel Id and Tunnel ID field values in case of RSVP path messages?
   b) Ingress LSR Router ID and Local CRLS- Id in case of CRLDP Lbl Req messages?

        See last email to Adrian Farrel.

2) What is the significant difference between the MIB objects "mplsTunnelOwner"
and "mplsTunnelSignallingProto"? and how are these fields to be used?

        The main difference between these is the TunnelOwner
is the entity that created the tunnel. The signaling protocol is
the signaling protocol that was used to signal the tunnel.

  a) If the field "mplsTunnelOwner" is set to snmp(1) and the "mplsTunnel
      SignallingProto" is set to "ldp" / "rsvp", does this mean once the row
      status is made up, the tunnel must be established using CRLDP or
      RSVP respectively?

        Yes.

  b) If the filed "mplsTunnelOwner" indicates "ldp" or "rsvp" does it mean
     that the tunnel is dynamically established using IGP (routing info)
     information? If so will the "mplsTunnelSignallingProto" have value
     "ldp" or "rsvp" respectively?

        No. It depends on the ERO.              
                
        --Tom

--=====================_19390993==_.ALT-- From owner-mpls@UU.NET Wed May 17 15:34: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 ESMTP id PAA10382 for ; Wed, 17 May 2000 15:34: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 QQippm09998; Wed, 17 May 2000 19:33:59 GMT Received: by mail-control.mail.uu.net id QQippm00508 for mpls-outgoing; Wed, 17 May 2000 19:33:11 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 QQippm00491 for ; Wed, 17 May 2000 19:32: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 QQippm23048 for ; Wed, 17 May 2000 15:31: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 QQippm10290 for ; Wed, 17 May 2000 19:31:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA28811 for mpls@uu.net; Wed, 17 May 2000 15:31:54 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippm00453 for ; Wed, 17 May 2000 19:31:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQippm29424 for ; Wed, 17 May 2000 15:30:43 -0400 (EDT) Received: from tnnt3.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQippm07696 for ; Wed, 17 May 2000 19:30:42 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 15:32:32 -0400 Message-ID: From: Cheenu Srinivasan To: "'Adrian Farrel'" Cc: "'mpls@uu.net'" , "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" Subject: RE: MPLS TE MIB - Doubts Date: Wed, 17 May 2000 15:32:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC036.A52033C2" 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_01BFC036.A52033C2 Content-Type: text/plain; charset="iso-8859-1" Adrian, Please see our comments to the questions you sent some time back about the TE MIB. (Your questions are in black.) 1. Control of Notifications I regard it as important to allow a facility for the Management Tool to disable notifications to save resources. In an email to Tom on 5th Jan I suggested some ASN.1 for two top level objects to achieve this. Do you have any objections to adding this function? Would you like me to resend you the ASN.1? That is fine. We will add these. 2. Support for configuring DiffServ LSPs draft-ietf-mpls-diff-ext is well progressed. I think it would be sensible to offer support for configuring E-LSPs and L-LSPs at the ingress. Do you agree? In the above-mentioned email to Tom, I suggested some ASN.1 to achieve this. Would you like me to resend it? I suspect that the ASN.1 should be run past the authors of the diff-ext draft to check that it is in line with their requirements. Similar objects are not supported in the LSR MIB for reasons we explained earlier. 3. LSPId explicit hop type Is there any reason to prevent configuration of an explicit hop of type LSPId? I suggested some ASN.1 for this in an email to Tom on 7th Jan. If ldp is chosen to route the tunnel then we'll add this as a choice for the hop type. 4. Non-use of ERO This is a bit philosophical :-Z If I know my egress but I have no requirement to specify an ER, I can set up just one hop showing a loose hop to the egress. How can the protocol code tell the difference between a request to use an ER object/TLV with a single hop, and a request to use no ER object/TLV? Things that influence this are - is the route pinned? - do all of the LSRs on the route support ER? Clearly the protocol code can make a local policy decision on whether to include the ER object/TLV based on this information. Without appropriate configuration, it may be necessary (e.g. in RSVP) to experiment by sending an ER and finding out if the LSRs on the path reject it. Would it be worth adding mplsTunnelEgress to the main TunnelTable thereby allowing the ER to be omitted? We don't want to replicate all the objects from the hop table in the tunnel table by allowing the last hop to be specified in the tunnel table itself. As the hope table stands, the tunnel endpoint is the last hop in the hop table. If there is only one hop (the last hop) for a particular tunnel, the signaling protocol can discover this and avoid sending the ERO object. Questions/Clarifications 5. Make before break I think that the TunnelInstance object gives the facility for controlling make before break, but I believe it would enhance the draft to add some explanation of how this field can be used. Sure. 6. MPLS Tunnel Resource Table This table is a welcome addition. I believe you need to be very careful because of the differences between forward and reverse resource reservation. For example, for an RSVP tunnel, what is configured here must be the TSpec. Clearly, sharing TSpecs is useful from a configuration point of view, but says nothing about sharing of resources which is determined elsewhere in the network. Is it your intention that this table is updated on the reverse path? - tunnels are unidirectional; so the issue of bidirectional resource reservation does not arise - these objects are information provided by the one who wants to set up the tunnels to the signaling protocol (if signaled); how the signaling proto uses them is their business - note: We shd add an OID pointer (as we did in the LSR MIB) which can be used to point at either the resource table in the MIB, or your own extension. 7. MplsTunnelIndex Although current MPLS tunnels signaling protocols only support 16 bits to identify a tunnel from a specific ingress, it may be that some future protocol will allow a greater number of tunnels. Would it be wise to prepare for this by allowing MplsTunnelIndex to have a greater range? We cannot. We can only support what is specified in the protocols doc. 8. Cookies These are defined as read-only. Do we need write access to configure them for bi-directional tunnels? Yes; make them writeable (or throw them out all together) 9. mplsTunnelHopTable This is currently indexed by mplsTunnelIndex. Does this mean that different instances of a tunnel as defined by mplsTunnelInstance cannot have different routes? If you add mplsTunnelInstance as an index to the HopTable, it means that each instance must have its own ER defined and cannot share the definition for all instances of the same LSP. Would could change the indexing of the hop table to include a (hopListIndex, TunnelHopIndex) to allow the two or more tunnelEntries to point to the same hopListEntry. We could then point the tunnelTable to the new primary index. We also need to make sure that the TunnelEntry has a poitner to the tunnelARHopPtr so that the actual route (RRO) can be know. 10. mplsTunnelHopTable The description says that you can specify the outgoing interface at the tunnel ingress through the first hop of the ER. Is this done using the IP address for the interface? You must specify the IP address. Perhaps the description needs a bit of updating? Editorial 11. Example The example in section 7 needs updating in line with the changes to the tables. - IsMergeable, IsPersistent and LocalProtectInUse are no longer objects in the table. - TunnelIfIndex, LocalCookie and RemoteCookie are read-only so shouldn't be modified here. - The example values for some of the objects are, perhaps, a little unusual for some of the objects (e.g. TunnelDirection, RemoteCookie) - Would you expect to set the In and Out resource values for an 'in' tunnel. Okay. 12. References The version numbers of the referenced drafts in DESCRIPTION fields in the MIB tables need updating. I believe that any drafts referenced in this way need to be flagged as "work in progress". Yes. 13. Terminology In a couple of places you have used ERLSP. It's a bit pedantic, but I think we should refer to CRLSP (or perhaps just LSP) since explicit routes don't have to be used. We just made an acronym out of "explicitly routed LSPs" from section 4.2.1 in the MPLS architecture doc. 14. Textual Convention for IP Addresses I believe that there is a move to define a single textual convention to cover IPv4 and IPv6 addresses. The aim is to avoid the need for each new MIB to define its own textual convention. It might be worth looking into this. We need to update these (just as we did for the LSR MIB). 15. mplsTunnelXCIndex It would be good to expand on the Description. Explain that this object is only writeable in conjunction with pre-existing entries in the LSR MIB. Say that in normal signaled operation this object will be set by the LSR. Explain the meaning of zero. We'll see how to improve the description. 16. mplsTunnelSignallingProto Assuming future protocols will come along, would it be tidier to set the value of 'other' higher to allow space for future extension? We can instead change the value of other to 2 and move ldp and rsvp up. That way newer protocols will be added after. 17. BITS I'm uneasy about the use of BITS for mplsTunnelSessionAttributes. Asides from whether this is standard in MIBs, I don't see the need. Why not keep the bit fields as separate objects? BITS is a standard object that has been used in other RFCs as well. For example, see RFC 2558. 18. Defaults for mplsTunnelSessionAttributes, mplsTunnelInstancePriority and mplsTunnelAdminStatus ok. 19. MplsTunnelResourceEntry. Most of the objects describe mappings to the objects in the mplsTSpecTable of the LSR MIB in terms of "copying". I think you should relax your text a bit and just say that the values correspond to the values of the objects in the mplsTSpecTable. ok; we will change the wording to say "values are reflected" in the traffic param table (or any other table that they may choose to implement) 20. MplsTunnelARHopEntry I can see that mplsTunnelARHopAsNumber would be useful or interesting to ISPs (perhaps they would edit the RRO on exit from their AS, but this is currently not supported by the signaling protocols. Since the RRO does not contain the AS number we shd remove it from this table (and leave it only in the hop table since the ERO supports it); see section 4.4.3, RSVP LSP Tunnels - 05.txt 21. Notifications Add mplsTunnelInstance. OK. Typographic Section 7, paragraph 1, line two. Insert "a" to read "create a loosely routed" Formatting needs a little tidying up in places - section 7, mplsTunnelIsPersistent - section 8, Imports - MplsTunnelEntry - mplsTunnelOperStatus - mplsTunnelResourceEntry - mplsTunnelGroup Integer options It is usual to list these with each entry on a new line (e.g. mplsTunnelDirection). mplsSessionAttributes. - The Description refers to fastReroute, the bit is called ingressMayReroute - localProtectionAvailable "det4ected" - isPinned "Indicates" read "indicates" mplsTunnelOwner. Value 2 is called 'ldp'. Risking the dangerous political field, can I suggest that this should be 'crldp'. mplsTunnelInstancePriority first line for "which" read "the" mplsTunnelInstancePriority line 8 for "particular a" read "a particular" mplsTunnelResourceIndexNext/mplsTunnelResourceIndex Decide on common syntax. Zero should not be a valid value for mplsTunnelResourceIndex mplsTunnelResourceInMaxRate etc. MplsBitRate is defined in the LSR MIB in 1,000 bits per second. The descriptions for these fields need updating. Additionally, the UNITS tag is ood. What do you mean by this sentence ("ood")? mplsTunnelHopStrictOrLoose Delete "is" to read "this tunnel hop" mplsTunnelARHopEntry "represents an currently" We will fix all these typos. Thanks, Cheenu, Arun, Tom ------_=_NextPart_001_01BFC036.A52033C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS TE MIB - Doubts

Adrian,

Please see our = comments to the questions you sent some time back about
the TE MIB. = (Your questions are in black.)

1. Control of = Notifications
   I regard it as = important to allow a facility for the
   Management Tool to = disable notifications to save resources.
   In an email to Tom = on 5th Jan I suggested some ASN.1 for two
   top level objects = to achieve this.
   Do you have any = objections to adding this function?
   Would you like me = to resend you the ASN.1?

        That is fine. We will = add these.

2. Support for configuring = DiffServ LSPs
   = draft-ietf-mpls-diff-ext is well progressed. I think it would
   be sensible to = offer support for configuring E-LSPs and L-LSPs
   at the ingress. Do = you agree?
   In the = above-mentioned email to Tom, I suggested some ASN.1 to
   achieve = this.  Would you like me to resend it?
   I suspect that the = ASN.1 should be run past the authors of the
   diff-ext draft to = check that it is in line with their
   = requirements.

        Similar objects are not supported in the = LSR MIB for reasons we
        explained earlier.

3. LSPId explicit hop = type
   Is there any = reason to prevent configuration of an explicit hop
   of type = LSPId?  I suggested some ASN.1 for this in an email to
   Tom on 7th = Jan.

        If ldp is chosen to route the tunnel then = we'll add this as
        a choice for the hop type.

4. Non-use of ERO
   This is a bit = philosophical :-Z
   If I know my = egress but I have no requirement to specify an ER, I
   can set up just = one hop showing a loose hop to the egress.
   How can the = protocol code tell the difference between a request to
   use an ER = object/TLV with a single hop, and a request to use no
   ER = object/TLV?

   Things that = influence this are
   - is the route = pinned?
   - do all of the = LSRs on the route support ER?
   Clearly the = protocol code can make a local policy decision on
   whether to include = the ER object/TLV based on this information.
   Without = appropriate configuration, it may be necessary (e.g. in
   RSVP) to = experiment by sending an ER and finding out if the LSRs
   on the path reject = it.

   Would it be worth = adding mplsTunnelEgress to the main TunnelTable
   thereby allowing = the ER to be omitted?

        We don't want to replicate all the = objects from the hop table
        in the tunnel table
        by allowing the last hop to be specified = in the tunnel table
        itself. As the hope table stands, the = tunnel endpoint is the
        last hop in the hop table. If there is = only one hop (the last
        hop) for a particular tunnel, the = signaling protocol can
        discover this and avoid sending the ERO = object.

Questions/Clarifications

5. Make before break
   I think that the = TunnelInstance object gives the facility for
   controlling make = before break, but I believe it would enhance the
   draft to add some = explanation of how this field can be used.

        Sure.

6. MPLS Tunnel Resource = Table
   This table is a = welcome addition.
   I believe you need = to be very careful because of the differences
   between forward = and reverse resource reservation.  For example,
   for an RSVP = tunnel, what is configured here must be the TSpec. 
   Clearly, sharing = TSpecs is useful from a configuration point of
   view, but says = nothing about sharing of resources which is
   determined = elsewhere in the network.  Is it your intention that
   this table is = updated on the reverse path?

        - tunnels are unidirectional; so the = issue of bidirectional    
        =         resource reservation does not = arise
        - these objects are information provided = by the one who wants to
        =         set up the tunnels to the signaling = protocol (if signaled);
        =         how the signaling proto uses them is = their business
        - note: We shd add an OID pointer (as we = did in the LSR MIB) which
        =         can be used to point at either the = resource table in the MIB,
        =         or your own extension.

7. MplsTunnelIndex
   Although current = MPLS tunnels signaling protocols only support
   16 bits to = identify a tunnel from a specific ingress, it may be
   that some future = protocol will allow a greater number of tunnels.
   Would it be wise = to prepare for this by allowing MplsTunnelIndex
   to have a greater = range?

        We cannot. We can only support what is = specified in the
        protocols doc.

8. Cookies
   These are defined = as read-only. Do we need write access to
   configure them for = bi-directional tunnels?

        Yes; make them = writeable (or throw them out all together)

9. mplsTunnelHopTable
   This is currently = indexed by mplsTunnelIndex.  Does this mean that
   different = instances of a tunnel as defined by mplsTunnelInstance
   cannot have = different routes? 
    If you add = mplsTunnelInstance as an index to the HopTable, it means
   that each instance = must have its own ER defined and cannot share the
   definition for all = instances of the same LSP.

        Would could change the indexing of the = hop table
        to include a (hopListIndex, = TunnelHopIndex) to allow the two
        or more tunnelEntries to point to the = same hopListEntry. We
        could then point the tunnelTable to the = new primary index. We
        also need to make sure that the = TunnelEntry has a poitner to the
        tunnelARHopPtr so that the actual route = (RRO) can be know.

10. mplsTunnelHopTable
   The description = says that you can specify the outgoing interface at
   the tunnel ingress = through the first hop of the ER.  Is this done
   using the IP = address for the interface?

        You must specify the IP address. Perhaps = the description
        needs a bit of updating?

Editorial

11. Example
   The example in = section 7 needs updating in line with the changes
   to the = tables.
   - IsMergeable, = IsPersistent and LocalProtectInUse are no longer
     = objects in the table.
   - TunnelIfIndex, = LocalCookie and RemoteCookie are read-only so
     = shouldn't be modified here.
   - The example = values for some of the objects are, perhaps, a
     little = unusual for some of the objects (e.g. TunnelDirection,
     = RemoteCookie)
   - Would you expect = to set the In and Out resource values for an
     'in' = tunnel.

        Okay.


12. References
   The version = numbers of the referenced drafts in DESCRIPTION fields
   in the MIB tables = need updating.  I believe that any drafts
   referenced in this = way need to be flagged as "work in progress".

        Yes.

13. Terminology
   In a couple of = places you have used ERLSP.  It's a bit pedantic,
   but I think we = should refer to CRLSP (or perhaps just LSP) since
   explicit routes = don't have to be used.

        We just made an acronym out of = "explicitly routed LSPs" from
        section 4.2.1 in the MPLS architecture = doc.           &n= bsp;   

14. Textual Convention for IP = Addresses
   I believe that = there is a move to define a single textual convention
   to cover IPv4 and = IPv6 addresses.  The aim is to avoid the need for
   each new MIB to = define its own textual convention.  It might be worth
   looking into = this.

        We need to update these (just as we did = for the LSR MIB).

15. mplsTunnelXCIndex
   It would be good = to expand on the Description.  Explain that this
   object is only = writeable in conjunction with pre-existing entries
   in the LSR = MIB.  Say that in normal signaled operation this object
   will be set by the = LSR.  Explain the meaning of zero.

        We'll see how to improve the = description.

16. = mplsTunnelSignallingProto
   Assuming future = protocols will come along, would it be tidier to
   set the value of = 'other' higher to allow space for future extension?

        We can instead change the value of other = to 2 and move ldp and
        rsvp up. That way newer protocols will be = added after.

17. BITS
   I'm uneasy about = the use of BITS for mplsTunnelSessionAttributes.
   Asides from = whether this is standard in MIBs, I don't see the need.
   Why not keep the = bit fields as separate objects?

        BITS is a standard object that has been = used in other RFCs as
        well. For example, see RFC 2558.

18. Defaults for = mplsTunnelSessionAttributes,
   = mplsTunnelInstancePriority and mplsTunnelAdminStatus

        ok.

19. = MplsTunnelResourceEntry.
   Most of the = objects describe mappings to the objects in the
   mplsTSpecTable of = the LSR MIB in terms of "copying".  I think you
   should relax your = text a bit and just say that the values correspond
   to the values of = the objects in the mplsTSpecTable.

        ok; we will change the wording to say = "values are reflected"
        in the traffic param table (or any other = table that they may
        choose to implement)

20. MplsTunnelARHopEntry
   I can see that = mplsTunnelARHopAsNumber would be useful or
   interesting to = ISPs (perhaps they would edit the RRO on exit from
   their AS, but this = is currently not supported by the signaling
   protocols.

        Since the RRO does not contain the AS = number we shd remove
        it from this table (and leave it only in = the hop table since
        the ERO supports it); see section 4.4.3, = RSVP LSP Tunnels -
        05.txt

21. Notifications
   Add = mplsTunnelInstance.

        OK.

Typographic

Section 7, paragraph 1, line = two.
Insert "a" to read = "create a loosely routed"

Formatting needs a little = tidying up in places
- section 7, = mplsTunnelIsPersistent
- section 8, Imports
- MplsTunnelEntry
- mplsTunnelOperStatus
- = mplsTunnelResourceEntry
- mplsTunnelGroup

Integer options
It is usual to list these with = each entry on a new line (e.g.
mplsTunnelDirection).

mplsSessionAttributes.
- The Description refers to = fastReroute, the bit is called
  ingressMayReroute
- localProtectionAvailable = "det4ected"
- isPinned = "Indicates" read "indicates"

mplsTunnelOwner.  Value 2 = is called 'ldp'.  Risking the dangerous
political field, can I suggest = that this should be 'crldp'.

mplsTunnelInstancePriority first = line for "which" read "the"

mplsTunnelInstancePriority line = 8 for "particular a" read "a
particular"

mplsTunnelResourceIndexNext/mplsTunnelResourceIndex
Decide on common syntax.  = Zero should not be a valid value for
mplsTunnelResourceIndex

mplsTunnelResourceInMaxRate = etc.
MplsBitRate is defined in the = LSR MIB in 1,000 bits per second.
The descriptions for these = fields need updating.  Additionally,
the UNITS tag is ood.

        What do you mean by this sentence = ("ood")?

mplsTunnelHopStrictOrLoose  = Delete "is" to read "this tunnel hop"

mplsTunnelARHopEntry = "represents an currently"

        We will fix all these typos.

Thanks,

Cheenu, Arun, = Tom



------_=_NextPart_001_01BFC036.A52033C2-- From owner-mpls@UU.NET Wed May 17 15:37: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 ESMTP id PAA10411 for ; Wed, 17 May 2000 15:37: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 QQippm12942; Wed, 17 May 2000 19:37:40 GMT Received: by mail-control.mail.uu.net id QQippm00728 for mpls-outgoing; Wed, 17 May 2000 19:37:06 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 QQippm00712 for ; Wed, 17 May 2000 19:36: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 QQippm07371 for ; Wed, 17 May 2000 15:36:41 -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 QQippm12123 for ; Wed, 17 May 2000 19:36:41 GMT Received: from ennovatenetworks.com (zeppo.ennovatenetworks.com [208.227.99.180]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id PAA18545; Wed, 17 May 2000 15:36:05 -0400 (EDT) (envelope-from pchen@ennovatenetworks.com) Message-ID: <3922F7A8.AACE0E56@ennovatenetworks.com> Date: Wed, 17 May 2000 15:48:56 -0400 From: Philip Chen X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Katz CC: jlawrenc@cisco.com, hchan@newbridge.com, mpls@UU.NET Subject: Re: MPLS and IS-IS References: <200005170223.TAA04112@cirrus.juniper.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Dave Katz wrote: > One should note that these "advantages" are artifacts of the state of > a particular vendor's implementations, and does not reflect on any > inherent scaling or stability issues in the protocols themselves. > > Probably the bigger issue as far as TE, or extensions in general, is that > they tend to happen faster in IS-IS because the largest customers of > the dominant vendors tend to use it, so it is the first target of > implementation. > > --Dave > > IS-IS has some advantages over OSPF in general. These are at > least as relevant in MPLS networks doing traffic engineering as > they are in networks not doing TE or MPLS: > - In practice, IS-IS has been shown to support larger Areas > than OSPF. This is of particular relevance to TE as it > extends the regions over which a router can have detailed > knowledge of link state, and hence knowledge of optimal > routing of TE paths. > - In practice, IS-IS has proved to be more stable than OSPF > due to features like the pacing of LSP distribution (at > least one OSPF implementation has caught up in this regard). Here is my 2 cents on the subject of IS-IS vs OSPF scalability issue: If I understand correctly, the original reason why IS-IS is in favor of other routing protocols is because IS-IS can be easily made to support multiple communication protocols. This will alow us to avoid so called “Ships in the Night” approach. The advantages of this approach include: less management work (do not have to manage many protocol any more) less router resources consumption (less routing process is running) These translate to better scalability for IS-IS. However, those reasons are vanished now. Today, a carrier network pretty much only needs to deal with one protocol--IP. So, use a non generic routing protocol optimized for IP such as OSPF makes more sense. Another technical reason why IS-IS might be better scalable than OSPF comes from the following fact: Both IS-IS and OSPF follows two level of hierarchy, but they differ in the amount of information flooded into each area. OSPF floods more information about other areas to an area, so an internal OSPF router can choose an optimal ABR (if there are more than one ABRs) for traffic destinated to other areas. Why IS-IS follows more strict hierarchy model. IS-IS has no information about other level 1 area. So an internal IS-IS router will always send the traffic destinated to other level 1 areas to the nearest level 2 router (if ther are more than one level 2 routers). Note the difference here: if there are more than one "ABR"s for traffics to other areas, OSPF always pick the optimized path. IS-IS may not. The price paid by OSPF is more router and network resource utilization to deal with more network reachability information and of course more complex protocol. In other words, for the same resources consumption, IS-IS can support larger networks (area, AS) than OSPF. In this sense IS-IS is more scalable than OSPF, but we have to mention another side of the coin: that is OSPF alway pick optimized routes. That is not the complete story yet. OSPF fixes some of the scalability problem by introducing stub area and NSSA. This allows controlled filtering of information flooded into an area. One important difference is stub area cannot be a transit area. Nevertherless, in many cases, this is good enough to solve OSPF scalibility issue. Oh, do not forget, the concept of stub area, NSSA also contribute to the complexity of OSPF over IS-IS. Thanks! --Phil From owner-mpls@UU.NET Wed May 17 15:46: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 PAA10460 for ; Wed, 17 May 2000 15:46: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 QQippn21144; Wed, 17 May 2000 19:45:58 GMT Received: by mail-control.mail.uu.net id QQippn01869 for mpls-outgoing; Wed, 17 May 2000 19:45:26 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippn01856 for ; Wed, 17 May 2000 19:45:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippn01045 for ; Wed, 17 May 2000 15:45:23 -0400 (EDT) Received: from tcb.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQippn20618 for ; Wed, 17 May 2000 19:45:23 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id NAA16845 for ; Wed, 17 May 2000 13:46:44 -0600 Message-Id: <200005171946.NAA16845@tcb.net> To: mpls@UU.NET From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MPLS and IS-IS Date: Wed, 17 May 2000 13:46:44 -0600 Sender: owner-mpls@UU.NET Precedence: bulk Dave is actually discussing this at the upcoming NANOG. I really can't think of anyone more qualified. -danny > Irrespective of who's running what, I'd be interested in hearing someone > compare the technical aspects of the *protocols* (although of course the > quality of the available implementation is a factor in any operational > choice) - I used to be able to do this, but it's been years since I looked at > the two of them in detail. > > Noel From owner-mpls@UU.NET Wed May 17 15:58: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 ESMTP id PAA10528 for ; Wed, 17 May 2000 15:58: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 QQippn27946; Wed, 17 May 2000 19:58:01 GMT Received: by mail-control.mail.uu.net id QQippn03048 for mpls-outgoing; Wed, 17 May 2000 19:57:41 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippn03040 for ; Wed, 17 May 2000 19:57:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQippn02424 for ; Wed, 17 May 2000 15:57:10 -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 QQippn27274 for ; Wed, 17 May 2000 19:57:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA03945 for mpls@uu.net; Wed, 17 May 2000 15:57:08 -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 QQippn02957 for ; Wed, 17 May 2000 19:56: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 QQippn26591 for ; Wed, 17 May 2000 15:56: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 QQippn28460 for ; Wed, 17 May 2000 19:56:14 GMT Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA03806; Wed, 17 May 2000 15:56:11 -0400 (EDT) Message-Id: <4.2.0.58.20000517155915.00aacea0@pilgrim.cisco.com> X-Sender: rschmitt@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 17 May 2000 16:00:23 -0700 To: jcucchiara@brixnet.com, mpls@UU.NET From: Rob Schmitt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk What is the latest status on the LDP-MIB last call? /rs +-----------------------------------------------------------------+ Robert Schmitt CISCO SYSTEMS rschmitt@cisco.com Chelmsford, MA 978-244-3076 +----------------------------------------------------------------+ From owner-mpls@UU.NET Wed May 17 16:03: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 QAA10620 for ; Wed, 17 May 2000 16:03: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 QQippo03216; Wed, 17 May 2000 20:02:39 GMT Received: by mail-control.mail.uu.net id QQippo09839 for mpls-outgoing; Wed, 17 May 2000 20:02:01 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 QQippo09799 for ; Wed, 17 May 2000 20:02: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 QQippo10241 for ; Wed, 17 May 2000 16:01:41 -0400 (EDT) Received: from ginger.lcs.mit.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQippo01047 for ; Wed, 17 May 2000 20:01:40 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id QAA13594; Wed, 17 May 2000 16:01:29 -0400 Date: Wed, 17 May 2000 16:01:29 -0400 From: "J. Noel Chiappa" Message-Id: <200005172001.QAA13594@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: MPLS and IS-IS Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Philip Chen Both IS-IS and OSPF follows two level of hierarchy, but they differ in > the amount of information flooded into each area. ... an internal OSPF > router can choose an optimal ABR (if there are more than one ABRs) for > traffic destinated to other areas. .. IS-IS has no information about > other level 1 area. So an internal IS-IS router will always send the > traffic destinated to other level 1 areas to the nearest level 2 router > ... > OSPF fixes some of the scalability problem by introducing stub area > .. One important difference is stub area cannot be a transit area. In fact, it's fundamentally impossible for an area which does not have complete information about the state of things outside the area to serve as a transit area (at least in a pure datagram mode of operation - obviously, you can tunnel stuff across). The reason is fairly obvious - if an internal router simply routes packets destined to external destinations to the nearest border router, and the packet is a transit packet, it's quite likely that that router would be the router the packet came in through! It's because IS-IS doesn't import data that it has (unless there's been some recent upgrade I'm not familiar with) the restriction that the level 2 routers have to form a directly connected graph (i.e. no virtual links across level 1 areas, as supported by OSPF). Noel From owner-mpls@UU.NET Wed May 17 16:05: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 ESMTP id QAA10650 for ; Wed, 17 May 2000 16:05: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 QQippo03619; Wed, 17 May 2000 20:04:56 GMT Received: by mail-control.mail.uu.net id QQippo11892 for mpls-outgoing; Wed, 17 May 2000 20:04:38 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 QQippo11883 for ; Wed, 17 May 2000 20:04: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 QQippo27918 for ; Wed, 17 May 2000 16:04:13 -0400 (EDT) Received: from po1.bbn.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: PO1.BBN.COM [192.1.50.38]) id QQippo04428 for ; Wed, 17 May 2000 20:04:12 GMT Received: from [171.78.6.241] (dhcp006-241.bbn.com [171.78.6.241]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA12673; Wed, 17 May 2000 16:04:06 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: day@po1.bbn.com Message-Id: In-Reply-To: <200005171855.LAA06404@cirrus.juniper.net> References: <20000517103019.A1590@layer8.net> (message from Ben Black on Wed, 17 May 2000 10:30:19 -0700) Date: Wed, 17 May 2000 16:00:21 -0400 To: Dave Katz , ben@layer8.net From: John Day Subject: Re: MPLS and IS-IS Cc: danny@tcb.net, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk > >At the end of the day, while OSPF is more complex than IS-IS, it is not >*that* much more complex. The stuff that is hard to do well is, for >the most part, common to the two protocols. Each has its peculiar >challenges. > It is not just shaking out the implementation that reduces the stability, but the number of "knobs" you have for tuning it. OSPF has many more "knobs" than ISIS. This makes it "more flexible", but it also makes getting a stable configuration more difficult. The analogy I have always used that it was a bit like trying to tune an old TV tube. There are only 3 knobs but any adjustment of one affects the others. The problem with OSPF is that there are many more than 3 knobs and none are orthogonal to any of the others. This makes finding a stable configuration very difficult and the bigger the network the more difficult it will be and hence the belief that it doesn't scale well. From owner-mpls@UU.NET Wed May 17 16: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 QAA10687 for ; Wed, 17 May 2000 16:10: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 QQippo08596; Wed, 17 May 2000 20:10:25 GMT Received: by mail-control.mail.uu.net id QQippo12346 for mpls-outgoing; Wed, 17 May 2000 20:09:28 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQippo12341 for ; Wed, 17 May 2000 20:09:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippo03926 for ; Wed, 17 May 2000 16:08:58 -0400 (EDT) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQippo07438 for ; Wed, 17 May 2000 20:08:56 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id QAA13630; Wed, 17 May 2000 16:08:56 -0400 Date: Wed, 17 May 2000 16:08:56 -0400 From: "J. Noel Chiappa" Message-Id: <200005172008.QAA13630@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: MPLS and IS-IS Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Danny McPherson >> I'd be interested in hearing someone compare the technical aspects of >> the *protocols* > Dave is actually discussing this at the upcoming NANOG. Those not going to NANOG might be interested in seeing this online (and in fact such an analysis would be a good thing to have as an online resource). I know some NANOG material makes it online, but are there plans for Dave's notes to be available? Noel PS: Somwhere, covered by many layers of dust, I have at least two such documents, one by Radia and one by me, dating from around the period of the FSU IETF (whenever that was - probably '84 or so). From owner-mpls@UU.NET Wed May 17 16:20:33 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 QAA10781 for ; Wed, 17 May 2000 16:20: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 QQippp15829; Wed, 17 May 2000 20:20:22 GMT Received: by mail-control.mail.uu.net id QQippp13307 for mpls-outgoing; Wed, 17 May 2000 20:19:56 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippp13302 for ; Wed, 17 May 2000 20:19:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippp05042 for ; Wed, 17 May 2000 16:19:39 -0400 (EDT) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQippp15001 for ; Wed, 17 May 2000 20:19:36 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id QAA13713; Wed, 17 May 2000 16:19:35 -0400 Date: Wed, 17 May 2000 16:19:35 -0400 From: "J. Noel Chiappa" Message-Id: <200005172019.QAA13713@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: MPLS and IS-IS Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Andrew Partan > One main difference is security - its difficult to send a forged ISIS > packet across the Internet to attack someone. All LS protocols (i.e. including both IS-IS and OSPF) are inherently much harder to mess with than Destinvation Vector protocols, for the simple reason that they advertise links, not routes, and before a link can be declared up, you have to hear from both ends of it. Although I suppose the way external routes are imported doesn't follow this rule... Still, it's a lot trickier to mess an LS protocol up - you have to get into a topology map database exchange protocol, not just send someone a bogus routing table entry directly. Also, I know that OSPF had authentication, and it was extendable (i.e. you could add new methods); my knowledge in this area is out-of-date, and I'm not sure which methods have been added since it was first defined. Noel PS: My memory is clearly failing. The FSU IETF was in '90, not '85 - ten years ago, 15 years, whatever, it was still a long time ago! :-) From owner-mpls@UU.NET Wed May 17 16:25: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 ESMTP id QAA10822 for ; Wed, 17 May 2000 16:25: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 QQippp19375; Wed, 17 May 2000 20:25:08 GMT Received: by mail-control.mail.uu.net id QQippp13681 for mpls-outgoing; Wed, 17 May 2000 20:24:48 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippp13676 for ; Wed, 17 May 2000 20:24:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQippp05639 for ; Wed, 17 May 2000 16:24:14 -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 QQippp17220 for ; Wed, 17 May 2000 20:24:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA09428 for mpls@uu.net; Wed, 17 May 2000 16:24: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 QQippp13657 for ; Wed, 17 May 2000 20:23: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 QQippp12834 for ; Wed, 17 May 2000 16:23:46 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQippp16937 for ; Wed, 17 May 2000 20:23:46 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 16:22:11 -0400 Message-ID: From: "Sanford, Bill" To: "'mpls@UU.NET'" Subject: RSVP-TE objects "Quick Reference" Date: Wed, 17 May 2000 16:22:08 -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 would like to submit a "Quick Reference" for RSVP-TE objects. During the RSVP-TE Group Test Period at UNH and just recently Interop in Las Vegas, I found that this was incredibly helpful for analyzing hex dumps. Most of the objects are there and hopefully most are accurate. I wanted to get this to the MPLS list so that it can be updated and maybe even used. Bill -- Bill Sanford bills@hjinc.com Senior SQA Test Engineer http://www.hjinc.com Harris & Jeffries, Inc. 888 Washington Street Dedham MA 02026 Tel: (781) 329-3200 Fax: (781) 329-4148 From owner-mpls@UU.NET Wed May 17 16:28: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 QAA10864 for ; Wed, 17 May 2000 16:28: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 QQippp21773; Wed, 17 May 2000 20:28:13 GMT Received: by mail-control.mail.uu.net id QQippp13908 for mpls-outgoing; Wed, 17 May 2000 20:27:45 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 QQippp13897 for ; Wed, 17 May 2000 20:27: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 QQippp01041 for ; Wed, 17 May 2000 16:27:02 -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 QQippp20843 for ; Wed, 17 May 2000 20:27: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 NAA19200 for ; Wed, 17 May 2000 13:27:07 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA20246 for mpls@uu.net; Wed, 17 May 2000 16:27: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 QQippo12357 for ; Wed, 17 May 2000 20:09:52 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 QQippo11149 for ; Wed, 17 May 2000 16:09:41 -0400 (EDT) Received: from tower.partan.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tower.partan.com [198.6.255.248]) id QQippo07948 for ; Wed, 17 May 2000 20:09:41 GMT Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id QAA09114; Wed, 17 May 2000 16:09:40 -0400 (EDT) From: Andrew Partan Message-Id: <200005172009.QAA09114@tower.partan.com> Subject: Re: MPLS and IS-IS To: jnc@ginger.lcs.mit.edu (J. Noel Chiappa) Date: Wed, 17 May 2000 16:09:40 -0400 (EDT) Cc: mpls@UU.NET, jnc@ginger.lcs.mit.edu In-Reply-To: <200005171926.PAA13431@ginger.lcs.mit.edu> from "J. Noel Chiappa" at May 17, 0 03:26:28 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-mpls@UU.NET Precedence: bulk > My dim recollection is that for a variety of reasons, the major vendor had a > better IS-IS implementation, That plus a desire to route both IP and CLNS. > Irrespective of who's running what, I'd be interested in hearing someone > compare the technical aspects of the *protocols* One main difference is security - its difficult to send a forged ISIS packet across the Internet to attack someone. ISIS does not run on top of IP (unless you use that non-default encapsulation); thus it only exists on a link between routers. --asp@partan.com (Andrew Partan) From owner-mpls@UU.NET Wed May 17 16:28: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 ESMTP id QAA10879 for ; Wed, 17 May 2000 16:28:43 -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 QQippp20441; Wed, 17 May 2000 20:28:31 GMT Received: by mail-control.mail.uu.net id QQippp13916 for mpls-outgoing; Wed, 17 May 2000 20:27:48 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 QQippp13899 for ; Wed, 17 May 2000 20:27:36 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 QQippp00993 for ; Wed, 17 May 2000 16:26:47 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQippp20631 for ; Wed, 17 May 2000 20:26:47 GMT Received: from fuinar.juniper.net (fuinar.juniper.net [207.79.80.140]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA00862; Wed, 17 May 2000 13:26:46 -0700 (PDT) Received: (from qv@localhost) by fuinar.juniper.net (8.8.8/8.7.3) id NAA29870; Wed, 17 May 2000 13:26:48 -0700 (PDT) From: Quaizar Vohra MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 17 May 2000 13:26:48 -0700 (PDT) To: "J. Noel Chiappa" Cc: mpls@UU.NET Subject: Re: MPLS and IS-IS In-Reply-To: <200005171926.PAA13431@ginger.lcs.mit.edu> References: <200005171926.PAA13431@ginger.lcs.mit.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14626.64538.76113.849173@fuinar.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Here are a few differences : 1) In OSPF, an ABR can be connected to more than 2 areas which brings in a whole lot of complexity during post SPF route calculation when a route is accesible from more than 1 area. While in ISIS, a router can be connected to atmost 2 areas, i.e. L1 and L2 and you strictly prefer routes from L1 over L2. Offcourse the route selection becomes more complex when ISIS allows leaking L2 into L1 (new ISIS draft) but is still simpler than supporting multiple areas on an ABR which have same level of priority. 2) DR election in OSPF is much more complex because a DR has to play a more complex role in OSPF than ISIS because of a more complex flood/ack mechanism of OSPF. 3) ISIS allows breaking of a large LSP into MTU sized chunks, while OSPF depends on IP fragmentation. If one fragment is lost you end up transmitting only that fragment in ISIS. In OSPF you end up trasnsmitting an entire LSA. 4) 35 K in OSPF lines of code vs 15 K lines of ISIS code. 5) ISIS lacks virtual link and NSSA like optimizations. OSPF seems more complex to implement but the complexity could be gotten rid off if you choose note to implement the not so heavily used features as in 5). Quaizar > > From: Danny McPherson > > > Note also that besides what Curtis/Dave mentioned wrt the state of a > > particular vendors implementation having an impact on which IGP legacy > > providers deployed ... seemingly more stable IS-IS suuport > > My dim recollection is that for a variety of reasons, the major vendor had a > better IS-IS implementation, and that led to a lot of people starting off > with IS-IS, and of course once something's deployed, people tend to stick > with it. > > Irrespective of who's running what, I'd be interested in hearing someone > compare the technical aspects of the *protocols* (although of course the > quality of the available implementation is a factor in any operational > choice) - I used to be able to do this, but it's been years since I looked at > the two of them in detail. > > Noel From owner-mpls@UU.NET Wed May 17 16: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 QAA10920 for ; Wed, 17 May 2000 16:29: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 QQippp22967; Wed, 17 May 2000 20:29:29 GMT Received: by mail-control.mail.uu.net id QQippp13917 for mpls-outgoing; Wed, 17 May 2000 20:27: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 QQippp13901 for ; Wed, 17 May 2000 20:27: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 QQippp13210 for ; Wed, 17 May 2000 16:27: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 QQippp20798 for ; Wed, 17 May 2000 20:26:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA10059 for mpls@uu.net; Wed, 17 May 2000 16:26:56 -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 QQippp13864 for ; Wed, 17 May 2000 20:26:40 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 QQippp13044 for ; Wed, 17 May 2000 16:25:56 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQippp18433 for ; Wed, 17 May 2000 20:25:55 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 May 2000 16:24:21 -0400 Message-ID: From: "Sanford, Bill" To: "'mpls@uu.net'" Subject: RSVP-TE objects "Quick Reference" Date: Wed, 17 May 2000 16:24:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFC03D.E00475F0" 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_01BFC03D.E00475F0 Content-Type: text/plain; charset="iso-8859-1" I would like to submit a "Quick Reference" for RSVP-TE objects. During the RSVP-TE Group Test Period at UNH and just recently Interop in Las Vegas, I found that this was incredibly helpful for analyzing hex dumps. Most of the objects are there and hopefully most are accurate. I wanted to get this to the MPLS list so that it can be updated and maybe even used. Bill -- Bill Sanford bills@hjinc.com Senior SQA Test Engineer http://www.hjinc.com Harris & Jeffries, Inc. 888 Washington Street Dedham MA 02026 Tel: (781) 329-3200 Fax: (781) 329-4148 ------_=_NextPart_000_01BFC03D.E00475F0 Content-Type: application/vnd.ms-excel; name="RSVPObjectsQuickReference.xls" Content-Disposition: attachment; filename="RSVPObjectsQuickReference.xls" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAVAAAAAAAAAAA EAAA/v///wAAAAD+////AAAAAFMAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAK8YzQfJQAAABgEAAOEAAgCwBMEAAgAAAOIAAABcAHAADAAAQmlsbCBTYW5mb3JkICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQIA AgCcAAIADgAZAAIAAAASAAIAAAATAAIAAACvAQIAAAC8AQIAAAA9ABIAaAFLAKAyah04AAAAAAAB AFgCQAACAAAAjQACAAAAIgACAAAADgACAAEAtwECAAAA2gACAAAAMQAaAMgAAAD/f5ABAAAAAAAB BQFBAHIAaQBhAGwAMQAaAMgAAQD/f7wCAAAAAAABBQFBAHIAaQBhAGwAMQAaAMgAAgD/f5ABAAAA AAABBQFBAHIAaQBhAGwAMQAaAMgAAwD/f7wCAAAAAAABBQFBAHIAaQBhAGwAMQAaAMgAAAD/f5AB AAAAAAABBQFBAHIAaQBhAGwAMQAaAKAAAAD/f5ABAAAAAgABBQFBAHIAaQBhAGwAMQAaAKAAAQD/ f7wCAAAAAgABBQFBAHIAaQBhAGwAHgQcAAUAFwAAIiQiIywjIzBfKTtcKCIkIiMsIyMwXCkeBCEA BgAcAAAiJCIjLCMjMF8pO1tSZWRdXCgiJCIjLCMjMFwpHgQiAAcAHQAAIiQiIywjIzAuMDBfKTtc KCIkIiMsIyMwLjAwXCkeBCcACAAiAAAiJCIjLCMjMC4wMF8pO1tSZWRdXCgiJCIjLCMjMC4wMFwp HgQ3ACoAMgAAXygiJCIqICMsIyMwXyk7XygiJCIqIFwoIywjIzBcKTtfKCIkIiogIi0iXyk7XyhA XykeBC4AKQApAABfKCogIywjIzBfKTtfKCogXCgjLCMjMFwpO18oKiAiLSJfKTtfKEBfKR4EPwAs ADoAAF8oIiQiKiAjLCMjMC4wMF8pO18oIiQiKiBcKCMsIyMwLjAwXCk7XygiJCIqICItIj8/Xyk7 XyhAXykeBDYAKwAxAABfKCogIywjIzAuMDBfKTtfKCogXCgjLCMjMC4wMFwpO18oKiAiLSI/P18p O18oQF8pHgQVAKQAEAAAIlllcyI7IlllcyI7Ik5vIh4EGgClABUAACJUcnVlIjsiVHJ1ZSI7IkZh bHNlIh4EFACmAA8AACJPbiI7Ik9uIjsiT2ZmIuAAFAAAAAAA9f8gAAAAAAAAAAAAAADAIOAAFAAB AAAA9f8gAAD0AAAAAAAAAADAIOAAFAABAAAA9f8gAAD0AAAAAAAAAADAIOAAFAACAAAA9f8gAAD0 AAAAAAAAAADAIOAAFAACAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADA IOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA 9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAA AAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAA FAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAAAQAg AAAAAAAAAAAAAADAIOAAFAAFACsA9f8gAAD4AAAAAAAAAADAIOAAFAAFACkA9f8gAAD4AAAAAAAA AADAIOAAFAAFACwA9f8gAAD4AAAAAAAAAADAIOAAFAAFACoA9f8gAAD4AAAAAAAAAADAIOAAFAAF AAkA9f8gAAD4AAAAAAAAAADAIOAAFAAAAAAAAQAgAAAgAAAAAAAAAADAIOAAFAAGAAAAAQASAAA4 EAAAIAAAAADAIOAAFAAGAAAAAQASAAA4EAEAIEAAAADAIOAAFAAHAAAAAQASAAB8ERFAIEAgAAQW IOAAFAAHAAAAAQASAAB4ERFAIEAgAAQWIOAAFAAHAAAAAQASAAB4EBEAIEAgAAQWIOAAFAAGAAAA AQASAAA4AAAAAAAAAADAIOAAFAAGAAAAAQASAAA4EBEAIEAgAADAIOAAFAAGAAAAAQASAAA4ERFA IEAgAADAIOAAFAAGAAAAAQASAAA8ERFAIEAgAADAIOAAFAAHAAAAAQASAAB4EBAAIAAgAAQWIOAA FAAGAAAAAQASAAA8AAAAAAAAAADAIOAAFAAGAAAAAQAiAAA4ERFAIEAgAADAIOAAFAAGAAAAAQAa AAA4ERFAIEAgAADAIOAAFAAGAAAAAQAoAAA4AAAAAAAAAADAIOAAFAAGAAAAAQAaAAA4EBEAIEAg AADAIOAAFAAGAAAAAQAZAAA4EAEAIEAAAADAIOAAFAAGAAAAAQAYAAA4ERFAIEAgAADAIOAAFAAG AAAAAQAqAAA4ERFAIEAgAADAIOAAFAAGAAAAAQAiAAA4EBEAIEAgAADAIOAAFAAGAAAAAQAiAAA4 ABEAAEAgAADAIOAAFAAGAAAAAQASAAA4ERBAIAAgAADAIOAAFAAGAAAAAQAZAAA4ERFAIEAgAADA IOAAFAAGAAAAAQAaAAA4AAAAAAAAAADAIOAAFAAGAAAAAQAgAAAIAAAAAAAAAADAIOAAFAAGAAAA AQAiAAA4AAAAAAAAAADAIOAAFAAGAAAAAQAqAAA4AAAAAAAAAADAIOAAFAAHAAAAAQASAAB4ERFA IEAgAAQWIOAAFAAGAAAAAQASAAA4ERFAIEAgAADAIOAAFAAGAAAAAQASAAA4EQFAIEAAAADAIOAA FAAGAAAAAQASAAA4ERBAIAAgAADAIOAAFAAHAAAAAQASAAB4ARFAAEAgAAQWIOAAFAAGAAAAAQAS AAA4ABEAAEAgAADAIOAAFAAGAAAAAQASAAA4EBEAIEAgAADAIOAAFAAHAAAAAQASAAB4ABEAAEAg AAQWIOAAFAAHAAAAAQASAAB4EBEAIEAgAAQWIJMCBAAQgAP/kwIEABGABv+TAgQAEoAE/5MCBAAT gAf/kwIEAACAAP+TAgQAFIAF/5IA4gA4AAAAAAD///8A/wAAAAD/AAAAAP8A//8AAP8A/wAA//8A gAAAAACAAAAAAIAAgIAAAIAAgAAAgIAAwMDAAICAgACAgP8AgCBgAP//wACg4OAAYACAAP+AgAAA gMAAwMD/AAAAgAD/AP8A//8AAAD//wCAAIAAgAAAAACAgAAAAP8AAMz/AGn//wDM/8wA//+ZAKbK 8ADMnMwAzJn/AOPj4wAzZv8AM8zMADOZMwCZmTMAmWYzAJlmZgBmZpkAlpaWADMzzAAzZmYAADMA ADMzAABmMwAAmTNmADMzmQBCQkIAXBAOAAMAAAAAAP///wAAAAAAYAECAAEAhQAOABJBAAAAAAYA U2hlZXQyjAAEAAEAAQCuAQQAAQABBBcADgACAAAA/////wAAAAAAABgAGwAgAAABCwAAAAEAAAAA AAAGOwEAAQANAQEAAwDBAQgAwQEAAIA4AQD8ABwgzAEAAO4AAAABAAAgBAAAU2l6ZQQAAE5hbWUU AABGdW5jdGlvbi9EZXNjcmlwdGlvbgUAAEZsYWdzCAAAUmVzZXJ2ZWQrAABJUHY0IFJTVlBfSE9Q IG9iamVjdDogQ2xhc3MgPSAzLCBDLVR5cGUgPSAxHgAASVB2NCBOZXh0L1ByZXZpb3VzIEhvcCBB ZGRyZXNzGAAATG9naWNhbCBJbnRlcmZhY2UgSGFuZGxlKQAAVElNRV9WQUxVRVMgT2JqZWN0OiBD bGFzcyA9IDUsIEMtVHlwZSA9IDEOAABSZWZyZXNoIFBlcmlvZC0AAElQdjQgRVJST1JfU1BFQyBv YmplY3Q6IENsYXNzID0gNiwgQy1UeXBlID0gMTsAAFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBub2Rl IGluIHdoaWNoIHRoZSBlcnJvciB3YXMgZGV0ZWN0ZWQuEgAARXJyb3IgTm9kZSBBZGRyZXNz2AEA MHgwMSAgSW5QbGFjZSAKVGhpcyBmbGFnIGlzIHVzZWQgb25seSBmb3IgYW4gRVJST1JfU1BFQyBv YmplY3QgaW4gYSBSZXN2RXJyIG1lc3NhZ2UuICBJZiBpdCBvbiwgdGhpcyBmbGFnIGluZGljYXRl cyB0aGF0IHRoZXJlIHdhcywgYW5kIHN0aWxsIGlzLCBhIHJlc2VydmF0aW9uIGluIHBsYWNlIGF0 IHRoZSBmYWlsdXJlIHBvaW50LiAKCjB4MDIgPSBOb3RHdWlsdHkKVGhpcyBmbGFnIGlzIHVzZWQg b25seSBmb3IgYW4gRVJST1JfU1BFQyBvYmplY3QgaW4gYSBSZXN2RXJyIG1lc3NhZ2UsIGFuZCBp dCBpcyBvbmx5IHNldCBpbiB0aGUgaW50ZXJmYWNlIHRvIHRoZSByZWNlaXZlciBhcHBsaWNhdGlv bi4gIElmIGl0IG9uLCB0aGlzIGZsYWcgaW5kaWNhdGVzIHRoYXQgdGhlIEZMT1dTUEVDIHRoYXQg ZmFpbGVkIHdhcyBzdHJpY3RseSBncmVhdGVyIHRoYW4gdGhlIEZMT1dTUEVDIHJlcXVlc3RlZCBi eSB0aGlzIHJlY2VpdmVyLgoAAEVycm9yIENvZGUeAABBIG9uZS1vY3RldCBlcnJvciBkZXNjcmlw dGlvbi4LAABFcnJvciBWYWx1ZW4AAEEgdHdvLW9jdGV0IGZpZWxkIGNvbnRhaW5pbmcgYWRkaXRp b25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXJyb3IuICBJdHMgY29udGVudHMgZGVwZW5kIHVw b24gdGhlIEVycm9yIFR5cGUuIwAAU1RZTEUgb2JqZWN0OiBDbGFzcyA9IDgsIEMtVHlwZSA9IDEN AABPcHRpb24gVmVjdG9yEwAAKE5vbmUgYXNzaWduZWQgeWV0KTsAAFRoZSBJUCBzb3VyY2UgYWRk cmVzcyBmb3IgYSBzZW5kZXIgaG9zdC4gIE11c3QgYmUgbm9uLXplcm8uMAAASVB2NCBSRVNWX0NP TkZJUk0gb2JqZWN0OiBDbGFzcyA9IDE1LCBDLVR5cGUgPSAxEQAAUmVjZWl2ZXIgQWRkcmVzcyAI AABOb3QgVXNlZAwAAE1VU1QgYmUgemVybwkAAFR1bm5lbCBJRBIAAEV4dGVuZGVkIFR1bm5lbCBJ RB0AAElQdjQgdHVubmVsIGVuZCBwb2ludCBhZGRyZXNzLgAASVB2NCBhZGRyZXNzIG9mIHRoZSBl Z3Jlc3Mgbm9kZSBmb3IgdGhlIHR1bm5lbFoAAEEgMTYtYml0IGlkZW50aWZpZXIgdXNlZCBpbiB0 aGUgU0VTU0lPTiB0aGF0IHJlbWFpbnMgY29uc3RhbnQgb3ZlciB0aGUgbGlmZSBvZiB0aGUgdHVu bmVsLg4AAE9iamVjdCBGb3JtYXRzBgAATGVuZ3RoCQAAQ2xhc3MtbnVtBgAAQy1UeXBlBgAAT2Jq ZWN0AQAALSgAAExlbmd0aCBvZiBvYmplY3QgaW5jbHVkaW5nIG9iamVjdCBoZWFkZXIrAABUaGUg cmVmcmVzaCB0aW1lb3V0IHBlcmlvZCBpbiBtaWxsaXNlY29uZHMuvwIAQSBzZXQgb2YgYml0IGZp ZWxkcyBnaXZpbmcgdmFsdWVzIGZvciB0aGUgcmVzZXJ2YXRpb24gb3B0aW9ucy4gIElmIG5ldyBv cHRpb25zIGFyZSBhZGRlZCBpbiB0aGUgZnV0dXJlLCBjb3JyZXNwb25kaW5nIGZpZWxkcyBpbiB0 aGUgb3B0aW9uIHZlY3RvciB3aWxsIGJlIGFzc2lnbmVkIGZyb20gdGhlIGxlYXN0LXNpZ25pZmlj YW50IGVuZC4gIElmIGEgbm9kZSBkb2VzIG5vdCByZWNvZ25pemUgYSBzdHlsZSBJRCwgaXQgbWF5 IGludGVycHJldCBhcyBtdWNoIG9mIHRoZSBvcHRpb24gdmVjdG9yIGFzIGl0IGNhbiwgaWdub3Jp bmcgbmV3IGZpZWxkcyB0aGF0IG1heSBoYXZlIGJlZW4gZGVmaW5lZC4gVGhlIG9wdGlvbiB2ZWN0 b3IgYml0cyBhcmUgYXNzaWduZWQgKGZyb20gdGhlIGxlZnQpIGFzIGZvbGxvd3M6CgoxOSBiaXRz OiBSZXNlcnZlZAoKMiBiaXRzOiBTaGFyaW5nIGNvbnRyb2wKMDBiOiBSZXNlcnZlZAowMWI6IERp c3RpbmN0IHJlc2VydmF0aW9ucwoxMGI6IFNoYXJlZCByZXNlcnZhdGlvbnMKCjMgYml0czogU2Vu ZGVyIHNlbGVjdGlvbiBjb250cm9sCjAwMGI6IFJlc2VydmVkCjAxMGI6IEV4cGxpY2l0CjAxMWIg LSAxMTFiOiBSZXNlcnZlZAoKVGhlIGxvdyBvcmRlciBiaXRzIG9mIHRoZSBvcHRpb24gdmVjdG9y IGFyZSBkZXRlcm1pbmVkIGJ5IHRoZSBzdHlsZSwgYXMgZm9sbG93czoKRkYgMDEwMTBiClNFIDEw MDEwYi8AAElQdjQgRklMVEVSX1NQRUMgb2JqZWN0OiBDbGFzcyA9IDEwLCBDLVR5cGUgPSA3GgAA SVB2NCB0dW5uZWwgc2VuZGVyIGFkZHJlc3MeAABJUHY0IGFkZHJlc3MgZm9yIGEgc2VuZGVyIG5v ZGUGAABMU1AgSUSKAABBIDE2LWJpdCBpZGVudGlmaWVyIHVzZWQgaW4gdGhlIFNFTkRFUl9URU1Q TEFURSBhbmQgdGhlIEZJTFRFUl9TUEVDICB0aGF0IGNhbiBiZSBjaGFuZ2VkIHRvIGFsbG93IGEg c2VuZGVyIHRvIHNoYXJlIHJlc291cmNlcyB3aXRoIGl0c2VsZi4zAABJUHY0IFNFTkRFUl9URU1Q TEFURSBvYmplY3Q6IENsYXNzID0gMTEsIEMtVHlwZSA9IDdAAABMYWJlbCBSZXF1ZXN0IHdpdGhv dXQgTGFiZWwgUmFuZ2Ugb2JqZWN0OiBDbGFzcyA9IDE5LCBDLVR5cGUgPSAxBQAATDNQSURdAABU aGlzIGZpZWxkIGlzIHJlc2VydmVkLiBJdCBNVVNUIGJlIHNldCB0byB6ZXJvIG9uIHRyYW5zbWlz c2lvbiBhbmQgTVVTVCBiZSBpZ25vcmVkIG9uIHJlY2VpcHRaAABBbiBpZGVudGlmaWVyIG9mIHRo ZSBsYXllciAzIHByb3RvY29sIHVzaW5nIHRoaXMgcGF0aC4gU3RhbmRhcmQgRXRoZXJ0eXBlIHZh bHVlcyBhcmUgdXNlZC4ZAABGaXJzdCA0IGJpdHMgYXJlIHJlc2VydmVkCwAATWluaW11bSBWUEnx AABUaGlzIDEyIGJpdCBmaWVsZCBzcGVjaWZpZXMgdGhlIGxvd2VyIGJvdW5kIG9mIGEgYmxvY2sg b2YgVmlydHVhbCBQYXRoIElkZW50aWZpZXJzIHRoYXQgaXMgc3VwcG9ydGVkIG9uIHRoZSBvcmln aW5hdGluZyBzd2l0Y2guICBJZiB0aGUgVlBJIGlzIGxlc3MgdGhhbiAxMi1iaXRzIGl0IE1VU1Qg YmUgcmlnaHQganVzdGlmaWVkIGluIHRoaXMgZmllbGQgYW5kIHByZWNlZGluZyBiaXRzIE1VU1Qg YmUgc2V0IHRvIHplcm8uDAAATWluaW11bSBWQ0kg9wAAVGhpcyAxNiBiaXQgZmllbGQgc3BlY2lm aWVzIHRoZSBsb3dlciBib3VuZCBvZiBhIGJsb2NrIG9mIFZpcnR1YWwgQ29ubmVjdGlvbiBJZGVu dGlmaWVycyB0aGF0IGlzIHN1cHBvcnRlZCBvbiB0aGUgb3JpZ2luYXRpbmcgc3dpdGNoLiAgSWYg dGhlIFZDSSBpcyBsZXNzIHRoYW4gMTYtYml0cyBpdCBNVVNUIGJlIHJpZ2h0IGp1c3RpZmllZCBp biB0aGlzIGZpZWxkIGFuZCBwcmVjZWRpbmcgYml0cyBNVVNUIGJlIHNldCB0byB6ZXJvLgsAAE1h eGltdW0gVlBJ8QAAVGhpcyAxMiBiaXQgZmllbGQgc3BlY2lmaWVzIHRoZSB1cHBlciBib3VuZCBv ZiBhIGJsb2NrIG9mIFZpcnR1YWwgUGF0aCBJZGVudGlmaWVycyB0aGF0IGlzIHN1cHBvcnRlZCBv biB0aGUgb3JpZ2luYXRpbmcgc3dpdGNoLiAgSWYgdGhlIFZQSSBpcyBsZXNzIHRoYW4gMTItYml0 cyBpdCBNVVNUIGJlIHJpZ2h0IGp1c3RpZmllZCBpbiB0aGlzIGZpZWxkIGFuZCBwcmVjZWRpbmcg Yml0cyBNVVNUIGJlIHNldCB0byB6ZXJvLvcAAFRoaXMgMTYgYml0IGZpZWxkIHNwZWNpZmllcyB0 aGUgdXBwZXIgYm91bmQgb2YgYSBibG9jayBvZiBWaXJ0dWFsIENvbm5lY3Rpb24gSWRlbnRpZmll cnMgdGhhdCBpcyBzdXBwb3J0ZWQgb24gdGhlIG9yaWdpbmF0aW5nIHN3aXRjaC4gIElmIHRoZSBW Q0kgaXMgbGVzcyB0aGFuIDE2LWJpdHMgaXQgTVVTVCBiZSByaWdodCBqdXN0aWZpZWQgaW4gdGhp cyBmaWVsZCBhbmQgcHJlY2VkaW5nIGJpdHMgTVVTVCBiZSBzZXQgdG8gemVyby4LAABNYXhpbXVt IFZDSQMAAERMSRkAAEZpcnN0IDcgYml0cyBhcmUgcmVzZXJ2ZWQMAABNaW5pbXVtIERMQ0kZAABG aXJzdCA5IGJpdHMgYXJlIHJlc2VydmVkDAAATWF4aW11bSBETENJ4QAAVGhpcyAyMy1iaXQgZmll bGQgc3BlY2lmaWVzIHRoZSBsb3dlciBib3VuZCBvZiBhIGJsb2NrIG9mIERhdGEgTGluayBDb25u ZWN0aW9uIElkZW50aWZpZXJzIChETENJcykgdGhhdCBpcyBzdXBwb3J0ZWQgb24gdGhlIG9yaWdp bmF0aW5nIHN3aXRjaC4gIFRoZSBETENJIE1VU1QgYmUgcmlnaHQganVzdGlmaWVkIGluIHRoaXMg ZmllbGQgYW5kIHVudXNlZCBiaXRzIE1VU1QgYmUgc2V0IHRvIDAu4wAAVGhpcyAyMy1iaXQgZmll bGQgc3BlY2lmaWVzIHRoZSB1cHBlciBib3VuZCBvZiBhIGJsb2NrIG9mICBEYXRhIExpbmsgQ29u bmVjdGlvbiBJZGVudGlmaWVycyAgKERMQ0lzKSB0aGF0IGlzIHN1cHBvcnRlZCBvbiB0aGUgb3Jp Z2luYXRpbmcgc3dpdGNoLiAgVGhlIERMQ0kgTVVTVCBiZSByaWdodCBqdXN0aWZpZWQgaW4gdGhp cyBmaWVsZCBhbmQgdW51c2VkIGJpdHMgTVVTVCBiZSBzZXQgdG8gMC4dAABNZXNzYWdlIGZvcm1h dCB2ZXJzaW9uIG51bWJlchAAAFZlcnNpb24gKDQgYml0cykSAABSZXNlcnZlZCAoMTIgYml0cykO AABTZXJ2aWNlIEhlYWRlcggAADAgKDFiaXQpEQAAUmVzZXJ2ZWQgKDcgYml0cykOAABPdmVyYWxs IExlbmd0aB8AAExlbmd0aCBvZiBjb250cm9sbGVkLWxvYWQgZGF0YS4MAABQYXJhbWV0ZXIgSUQh AABQYXJhbWV0ZXIgMTI3IChUb2tlbiBCdWNrZXQgU3BlYykTAABQYXJhbWV0ZXIgMTI3IEZsYWdz CAAATm9uZSBTZXQUAABQYXJhbWV0ZXIgMTI3IExlbmd0aCgAADUgV29yZHMgbm90IGluY2x1ZGlu ZyBwZXItc2VydmljZSBoZWFkZXIUAABNaW5pbXVtIFBvbGljZWQgVW5pdA4AAFBlYWsgRGF0YSBS YXRlEQAAVG9rZW4gQnVja2V0IFNpemURAABUb2tlbiBCdWNrZXQgUmF0ZRQAACBNYXhpbXVtIFBh Y2tldCBTaXplAwIAVGhlIG1heGltdW0gcGFja2V0IHNpemUgcGFyYW1ldGVyIFtNXSBzaG91bGQg YmUgc2V0IHRvIHRoZSB2YWx1ZSBvZiB0aGUgc21hbGxlc3QgcGF0aCBNVFUsIHdoaWNoIHRoZSBy ZWNlaXZlciBsZWFybnMgZnJvbSBpbmZvcm1hdGlvbiBpbiBhcnJpdmluZyBSU1ZQIEFEU1BFQyBv YmplY3RzLiAgQWx0ZXJuYXRpdmVseSwgaWYgdGhlIHJlY2VpdmluZyBhcHBsaWNhdGlvbiBoYXMg YnVpbHQtaW4ga25vd2xlZGdlIG9mIHRoZSBtYXhpbXVtIHBhY2tldCBzaXplIGluIHVzZSB3aXRo aW4gdGhlIFJTVlAgc2Vzc2lvbiwgYW5kIHRoaXMgdmFsdWUgaXMgc21hbGxlciB0aGFuIHRoZSBz bWFsbGVzdCBwYXRoIE1UVSwgW01dIG1heSBiZSBzZXQgdG8gdGhpcyB2YWx1ZS4gIE5vdGUgdGhh dCByZXF1ZXN0aW5nIGEgdmFsdWUgb2YgW01dIGxhcmdlciB0aGFuIHRoZSBzZXJ2aWNlIG1vZHVs ZXMgYWxvbmcgdGhlIGRhdGEgcGF0aCBjYW4gc3VwcG9ydCB3aWxsIGNhdXNlIHRoZSByZXNlcnZh dGlvbiB0byBmYWlsLiAiAABTZXJ2aWNlIG51bWJlciA1IChDb250cm9sbGVkLUxvYWQpLQAAT3Zl cmFsbCBsZW5ndGggKDcgd29yZHMgbm90IGluY2x1ZGluZyBoZWFkZXIpSAAATGVuZ3RoIG9mIGNv bnRyb2xsZWQtbG9hZCBkYXRhLCA2IHdvcmRzIG5vdCBpbmNsdWRpbmcgcGVyLXNlcnZpY2UgaGVh ZGVyOAAARmxvd3NwZWMgb2JqZWN0IChDb250cm9sbGVkIExvYWQpOiBDbGFzcyA9IDksIEMtVHlw ZSA9IDI7AABGbG93c3BlYyBvYmplY3QgKEd1YXJhbnRlZWQgU2VydmljZSk6IENsYXNzID0gOSwg Qy1UeXBlID0gMhAAAFVudXNlZCAoMTIgYml0cykGAABVbnVzZWQdAABTZXJ2aWNlIG51bWJlciAy IChHdWFyYW50ZWVkKUQAAExlbmd0aCBvZiBwZXItc2VydmljZSBkYXRhLCA5IHdvcmRzIG5vdCBp bmNsdWRpbmcgcGVyLXNlcnZpY2UgaGVhZGVyGgAATGVuZ3RoIG9mIHBlci1zZXJ2aWNlIGRhdGEo AABQYXJhbWV0ZXIgMTMwIChHdWFyYW50ZWVkIFNlcnZpY2UgUlNwZWMpEwAAUGFyYW1ldGVyIDEz MCBGbGFncxQAAFBhcmFtZXRlciAxMzAgTGVuZ3RoKAAAMiBXb3JkcyBub3QgaW5jbHVkaW5nIHBl ci1zZXJ2aWNlIGhlYWRlcgQAAFJhdGUKAABTbGFjayBUZXJtJgAARmxvd3NwZWMgb2JqZWN0OiBD bGFzcyA9IDksIEMtVHlwZSA9IDMDAABDb1MTAABNYXhpbXVtIFBhY2tldCBTaXplnQAASW5kaWNh dGVzIHRoZSBDbGFzcyBvZiBTZXJ2aWNlIChDb1MpIG9mIHRoZSBkYXRhIHRyYWZmaWMgYXNzb2Np YXRlZCB3aXRoIHRoZSByZXF1ZXN0LiBBIHZhbHVlIG9mIHplcm8gKDApIGluZGljYXRlcyB0aGF0 IGFzc29jaWF0ZWQgdHJhZmZpYyBpcyAiQmVzdC1FZmZvcnQiLhIBAFRoZSBtYXhpbXVtIHBhY2tl dCBzaXplIHBhcmFtZXRlciBbTV0gU0hPVUxEIGJlIHNldCB0byB0aGUgdmFsdWUgb2YgdGhlIHNt YWxsZXN0IHBhdGggTVRVLiBUaGlzIHBhcmFtZXRlciBpcyBzZXQgaW4gUmVzdiBtZXNzYWdlcyBi eSB0aGUgcmVsaWV2ZXIgYmFzZWQgb24gaW5mb3JtYXRpb24gaW4gYXJyaXZpbmcgUlNWUCBBRFNQ RUMgb2JqZWN0cy4gICBUaGlzIHBhcmFtZXRlciBpcyBpZ25vcmVkIHdoZW4gdGhlIG9iamVjdCBp cyBjb250YWluZWQgaW4gUGF0aCBtZXNzYWdlcy4rAABTZW5kZXJfVFNQRUMgb2JqZWN0OiBDbGFz cyA9IDEyLCBDLVR5cGUgPSAyLQAAU2VydmljZSBudW1iZXIgMSAoZGVmYXVsdC9nbG9iYWwgaW5m b3JtYXRpb24pNgAATGVuZ3RoIG9mIHNlcnZpY2UgMSBkYXRhLCA2IHdvcmRzIG5vdCBpbmNsdWRp bmcgaGVhZGVyGAAATGVuZ3RoIG9mIHNlcnZpY2UgMSBkYXRhHAAANSB3b3JkcyBub3QgaW5jbHVk aW5nIGhlYWRlcisAAFNlbmRlcl9UU1BFQyBvYmplY3Q6IENsYXNzID0gMTIsIEMtVHlwZSA9IDNs AQBJbmRpY2F0ZXMgdGhlIENsYXNzIG9mIFNlcnZpY2UgKENvUykgb2YgdGhlIGRhdGEgdHJhZmZp YyBhc3NvY2lhdGVkIHdpdGggdGhlIHJlcXVlc3QuICBBIHZhbHVlIG9mIHplcm8gKDApIGluZGlj YXRlcyB0aGF0IGFzc29jaWF0ZWQgdHJhZmZpYyBpcyAiQmVzdC1FZmZvcnQiLiAgU3BlY2lmaWNh bGx5IG5vIHNlcnZpY2UgYXNzdXJhbmNlcyBhcmUgYmVpbmcgcmVxdWVzdGVkIGZyb20gdGhlIG5l dHdvcmsuIE5vbi16ZXJvIHZhbHVlcyBoYXZlIGxvY2FsIHNpZ25pZmljYW5jZS4gVGhlIHRyYW5z bGF0aW9uIGZyb20gYSBzcGVjaWZpYyB2YWx1ZSB0byBhbiBhbGxvY2F0aW9uIGlzIGEgbG9jYWwg YWRtaW5pc3RyYXRpdmUgZGVjaXNpb24uEAEAVGhlIG1heGltdW0gcGFja2V0IHNpemUgcGFyYW1l dGVyIFtNXSBTSE9VTEQgYmUgc2V0IHRvIHRoZSB2YWx1ZSBvZiB0aGUgc21hbGxlc3QgcGF0aCBN VFUuIFRoaXMgcGFyYW1ldGVyIGlzIHNldCBpbiBSZXN2IG1lc3NhZ2VzIGJ5IHRoZSByZWxpZXZl ciBiYXNlZCBvbiBpbmZvcm1hdGlvbiBpbiBhcnJpdmluZyBSU1ZQIEFEU1BFQyBvYmplY3RzLiBU aGlzIHBhcmFtZXRlciBpcyBpZ25vcmVkIHdoZW4gdGhlIG9iamVjdCBpcyBjb250YWluZWQgaW4g UGF0aCBtZXNzYWdlcy4eAABNZXNzYWdlIGZvcm1hdCB2ZXJzaW9uIG51bWJlciASAABWZXJzaW9u IG51bWJlciAoMCkOAABNZXNzYWdlIExlbmd0aA4AAE1lc3NhZ2UgSGVhZGVyLAAARGVmYXVsdCBH ZW5lcmFsIENoYXJhY3Rlcml6YXRpb24gUGFyYW1ldGVycyBBAABQZXItU2VydmljZSBoZWFkZXIs IHNlcnZpY2UgbnVtYmVyIDEgKERlZmF1bHQgR2VuZXJhbCBQYXJhbWV0ZXJzKQYAAEhlYWRlcmIA AEdsb2JhbCBCcmVhayBiaXQgKFtSRkMgMjIxNV0sIFBhcmFtZXRlciAyKSAobWFya2VkIHgpIGFu ZCBsZW5ndGggb2YgR2VuZXJhbCBQYXJhbWV0ZXJzIGRhdGEgYmxvY2suDwAAUmVzZXJ2ZWQgNyBi aXRzAQAAeAUAADEgYml0QwAAUGFyYW1ldGVyIElELCBwYXJhbWV0ZXIgNCAoTnVtYmVyLW9mLUlT LWhvcHMgcGFyYW0gZnJvbSBbUkZDIDIyMTVdKRAAAEdsb2JhbCBCcmVhayBiaXQVAABQYXJhbWV0 ZXIgNCBmbGFnIGJ5dGUSAABQYXJhbWV0ZXIgNCBsZW5ndGgvAABQYXJhbWV0ZXIgNCBsZW5ndGgs IDEgd29yZCBub3QgaW5jbHVkaW5nIGhlYWRlcjkAAFBhcmFtZXRlciBJRCwgcGFyYW1ldGVyIDYg KFBhdGgtQlcgcGFyYW0gZnJvbSBbUkZDIDIyMTVdKQ4AAFBhcmFtZXRlciBJRCA0DgAAUGFyYW1l dGVyIElEIDYVAABQYXJhbWV0ZXIgNiBmbGFnIGJ5dGUSAABQYXJhbWV0ZXIgNiBsZW5ndGgvAABQ YXJhbWV0ZXIgNiBsZW5ndGgsIDEgd29yZCBub3QgaW5jbHVkaW5nIGhlYWRlciQAAElTIGhvcCBj bnQgKDMyLWJpdCB1bnNpZ25lZCBpbnRlZ2VyKQsAAElTIGhvcCBjbnQgPABiFTYAAFBhdGggYi93 IGVzdGltYXRlICAoMzItYml0IElFRUUgZmxvYXRpbmcgcG9pbnQgbnVtYmVyKREAAFBhdGggYi93 IGVzdGltYXRlQAAAUGFyYW1ldGVyIElELCBwYXJhbWV0ZXIgOCAobWluaW11bSBwYXRoIGxhdGVu Y3kgZnJvbSBbUkZDIDIyMTVdKQ4AAFBhcmFtZXRlciBJRCA4FQAAUGFyYW1ldGVyIDggZmxhZyBi eXRlEgAAUGFyYW1ldGVyIDggbGVuZ3RoLwAAUGFyYW1ldGVyIDggbGVuZ3RoLCAxIHdvcmQgbm90 IGluY2x1ZGluZyBoZWFkZXIVAABNaW5pbXVtIHBhdGggbGF0ZW5jeSAPAABQYXJhbWV0ZXIgSUQg MTAWAABQYXJhbWV0ZXIgMTAgZmxhZyBieXRlEwAAUGFyYW1ldGVyIDEwIGxlbmd0aD4AAFBhcmFt ZXRlciBJRCwgcGFyYW1ldGVyIDEwIChjb21wb3NlZCBwYXRoIE1UVSBmcm9tIFtSRkMgMjIxNV0p MAAAUGFyYW1ldGVyIDEwIGxlbmd0aCwgMSB3b3JkIG5vdCBpbmNsdWRpbmcgaGVhZGVyDQAAQ29t cG9zZWQgTVRVICcAAEd1YXJhbnRlZWQgU2VydmljZSBBRFNQRUMgZGF0YSBmcmFnbWVudDEAAFBl ci1TZXJ2aWNlIGhlYWRlciwgc2VydmljZSBudW1iZXIgMiAoR3VhcmFudGVlZClTAABCcmVhayBi aXQgYW5kIExlbmd0aCBvZiBwZXItc2VydmljZSBkYXRhIGluIDMyLWJpdCB3b3JkcyBub3QgaW5j bHVkaW5nIGhlYWRlciB3b3JkLisAAFBhcmFtZXRlciBJRCwgcGFyYW1ldGVyIDEzMyAoQ29tcG9z ZWQgQ3RvdCkXAABQYXJhbWV0ZXIgMTMzIGZsYWcgYnl0ZTEAAFBhcmFtZXRlciAxMzMgbGVuZ3Ro LCAxIHdvcmQgbm90IGluY2x1ZGluZyBoZWFkZXIUAABQYXJhbWV0ZXIgMTMzIGxlbmd0aBAAAFBh cmFtZXRlciBJRCAxMzMnAABFbmQtdG8tZW5kIGNvbXBvc2VkIHZhbHVlIGZvciBDIFtDdG90XSAK AABDdG90IHZhbHVlEAAAUGFyYW1ldGVyIElEIDEzNBcAAFBhcmFtZXRlciAxMzQgZmxhZyBieXRl FAAAUGFyYW1ldGVyIDEzNCBsZW5ndGgxAABQYXJhbWV0ZXIgMTM0IGxlbmd0aCwgMSB3b3JkIG5v dCBpbmNsdWRpbmcgaGVhZGVyKwAAUGFyYW1ldGVyIElELCBwYXJhbWV0ZXIgMTM0IChDb21wb3Nl ZCBEdG90KQoAAER0b3QgdmFsdWUnAABFbmQtdG8tZW5kIGNvbXBvc2VkIHZhbHVlIGZvciBEIFtE dG90XSAsAABQYXJhbWV0ZXIgSUQsIHBhcmFtZXRlciAxMzUgKENvbXBvc2VkIENzdW0pLhAAAFBh cmFtZXRlciBJRCAxMzUXAABQYXJhbWV0ZXIgMTM1IGZsYWcgYnl0ZRQAAFBhcmFtZXRlciAxMzUg bGVuZ3RoMQAAUGFyYW1ldGVyIDEzNSBsZW5ndGgsIDEgd29yZCBub3QgaW5jbHVkaW5nIGhlYWRl ciwAAFNpbmNlLWxhc3QtcmVzaGFwaW5nIHBvaW50IGNvbXBvc2VkIEMgW0NzdW1dEQAAW0NzdW1d IHNpbmNlIGxhc3QQAABQYXJhbWV0ZXIgSUQgMTM2FwAAUGFyYW1ldGVyIDEzNiBmbGFnIGJ5dGUU AABQYXJhbWV0ZXIgMTM2IGxlbmd0aDEAAFBhcmFtZXRlciAxMzYgbGVuZ3RoLCAxIHdvcmQgbm90 IGluY2x1ZGluZyBoZWFkZXIsAABQYXJhbWV0ZXIgSUQsIHBhcmFtZXRlciAxMzYgKENvbXBvc2Vk IERzdW0pLhEAAFtEc3VtXSBzaW5jZSBsYXN0LAAAU2luY2UtbGFzdC1yZXNoYXBpbmcgcG9pbnQg Y29tcG9zZWQgRCBbRHN1bV0+AABTZXJ2aWNlLXNwZWNpZmljIGdlbmVyYWwgcGFyYW1ldGVyIGhl YWRlcnMvdmFsdWVzLCBpZiBwcmVzZW50IC8AAEd1YXJhbnRlZWQgU2VydmljZSBBRFNQRUMgZGF0 YSBmcmFnbWVudCAiRW1wdHkiJQAAQURTUEVDIG9iamVjdDogQ2xhc3MgPSAxMywgQy1UeXBlID0g MiwAAENvbnRyb2xsZWQtTG9hZCBTZXJ2aWNlIEFEU1BFQyBkYXRhIGZyYWdtZW50NgAAUGVyLVNl cnZpY2UgaGVhZGVyLCBzZXJ2aWNlIG51bWJlciA1IChDb250cm9sbGVkLUxvYWQpRQAATGVuZ3Ro IG9mIHBlci1zZXJ2aWNlIGRhdGEgaW4gMzIgYml0IHdvcmRzIG5vdCBpbmNsdWRpbmcgaGVhZGVy IHdvcmQuCQAAQnJlYWsgQml0EgAAQnJlYWsgQml0ICg3IGJpdHMpPwAAT3ZlcnJpZGluZyBHbG9i YWwgQURTUEVDIERhdGEgd2l0aCBTZXJ2aWNlLVNwZWNpZmljIEluZm9ybWF0aW9uVgAAUGFyYW1l dGVyIElELCBwYXJhbWV0ZXIgNiAoQVZBSUxBQkxFX1BBVEhfQkFORFdJRFRIIGdlbmVyYWwgcGFy YW1ldGVyIGZyb20gW1JGQyAyMjE1XSkcAABQYXJhbWV0ZXIgNiBmbGFncyAobm9uZSBzZXQpEQAA UGFyYW1ldGVyIDYgZmxhZ3MxAABQYXJhbWV0ZXIgNiBsZW5ndGgsIG9uZSB3b3JkIG5vdCBpbmNs dWRpbmcgaGVhZGVyIQAAUGF0aCBiL3cgZXN0aW1hdGUgZm9yIEMtTCBzZXJ2aWNlOgAATGFiZWwg UmVxdWVzdCB3aXRoIEFUTSBMYWJlbCBSYW5nZTogQ2xhc3MgPSAxOSwgQy1UeXBlID0gMisAAFJl Y29yZCBSb3V0ZSBvYmplY3Q6IENsYXNzID0gMjEsIEMtVHlwZSA9IDMEAABUeXBlDAAASVB2NCBh ZGRyZXNzDQAAUHJlZml4IExlbmd0aBIAADB4MDEgIElQdjQgYWRkcmVzc30AAFRoZSBMZW5ndGgg Y29udGFpbnMgdGhlIHRvdGFsIGxlbmd0aCBvZiB0aGUgc3Vib2JqZWN0IGluIGJ5dGVzLCBpbmNs dWRpbmcgdGhlIFR5cGUgYW5kIExlbmd0aCBmaWVsZHMuIFRoZSBMZW5ndGggaXMgYWx3YXlzIDgu pAAAQSAzMi1iaXQgdW5pY2FzdCwgaG9zdCBhZGRyZXNzLiAgQW55IG5ldHdvcmstcmVhY2hhYmxl IGludGVyZmFjZSBhZGRyZXNzIGlzIGFsbG93ZWQgaGVyZS4gSWxsZWdhbCBhZGRyZXNzZXMsIHN1 Y2ggYXMgY2VydGFpbiBsb29wYmFjayBhZGRyZXNzZXMsIFNIT1VMRCBOT1QgYmUgdXNlZC4gAAAw eDAxICBMb2NhbCBwcm90ZWN0aW9uIGF2YWlsYWJsZSQAAExBQkVMIG9iamVjdDogQ2xhc3MgPSAx NiwgQy1UeXBlID0gMQUAAExhYmVs+AEATGFiZWxzIE1BWSBiZSBjYXJyaWVkIGluIFJlc3YgbWVz c2FnZXMuIEZvciB0aGUgRkYgYW5kIFNFIHN0eWxlcywgYSBsYWJlbCBpcyBhc3NvY2lhdGVkIHdp dGggZWFjaCBzZW5kZXIuICBUaGUgbGFiZWwgZm9yIGEgc2VuZGVyIE1VU1QgaW1tZWRpYXRlbHkg Zm9sbG93IHRoZSBGSUxURVJfU1BFQyBmb3IgdGhhdCBzZW5kZXIgaW4gdGhlIFJlc3YgbWVzc2Fn ZS4gIFRoZSBjb250ZW50cyBvZiBhIExBQkVMIG9iamVjdCBhcmUgYSBzdGFjayBvZiBsYWJlbHMs IHdoZXJlIGVhY2ggbGFiZWwgaXMgZW5jb2RlZCByaWdodCBhbGlnbmVkIGluIDQgb2N0ZXRzLiBU aGUgdG9wIG9mIHRoZSBzdGFjayBpcyBpbiB0aGUgcmlnaHQgNCBvY3RldHMgb2YgdGhlIG9iamVj dCBjb250ZW50cy4gIEEgTEFCRUwgb2JqZWN0IHRoYXQgY29udGFpbnMgbm8gbGFiZWxzIGlzIGls bGVnYWwuIEVhY2ggbGFiZWwgaXMgYW4gdW5zaWduZWQgaW50ZWdlciBpbiB0aGUgcmFuZ2UgMCB0 aHJvdWdoIDEwNDg1NzUuXgAAVGhpcyBmaWVsZCBpcyByZXNlcnZlZC4gSXQgTVVTVCBiZSBzZXQg dG8gemVybyBvbiB0cmFuc21pc3Npb24gYW5kIE1VU1QgYmUgaWdub3JlZCBvbiByZWNlaXB0Li0A AEV4cGxpY2l0IFJvdXRlIG9iamVjdDogQ2xhc3MgPSAyMCwgQy1UeXBlID0gMQ0AAEwgYml0ICgx IGJpdCkNAABUeXBlICg3IGJpdHMpCwAASVB2NCBwcmVmaXgNAABJUHY0IGFkZHJlc3MgDgAAUHJl Zml4IExlbmd0aCDRAABUaGUgTCBiaXQgaXMgYW4gYXR0cmlidXRlIG9mIHRoZSBzdWJvYmplY3Qu ICBUaGUgTCBiaXQgaXMgc2V0IGlmICB0aGUgc3Vib2JqZWN0IHJlcHJlc2VudHMgYSBsb29zZSBo b3AgaW4gdGhlIGV4cGxpY2l0IHJvdXRlLiBJZiB0aGUgYml0IGlzIG5vdCBzZXQsIHRoZSBzdWJv YmplY3QgcmVwcmVzZW50cyBhIHN0cmljdCBob3AgaW4gdGhlIGV4cGxpY2l0IHJvdXRlLgkAAFNl ZSBhYm92ZWoAAFRoZSBMZW5ndGggY29udGFpbnMgdGhlIHN1Ym9iamVjdCBpbiBieXRlcywgaW5j bHVkaW5nIHRoZSBUeXBlIGFuZCBMZW5ndGggZmllbGRzLiAgVGhlIExlbmd0aCBpcyBhbHdheXMg OC63AABBbiBJUHY0IGFkZHJlc3MuICBUaGlzIGFkZHJlc3MgaXMgdHJlYXRlZCBhcyBhIHByZWZp eCBiYXNlZCBvbiB0aGUgcHJlZml4IGxlbmd0aCB2YWx1ZSBiZWxvdy4gIEJpdHMgYmV5b25kIHRo ZSBwcmVmaXggYXJlIGlnbm9yZWQgb24gcmVjZWlwdCBhbmQgU0hPVUxEIGJlIHNldCB0byB6ZXJv IG9uIHRyYW5zbWlzc2lvbi4qAABaZXJvIG9uIHRyYW5zbWlzc2lvbi4gIElnbm9yZWQgb24gcmVj ZWlwdC4nAABTdWJvYmplY3QgMzI6ICBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXIJAABBUyBOdW1i ZXK8AABUaGUgY29udGVudHMgb2YgYW4gQXV0b25vbW91cyBTeXN0ZW0gKEFTKSBudW1iZXIgc3Vi b2JqZWN0IGFyZSBhIDItb2N0ZXQgQVMgbnVtYmVyLiAgVGhlIGFic3RyYWN0IG5vZGUgcmVwcmVz ZW50ZWQgYnkgdGhpcyBzdWJvYmplY3QgaXMgdGhlIHNldCBvZiBub2RlcyBiZWxvbmdpbmcgdG8g dGhlIGF1dG9ub21vdXMgc3lzdGVtLjIAAFRoZSBsZW5ndGggb2YgdGhlIEFTIG51bWJlciBzdWJv YmplY3QgaXMgNCBvY3RldHMuMwAAU3Vib2JqZWN0IDY0OiAgTVBMUyBMYWJlbCBTd2l0Y2hlZCBQ YXRoIFRlcm1pbmF0aW9uTQAAVGhlIGxlbmd0aCBvZiB0aGUgTVBMUyBsYWJlbCBzd2l0Y2hlZCBw YXRoIHRlcm1pbmF0aW9uIHN1Ym9iamVjdCBpcyA0IG9jdGV0cy7dAABUaGUgY29udGVudHMgb2Yg YW4gTVBMUyBsYWJlbCBzd2l0Y2hlZCBwYXRoIHRlcm1pbmF0aW9uIHN1Ym9iamVjdCBhcmUgMiBv Y3RldHMgb2YgcGFkZGluZy4gIFRoaXMgc3Vib2JqZWN0IGlzIGFuIG9wZXJhdGlvbiBzdWJvYmpl Y3QuICBUaGlzIG9iamVjdCBpcyBvbmx5IG1lYW5pbmdmdWwgaWYgdGhlcmUgaXMgYSBMQUJFTF9S RVFVRVNUIG9iamVjdCBpbiB0aGUgUGF0aCBtZXNzYWdlLqsAAEEgMiBiaXQgZmllbGQgdGhhdCBp cyB0aGUgRExDSSBMZW5ndGggSW5kaWNhdG9yLiAgVGhlIG51bWJlciBvZiBiaXRzIGluIHRoZSBE TENJLiBUaGUgZm9sbG93aW5nIHZhbHVlcyBhcmUgc3VwcG9ydGVkOgoKTGVuICAgIERMQ0kgYml0 cwowICAgICAgICAxMAoxICAgICAgICAxNwoyICAgICAgICAyM0IAAExhYmVsIFJlcXVlc3Qgd2l0 aCBGcmFtZSBSZWxheSBMYWJlbCBSYW5nZTogQ2xhc3MgPSAxOSwgQy1UeXBlID0gMxoBAEEgMzIt Yml0IGlkZW50aWZpZXIgdXNlZCBpbiB0aGUgU0VTU0lPTiB0aGF0ICByZW1haW5zICBjb25zdGFu dCBvdmVyICB0aGUgIGxpZmUgIG9mICB0aGUgIHR1bm5lbC4gICBOb3JtYWxseSBzZXQgdG8gYWxs IHplcm9zLiBJbmdyZXNzIG5vZGVzIHRoYXQgd2lzaCB0byBuYXJyb3cgdGhlIHNjb3BlIG9mIGEg U0VTU0lPTiB0byB0aGUgaW5ncmVzcy1lZ3Jlc3MgIHBhaXIgIG1heSAgcGxhY2UgIHRoZWlyICBJ UHY0IGFkZHJlc3MgaGVyZSBhcyBhIGdsb2JhbGx5IHVuaXF1ZSBpZGVudGlmaWVyLjUAAExTUF9U VU5ORUxfSVB2NCBTRVNTSU9OIG9iamVjdDogQ2xhc3MgPSAxLCBDLVR5cGUgPSA3LgAAT3ZlcmFs bCBsZW5ndGggKDEwIHdvcmRzIG5vdCBpbmNsdWRpbmcgaGVhZGVyKTIAAFRoZSBvYmplY3RzIGZv bGxvdyB0aGlzIDQgb2N0ZXQgaGVhZGVyIChTZWUgYmVsb3cpLQAATGVuZ3RoIGluIGJpdHMgb2Yg dGhlIElQdjQgcHJlZml4IFRoaXMgaXMgMzIuEgAAUmVzZXJ2ZWQgKFBhZGRpbmcp/wDyAAgAngoA AAwAAAApCwAAlwAAAOwNAABaAwAASQ8AALcEAABGEAAAtAUAANsQAABJBgAAHBUAAIoKAAAIGAAA dg0AAF8aAADNDwAAnBwAAAoSAABOHQAAvBIAAAsgAAB5FQAAgiEAAPAWAABfIgAAzRcAAOIkAABQ GgAACSgAAHcdAABOKQAAvB4AADYqAACkHwAAVysAAKUAAABQLAAAngEAAMMtAAARAwAAnC4AAOoD AACoLwAA9gQAAKYwAAD0BQAALDIAAHoHAACkMwAA8ggAAFc1AAClCgAAQDgAAI4NAAC/OgAADRAA ABg+AABmEwAACgAAAAkIEAAABhAArxjNB8lAAAAGAQAACwI0AAAAAAABAAAADgEAAJtDAAD7SgAA pVIAAPVZAABFYQAAC2kAAE1wAACpdwAA034AABWCAAANAAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQ AAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAD/AIEA AgDBBBsAIAAFACQAAAD/AFMAAAD/AH4AAAD/AL0AAAD/AOMAAAD/ABQAGQAWAAAmQ1JTVlAgUXVp Y2sgUmVmZXJlbmNlFQAeABsAACZMQmlsbCBTYW5mb3JkJkNQYWdlICZQJlImRIMAAgABAIQAAgAA AE0ATgEAAFwAXABJAE4ARgBPAFMARQBSAFYARQBcAEgAUAA1AEUATgBHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABBAED3ABwAANzAQABAAEAAAAAAAAAAQAPAFgCAgACAFgCAgAAAEwAZQB0 AHQAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAg AP////85AwAAAAAAAP//////////BAATAAYAEQD//wEAAwAAAAEA//8BAAEAAAD//wEAAwD///// //////////////////////////////////8AAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAoQAi AAEATQABAAEAAQACAAAAWAIAAAAAAADgPwAAAAAAAOA/AQBVAAIACAB9AAwAAAAAALYBDwACAAIA fQAMAAEAAQC2BQ8AAgACAH0ADAACAAIAthkPAAIAAgB9AAwAAwADALZBDwACAAIAAAIOAAEAAAAO AQAAAQAEAAAACAIQAAEAAQAEAP8AAAAAAAABDwAIAhAAAgABAAQA/wAAAAAAAAEPAAgCEAADAAEA BAD/AAAAAAAAAQ8ACAIQAAQAAQAEAP8AAAAAAAABDwAIAhAABQABAAQA/wAAAAAAAAEPAAgCEAAG AAEABAD/AAAAAAAAAQ8ACAIQAAcAAQAEAP8AAAAAAAABDwAIAhAACAABAAQA/wAAAAAAAAEPAAgC EAAJAAEABAD/AAAAAAAAAQ8ACAIQAAoAAQAEAP8AAAAAAAABDwAIAhAACwABAAQA/wAAAAAAAAEP AAgCEAAMAAEABAD/AAAAAAAAAQ8ACAIQAA0AAQAEAKMCAAAAAAABDwAIAhAADgABAAQA/wAAAAAA AAEPAAgCEAAPAAEABAD/AAAAAAAAAQ8ACAIQABAAAQAEAP8AAAAAAAABDwAIAhAAEQABAAQA/wAA AAAAAAEPAAgCEAASAAEABAD/AAAAAAAAAQ8ACAIQABMAAQAEAP8AAAAAAAABDwAIAhAAFAABAAQA /wAAAAAAAAEPAAgCEAAVAAEABAD/AAAAAAAAAQ8ACAIQABYAAQAEAP8AAAAAAAABDwAIAhAAFwAB AAQA/wAAAAAAAAEPAAgCEAAYAAEABAD/AAAAAAAAAQ8ACAIQABkAAQAEAP8AAAAAAAABDwAIAhAA GgABAAQA/wAAAAAAAAEPAAgCEAAbAAEABAAIBwAAAAAAAQ8ACAIQABwAAQAEAP8AAAAAAAABDwAI AhAAHQABAAQAwgEAAAAAAAEPAAgCEAAeAAEABAD/AAAAAAAAAQ8ACAIQAB8AAQAEAP8AAAAAAAAB DwAIAhAAIAABAAQA/wAAAAAAAAEPAP0ACgABAAEANAAgAAAAvgAKAAEAAgA1ADYAAwD9AAoAAgAB ABgAAQAAAP0ACgACAAIAGgACAAAA/QAKAAIAAwAaAAMAAAB+AgoAAwABAB0AAAAAQP0ACgADAAIA HAAhAAAA/QAKAAMAAwAnACYAAAB+AgoABAABAB0AAADwP/0ACgAEAAIAHAAiAAAA/QAKAAQAAwAc ACIAAAB+AgoABQABAB0AAADwP/0ACgAFAAIAHAAjAAAA/QAKAAUAAwAcACMAAAD9AAoABgABAB0A JQAAAP0ACgAGAAIAHAAkAAAA/QAKAAYAAwAnAOsAAAC+AAwABwABAC0ALQAtAAMA/QAKAAgAAQA0 AOkAAAC+AAoACAACADUANgADAP0ACgAJAAEAGAABAAAA/QAKAAkAAgAaAAIAAAD9AAoACQADABoA AwAAAH4CCgAKAAEAHQAAABBA/QAKAAoAAgAcAB0AAAD9AAoACgADACcAHgAAAH4CCgALAAEAHQAA AABA/QAKAAsAAgAcABoAAAD9AAoACwADAB0AGgAAAH4CCgAMAAEAHQAAAABA/QAKAAwAAgAcABsA AAD9AAoADAADACIAHwAAAH4CCgANAAEAHQAAABBA/QAKAA0AAgAcABwAAAD9AAoADQADACcA6AAA AL4ADAAOAAEAGwAbACMAAwD9AAoADwABADQABgAAAL4ACgAPAAIANQA2AAMA/QAKABAAAQAYAAEA AAD9AAoAEAACABoAAgAAAP0ACgAQAAMAGgADAAAAfgIKABEAAQAdAAAAEED9AAoAEQACACgABwAA AAECBgARAAMAFgB+AgoAEgABAB0AAAAQQP0ACgASAAIAKQAIAAAAAQIGABIAAwAdAP0ACgATAAEA IAAAAAAAvgAKABMAAgAbABsAAwD9AAoAFAABADQACQAAAL4ACgAUAAIANQA2AAMA/QAKABUAAQAY AAEAAAD9AAoAFQACABoAAgAAAP0ACgAVAAMAGgADAAAAfgIKABYAAQAdAAAAEED9AAoAFgACABwA CgAAAP0ACgAWAAMAJAAnAAAAvgAMABcAAQAgABsAGwADAP0ACgAYAAEANAALAAAAvgAKABgAAgA1 ADYAAwD9AAoAGQABABgAAQAAAP0ACgAZAAIAHwACAAAA/QAKABkAAwAfAAMAAAB+AgoAGgABAB0A AAAQQP0ACgAaAAIAFgANAAAA/QAKABoAAwAWAAwAAAB+AgoAGwABAB0AAADwP/0ACgAbAAIAFwAE AAAA/QAKABsAAwAlAA4AAAB+AgoAHAABAB0AAADwP/0ACgAcAAIAFwAPAAAA/QAKABwAAwAhABAA AAB+AgoAHQABAB0AAAAAQP0ACgAdAAIAHAARAAAA/QAKAB0AAwAkABIAAAD9AAoAHgABACAAAAAA AP0ACgAeAAIAGwAAAAAA/QAKAB4AAwAbAAAAAAD9AAoAHwABADAAEwAAAL4ACgAfAAIAMQAxAAMA /QAKACAAAQAYAAEAAAD9AAoAIAACABoAAgAAAP0ACgAgAAMAGgADAAAA1wBEAAgHAABsAhwAKgAq ACoAKgAqABAAHAAqACoAKgAqACoAEAAcACoAJgAmABwAHAAqACoAEAAcACoAKgAqACoAKgAqABwA CAIQACEAAQAEAP8AAAAAAAABDwAIAhAAIgABAAQAdRIAAAAAAAEPAAgCEAAjAAEABAD/AAAAAAAA AQ8ACAIQACQAAQAEAP8AAAAAAAABDwAIAhAAJQABAAQA/wAAAAAAAAEPAAgCEAAmAAEABAD/AAAA AAAAAQ8ACAIQACcAAQAEAP8AAAAAAAABDwAIAhAAKAABAAQA/wAAAAAAAAEPAAgCEAApAAEABAD/ AAAAAAAAAQ8ACAIQACoAAQAEAP8AAAAAAAABDwAIAhAAKwABAAQA/wAAAAAAAAEPAAgCEAAsAAEA BAD/AAAAAAAAAQ8ACAIQAC0AAQAEAP8AAAAAAAABDwAIAhAALgABAAQA/wAAAAAAAAEPAAgCEAAv AAEABAD/AAAAAAAAAQ8ACAIQADAAAQAEAP8AAAAAAAABDwAIAhAAMQABAAQA/wAAAAAAAAEPAAgC EAAyAAEABAD/AAAAAAAAAQ8ACAIQADMAAQAEAP8AAAAAAAABDwAIAhAANAABAAQARgUAAAAAAAEP AAgCEAA1AAEABAD/AAAAAAAAAQ8ACAIQADYAAQAEAP8AAAAAAAABDwAIAhAANwABAAQA/wAAAAAA AAEPAAgCEAA4AAEABAD/AAAAAAAAAQ8ACAIQADkAAQAEAP8AAAAAAAABDwAIAhAAOgABAAQA/wAA AAAAAAEPAAgCEAA7AAEABAD/AAAAAAAAAQ8ACAIQADwAAQAEAP8AAAAAAAABDwAIAhAAPQABAAQA /wAAAAAAAAEPAAgCEAA+AAEABAD/AAAAAAAAAQ8ACAIQAD8AAQAEAP8AAAAAAAABDwAIAhAAQAAB AAQA/wAAAAAAAAEPAH4CCgAhAAEAHQAAAPA//QAKACEAAgAXAAQAAAD9AAoAIQADABcAFQAAAH4C CgAiAAEAHQAAAAhA/QAKACIAAgAdABQAAAD9AAoAIgADACYAKAAAAP0ACgAjAAEAIAAAAAAA/QAK ACMAAgAbAAAAAAD9AAoAIwADABsAAAAAAP0ACgAkAAEAMABaAAAAvgAKACQAAgAxADEAAwD9AAoA JQABABgAAQAAAP0ACgAlAAIAGQACAAAA/QAKACUAAwAZAAMAAAB+AgoAJgABADIAAAAAQP0ACgAm AAIAHQBEAAAA/QAKACYAAwAiAEMAAAABAgYAJwABADMA/QAKACcAAgAdAEUAAAD9AAoAJwADAB0A BQAAAH4CCgAoAAEAKgAAAABA/QAKACgAAgAdAEkAAAD9AAoAKAADAB0AWAAAAH4CCgApAAEAHQAA APA//QAKACkAAgAdAEYAAAD9AAoAKQADACIAVwAAAH4CCgAqAAEAMgAAAPA//QAKACoAAgAdAEcA AAABAgYAKgADAB0AAQIGACsAAQAzAP0ACgArAAIAHQBIAAAA/QAKACsAAwAdAAUAAAB+AgoALAAB AB0AAAAAQP0ACgAsAAIAHQBKAAAA/QAKACwAAwAdAFkAAAB+AgoALQABAB0AAADwP/0ACgAtAAIA HQBLAAAA/QAKAC0AAwAdAEwAAAB+AgoALgABAB0AAADwP/0ACgAuAAIAHQBNAAAA/QAKAC4AAwAd AE4AAAB+AgoALwABAB0AAAAAQP0ACgAvAAIAHQBPAAAA/QAKAC8AAwAdAFAAAAB+AgoAMAABAB0A AAAQQP0ACgAwAAIAHQBUAAAAAQIGADAAAwAiAH4CCgAxAAEAHQAAABBA/QAKADEAAgAdAFMAAAAB AgYAMQADACIAfgIKADIAAQAdAAAAEED9AAoAMgACAB0AUgAAAAECBgAyAAMAIgB+AgoAMwABAB0A AAAQQP0ACgAzAAIAHQBRAAAAAQIGADMAAwAiAH4CCgA0AAEAHgAAABBA/QAKADQAAgAdAFUAAAD9 AAoANAADACIAVgAAAL4ADAA1AAEAIAAbABsAAwD9AAoANgABADAAWwAAAL4ACgA2AAIAMQAxAAMA /QAKADcAAQAYAAEAAAD9AAoANwACABkAAgAAAP0ACgA3AAMAGQADAAAAfgIKADgAAQAyAAAAAED9 AAoAOAACAB0ARAAAAP0ACgA4AAMAIgBDAAAAAQIGADkAAQAzAP0ACgA5AAIAHQBcAAAA/QAKADkA AwAdAF0AAAB+AgoAOgABACoAAAAAQP0ACgA6AAIAHQBJAAAA/QAKADoAAwAdAOoAAAB+AgoAOwAB AB0AAADwP/0ACgA7AAIAHQBGAAAA/QAKADsAAwAdAF4AAAB+AgoAPAABADIAAADwP/0ACgA8AAIA HQBHAAAAAQIGADwAAwAdAAECBgA9AAEAMwD9AAoAPQACAB0ASAAAAP0ACgA9AAMAHQAFAAAAfgIK AD4AAQAdAAAAAED9AAoAPgACAB0AYAAAAP0ACgA+AAMAHQBfAAAAfgIKAD8AAQAdAAAA8D/9AAoA PwACAB0ASwAAAP0ACgA/AAMAHQBMAAAAfgIKAEAAAQAdAAAA8D/9AAoAQAACAB0ATQAAAP0ACgBA AAMAHQBOAAAA1wBEAGIHAABsAioAKgAqABwAKgAqACYAKgAqACYAJgAqACoAKgAqACYAJgAmACYA KgAQABwAKgAqACYAKgAqACYAJgAqACoACAIQAEEAAQAEAP8AAAAAAAABDwAIAhAAQgABAAQA/wAA AAAAAAEPAAgCEABDAAEABAD/AAAAAAAAAQ8ACAIQAEQAAQAEAP8AAAAAAAABDwAIAhAARQABAAQA /wAAAAAAAAEPAAgCEABGAAEABABGBQAAAAAAAQ8ACAIQAEcAAQAEAP8AAAAAAAABDwAIAhAASAAB AAQA/wAAAAAAAAEPAAgCEABJAAEABAD/AAAAAAAAAQ8ACAIQAEoAAQAEAP8AAAAAAAABDwAIAhAA SwABAAQA/wAAAAAAAAEPAAgCEABMAAEABAD/AAAAAAAAAQ8ACAIQAE0AAQAEAP8AAAAAAAABDwAI AhAATgABAAQA/wAAAAAAAAEPAAgCEABPAAEABAD/AAAAAABAAQ8ACAIQAFAAAQAEAMIBAAAAAAAB DwAIAhAAUQABAAQA/QIAAAAAQAEPAAgCEABSAAEABAD/AAAAAAAAAQ8ACAIQAFMAAQAEAP8AAAAA AAABDwAIAhAAVAABAAQA/wAAAAAAAAEPAAgCEABVAAEABAD/AAAAAAAAAQ8ACAIQAFYAAQAEAP8A AAAAAAABDwAIAhAAVwABAAQA/gEAAAAAQAEPAAgCEABYAAEABAD/AAAAAAAAAQ8ACAIQAFkAAQAE AP8AAAAAAAABDwAIAhAAWgABAAQA/wAAAAAAAAEPAAgCEABbAAEABAD/AAAAAAAAAQ8ACAIQAFwA AQAEAP8AAAAAAAABDwAIAhAAXQABAAQA/gEAAAAAQAEPAAgCEABeAAEABAD/AAAAAAAAAQ8ACAIQ AF8AAQAEAP8AAAAAAAABDwAIAhAAYAABAAQA/wAAAAAAAAEPAH4CCgBBAAEAHQAAAABA/QAKAEEA AgAdAE8AAAD9AAoAQQADAB0AUAAAAH4CCgBCAAEAHQAAABBA/QAKAEIAAgAdAFQAAAABAgYAQgAD ACIAfgIKAEMAAQAdAAAAEED9AAoAQwACAB0AUwAAAAECBgBDAAMAIgB+AgoARAABAB0AAAAQQP0A CgBEAAIAHQBSAAAAAQIGAEQAAwAiAH4CCgBFAAEAHQAAABBA/QAKAEUAAgAdAFEAAAABAgYARQAD ACIAfgIKAEYAAQAeAAAAEED9AAoARgACAB0AVQAAAP0ACgBGAAMAIgBWAAAAfgIKAEcAAQAeAAAA 8D/9AAoARwACAB0ASwAAAP0ACgBHAAMAHQBhAAAAfgIKAEgAAQAeAAAA8D/9AAoASAACAB0AYgAA AP0ACgBIAAMAHQBOAAAAfgIKAEkAAQAeAAAAAED9AAoASQACAB0AYwAAAP0ACgBJAAMAHQBkAAAA fgIKAEoAAQAeAAAAEED9AAoASgACAB0AZQAAAAECBgBKAAMAHQB+AgoASwABAB4AAAAQQP0ACgBL AAIAHQBmAAAAAQIGAEsAAwAdAL4ADABMAAEAIAAbABsAAwD9AAoATQABADAAZwAAAL4ACgBNAAIA MQAxAAMA/QAKAE4AAQAYAAEAAAD9AAoATgACABkAAgAAAP0ACgBOAAMAGQADAAAAfgIKAE8AAQAq AAAA8D/9AAoATwACAB0ABQAAAP0ACgBPAAMAIgDTAAAAfgIKAFAAAQAdAAAA8D/9AAoAUAACAB0A aAAAAP0ACgBQAAMAIgBqAAAAfgIKAFEAAQAdAAAAAED9AAoAUQACACIAaQAAAP0ACgBRAAMAIgBr AAAAvgAMAFIAAQAgABsAGwADAP0ACgBTAAEAMAApAAAAvgAKAFMAAgAxADEAAwD9AAoAVAABABgA AQAAAP0ACgBUAAIAGgACAAAA/QAKAFQAAwAZAAMAAAB+AgoAVQABAB0AAAAQQP0ACgBVAAIAHAAq AAAA/QAKAFUAAwAdACsAAAB+AgoAVgABAB0AAAAAQP0ACgBWAAIAHAAZAAAA/QAKAFYAAwAdABoA AAB+AgoAVwABAB0AAAAAQP0ACgBXAAIAHAAsAAAA/QAKAFcAAwAiAC0AAAC+AAwAWAABACAAGwAb AAMA/QAKAFkAAQA0AC4AAAC+AAoAWQACADUANgADAP0ACgBaAAEAGAABAAAA/QAKAFoAAgAaAAIA AAD9AAoAWgADABkAAwAAAH4CCgBbAAEAHQAAABBA/QAKAFsAAgAcACoAAAD9AAoAWwADAB0AFgAA AH4CCgBcAAEAHQAAAABA/QAKAFwAAgAdABkAAAD9AAoAXAADAB0AGgAAAH4CCgBdAAEAHQAAAABA /QAKAF0AAgAcACwAAAD9AAoAXQADACIALQAAAL4ADABeAAEAGwAbABsAAwD9AAoAXwABADAAbAAA AL4ACgBfAAIAMQAxAAMA/QAKAGAAAQAYAAEAAAD9AAoAYAACABkAAgAAAP0ACgBgAAMAGQADAAAA 1wBEAAgHAABsAioAJgAmACYAJgAqACoAKgAqACYAJgAQABwAKgAqACoAKgAQABwAKgAqACoAKgAQ ABwAKgAqACoAKgAQABwACAIQAGEAAQAEAP8AAAAAAAABDwAIAhAAYgABAAQA/wAAAAAAAAEPAAgC EABjAAEABAD/AAAAAAAAAQ8ACAIQAGQAAQAEAP8AAAAAAAABDwAIAhAAZQABAAQA/wAAAAAAAAEP AAgCEABmAAEABAD/AAAAAAAAAQ8ACAIQAGcAAQAEAP8AAAAAAAABDwAIAhAAaAABAAQA/wAAAAAA AAEPAAgCEABpAAEABAD/AAAAAAAAAQ8ACAIQAGoAAQAEAP8AAAAAAAABDwAIAhAAawABAAQA/wAA AAAAAAEPAAgCEABsAAEABAD/AAAAAAAAAQ8ACAIQAG0AAQAEAP8AAAAAAAABDwAIAhAAbgABAAQA /wAAAAAAAAEPAAgCEABvAAEABABGBQAAAAAAAQ8ACAIQAHAAAQAEAP8AAAAAAAABDwAIAhAAcQAB AAQA/wAAAAAAAAEPAAgCEAByAAEABAD/AAAAAAAAAQ8ACAIQAHMAAQAEAP8AAAAAAEABDwAIAhAA dAABAAQAZQQAAAAAAAEPAAgCEAB1AAEABACEAwAAAAAAAQ8ACAIQAHYAAQAEAP8AAAAAAAABDwAI AhAAdwABAAQA/wAAAAAAAAEPAAgCEAB4AAEABAD/AAAAAAAAAQ8ACAIQAHkAAQAEAP8AAAAAAAAB DwAIAhAAegABAAQA/wAAAAAAAAEPAAgCEAB7AAEABAD/AAAAAAAAAQ8ACAIQAHwAAQAEAP8AAAAA AAABDwAIAhAAfQABAAQA/wAAAAAAAAEPAAgCEAB+AAEABAD/AAAAAAAAAQ8ACAIQAH8AAQAEAP8A AAAAAAABDwAIAhAAgAABAAQA/wAAAAAAAAEPAH4CCgBhAAEAMgAAAABA/QAKAGEAAgAdAEQAAAD9 AAoAYQADACIAQwAAAAECBgBiAAEAMwD9AAoAYgACAB0ARQAAAP0ACgBiAAMAHQAFAAAAfgIKAGMA AQAqAAAAAED9AAoAYwACAB0ASQAAAP0ACgBjAAMAHQBYAAAAfgIKAGQAAQAdAAAA8D/9AAoAZAAC AB0ARgAAAP0ACgBkAAMAHQBtAAAAfgIKAGUAAQAyAAAA8D/9AAoAZQACAB0ARwAAAAECBgBlAAMA HQABAgYAZgABADMA/QAKAGYAAgAdAEgAAAD9AAoAZgADAB0ABQAAAH4CCgBnAAEAHQAAAABA/QAK AGcAAgAdAG8AAAD9AAoAZwADAB0AbgAAAH4CCgBoAAEAHQAAAPA//QAKAGgAAgAdAEsAAAD9AAoA aAADAB0ATAAAAH4CCgBpAAEAHQAAAPA//QAKAGkAAgAdAE0AAAD9AAoAaQADAB0ATgAAAH4CCgBq AAEAHQAAAABA/QAKAGoAAgAdAE8AAAD9AAoAagADAB0AcAAAAH4CCgBrAAEAHQAAABBA/QAKAGsA AgAdAFQAAAABAgYAawADACIAfgIKAGwAAQAdAAAAEED9AAoAbAACAB0AUwAAAAECBgBsAAMAIgB+ AgoAbQABAB0AAAAQQP0ACgBtAAIAHQBSAAAAAQIGAG0AAwAiAH4CCgBuAAEAHQAAABBA/QAKAG4A AgAdAFEAAAABAgYAbgADACIAfgIKAG8AAQAeAAAAEED9AAoAbwACAB0AVQAAAP0ACgBvAAMAIgBW AAAAvgAMAHAAAQAbABsAGwADAP0ACgBxAAEAMABxAAAAvgAKAHEAAgAxADEAAwD9AAoAcgABABgA AQAAAP0ACgByAAIAGQACAAAA/QAKAHIAAwAZAAMAAAB+AgoAcwABAB0AAADwP/0ACgBzAAIAHQAF AAAA/QAKAHMAAwAiANMAAAB+AgoAdAABAB0AAADwP/0ACgB0AAIAHQBoAAAA/QAKAHQAAwAiAHIA AAB+AgoAdQABACoAAAAAQP0ACgB1AAIAHQBpAAAA/QAKAHUAAwAiAHMAAAC+AAwAdgABABsAGwAb AAMA/QAKAHcAAQA0ALsAAAC+AAoAdwACADcAOAADAP0ACgB4AAEANAB3AAAAvgAKAHgAAgA1ADYA AwD9AAoAeQABABgAAQAAAP0ACgB5AAIAGgACAAAA/QAKAHkAAwAZAAMAAAB+AgoAegABADIAAAAA QP0ACgB6AAIAHQB1AAAA/QAKAHoAAwAiAHQAAAABAgYAewABADMA/QAKAHsAAgAdAAUAAAD9AAoA ewADAB0ABQAAAAECBgB8AAEAHQD9AAoAfAACAB0AIQAAAP0ACgB8AAMAHQB2AAAAvgAMAH0AAQAb ABsALAADAP0ACgB+AAEANAC7AAAAvgAKAH4AAgA3ADgAAwD9AAoAfwABADQAeAAAAL4ACgB/AAIA NQA2AAMA/QAKAIAAAQAYAAEAAAD9AAoAgAACABoAAgAAAP0ACgCAAAMAGQADAAAA1wBEAAgHAABs AioAJgAqACoAJgAmACoAKgAqACoAJgAmACYAJgAqABAAHAAqACoAKgAqABAAHAAcACoAKgAmACYA EAAcABwACAIQAIEAAQAEAP8AAAAAAAABDwAIAhAAggABAAQA/wAAAAAAAAEPAAgCEACDAAEABAD/ AAAAAAAAAQ8ACAIQAIQAAQAEAMIBAAAAAAABDwAIAhAAhQABAAQA/wAAAAAAQAEPAAgCEACGAAEA BAD/AAAAAAAAAQ8ACAIQAIcAAQAEAP8AAAAAAAABDwAIAhAAiAABAAQA/wAAAAAAAAEPAAgCEACJ AAEABAD/AAAAAAAAAQ8ACAIQAIoAAQAEAP8AAAAAAAABDwAIAhAAiwABAAQA/wAAAAAAAAEPAAgC EACMAAEABAD/AAAAAAAAAQ8ACAIQAI0AAQAEAP8AAAAAAAABDwAIAhAAjgABAAQA/wAAAAAAAAEP AAgCEACPAAEABAD/AAAAAAAAAQ8ACAIQAJAAAQAEAP8AAAAAAAABDwAIAhAAkQABAAQA/wAAAAAA AAEPAAgCEACSAAEABAD/AAAAAAAAAQ8ACAIQAJMAAQAEAP8AAAAAAAABDwAIAhAAlAABAAQA/wAA AAAAAAEPAAgCEACVAAEABAD/AAAAAAAAAQ8ACAIQAJYAAQAEAP8AAAAAAAABDwAIAhAAlwABAAQA /wAAAAAAAAEPAAgCEACYAAEABAD/AAAAAAAAAQ8ACAIQAJkAAQAEAP8AAAAAAAABDwAIAhAAmgAB AAQA/wAAAAAAAAEPAAgCEACbAAEABAD/AAAAAAAAAQ8ACAIQAJwAAQAEAP8AAAAAAAABDwAIAhAA nQABAAQA/wAAAAAAAAEPAAgCEACeAAEABAD/AAAAAAAAAQ8ACAIQAJ8AAQAEAP8AAAAAAAABDwAI AhAAoAABAAQA/wAAAAAAAAEPAH4CCgCBAAEAHQAAAPA//QAKAIEAAgAdAHoAAAD9AAoAgQADACIA eQAAAH4CCgCCAAEAMQAAAPA//QAKAIIAAgAdAH0AAAD9AAoAggADACIAfgAAAAECBgCDAAEAMQD9 AAoAgwACAB0ABQAAAP0ACgCDAAMAHQB8AAAAfgIKAIQAAQAdAAAAAED9AAoAhAACAB0AgAAAAP0A CgCEAAMAIgB7AAAAfgIKAIUAAQAdAAAA8D/9AAoAhQACAB0AhQAAAP0ACgCFAAMAIgB/AAAAfgIK AIYAAQAdAAAA8D/9AAoAhgACACEAgQAAAP0ACgCGAAMAIQCBAAAAfgIKAIcAAQAdAAAAAED9AAoA hwACAB0AggAAAP0ACgCHAAMAIgCDAAAAfgIKAIgAAQAdAAAAEED9AAoAiAACAB0AiwAAAP0ACgCI AAMAIgCKAAAAfgIKAIkAAQAdAAAA8D/9AAoAiQACAB0AhgAAAP0ACgCJAAMAIgCEAAAAfgIKAIoA AQAdAAAA8D/9AAoAigACACEAhwAAAP0ACgCKAAMAIQCHAAAAfgIKAIsAAQAdAAAAAED9AAoAiwAC AB0AiAAAAP0ACgCLAAMAIgCJAAAAfgIKAIwAAQAdAAAAEED9AAoAjAACAB0AjQAAAP0ACgCMAAMA IgCMAAAAfgIKAI0AAQAdAAAA8D/9AAoAjQACAB0AjwAAAP0ACgCNAAMAIgCOAAAAfgIKAI4AAQAd AAAA8D/9AAoAjgACACEAkAAAAP0ACgCOAAMAIQCQAAAAfgIKAI8AAQAdAAAAAED9AAoAjwACAB0A kQAAAP0ACgCPAAMAIgCSAAAAfgIKAJAAAQAdAAAAEED9AAoAkAACAB0AkwAAAP0ACgCQAAMAIgCT AAAAfgIKAJEAAQAdAAAA8D/9AAoAkQACAB0AlAAAAP0ACgCRAAMAIgCXAAAAfgIKAJIAAQAdAAAA 8D/9AAoAkgACACEAlQAAAP0ACgCSAAMAIQCVAAAAfgIKAJMAAQAdAAAAAED9AAoAkwACAB0AlgAA AP0ACgCTAAMAIgCYAAAAfgIKAJQAAQAdAAAAEED9AAoAlAACAB0AmQAAAP0ACgCUAAMAIgCZAAAA vgAMAJUAAQAbABsALAADAP0ACgCWAAEANAC7AAAAvgAKAJYAAgA3ADgAAwD9AAoAlwABADQAmgAA AL4ACgCXAAIANQA2AAMA/QAKAJgAAQAYAAEAAAD9AAoAmAACABoAAgAAAP0ACgCYAAMAGQADAAAA fgIKAJkAAQAdAAAA8D/9AAoAmQACAB0AegAAAP0ACgCZAAMAIgCbAAAAfgIKAJoAAQAxAAAA8D/9 AAoAmgACAB0AfQAAAP0ACgCaAAMAIgB+AAAAAQIGAJsAAQAxAP0ACgCbAAIAHQAFAAAA/QAKAJsA AwAdAHwAAAB+AgoAnAABAB0AAAAAQAECBgCcAAIAHQD9AAoAnAADACIAnAAAAH4CCgCdAAEAHQAA APA//QAKAJ0AAgAdAKEAAAD9AAoAnQADACIAnQAAAH4CCgCeAAEAHQAAAPA//QAKAJ4AAgAhAJ4A AAD9AAoAngADACEAngAAAH4CCgCfAAEAHQAAAABA/QAKAJ8AAgAdAKAAAAD9AAoAnwADACIAnwAA AH4CCgCgAAEAHQAAABBA/QAKAKAAAgAdAKMAAAD9AAoAoAADACIAogAAANcARAB+BwAAbAIqACoA JgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAEAAcABwAKgAqACoAJgAmACoAKgAq AAgCEAChAAEABAD/AAAAAAAAAQ8ACAIQAKIAAQAEAP8AAAAAAAABDwAIAhAAowABAAQA/wAAAAAA AAEPAAgCEACkAAEABAD/AAAAAAAAAQ8ACAIQAKUAAQAEAP8AAAAAAAABDwAIAhAApgABAAQA/wAA AAAAAAEPAAgCEACnAAEABAD/AAAAAAAAAQ8ACAIQAKgAAQAEAP8AAAAAAAABDwAIAhAAqQABAAQA /wAAAAAAAAEPAAgCEACqAAEABAD/AAAAAAAAAQ8ACAIQAKsAAQAEAP8AAAAAAAABDwAIAhAArAAB AAQA/wAAAAAAAAEPAAgCEACtAAEABAD/AAAAAAAAAQ8ACAIQAK4AAQAEAP8AAAAAAAABDwAIAhAA rwABAAQA/wAAAAAAAAEPAAgCEACwAAEABAD/AAAAAAAAAQ8ACAIQALEAAQAEAP8AAAAAAAABDwAI AhAAsgABAAQA/wAAAAAAAAEPAAgCEACzAAEABAD/AAAAAAAAAQ8ACAIQALQAAQAEAP8AAAAAAAAB DwAIAhAAtQABAAQA/wAAAAAAAAEPAAgCEAC2AAEABAD/AAAAAAAAAQ8ACAIQALcAAQAEAP8AAAAA AAABDwAIAhAAuAABAAQA/wAAAAAAAAEPAAgCEAC5AAEABAD/AAAAAAAAAQ8ACAIQALoAAQAEAP8A AAAAAAABDwAIAhAAuwABAAQA/wAAAAAAAAEPAAgCEAC8AAEABAD/AAAAAAAAAQ8ACAIQAL0AAQAE AP8AAAAAAAABDwAIAhAAvgABAAQA/wAAAAAAAAEPAAgCEAC/AAEABAD/AAAAAAAAAQ8ACAIQAMAA AQAEAP8AAAAAAAABDwB+AgoAoQABAB0AAADwP/0ACgChAAIAHQCkAAAA/QAKAKEAAwAiAKgAAAB+ AgoAogABAB0AAADwP/0ACgCiAAIAIQClAAAA/QAKAKIAAwAhAKUAAAB+AgoAowABAB0AAAAAQP0A CgCjAAIAHQCmAAAA/QAKAKMAAwAiAKcAAAB+AgoApAABAB0AAAAQQP0ACgCkAAIAHQCpAAAA/QAK AKQAAwAiAKoAAAB+AgoApQABAB0AAADwP/0ACgClAAIAHQCsAAAA/QAKAKUAAwAiAKsAAAB+AgoA pgABAB0AAADwP/0ACgCmAAIAIQCtAAAA/QAKAKYAAwAhAK0AAAB+AgoApwABAB0AAAAAQP0ACgCn AAIAHQCuAAAA/QAKAKcAAwAiAK8AAAB+AgoAqAABAB0AAAAQQP0ACgCoAAIAHQCxAAAA/QAKAKgA AwAiALAAAAB+AgoAqQABAB0AAADwP/0ACgCpAAIAHQCyAAAA/QAKAKkAAwAiALYAAAB+AgoAqgAB AB0AAADwP/0ACgCqAAIAIQCzAAAA/QAKAKoAAwAhALMAAAB+AgoAqwABAB0AAAAAQP0ACgCrAAIA HQC0AAAA/QAKAKsAAwAiALUAAAB+AgoArAABAB0AAAAQQP0ACgCsAAIAHQC3AAAA/QAKAKwAAwAi ALgAAAC+AAoArQABAB0AHQACAP0ACgCtAAMAIgC5AAAAvgAMAK4AAQAbABsALAADAP0ACgCvAAEA NAC7AAAAvgAKAK8AAgA3ADgAAwD9AAoAsAABADQAugAAAL4ACgCwAAIANQA2AAMA/QAKALEAAQAY AAEAAAD9AAoAsQACABoAAgAAAP0ACgCxAAMAGQADAAAAfgIKALIAAQAdAAAA8D/9AAoAsgACAB0A egAAAP0ACgCyAAMAIgCbAAAAfgIKALMAAQAxAAAA8D/9AAoAswACAB0AfQAAAP0ACgCzAAMAIgB+ AAAAAQIGALQAAQAxAP0ACgC0AAIAHQAFAAAA/QAKALQAAwAdAHwAAAC+AAwAtQABABsAGwAsAAMA /QAKALYAAQA0ALsAAAC+AAoAtgACADcAOAADAP0ACgC3AAEANAC8AAAAvgAKALcAAgA1ADYAAwD9 AAoAuAABABgAAQAAAP0ACgC4AAIAGgACAAAA/QAKALgAAwAZAAMAAAB+AgoAuQABAB0AAADwP/0A CgC5AAIAHQB6AAAA/QAKALkAAwAiAL0AAAB+AgoAugABADEAAADwP/0ACgC6AAIAHQB9AAAA/QAK ALoAAwAiAH4AAAABAgYAuwABADEA/QAKALsAAgAdAL8AAAD9AAoAuwADAB0AwAAAAH4CCgC8AAEA HQAAAABA/QAKALwAAgAdACEAAAD9AAoAvAADACIAvgAAAL4ADAC9AAEAGwAbACwAAwD9AAoAvgAB ADQAuwAAAL4ACgC+AAIANwA4AAMA/QAKAL8AAQA0ALwAAAC+AAoAvwACADUANgADAP0ACgDAAAEA NADBAAAAvgAKAMAAAgA1ADYAAwDXAEQA+gYAAGwCKgAqACoAKgAqACoAKgAqACoAKgAqACoAHAAQ ABwAHAAqACoAKgAmABAAHAAcACoAKgAqACYAKgAQABwAHAAIAhAAwQABAAQA/wAAAAAAAAEPAAgC EADCAAEABAD/AAAAAAAAAQ8ACAIQAMMAAQAEAP8AAAAAAAABDwAIAhAAxAABAAQA/wAAAAAAAAEP AAgCEADFAAEABAD/AAAAAAAAAQ8ACAIQAMYAAQAEAMIBAAAAAAABDwAIAhAAxwABAAQA/wAAAAAA AAEPAAgCEADIAAEABAD/AAAAAAAAAQ8ACAIQAMkAAQAEAP8AAAAAAAABDwAIAhAAygABAAQA/wAA AAAAAAEPAAgCEADLAAEABAD/AAAAAAAAAQ8ACAIQAMwAAQAEAP8AAAAAAAABDwAIAhAAzQABAAQA /wAAAAAAAAEPAAgCEADOAAEABAD/AAAAAAAAAQ8ACAIQAM8AAQAEAP8AAAAAAAABDwAIAhAA0AAB AAQA/wAAAAAAAAEPAAgCEADRAAEABABGBQAAAAAAAQ8ACAIQANIAAQAEAP8AAAAAAAABDwAIAhAA 0wABAAQA/wAAAAAAAAEPAAgCEADUAAEABAD/AAAAAAAAAQ8ACAIQANUAAQAEAP8AAAAAAEABDwAI AhAA1gABAAQA/wAAAAAAQAEPAAgCEADXAAEABAD/AAAAAAAAAQ8ACAIQANgAAQAEAP8AAAAAAAAB DwAIAhAA2QABAAQA/wAAAAAAAAEPAAgCEADaAAEABAD/AAAAAABAAQ8ACAIQANsAAQAEAP8AAAAA AEABDwAIAhAA3AABAAQA/wAAAAAAAAEPAAgCEADdAAEABACjAgAAAAAAAQ8ACAIQAN4AAQAEAKMC AAAAAAABDwAIAhAA3wABAAQA/wAAAAAAAAEPAAgCEADgAAEABACjAgAAAAAAAQ8A/QAKAMEAAQAY AAEAAAD9AAoAwQACABoAAgAAAP0ACgDBAAMAGQADAAAAfgIKAMIAAQAdAAAA8D/9AAoAwgACAB0A egAAAP0ACgDCAAMAIgC9AAAAfgIKAMMAAQAxAAAA8D/9AAoAwwACAB0AfQAAAP0ACgDDAAMAIgB+ AAAAAQIGAMQAAQAxAP0ACgDEAAIAHQC/AAAA/QAKAMQAAwAdAMAAAAB+AgoAxQABAB0AAAAAQP0A CgDFAAIAHQAhAAAA/QAKAMUAAwAiAL4AAAB+AgoAxgABAB0AAADwP/0ACgDGAAIAHQCGAAAA/QAK AMYAAwAiAMIAAAB+AgoAxwABAB0AAADwP/0ACgDHAAIAHQDEAAAA/QAKAMcAAwAiAMMAAAB+AgoA yAABAB0AAAAAQP0ACgDIAAIAHQCIAAAA/QAKAMgAAwAiAMUAAAB+AgoAyQABAB0AAAAgQP0ACgDJ AAIAHQCNAAAA/QAKAMkAAwAiAMYAAAC+AAwAygABABsAGwAsAAMA/QAKAMsAAQAwABcAAAC+AAoA ywACADEAMQADAP0ACgDMAAEAGAABAAAA/QAKAMwAAgAZAAIAAAD9AAoAzAADABkAAwAAAH4CCgDN AAEAHQAAABBA/QAKAM0AAgAdABgAAAD9AAoAzQADAB0AGAAAAL4ADADOAAEALQAtAC0AAwD9AAoA zwABADAA0AAAAL4ACgDPAAIAMQAxAAMA/QAKANAAAQAYAAEAAAD9AAoA0AACABkAAgAAAP0ACgDQ AAMAGQADAAAAfgIKANEAAQAdAAAAEED9AAoA0QACAB0A0QAAAP0ACgDRAAMAIgDSAAAAvgAMANIA AQAtAC0ALQADAP0ACgDTAAEAMAAvAAAAvgAKANMAAgAxADEAAwD9AAoA1AABABgAAQAAAP0ACgDU AAIAGQACAAAA/QAKANQAAwAZAAMAAAB+AgoA1QABAB0AAAAAQP0ACgDVAAIAHAAFAAAA/QAKANUA AwAiADEAAAB+AgoA1gABAB0AAAAAQP0ACgDWAAIAHAAwAAAA/QAKANYAAwAiADIAAAC+AAwA1wAB AC0ALQAtAAMA/QAKANgAAQAwAMcAAAC+AAoA2AACADEAMQADAP0ACgDZAAEAGAABAAAA/QAKANkA AgAZAAIAAAD9AAoA2QADABkAAwAAAH4CCgDaAAEAHQAAAABA/QAKANoAAgAdAAUAAAD9AAoA2gAD ACIAMQAAAH4CCgDbAAEAHQAAAABA/QAKANsAAgAdADAAAAD9AAoA2wADACIAMgAAAH4CCgDcAAEA MQAAAABA/QAKANwAAgAdAAUAAAD9AAoA3AADACIAMwAAAAECBgDdAAEAMQD9AAoA3QACAB0ANAAA AP0ACgDdAAMAIgA1AAAAfgIKAN4AAQAdAAAAAED9AAoA3gACAB0ANgAAAP0ACgDeAAMAIgA3AAAA fgIKAN8AAQAxAAAAAED9AAoA3wACAB0ABQAAAP0ACgDfAAMAIgAzAAAAAQIGAOAAAQAxAP0ACgDg AAIAHQA4AAAA/QAKAOAAAwAiADkAAADXAEQAFAcAAGwCKgAqACoAJgAqACoAKgAqACoAEAAcACoA KgAQABwAKgAqABAAHAAqACoAKgAQABwAKgAqACoAKgAmACoAKgAIAhAA4QABAAQAowIAAAAAAAEP AAgCEADiAAEABAD/AAAAAAAAAQ8ACAIQAOMAAQAEAP8AAAAAAAABDwAIAhAA5AABAAQA/wAAAAAA AAEPAAgCEADlAAEABAD/AAAAAABAAQ8ACAIQAOYAAQAEAP8AAAAAAAABDwAIAhAA5wABAAQA/wAA AAAAAAEPAAgCEADoAAEABAAnBgAAAAAAAQ8ACAIQAOkAAQAEAKMCAAAAAAABDwAIAhAA6gABAAQA /wAAAAAAAAEPAAgCEADrAAEABACjAgAAAAAAAQ8ACAIQAOwAAQAEAP8AAAAAAAABDwAIAhAA7QAB AAQA/wAAAAAAAAEPAAgCEADuAAEABAD/AAAAAAAAAQ8ACAIQAO8AAQAEAP8AAAAAAAABDwAIAhAA 8AABAAQAowIAAAAAAAEPAAgCEADxAAEABAD/AAAAAAAAAQ8ACAIQAPIAAQAEAMIBAAAAAAABDwAI AhAA8wABAAQA/gEAAAAAQAEPAAgCEAD0AAEABAD/AAAAAAAAAQ8ACAIQAPUAAQAEAP8AAAAAAAAB DwAIAhAA9gABAAQA/wAAAAAAgAEVAAgCEAD3AAEABAD/AAAAAACAARUACAIQAPgAAQAEAP8AAAAA AIABFQAIAhAA+QABAAQA/wAAAAAAgAEVAAgCEAD6AAEABAD/AAAAAACAARUACAIQAPsAAQAEAP8A AAAAAIABFQAIAhAA/AABAAQA/wAAAAAAgAEVAAgCEAD9AAEABACjAgAAAACAARUACAIQAP4AAQAE AP8AAAAAAIABFQAIAhAA/wABAAQA/wAAAAAAgAEVAAgCEAAAAQEABAD/AAAAAACAARUAfgIKAOEA AQAdAAAAAED9AAoA4QACAB0AOwAAAP0ACgDhAAMAIgA6AAAAvgAMAOIAAQAtAC0ALQADAP0ACgDj AAEAMADnAAAAvgAKAOMAAgAxADEAAwD9AAoA5AABABgAAQAAAP0ACgDkAAIAGQACAAAA/QAKAOQA AwAZAAMAAAB+AgoA5QABAB0AAAAAQP0ACgDlAAIAHQAFAAAA/QAKAOUAAwAiADEAAAB+AgoA5gAB AB0AAAAAQP0ACgDmAAIAHQAwAAAA/QAKAOYAAwAiADIAAAB+AgoA5wABADEAAAAgQP0ACgDnAAIA HQAFAAAA/QAKAOcAAwAiAD0AAAABAgYA6AABADEA/QAKAOgAAgAdADwAAAD9AAoA6AADACsA5gAA AAECBgDpAAEAMQD9AAoA6QACAB0APgAAAP0ACgDpAAMAIgBBAAAAfgIKAOoAAQAxAAAAEED9AAoA 6gACAB0ABQAAAP0ACgDqAAMAIgA/AAAAAQIGAOsAAQAxAP0ACgDrAAIAHQBAAAAA/QAKAOsAAwAi AEIAAAC+AAwA7AABAC0ALQAtAAMA/QAKAO0AAQAwANQAAAC+AAoA7QACADEAMQADAP0ACgDuAAEA MADXAAAAvgAKAO4AAgAxADEAAwD9AAoA7wABABgAAQAAAP0ACgDvAAIAGQACAAAA/QAKAO8AAwAZ AAMAAAB+AgoA8AABADIAAADwP/0ACgDwAAIAHADVAAAA/QAKAPAAAwAkANoAAAABAgYA8QABADMA /QAKAPEAAgAcANYAAAD9AAoA8QADABwAzAAAAH4CCgDyAAEAKgAAAPA//QAKAPIAAgAcACEAAAD9 AAoA8gADACQA3AAAAH4CCgDzAAEAHQAAABBA/QAKAPMAAgAcANgAAAD9AAoA8wADACQA3QAAAH4C CgD0AAEAHQAAAPA//QAKAPQAAgAdANkAAAD9AAoA9AADACIA7AAAAH4CCgD1AAEAHQAAAPA//QAK APUAAgAdAO0AAAD9AAoA9QADACIA3gAAAL4ADAD2AAEALgAuAC8AAwD9AAoA9wABADAA1AAAAL4A CgD3AAIAMQAxAAMA/QAKAPgAAQAwAN8AAAC+AAoA+AACADEAMQADAP0ACgD5AAEAGAABAAAA/QAK APkAAgAZAAIAAAD9AAoA+QADABkAAwAAAH4CCgD6AAEAMgAAAPA//QAKAPoAAgAcANUAAAD9AAoA +gADACQA2wAAAAECBgD7AAEAMwD9AAoA+wACABwA1gAAAP0ACgD7AAMAHADWAAAAfgIKAPwAAQAq AAAA8D/9AAoA/AACABwAIQAAAP0ACgD8AAMAHADiAAAAfgIKAP0AAQAdAAAAAED9AAoA/QACAB0A 4AAAAP0ACgD9AAMAIgDhAAAAvgAMAP4AAQAuAC4ALwADAP0ACgD/AAEAMADUAAAAvgAKAP8AAgAx ADEAAwD9AAoAAAEBADAA4wAAAL4ACgAAAQIAMQAxAAMA1wBEAOIGAABsAioAEAAcACoAKgAqACoA JgAmACoAJgAQABwAHAAqACoAJgAqACoAKgAqABAAHAAcACoAKgAmACoAKgAQABwACAIQAAEBAQAE AP8AAAAAAIABFQAIAhAAAgEBAAQA/wAAAAAAgAEVAAgCEAADAQEABAD/AAAAAACAARUACAIQAAQB AQAEAP8AAAAAAIABFQAIAhAABQEBAAQAowIAAAAAgAEVAAgCEAAGAQEABAD/AAAAAAAAAQ8ACAIQ AAcBAQAEAP8AAAAAAAABDwAIAhAACAEBAAQA/wAAAAAAAAEPAAgCEAAJAQEABAD/AAAAAAAAAQ8A CAIQAAoBAQAEAMIBAAAAAAABDwAIAhAACwEBAAQAwgEAAAAAAAEPAAgCEAAMAQEABAD/AAAAAAAA AQ8ACAIQAA0BAQAEAP8AAAAAAAABDwD9AAoAAQEBABgAAQAAAP0ACgABAQIAGQACAAAA/QAKAAEB AwAZAAMAAAB+AgoAAgEBADIAAADwP/0ACgACAQIAHADVAAAA/QAKAAIBAwAkANsAAAABAgYAAwEB ADMA/QAKAAMBAgAcANYAAAD9AAoAAwEDABwA1gAAAH4CCgAEAQEAKgAAAPA//QAKAAQBAgAcACEA AAD9AAoABAEDABwA5AAAAH4CCgAFAQEAHQAAAABA/QAKAAUBAgAdAOAAAAD9AAoABQEDACIA5QAA AL4ADAAGAQEALQAtAC0AAwD9AAoABwEBADAAyAAAAL4ACgAHAQIAMQAxAAMA/QAKAAgBAQAYAAEA AAD9AAoACAECABkAAgAAAP0ACgAIAQMAGQADAAAAfgIKAAkBAQAdAAAA8D/9AAoACQECAB0AyQAA AP0ACgAJAQMAIgDMAAAAfgIKAAoBAQAdAAAA8D/9AAoACgECAB0AIQAAAP0ACgAKAQMAIgDNAAAA fgIKAAsBAQAhAAAAEED9AAoACwECACEAygAAAP0ACgALAQMAJwDOAAAAfgIKAAwBAQAhAAAA8D/9 AAoADAECACEAywAAAH4CCgAMAQMAIQAAAEBAfgIKAA0BAQAhAAAA8D/9AAoADQECACEABAAAAP0A CgANAQMAIQDPAAAA1wAeAPoCAADwACoAKgAmACoAKgAQABwAKgAqACoAKgAqAD4CEgC2BkUAAABA AAAAMgBkAAAAAAAdAA8AA0sAAwAAAAEASwBLAAMD5QDKATkAvgC+AAEAAwDAAMAAAQADAAEAAQAB AAMA0wDTAAEAAwAmACcAAQABACoAKwABAAEANgA2AAEAAwA4ADkAAQABADwAPQABAAEATQBNAAEA AwCzALQAAQABALYAtgABAAMAtwC3AAEAAwC6ALsAAQABAFkAWQABAAMAUwBTAAEAAwAkACQAAQAD ALAAsAABAAMAeAB4AAEAAwAfAB8AAQADABgAGAABAAMA5wDpAAEAAQAUABQAAQADAH4AfgABAAMA fwB/AAEAAwCCAIMAAQABAJcAlwABAAMAmgCbAAEAAQCvAK8AAQADAA8ADwABAAMACAAIAAEAAwDq AOsAAQABAF8AXwABAAMAYQBiAAEAAQBlAGYAAQABAHEAcQABAAMAegB7AAEAAQB3AHcAAQADAJYA lgABAAMAwwDEAAEAAQC/AL8AAQADAAcBBwEBAAMAAgEDAQEAAQDLAMsAAQADAN8A4AABAAEA4wDj AAEAAwDYANgAAQADANwA3QABAAEAzwDPAAEAAwDuAO4AAQADAO0A7QABAAMA8ADxAAEAAQD3APcA AQADAPgA+AABAAMA+gD7AAEAAQD/AP8AAQADAAABAAEBAAMA7wAGAAAANwAAAAoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAMAAAAAIAAAAAQAAAEgAAAAEAAAA UAAAAAgAAABkAAAAEgAAAHwAAAALAAAAlAAAAAwAAACgAAAADQAAAKwAAAATAAAAuAAAAAIAAADk BAAAHgAAAAkAAABUb20gTG93ZQAAIAAeAAAADQAAAEJpbGwgU2FuZm9yZAAAeAAeAAAAEAAAAE1p Y3Jvc29mdCBFeGNlbABAAAAAAHsX4DjAvwFAAAAAAJsgZ/BbvAFAAAAAgMfYbjrAvwEDAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAA AAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADUAAAACQAAAAEAAABQAAAADwAAAFgAAAAXAAAA dAAAAAsAAAB8AAAAEAAAAIQAAAATAAAAjAAAABYAAACUAAAADQAAAJwAAAAMAAAArwAAAAIAAADk BAAAHgAAABQAAABIYXJyaXMgYW5kIEplZmZyaWVzAAMAAACgCgkACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAACwAAAAAAAAAeEAAAAQAAAAcAAABTaGVldDIADBAAAAIAAAAeAAAACwAAAFdvcmtzaGVl dHMAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAk AAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIA AAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAA AEEAAABCAAAA/v///0QAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAAD+////TAAAAE0AAABOAAAA TwAAAFAAAABRAAAAUgAAAP7////9/////v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AgAAACAIAgAA AAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAFcAbwByAGsAYgBvAG8A awAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADyEAAAAAAAA BQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACgAAgEBAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABDAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEsAAAAAEAAAAAAAAA== ------_=_NextPart_000_01BFC03D.E00475F0-- From owner-mpls@UU.NET Wed May 17 16:31: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 QAA10992 for ; Wed, 17 May 2000 16:31: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 QQippq22871; Wed, 17 May 2000 20:31:05 GMT Received: by mail-control.mail.uu.net id QQippq14042 for mpls-outgoing; Wed, 17 May 2000 20:30: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 QQippp14001 for ; Wed, 17 May 2000 20:29: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 QQippp13555 for ; Wed, 17 May 2000 16:29:35 -0400 (EDT) Received: from petal.blackrose.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thorn.blackrose.org [204.212.44.2]) id QQippp23027 for ; Wed, 17 May 2000 20:29:35 GMT Received: (from dorian@localhost) by petal.blackrose.org (8.9.3/8.9.3) id QAA05652; Wed, 17 May 2000 16:29:03 -0400 Date: Wed, 17 May 2000 16:29:03 -0400 From: Dorian Kim To: Yangguang Xu Cc: Chris.Flores@broadwing.com, mpls@UU.NET Subject: Re: FW: MPLS and IS-IS Message-ID: <20000517162903.L747@blackrose.org> References: <83D3AE577F81D31196B10008C7DFB055AFABF7@metexch4.ixc-comm.com> <3922F006.FD1A7A36@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3922F006.FD1A7A36@lucent.com>; from xuyg@lucent.com on Wed, May 17, 2000 at 03:16:22PM -0400 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, May 17, 2000 at 03:16:22PM -0400, Yangguang Xu wrote: > > > > > Most large ISPs in the US use ISIS: > > > > UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. > > > > It also seems like more and more european ISPs are starting to use ISIS: > > EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. > > Do they "only" use IS-IS for IGP, or IS-IS and OSPF together? Most only use ISIS for IGP, but some use both. In cases that I've seen where both is used, ISIS is used as backbone IGP, while OSPF is used to refine next hop info from aggregation devices, most often within a single POP. -dorian From owner-mpls@UU.NET Wed May 17 16:31: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 QAA11005 for ; Wed, 17 May 2000 16:31: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 QQippq24903; Wed, 17 May 2000 20:31:37 GMT Received: by mail-control.mail.uu.net id QQippq14242 for mpls-outgoing; Wed, 17 May 2000 20:31: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 QQippq14089 for ; Wed, 17 May 2000 20:31: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 QQippq13811 for ; Wed, 17 May 2000 16:30:44 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQippq22553 for ; Wed, 17 May 2000 20:30:43 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA01274; Wed, 17 May 2000 13:30:43 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id NAA06761; Wed, 17 May 2000 13:30:42 -0700 (PDT) Date: Wed, 17 May 2000 13:30:42 -0700 (PDT) Message-Id: <200005172030.NAA06761@cirrus.juniper.net> From: Dave Katz To: jnc@ginger.lcs.mit.edu CC: mpls@UU.NET, jnc@ginger.lcs.mit.edu In-reply-to: <200005172001.QAA13594@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: MPLS and IS-IS Sender: owner-mpls@UU.NET Precedence: bulk It's because IS-IS doesn't import data that it has (unless there's been some recent upgrade I'm not familiar with) the restriction that the level 2 routers have to form a directly connected graph (i.e. no virtual links across level 1 areas, as supported by OSPF). There has been an upgrade... Virtual links aren't really something to get too excited about. The urge to use them usually means that you should think about replumbing your topology a bit instead, and implementations tend to be buggy in this area because most people are smart enough to not use them (see previous message about bugs and code use). They're fundamentally brittle because the routing information is tunneled but the data is not, so it doesn't take much to mess them up. From owner-mpls@UU.NET Wed May 17 16:33:33 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 QAA11036 for ; Wed, 17 May 2000 16:33: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 QQippq26618; Wed, 17 May 2000 20:33:25 GMT Received: by mail-control.mail.uu.net id QQippq14326 for mpls-outgoing; Wed, 17 May 2000 20:32:46 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQippq14317 for ; Wed, 17 May 2000 20:32:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippq06717 for ; Wed, 17 May 2000 16:32:16 -0400 (EDT) Received: from petal.blackrose.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thorn.blackrose.org [204.212.44.2]) id QQippq25635 for ; Wed, 17 May 2000 20:32:16 GMT Received: (from dorian@localhost) by petal.blackrose.org (8.9.3/8.9.3) id QAA05689; Wed, 17 May 2000 16:31:39 -0400 Date: Wed, 17 May 2000 16:31:39 -0400 From: Dorian Kim To: Andrew Partan Cc: "J. Noel Chiappa" , mpls@UU.NET Subject: Re: MPLS and IS-IS Message-ID: <20000517163139.M747@blackrose.org> References: <200005171926.PAA13431@ginger.lcs.mit.edu> <200005172009.QAA09114@tower.partan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200005172009.QAA09114@tower.partan.com>; from asp@partan.com on Wed, May 17, 2000 at 04:09:40PM -0400 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, May 17, 2000 at 04:09:40PM -0400, Partan, Andrew wrote: > > My dim recollection is that for a variety of reasons, the major vendor had a > > better IS-IS implementation, > > That plus a desire to route both IP and CLNS. Yup, back then, many networks ran CLNP native, and had requirements to support both IP and CLNS, many with eye on moving to reduce "legacy" IP support. -dorian From owner-mpls@UU.NET Wed May 17 16:40:33 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 QAA11093 for ; Wed, 17 May 2000 16:40: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 QQippq01847; Wed, 17 May 2000 20:40:26 GMT Received: by mail-control.mail.uu.net id QQippq14610 for mpls-outgoing; Wed, 17 May 2000 20:39: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 QQippq14605 for ; Wed, 17 May 2000 20:39: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 QQippq14804 for ; Wed, 17 May 2000 16:39:18 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQippq29198 for ; Wed, 17 May 2000 20:39:17 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA01965; Wed, 17 May 2000 13:39:11 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id NAA06796; Wed, 17 May 2000 13:39:11 -0700 (PDT) Date: Wed, 17 May 2000 13:39:11 -0700 (PDT) Message-Id: <200005172039.NAA06796@cirrus.juniper.net> From: Dave Katz To: jnc@ginger.lcs.mit.edu CC: mpls@UU.NET, jnc@ginger.lcs.mit.edu In-reply-to: <200005172008.QAA13630@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: MPLS and IS-IS Sender: owner-mpls@UU.NET Precedence: bulk Urk, now I've got stage fright. ;-) I'll have a bunch of Powerpoint slides, most likely. I'm sure that we can come up with some way of making them available. For what it's worth, the slant on my talk is going to be mostly from an operational perspective ("Which protocol should I run?") so it will be technical, but perhaps a little watered down relative to what a scholarly treatise might contain. --Dave Date: Wed, 17 May 2000 16:08:56 -0400 From: "J. Noel Chiappa" Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Danny McPherson >> I'd be interested in hearing someone compare the technical aspects of >> the *protocols* > Dave is actually discussing this at the upcoming NANOG. Those not going to NANOG might be interested in seeing this online (and in fact such an analysis would be a good thing to have as an online resource). I know some NANOG material makes it online, but are there plans for Dave's notes to be available? Noel PS: Somwhere, covered by many layers of dust, I have at least two such documents, one by Radia and one by me, dating from around the period of the FSU IETF (whenever that was - probably '84 or so). From owner-mpls@UU.NET Wed May 17 16:47: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 QAA11147 for ; Wed, 17 May 2000 16:47: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 QQippr07200; Wed, 17 May 2000 20:47:18 GMT Received: by mail-control.mail.uu.net id QQippr15173 for mpls-outgoing; Wed, 17 May 2000 20:46:45 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippr15168 for ; Wed, 17 May 2000 20:46:43 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippr08462 for ; Wed, 17 May 2000 16:46:18 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQippr06453 for ; Wed, 17 May 2000 20:46:17 GMT Received: from ennovatenetworks.com (zeppo.ennovatenetworks.com [208.227.99.180]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id QAA21421; Wed, 17 May 2000 16:46:16 -0400 (EDT) (envelope-from pchen@ennovatenetworks.com) Message-ID: <3923081C.A7BB94A1@ennovatenetworks.com> Date: Wed, 17 May 2000 16:59:08 -0400 From: Philip Chen X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "J. Noel Chiappa" CC: mpls@UU.NET Subject: Re: MPLS and IS-IS References: <200005172019.QAA13713@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "J. Noel Chiappa" wrote: > > From: Andrew Partan > > > One main difference is security - its difficult to send a forged ISIS > > packet across the Internet to attack someone. > > All LS protocols (i.e. including both IS-IS and OSPF) are inherently much > harder to mess with than Destinvation Vector protocols, for the simple reason > that they advertise links, not routes, and before a link can be declared up, > you have to hear from both ends of it. > > Although I suppose the way external routes are imported doesn't follow this > rule... Still, it's a lot trickier to mess an LS protocol up - you have to > get into a topology map database exchange protocol, not just send someone a > bogus routing table entry directly. > > Also, I know that OSPF had authentication, and it was extendable (i.e. you > could add new methods); my knowledge in this area is out-of-date, and I'm not > sure which methods have been added since it was first defined. I beleive IS-IS also have an extendable authentication mechanism. This also is not unique to link state protocols. RIP has authentication too. > > > Noel > > PS: My memory is clearly failing. The FSU IETF was in '90, not '85 - ten > years ago, 15 years, whatever, it was still a long time ago! :-) From owner-mpls@UU.NET Wed May 17 17:13: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 RAA11334 for ; Wed, 17 May 2000 17:13: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 QQipps24225; Wed, 17 May 2000 21:12:59 GMT Received: by mail-control.mail.uu.net id QQipps25543 for mpls-outgoing; Wed, 17 May 2000 21:12: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 QQipps25538 for ; Wed, 17 May 2000 21:12:36 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 QQipps07829 for ; Wed, 17 May 2000 17:12:33 -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 QQipps25987 for ; Wed, 17 May 2000 21:12:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA18769 for mpls@uu.net; Wed, 17 May 2000 17:12:32 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipps25520 for ; Wed, 17 May 2000 21:11:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipps11498 for ; Wed, 17 May 2000 17:11:29 -0400 (EDT) Received: from frogger.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: frogger.cisco.com [171.71.161.88]) id QQipps25231 for ; Wed, 17 May 2000 21:11:28 GMT Received: from cwhytent2 (cwhyte-isdn1.cisco.com [10.19.229.234]) by frogger.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id OAA16454; Wed, 17 May 2000 14:10:50 -0700 (PDT) Message-ID: <047601bfc044$a1631e80$eae5130a@cisco.com> Reply-To: "Chris Whyte" From: "Chris Whyte" To: , References: <200005171628.KAA12003@tcb.net> Subject: Re: MPLS and IS-IS Date: Wed, 17 May 2000 14:12:32 -0700 Organization: cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > > I find that companies building products that support both protocols have to > > spend more time on bringing OSPF up to RFC compliancy (eg adding yet another > > LSA type), because it's so well defined and attempts to solve so many > > problems, rather than focusing on code and protocol optimizations that can > > solve more pressing customer problems. > > I find that initially these companies first implement and stabilize > the feature sets they're customers are asking for and *deploying*, then > worry about the 'kitchen sink'. But once you introduce the 'kitchen sink' you have to revisit the stability issue (again). I have yet to experience a company who seems to do both at the same time. That is, you ramp up on features until stability becomes a problem, then you address the stability issue. Chicken and the egg thing... Sure, maybe the startups don't have to deal with this cycle (to the same degree) quite yet. But I believe it's somewhat inevitable for them too. > > > I do believe the "perception" goes a little bit beyond implementation only > > issues. > > I don't completely follow you here. Are you suggesting that implementation > difficulty alone makes the OSPF routing protocol itself less scalable? While > they're indeed related, they're still very separate things. That's not really what I was suggesting. So yes, 5-6 years ago people might have chosen IS-IS over OSPF because of cisco's implementation issues but even today we see many more SPs around the world embracing IS-IS. And since customers drive much of the feature development, MPLS/TE using IS-IS. Why? Well, possibly lots of reasons of which more are probably intangible than tangible. But having myself spent time building and/or supporting both, and seeing others building and supporting both, I've clearly come to the conclusion that it's a bit beyond any one implementation. Possibly 244 pages of a spec (OSPF) has something to do with it... Thanks, Chris > > -danny > > From owner-mpls@UU.NET Wed May 17 17:15: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 RAA11350 for ; Wed, 17 May 2000 17:15: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 QQippt26156; Wed, 17 May 2000 21:15:15 GMT Received: by mail-control.mail.uu.net id QQipps25612 for mpls-outgoing; Wed, 17 May 2000 21:14:43 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 QQipps25607 for ; Wed, 17 May 2000 21:14: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 QQipps08113 for ; Wed, 17 May 2000 17:14:36 -0400 (EDT) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQipps27423 for ; Wed, 17 May 2000 21:14:36 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id RAA14032; Wed, 17 May 2000 17:14:30 -0400 Date: Wed, 17 May 2000 17:14:30 -0400 From: "J. Noel Chiappa" Message-Id: <200005172114.RAA14032@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: MPLS and IS-IS Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Curtis Villamizar > one timer for a one big ISIS-LSP is much friendlier to naive timer > implementations (such as linked lists of timer events) than a timer > for each OSPF-LSA. Curtis, I seem to recall hearing that one protocol problem with OSPF, in terms of scaling, was the way it "rolls over" the database slowly, to ensure that any uncaught errors get flushed out. With the current routing table sizes of 70K+ routes, and the relatively modest rollover time (which I think is 30 minutes for the entire table, IIRC), that tends to cause a fairly high update rate. Of course, I don't think anyone (at the time these protocols were designed) ever imagined in their wildest dreams (nightmares? :-) that they'd be supporting routing tables with 70K+ entries, so it's not too surprising that their are some scaling issues... Noel From owner-mpls@UU.NET Wed May 17 17:18: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 ESMTP id RAA11375 for ; Wed, 17 May 2000 17:18: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 QQippt28657; Wed, 17 May 2000 21:18:12 GMT Received: by mail-control.mail.uu.net id QQippt26045 for mpls-outgoing; Wed, 17 May 2000 21:17:43 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 QQippt26040 for ; Wed, 17 May 2000 21:17: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 QQippt08560 for ; Wed, 17 May 2000 17:17:37 -0400 (EDT) Received: from petal.blackrose.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thorn.blackrose.org [204.212.44.2]) id QQippt28141 for ; Wed, 17 May 2000 21:17:37 GMT Received: (from dorian@localhost) by petal.blackrose.org (8.9.3/8.9.3) id RAA06150; Wed, 17 May 2000 17:17:08 -0400 Date: Wed, 17 May 2000 17:17:08 -0400 From: Dorian Kim To: Chris Whyte Cc: danny@tcb.net, mpls@UU.NET Subject: Re: MPLS and IS-IS Message-ID: <20000517171708.W747@blackrose.org> References: <200005171628.KAA12003@tcb.net> <047601bfc044$a1631e80$eae5130a@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <047601bfc044$a1631e80$eae5130a@cisco.com>; from cwhyte@cisco.com on Wed, May 17, 2000 at 02:12:32PM -0700 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, May 17, 2000 at 02:12:32PM -0700, Chris Whyte wrote: > So yes, 5-6 years ago people might have chosen IS-IS over OSPF because of > cisco's implementation issues but even today we see many more SPs around the > world embracing IS-IS. And since customers drive much of the feature > development, MPLS/TE using IS-IS. > > Why? Well, possibly lots of reasons of which more are probably intangible > than tangible. But having myself spent time building and/or supporting both, > and seeing others building and supporting both, I've clearly come to the > conclusion that it's a bit beyond any one implementation. > > Possibly 244 pages of a spec (OSPF) has something to do with it... Don't underestimate the people factor. People got used to/trained with ISIS at most large ISPs. With the ever rotating musical chairs game of people that seems to be going at the ISPs engineering departments, this means that people bring what they got used to with them, hence contributing greatly to spread of ISIS. -dorian From owner-mpls@UU.NET Wed May 17 17:21:45 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 RAA11394 for ; Wed, 17 May 2000 17:21: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 QQippt02566; Wed, 17 May 2000 21:21:16 GMT Received: by mail-control.mail.uu.net id QQippt26204 for mpls-outgoing; Wed, 17 May 2000 21:20:57 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQippt26184 for ; Wed, 17 May 2000 21:20:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippt12523 for ; Wed, 17 May 2000 17:20:42 -0400 (EDT) Received: from petal.blackrose.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thorn.blackrose.org [204.212.44.2]) id QQippt01998 for ; Wed, 17 May 2000 21:20:42 GMT Received: (from dorian@localhost) by petal.blackrose.org (8.9.3/8.9.3) id RAA06198; Wed, 17 May 2000 17:20:20 -0400 Date: Wed, 17 May 2000 17:20:20 -0400 From: Dorian Kim To: "J. Noel Chiappa" Cc: mpls@UU.NET Subject: Re: MPLS and IS-IS Message-ID: <20000517172020.X747@blackrose.org> References: <200005172114.RAA14032@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200005172114.RAA14032@ginger.lcs.mit.edu>; from jnc@ginger.lcs.mit.edu on Wed, May 17, 2000 at 05:14:30PM -0400 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, May 17, 2000 at 05:14:30PM -0400, Chiappa, Noel wrote: > > From: Curtis Villamizar > > > one timer for a one big ISIS-LSP is much friendlier to naive timer > > implementations (such as linked lists of timer events) than a timer > > for each OSPF-LSA. > > Curtis, I seem to recall hearing that one protocol problem with OSPF, in > terms of scaling, was the way it "rolls over" the database slowly, to ensure > that any uncaught errors get flushed out. With the current routing table > sizes of 70K+ routes, and the relatively modest rollover time (which I think > is 30 minutes for the entire table, IIRC), that tends to cause a fairly high > update rate. > > Of course, I don't think anyone (at the time these protocols were designed) > ever imagined in their wildest dreams (nightmares? :-) that they'd be > supporting routing tables with 70K+ entries, so it's not too surprising that > their are some scaling issues... I doubt too many people's IGP is carrying 70+K routes. Most folks only carry internal links and router loopbacks in their IGPs as this is the only way to scale. -dorian From owner-mpls@UU.NET Wed May 17 17:38: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 RAA11550 for ; Wed, 17 May 2000 17:38: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 QQippu15616; Wed, 17 May 2000 21:38:55 GMT Received: by mail-control.mail.uu.net id QQippu27797 for mpls-outgoing; Wed, 17 May 2000 21:38:31 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 QQippu27783 for ; Wed, 17 May 2000 21:38:24 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 QQippu11351 for ; Wed, 17 May 2000 17:38:22 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQippu13028 for ; Wed, 17 May 2000 21:38:22 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA06707; Wed, 17 May 2000 14:38:19 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id OAA06945; Wed, 17 May 2000 14:38:19 -0700 (PDT) Date: Wed, 17 May 2000 14:38:19 -0700 (PDT) Message-Id: <200005172138.OAA06945@cirrus.juniper.net> From: Dave Katz To: dorian@blackrose.org CC: jnc@ginger.lcs.mit.edu, mpls@UU.NET In-reply-to: <20000517172020.X747@blackrose.org> (message from Dorian Kim on Wed, 17 May 2000 17:20:20 -0400) Subject: Re: MPLS and IS-IS Sender: owner-mpls@UU.NET Precedence: bulk > Of course, I don't think anyone (at the time these protocols were designed) > ever imagined in their wildest dreams (nightmares? :-) that they'd be > supporting routing tables with 70K+ entries, so it's not too surprising that > their are some scaling issues... I doubt too many people's IGP is carrying 70+K routes. Most folks only carry internal links and router loopbacks in their IGPs as this is the only way to scale. To my knowledge, the only people that have done this have not done it on purpose. It is quite educational to watch when it does happen. From owner-mpls@UU.NET Wed May 17 17:43: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 ESMTP id RAA11583 for ; Wed, 17 May 2000 17:43: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 QQippu19345; Wed, 17 May 2000 21:43:32 GMT Received: by mail-control.mail.uu.net id QQippu28236 for mpls-outgoing; Wed, 17 May 2000 21:42:51 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQippu28226 for ; Wed, 17 May 2000 21:42:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQippu14987 for ; Wed, 17 May 2000 17:42:28 -0400 (EDT) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQippu18495 for ; Wed, 17 May 2000 21:42:28 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id RAA14152; Wed, 17 May 2000 17:42:27 -0400 Date: Wed, 17 May 2000 17:42:27 -0400 From: "J. Noel Chiappa" Message-Id: <200005172142.RAA14152@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: MPLS and IS-IS Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Dino Farinacci > Noel, no one in their right mind would carry 70K routes in their IGP. Well, yes, for most people, I reckon. (If you're a singly-homed customer, absolutely, it makes no sense; just head for the exit. And if you're an IGP, you're using iBGP between your edge routers anyway.) But this issue (the roll-over) was reported to me in the context of someone who was seeing this as a real problem, although I don't know the environment. Perhaps it was a large, multi-homed site, where they wanted traffic to take the optimal external exit (and for whatever reason they didn't want to just filter in a few destinations, and have the rest of the traffic go to the nearest exit router). > For OSPF, it was a design goal to support this. Well, it was a design goal for OSPF to carry the whole routing table (in part to avoid having to do anything like iBGP, although this was before BGP existed). However, I don't think the number "70K" was in evidence at the time! :-) Noel From owner-mpls@UU.NET Wed May 17 18:11: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 ESMTP id SAA11826 for ; Wed, 17 May 2000 18:11: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 QQippw05293; Wed, 17 May 2000 22:10:53 GMT Received: by mail-control.mail.uu.net id QQippw08926 for mpls-outgoing; Wed, 17 May 2000 22:10:13 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQippw08899 for ; Wed, 17 May 2000 22:10:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQippw17779 for ; Wed, 17 May 2000 18:09: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 QQippw04443 for ; Wed, 17 May 2000 22:09:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA27672 for mpls@uu.net; Wed, 17 May 2000 18:09:57 -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 QQippw08871 for ; Wed, 17 May 2000 22:09: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 QQippw24793 for ; Wed, 17 May 2000 18:09:17 -0400 (EDT) Received: from frogger.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: frogger.cisco.com [171.71.161.88]) id QQippw06514 for ; Wed, 17 May 2000 22:09:16 GMT Received: from cwhytent2 (cwhyte-isdn1.cisco.com [10.19.229.234]) by frogger.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id PAA21375; Wed, 17 May 2000 15:08:21 -0700 (PDT) Message-ID: <04ac01bfc04c$a70feef0$eae5130a@cisco.com> Reply-To: "Chris Whyte" From: "Chris Whyte" To: "Dorian Kim" Cc: , References: <200005171628.KAA12003@tcb.net> <047601bfc044$a1631e80$eae5130a@cisco.com> <20000517171708.W747@blackrose.org> Subject: Re: MPLS and IS-IS Date: Wed, 17 May 2000 15:10:02 -0700 Organization: cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > On Wed, May 17, 2000 at 02:12:32PM -0700, Chris Whyte wrote: > > So yes, 5-6 years ago people might have chosen IS-IS over OSPF because of > > cisco's implementation issues but even today we see many more SPs around the > > world embracing IS-IS. And since customers drive much of the feature > > development, MPLS/TE using IS-IS. > > > > Why? Well, possibly lots of reasons of which more are probably intangible > > than tangible. But having myself spent time building and/or supporting both, > > and seeing others building and supporting both, I've clearly come to the > > conclusion that it's a bit beyond any one implementation. > > > > Possibly 244 pages of a spec (OSPF) has something to do with it... > > Don't underestimate the people factor. People got used to/trained with > ISIS at most large ISPs. With the ever rotating musical chairs game of > people that seems to be going at the ISPs engineering departments, this > means that people bring what they got used to with them, hence > contributing greatly to spread of ISIS. I completely agree. But I also see nothing wrong with making decisions based on what's been widely implemented in some of the largest, most complex networks, in the world. In my mind, "smart" networking has mostly been about choosing the road *more* travelled, as opposed to making general decisions in life. Like I said above, many of the reasons are likely more intangible than tangible. It always seems like we're looking for tangible reasons in order to understand why, and where, we are today. People appear to feel very comfortable with building large networks with IS-IS over OSPF. I believe you can get into this analysis paralysis phase of trying to understand why, or you can just accept it for what's it worth and continue to ride the wave. Personally, I prefer to take the simple route and ride the wave. Unfortunately, many of us as engineers have a tendency to analyze things to death at times and I wonder what we really accomplish in the process. And mind you, this is coming from someone who was a complete believer that OSPF was the only way to build a network 3 years ago. Of course, I didn't know jack about IS-IS back then either. :-) Thanks, Chris > > -dorian > > From owner-mpls@UU.NET Wed May 17 20:48: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 UAA12839 for ; Wed, 17 May 2000 20:48: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 QQipqh18944; Thu, 18 May 2000 00:48:46 GMT Received: by mail-control.mail.uu.net id QQipqh06242 for mpls-outgoing; Thu, 18 May 2000 00:48:31 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipqh06237 for ; Thu, 18 May 2000 00:48:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipqh00811 for ; Wed, 17 May 2000 20:48: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 QQipqh18557 for ; Thu, 18 May 2000 00:48:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA10529 for mpls@uu.net; Wed, 17 May 2000 20:48:19 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipqh06224 for ; Thu, 18 May 2000 00:48:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipqh00798 for ; Wed, 17 May 2000 20:48:05 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQipqh14492 for ; Thu, 18 May 2000 00:48:00 GMT Received: from dhcp-sjc16-53.cisco.com (dhcp-sjc16-53.cisco.com [171.70.96.53]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA21371; Wed, 17 May 2000 17:47:27 -0700 (PDT) Date: Wed, 17 May 2000 17:43:34 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <3738.000517@cisco.com> To: Dorian Kim CC: Chris Whyte , danny@tcb.net, mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: <20000517171708.W747@blackrose.org> References: <20000517171708.W747@blackrose.org> 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 Wednesday, May 17, 2000, 2:17 PM, Dorian Kim wrote: > Don't underestimate the people factor. People got used to/trained with > ISIS at most large ISPs. With the ever rotating musical chairs game of > people that seems to be going at the ISPs engineering departments, this > means that people bring what they got used to with them, hence > contributing greatly to spread of ISIS. Unfortunately this is true. It's becoming ok for some reason to change the IGP when a new "smart" guy comes in just because this guy feels comfortable with the other proto, instead of having this guy study the one already used. And we're talking about *operational* networks, not just labs. Alex. From owner-mpls@UU.NET Wed May 17 20:56: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 ESMTP id UAA12900 for ; Wed, 17 May 2000 20:56:08 -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 QQipqh19528; Thu, 18 May 2000 00:56:02 GMT Received: by mail-control.mail.uu.net id QQipqh06532 for mpls-outgoing; Thu, 18 May 2000 00:55:43 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 QQipqh06527 for ; Thu, 18 May 2000 00:55: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 QQipqh08353 for ; Wed, 17 May 2000 20:55:22 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQipqh23370 for ; Thu, 18 May 2000 00:55:22 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA22470; Wed, 17 May 2000 17:54:46 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id RAA07950; Wed, 17 May 2000 17:54:45 -0700 (PDT) Date: Wed, 17 May 2000 17:54:45 -0700 (PDT) Message-Id: <200005180054.RAA07950@cirrus.juniper.net> From: Dave Katz To: azinin@cisco.com CC: dorian@blackrose.org, cwhyte@cisco.com, danny@tcb.net, mpls@UU.NET In-reply-to: <3738.000517@cisco.com> (message from Alex Zinin on Wed, 17 May 2000 17:43:34 -0700) Subject: Re: MPLS and IS-IS Sender: owner-mpls@UU.NET Precedence: bulk > Don't underestimate the people factor. People got used to/trained with > ISIS at most large ISPs. With the ever rotating musical chairs game of > people that seems to be going at the ISPs engineering departments, this > means that people bring what they got used to with them, hence > contributing greatly to spread of ISIS. Unfortunately this is true. It's becoming ok for some reason to change the IGP when a new "smart" guy comes in just because this guy feels comfortable with the other proto, instead of having this guy study the one already used. And we're talking about *operational* networks, not just labs. Frankly, this is the ISP's call, not the vendors'. It guarantees continued employment for the vendors' customer support departments, and is self-limiting on the ISP's side if it turns out to be a bad call... From owner-mpls@UU.NET Wed May 17 21:00: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 ESMTP id VAA12946 for ; Wed, 17 May 2000 21:00: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 QQipqi22954; Thu, 18 May 2000 01:00:54 GMT Received: by mail-control.mail.uu.net id QQipqi09387 for mpls-outgoing; Thu, 18 May 2000 01:00:38 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 QQipqi09083 for ; Thu, 18 May 2000 01:00: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 QQipqi01415 for ; Wed, 17 May 2000 21:00:22 -0400 (EDT) Received: from petal.blackrose.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thorn.blackrose.org [204.212.44.2]) id QQipqi22488 for ; Thu, 18 May 2000 01:00:22 GMT Received: (from dorian@localhost) by petal.blackrose.org (8.9.3/8.9.3) id UAA07147; Wed, 17 May 2000 20:59:10 -0400 Date: Wed, 17 May 2000 20:59:10 -0400 From: Dorian Kim To: Alex Zinin Cc: Chris Whyte , danny@tcb.net, mpls@UU.NET Subject: Re: MPLS and IS-IS Message-ID: <20000517205910.D747@blackrose.org> References: <20000517171708.W747@blackrose.org> <3738.000517@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3738.000517@cisco.com>; from azinin@cisco.com on Wed, May 17, 2000 at 05:43:34PM -0700 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, May 17, 2000 at 05:43:34PM -0700, Alex Zinin wrote: > > Wednesday, May 17, 2000, 2:17 PM, Dorian Kim wrote: > > > Don't underestimate the people factor. People got used to/trained with > > ISIS at most large ISPs. With the ever rotating musical chairs game of > > people that seems to be going at the ISPs engineering departments, this > > means that people bring what they got used to with them, hence > > contributing greatly to spread of ISIS. > > Unfortunately this is true. > > It's becoming ok for some reason to change the IGP when a new "smart" > guy comes in just because this guy feels comfortable with the other > proto, instead of having this guy study the one already used. > And we're talking about *operational* networks, not just labs. This is not necessarily a bad thing in and of itself if done with due consideration. After all, it's an operational network, meaning that there are people operating it, and one arrives at the best technology to use via looking at the network itself and the people running as well. -dorian From owner-mpls@UU.NET Wed May 17 22:55:11 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 WAA15298 for ; Wed, 17 May 2000 22:55:10 -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 QQipqp04106; Thu, 18 May 2000 02:55:06 GMT Received: by mail-control.mail.uu.net id QQipqp00428 for mpls-outgoing; Thu, 18 May 2000 02:54: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 QQipqp00420 for ; Thu, 18 May 2000 02:54:33 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 QQipqp11447 for ; Wed, 17 May 2000 22:54:24 -0400 (EDT) Received: from chmls05.mediaone.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ne.mediaone.net [24.128.1.70]) id QQipqp03535 for ; Thu, 18 May 2000 02:54:23 GMT Received: from [24.147.154.31] (chapins.ne.mediaone.net [24.147.154.31]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id WAA28266; Wed, 17 May 2000 22:54:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: lyman@127.0.0.1 Message-Id: In-Reply-To: <200005172008.QAA13630@ginger.lcs.mit.edu> References: <200005172008.QAA13630@ginger.lcs.mit.edu> Date: Wed, 17 May 2000 22:54:05 -0400 To: "J. Noel Chiappa" From: Lyman Chapin Subject: Re: MPLS and IS-IS Cc: mpls@UU.NET, lyman@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 4:08 PM -0400 5/17/00, J. Noel Chiappa wrote: >PS: Somwhere, covered by many layers of dust, I have at least two such >documents, one by Radia and one by me, dating from around the period of the >FSU IETF (whenever that was - probably '84 or so). Noel, Probably not '84, as the first IETF meeting took place in January 1986. Radia's paper was published in IEEE Network (September 1991) - "A Comparison between Two Routing Protocols: OSPF and IS-IS." The definitive comparison of OSPF and IS-IS, of course, is the 1991 Interop debate between Radia and Milo Medin, which also featured Ross Callon and Dave Clark debating the merits, respectively, of "integrated" and "ships in the night" routing for the Internet. Radia and Milo published their debate arguments in the October 1991 number (5:10) of Ole Jacobsen's ConneXions - "The Great IGP Debate, Part I: IS-IS and Integrated Routing" by Radia, and "The Great IGP Debate, Part II: The Open Shortest Path First (OSPF) Routing Protocol" by Milo. I'm sure these are on the web somewhere. - Lyman From owner-mpls@UU.NET Thu May 18 02:13:00 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 CAA28155 for ; Thu, 18 May 2000 02:12: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 QQiprc18841; Thu, 18 May 2000 06:12:53 GMT Received: by mail-control.mail.uu.net id QQiprc15126 for mpls-outgoing; Thu, 18 May 2000 06:12: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 QQiprc15121 for ; Thu, 18 May 2000 06:12:24 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 QQiprc02672 for ; Thu, 18 May 2000 02:12: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 QQiprc17740 for ; Thu, 18 May 2000 06:12:19 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA01999 for mpls@uu.net; Thu, 18 May 2000 02:12:08 -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 QQiprc15103 for ; Thu, 18 May 2000 06:11: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 QQiprc02644 for ; Thu, 18 May 2000 02:11:38 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiprc16629 for ; Thu, 18 May 2000 06:11:38 GMT Received: from sj-dial-2-200.cisco.com (sj-dial-2-200.cisco.com [10.19.226.201]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA09632; Wed, 17 May 2000 23:09:57 -0700 (PDT) Date: Wed, 17 May 2000 23:06:01 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <15962.000517@cisco.com> To: Dave Katz CC: dorian@blackrose.org, cwhyte@cisco.com, danny@tcb.net, mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: <200005180054.RAA07950@cirrus.juniper.net> References: <200005180054.RAA07950@cirrus.juniper.net> 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 Wednesday, May 17, 2000, 5:54 PM, Dave Katz wrote: > It's becoming ok for some reason to change the IGP when a new "smart" > guy comes in just because this guy feels comfortable with the other > proto, instead of having this guy study the one already used. > And we're talking about *operational* networks, not just labs. > Frankly, this is the ISP's call, not the vendors'. It guarantees > continued employment for the vendors' customer support departments, > and is self-limiting on the ISP's side if it turns out to be a bad > call... This may be true... However, this also is a matter of stability of ISPs' networks [read stability of the Internet] and of things like the number of night pages from your customer... And one more point---if you really care about your customer, do you want them to change their IGP just because some ppl [that usually come and go] feel better about the other proto? Alex. From owner-mpls@UU.NET Thu May 18 02:19: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 ESMTP id CAA28518 for ; Thu, 18 May 2000 02:19: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 QQiprd00749; Thu, 18 May 2000 06:19:30 GMT Received: by mail-control.mail.uu.net id QQiprd15628 for mpls-outgoing; Thu, 18 May 2000 06:19: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 QQiprd15623 for ; Thu, 18 May 2000 06:19: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 QQiprd03210 for ; Thu, 18 May 2000 02:18:54 -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 QQiprd07729 for ; Thu, 18 May 2000 06:18:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA02547 for mpls@uu.net; Thu, 18 May 2000 02:18:53 -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 QQiprd15600 for ; Thu, 18 May 2000 06:18:37 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 QQiprd03174 for ; Thu, 18 May 2000 02:18:34 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiprd29137 for ; Thu, 18 May 2000 06:18:34 GMT Received: from sj-dial-2-200.cisco.com (sj-dial-2-200.cisco.com [10.19.226.201]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA11689; Wed, 17 May 2000 23:17:36 -0700 (PDT) Date: Wed, 17 May 2000 23:13:42 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <8967.000517@cisco.com> To: Dorian Kim CC: Chris Whyte , danny@tcb.net, mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: <20000517205910.D747@blackrose.org> References: <20000517205910.D747@blackrose.org> 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 Wednesday, May 17, 2000, 5:59 PM, Dorian Kim wrote: >> It's becoming ok for some reason to change the IGP when a new "smart" >> guy comes in just because this guy feels comfortable with the other >> proto, instead of having this guy study the one already used. >> And we're talking about *operational* networks, not just labs. > This is not necessarily a bad thing in and of itself if done with due > consideration. Well, sure it's not, provided [as you say] it's really and really justified. Can you imagine a new PC support guy coming in and changing all OS'es from Win9X to OS/2 just because he thinks it's cool and Win9X makes him seek? ;) See what I'm getting on? If personal preferences are the only *real* driving factor and it's affecting one's engineering, troubleshooting and NOC services [just because ppl already know the proto they've been working with for considerable time] it seems to be that the change [which is not bad per se, of course] may probably lead to bad things :) > After all, it's an operational network, meaning that there are people > operating it, I'd say "operational" == "the one that actually operates" :) Alex. > and one arrives at the best technology to use via > looking at the network itself and the people running as well. > -dorian From owner-mpls@UU.NET Thu May 18 02:27: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 CAA28578 for ; Thu, 18 May 2000 02:27: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 QQiprd15727; Thu, 18 May 2000 06:27:46 GMT Received: by mail-control.mail.uu.net id QQiprd16129 for mpls-outgoing; Thu, 18 May 2000 06:27:10 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 QQiprd16124 for ; Thu, 18 May 2000 06:27: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 QQiprd06688 for ; Thu, 18 May 2000 02:27:05 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQiprd12512 for ; Thu, 18 May 2000 06:27:05 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id XAA10268; Wed, 17 May 2000 23:26:30 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id XAA09536; Wed, 17 May 2000 23:26:28 -0700 (PDT) Date: Wed, 17 May 2000 23:26:28 -0700 (PDT) Message-Id: <200005180626.XAA09536@cirrus.juniper.net> From: Dave Katz To: azinin@cisco.com CC: dorian@blackrose.org, cwhyte@cisco.com, danny@tcb.net, mpls@UU.NET In-reply-to: <15962.000517@cisco.com> (message from Alex Zinin on Wed, 17 May 2000 23:06:01 -0700) Subject: Re: MPLS and IS-IS Sender: owner-mpls@UU.NET Precedence: bulk However, this also is a matter of stability of ISPs' networks [read stability of the Internet] and of things like the number of night pages from your customer... And one more point---if you really care about your customer, do you want them to change their IGP just because some ppl [that usually come and go] feel better about the other proto? What I want them to do is not at issue. I would advise a customer against making such changes willy-nilly, but I don't think there are very many that would make such a change lightly. I'll settle for getting enough notice so that we can help with the transition (as opposed to "guess what, we're switching IGPs this weekend!") ISPs that are flippant about such issues don't stay in business too long (or at least the engineers making such decisions don't stay employed too long). Self-correcting. From owner-mpls@UU.NET Thu May 18 03:01: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 DAA28819 for ; Thu, 18 May 2000 03:01: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 QQiprg03289; Thu, 18 May 2000 07:01:39 GMT Received: by mail-control.mail.uu.net id QQiprg22395 for mpls-outgoing; Thu, 18 May 2000 07:01: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 QQiprg22390 for ; Thu, 18 May 2000 07:01: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 QQiprg06838 for ; Thu, 18 May 2000 03:01:17 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQiprg02969 for ; Thu, 18 May 2000 07:01:16 GMT Received: from oleary-lt (wcom-dial-51.juniper.net [172.16.14.116]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id AAA12265; Thu, 18 May 2000 00:01:11 -0700 (PDT) Message-Id: <4.2.0.58.20000517174906.01f3de40@garnet.juniper.net> X-Sender: doleary@garnet.juniper.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 17 May 2000 17:52:04 -0700 To: Dave Katz , jnc@ginger.lcs.mit.edu From: "dave o'leary" Subject: Re: MPLS and IS-IS Cc: mpls@UU.NET In-Reply-To: <200005172039.NAA06796@cirrus.juniper.net> References: <200005172008.QAA13630@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:39 PM 5/17/00 -0700, Dave Katz wrote: > PS: Somwhere, covered by many layers of dust, I have at least two such > documents, one by Radia and one by me, dating from around the period > of the > FSU IETF (whenever that was - probably '84 or so). FSU was in 1990, one of the first ones I went to (and the first one hosted at a SURAnet site after I started working there, so I really remember how bad the connectivity was!). There was also "the great IGP debate" between Milo and Radia (?) at one of the early Interops, and they wrote accompanying pieces for Connections, which might be on-line somewhere, or at least Ole probably has electronic copies somewhere. We're straying pretty far from the MPLS WG mailing list charter at this point. dave From owner-mpls@UU.NET Thu May 18 03:06: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 DAA28842 for ; Thu, 18 May 2000 03:06: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 QQiprg28543; Thu, 18 May 2000 07:06:49 GMT Received: by mail-control.mail.uu.net id QQiprg26449 for mpls-outgoing; Thu, 18 May 2000 07:06: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 QQiprg26430 for ; Thu, 18 May 2000 07:06:15 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 QQiprg09652 for ; Thu, 18 May 2000 03:05:59 -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 QQiprg26920 for ; Thu, 18 May 2000 07:05:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA05518 for mpls@uu.net; Thu, 18 May 2000 03:05:58 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiprg26301 for ; Thu, 18 May 2000 07:05:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiprg03907 for ; Thu, 18 May 2000 03:05:24 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiprg25762 for ; Thu, 18 May 2000 07:05:24 GMT Received: from sj-dial-2-200.cisco.com (sj-dial-2-200.cisco.com [10.19.226.201]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA24055; Thu, 18 May 2000 00:04:50 -0700 (PDT) Date: Thu, 18 May 2000 00:00:56 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <80.000518@cisco.com> To: Quaizar Vohra CC: "J. Noel Chiappa" , mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: <14626.64538.76113.849173@fuinar.juniper.net> References: <14626.64538.76113.849173@fuinar.juniper.net> 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 Some notes: Wednesday, May 17, 2000, 1:26 PM, Quaizar Vohra wrote: > 2) DR election in OSPF is much more complex because a DR has to > play a more complex role in OSPF than ISIS because of a more complex > flood/ack mechanism of OSPF. I wouldn't say DR election is really much more complex. Yes we elect BDR as well, yes we optimize flooding through broadcast links, but I doubt it adds much of the complexity. > 3) ISIS allows breaking of a large LSP into MTU sized chunks, > while OSPF depends on IP fragmentation. If one fragment is lost > you end up transmitting only that fragment in ISIS. In OSPF you end > up trasnsmitting an entire LSA. 1. OSPF RFC *discourages* origination of big LSAs. They can be used, but if the implementation is clueful enough, it is not necessary [unless you have a really large number of neighbors or stub hosts, but even then you can do some tricks] 2. I'd say "an entire LSA" is going to be much smaller than an LSP fragment. This is because in ISIS we put TLVs to different fragments of the LSP and the number of fragments is limited, while in OSPF we originate different LSAs for different purposes and the number of originated LSAs is not limited [e.g. you originate a separate LSA for every inter-area or external route]. 3. We do not retransmit LSAs in OSPF, we send LS Update packets that contain them. > 4) 35 K in OSPF lines of code vs 15 K lines of ISIS code. > 5) ISIS lacks virtual link and NSSA like optimizations. > OSPF seems more complex to implement but the complexity could > be gotten rid off if you choose note to implement the not so > heavily used features as in 5). You wouldn't be compliant to the RFC without the VLs :)) Alex. From owner-mpls@UU.NET Thu May 18 03:18: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 DAA28920 for ; Thu, 18 May 2000 03:18: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 QQiprh16706; Thu, 18 May 2000 07:18:17 GMT Received: by mail-control.mail.uu.net id QQiprh27314 for mpls-outgoing; Thu, 18 May 2000 07:17:54 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 QQiprh27309 for ; Thu, 18 May 2000 07:17: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 QQiprh08669 for ; Thu, 18 May 2000 03:17: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 QQiprh15275 for ; Thu, 18 May 2000 07:17:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA06354 for mpls@uu.net; Thu, 18 May 2000 03:17:39 -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 QQiprh27253 for ; Thu, 18 May 2000 07:17: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 QQiprh11212 for ; Thu, 18 May 2000 03:17:07 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiprh12782 for ; Thu, 18 May 2000 07:17:07 GMT Received: from sj-dial-2-200.cisco.com (sj-dial-2-200.cisco.com [10.19.226.201]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA28989; Thu, 18 May 2000 00:15:34 -0700 (PDT) Date: Thu, 18 May 2000 00:11:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <38.000518@cisco.com> To: John Day CC: Dave Katz , ben@layer8.net, danny@tcb.net, mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: References: 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 Wednesday, May 17, 2000, 1:00 PM, John Day wrote: >> >>At the end of the day, while OSPF is more complex than IS-IS, it is not >>*that* much more complex. The stuff that is hard to do well is, for >>the most part, common to the two protocols. Each has its peculiar >>challenges. >> > It is not just shaking out the implementation that reduces the stability, > but the number of "knobs" you have for tuning it. OSPF has many more > "knobs" than ISIS. This makes it "more flexible", but it also makes > getting a stable configuration more difficult. The analogy I have always > used that it was a bit like trying to tune an old TV tube. There are only > 3 knobs but any adjustment of one affects the others. The problem with > OSPF is that there are many more than 3 knobs and none are orthogonal to > any of the others. This makes finding a stable configuration very > difficult and the bigger the network the more difficult it will be and > hence the belief that it doesn't scale well. But another question is---what are the knobs and what are just usual configuration commands, and how many knobs do you really *have* to touch? I mean in order to get OSPF up and running all you need is just start the process and assign interfaces to areas. You want ABR to summarize the routes---you need one more command to tell him how you want to be done [I can't imagine any proto doing this automagically other than the way RIPv1 and IGRP did this in classful networks]. You need the area to be stub---just mark it as stub. You want no inter-area route to go into it---just tell the ABR about it. I mean, most of the commands [that actually correspond to protocol- specific settings] *are* orthogonal. Alex. From owner-mpls@UU.NET Thu May 18 03:30: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 ESMTP id DAA29004 for ; Thu, 18 May 2000 03:30: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 QQiprh20678; Thu, 18 May 2000 07:29:55 GMT Received: by mail-control.mail.uu.net id QQiprh27915 for mpls-outgoing; Thu, 18 May 2000 07:29:34 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiprh27910 for ; Thu, 18 May 2000 07:29:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiprh05688 for ; Thu, 18 May 2000 03:29:19 -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 QQiprh20212 for ; Thu, 18 May 2000 07:29:19 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA07129 for mpls@uu.net; Thu, 18 May 2000 03:29:18 -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 QQiprh27899 for ; Thu, 18 May 2000 07:28:55 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 QQiprh11986 for ; Thu, 18 May 2000 03:28:49 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiprh19874 for ; Thu, 18 May 2000 07:28:49 GMT Received: from sj-dial-2-200.cisco.com (sj-dial-2-200.cisco.com [10.19.226.201]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA02587; Thu, 18 May 2000 00:28:46 -0700 (PDT) Date: Thu, 18 May 2000 00:24:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <1117.000518@cisco.com> To: "J. Noel Chiappa" CC: mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: <200005172001.QAA13594@ginger.lcs.mit.edu> References: <200005172001.QAA13594@ginger.lcs.mit.edu> 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 Wednesday, May 17, 2000, 1:01 PM, J. Noel Chiappa wrote: > > OSPF fixes some of the scalability problem by introducing stub area > > .. One important difference is stub area cannot be a transit area. > In fact, it's fundamentally impossible for an area which does not have > complete information about the state of things outside the area to serve as a > transit area (at least in a pure datagram mode of operation - obviously, you > can tunnel stuff across). As we can see with NSSAs, this pretty much depends on the direction. If the area has info how to reach the prefixes announced from it to the backbone, it's all right, since the reverse traffic will be forwarded to a more knowledgeable router [ABR] along the default. > The reason is fairly obvious - if an internal router simply routes packets > destined to external destinations to the nearest border router, and the > packet is a transit packet, it's quite likely that that router would be the > router the packet came in through! We're talking about IGP routes, right? I mean if we have BGP on top of this, we're gonna have much more fun :) If we're talking about the IGP case, then things are not so bad. If that border router received that packet, it means that it either: - originated a route covering packet's destination address, or - the best path to such a route is going through it [external route most probably] In the first case we're supposed to know the destination (since that guy forwarded the packet to us), but it's not interesting, since we're not the transit area... In the second case we need to have an explicit route to the external destination, while having the default to the border. This is the case with NSSA. Alex. > It's because IS-IS doesn't import data that it has (unless there's been some > recent upgrade I'm not familiar with) the restriction that the level 2 > routers have to form a directly connected graph (i.e. no virtual links across > level 1 areas, as supported by OSPF). > Noel From owner-mpls@UU.NET Thu May 18 04:28: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 ESMTP id EAA29742 for ; Thu, 18 May 2000 04:28: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 QQiprl29516; Thu, 18 May 2000 08:28:21 GMT Received: by mail-control.mail.uu.net id QQiprl09651 for mpls-outgoing; Thu, 18 May 2000 08:27:33 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiprl09643 for ; Thu, 18 May 2000 08:27:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiprl09633; Thu, 18 May 2000 04:27:18 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQiprl28814; Thu, 18 May 2000 08:27:16 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4I8EmH27996; Thu, 18 May 2000 10:14:48 +0200 (MET DST) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4I8KPq14042; Thu, 18 May 2000 10:20:26 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 18 May 2000 10:18:27 +0200 Received: from esealnt409-in.al.sw.ericsson.se ([153.88.251.32]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 18 May 2000 08:18:27 0000 (GMT) Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt409-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 18 May 2000 10:18:27 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 18 May 2000 10:20:23 +0200 Message-ID: From: "Gabor Korossy (ETH)" To: mpls@UU.NET, "'isis-wg@juniper.net'" , "'te-wg@uu.net'" Subject: RE: MPLS and IS-IS Date: Thu, 18 May 2000 10:20:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 May 2000 08:18:27.0859 (UTC) FILETIME=[A4E7DE30:01BFC0A1] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA29742 Hi, if I may repeat, could anyone help me please, find the draft "IS-IS extensions for Traffic Engineering," draft-ietf-isis-traffic-01.txt If so many ISPs run IS-IS with MPLS TE extensions shouldn't it become an IETF standard? Maybe one of the MPLS, TE and IS-IS working groups doesn´t feel ashamed to adopt this child? regards - Gabor >> -----Original Message----- >> From: Chris.Flores@broadwing.com [mailto:Chris.Flores@broadwing.com] >> Sent: Wednesday, May 17, 2000 8:48 PM >> To: mpls@UU.NET >> Subject: FW: MPLS and IS-IS >> >> >> >> David - >> >> Most large ISPs in the US use ISIS: >> >> UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. >> >> It also seems like more and more european ISPs are starting >> to use ISIS: >> EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. >> >> Chris >> >> -----Original Message----- >> From: David Wang [mailto:david.wang@metro-optix.com] >> Sent: Wednesday, May 17, 2000 12:36 PM >> To: 'HANSEN CHAN'; mpls@UU.NET >> Subject: RE: MPLS and IS-IS >> >> >> Hi all, >> >> IS-IS is defined to work with CLNP not for IP originally. >> Until today a lot >> of SONET and telecommunication equipment vendors still use >> IS-IS to route >> CLNP packets through the SONET Data communication >> channel(DCC) to carry >> management information and there is a great pressure to >> change this to OSPF >> and IP. I also know that UUNET runs IS-IS on their network. >> I never heard >> any other networks run IS-IS. Seems I am wrong. My questions are. >> >> 1. You guys are talking about using IS-IS in a IP networks >> not in CLNP >> networks. The IS-IS has been modified according to RFC 1195 >> (Use of OSI >> IS-IS for Routing in TCP/IP and Dual Environments) or some >> other standard. >> Is this correct? >> >> 2. Besides UUNET, which ISPs run IS-IS protocol? Can you >> name a few? or >> what percentage of networks run IS-IS instead of OSPF? >> >> Thanks >> David >> >> >> -----Original Message----- >> From: HANSEN CHAN [mailto:hchan@newbridge.com] >> Sent: Tuesday, May 16, 2000 7:22 AM >> To: mpls@UU.NET >> Subject: MPLS and IS-IS >> >> >> Hi all, >> >> I have been hearing IS-IS is a better protocol to be used >> than OSPF in a >> MPLS >> network for TE application. Is that a fair statement? What >> are the technical >> reasons? >> >> Appreciate if someone can shed some light on this subject. >> >> Thanks, >> Hansen >> >> From owner-mpls@UU.NET Thu May 18 05:13: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 FAA01219 for ; Thu, 18 May 2000 05:13: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 QQipro27450; Thu, 18 May 2000 09:13:09 GMT Received: by mail-control.mail.uu.net id QQipro20474 for mpls-outgoing; Thu, 18 May 2000 09:12:35 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipro20469 for ; Thu, 18 May 2000 09:12:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipro13138 for ; Thu, 18 May 2000 05:12:09 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQipro26013 for ; Thu, 18 May 2000 09:12:09 GMT Received: from fuinar.juniper.net (fuinar.juniper.net [207.79.80.140]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id CAA19460; Thu, 18 May 2000 02:12:07 -0700 (PDT) Received: (from qv@localhost) by fuinar.juniper.net (8.8.8/8.7.3) id CAA01778; Thu, 18 May 2000 02:12:09 -0700 (PDT) From: Quaizar Vohra MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 18 May 2000 02:12:08 -0700 (PDT) To: Alex Zinin Cc: Quaizar Vohra , "J. Noel Chiappa" , mpls@UU.NET Subject: Re: MPLS and IS-IS In-Reply-To: <80.000518@cisco.com> References: <14626.64538.76113.849173@fuinar.juniper.net> <80.000518@cisco.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14627.44242.875167.230651@fuinar.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Some notes: > > broadcast links, but I doubt it adds much of the complexity. > > > 3) ISIS allows breaking of a large LSP into MTU sized chunks, > > while OSPF depends on IP fragmentation. If one fragment is lost > > you end up transmitting only that fragment in ISIS. In OSPF you end > > up trasnsmitting an entire LSA. > > 1. OSPF RFC *discourages* origination of big LSAs. They can be used, > but if the implementation is clueful enough, it is not necessary > [unless you have a really large number of neighbors or stub hosts, > but even then you can do some tricks] OSPF does certainly mention breaking OSPF packet types likely to be large into several seperate protocol packets. But I certainly dont know of a way of breaking an LSA itself. Specially if router LSAs are large. If you are refering to A.1 in rfc 2328 then this is what I interpret. I should have added that 3) is true only in the router LSA context. An OSPF router LSA can be larger than the link MTU and hence would fit one single LS update paclet and would need IP fragmentation. Yes I agree that an ISIS LSP can be much larger as it contains all the other TLVs, just not the IS Reachability TLV. But loosing an LSP fragment is not worse than loosing an OSPF LS update packet with all its different LSAs, as you would end up loosing all the LSAs in the packet. But the issue I was raising was that if a router LSA is larger than the link mtu, it will fit a single update packet which will be IP fragmented. If one IP frag is lost, you end up retrasmitting the entire LSA. While in case of ISIS the corresponding IS Reachability TLVs will span several LSP fragments. If one is lost, you just need to retranmit that single LSP fragment. Afterall this might not be so important if your topology doesnot have a large degree of connectivity, e.g. in an ATM overlay model. > > 2. I'd say "an entire LSA" is going to be much smaller than an LSP > fragment. This is because in ISIS we put TLVs to different > fragments of the LSP and the number of fragments is limited, while > in OSPF we originate different LSAs for different purposes and > the number of originated LSAs is not limited [e.g. you originate > a separate LSA for every inter-area or external route]. Agreed, but this is another difference. A pro for the OSPF. > > 3. We do not retransmit LSAs in OSPF, we send LS Update packets that The unit of retransmission is an LSA not an LS update packet. Yes if an LS update packet is lost, all its constituent LSAs will need retrasmitting. So is the case of LSP fragment. > contain them. > > > 4) 35 K in OSPF lines of code vs 15 K lines of ISIS code. > > > 5) ISIS lacks virtual link and NSSA like optimizations. > > > OSPF seems more complex to implement but the complexity could > > be gotten rid off if you choose note to implement the not so > > heavily used features as in 5). > > You wouldn't be compliant to the RFC without the VLs :)) > > Alex. > > From owner-mpls@UU.NET Thu May 18 10:09: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 KAA07055 for ; Thu, 18 May 2000 10:09: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 QQipsi09907; Thu, 18 May 2000 14:09:32 GMT Received: by mail-control.mail.uu.net id QQipsi22139 for mpls-outgoing; Thu, 18 May 2000 14:08:40 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipsi22129 for ; Thu, 18 May 2000 14:08:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipsi08680 for ; Thu, 18 May 2000 10:08:06 -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 QQipsi08862 for ; Thu, 18 May 2000 14:08:06 GMT Received: (qmail 6336 invoked by uid 60001); 18 May 2000 14:08:05 -0000 Message-ID: <20000518140805.6335.qmail@web3001.mail.yahoo.com> Received: from [141.212.130.253] by web3001.mail.yahoo.com; Thu, 18 May 2000 07:08:05 PDT Date: Thu, 18 May 2000 07:08:05 -0700 (PDT) From: Jessica Yu Subject: Re: MPLS and IS-IS To: mpls@UU.NET Cc: jyy_99@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Every couple of years (as recent as last year), IS-IS vs OSPF debate pops up. Same history reiterated, same comparison made and not much differences among the two discovered. Every time a new features to be added to IGP such as TE, parallel efforts have to be made to add it to both protocols. Every time someone building a new network, they have to spent time agonizing about what to use: OSPF or IS-IS. Every router vendor has to split already thin software development resource to develop and/or maintain both IGP protocols. As a result, instead of having a fully cooked IGP, they may have two half-cooked ones. ...... Lots lots energy, resource and brain power can be saved. So the question is - Is there any value to continue supporting 2 different IGP protocols which essentially serve the same purpose (especially the need for supporting CLNS does not exist) and there is no obvious advantages associated with one over the other ? To continue serve the installed base is probably the only reason to keep both? Anything else? By the way, it's fortunate that BGP and IDRP did not take the same path. Now we only have one inter-domain protocol to implement and support. --jessica __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Thu May 18 10:29: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 KAA07546 for ; Thu, 18 May 2000 10:29: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 QQipsj25477; Thu, 18 May 2000 14:29:50 GMT Received: by mail-control.mail.uu.net id QQipsj23559 for mpls-outgoing; Thu, 18 May 2000 14:29:25 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 QQipsj23554 for ; Thu, 18 May 2000 14:29: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 QQipsj22580 for ; Thu, 18 May 2000 10:29:00 -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 QQipsj24899 for ; Thu, 18 May 2000 14:28:59 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 HAA26568 for ; Thu, 18 May 2000 07:29:05 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA22707 for mpls@uu.net; Thu, 18 May 2000 10:28:58 -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 QQippt26864 for ; Wed, 17 May 2000 21:25:38 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 QQippt20368 for ; Wed, 17 May 2000 17:25:33 -0400 (EDT) Received: from dino-pc.procket.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: flowpoint.procket.com [205.253.146.41]) id QQippt05676 for ; Wed, 17 May 2000 21:25:33 GMT Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id OAA21101; Wed, 17 May 2000 14:25:26 -0700 Date: Wed, 17 May 2000 14:25:26 -0700 Message-Id: <200005172125.OAA21101@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: jnc@ginger.lcs.mit.edu CC: mpls@UU.NET, jnc@ginger.lcs.mit.edu In-reply-to: <200005172114.RAA14032@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: MPLS and IS-IS References: <200005172114.RAA14032@ginger.lcs.mit.edu> Sender: owner-mpls@UU.NET Precedence: bulk >> Of course, I don't think anyone (at the time these protocols were designed) >> ever imagined in their wildest dreams (nightmares? :-) that they'd be >> supporting routing tables with 70K+ entries, so it's not too surprising that >> their are some scaling issues... Noel, no one in their right mind would carry 70K routes in their IGP. For OSPF, it was a design goal to support this. For IS-IS, it was never intended to import OSI inter-domain routes into IS-IS. Yes, you can configure many IS-IS implementations to do this, but no one would dare do it. Dino From owner-mpls@UU.NET Thu May 18 10:30: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 KAA07574 for ; Thu, 18 May 2000 10:30: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 QQipsk26299; Thu, 18 May 2000 14:30:25 GMT Received: by mail-control.mail.uu.net id QQipsj23568 for mpls-outgoing; Thu, 18 May 2000 14:29:45 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 QQipsj23563 for ; Thu, 18 May 2000 14:29: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 QQipsj17779 for ; Thu, 18 May 2000 10:29:22 -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 QQipsj24965 for ; Thu, 18 May 2000 14:29:20 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 HAA22233 for ; Thu, 18 May 2000 07:29:27 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA22711 for mpls@uu.net; Thu, 18 May 2000 10:29:17 -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 QQippv29106 for ; Wed, 17 May 2000 21:52: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 QQippv13088 for ; Wed, 17 May 2000 17:52:36 -0400 (EDT) Received: from dino-pc.procket.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: flowpoint.procket.com [205.253.146.41]) id QQippv22762 for ; Wed, 17 May 2000 21:52:34 GMT Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id OAA22095; Wed, 17 May 2000 14:52:30 -0700 Date: Wed, 17 May 2000 14:52:30 -0700 Message-Id: <200005172152.OAA22095@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: jnc@ginger.lcs.mit.edu CC: mpls@UU.NET, jnc@ginger.lcs.mit.edu In-reply-to: <200005172142.RAA14152@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: MPLS and IS-IS References: <200005172142.RAA14152@ginger.lcs.mit.edu> Sender: owner-mpls@UU.NET Precedence: bulk >> But this issue (the roll-over) was reported to me in the context of someone >> who was seeing this as a real problem, although I don't know the environment. >> Perhaps it was a large, multi-homed site, where they wanted traffic to take >> the optimal external exit (and for whatever reason they didn't want to just >> filter in a few destinations, and have the rest of the traffic go to the >> nearest exit router). NSI. Remember the old original OSPF working group days Noel. You, Paul T, John, Rob, Milo, and me? >> Well, it was a design goal for OSPF to carry the whole routing table (in part >> to avoid having to do anything like iBGP, although this was before BGP >> existed). However, I don't think the number "70K" was in evidence at the >> time! :-) My memory recalls they were both going on at the same time. This was '89-'90 time frame. OSPF did start first, but BGP began before OSPF was done. Dino P.S. BTW, is OSPF done? ;-) From owner-mpls@UU.NET Thu May 18 10:31: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 KAA07651 for ; Thu, 18 May 2000 10:31: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 QQipsk27412; Thu, 18 May 2000 14:31:21 GMT Received: by mail-control.mail.uu.net id QQipsk23671 for mpls-outgoing; Thu, 18 May 2000 14: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 QQipsk23648 for ; Thu, 18 May 2000 14:30: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 QQipsk22927 for ; Thu, 18 May 2000 10:30:32 -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 QQipsk26481 for ; Thu, 18 May 2000 14:30:31 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 HAA27595 for ; Thu, 18 May 2000 07:30:37 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA22721 for mpls@uu.net; Thu, 18 May 2000 10:30:30 -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 QQipre16355 for ; Thu, 18 May 2000 06:32: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 QQipre07477 for ; Thu, 18 May 2000 02:32:03 -0400 (EDT) Received: from pub187.ripemtg.ripe.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pub187.ripemtg.ripe.net [193.0.5.187]) id QQipre24432 for ; Thu, 18 May 2000 06:32:02 GMT Received: from randy by pub187.ripemtg.ripe.net with local (Exim 3.12 #1) id 12sJqe-0002HY-00; Thu, 18 May 2000 08:31:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Alex Zinin Cc: mpls@UU.NET Subject: Re: MPLS and IS-IS References: <200005180054.RAA07950@cirrus.juniper.net> <15962.000517@cisco.com> Message-Id: Date: Thu, 18 May 2000 08:31:56 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >>> It's becoming ok for some reason to change the IGP when a new "smart" >>> guy comes in just because this guy feels comfortable with the other >>> proto, instead of having this guy study the one already used. >>> And we're talking about *operational* networks, not just labs. >> Frankly, this is the ISP's call, not the vendors'. It guarantees >> continued employment for the vendors' customer support departments, >> and is self-limiting on the ISP's side if it turns out to be a bad >> call... > This may be true... > However, this also is a matter of stability of ISPs' networks [read > stability of the Internet] and of things like the number of night > pages from your customer... so, should we expect an internet-draft from you outlawing smart people doing smart things to their own networks? randy From owner-mpls@UU.NET Thu May 18 10:32:10 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 KAA07675 for ; Thu, 18 May 2000 10:32: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 QQipsk27947; Thu, 18 May 2000 14:32:05 GMT Received: by mail-control.mail.uu.net id QQipsk23809 for mpls-outgoing; Thu, 18 May 2000 14:31: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 QQipsk23751 for ; Thu, 18 May 2000 14:31: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 QQipsk18158 for ; Thu, 18 May 2000 10:30:54 -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 QQipsk26639 for ; Thu, 18 May 2000 14:30:54 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 HAA23400 for ; Thu, 18 May 2000 07:31:00 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA22727 for mpls@uu.net; Thu, 18 May 2000 10: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 QQipre16532 for ; Thu, 18 May 2000 06:37:17 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 QQipre04878 for ; Thu, 18 May 2000 02:37:01 -0400 (EDT) Received: from pub187.ripemtg.ripe.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pub187.ripemtg.ripe.net [193.0.5.187]) id QQipre18231 for ; Thu, 18 May 2000 06:37:01 GMT Received: from randy by pub187.ripemtg.ripe.net with local (Exim 3.12 #1) id 12sJvO-0002IV-00; Thu, 18 May 2000 08:36:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Dave Katz Cc: mpls@UU.NET Subject: Re: MPLS and IS-IS References: <15962.000517@cisco.com> <200005180626.XAA09536@cirrus.juniper.net> Message-Id: Date: Thu, 18 May 2000 08:36:50 +0200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > However, this also is a matter of stability of ISPs' networks [read > stability of the Internet] and of things like the number of night > pages from your customer... > > And one more point---if you really care about your customer, do > you want them to change their IGP just because some ppl [that usually > come and go] feel better about the other proto? > > What I want them to do is not at issue. I would advise a customer > against making such changes willy-nilly, but I don't think there are > very many that would make such a change lightly. I'll settle for > getting enough notice so that we can help with the transition (as > opposed to "guess what, we're switching IGPs this weekend!") uh, dave. other than network stability etc, a customer should neither know nor care what igp an isp runs. no notice to customers should be relevant. until mpls/igp/te, one's igp was a trivial part of one's configuration, merely a way to help the bgp-enabled interfaces find eachother and to do some very primitive te. randy From owner-mpls@UU.NET Thu May 18 11:26:12 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 LAA08645 for ; Thu, 18 May 2000 11:26:12 -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 QQipsn11988; Thu, 18 May 2000 15:26:07 GMT Received: by mail-control.mail.uu.net id QQipsn06234 for mpls-outgoing; Thu, 18 May 2000 15:25: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 QQipsn06229 for ; Thu, 18 May 2000 15:25: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 QQipsn03062 for ; Thu, 18 May 2000 11:25: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 QQipsn10013 for ; Thu, 18 May 2000 15:25:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA19621 for mpls@uu.net; Thu, 18 May 2000 11:25:14 -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 QQipsn06189 for ; Thu, 18 May 2000 15:24: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 QQipsn25986 for ; Thu, 18 May 2000 11:24: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 QQipsn10795 for ; Thu, 18 May 2000 15:24:37 GMT Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA19492; Thu, 18 May 2000 11:24:28 -0400 (EDT) Message-Id: <4.2.0.58.20000518112251.00a73420@pilgrim.cisco.com> X-Sender: rschmitt@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 18 May 2000 11:28:41 -0700 To: jcucchiara@brixnet.com, mpls@UU.NET From: Rob Schmitt Subject: OID progression in LDP MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk It should be noted that the OID progression in the LDP MIB rev 05 has some holes in it. Since the LdpSessionObjects were made into LdpPeerObjects, it caused the mplsLdpObjects to progress 1,2,3,6... Similarly, the LdpSessionObjects progress 1,2,4... No big deal I suppose, but it may as well be fixed. Why were the Session objects put under Peer objects? +-----------------------------------------------------------------+ Robert Schmitt CISCO SYSTEMS rschmitt@cisco.com Chelmsford, MA 978-244-3076 +----------------------------------------------------------------+ From owner-mpls@UU.NET Thu May 18 11:56: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 ESMTP id LAA09333 for ; Thu, 18 May 2000 11:56: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 QQipsp08940; Thu, 18 May 2000 15:56:32 GMT Received: by mail-control.mail.uu.net id QQipsp08718 for mpls-outgoing; Thu, 18 May 2000 15:55:48 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipsp08701 for ; Thu, 18 May 2000 15:55:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipsp23840 for ; Thu, 18 May 2000 11:55:23 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQipsp07174 for ; Thu, 18 May 2000 15:55:22 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA09838; Thu, 18 May 2000 08:55:23 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id IAA10774; Thu, 18 May 2000 08:55:22 -0700 (PDT) Date: Thu, 18 May 2000 08:55:22 -0700 (PDT) Message-Id: <200005181555.IAA10774@cirrus.juniper.net> From: Dave Katz To: rbush@bainbridge.verio.net CC: mpls@UU.NET In-reply-to: (message from Randy Bush on Thu, 18 May 2000 08:36:50 +0200) Subject: Re: MPLS and IS-IS Sender: owner-mpls@UU.NET Precedence: bulk Note that, to me, "customer" == "ISP". MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush Cc: mpls@uu.net References: <15962.000517@cisco.com> <200005180626.XAA09536@cirrus.juniper.net> Sender: Randy Bush Date: Thu, 18 May 2000 08:36:50 +0200 > However, this also is a matter of stability of ISPs' networks [read > stability of the Internet] and of things like the number of night > pages from your customer... > > And one more point---if you really care about your customer, do > you want them to change their IGP just because some ppl [that usually > come and go] feel better about the other proto? > > What I want them to do is not at issue. I would advise a customer > against making such changes willy-nilly, but I don't think there are > very many that would make such a change lightly. I'll settle for > getting enough notice so that we can help with the transition (as > opposed to "guess what, we're switching IGPs this weekend!") uh, dave. other than network stability etc, a customer should neither know nor care what igp an isp runs. no notice to customers should be relevant. until mpls/igp/te, one's igp was a trivial part of one's configuration, merely a way to help the bgp-enabled interfaces find eachother and to do some very primitive te. randy From owner-mpls@UU.NET Thu May 18 11:57: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 LAA09400 for ; Thu, 18 May 2000 11:57: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 QQipsp10697; Thu, 18 May 2000 15:57:04 GMT Received: by mail-control.mail.uu.net id QQipsp08814 for mpls-outgoing; Thu, 18 May 2000 15:56: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 QQipsp08778 for ; Thu, 18 May 2000 15:56: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 QQipsp01160 for ; Thu, 18 May 2000 11:55:35 -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 QQipsp07422 for ; Thu, 18 May 2000 15:55:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA24483 for mpls@uu.net; Thu, 18 May 2000 11:55:32 -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 QQipsp08668 for ; Thu, 18 May 2000 15: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 QQipsp08485 for ; Thu, 18 May 2000 11:55:11 -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 QQipsp07266 for ; Thu, 18 May 2000 15:55:09 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 11:55:08 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEAEF@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Rob Schmitt'" , "Cucchiara, Joan" , mpls@UU.NET Subject: RE: OID progression in LDP MIB Date: Thu, 18 May 2000 11:55:07 -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: Rob Schmitt [mailto:rschmitt@cisco.com] > Sent: Thursday, May 18, 2000 2:29 PM > To: jcucchiara@brixnet.com; mpls@UU.NET > Subject: OID progression in LDP MIB > > > > It should be noted that the OID progression in the > LDP MIB rev 05 has some holes in it. Since the > LdpSessionObjects were made into LdpPeerObjects, > it caused the mplsLdpObjects to progress 1,2,3,6... > > Similarly, the LdpSessionObjects progress 1,2,4... > > No big deal I suppose, but it may as well be fixed. Thanks, good catch. > Why were the Session objects put under Peer objects? This issue was raised during the last call. The result was to have the Session Table have an AUGMENTS relationship to the Peer table, and thus, these objects are all under the same branch (a Sessions Objects branch.) -Joan > > > +-----------------------------------------------------------------+ > Robert Schmitt CISCO SYSTEMS > rschmitt@cisco.com > Chelmsford, MA 978-244-3076 > +----------------------------------------------------------------+ > > From owner-mpls@UU.NET Thu May 18 14:16: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 OAA11593 for ; Thu, 18 May 2000 14:16: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 QQipsz03578; Thu, 18 May 2000 18:16:04 GMT Received: by mail-control.mail.uu.net id QQipsz12940 for mpls-outgoing; Thu, 18 May 2000 18:15:28 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipsz12935 for ; Thu, 18 May 2000 18:15:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipsz14281 for ; Thu, 18 May 2000 14:15:09 -0400 (EDT) Received: from postal.redback.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQipsz02822 for ; Thu, 18 May 2000 18:15:08 GMT Received: from tradrat.redback.com (tradrat.redback.com [155.53.36.49]) by postal.redback.com (Postfix) with ESMTP id 6101E2AA19; Thu, 18 May 2000 11:15:08 -0700 (PDT) Received: (from tor@localhost) by tradrat.redback.com (8.8.8/8.8.8/null redback bsdclient) id LAA11006; Thu, 18 May 2000 11:15:08 -0700 (PDT) Date: Thu, 18 May 2000 11:15:08 -0700 From: Rene Tio To: Jessica Yu Cc: mpls@UU.NET Subject: Re: MPLS and IS-IS Message-ID: <20000518111508.B10618@redback.com> References: <20000518140805.6335.qmail@web3001.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000518140805.6335.qmail@web3001.mail.yahoo.com>; from jyy_99@yahoo.com on Thu, May 18, 2000 at 07:08:05AM -0700 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, May 18, 2000 at 07:08:05AM -0700, Jessica Yu wrote: [...] > Every router vendor has to split already thin software > development resource to develop and/or maintain both > IGP protocols. As a result, instead of having a fully > cooked IGP, they may have two half-cooked ones. > ...... > > Lots lots energy, resource and brain power can be > saved. > > So the question is - > > Is there any value to continue supporting 2 different > IGP protocols which essentially serve the same purpose > (especially the need for supporting CLNS does not > exist) and there is no obvious advantages associated > with one over the other ? [...] Anyone who thinks that any single protocol can (a) be fully cooked or (b) take care of the entire world's needs really needs to re-think. Gee, why not just build a sedan, forget about SUVs, vans, or sports cars. Nothing wrong with a friendly OSPF / IS-IS debate. Vive la difference. R. From owner-mpls@UU.NET Thu May 18 15: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 ESMTP id PAA12390 for ; Thu, 18 May 2000 15: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 QQiptf16513; Thu, 18 May 2000 19:51:44 GMT Received: by mail-control.mail.uu.net id QQiptf27842 for mpls-outgoing; Thu, 18 May 2000 19:51:23 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiptf27829 for ; Thu, 18 May 2000 19:51:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiptf26120 for ; Thu, 18 May 2000 15:51: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 QQiptf15990 for ; Thu, 18 May 2000 19:51:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA01534 for mpls@uu.net; Thu, 18 May 2000 15:51:09 -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 QQiptf27623 for ; Thu, 18 May 2000 19:50: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 QQiptf04886 for ; Thu, 18 May 2000 15:50:13 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiptf15285 for ; Thu, 18 May 2000 19:50:13 GMT Received: from dhcp-sjc16-59.cisco.com (dhcp-sjc16-59.cisco.com [171.70.96.59]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA29910; Thu, 18 May 2000 12:49:41 -0700 (PDT) Date: Thu, 18 May 2000 12:45:48 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <11531.000518@cisco.com> To: Quaizar Vohra CC: "J. Noel Chiappa" , mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: <14627.44242.875167.230651@fuinar.juniper.net> References: <14627.44242.875167.230651@fuinar.juniper.net> 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 Thursday, May 18, 2000, 2:12 AM, Quaizar Vohra wrote: > > > 3) ISIS allows breaking of a large LSP into MTU sized chunks, > > > while OSPF depends on IP fragmentation. If one fragment is lost > > > you end up transmitting only that fragment in ISIS. In OSPF you end > > > up trasnsmitting an entire LSA. > > > > 1. OSPF RFC *discourages* origination of big LSAs. They can be used, > > but if the implementation is clueful enough, it is not necessary > > [unless you have a really large number of neighbors or stub hosts, > > but even then you can do some tricks] > OSPF does certainly mention breaking OSPF packet types likely to be > large into several seperate protocol packets. But I certainly dont > know of a way of breaking an LSA itself. Specially if router LSAs are > large. Nothing that the standard would speak about, but if you ever need to announce a large number of adjacencies, there are some methods [just off-topic a bit]. > If you are refering to A.1 in rfc 2328 then this is what I > interpret. > I should have added that 3) is true only in the router LSA context. correct > An OSPF router LSA can be larger than the link MTU and hence would > fit one single LS update paclet and would need IP fragmentation. The question is when would it be so large. Is it a good network design when a router has over 100 neighbors in the same area [note that we're not talking about LANs]? > Yes I agree that an ISIS LSP can be much larger as it contains all > the other TLVs, just not the IS Reachability TLV. But loosing > an LSP fragment is not worse than loosing an OSPF LS update > packet with all its different LSAs, as you would end up loosing > all the LSAs in the packet. The standard does not specify how many LSAs you should put into a single LSU. It's up to the implementers to choose between OSPF packet header overhead and possible retransmission overhead. > But the issue I was raising was that if a router LSA is larger than > the link mtu, it will fit a single update packet which will be IP > fragmented. If one IP frag is lost, you end up retrasmitting the > entire LSA. While in case of ISIS the corresponding IS Reachability > TLVs will span several LSP fragments. If one is lost, you just need > to retranmit that single LSP fragment. This is correct, but again---when would you have a big router-LSA? > Afterall this might not be so important if your topology doesnot > have a large degree of connectivity, e.g. in an ATM overlay model. Exactly for OSPF :) For ISIS you still have that limited number of LSP frags possibly leading to bigger size of each fragment :) > > 3. We do not retransmit LSAs in OSPF, we send LS Update packets > that > The unit of retransmission is an LSA not an LS update packet. Yes > if an LS update packet is lost, all its constituent LSAs will need > retrasmitting. So is the case of LSP fragment. Yeah, I should've said we drop LS Update packet and retransmit several [1 or more] LSAs in another LSU packet. Alex. From owner-mpls@UU.NET Thu May 18 16:13: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 ESMTP id QAA12674 for ; Thu, 18 May 2000 16:13: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 QQiptg02439; Thu, 18 May 2000 20:13:22 GMT Received: by mail-control.mail.uu.net id QQiptg08399 for mpls-outgoing; Thu, 18 May 2000 20:12: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 QQiptg08394 for ; Thu, 18 May 2000 20:12: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 QQiptg21032 for ; Thu, 18 May 2000 16:12:28 -0400 (EDT) Received: from hawk.crescentnets.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.177.194.54]) id QQiptg01703 for ; Thu, 18 May 2000 20:12:27 GMT Received: from crescentnets.com (langille.in.crescentnets.com [192.168.29.105]) by hawk.crescentnets.com (8.9.3/8.9.3) with ESMTP id QAA14260; Thu, 18 May 2000 16:12:17 -0400 (EDT) Message-ID: <39244F2F.88D9105F@crescentnets.com> Date: Thu, 18 May 2000 16:14:39 -0400 From: Paul Langille Organization: Crescent Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cheenu Srinivasan CC: "'Adrian Farrel'" , "'mpls@uu.net'" , "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" Subject: Re: MPLS TE MIB - Doubts References: Content-Type: multipart/alternative; boundary="------------4185DB6531D01632C4436599" Sender: owner-mpls@UU.NET Precedence: bulk --------------4185DB6531D01632C4436599 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Cheenu, Arun, and Tom. Cheenu Srinivasan wrote: > > > Adrian, > > Please see our comments to the questions you sent some time back about > > the TE MIB. (Your questions are in black.) > (A bunch of stuff removed) > > > > 6. MPLS Tunnel Resource Table > This table is a welcome addition. > I believe you need to be very careful because of the differences > between forward and reverse resource reservation. For example, > for an RSVP tunnel, what is configured here must be the TSpec. > Clearly, sharing TSpecs is useful from a configuration point of > view, but says nothing about sharing of resources which is > determined elsewhere in the network. Is it your intention that > this table is updated on the reverse path? > > - tunnels are unidirectional; so the issue of bidirectional > resource reservation does not arise I am confused by the "tunnels are unidirectional" statement. (The mplsTunnelDirection object specifies bi-directional as an option ("in-out(3)"). Am I missing some basic concept? Did you mean to say that the Resource Tunnel is unidirectional in nature? This is the way I interpreted the Resource Table so I have the same concerns as Adrian in that I am curious about the reverse path. Thanks Paul > > - these objects are information provided by the one who wants > to > set up the tunnels to the signaling protocol (if > signaled); > how the signaling proto uses them is their business > - note: We shd add an OID pointer (as we did in the LSR MIB) > which > can be used to point at either the resource table in > the MIB, > or your own extension. > > Thanks, > > Cheenu, Arun, Tom > -- Paul Langille e-mail: langille@crescentnets.com Crescent Networks phone: (978) 244-9002 x244 201 Riverneck Road fax: (978) 244-9211 Chelmsford, MA 01824 --------------4185DB6531D01632C4436599 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
    Hi Cheenu, Arun, and Tom.

Cheenu Srinivasan wrote:

 

Adrian,

Please see our comments to the questions you sent some time back about
the TE MIB. (Your questions are in black.)
 

(A bunch of stuff removed)
 
 

6. MPLS Tunnel Resource Table
   This table is a welcome addition.
   I believe you need to be very careful because of the differences
   between forward and reverse resource reservation.  For example,
   for an RSVP tunnel, what is configured here must be the TSpec.
   Clearly, sharing TSpecs is useful from a configuration point of
   view, but says nothing about sharing of resources which is
   determined elsewhere in the network.  Is it your intention that
   this table is updated on the reverse path?

        - tunnels are unidirectional; so the issue of bidirectional
                resource reservation does not arise

I am confused by the "tunnels are unidirectional" statement. (The mplsTunnelDirection object specifies bi-directional as an option ("in-out(3)"). Am I missing some basic concept?
Did you mean to say that the Resource Tunnel is unidirectional in nature? This is the way I interpreted the Resource Table so I have the same concerns as Adrian in that I am curious about the reverse path.

    Thanks Paul

 
        - these objects are information provided by the one who wants to
                set up the tunnels to the signaling protocol (if signaled);
                how the signaling proto uses them is their business
        - note: We shd add an OID pointer (as we did in the LSR MIB) which
                can be used to point at either the resource table in the MIB,
                or your own extension.

Thanks,

Cheenu, Arun, Tom
 

--
Paul Langille                e-mail: langille@crescentnets.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824
  --------------4185DB6531D01632C4436599-- From owner-mpls@UU.NET Thu May 18 16: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 ESMTP id QAA12731 for ; Thu, 18 May 2000 16: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 QQipth07830; Thu, 18 May 2000 20:20:20 GMT Received: by mail-control.mail.uu.net id QQipth09382 for mpls-outgoing; Thu, 18 May 2000 20:20:01 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipth09361 for ; Thu, 18 May 2000 20:19:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipth29493 for ; Thu, 18 May 2000 16:19:46 -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 QQipth07246 for ; Thu, 18 May 2000 20:19:43 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 NAA15232 for ; Thu, 18 May 2000 13:19:25 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA24012 for mpls@uu.net; Thu, 18 May 2000 16:19:14 -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 QQipth09205 for ; Thu, 18 May 2000 20:17: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 QQipth08287; Thu, 18 May 2000 16:17:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQipth05452; Thu, 18 May 2000 20:17:33 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 QAA07415; Thu, 18 May 2000 16:17:18 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17046; Thu, 18 May 2000 16:17:16 -0400 (EDT) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 16:11:13 -0400 Message-ID: From: "Proch, Daniel" To: "'Gabor Korossy (ETH)'" , mpls@UU.NET, "'isis-wg@juniper.net'" , "'te-wg@uu.net'" Subject: RE: [Isis-wg] RE: MPLS and IS-IS Date: Thu, 18 May 2000 16:17:08 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA12731 Gabor, http://202.38.127.18/res/www.ietf.org/internet-drafts/draft-ietf-isis-traffi c-01.txt If that link is broke, I will send it to you. ======================== Daniel Proch Marconi Communications ======================== -----Original Message----- From: Gabor Korossy (ETH) [mailto:ethkkg@etxb.ericsson.se] Sent: Thursday, May 18, 2000 4:20 AM To: mpls@UU.NET; 'isis-wg@juniper.net'; 'te-wg@uu.net' Subject: [Isis-wg] RE: MPLS and IS-IS Hi, if I may repeat, could anyone help me please, find the draft "IS-IS extensions for Traffic Engineering," draft-ietf-isis-traffic-01.txt If so many ISPs run IS-IS with MPLS TE extensions shouldn't it become an IETF standard? Maybe one of the MPLS, TE and IS-IS working groups doesn´t feel ashamed to adopt this child? regards - Gabor >> -----Original Message----- >> From: Chris.Flores@broadwing.com [mailto:Chris.Flores@broadwing.com] >> Sent: Wednesday, May 17, 2000 8:48 PM >> To: mpls@UU.NET >> Subject: FW: MPLS and IS-IS >> >> >> >> David - >> >> Most large ISPs in the US use ISIS: >> >> UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. >> >> It also seems like more and more european ISPs are starting >> to use ISIS: >> EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. >> >> Chris >> >> -----Original Message----- >> From: David Wang [mailto:david.wang@metro-optix.com] >> Sent: Wednesday, May 17, 2000 12:36 PM >> To: 'HANSEN CHAN'; mpls@UU.NET >> Subject: RE: MPLS and IS-IS >> >> >> Hi all, >> >> IS-IS is defined to work with CLNP not for IP originally. >> Until today a lot >> of SONET and telecommunication equipment vendors still use >> IS-IS to route >> CLNP packets through the SONET Data communication >> channel(DCC) to carry >> management information and there is a great pressure to >> change this to OSPF >> and IP. I also know that UUNET runs IS-IS on their network. >> I never heard >> any other networks run IS-IS. Seems I am wrong. My questions are. >> >> 1. You guys are talking about using IS-IS in a IP networks >> not in CLNP >> networks. The IS-IS has been modified according to RFC 1195 >> (Use of OSI >> IS-IS for Routing in TCP/IP and Dual Environments) or some >> other standard. >> Is this correct? >> >> 2. Besides UUNET, which ISPs run IS-IS protocol? Can you >> name a few? or >> what percentage of networks run IS-IS instead of OSPF? >> >> Thanks >> David >> >> >> -----Original Message----- >> From: HANSEN CHAN [mailto:hchan@newbridge.com] >> Sent: Tuesday, May 16, 2000 7:22 AM >> To: mpls@UU.NET >> Subject: MPLS and IS-IS >> >> >> Hi all, >> >> I have been hearing IS-IS is a better protocol to be used >> than OSPF in a >> MPLS >> network for TE application. Is that a fair statement? What >> are the technical >> reasons? >> >> Appreciate if someone can shed some light on this subject. >> >> Thanks, >> Hansen >> >> _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From owner-mpls@UU.NET Thu May 18 16:24:22 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 QAA12752 for ; Thu, 18 May 2000 16:24: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 QQipth10234; Thu, 18 May 2000 20:23:35 GMT Received: by mail-control.mail.uu.net id QQipth09649 for mpls-outgoing; Thu, 18 May 2000 20:23:01 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipth09634 for ; Thu, 18 May 2000 20:22:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipth29931 for ; Thu, 18 May 2000 16:22:27 -0400 (EDT) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQipth09348 for ; Thu, 18 May 2000 20:22:26 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 21:22:21 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E140AA5@monk.datcon.co.uk> From: Adrian Farrel To: Cheenu Srinivasan Cc: "'mpls@uu.net'" , "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" Subject: RE: MPLS TE MIB - Doubts Date: Thu, 18 May 2000 21:22:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC106.C4F0FFDA" 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_01BFC106.C4F0FFDA Content-Type: text/plain; charset="iso-8859-1" Thanks Cheenu, Arun and Tom. Good stuff. Some responses (which appear to be in green for those following the thread in html) Adrian, Please see our comments to the questions you sent some time back about the TE MIB. (Your questions are in black.) - blue? 3. LSPId explicit hop type Is there any reason to prevent configuration of an explicit hop of type LSPId? I suggested some ASN.1 for this in an email to Tom on 7th Jan. If ldp is chosen to route the tunnel then we'll add this as a choice for the hop type. I'm not quite sure what your answer means. I think you're saying you'll add the hop type but only allow it if the signaling protocol is flagged as [CR-]LDP. This would be great. 6. MPLS Tunnel Resource Table This table is a welcome addition. I believe you need to be very careful because of the differences between forward and reverse resource reservation. For example, for an RSVP tunnel, what is configured here must be the TSpec. Clearly, sharing TSpecs is useful from a configuration point of view, but says nothing about sharing of resources which is determined elsewhere in the network. Is it your intention that this table is updated on the reverse path? - tunnels are unidirectional; so the issue of bidirectional resource reservation does not arise It wasn't my intention to talk about bi-directional LSPs at this point (although that is an interesting topic of conversation in this regard). When I talk about forward and reverse reservation I am simply distinguishing between CR-LDP where the resources are reserved as the Label_Request traverses the network, and RSVP where the resources are (strictly speaking) only reserved when the Resv travels back. Thus the information in the MIB row is far more likely to reflect the true reservation in CR-LDP than in RSVP unless the table is updated by the protocol code on completion of LSP setup to reflect the flowspec. - these objects are information provided by the one who wants to set up the tunnels to the signaling protocol (if signaled); how the signaling proto uses them is their business Well, true, but... We normally give some guidance on the effect that the user can expect to see when they set a certain set of values. - note: We shd add an OID pointer (as we did in the LSR MIB) which can be used to point at either the resource table in the MIB, or your own extension. That would be a good idea. 7. MplsTunnelIndex Although current MPLS tunnels signaling protocols only support 16 bits to identify a tunnel from a specific ingress, it may be that some future protocol will allow a greater number of tunnels. Would it be wise to prepare for this by allowing MplsTunnelIndex to have a greater range? We cannot. We can only support what is specified in the protocols doc. I think you could (you already support some things that one of RSVP or CR-LDP don't support). I'm happy with you deciding that you don't see the need at the moment. 8. Cookies These are defined as read-only. Do we need write access to configure them for bi-directional tunnels? Yes; make them writeable (or throw them out all together) Right! So which way do we jump? There is currently some interesting work going on in the field of bi-directional tunnels, but I'd suggest that in the short term cookies do provide a useful hook on which to hang b-directionality. 9. mplsTunnelHopTable This is currently indexed by mplsTunnelIndex. Does this mean that different instances of a tunnel as defined by mplsTunnelInstance cannot have different routes? If you add mplsTunnelInstance as an index to the HopTable, it means that each instance must have its own ER defined and cannot share the definition for all instances of the same LSP. Would could change the indexing of the hop table to include a (hopListIndex, TunnelHopIndex) to allow the two or more tunnelEntries to point to the same hopListEntry. We could then point the tunnelTable to the new primary index. We also need to make sure that the TunnelEntry has a poitner to the tunnelARHopPtr so that the actual route (RRO) can be know. That sounds good. 15. mplsTunnelXCIndex It would be good to expand on the Description. Explain that this object is only writeable in conjunction with pre-existing entries in the LSR MIB. Say that in normal signaled operation this object will be set by the LSR. Explain the meaning of zero. We'll see how to improve the description. How about... "This variable represents an index into the mplsXCTable. This table identifies the segments that compose this tunnel, their characteristics, and relationships to each other. In the case where a signaling protocol is used to set up the tunnel, this field is set by the MPLS code to reflect the row in the mplsXCTable that has been set up to describe the cross- connect for this LSP and SHOULD NOT be changed. In the case where the tunnel has been statically configured by writing to the tables in the LSR MIB, this field MUST be set to indicate the correct entry in the mplsXCTable." Typographic mplsTunnelResourceInMaxRate etc. MplsBitRate is defined in the LSR MIB in 1,000 bits per second. The descriptions for these fields need updating. Additionally, the UNITS tag is ood. What do you mean by this sentence ("ood")? Sorry. ood = out of date. In other words, all of the UNITS definitions say "bits per second" and should say "1,000s of bits per second". 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 ------_=_NextPart_001_01BFC106.C4F0FFDA Content-Type: text/html; charset="iso-8859-1" RE: MPLS TE MIB - Doubts

Thanks Cheenu, Arun and Tom.
Good stuff.  Some responses (which appear to be in green for those following the thread in html)

Adrian,

Please see our comments to the questions you sent some time back about
the TE MIB. (Your questions are in black.)  - blue?

3. LSPId explicit hop type
   Is there any reason to prevent configuration of an explicit hop
   of type LSPId?  I suggested some ASN.1 for this in an email to
   Tom on 7th Jan.

        If ldp is chosen to route the tunnel then we'll add this as
        a choice for the hop type.

I'm not quite sure what your answer means.  I think you're saying you'll add the hop type but only allow it if the signaling protocol is flagged as [CR-]LDP.  This would be great.

6. MPLS Tunnel Resource Table
   This table is a welcome addition.
   I believe you need to be very careful because of the differences
   between forward and reverse resource reservation.  For example,
   for an RSVP tunnel, what is configured here must be the TSpec. 
   Clearly, sharing TSpecs is useful from a configuration point of
   view, but says nothing about sharing of resources which is
   determined elsewhere in the network.  Is it your intention that
   this table is updated on the reverse path?

        - tunnels are unidirectional; so the issue of bidirectional    
                resource reservation does not arise 
It wasn't my intention to talk about bi-directional LSPs at this point (although that is an interesting topic of conversation in this regard).  When I talk about forward and reverse reservation I am simply distinguishing between CR-LDP where the resources are reserved as the Label_Request traverses the network, and RSVP where the resources are (strictly speaking) only reserved when the Resv travels back.  Thus the information in the MIB row is far more likely to reflect the true reservation in CR-LDP than in RSVP unless the table is updated by the protocol code on completion of LSP setup to reflect the flowspec.
        - these objects are information provided by the one who wants to
                set up the tunnels to the signaling protocol (if signaled);
                how the signaling proto uses them is their business 
Well, true, but...
We normally give some guidance on the effect that the user can expect to see when they set a certain set of values.
        - note: We shd add an OID pointer (as we did in the LSR MIB) which
                can be used to point at either the resource table in the MIB,
                or your own extension. 
That would be a good idea.

7. MplsTunnelIndex
   Although current MPLS tunnels signaling protocols only support
   16 bits to identify a tunnel from a specific ingress, it may be
   that some future protocol will allow a greater number of tunnels.
   Would it be wise to prepare for this by allowing MplsTunnelIndex
   to have a greater range?

        We cannot. We can only support what is specified in the
        protocols doc. 
I think you could (you already support some things that one of RSVP or CR-LDP don't support).
I'm happy with you deciding that you don't see the need at the moment.

8. Cookies
   These are defined as read-only. Do we need write access to
   configure them for bi-directional tunnels?

        Yes; make them writeable (or throw them out all together) 
Right!
So which way do we jump?  There is currently some interesting work going on in the field of bi-directional tunnels, but I'd suggest that in the short term cookies do provide a useful hook on which to hang b-directionality.

9. mplsTunnelHopTable
   This is currently indexed by mplsTunnelIndex.  Does this mean that
   different instances of a tunnel as defined by mplsTunnelInstance
   cannot have different routes? 
    If you add mplsTunnelInstance as an index to the HopTable, it means
   that each instance must have its own ER defined and cannot share the
   definition for all instances of the same LSP.

        Would could change the indexing of the hop table
        to include a (hopListIndex, TunnelHopIndex) to allow the two
        or more tunnelEntries to point to the same hopListEntry. We
        could then point the tunnelTable to the new primary index. We
        also need to make sure that the TunnelEntry has a poitner to the
        tunnelARHopPtr so that the actual route (RRO) can be know. 
That sounds good. 

15. mplsTunnelXCIndex
   It would be good to expand on the Description.  Explain that this
   object is only writeable in conjunction with pre-existing entries
   in the LSR MIB.  Say that in normal signaled operation this object
   will be set by the LSR.  Explain the meaning of zero.

        We'll see how to improve the description. 
How about...
       "This variable represents an index into the
        mplsXCTable. This table identifies the segments
        that compose this tunnel, their characteristics,
        and relationships to each other. 
        In the case where a signaling protocol is used
        to set up the tunnel, this field is set by the
        MPLS code to reflect the row in the mplsXCTable
        that has been set up to describe the cross-
        connect for this LSP and SHOULD NOT be changed.
        In the case where the tunnel has been statically
        configured by writing to the tables in the LSR
        MIB, this field MUST be set to indicate the
        correct entry in the mplsXCTable."

Typographic

mplsTunnelResourceInMaxRate etc.
MplsBitRate is defined in the LSR MIB in 1,000 bits per second.
The descriptions for these fields need updating.  Additionally,
the UNITS tag is ood.

        What do you mean by this sentence ("ood")? 
Sorry.  ood = out of date.
In other words, all of the UNITS definitions say "bits per second" and should say "1,000s of bits per second".

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

------_=_NextPart_001_01BFC106.C4F0FFDA-- From owner-mpls@UU.NET Thu May 18 23:46: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 XAA18426 for ; Thu, 18 May 2000 23:46: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 QQipul19838; Fri, 19 May 2000 03:45:55 GMT Received: by mail-control.mail.uu.net id QQipul10752 for mpls-outgoing; Fri, 19 May 2000 03:45:39 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipul10746 for ; Fri, 19 May 2000 03:45:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipul16254 for ; Thu, 18 May 2000 23:45:29 -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 QQipul16802 for ; Fri, 19 May 2000 03:45:29 GMT Received: from localhost (hsong@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id XAA01966; Thu, 18 May 2000 23:45:24 -0400 (EDT) Date: Thu, 18 May 2000 23:45:24 -0400 (EDT) From: Haoxin Song To: HANSEN CHAN cc: mpls@UU.NET Subject: Re: MPLS and IS-IS In-Reply-To: <39213D6D.10AAFFC3@newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk hi there, Although both OSPF and ISIS meet basic IGP requirements to support TE over MPLS, there are some basic differences in their features which I think might be causing ISPs to change from OSPF to ISIS. 1. the method of fragmentation of LSPs are different. ISIS divides all the Link_state information into MTUs which could be sent independently. In OSPF, fragmentation is first made based on different type of information, but as the number of neighbors increases, it's quite possible that the fragmented LSAs still exceeds MTU, so OSPF will further divide it by creating one LSP for each destination. This will make OSPF to transmit much more LSAs than ISIS to advertise same information. Since each LSP need a packet header, more LSPs will mean more overhead which make OSPF less scalable. 2. Both protocol support two level hierarchy, but ISIS level 1 router flood only information about its own area while OSPF level 1 router floods also information about level two. This is also a reason OSPF will need more bandwidth for advertising. Although there are some methods to solve the scalable problem, that will introduce more complexity. cheers, Larry On Tue, 16 May 2000, HANSEN CHAN wrote: > Hi all, > > I have been hearing IS-IS is a better protocol to be used than OSPF in a MPLS > network for TE application. Is that a fair statement? What are the technical > reasons? > > Appreciate if someone can shed some light on this subject. > > Thanks, > Hansen > > From owner-mpls@UU.NET Fri May 19 02:13: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 ESMTP id CAA01074 for ; Fri, 19 May 2000 02:13: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 QQipuu18487; Fri, 19 May 2000 06:11:48 GMT Received: by mail-control.mail.uu.net id QQipuu15237 for mpls-outgoing; Fri, 19 May 2000 06:11:34 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipuu15232 for ; Fri, 19 May 2000 06:11:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipuu27009 for ; Fri, 19 May 2000 02:11:19 -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 QQipuu18043 for ; Fri, 19 May 2000 06:11:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA21090 for mpls@uu.net; Fri, 19 May 2000 02:11:18 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipuu15112 for ; Fri, 19 May 2000 06:10:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipuu26970 for ; Fri, 19 May 2000 02:10:40 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQipuu14222 for ; Fri, 19 May 2000 06:10:37 GMT Received: from sj-dial-2-78.cisco.com (sj-dial-2-78.cisco.com [10.19.226.79]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA13981; Thu, 18 May 2000 23:09:57 -0700 (PDT) Date: Thu, 18 May 2000 23:06:00 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <8962.000518@cisco.com> To: Haoxin Song CC: HANSEN CHAN , mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: References: 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 > 1. the method of fragmentation of LSPs are different. ISIS divides all the > Link_state information into MTUs which could be sent independently. In > OSPF, fragmentation is first made based on different type of information, > but as the number of neighbors increases, it's quite possible that the > fragmented LSAs still exceeds MTU, We do not fragment LSAs. > so OSPF will further divide it by > creating one LSP for each destination. We also do not divide LSAs into LSPs [in fact, we don't have LSPs in OSPF at all]. Enabling error correction produces somewhat like "OSPF will create a separate LSA for each external prefix"? Is this what you mean? > This will make OSPF to transmit > much more LSAs than ISIS to advertise same information. Since each LSP > need a packet header, Seems to be you're still making a difference between LSAs and LSPs. What do you mean by LSP in OSPF? As far as the number of LSAs vs number of ISIS LSP fragments is concerned, this is always a choice between possibility to put more info within one PDU (read "put more TLVs into one LSP") vs necessity to reoriginate and reflood the whole PDU when one item changes. > more LSPs will mean more overhead which make OSPF > less scalable. Easy to say, isn't it? An example to you: you have an ISIS LSP fragment fitting 1500b MTU, full of internal adjacency info and a couple of external routes, and you have an OSPF router-LSA carrying adj. info and two ASE-LSAs carrying external routes. Now suppose your external route starts flapping, which protocol will consume more bandwidth? Now change external routing info to TE info... See what I mean? Again, my point is not that ISIS is worse and OSPF is better or the other way. My point is that you cannot make such an "easy" conclusion that one proto is less scalable than the other. Both protos have pros and cons. > 2. Both protocol support two level hierarchy, but ISIS level 1 router > flood only information about its own area while OSPF level 1 router > floods also information about level two. This is also a reason OSPF will > need more bandwidth for advertising. Although there are some methods to > solve the scalable problem, that will introduce more complexity. I would recommend reading RFC2328, specifically the part about stub areas. I'd also recommend reading drafts about L2-to-L1 route leaking in ISIS. Cheers, Alex. > cheers, > Larry From owner-mpls@UU.NET Fri May 19 07:25: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 HAA03018 for ; Fri, 19 May 2000 07:25: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 QQipvp24791; Fri, 19 May 2000 11:23:34 GMT Received: by mail-control.mail.uu.net id QQipvp17959 for mpls-outgoing; Fri, 19 May 2000 11:22: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 QQipvp17952 for ; Fri, 19 May 2000 11:22:49 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 QQipvp21464 for ; Fri, 19 May 2000 07:22:45 -0400 (EDT) Received: from web3004.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web3004.mail.yahoo.com [204.71.202.167]) id QQipvp24195 for ; Fri, 19 May 2000 11:22:44 GMT Received: (qmail 27395 invoked by uid 60001); 19 May 2000 11:22:44 -0000 Message-ID: <20000519112244.27394.qmail@web3004.mail.yahoo.com> Received: from [141.212.130.253] by web3004.mail.yahoo.com; Fri, 19 May 2000 04:22:44 PDT Date: Fri, 19 May 2000 04:22:44 -0700 (PDT) From: Jessica Yu Subject: Re: MPLS and IS-IS To: Rene Tio Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Just use your example. Compare to sedan, SUV has higher clearance, more leg room and advantage when collision happens. SUVs also consume more gas, pollute more, etc. Does IS-IS and OSPF have such clear differences in terms of function and performance? All the discussion happens year after year pretty much concluded that the two has little differences (except quality of implementation difference). So supporting both does not gain more but consumes more resources. In terms of the benefit of having one protocol vs two very similar ones or whether one is enough. Just think about the case of BGP. There used to be BGP and IDRP. The two have very similar function and mechanism. IDRP supports dual mode (sounds familiar?) Just having BGP works just as well as having both and maybe better given vendors do not need to spread thin development resource to take care of both. There is nothing wrong to discuss the difference. But when the content just repeats time after time, it makes you wonder if we have better things to do. --Jessica --- Rene Tio wrote: > On Thu, May 18, 2000 at 07:08:05AM -0700, Jessica Yu > wrote: > [...] > > Every router vendor has to split already thin > software > > development resource to develop and/or maintain > both > > IGP protocols. As a result, instead of having a > fully > > cooked IGP, they may have two half-cooked ones. > > > ...... > > > > Lots lots energy, resource and brain power can be > > saved. > > > > So the question is - > > > > Is there any value to continue supporting 2 > different > > IGP protocols which essentially serve the same > purpose > > (especially the need for supporting CLNS does not > > exist) and there is no obvious advantages > associated > > with one over the other ? > [...] > > Anyone who thinks that any single protocol can (a) > be fully cooked or (b) > take care of the entire world's needs really needs > to re-think. Gee, why > not just build a sedan, forget about SUVs, vans, or > sports cars. > > Nothing wrong with a friendly OSPF / IS-IS debate. > Vive la difference. > > R. > __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Fri May 19 08: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 IAA04439 for ; Fri, 19 May 2000 08: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 QQipvv23308; Fri, 19 May 2000 12:50:51 GMT Received: by mail-control.mail.uu.net id QQipvv03959 for mpls-outgoing; Fri, 19 May 2000 12:50:32 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 QQipvv03954 for ; Fri, 19 May 2000 12:50: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 QQipvv01507 for ; Fri, 19 May 2000 08:50:19 -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 QQipvv22815 for ; Fri, 19 May 2000 12:50:19 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA09396 for mpls@uu.net; Fri, 19 May 2000 08:50:18 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipvv03918 for ; Fri, 19 May 2000 12:49:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipvv28155 for ; Fri, 19 May 2000 08:49:22 -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 QQipvv20996 for ; Fri, 19 May 2000 12:49:19 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA00080; Fri, 19 May 2000 05:47:36 -0700 (PDT) Message-Id: <200005191247.FAA00080@omega.cisco.com> To: Jessica Yu cc: mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-to: Your message of "Fri, 19 May 2000 04:22:44 PDT." <20000519112244.27394.qmail@web3004.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77.958740456.1@cisco.com> Date: Fri, 19 May 2000 05:47:36 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Jessica, > Just use your example. Compare to sedan, SUV has > higher clearance, more leg room and advantage when > collision happens. SUVs also consume more gas, pollute > more, etc. Does IS-IS and OSPF have such clear > differences in terms of function and performance? All > the discussion happens year after year pretty much > concluded that the two has little differences (except > quality of implementation difference). So supporting > both does not gain more but consumes more resources. > > In terms of the benefit of having one protocol vs two > very similar ones or whether one is enough. Just think > about the case of BGP. There used to be BGP and IDRP. > The two have very similar function and mechanism. IDRP > supports dual mode (sounds familiar?) Just having BGP > works just as well as having both and maybe better > given vendors do not need to spread thin development > resource to take care of both. Just to add, as BGP evolved it included some of the functionality of IDRP (e.g., multiprotocol extensions, BGP Refresh). Yakov. From owner-mpls@UU.NET Fri May 19 11:32:22 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 LAA06746 for ; Fri, 19 May 2000 11:32: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 QQipwg09125; Fri, 19 May 2000 15:31:06 GMT Received: by mail-control.mail.uu.net id QQipwg18882 for mpls-outgoing; Fri, 19 May 2000 15:30:34 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 QQipwg18863 for ; Fri, 19 May 2000 15:30: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 QQipwg02947 for ; Fri, 19 May 2000 11:30:09 -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 QQipwg08152 for ; Fri, 19 May 2000 15:30:08 GMT Received: (qmail 4261 invoked by uid 60001); 19 May 2000 15:30:08 -0000 Message-ID: <20000519153008.4260.qmail@web3001.mail.yahoo.com> Received: from [141.212.130.253] by web3001.mail.yahoo.com; Fri, 19 May 2000 08:30:08 PDT Date: Fri, 19 May 2000 08:30:08 -0700 (PDT) From: Jessica Yu Subject: Re: MPLS and IS-IS To: Yakov Rekhter Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Yakov: That's something I wanted to point out in my previous message but forgot in the process. Thanks for mentioning it and if I can add, the concept of confederation is another feature that BGP incorporated from IDRP. Back to the basic question: If we have two protocols (X and Y) which essentially serve the same purpose and are very similar, shall we, given resource is limited, a)evolve one of them and incorporate all the good features of the other and just support one, or b)keep doing parallel work (which does not led to significant difference between the two) on both? --Jessica --- Yakov Rekhter wrote: > Jessica, > > > Just use your example. Compare to sedan, SUV has > > higher clearance, more leg room and advantage when > > collision happens. SUVs also consume more gas, > pollute > > more, etc. Does IS-IS and OSPF have such clear > > differences in terms of function and performance? > All > > the discussion happens year after year pretty much > > concluded that the two has little differences > (except > > quality of implementation difference). So > supporting > > both does not gain more but consumes more > resources. > > > > In terms of the benefit of having one protocol vs > two > > very similar ones or whether one is enough. Just > think > > about the case of BGP. There used to be BGP and > IDRP. > > The two have very similar function and mechanism. > IDRP > > supports dual mode (sounds familiar?) Just having > BGP > > works just as well as having both and maybe better > > given vendors do not need to spread thin > development > > resource to take care of both. > > Just to add, as BGP evolved it included some of the > functionality of IDRP (e.g., multiprotocol > extensions, > BGP Refresh). > > Yakov. ===== __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Fri May 19 12:04: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 ESMTP id MAA07516 for ; Fri, 19 May 2000 12:04: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 QQipwi12522; Fri, 19 May 2000 16:03:56 GMT Received: by mail-control.mail.uu.net id QQipwi25761 for mpls-outgoing; Fri, 19 May 2000 16:03: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 QQipwi25661 for ; Fri, 19 May 2000 16:03: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 QQipwi10148 for ; Fri, 19 May 2000 12:03:13 -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 QQipwi10814 for ; Fri, 19 May 2000 16:03:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA08469 for mpls@uu.net; Fri, 19 May 2000 12:03:12 -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 QQipwi24902 for ; Fri, 19 May 2000 16:02: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 QQipwi08022 for ; Fri, 19 May 2000 12:02:25 -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 QQipwi10186 for ; Fri, 19 May 2000 16:02:24 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA14834; Fri, 19 May 2000 09:02:20 -0700 (PDT) Message-Id: <200005191602.JAA14834@omega.cisco.com> To: Jessica Yu cc: mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-to: Your message of "Fri, 19 May 2000 08:30:08 PDT." <20000519153008.4260.qmail@web3001.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14831.958752140.1@cisco.com> Date: Fri, 19 May 2000 09:02:20 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Jessica, > That's something I wanted to point out in my previous > message but forgot in the process. Thanks for > mentioning it and if I can add, the concept of > confederation is another feature that BGP incorporated > from IDRP. > > Back to the basic question: > > If we have two protocols (X and Y) which essentially > serve the same purpose and are very similar, shall we, > given resource is limited, > > a)evolve one of them and incorporate all the good > features of the other and just support one, or > > b)keep doing parallel work (which does not led to > significant difference between the two) on both ? I think that router vendors would allocate resources for ISIS and OSPF based on their customers' demand for ISIS and OSPF. So, the answer to your question will be determined by customers, not by vendors. It seems that so far we've been moving along option (b). Yakov. From owner-mpls@UU.NET Fri May 19 12:16:10 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 MAA07658 for ; Fri, 19 May 2000 12:16:10 -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 QQipwj20287; Fri, 19 May 2000 16:15:12 GMT Received: by mail-control.mail.uu.net id QQipwi01661 for mpls-outgoing; Fri, 19 May 2000 16:14:37 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipwi01645 for ; Fri, 19 May 2000 16:14:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipwi00654 for ; Fri, 19 May 2000 12:14:22 -0400 (EDT) Received: from tcb.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQipwi20414 for ; Fri, 19 May 2000 16:14:22 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA05817 for ; Fri, 19 May 2000 10:15:38 -0600 Message-Id: <200005191615.KAA05817@tcb.net> To: mpls@UU.NET From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MPLS and IS-IS Date: Fri, 19 May 2000 10:15:38 -0600 Sender: owner-mpls@UU.NET Precedence: bulk > I think that router vendors would allocate resources for ISIS and OSPF > based on their customers' demand for ISIS and OSPF. So, the answer to > your question will be determined by customers, not by vendors. > > It seems that so far we've been moving along option (b). Indeed, it's all about market demand. And considering there's a huge install base for both, well, I doubt either will be retired anytime soon. Besides that, I could envision the "which one should be retired" debate going on for years, and using more resources then simply doing parallel development of both. Lastly, having intially fostered much of the beginning of this thread, I'd suggest we now retire it (at least for another year or so), we've strayed quite a ways form the mailing lists charter. -danny From owner-mpls@UU.NET Fri May 19 12: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 ESMTP id MAA07806 for ; Fri, 19 May 2000 12: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 QQipwj26068; Fri, 19 May 2000 16:21:51 GMT Received: by mail-control.mail.uu.net id QQipwj02753 for mpls-outgoing; Fri, 19 May 2000 16:21:18 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 QQipwj02634 for ; Fri, 19 May 2000 16:20:59 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 QQipwj12401 for ; Fri, 19 May 2000 12:20:49 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQipwj25160 for ; Fri, 19 May 2000 16:20:49 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id MAA19599; Fri, 19 May 2000 12:17:11 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Jessica Yu'" Cc: Subject: RE: MPLS and IS-IS Date: Fri, 19 May 2000 12:20:56 -0400 Message-ID: <000201bfc1ae$367e9980$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: <20000519153008.4260.qmail@web3001.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Back to the basic question: > > If we have two protocols (X and Y) which essentially > serve the same purpose and are very similar, shall we, > given resource is limited, > > a)evolve one of them and incorporate all the good > features of the other and just support one, or > > b)keep doing parallel work (which does not led to > significant difference between the two) on > both. Jessica, Routing is not alone where multiple standards exist for essentially the same purpose. Even though many subtle differences exist between OSPF and IS-IS as pointed out by previous mails in this thread, supporting an extra routing protocol is a far simpler problem compared to the problems in some other technology domains. Just compare this to the problem of manufacturers and/or operators of cellular systems who need to put resources in developing infrastructure components (BTS, BSCs and Switches etc.) for TDMA, GSM and CDMA which all achieve the "similar purpose" (with only marginal differences in channel utilization and/or quality of voice). The parallel evolution is not such a bad thing as at some point the natural factors will decide whether IS-IS or OSPF survives, or they both get replaced by a single unified specification. Cheers, --brijesh Ennovate Networks Inc. From owner-mpls@UU.NET Fri May 19 23:48: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 ESMTP id XAA15327 for ; Fri, 19 May 2000 23:48: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 QQipyd27253; Sat, 20 May 2000 03:47:14 GMT Received: by mail-control.mail.uu.net id QQipyd02968 for mpls-outgoing; Sat, 20 May 2000 03:46: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 QQipyd02963 for ; Sat, 20 May 2000 03:46: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 QQipyd29922 for ; Fri, 19 May 2000 23:46:42 -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 QQipyd06954 for ; Sat, 20 May 2000 03:46:42 GMT Received: from localhost (hsong@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id XAA30163; Fri, 19 May 2000 23:46:32 -0400 (EDT) Date: Fri, 19 May 2000 23:46:31 -0400 (EDT) From: Haoxin Song To: Alex Zinin cc: HANSEN CHAN , mpls@UU.NET Subject: Re: MPLS and IS-IS In-Reply-To: <8962.000518@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 18 May 2000, Alex Zinin wrote: > > 1. the method of fragmentation of LSPs are different. ISIS divides all the > > Link_state information into MTUs which could be sent independently. In > > OSPF, fragmentation is first made based on different type of information, > > but as the number of neighbors increases, it's quite possible that the > > fragmented LSAs still exceeds MTU, > > We do not fragment LSAs. > > > so OSPF will further divide it by > > creating one LSP for each destination. > > We also do not divide LSAs into LSPs [in fact, we don't have LSPs in > OSPF at all]. I am sorry that I may have introduced some confusions in last mail dy using the terms of LSP, LSA and fragmentation. OK, let's put it this way, both protocol need a method to split information, which need to be advertised, into meaningful smaller pieces (in ISIS, LSP fragments; in OSPF, LSAs) so that each of them could be forwarded independently. Otherwise, during transmission, it will have to relay on conventional fragmentation/reassembly (in OSPF, IP fragmentation), which will make the packets have to wait to be reassembled at each hop. The overhead I mensioned in last mail comes from the different method of this spliting. Does that make sense now? > > Enabling error correction produces somewhat like "OSPF will create > a separate LSA for each external prefix"? Is this what you mean? As described above, OSPF split the whole information into smaller pieces based first on defferent types, if the smaller pieces is still too large to be fitted in one IP packet, it will further divide it by different neighbors and make each of them a LSAs. > > This will make OSPF to transmit > > much more LSAs than ISIS to advertise same information. Since each LSP > > need a packet header, > > As far as the number of LSAs vs number of ISIS LSP fragments is > concerned, this is always a choice between possibility to put more > info within one PDU (read "put more TLVs into one LSP") vs necessity > to reoriginate and reflood the whole PDU when one item changes. > > > more LSPs will mean more overhead which make OSPF > > less scalable. > > Again, my point is not that ISIS is worse and OSPF is better > or the other way. My point is that you cannot make such an "easy" > conclusion that one proto is less scalable than the other. > Both protos have pros and cons. Yes, I agree with you. I was not tring to make any conclusion that in general one is better than the other. What I was tring to point out is just some differents of the two protocols which could be one of the reasons ISPs make their decision. > I would recommend reading RFC2328, specifically the part about stub > areas. I'd also recommend reading drafts about L2-to-L1 route leaking > in ISIS. Thanks for reconmmending, I will. Regards, Larry From owner-mpls@UU.NET Sat May 20 02:03: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 ESMTP id CAA25688 for ; Sat, 20 May 2000 02:03: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 QQipym15005; Sat, 20 May 2000 06:02:00 GMT Received: by mail-control.mail.uu.net id QQipym03040 for mpls-outgoing; Sat, 20 May 2000 06:01: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 QQipym03033 for ; Sat, 20 May 2000 06:01: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 QQipym10815 for ; Sat, 20 May 2000 02:01: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 QQipym18999 for ; Sat, 20 May 2000 06:01:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA24658 for mpls@uu.net; Sat, 20 May 2000 02:01: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 QQipym01522 for ; Sat, 20 May 2000 06:00: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 QQipym10790 for ; Sat, 20 May 2000 02:00:46 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQipym18687 for ; Sat, 20 May 2000 06:00:45 GMT Received: from sj-dial-2-66.cisco.com (sj-dial-2-66.cisco.com [10.19.226.67]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA09969; Fri, 19 May 2000 23:00:04 -0700 (PDT) Date: Fri, 19 May 2000 22:56:05 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <7955.000519@cisco.com> To: Haoxin Song CC: HANSEN CHAN , mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: References: 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 Friday, May 19, 2000, 8:46 PM, Haoxin Song wrote: > I am sorry that I may have introduced some confusions in last mail dy > using the terms of LSP, LSA and fragmentation. OK, let's put it this way, > both protocol need a method to split information, which need to be > advertised, into meaningful smaller pieces (in ISIS, LSP fragments; in > OSPF, LSAs) so that each of them could be forwarded > independently. Otherwise, during transmission, it will have to relay on > conventional fragmentation/reassembly (in OSPF, IP fragmentation), which > will make the packets have to wait to be reassembled at each hop. The > overhead I mensioned in last mail comes from the different method of this > spliting. Does that make sense now? Yeah... I could add some notes, but it is ok so far. >> Enabling error correction produces somewhat like "OSPF will create >> a separate LSA for each external prefix"? Is this what you mean? > As described above, OSPF split the whole information into smaller pieces > based first on defferent types, if the smaller pieces is still too large > to be fitted in one IP packet, it will further divide it by different > neighbors and make each of them a LSAs. Larry, I'm afraid reality is a bit different. The only type of LSA in OSPF that may become huge is router-LSA. We can do some tricks [potentially] to break adjacency info into several LSAs, BUT no OSPF implementation [AFAIK] is doing this today. The reason for not doing this is because we don't have a lot of huge router-LSAs in reality. >> Again, my point is not that ISIS is worse and OSPF is better >> or the other way. My point is that you cannot make such an "easy" >> conclusion that one proto is less scalable than the other. >> Both protos have pros and cons. > Yes, I agree with you. I was not tring to make any conclusion that in > general one is better than the other. What I was tring to point out is > just some differents of the two protocols which could be one of the > reasons ISPs make their decision. The thing is that both protos are equally good. They are both link-state. They use the same topology abstraction methods, practically the same flooding algo, and practically the same Dijkstra [especially if you recall wide-scale metrics in ISIS]. How you tie routing info to a vertex in the topo graph is just a minor detail. Everyone has one's personal preference. I don't want to talk about reasons for the choice, since it will just start the whole thread over. Alex. P.S. Don't expect ppl developing OSPF to say "yeah, ISIS is better" and the other way. Note however, that people who actually implemented them never say one proto is better than the other in public. Why? Because they know the truth :) From owner-mpls@UU.NET Sat May 20 16:22:17 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 QAA01043 for ; Sat, 20 May 2000 16:22:17 -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 QQiqar07541; Sat, 20 May 2000 20:21:43 GMT Received: by mail-control.mail.uu.net id QQiqar28973 for mpls-outgoing; Sat, 20 May 2000 20:21:24 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 QQiqar28968 for ; Sat, 20 May 2000 20:21:13 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 QQiqar19592 for ; Sat, 20 May 2000 16:21:02 -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 QQiqar07082 for ; Sat, 20 May 2000 20:21:02 GMT Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id QAA29299 for ; Sat, 20 May 2000 16:14:08 -0400 (EDT) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdAAAa0079h; Sat May 20 16:14:03 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Sat, 20 May 2000 16:20:54 -0400 Received: from newbridge.com ([138.120.49.89]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA6418; Sat, 20 May 2000 16:21:00 -0400 Message-Id: <3926F2E3.5CCBE904@newbridge.com> Date: Sat, 20 May 2000 16:17:40 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alex Zinin CC: Haoxin Song , mpls@UU.NET Subject: Re: MPLS and IS-IS References: <8962.000518@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alex, > > I would recommend reading RFC2328, specifically the part about stub > areas. I'd also recommend reading drafts about L2-to-L1 route leaking > in ISIS. Can you point me to the L2-to-L1 route leak draft? I searched both RFC and draft webpage of IETF to no avail. What is the experience of deploying that L2-to-L1 route leaking? Is it actually deployed today in the big tier 1 ISP network? Does it help to optimize inter-area forwarding to the same degree of OSPF? Cheers, Hansen From owner-mpls@UU.NET Sun May 21 15:44: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 PAA09773 for ; Sun, 21 May 2000 15:44: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 QQiqeg25596; Sun, 21 May 2000 19:42:41 GMT Received: by mail-control.mail.uu.net id QQiqeg28717 for mpls-outgoing; Sun, 21 May 2000 19:42:22 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqeg28712 for ; Sun, 21 May 2000 19:42:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqeg19614 for ; Sun, 21 May 2000 15:42: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 QQiqeg07220 for ; Sun, 21 May 2000 19:42:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA15672 for mpls@uu.net; Sun, 21 May 2000 15:42:10 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqeg28700 for ; Sun, 21 May 2000 19:41:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqeg19588 for ; Sun, 21 May 2000 15:41:49 -0400 (EDT) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQiqeg07033 for ; Sun, 21 May 2000 19:41:48 GMT Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68]) by ogma.cisco.com (Postfix) with ESMTP id 128CA7F; Sun, 21 May 2000 21:41:48 +0200 (MET DST) Received: from sprevidi-8kcdt (sprevidi-isdn-home.cisco.com [10.49.0.58]) by brussels.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA11243; Sun, 21 May 2000 21:41:46 +0200 (MET DST) Message-Id: <4.2.0.58.20000521213729.00a52960@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 21 May 2000 21:40:03 +0200 To: "HANSEN CHAN" From: stefano previdi Subject: Re: MPLS and IS-IS Cc: Haoxin Song , mpls@UU.NET In-Reply-To: <3926F2E3.5CCBE904@newbridge.com> References: <8962.000518@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk >At 22:17 20/05/2000 , HANSEN CHAN wrote: >Alex, > >> >> I would recommend reading RFC2328, specifically the part about stub >> areas. I'd also recommend reading drafts about L2-to-L1 route >leaking >> in ISIS. > >Can you point me to the L2-to-L1 route leak draft? I searched both RFC >and draft >webpage of IETF to no avail. What is the experience of deploying that >L2-to-L1 >route leaking? http://www.ietf.org/internet-drafts/draft-ietf-isis-domain-wide-02.txt >Is it actually deployed today in the big tier 1 ISP network? Does >it help to optimize inter-area forwarding to the same degree of OSPF? yes, with some small differences that have already been debated on this list.... s. From owner-mpls@UU.NET Sun May 21 21:09:12 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 VAA11547 for ; Sun, 21 May 2000 21: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 QQiqfc19188; Mon, 22 May 2000 01:07:31 GMT Received: by mail-control.mail.uu.net id QQiqfc06928 for mpls-outgoing; Mon, 22 May 2000 01:07:00 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 QQiqfc06923 for ; Mon, 22 May 2000 01:06: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 QQiqfc00631 for ; Sun, 21 May 2000 21:06: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 QQiqfc02054 for ; Mon, 22 May 2000 01:06:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA26523 for mpls@uu.net; Sun, 21 May 2000 21:06:43 -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 QQiqfc06881 for ; Mon, 22 May 2000 01:06: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 QQiqfc00564 for ; Sun, 21 May 2000 21:05:53 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiqfc01563 for ; Mon, 22 May 2000 01:05:52 GMT Received: from dhcp-sjc16-60.cisco.com (dhcp-sjc16-60.cisco.com [171.70.96.60]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA24825; Sun, 21 May 2000 18:05:19 -0700 (PDT) Date: Sun, 21 May 2000 18:01:22 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <11750.000521@cisco.com> To: stefano previdi CC: "HANSEN CHAN" , Haoxin Song , mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: <4.2.0.58.20000521213729.00a52960@brussels.cisco.com> References: <4.2.0.58.20000521213729.00a52960@brussels.cisco.com> 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, Stefano. Regarding any ISPs using this ISIS feature: my sources say "no" :) Alex. Sunday, May 21, 2000, 12:40 PM, stefano previdi wrote: > >Can you point me to the L2-to-L1 route leak draft? I searched both RFC > >and draft > >webpage of IETF to no avail. What is the experience of deploying that > >L2-to-L1 > >route leaking? > http://www.ietf.org/internet-drafts/draft-ietf-isis-domain-wide-02.txt > >Is it actually deployed today in the big tier 1 ISP network? Does > >it help to optimize inter-area forwarding to the same degree of OSPF? > yes, with some small differences that have already been debated > on this list.... > s. From owner-mpls@UU.NET Sun May 21 21:39:10 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 VAA11695 for ; Sun, 21 May 2000 21:39: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 QQiqfe05699; Mon, 22 May 2000 01:37:34 GMT Received: by mail-control.mail.uu.net id QQiqfe08531 for mpls-outgoing; Mon, 22 May 2000 01:37:03 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqfe08526 for ; Mon, 22 May 2000 01:36:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqfe13006 for ; Sun, 21 May 2000 21:36:51 -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 QQiqfe05181 for ; Mon, 22 May 2000 01:36:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA27954 for mpls@uu.net; Sun, 21 May 2000 21:36:50 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqfe08516 for ; Mon, 22 May 2000 01:36:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqfe12984 for ; Sun, 21 May 2000 21:36: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 QQiqfe17504 for ; Mon, 22 May 2000 01:36: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 SAA05338; Sun, 21 May 2000 18:36:36 -0700 (PDT) Received: from cisco.com (rraszuk-dsl5.cisco.com [10.19.31.94]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA12803; Sun, 21 May 2000 18:36:36 -0700 (PDT) Message-ID: <3929D2B3.BEA0FA43@cisco.com> Date: Mon, 22 May 2000 17:37:07 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: stefano previdi , HANSEN CHAN , Haoxin Song , mpls@UU.NET Subject: Re: MPLS and IS-IS References: <4.2.0.58.20000521213729.00a52960@brussels.cisco.com> <11750.000521@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alex, Most ISPs I know who run ISIS have a single level so this does not apply. Although I know at least one who is leaking /32 (of their PEs) to level1s due to the fact that this is required by mpls-vpns. R. > Alex Zinin wrote: > > Thanks, Stefano. > > Regarding any ISPs using this ISIS feature: my sources say "no" :) > > Alex. > > Sunday, May 21, 2000, 12:40 PM, stefano previdi wrote: > > >Can you point me to the L2-to-L1 route leak draft? I searched both RFC > > >and draft > > >webpage of IETF to no avail. What is the experience of deploying that > > >L2-to-L1 > > >route leaking? > > > http://www.ietf.org/internet-drafts/draft-ietf-isis-domain-wide-02.txt > > > >Is it actually deployed today in the big tier 1 ISP network? Does > > >it help to optimize inter-area forwarding to the same degree of OSPF? > > > yes, with some small differences that have already been debated > > on this list.... > > > s. From owner-mpls@UU.NET Mon May 22 02:33:47 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 CAA27019 for ; Mon, 22 May 2000 02:33: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 QQiqfy01034; Mon, 22 May 2000 06:33:08 GMT Received: by mail-control.mail.uu.net id QQiqfy07192 for mpls-outgoing; Mon, 22 May 2000 06:32: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 QQiqfy07187 for ; Mon, 22 May 2000 06:32: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 QQiqfy26426 for ; Mon, 22 May 2000 02:32:32 -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 QQiqfy12868 for ; Mon, 22 May 2000 06:32:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA10983 for mpls@uu.net; Mon, 22 May 2000 02:32: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 QQiqfy07174 for ; Mon, 22 May 2000 06:31: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 QQiqfy26368 for ; Mon, 22 May 2000 02:31:40 -0400 (EDT) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQiqfy00195 for ; Mon, 22 May 2000 06:31:40 GMT Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68]) by ogma.cisco.com (Postfix) with ESMTP id B98E15C9; Mon, 22 May 2000 08:31:39 +0200 (MET DST) Received: from sprevidi-8kcdt (sprevidi-isdn-home.cisco.com [10.49.0.58]) by brussels.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA02901; Mon, 22 May 2000 08:31:38 +0200 (MET DST) Message-Id: <4.2.0.58.20000522082919.00986760@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 22 May 2000 08:29:59 +0200 To: Alex Zinin From: stefano previdi Subject: Re: MPLS and IS-IS Cc: "HANSEN CHAN" , Haoxin Song , mpls@UU.NET In-Reply-To: <11750.000521@cisco.com> References: <4.2.0.58.20000521213729.00a52960@brussels.cisco.com> <4.2.0.58.20000521213729.00a52960@brussels.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 03:01 22/05/2000 , Alex Zinin wrote: >Thanks, Stefano. > >Regarding any ISPs using this ISIS feature: my sources say "no" :) I know one who is deploying this. s. From owner-mpls@UU.NET Mon May 22 02: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 CAA27096 for ; Mon, 22 May 2000 02: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 QQiqfz23076; Mon, 22 May 2000 06:51:44 GMT Received: by mail-control.mail.uu.net id QQiqfz08066 for mpls-outgoing; Mon, 22 May 2000 06:51:28 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 QQiqfz08061 for ; Mon, 22 May 2000 06:51: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 QQiqfz27855 for ; Mon, 22 May 2000 02:51:13 -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 QQiqfz10933 for ; Mon, 22 May 2000 06:51:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA11820 for mpls@uu.net; Mon, 22 May 2000 02:51:12 -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 QQiqfz07957 for ; Mon, 22 May 2000 06:50:40 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 QQiqfz01535 for ; Mon, 22 May 2000 02:50:31 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiqfz10543 for ; Mon, 22 May 2000 06:50:30 GMT Received: from sj-dial-2-214.cisco.com (sj-dial-2-214.cisco.com [10.19.226.215]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA12173; Sun, 21 May 2000 23:49:55 -0700 (PDT) Date: Sun, 21 May 2000 23:45:57 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <17990.000521@cisco.com> To: Robert Raszuk CC: stefano previdi , HANSEN CHAN , Haoxin Song , mpls@UU.NET Subject: Re: MPLS and IS-IS In-reply-To: <3929D2B3.BEA0FA43@cisco.com> References: <3929D2B3.BEA0FA43@cisco.com> 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 Robert: Monday, May 22, 2000, 5:37 PM, Robert Raszuk wrote: > Alex, > Most ISPs I know who run ISIS have a single level so this does not apply. Since one of the reasons for not running multiple levels could be lack of inter-area routes, I think it does apply. > Although I know at least one who is leaking /32 (of their PEs) to level1s due > to the fact that this is required by mpls-vpns. Thanks for the info. It is especially interesting because of the subject of this thread. A. ;) > R. >> Alex Zinin wrote: >> >> Thanks, Stefano. >> >> Regarding any ISPs using this ISIS feature: my sources say "no" :) >> >> Alex. >> >> Sunday, May 21, 2000, 12:40 PM, stefano previdi wrote: >> > >Can you point me to the L2-to-L1 route leak draft? I searched both RFC >> > >and draft >> > >webpage of IETF to no avail. What is the experience of deploying that >> > >L2-to-L1 >> > >route leaking? >> >> > http://www.ietf.org/internet-drafts/draft-ietf-isis-domain-wide-02.txt >> >> > >Is it actually deployed today in the big tier 1 ISP network? Does >> > >it help to optimize inter-area forwarding to the same degree of OSPF? >> >> > yes, with some small differences that have already been debated >> > on this list.... >> >> > s. From owner-mpls@UU.NET Mon May 22 04:36: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 EAA27768 for ; Mon, 22 May 2000 04:36: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 QQiqgg07566; Mon, 22 May 2000 08:35:47 GMT Received: by mail-control.mail.uu.net id QQiqgg00815 for mpls-outgoing; Mon, 22 May 2000 08:35: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 QQiqgg00810 for ; Mon, 22 May 2000 08:35:13 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 QQiqgg09327 for ; Mon, 22 May 2000 04:35:00 -0400 (EDT) Received: from smtp1.cluster.oleane.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.cluster.oleane.net [195.25.12.16]) id QQiqgg18037 for ; Mon, 22 May 2000 08:34:59 GMT Received: from oleane (dyn-1-2-245.Vin.dialup.oleane.fr [194.2.4.245]) by smtp1.cluster.oleane.net with SMTP id KAA08350; Mon, 22 May 2000 10:34:56 +0200 (CEST) Message-ID: <017b01bfc3c7$cb26f760$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP over DWDM Conference Date: Mon, 22 May 2000 10:29:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0178_01BFC3D8.8D1CF260" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0178_01BFC3D8.8D1CF260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP over DWDM Conference, 27-30 November 2000, Paris Please take a look on the Call for papers at: http://www.upperside.fr/badwdm.htm ------=_NextPart_000_0178_01BFC3D8.8D1CF260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IP over DWDM Conference, 27-30 = November 2000,=20 Paris
Please take a = look on the=20 Call for papers at:
http://www.upperside.fr/badwd= m.htm
------=_NextPart_000_0178_01BFC3D8.8D1CF260-- From owner-mpls@UU.NET Mon May 22 08:45: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 IAA01254 for ; Mon, 22 May 2000 08:45: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 QQiqgw22219; Mon, 22 May 2000 12:43:56 GMT Received: by mail-control.mail.uu.net id QQiqgw19244 for mpls-outgoing; Mon, 22 May 2000 12:43: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 QQiqgw19239 for ; Mon, 22 May 2000 12:43: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 QQiqgw26413 for ; Mon, 22 May 2000 08:43:13 -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 QQiqgw04585 for ; Mon, 22 May 2000 12:43:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA26158 for mpls@uu.net; Mon, 22 May 2000 08:43:12 -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 QQiqgw19221 for ; Mon, 22 May 2000 12:43:02 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 QQiqgw26377 for ; Mon, 22 May 2000 08:42:46 -0400 (EDT) Received: from baynet.baynetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQiqgw04346 for ; Mon, 22 May 2000 12:42:46 GMT Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id FAA21640; Mon, 22 May 2000 05:41:15 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id FAA26811; Mon, 22 May 2000 05:41:12 -0700 (PDT) Received: from nortelnetworks.com (dhcp220-138 [192.32.220.138]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id IAA03557; Mon, 22 May 2000 08:42:42 -0400 for Message-ID: <392A7D27.11B1E1E0@nortelnetworks.com> Date: Tue, 23 May 2000 08:44:24 -0400 From: Dave Wilder Reply-To: dawilder@nortelnetworks.com Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en]C-3M;VANGRD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sanford, Bill" CC: "'mpls@uu.net'" Subject: Re: RSVP-TE objects "Quick Reference" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bill, This was a great time-saver to me in my RSVP testing. Thanks, Dave "Sanford, Bill" wrote: > I would like to submit a "Quick Reference" for RSVP-TE objects. During the > RSVP-TE Group Test Period at UNH and just recently Interop in Las Vegas, I > found that this was incredibly helpful for analyzing hex dumps. Most of the > objects are there and hopefully most are accurate. I wanted to get this to > the MPLS list so that it can be updated and maybe even used. > > Bill > > -- > Bill Sanford > bills@hjinc.com > Senior SQA Test Engineer > http://www.hjinc.com > Harris & Jeffries, Inc. > 888 Washington Street > Dedham MA 02026 > Tel: (781) 329-3200 > Fax: (781) 329-4148 > > ------------------------------------------------------------------------ > Name: RSVPObjectsQuickReference.xls > RSVPObjectsQuickReference.xls Type: Microsoft Excel Worksheet (application/vnd.ms-excel) > Encoding: base64 From owner-mpls@UU.NET Mon May 22 09:10: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 JAA01622 for ; Mon, 22 May 2000 09:10: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 QQiqgy21739; Mon, 22 May 2000 13:08:41 GMT Received: by mail-control.mail.uu.net id QQiqgy26590 for mpls-outgoing; Mon, 22 May 2000 13:08:16 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqgy26479 for ; Mon, 22 May 2000 13:08:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqgy29897 for ; Mon, 22 May 2000 09:08: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 QQiqgy21177 for ; Mon, 22 May 2000 13:08:04 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 GAA19875 for ; Mon, 22 May 2000 06:08:11 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA06512 for mpls@uu.net; Mon, 22 May 2000 09:08:02 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQipyd03066 for ; Sat, 20 May 2000 03:50:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQipyd10791 for ; Fri, 19 May 2000 23:50:09 -0400 (EDT) Received: from roam.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mg-206253200-87.ricochet.net [206.253.200.87]) id QQipyd29190 for ; Sat, 20 May 2000 03:50:08 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12svMl-0000Oq-00; Fri, 19 May 2000 15:35:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Jessica Yu Cc: mpls@UU.NET Subject: Re: MPLS and IS-IS References: <20000519112244.27394.qmail@web3004.mail.yahoo.com> Message-Id: Date: Fri, 19 May 2000 15:35:35 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit i'll be my normal tactless self. the problem is that one has to support ospf because the vast majority of customers use it. is-is is only used by a few networks, just the largest ones. so expect support for both. randy From owner-mpls@UU.NET Mon May 22 09:11: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 JAA01683 for ; Mon, 22 May 2000 09:11:43 -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 QQiqgy10208; Mon, 22 May 2000 13:10:08 GMT Received: by mail-control.mail.uu.net id QQiqgy28060 for mpls-outgoing; Mon, 22 May 2000 13:09:37 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqgy27859 for ; Mon, 22 May 2000 13:09:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqgy29987 for ; Mon, 22 May 2000 09:09:09 -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 QQiqgy09081 for ; Mon, 22 May 2000 13:09:05 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 GAA04154 for ; Mon, 22 May 2000 06:09:12 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA06518 for mpls@uu.net; Mon, 22 May 2000 09:09:02 -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 QQiqdc29574 for ; Sun, 21 May 2000 12:05:21 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 QQiqdc10968 for ; Sun, 21 May 2000 08:05:13 -0400 (EDT) Received: from neptune.telecomm.tadiran.co.il by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tadiran.co.il [194.90.248.2]) id QQiqdc04572 for ; Sun, 21 May 2000 12:05:06 GMT Received: from oranus.tadirantele.com (oranus [10.115.11.180]) by neptune.telecomm.tadiran.co.il (8.9.3/8.9.3) with ESMTP id OAA18465; Sun, 21 May 2000 14:01:24 +0200 (IST) Received: by oranus.tadirantele.com with Internet Mail Service (5.5.2650.21) id ; Sun, 21 May 2000 15:01:31 +0300 Message-ID: From: Levi Daphna To: "'Eric Gray'" Cc: "'mpls@UU.NET'" Subject: RE: Question:draft-ietf-mpls-atm-03.txt Date: Sun, 21 May 2000 15:01:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-8" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA01683 Eric, Let me see if I understand, connecting LC-ATM interfaces via an ATM VP is just like IP over ATM, but instead of using ATM interfaces to connect Routers we use LC-ATM interfaces to connect LSRs. The LSRs are logically adjacent to one another while they are physically connected via ATM VP connection. I am not quite sure what is the logic to do that , after all this is the infamous overlay model. (unless you use the ATM cloud as a multiservice cloud and then you can avoid ships in the night) . Daphna > -----Original Message----- > From: Eric Gray [SMTP:EGray@zaffire.com] > Sent: ä îàé 18 2000 23:25 > To: 'Daphna.Levi@ecitele.com' > Cc: Eric Gray; Eric W Gray (E-mail) > Subject: Re: Question:draft-ietf-mpls-atm-03.txt > > Daphna, > > When using a Virtual Path to connect LSRs across > multiple intervening VP switches, VP values are set at > each intervening switch - usually via configuration or > provisioning. > > For the ATM switches at each end of the virtual > path, the VPI is set in the same way. > > The actual VPI need not be the same at any two > ATM physical links since the VP switch may change > the VPI value in switching cells from input interface > to output interface. However, VP switches do not > change VCI values, so MPLS needs the two LSRs at > either end of a VP to act as if they are adjacent in > assigning VCI values. > > Does this help? > > -- > Eric Gray << File: TechTool.gif >> From owner-mpls@UU.NET Mon May 22 09:12: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 ESMTP id JAA01696 for ; Mon, 22 May 2000 09:12: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 QQiqgy23712; Mon, 22 May 2000 13:10:59 GMT Received: by mail-control.mail.uu.net id QQiqgy29369 for mpls-outgoing; Mon, 22 May 2000 13:10: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 QQiqgy29345 for ; Mon, 22 May 2000 13:10: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 QQiqgy00222 for ; Mon, 22 May 2000 09:10:11 -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 QQiqgy10260 for ; Mon, 22 May 2000 13:10:11 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 GAA04642 for ; Mon, 22 May 2000 06:10:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA06524 for mpls@uu.net; Mon, 22 May 2000 09:10:08 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQipyh15290 for ; Sat, 20 May 2000 04:51:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQipyh15393 for ; Sat, 20 May 2000 00:51:53 -0400 (EDT) Received: from sasi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQipyh25912 for ; Sat, 20 May 2000 04:51:50 GMT Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id KAA08187; Sat, 20 May 2000 10:20:19 +0530 (IST) Received: from sund2.sasi.com ([10.0.16.2]) by sasi.com; Sat, 20 May 2000 10:20:18 +0000 (IST) Received: from localhost (ramp@localhost) by sund2.sasi.com (8.9.1/8.9.1) with ESMTP id KAA03858; Sat, 20 May 2000 10:23:14 +0530 (IST) Date: Sat, 20 May 2000 10:23:13 +0530 (IST) From: B G Ramprasad Torati To: ietf@ietf.org cc: mpls@UU.NET Subject: Help on doing MPLS Performance analysis.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have simulated the LDP part of MPLS by extending netwrok simulator 2.(ns2.1b5). Now I want to do performance analasys using that.I know MPLS has several adavantages over normal IP forwarding paradigm. But I don't know exactly how to test this.So can anybody suggest what to do for doing this MPLS performance analasys. What I means here is what are all the things I have to test like packet loss,throughput,dealys etc, and how to do those tests. I want to know what numbers I have to set for the parameters like bandwidth, link dalay of links between two nodes while doing this performance analysis. Any help is graetly appreciated.. Thanks and Regards, Ramp From owner-mpls@UU.NET Mon May 22 10:50:47 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 KAA03221 for ; Mon, 22 May 2000 10:50:47 -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 QQiqhf18971; Mon, 22 May 2000 14:48:48 GMT Received: by mail-control.mail.uu.net id QQiqhf18193 for mpls-outgoing; Mon, 22 May 2000 14:48:17 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqhf18180 for ; Mon, 22 May 2000 14:48:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqhf11825 for ; Mon, 22 May 2000 10:47:48 -0400 (EDT) Received: from web3006.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web3006.mail.yahoo.com [204.71.202.169]) id QQiqhf18035 for ; Mon, 22 May 2000 14:47:47 GMT Received: (qmail 14242 invoked by uid 60001); 22 May 2000 14:47:47 -0000 Message-ID: <20000522144747.14241.qmail@web3006.mail.yahoo.com> Received: from [141.212.130.253] by web3006.mail.yahoo.com; Mon, 22 May 2000 07:47:47 PDT Date: Mon, 22 May 2000 07:47:47 -0700 (PDT) From: Jessica Yu Subject: Re: MPLS and IS-IS To: Randy Bush Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk My original message recognized the installed base issue. I am asking besides that, is there other values for supporting both in the particular situation? It may help for future protocol standardization process in the ietf. --jessica --- Randy Bush wrote: > i'll be my normal tactless self. the problem is > that one has to support > ospf because the vast majority of customers use it. > is-is is only used > by a few networks, just the largest ones. so expect > support for both. > > randy > __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Mon May 22 12:17: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 ESMTP id MAA04491 for ; Mon, 22 May 2000 12:17: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 QQiqhl21882; Mon, 22 May 2000 16:15:08 GMT Received: by mail-control.mail.uu.net id QQiqhk12379 for mpls-outgoing; Mon, 22 May 2000 16:14: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 QQiqhk12364 for ; Mon, 22 May 2000 16:14: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 QQiqhk01940 for ; Mon, 22 May 2000 12:14:05 -0400 (EDT) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQiqhk21183 for ; Mon, 22 May 2000 16:14:05 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon May 22 12:12:23 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn64.pa.bell-labs.com [135.250.1.64]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA19211; Mon, 22 May 2000 12:12:30 -0400 (EDT) Message-ID: <39295D45.99B88B95@dnrc.bell-labs.com> Date: Mon, 22 May 2000 09:16:05 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jessica Yu CC: Randy Bush , mpls@UU.NET Subject: Re: MPLS and IS-IS References: <20000522144747.14241.qmail@web3006.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [..] > It may help for future protocol standardization > process in the ietf. While ever the IETF holds to the notion that "running code" largely validates a protocol's development, we'll find it hard to *completely* stamp out instances of similar-but-not-quite-the-same protocols being progressed. (Especially if both work - for some constituency's definition of work) Since requiring "running code" is in itself a good filter mechanism for protocol development, we'll probably just have to live with the potential downsides... Can we close this current OSPF vs IS-IS chapter and get back to TE for MPLS? cheers, gja From owner-mpls@UU.NET Mon May 22 19:22: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 ESMTP id TAA11047 for ; Mon, 22 May 2000 19:22: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 QQiqin00036; Mon, 22 May 2000 23:20:36 GMT Received: by mail-control.mail.uu.net id QQiqin15367 for mpls-outgoing; Mon, 22 May 2000 23:20: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 QQiqin15359 for ; Mon, 22 May 2000 23:20:04 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 QQiqin15444 for ; Mon, 22 May 2000 19:20: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 QQiqin13161 for ; Mon, 22 May 2000 23:20:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA19705 for mpls@uu.net; Mon, 22 May 2000 19:20:02 -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 QQiqin15322 for ; Mon, 22 May 2000 23:19: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 QQiqin29370 for ; Mon, 22 May 2000 19:19:13 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiqin12754 for ; Mon, 22 May 2000 23:19:13 GMT Received: from akyol (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with SMTP id QAA09406 for ; Mon, 22 May 2000 16:19:12 -0700 (PDT) Message-ID: <01ef01bfc444$246aea30$873710ac@pluris.com> From: "Bora Akyol" To: Subject: RSVP-TE and Operation Suboject Date: Mon, 22 May 2000 16:19: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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Where are the "operation subobjects" for the Explicit Route object defined? A text search through the document does not yield anything. I have the latest version of this draft. Bora From owner-mpls@UU.NET Mon May 22 20:12: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 ESMTP id UAA11546 for ; Mon, 22 May 2000 20:12: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 QQiqiq12049; Tue, 23 May 2000 00:10:54 GMT Received: by mail-control.mail.uu.net id QQiqiq27633 for mpls-outgoing; Tue, 23 May 2000 00:10: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 QQiqiq27577 for ; Tue, 23 May 2000 00:09:59 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 QQiqiq04106 for ; Mon, 22 May 2000 20:09:49 -0400 (EDT) From: lijianping@mail.zte.com.cn Received: from mail.zhongxing.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) id QQiqiq11176 for ; Tue, 23 May 2000 00:09:42 GMT Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 482568E8.0000E514 ; Tue, 23 May 2000 08:09:46 +0800 X-Lotus-FromDomain: ZTE_LTD To: B G Ramprasad Torati cc: mpls@UU.NET Message-ID: Date: Tue, 23 May 2000 09:04:12 +0900 Subject: ´ð¸´:Help on doing MPLS Performance analysis.... Sender: owner-mpls@UU.NET Precedence: bulk At least, you can test the speed of ping packets. Ping packets transmit faster when passing two MPLS-enabled switches than passing two MPLS-disabled routers. Good luck! Lijianping. From owner-mpls@UU.NET Tue May 23 07:18: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 ESMTP id HAA00142 for ; Tue, 23 May 2000 07:18: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 QQiqkj24344; Tue, 23 May 2000 11:17:43 GMT Received: by mail-control.mail.uu.net id QQiqkj20984 for mpls-outgoing; Tue, 23 May 2000 11:17: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 QQiqkj20970 for ; Tue, 23 May 2000 11:16:59 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 QQiqkj08561 for ; Tue, 23 May 2000 07:16:49 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiqkj09413 for ; Tue, 23 May 2000 11:16:26 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id JAA05898 for ; Tue, 23 May 2000 09:28:09 -0600 (GMT) Message-ID: <003e01bfacd9$29e7c8c0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: VC Merge support in LDP Date: Sun, 23 Apr 2000 09:34:08 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01BFAD07.131B5D40" 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 This is a multi-part message in MIME format. ------=_NextPart_000_003B_01BFAD07.131B5D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=20 I am implementing LDP-06 and I have question regarding vc merge.=20 When LDP merges 2 LSPs into 1, it should take care that the bandwidth on = the outgoing channel from that point onwards till the egress LER should = be such that it is sufficient for the data merged from 2 LSPs. Suppose 1 = LSP is already setup and later a request comes for the same destination = and an LSR decides to merge this new request with the already existing = LSP. But there is no such provision in the LDP draft to modify the LSP. = So how is this merging supported ?=20 In CR-LDP 03 draft, the LSP can be modified but that has to be triggered = from the Ingress LER and not by any LSR in between the LSP. So how could = we possibly go about doing it, even in CR-LDP ?=20 santosh ------=_NextPart_000_003B_01BFAD07.131B5D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
    I am implementing LDP-06 and I have = question=20 regarding vc merge.
When LDP merges 2 LSPs into 1, it should take care that the = bandwidth on=20 the outgoing channel from that point onwards till the egress LER should = be such=20 that it is sufficient for the data merged from 2 LSPs. Suppose 1 LSP is = already=20 setup and later a request comes for the same destination and an LSR = decides to=20 merge this new request with the already existing LSP. But there is no = such=20 provision in the LDP draft to modify the LSP. So how is this merging = supported ?=20
 
In CR-LDP 03 draft, the LSP can be modified but that has to be = triggered=20 from the Ingress LER and not by any LSR in between the LSP. So how could = we=20 possibly go about doing it, even in CR-LDP ?

santosh
------=_NextPart_000_003B_01BFAD07.131B5D40-- From owner-mpls@UU.NET Tue May 23 07:19: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 HAA00184 for ; Tue, 23 May 2000 07:19: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 QQiqkj10499; Tue, 23 May 2000 11:18:01 GMT Received: by mail-control.mail.uu.net id QQiqkj21043 for mpls-outgoing; Tue, 23 May 2000 11:17:28 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 QQiqkj21017 for ; Tue, 23 May 2000 11:17: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 QQiqkj08599 for ; Tue, 23 May 2000 07:17:06 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiqkj09054 for ; Tue, 23 May 2000 11:15:54 GMT Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id QAA11270 for ; Tue, 23 May 2000 16:40:25 -0600 (GMT) Message-ID: <392A6873.BB3D15D0@daewoo.dti.daewoo.co.kr> Date: Tue, 23 May 2000 16:46:04 +0530 From: Neetu Gupta Reply-To: neetug@daewoo.dti.daewoo.co.kr Organization: Daewoo Telecom X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: mpls@UU.NET Subject: LSP Merge issue(Using RSVP) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, This topic has been discussed before. But, My query is bit different from the one previously discussed: Suppose we have the following setup: A \ \ C===D===E / / B Suppose that A sends Path message specifying tunnel endpoint address E. Thus LSP 1 is created from A to E. Now Suppose another Path Message from B and destined for E comes. Suppose , it is configured that LSP merging at C is possible - Both Path messages have "Merge permitted" flag in Session Attributes set - Both Path Messages requesting for same Class of Service When the Path Message from B reaches E, E finds that there is already an LSP for the session, and since it knows that C can merge the LSPs, it'll assign a new label with the resources set for this LSP equal to LUB of both the flowspecs(if style is Shared Explicit) or sum of both the flowspecs(if style is FixedFilter) and delete the label of LSP1 - E sends Resv Message to D with Flow Descriptor containing merged flowspec and two Filterspec objects (one for A and one for B) and same label to both . - D assigns a new incoming label and remove the old label of LSP1 and modify the flowspec with the one coming in the Resv Message and sends the Resv Message to C. This Resv also specifies identical label values for A and B, and flowdescriptor identical to the one coming in the Resv Message from E. - Since, C is the merge point. It assigns a new incoming label for B. Thus at C, there will be two incoming labels , one for A and one for B. It then sends Resv to B. Is this correct? Can we Merge the LSPs as specified above? Please clarify -neetu From owner-mpls@UU.NET Tue May 23 07:28: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 HAA00428 for ; Tue, 23 May 2000 07:28: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 QQiqkj16055; Tue, 23 May 2000 11:27:37 GMT Received: by mail-control.mail.uu.net id QQiqkj21932 for mpls-outgoing; Tue, 23 May 2000 11:27:05 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqkj21912 for ; Tue, 23 May 2000 11:26:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqkj27137 for ; Tue, 23 May 2000 07:16:12 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiqkj08974 for ; Tue, 23 May 2000 11:15:45 GMT Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id JAA06182 for ; Tue, 23 May 2000 09:52:53 -0600 (GMT) Message-ID: <392A08DE.17323756@daewoo.dti.daewoo.co.kr> Date: Tue, 23 May 2000 09:58:15 +0530 From: Neetu Gupta Reply-To: neetug@daewoo.dti.daewoo.co.kr Organization: Daewoo Telecom X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: mpls@UU.NET Subject: LSP Merge Issue(Using RSVP) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, This topic has been discussed before. But, My query is bit different from the one previously discussed: Suppose we have the following setup: A \ \ C===D===E / / B Suppose that A sends Path message specifying tunnel endpoint address E. Thus LSP 1 is created from A to E. Now Suppose another Path Message from B and destined for E comes. Suppose , it is configured that LSP merging at C is possible - Both Path messages have "Merge permitted" flag in Session Attributes set - Both Path Messages requesting for same Class of Service When the Path Message from B reaches E, E finds that there is already an LSP for the session, and since it knows that C can merge the LSPs, it'll assign a new label with the resources set for this LSP equal to LUB of both the flowspecs(if style is Shared Explicit) or sum of both the flowspecs(if style is FixedFilter) and delete the label of LSP1 - E sends Resv Message to D with Flow Descriptor containing merged flowspec and two Filterspec objects (one for A and one for B) and same label to both . - D assigns a new incoming label and remove the old label of LSP1 and modify the flowspec with the one coming in the Resv Message and sends the Resv Message to C. This Resv also specifies identical label values for A and B, and flowdescriptor identical to the one coming in the Resv Message from E. - Since, C is the merge point. It assigns a new incoming label for B. Thus at C, there will be two incoming labels , one for A and one for B. It then sends Resv to B. Is this correct? Can we Merge the LSPs as specified above? Please clarify -neetu From owner-mpls@UU.NET Tue May 23 11:21: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 ESMTP id LAA04942 for ; Tue, 23 May 2000 11:21: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 QQiqkz17970; Tue, 23 May 2000 15:21:01 GMT Received: by mail-control.mail.uu.net id QQiqkz15885 for mpls-outgoing; Tue, 23 May 2000 15:20:34 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqkz15873 for ; Tue, 23 May 2000 15:20:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqkz23346 for ; Tue, 23 May 2000 11:20:25 -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 QQiqkz01488 for ; Tue, 23 May 2000 15:20:24 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 IAA18781 for ; Tue, 23 May 2000 08:20:31 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA10360 for mpls@uu.net; Tue, 23 May 2000 11:20: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 QQiqkv01350 for ; Tue, 23 May 2000 14:21: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 QQiqkv28661 for ; Tue, 23 May 2000 10:21:12 -0400 (EDT) Received: from phoenix.ficon-tech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: phoenix.ficon-tech.com [209.125.90.2]) id QQiqkv19240 for ; Tue, 23 May 2000 14:21:12 GMT Received: from globespan.net (192.168.137.202) by phoenix.ficon-tech.com (Worldmail 1.3.167); 23 May 2000 10:31:10 -0400 Message-ID: <392A9391.D312AEAF@globespan.net> Date: Tue, 23 May 2000 10:20:01 -0400 From: Rohit Chhapolia Organization: Globespan, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: neetug@daewoo.dti.daewoo.co.kr CC: mpls@UU.NET Subject: Re: LSP Merge issue(Using RSVP) References: <392A6873.BB3D15D0@daewoo.dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Please see the comments below. Neetu Gupta wrote: > > Hello, > This topic has been discussed before. But, My query is bit different > > from the one previously discussed: > > Suppose we have the following setup: > > A > \ > \ > C===D===E > / > / > B > > Suppose that A sends Path message specifying tunnel endpoint address E. > Thus LSP 1 is created from A to E. > Now Suppose another Path Message from B and destined for E comes. > > Suppose , it is configured that LSP merging at C is possible > - Both Path messages have "Merge permitted" flag in Session > Attributes set > - Both Path Messages requesting for same Class of Service > > When the Path Message from B reaches E, E finds that there is already an > > LSP for the session, and since it knows that C can merge the LSPs, it'll > > assign a new label with the resources set for this LSP equal to LUB of > both the flowspecs(if style is Shared Explicit) or sum of both the > flowspecs(if style is FixedFilter) and delete the label of LSP1 > - E sends Resv Message to D with Flow Descriptor containing merged > flowspec and two Filterspec objects (one for A and one for B) and same > label to both . E can not send same label for both filterspecs. For E to send same label for both Filterspecs, it should know that C is capable of merging LSPs. Firstly, E does not know which node does the merging. Secondly, it does not know whether that node is merge capable. > - D assigns a new incoming label and remove the old label of LSP1 and > modify the flowspec with the one coming in the Resv Message and sends > the Resv Message to C. This Resv also specifies identical label values > for A and B, and flowdescriptor identical to the one coming in the Resv > Message from E. > - Since, C is the merge point. It assigns a new incoming label for B. > Thus at C, there will be two incoming labels , one for A and one for B. > It then sends Resv to B. > > Is this correct? Can we Merge the LSPs as specified above? > Please clarify > -neetu -- Rohit Chhapolia Globespan, Inc. mailto:rohit@globespan.net http://www.globespan.net From owner-mpls@UU.NET Tue May 23 21:30: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 VAA14321 for ; Tue, 23 May 2000 21:30: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 QQiqmn27935; Wed, 24 May 2000 01:29:48 GMT Received: by mail-control.mail.uu.net id QQiqmn04293 for mpls-outgoing; Wed, 24 May 2000 01:29:17 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqmn04278 for ; Wed, 24 May 2000 01:29:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqmn12089 for ; Tue, 23 May 2000 21:23:22 -0400 (EDT) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQiqmn22185 for ; Wed, 24 May 2000 01:23:21 GMT Received: from zcpzd009.asiapac.nortel.com (actually 47.134.112.12) by smtprch1.nortel.com; Tue, 23 May 2000 20:20:04 -0500 Received: by zcpzd009.asiapac.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 09:19:41 +0800 Message-ID: <6514C2683A0CD311BB5F0000F8100284F0E437@zclbd003.asiapac.nortel.com> From: "Stewart Pu" To: mpls@UU.NET Subject: Questions: IS-IS vs. OSPF Date: Wed, 24 May 2000 09:18:11 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC51E.2225AE2E" 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_01BFC51E.2225AE2E Content-Type: text/plain Hi, Forgive my silly questions: * To implement an IGP in a large ISP network, which one is better? OSPF or IS-IS? Why? * To support MPLS, which one is better? IS-IS of OSPF? Please Comment. Thanks. Stewart * : pusu@nortelnetworks.com ------_=_NextPart_001_01BFC51E.2225AE2E Content-Type: text/html Content-Transfer-Encoding: quoted-printable Questions: IS-IS vs. OSPF

Hi,

Forgive my silly questions:

  • To implement an IGP in a large = ISP network, which one is better? OSPF or IS-IS? Why?
  • To support MPLS, which one is better? = IS-IS of OSPF?


Please Comment. = Thanks.

Stewart
+ = : pusu@nortelnetworks.com

------_=_NextPart_001_01BFC51E.2225AE2E-- From owner-mpls@UU.NET Tue May 23 21:38: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 ESMTP id VAA14476 for ; Tue, 23 May 2000 21:38: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 QQiqmo00525; Wed, 24 May 2000 01:38:19 GMT Received: by mail-control.mail.uu.net id QQiqmo05550 for mpls-outgoing; Wed, 24 May 2000 01:38: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 QQiqmo05540 for ; Wed, 24 May 2000 01:37:48 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 QQiqmo02945 for ; Tue, 23 May 2000 21:37:24 -0400 (EDT) Received: from baynet.baynetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQiqmo02942 for ; Wed, 24 May 2000 01:37:24 GMT Received: from mailhost.BayNetworks.COM (h016d.s86b1.BayNetworks.COM [134.177.1.109]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id SAA25440 for ; Tue, 23 May 2000 18:35:55 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id SAA00226; Tue, 23 May 2000 18:30:38 -0700 (PDT) Received: from bubba.engeast (bubba [192.168.136.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id VAA20053; Tue, 23 May 2000 21:37:21 -0400 for Received: by bubba.engeast (SMI-8.6/SMI-SVR4) id VAA06085; Tue, 23 May 2000 21:37:20 -0400 From: dwilder@baynetworks.com (David Wilder) Message-Id: <200005240137.VAA06085@bubba.engeast> Subject: Re: Questions: IS-IS vs. OSPF In-Reply-To: <6514C2683A0CD311BB5F0000F8100284F0E437@zclbd003.asiapac.nortel.com> from Stewart Pu at "May 24, 2000 09:18:11 am" To: Stewart Pu Date: Tue, 23 May 2000 21:37:20 -0400 (EDT) CC: mpls@UU.NET X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 Stewart, There was just a very long discussion on this recently. You may want to check the May, 2000 archives when they are put up in a couple weeks. You can get to the archives of this discussion list via (among other ways): http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html Dave > Hi, > > Forgive my silly questions: > > * To implement an IGP in a large ISP network, which one is better? > OSPF or IS-IS? Why? > * To support MPLS, which one is better? IS-IS of OSPF? > > > Please Comment. Thanks. > > Stewart > * : pusu@nortelnetworks.com > From owner-mpls@UU.NET Tue May 23 23:44: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 ESMTP id XAA17443 for ; Tue, 23 May 2000 23:44: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 QQiqmw19084; Wed, 24 May 2000 03:43:31 GMT Received: by mail-control.mail.uu.net id QQiqmw03758 for mpls-outgoing; Wed, 24 May 2000 03:43: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 QQiqmw03751 for ; Wed, 24 May 2000 03:42: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 QQiqmw14667 for ; Tue, 23 May 2000 23:42:33 -0400 (EDT) Received: from 21cn.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [202.104.32.246]) id QQiqmw14812 for ; Wed, 24 May 2000 03:42:24 GMT Received: from 21cn.com([10.1.0.104]) by 21cn.com(JetMail 2.5.3.0) with SMTP id jm9392bacbb; Wed, 24 May 2000 03:39:55 -0000 Received: from wodc7-1.corprelay.mail.uu.net([192.48.96.68]) by 21cn.com(JetMail 2.3.2.6) with SMTP id /aimcque/jmail.rcv/3/jm238ffa4ef; Thu, 20 Apr 2000 21:08:30 -0000 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 QQilua04492; Thu, 20 Apr 2000 21:14:08 GMT Received: by mail-control.mail.uu.net id QQilua27377 for mpls-outgoing; Thu, 20 Apr 2000 21:13: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 QQilua27372 for ; Thu, 20 Apr 2000 21:13: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 QQilua12167 for ; Thu, 20 Apr 2000 17:13:37 -0400 (EDT) Received: from smtprich.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprich.nortel.com [192.135.215.8]) id QQilua09469 for ; Thu, 20 Apr 2000 21:13:37 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Thu, 20 Apr 2000 16:00:08 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <269W4514>; Thu, 20 Apr 2000 15:59:00 -0500 Message-ID: <6DDA62170439D31185750000F80826AC0247AF73@zmerd004.ca.nortel.com> From: "David Allan" To: Ben Mack-Crane Cc: Ben.Mack-Crane@tellabs.fi, Vishal.Sharma@tellabs.com, mpls@UU.NET, Srinivas.Makam@tellabs.com, Changcheng.Huang@tellabs.com, Ken.Owens@tellabs.com Subject: RE: draft-chang-mpls-path-protection Comments Date: Thu, 20 Apr 2000 15:58:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFAB0B.3EA774D8" X-Orig: 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_01BFAB0B.3EA774D8 Content-Type: text/plain; charset="iso-8859-1" Ben: > > I would broaden the definition as selection suggests to me explicit > > routing, whereas increasing the reliabilty of implicit path construction > > would imply intelligent pruning of options. To a certain extent, > > conservative label retention in an implicit case implies some knowledge > of > > which LSPs would be more optimal than others, and sufficient information > > should be available at the overall L3 layer (not just MPLS topolocy) to > make > > that determination. > > Selection, in this case, was meant generically (not intended to imply > explicit > routing); however, the path protection mechanism draft does not address > reroute recovery (this is covered in other IDs) and so the broadening > you suggest may be out of scope for that ID. Is there a need to address > this > in the framework (I don' think the framework says anything in particular > about > recovery path selection options)? > I'll admit, I've lumped the recovery mechanisms together where protection switching with resource reservation (and the corollary effect, pre-emption) is a superset of reroute recovery. To my mind, where reroute recovery and protection switching collide head on is in every way but the timely allocation of resources on the backup path (where specific resource allocation is required and we're out to be frugal). The livliness mechanisms, path routing, revertive protection etc. have common requirements. Such as timliness, path diversity, minimal disruption of ordering etc. > I was concerned that the broader defintion of protection domain being > proposed > implied that ONE recovery action (e.g., PSL switch) would be able > to recover from any fault in the protection domain. I had trouble seeing > how a fault on an L3 link could be correlated with the working LSP, and > the > PSL informed. The concept of concatenated protection domains is much > simpler, and I think this allows a narrower definition of protection > domain (uniform mechanism). Redundancy/diversity/coordination at > protection > domain boundaries is then the interesting problem. > Agreed, some of this is addressed by redundant egress LERs, as a failure of the egress LER can be addressed in the MPLS domain, a failure downstream of the egress LER is handed by the egress LER or a downstream node in the network. (it wears two hats). If I'm into another MPLS domain, I may have redundant trees, one anchored on the working egress LER and one on the protection egress LER, (I'd probably have that anyway), and if it is some other technology, it presumably would be non-MPLS re-route and may not be as fast, but then thats what you get. > Well... I wasn't trying to say anything about non-MPLS mechanisms. > We are trying to further clarify the framework terminology (a summary > has been posted to the mail list by Vas Makam) and "protection > switching" implies resource reservation. This is not to say that > there are not recovery mechanisms that work otherwise (e.g., reroute > recovery). The path protection mechanism ID is aimed at protection > switching, so resource reservation is assumed there, and this leads > to some desire to have a mechanism that operates simply at the MPLS > layer. > I'm not out to re-invent the rest of the network either... > It makes sense to have a bigger toolbox, as long as we have a reasonable > understanding of the tools and their appropriate use. You have pointed > out > a useful alternative to be added, and we should try to develop a clear > description for the affected IDs. > Agreed. > > > > 2) I don't think we need to overload the recovery space by > expanding > > the protected domain beyond MPLS, only acknowledge that we may > concatenate > > protection mechanisms, they function autonomously, and may have multiple > > points of attachment. Coordination of protection across multiple > transport > > technologies is out of scope if we are to make progress. > > This seems reasonable. > Good, regards Dave ------_=_NextPart_001_01BFAB0B.3EA774D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-chang-mpls-path-protection Comments

    Ben:

    <snip>

    >      I = would broaden the definition as selection suggests to me = explicit
    > routing, whereas increasing the = reliabilty of implicit path construction
    > would imply intelligent pruning = of options. To a certain extent,
    > conservative label retention in = an implicit case implies some knowledge of
    > which LSPs would be more optimal = than others, and sufficient information
    > should be available at the = overall L3 layer (not just MPLS topolocy) to make
    > that determination.

    Selection, in this case, was meant = generically (not intended to imply explicit
    routing); however, the path = protection mechanism draft does not address
    reroute recovery (this is covered in = other IDs) and so the broadening
    you suggest may be out of scope for = that ID.  Is there a need to address this
    in the framework (I don' think the = framework says anything in particular about
    recovery path selection = options)?

    I'll admit, I've = lumped the recovery mechanisms together where protection switching with = resource reservation (and the corollary effect, pre-emption) is a = superset of reroute recovery. To my mind, where reroute recovery and = protection switching collide head on is in every way but the timely = allocation of resources on the backup path (where specific resource = allocation is required and we're out to be frugal). The livliness = mechanisms, path routing, revertive protection etc. have common = requirements. Such as timliness, path diversity, minimal disruption of = ordering etc. 

    <snip>

    I was concerned that the broader = defintion of protection domain being proposed
    implied that ONE recovery action = (e.g., PSL switch) would be able
    to recover from any fault in the = protection domain.  I had trouble seeing
    how a fault on an L3 link could be = correlated with the working LSP, and the
    PSL informed.  The concept of = concatenated protection domains is much
    simpler, and I think this allows a = narrower definition of protection
    domain (uniform mechanism).  = Redundancy/diversity/coordination at protection
    domain boundaries is then the = interesting problem.

    Agreed, some of this = is addressed by redundant egress LERs, as a failure of the egress LER = can be addressed in the MPLS domain, a failure downstream of the egress = LER is handed by the egress LER or a downstream node in the network. = (it wears two hats). If I'm into another MPLS domain, I may have = redundant trees, one anchored on the working egress LER and one on the = protection egress LER, (I'd probably have that anyway), and if it is = some other technology, it presumably would be non-MPLS re-route and may = not be as fast, but then thats what you get.

    <snip>

    Well... I wasn't trying to say = anything about non-MPLS mechanisms.
    We are trying to further clarify the = framework terminology (a summary
    has been posted to the mail list by = Vas Makam) and "protection
    switching" implies resource = reservation.  This is not to say that
    there are not recovery mechanisms = that work otherwise (e.g., reroute
    recovery).  The path protection = mechanism ID is aimed at protection
    switching, so resource reservation is = assumed there, and this leads
    to some desire to have a mechanism = that operates simply at the MPLS
    layer.

    I'm not out to = re-invent the rest of the network either...

    <snip>

    It makes sense to have a bigger = toolbox, as long as we have a reasonable
    understanding of the tools and their = appropriate use.  You have pointed out
    a useful alternative to be added, and = we should try to develop a clear
    description for the affected = IDs.

    Agreed.

    >
    >      2) = I don't think we need to overload the recovery space by = expanding
    > the protected domain beyond = MPLS, only acknowledge that we may concatenate
    > protection mechanisms, they = function autonomously, and may have multiple
    > points of attachment. = Coordination of protection across multiple transport
    > technologies is out of scope if = we are to make progress.

    This seems reasonable.

    Good,

    regards
    Dave

------_=_NextPart_001_01BFAB0B.3EA774D8-- From owner-mpls@UU.NET Wed May 24 00:05: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 AAA17636 for ; Wed, 24 May 2000 00:05: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 QQiqmy01380; Wed, 24 May 2000 04:04:31 GMT Received: by mail-control.mail.uu.net id QQiqmy13548 for mpls-outgoing; Wed, 24 May 2000 04:04: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 QQiqmy13543 for ; Wed, 24 May 2000 04:04: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 QQiqmy22174 for ; Wed, 24 May 2000 00:03:51 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiqmy26267 for ; Wed, 24 May 2000 04:03:03 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id JAA15484 for ; Wed, 24 May 2000 09:28:10 -0600 (GMT) Message-ID: <007601bfada2$246b9240$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: VC Merge support in LDP Date: Mon, 24 Apr 2000 09:34:09 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01BFADD0.3DE9D280" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01BFADD0.3DE9D280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=20 I am implementing LDP-06 and I have question regarding vc merge.=20 When LDP merges 2 LSPs into 1, it should take care that the bandwidth on = the outgoing channel from that point onwards till the egress LER should = be such that it is sufficient for the data merged from 2 LSPs. Suppose 1 = LSP is already setup and later a request comes for the same destination = and an LSR decides to merge this new request with the already existing = LSP. But there is no such provision in the LDP draft to modify the LSP. = So how is this merging supported ?=20 In CR-LDP 03 draft, the LSP can be modified but that has to be triggered = from the Ingress LER and not by any LSR in between the LSP. So how could = we possibly go about doing it, even in CR-LDP ?=20 santosh ------=_NextPart_000_0073_01BFADD0.3DE9D280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello
    I am implementing LDP-06 and I have = question=20 regarding vc merge.
When LDP merges 2 LSPs into 1, it should take care that the = bandwidth on=20 the outgoing channel from that point onwards till the egress LER should = be such=20 that it is sufficient for the data merged from 2 LSPs. Suppose 1 LSP is = already=20 setup and later a request comes for the same destination and an LSR = decides to=20 merge this new request with the already existing LSP. But there is no = such=20 provision in the LDP draft to modify the LSP. So how is this merging = supported ?=20
 
In CR-LDP 03 draft, the LSP can be modified but that has to be = triggered=20 from the Ingress LER and not by any LSR in between the LSP. So how could = we=20 possibly go about doing it, even in CR-LDP ?

santosh
 
------=_NextPart_000_0073_01BFADD0.3DE9D280-- From owner-mpls@UU.NET Wed May 24 00: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 ESMTP id AAA17749 for ; Wed, 24 May 2000 00:27:12 -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 QQiqmz14553; Wed, 24 May 2000 04:26:05 GMT Received: by mail-control.mail.uu.net id QQiqmz15348 for mpls-outgoing; Wed, 24 May 2000 04:25:28 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqmz15342 for ; Wed, 24 May 2000 04:25:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqmz27967 for ; Wed, 24 May 2000 00:25:11 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiqmz08517 for ; Wed, 24 May 2000 04:24:46 GMT Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id JAA15846; Wed, 24 May 2000 09:42:30 -0600 (GMT) Message-ID: <392B57F1.7DB1597E@daewoo.dti.daewoo.co.kr> Date: Wed, 24 May 2000 09:47:54 +0530 From: Neetu Gupta Reply-To: neetug@daewoo.dti.daewoo.co.kr Organization: Daewoo Telecom X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Rohit Chhapolia CC: mpls@UU.NET Subject: Re: LSP Merge issue(Using RSVP) References: <392A6873.BB3D15D0@daewoo.dti.daewoo.co.kr> <392A9391.D312AEAF@globespan.net> Content-Type: multipart/alternative; boundary="------------CA0021FB11B25E61D0100C67" Sender: owner-mpls@UU.NET Precedence: bulk --------------CA0021FB11B25E61D0100C67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please c the comments > Please see the comments below. > > Neetu Gupta wrote: > > > > Hello, > > This topic has been discussed before. But, My query is bit different > > > > from the one previously discussed: > > > > Suppose we have the following setup: > > > > A > > \ > > \ > > C===D===E > > / > > / > > B > > > > Suppose that A sends Path message specifying tunnel endpoint address E. > > Thus LSP 1 is created from A to E. > > Now Suppose another Path Message from B and destined for E comes. > > > > Suppose , it is configured that LSP merging at C is possible > > - Both Path messages have "Merge permitted" flag in Session > > Attributes set > > - Both Path Messages requesting for same Class of Service > > > > When the Path Message from B reaches E, E finds that there is already an > > > > LSP for the session, and since it knows that C can merge the LSPs, it'll > > > > assign a new label with the resources set for this LSP equal to LUB of > > both the flowspecs(if style is Shared Explicit) or sum of both the > > flowspecs(if style is FixedFilter) and delete the label of LSP1 > > - E sends Resv Message to D with Flow Descriptor containing merged > > flowspec and two Filterspec objects (one for A and one for B) and same > > label to both . > > E can not send same label for both filterspecs. > For E to send same label for both Filterspecs, it should know that C > is capable of merging LSPs. Firstly, E does not know which node does the > merging. Secondly, it does not know whether that node is merge capable. >>>> We have a centralized Policy Server that maintains the information that whether the LSR is capable of merging the LSPs or not. This information is available to all the nodes in the MPLS Domain, so E already knows that what all nodes support VC Merging, Now if the Path Message contains RECORD_ROUTE Object that contains the address of C also, then E can send a single label. > > > > - D assigns a new incoming label and remove the old label of LSP1 and > > modify the flowspec with the one coming in the Resv Message and sends > > the Resv Message to C. This Resv also specifies identical label values > > for A and B, and flowdescriptor identical to the one coming in the Resv > > Message from E. > > - Since, C is the merge point. It assigns a new incoming label for B. > > Thus at C, there will be two incoming labels , one for A and one for B. > > It then sends Resv to B. > > > > Is this correct? Can we Merge the LSPs as specified above? > > Please clarify > > -neetu > > -- > Rohit Chhapolia > Globespan, Inc. > mailto:rohit@globespan.net > http://www.globespan.net --------------CA0021FB11B25E61D0100C67 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Please c the comments

Please see the comments below.

Neetu Gupta wrote:
>
> Hello,
>     This topic has been discussed before. But, My query is bit different
>
> from the one previously discussed:
>
> Suppose we have the following setup:
>
>     A
>         \
>           \
>            C===D===E
>           /
>          /
>       B
>
> Suppose that A sends Path message specifying tunnel endpoint address E.
> Thus LSP 1  is created from A to E.
> Now Suppose another Path Message from B and destined for E comes.
>
> Suppose , it is configured that LSP merging at C is possible
> - Both Path messages have "Merge permitted" flag in Session
>   Attributes set
> - Both Path Messages requesting for same Class of Service
>
> When the Path Message from B reaches E, E finds that there is already an
>
> LSP for the session, and since it knows that C can merge the LSPs, it'll
>
> assign a new label with the resources set for this LSP equal to LUB of
> both the flowspecs(if style is Shared Explicit) or sum of both the
> flowspecs(if style is FixedFilter) and delete the label of LSP1
> - E sends Resv Message to D with Flow Descriptor containing merged
> flowspec and two Filterspec objects (one for A and one for B) and same
> label to both .

E can not send same label for both filterspecs.
For E to send same label for both Filterspecs, it should know that C
is capable of merging LSPs. Firstly, E does not know which node does the
merging. Secondly, it does not know whether that node is merge capable.

>>>> We have a centralized Policy Server that maintains the information that whether the LSR is capable of merging the LSPs or not. This information is available to all the nodes in the MPLS Domain, so E already knows that what all nodes support VC Merging, Now if the Path Message contains RECORD_ROUTE Object that contains the address of C also, then E can send a single label.
 

> - D assigns a new incoming label and remove the old label of LSP1 and
> modify the flowspec with the one coming in the Resv Message and sends
> the Resv Message to C.  This Resv also specifies identical label values
> for A and B, and flowdescriptor identical to the one coming in the Resv
> Message from E.
> - Since, C is the merge point.  It assigns a new incoming label for B.
> Thus at C, there will be two incoming labels , one for A and one for B.
>   It then sends Resv to B.
>
> Is this correct? Can we Merge the LSPs as specified above?
> Please clarify
> -neetu

--
Rohit Chhapolia
Globespan, Inc.
mailto:rohit@globespan.net
http://www.globespan.net

  --------------CA0021FB11B25E61D0100C67-- From owner-mpls@UU.NET Wed May 24 05:25: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 ESMTP id FAA01395 for ; Wed, 24 May 2000 05:25: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 QQiqnt21033; Wed, 24 May 2000 09:24:47 GMT Received: by mail-control.mail.uu.net id QQiqnt16525 for mpls-outgoing; Wed, 24 May 2000 09:24: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 QQiqnt16520 for ; Wed, 24 May 2000 09:24:20 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 QQiqnt12593 for ; Wed, 24 May 2000 05:24:07 -0400 (EDT) Received: from TYO202.gate.nec.co.jp by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: TYO202.gate.nec.co.jp [202.247.6.41]) id QQiqnt20637 for ; Wed, 24 May 2000 09:24:06 GMT Received: from mailsv4.nec.co.jp (mailsv4-le1 [192.168.1.93]) by TYO202.gate.nec.co.jp (8.9.3/3.7W00052210) with ESMTP id SAA06365 for ; Wed, 24 May 2000 18:24:05 +0900 (JST) Received: from ipnmail.ipn.abk.nec.co.jp (ipnmail.ipn.abk.nec.co.jp [10.42.124.102]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id SAA14819 for ; Wed, 24 May 2000 18:24:05 +0900 (JST) Received: from ipns888.ipn.abk.nec.co.jp by ipnmail.ipn.abk.nec.co.jp (8.8.8+2.7Wbeta7/3.6W05/29/98) id SAA24122 for ; Wed, 24 May 2000 18:24:04 +0900 (JST) Received: from ipnb220.ipn.abk.nec.co.jp by ipns888.ipn.abk.nec.co.jp (8.8.7+2.7Wbeta7/3.6W-03/16/99) id SAA07852; Wed, 24 May 2000 18:24:03 +0900 (JST) Received: from ABKIPN-IPNB039.ipn.abk.nec.co.jp (ipnb039.ipn.abk.nec.co.jp [10.42.68.39]) by ipnb220.ipn.abk.nec.co.jp (8.9.3/3.7W-ipnb220/20000417) with ESMTP id SAA14056; Wed, 24 May 2000 18:24:02 +0900 Date: Wed, 24 May 2000 18:23:47 +0900 Message-ID: From: b-mizuhara@ak.jp.nec.com To: mpls@UU.NET Subject: A comment on draft-ietf-mpls-atm-03.txt User-Agent: Wanderlust/1.1.0 (Overjoyed) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.4 (i386-*-nt4.0.1381) MULE/4.1 (AOI) Meadow/1.10 (TSUYU) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have a comment on draft-ietf-mpls-atm-03.txt. In the fourth paragraph of section 9: 9. Encapsulation ... The packet's outgoing TTL, and its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim. (Obviously, "CoS" should be read as "Exp") In my opinion, how to encode DiffServ information for packets transferred over a LC-ATM interface is outside scope of this document, and reference to draft-ietf-mpls-diff-ext-04.txt should be included here. Regards, Bun MIZUHARA (Please note address change) 1st Development Department, IP Networks Division, 26-28221, NEC Corporation 1131 Hinode, Abiko city, Chiba 270-1198 Japan +81-471-85-6714 (Phone) +81-471-85-6848 (FAX) From owner-mpls@UU.NET Wed May 24 10:33:31 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 KAA06676 for ; Wed, 24 May 2000 10:33: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 QQiqoo24590; Wed, 24 May 2000 14:32:03 GMT Received: by mail-control.mail.uu.net id QQiqoo22762 for mpls-outgoing; Wed, 24 May 2000 14:31: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 QQiqoo22751 for ; Wed, 24 May 2000 14:31: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 QQiqoo12735 for ; Wed, 24 May 2000 10:30:59 -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 QQiqoo23741 for ; Wed, 24 May 2000 14:30:59 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id KAA25166; Wed, 24 May 2000 10:30:42 -0400 (EDT) Date: Wed, 24 May 2000 10:30:42 -0400 (EDT) From: Rajiv Papneja To: Neetu Gupta cc: mpls@UU.NET Subject: Re: LSP Merge Issue(Using RSVP) In-Reply-To: <392A08DE.17323756@daewoo.dti.daewoo.co.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi there, Please see my comments below On Tue, 23 May 2000, Neetu Gupta wrote: > Hello, > This topic has been discussed before. But, My query is bit different > from the one previously discussed: > > Suppose we have the following setup: > > A > \ > \ > C===D===E > / > / > B > > Suppose that A sends Path message specifying tunnel endpoint address E. > Thus LSP 1 is created from A to E. > Now Suppose another Path Message from B and destined for E comes. > > Suppose , it is configured that LSP merging at C is possible > - Both Path messages have "Merge permitted" flag in Session > Attributes set > - Both Path Messages requesting for same Class of Service > > When the Path Message from B reaches E, E finds that there is already an > LSP for the session, and since it knows that C can merge the LSPs, it'll > assign a new label with the resources set for this LSP equal to LUB of > both the flowspecs(if style is Shared Explicit) or sum of both the > flowspecs(if style is FixedFilter) and delete the label of LSP1 > - E sends Resv Message to D with Flow Descriptor containing merged > flowspec and two Filterspec objects (one for A and one for B) and same > label to both . COMMENTS : If the style is Shared Explicit then the resulting filterspec is the union of the original filterspecs and the resulting flowspec is the largest of the flow spec. However, if LSR B requests for higher bandwidth and LSR A requests for tighter delay, in this case service specific merging is would be required. Then, as you suggested, the resulting flowspec is at least as large as LUB ( least Union Bound). > - D assigns a new incoming label and remove the old label of LSP1 and > modify the flowspec with the one coming in the Resv Message and sends > the Resv Message to C. This Resv also specifies identical label values > for A and B, and flowdescriptor identical to the one coming in the Resv > Message from E. > - Since, C is the merge point. It assigns a new incoming label for B. > Thus at C, there will be two incoming labels , one for A and one for B. > It then sends Resv to B. > > Is this correct? Can we Merge the LSPs as specified above? > Please clarify > -neetu > > > > take care Rajiv AIL, GMU From owner-mpls@UU.NET Wed May 24 10:47:10 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 KAA06928 for ; Wed, 24 May 2000 10:47: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 QQiqop12775; Wed, 24 May 2000 14:45:38 GMT Received: by mail-control.mail.uu.net id QQiqop24153 for mpls-outgoing; Wed, 24 May 2000 14:45:13 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqop24142 for ; Wed, 24 May 2000 14:45:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqoo18813 for ; Wed, 24 May 2000 10:44:42 -0400 (EDT) Received: from mailhost.metro-optix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.metro-optix.com [63.91.47.254]) id QQiqoo11851 for ; Wed, 24 May 2000 14:44:41 GMT Received: by MAILHOST with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 09:36:38 -0500 Message-ID: From: David Wang To: "'mpls@uu.net'" Subject: Question about MPLS deployment and Inter-opbility Date: Wed, 24 May 2000 09:36:36 -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 Dear Friends, From the MPLS resource center I saw that UUnet is deploying MPLS into their networks. Are there any other service providers who is deploying and planning to deploy MPLS into their network? Is there any inter-opbility lab. where people can test the inter-opbility of their MPLS implementation ? Thanks David From owner-mpls@UU.NET Wed May 24 11:03: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 ESMTP id LAA07181 for ; Wed, 24 May 2000 11:03: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 QQiqoq17044; Wed, 24 May 2000 15:02:47 GMT Received: by mail-control.mail.uu.net id QQiqoq27847 for mpls-outgoing; Wed, 24 May 2000 15:02: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 QQiqoq27694 for ; Wed, 24 May 2000 15:02:02 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 QQiqoq25714 for ; Wed, 24 May 2000 11:01:57 -0400 (EDT) Received: from iol.unh.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mars.iol.unh.edu [132.177.121.222]) id QQiqoq24259 for ; Wed, 24 May 2000 15:01:57 GMT Received: (from rdb@localhost) by iol.unh.edu (8.9.3/8.9.3) id KAA05725; Wed, 24 May 2000 10:55:41 -0400 (EDT) From: Rob Blais Message-Id: <200005241455.KAA05725@iol.unh.edu> Subject: Re: Question about MPLS deployment and Inter-opbility To: david.wang@metro-optix.com (David Wang) Date: Wed, 24 May 2000 10:55:40 -0400 (EDT) Cc: mpls@UU.NET ('mpls@uu.net'), rdb@iol.unh.edu (Rob Blais) In-Reply-To: from "David Wang" at May 24, 2000 09:36:36 AM X-Mailer: ELM [version 2.5 PL3] 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 David; > Is there any inter-opbility lab. where people can test the inter-opbility of > their MPLS implementation ? Great question! I'm the manager of the MPLS Consortium at the University of New Hampshire InterOperability Lab. Testing the interoperability of MPLS equipment is exactly what we do. Since starting in February, we've already had one group test, have had several vendors schedule time to test in the lab, and are busy developing test suites for the various protocols involved in MPLS. We're also working on plans for the next group test. Please check out our website at http://www.iol.unh.edu/ For specific information on the MPLS Consortium, click on "Consortiums" and then click on "MPLS" in the left frame. If you have any questions, please let me know. Thank you, /rob --------------------------------------------------------------------- Rob Blais rdb@iol.unh.edu If it is to be, MPLS Consortium Manager Phone: 603-862-4569 it's up to me. ATM Operations Manager Fax: 603-862-4181 UNH InterOperability Lab http://www.iol.unh.edu/ From owner-mpls@UU.NET Wed May 24 11:20: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 LAA07309 for ; Wed, 24 May 2000 11:20: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 QQiqor06564; Wed, 24 May 2000 15:19:49 GMT Received: by mail-control.mail.uu.net id QQiqor05620 for mpls-outgoing; Wed, 24 May 2000 15:19:08 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 QQiqor05608 for ; Wed, 24 May 2000 15:18: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 QQiqor28029 for ; Wed, 24 May 2000 11:17:15 -0400 (EDT) Received: from ertpg15e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg15e1.nortelnetworks.com [47.234.0.36]) id QQiqor04544 for ; Wed, 24 May 2000 15:17:13 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Wed, 24 May 2000 10:56:11 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 10:56:09 -0400 Message-ID: <456E6DB7180ED3118A670000F8BDCA2902EEFAB9@zcard00p.ca.nortel.com> From: "Kainia Cloutier" To: David Wang Cc: "'mpls@uu.net'" Subject: RE: Question about MPLS deployment and Inter-opbility Date: Wed, 24 May 2000 10:55:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC590.31DA8912" 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_01BFC590.31DA8912 Content-Type: text/plain; charset="iso-8859-1" David, UNH and GMU have setup Interoperability labs. Check their web sites at: http://www.gmu.edu/ http://www.unh.edu/ Regards, Kainia Cloutier Nortel Networks (613) 768-4002 -----Original Message----- From: David Wang [mailto:david.wang@metro-optix.com] Sent: Wednesday, May 24, 2000 10:37 AM To: 'mpls@uu.net' Subject: Question about MPLS deployment and Inter-opbility Dear Friends, From the MPLS resource center I saw that UUnet is deploying MPLS into their networks. Are there any other service providers who is deploying and planning to deploy MPLS into their network? Is there any inter-opbility lab. where people can test the inter-opbility of their MPLS implementation ? Thanks David ------_=_NextPart_001_01BFC590.31DA8912 Content-Type: text/html; charset="iso-8859-1" RE: Question about MPLS deployment and Inter-opbility

David,

UNH and GMU have setup Interoperability labs. Check their web sites at:

http://www.gmu.edu/


http://www.unh.edu/


Regards,
Kainia Cloutier
Nortel Networks
(613) 768-4002


-----Original Message-----
From: David Wang [mailto:david.wang@metro-optix.com]
Sent: Wednesday, May 24, 2000 10:37 AM
To: 'mpls@uu.net'
Subject: Question about MPLS deployment and Inter-opbility


Dear Friends,

From the MPLS resource center I saw that UUnet is deploying MPLS into their
networks. Are there any other service providers who is deploying and
planning to deploy MPLS into their network?

Is there any inter-opbility lab. where people can test the inter-opbility of
their MPLS implementation ?

Thanks
David

------_=_NextPart_001_01BFC590.31DA8912-- From owner-mpls@UU.NET Wed May 24 11:34: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 LAA07504 for ; Wed, 24 May 2000 11:34: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 QQiqos16559; Wed, 24 May 2000 15:33:29 GMT Received: by mail-control.mail.uu.net id QQiqos06790 for mpls-outgoing; Wed, 24 May 2000 15:32:51 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqos06773 for ; Wed, 24 May 2000 15:32:37 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqos24723 for ; Wed, 24 May 2000 11:32: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 QQiqos07727 for ; Wed, 24 May 2000 15:32:13 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 IAA10263 for ; Wed, 24 May 2000 08:32:21 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA11405 for mpls@uu.net; Wed, 24 May 2000 11:32: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 QQiqnb16884 for ; Wed, 24 May 2000 04:53:59 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 QQiqnb26311 for ; Wed, 24 May 2000 00:53:48 -0400 (EDT) Received: from web4801.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web4801.mail.yahoo.com [216.115.105.199]) id QQiqnb01129 for ; Wed, 24 May 2000 04:53:48 GMT Message-ID: <20000524045347.10424.qmail@web4801.mail.yahoo.com> Received: from [164.164.56.2] by web4801.mail.yahoo.com; Tue, 23 May 2000 21:53:47 PDT Date: Tue, 23 May 2000 21:53:47 -0700 (PDT) From: B G Ramprasad Torati Subject: MPLS Performance analysis..... To: mpls@UU.NET Cc: ramp@sasi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi I simulated the LDP and MPLS packet switching parts of MPLS by extending the network simulator 2. Now I want to do the performance analysis between the two forwarding paradigms( MPLS forwarding and normal IP forwarding). For this I have taken an example topology and did the following things. 1. Using CBR agent I calculated the delays by using loss monitor as the sink of the CBR packets. 2. Using Ping agents I calculated the round trip time. I did those using both normal IP and MPLS with LDP. But I didn't get any difference between those two forwarding paradigms. I calculated the no. of packets lost using CBR agents. Still I got the same performance for both the above. I used both Link state and Distance Vector dynamic roting protocols while doing this analysis. So can anybody suggest how to do the performance analysis. I am new to this, so please tell how exactly I have to proceed in doing this analysis. Thanks and Regards, Ramp __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Wed May 24 11:34:17 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 LAA07525 for ; Wed, 24 May 2000 11:34: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 QQiqos08770; Wed, 24 May 2000 15:33:27 GMT Received: by mail-control.mail.uu.net id QQiqos06795 for mpls-outgoing; Wed, 24 May 2000 15:32:56 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqos06782 for ; Wed, 24 May 2000 15:32:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqos24648 for ; Wed, 24 May 2000 11:31:38 -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 QQiqos14815 for ; Wed, 24 May 2000 15:31:38 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 IAA21105 for ; Wed, 24 May 2000 08:31:44 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA11393 for mpls@uu.net; Wed, 24 May 2000 11:31:35 -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 QQiqmy13521 for ; Wed, 24 May 2000 04:03: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 QQiqmy22154 for ; Wed, 24 May 2000 00:03:36 -0400 (EDT) From: b-mizuhara@ipn.abk.nec.co.jp Received: from TYO202.gate.nec.co.jp by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: TYO202.gate.nec.co.jp [202.247.6.41]) id QQiqmy26522 for ; Wed, 24 May 2000 04:03:35 GMT Received: from mailsv4.nec.co.jp (mailsv4-le1 [192.168.1.93]) by TYO202.gate.nec.co.jp (8.9.3/3.7W00052210) with ESMTP id NAA13367 for ; Wed, 24 May 2000 13:03:34 +0900 (JST) Received: from ipnmail.ipn.abk.nec.co.jp (ipnmail.ipn.abk.nec.co.jp [10.42.124.102]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id NAA07909 for ; Wed, 24 May 2000 13:03:33 +0900 (JST) Received: from ipns888.ipn.abk.nec.co.jp by ipnmail.ipn.abk.nec.co.jp (8.8.8+2.7Wbeta7/3.6W05/29/98) id NAA12815 for ; Wed, 24 May 2000 13:03:32 +0900 (JST) Received: from ipnb220.ipn.abk.nec.co.jp by ipns888.ipn.abk.nec.co.jp (8.8.7+2.7Wbeta7/3.6W-03/16/99) id NAA06075; Wed, 24 May 2000 13:03:32 +0900 (JST) Received: from ABKIPN-IPNB039.ipn.abk.nec.co.jp (ipnb039.ipn.abk.nec.co.jp [10.42.68.39]) by ipnb220.ipn.abk.nec.co.jp (8.9.3/3.7W-ipnb220/20000417) with ESMTP id NAA13610; Wed, 24 May 2000 13:03:31 +0900 Date: Wed, 24 May 2000 13:03:17 +0900 Message-ID: To: mpls@UU.NET Subject: A comment on draft-ietf-mpls-atm-03.txt User-Agent: Wanderlust/1.1.0 (Overjoyed) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.4 (i386-*-nt4.0.1381) MULE/4.1 (AOI) Meadow/1.10 (TSUYU) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have a comment on draft-ietf-mpls-atm-03.txt. In the fourth paragraph of section 9: 9. Encapsulation ... The packet's outgoing TTL, and its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim. (Obviously, "CoS" should be read as "Exp") In my opinion, how to encode DiffServ information for packets transferred over a LC-ATM interface is outside scope of this document, and reference to draft-ietf-mpls-diff-ext-04.txt should be included here. Regards, Bun MIZUHARA (Please note address change) 1st Development Department, IP Networks Division, 26-28221, NEC Corporation 1131 Hinode, Abiko city, Chiba 270-1198 Japan +81-471-85-6714 (Phone) +81-471-85-6848 (FAX) From owner-mpls@UU.NET Wed May 24 11:34: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 LAA07537 for ; Wed, 24 May 2000 11:34: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 QQiqos15590; Wed, 24 May 2000 15:32:32 GMT Received: by mail-control.mail.uu.net id QQiqos06694 for mpls-outgoing; Wed, 24 May 2000 15:31: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 QQiqos06688 for ; Wed, 24 May 2000 15:31: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 QQiqos29992 for ; Wed, 24 May 2000 11:30:56 -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 QQiqos14312 for ; Wed, 24 May 2000 15:30:56 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 IAA20646 for ; Wed, 24 May 2000 08:31:02 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA11389 for mpls@uu.net; Wed, 24 May 2000 11:30:54 -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 QQiqln27966 for ; Tue, 23 May 2000 18:48: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 QQiqln03799 for ; Tue, 23 May 2000 14:47:53 -0400 (EDT) From: paul.mylotte@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 QQiqln13112 for ; Tue, 23 May 2000 18:47:52 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Tue, 23 May 2000 19:47:37 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Tue, 23 May 2000 19:47:36 +0100 Message-ID: To: mpls@UU.NET Cc: pjw@ip-engineering.bt.com Subject: FW: scalability of LDP Date: Tue, 23 May 2000 19:47: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 Dear All, > > BT is looking at how best it may make contributions to the MPLS WG > to make MPLS most useful and successful for large network operators. > Of particular concern are the scaling properties of MPLS, in particular: > > * What is the stability of LDP as the number of LSRs increase? Given > that as the network gets larger and the number of LSRs increase, the > topology will always be changing due to circuit or hardware faults; can > LDP cope with an ever-changing topology? Compare this with the need > to have route dampening on large BGP networks. > > * Does LDP have similar scaling properties to IGPs? > > * Does LDP fail safe or are there unstable modes it can get into? > > * Have the scaling properties of LDP already been studied? > > * Is it worth BT investing effort in modelling the scaling properties > of LDP or has a lot of work been done on this already? > > Regards, Paul Paul Mylotte IP Naming & Addressing Group Technology BT Adastral Park 01 473 60 6333 email: paul.mylotte@bt.com > > > From owner-mpls@UU.NET Wed May 24 11:35: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 LAA07553 for ; Wed, 24 May 2000 11:35: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 QQiqos17810; Wed, 24 May 2000 15:34:39 GMT Received: by mail-control.mail.uu.net id QQiqos06927 for mpls-outgoing; Wed, 24 May 2000 15:33:59 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqos06906 for ; Wed, 24 May 2000 15:33:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqos24758 for ; Wed, 24 May 2000 11:32:31 -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 QQiqos15547 for ; Wed, 24 May 2000 15:32:31 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 IAA21742 for ; Wed, 24 May 2000 08:32:37 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA11409 for mpls@uu.net; Wed, 24 May 2000 11:32:28 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqnc26416 for ; Wed, 24 May 2000 05:09:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqnc01083 for ; Wed, 24 May 2000 01:08:52 -0400 (EDT) Received: from web1306.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web1306.mail.yahoo.com [128.11.23.156]) id QQiqnc02443 for ; Wed, 24 May 2000 05:08:51 GMT Received: (qmail 9337 invoked by uid 60001); 24 May 2000 05:08:51 -0000 Message-ID: <20000524050851.9336.qmail@web1306.mail.yahoo.com> Received: from [202.247.6.31] by web1306.mail.yahoo.com; Tue, 23 May 2000 22:08:51 PDT Date: Tue, 23 May 2000 22:08:51 -0700 (PDT) From: Vikram Venkataraghavan Subject: MPLS implementation source code? To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I would like to learn the implementation of MPLS through studying some source code which is open to the public. Please advise me as to whether there is any open source code available that I could walk through to get a better understanding. Thank you in advance, Vikram Venkataraghavan __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Wed May 24 11:43: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 LAA07632 for ; Wed, 24 May 2000 11:43: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 QQiqos22819; Wed, 24 May 2000 15:40:59 GMT Received: by mail-control.mail.uu.net id QQiqos08031 for mpls-outgoing; Wed, 24 May 2000 15:40: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 QQiqos08022 for ; Wed, 24 May 2000 15:40: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 QQiqos01478 for ; Wed, 24 May 2000 11:39: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 QQiqos13747 for ; Wed, 24 May 2000 15:39:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA28426 for mpls@uu.net; Wed, 24 May 2000 11:39: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 QQiqos07871 for ; Wed, 24 May 2000 15:39: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 QQiqos22254 for ; Wed, 24 May 2000 11:38:57 -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 QQiqos21013 for ; Wed, 24 May 2000 15:38:56 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA01081; Wed, 24 May 2000 08:37:34 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 08:37:34 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40584@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'B G Ramprasad Torati'" , mpls@UU.NET Cc: ramp@sasi.com Subject: RE: MPLS Performance analysis..... Date: Wed, 24 May 2000 08:34:44 -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, The path taken by MPLS+LDP is exactly the same as the path taken by IP+OSPF/IS-IS. To see any difference you must use CR-LDP and use a less congested path for your LSP. Regards, Shahram >-----Original Message----- >From: B G Ramprasad Torati [mailto:ramp_mpls@yahoo.com] >Sent: Wednesday, May 24, 2000 12:54 AM >To: mpls@UU.NET >Cc: ramp@sasi.com >Subject: MPLS Performance analysis..... > > >Hi > >I simulated the LDP and MPLS packet switching parts of >MPLS by extending the network simulator 2. >Now I want to do the performance analysis between the >two forwarding paradigms( MPLS forwarding and normal >IP forwarding). > >For this I have taken an example topology and did the >following things. >1. Using CBR agent I calculated the delays by using >loss monitor as the sink of the CBR packets. >2. Using Ping agents I calculated the round trip time. > >I did those using both normal IP and MPLS with LDP. >But I didn't get any difference between those two >forwarding paradigms. I calculated the no. of packets >lost using CBR agents. Still I got the same >performance for both the above. I used both Link state >and Distance Vector dynamic roting protocols while >doing this analysis. > >So can anybody suggest how to do the performance >analysis. I am new to this, so please tell how exactly >I have to proceed in doing this analysis. > >Thanks and Regards, >Ramp > >__________________________________________________ >Do You Yahoo!? >Send instant messages & get email alerts with Yahoo! Messenger. >http://im.yahoo.com/ > From owner-mpls@UU.NET Wed May 24 11:54: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 LAA07793 for ; Wed, 24 May 2000 11:54: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 QQiqos14795; Wed, 24 May 2000 15:41:00 GMT Received: by mail-control.mail.uu.net id QQiqos08032 for mpls-outgoing; Wed, 24 May 2000 15:40:19 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqos08017 for ; Wed, 24 May 2000 15:40:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqos25580 for ; Wed, 24 May 2000 11:39:22 -0400 (EDT) Received: from relay1.pair.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: relay1.pair.com [209.68.1.20]) id QQiqos21364 for ; Wed, 24 May 2000 15:39:21 GMT Received: (qmail 11720 invoked from network); 24 May 2000 15:36:13 -0000 Received: from flure.pair.com (HELO asgard) (209.68.1.159) by relay1.pair.com with SMTP; 24 May 2000 15:36:13 -0000 X-pair-Authenticated: 209.68.1.159 From: "Thomas Wolfram" To: , "Vikram Venkataraghavan" Subject: RE: MPLS implementation source code? Date: Wed, 24 May 2000 17:39:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20000524050851.9336.qmail@web1306.mail.yahoo.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07793 > I would like to learn the implementation of MPLS > through studying some source code which is open to the > public. > Please advise me as to whether there is any open > source code available that I could walk through to get > a better understanding. > Thank you in advance, > Vikram Venkataraghavan Check out: - http://www.antd.nist.gov/itg/nistswitch/ (NISTSwitch) - ftp://nero.doit.wisc.edu/pub/mpls/ MfG, Thomas Wolfram -- mailto:thomas@wolfram.net From owner-mpls@UU.NET Wed May 24 12:01:31 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 MAA07949 for ; Wed, 24 May 2000 12:01: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 QQiqot28136; Wed, 24 May 2000 15:59:55 GMT Received: by mail-control.mail.uu.net id QQiqot09865 for mpls-outgoing; Wed, 24 May 2000 15:59:19 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 QQiqot09856 for ; Wed, 24 May 2000 15:59: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 QQiqot24824 for ; Wed, 24 May 2000 11:58:47 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.104.68.2]) id QQiqot27197 for ; Wed, 24 May 2000 15:58:46 GMT Received: by bgslc02.tbg.com with Internet Mail Service (5.5.2448.0) id <27GZLBFX>; Wed, 24 May 2000 09:53:10 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE76F6398@bgslc02.tbg.com> From: Irwin Lazar To: "'David Wang'" , "'mpls@uu.net'" Subject: RE: Question about MPLS deployment and Inter-opbility Date: Wed, 24 May 2000 09:53:00 -0600 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 There are several - see the MPLS FAQ at http://www.mplsrc.com/faq3.shtml Irwin -----Original Message----- From: David Wang [mailto:david.wang@metro-optix.com] Sent: Wednesday, May 24, 2000 10:37 AM To: 'mpls@uu.net' Subject: Question about MPLS deployment and Inter-opbility Dear Friends, From the MPLS resource center I saw that UUnet is deploying MPLS into their networks. Are there any other service providers who is deploying and planning to deploy MPLS into their network? Is there any inter-opbility lab. where people can test the inter-opbility of their MPLS implementation ? Thanks David From owner-mpls@UU.NET Wed May 24 12: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 ESMTP id MAA07961 for ; Wed, 24 May 2000 12:02: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 QQiqou06552; Wed, 24 May 2000 16:00:16 GMT Received: by mail-control.mail.uu.net id QQiqot09874 for mpls-outgoing; Wed, 24 May 2000 15:59:39 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqot09867 for ; Wed, 24 May 2000 15:59:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqot27921 for ; Wed, 24 May 2000 11:57:35 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.104.68.2]) id QQiqot26397 for ; Wed, 24 May 2000 15:57:35 GMT Received: by bgslc02.tbg.com with Internet Mail Service (5.5.2448.0) id <27GZLBFW>; Wed, 24 May 2000 09:51:58 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE76F6397@bgslc02.tbg.com> From: Irwin Lazar To: "'Vikram Venkataraghavan'" , mpls@UU.NET Subject: RE: MPLS implementation source code? Date: Wed, 24 May 2000 09:51:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk See: http://www.mplsrc.com/vendor.shtml for links to open code irwin -----Original Message----- From: Vikram Venkataraghavan [mailto:vikramv25@yahoo.com] Sent: Wednesday, May 24, 2000 1:09 AM To: mpls@UU.NET Subject: MPLS implementation source code? I would like to learn the implementation of MPLS through studying some source code which is open to the public. Please advise me as to whether there is any open source code available that I could walk through to get a better understanding. Thank you in advance, Vikram Venkataraghavan __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Wed May 24 12:34: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 MAA08721 for ; Wed, 24 May 2000 12:34: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 QQiqow28450; Wed, 24 May 2000 16:32:14 GMT Received: by mail-control.mail.uu.net id QQiqow20716 for mpls-outgoing; Wed, 24 May 2000 16:31:43 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 QQiqow20679 for ; Wed, 24 May 2000 16:31: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 QQiqow28762 for ; Wed, 24 May 2000 12:31:22 -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 QQiqow27751 for ; Wed, 24 May 2000 16:31:21 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id SAA19174; Wed, 24 May 2000 18:31:16 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id SAA21161; Wed, 24 May 2000 18:31:16 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14636.980.167643.543102@rasputin.ce.chalmers.se> Date: Wed, 24 May 2000 18:31:16 +0200 (MEST) To: B G Ramprasad Torati Cc: mpls@UU.NET, ramp@sasi.com Subject: Re: MPLS Performance analysis..... In-Reply-To: <20000524045347.10424.qmail@web4801.mail.yahoo.com> References: <20000524045347.10424.qmail@web4801.mail.yahoo.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: otel@ce.chalmers.se Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Hi > I simulated the LDP and MPLS packet switching parts of > MPLS by extending the network simulator 2. > Now I want to do the performance analysis between the > two forwarding paradigms( MPLS forwarding and normal > IP forwarding). Well, with the risk of getting flamed, i would argue that if you want to test _only_ the relative speed of MPLS switching vs. IP forwarding, a simulated environment doesn't sound to be the most appropriate way of doing this. Even more, assuming that you have access to 'real-world' code from a vendor, comparing the relative speeds of the two forwarding paradigms will be non-trivial: You will have to analyze the processing paths for the two cases, install stubs in the software, etc. All in all the relative performance analysis you want is irrelevant IMHO: It all depends on the details of a specific implementation. So, even that if, in theory, "MPLS switching is faster than IP forwarding cause it's based on table indexing and not a longest-prefix match" (or a similar mantra) I would take this type of statements with a grain of salt. Remember, "the devil is in the details".. Cheers, Florian. From owner-mpls@UU.NET Wed May 24 12:38: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 ESMTP id MAA08763 for ; Wed, 24 May 2000 12:38: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 QQiqow01090; Wed, 24 May 2000 16:36:02 GMT Received: by mail-control.mail.uu.net id QQiqow21099 for mpls-outgoing; Wed, 24 May 2000 16:35: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 QQiqow21093 for ; Wed, 24 May 2000 16:35: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 QQiqow08959 for ; Wed, 24 May 2000 12:33:42 -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 QQiqow29398 for ; Wed, 24 May 2000 16:33:27 GMT Received: from zcpzd009.asiapac.nortel.com (actually 47.134.112.12) by ertpg14e1.nortelnetworks.com; Wed, 24 May 2000 06:08:25 -0400 Received: by zcpzd009.asiapac.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 18:05:04 +0800 Message-ID: <6514C2683A0CD311BB5F0000F8100284F0EA7D@zclbd003.asiapac.nortel.com> From: "Stewart Pu" To: mpls@UU.NET Subject: Lambda Switching Date: Wed, 24 May 2000 18:05:02 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC567.8758E8BC" 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_01BFC567.8758E8BC Content-Type: text/plain; charset="iso-8859-1" Hi, all, I have a question about MPLS. Is it possible for MPLS using lambda as the label? I mean, if DWDM technology can provide enough available lambda, can MPLS use lambda as the label? If yes, can we say ' We can achieve optical switching or optical routing.'? But I ever heard that it is impossible to achieve optical routing, is it right? Stewart ------_=_NextPart_001_01BFC567.8758E8BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lambda Switching

Hi, all,

I have a question about MPLS. Is it = possible for MPLS using lambda as the label? I mean, if DWDM technology = can provide enough available lambda, can MPLS use lambda as the label? = If yes, can we say ' We can achieve optical switching or optical = routing.'? But I ever heard that it is impossible to achieve optical = routing, is it right?

Stewart

------_=_NextPart_001_01BFC567.8758E8BC-- From owner-mpls@UU.NET Wed May 24 12:44: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 ESMTP id MAA08823 for ; Wed, 24 May 2000 12:44: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 QQiqow26781; Wed, 24 May 2000 16:43:09 GMT Received: by mail-control.mail.uu.net id QQiqow21674 for mpls-outgoing; Wed, 24 May 2000 16:42:41 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqow21665 for ; Wed, 24 May 2000 16:42:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqow02870 for ; Wed, 24 May 2000 12:42:14 -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 QQiqow26146 for ; Wed, 24 May 2000 16:42:14 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id MAA09614; Wed, 24 May 2000 12:40:32 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'B G Ramprasad Torati'" , Cc: Subject: RE: MPLS Performance analysis..... Date: Wed, 24 May 2000 12:44:16 -0400 Message-ID: <00bb01bfc59f$4d58cb40$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20000524045347.10424.qmail@web4801.mail.yahoo.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit G. Ramprasda writes, > I simulated the LDP and MPLS packet switching parts of > MPLS by extending the network simulator 2. > Now I want to do the performance analysis between the > two forwarding paradigms( MPLS forwarding and normal > IP forwarding). > > For this I have taken an example topology and did the > following things. > 1. Using CBR agent I calculated the delays by using > loss monitor as the sink of the CBR packets. > 2. Using Ping agents I calculated the round trip time. > > I did those using both normal IP and MPLS with LDP. > But I didn't get any difference between those two > forwarding paradigms. I calculated the no. of packets > lost using CBR agents. Still I got the same > performance for both the above. I used both Link state > and Distance Vector dynamic roting protocols while > doing this analysis. > > So can anybody suggest how to do the performance > analysis. I am new to this, so please tell how exactly > I have to proceed in doing this analysis. You are missing the whole point of MPLS in your simulation. MPLS transforms the problem of finding the next hop in the forwarding table using in-exact match based on the destination IP address or a prefix to the problem of finding an exact match of the label. Typical, IP route look ups are expensive and, the best of the binary search algorithm for route look up have the complexity of log (base 2) 2N, with N being the number of routing table entries. The original algorithm implemented in BSD Unix had worst case time of O(W**2), where W is the length of address. Moreover, the search time is un-determinsitic as average and worse case search will take different times. This is totally unacceptable for high speed routing where several terabits of data has to moved in a second. Here comes the MPLS for your rescue. See, this has nothing to with the routing protocols, but how forwarding information is looked from the forwarding tables. With a label in a packet, you can now have exact match look up - in an index array or a hash table. This means that you can do search in O(1) time. Moreover the search time is deterministic. Therefore, now you can have route look ups lot faster and in deterministic times. This is what MPLS is all about. You are not going to see any performance difference with four sources going through four routers in your simulator. Create a few thousand entries in forwarding table and send some high volume data - the effect will become vary clear. Try this exercise in your simulator. Now moving on to CR-LDP effects. CR-LDP provides the ability to control the traffic over certain routes quite similar to IP-source routing. But with LSP previously set for you, the packet doesn't have to carry multiple IP addresses in its header, And the route can be different than provided by hop-by-hop forwarding. If you wish to study this, then study how use of CR-LDP affects the over all traffic/network dynamics of the network both from end-applications perspective, and also taking the network as a single unit. How much more traffic can now be pushed in the network while maintaining similar end to end delays? Have fun. --brijesh Ennovate Networks Inc. From owner-mpls@UU.NET Wed May 24 13:08: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 NAA09144 for ; Wed, 24 May 2000 13:08: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 QQiqoy13387; Wed, 24 May 2000 17:07:53 GMT Received: by mail-control.mail.uu.net id QQiqoy02105 for mpls-outgoing; Wed, 24 May 2000 17:07:35 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqoy02099 for ; Wed, 24 May 2000 17:07:32 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqoy05422 for ; Wed, 24 May 2000 13:06:50 -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 QQiqoy22712 for ; Wed, 24 May 2000 17:06:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA13831 for mpls@uu.net; Wed, 24 May 2000 13:06: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 QQiqoy01959 for ; Wed, 24 May 2000 17:06: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 QQiqoy02918 for ; Wed, 24 May 2000 13:06:13 -0400 (EDT) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQiqoy22344 for ; Wed, 24 May 2000 17:06:12 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA25802; Wed, 24 May 2000 10:06:10 -0700 (PDT) Message-Id: <200005241706.KAA25802@omega.cisco.com> To: "Stewart Pu" cc: mpls@UU.NET Subject: Re: Lambda Switching In-reply-to: Your message of "Wed, 24 May 2000 18:05:02 +0800." <6514C2683A0CD311BB5F0000F8100284F0EA7D@zclbd003.asiapac.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25799.959187969.1@cisco.com> Date: Wed, 24 May 2000 10:06:10 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Stewart, > I have a question about MPLS. Is it possible for MPLS using lambda as the > label? I mean, if DWDM technology can provide enough available lambda, can > MPLS use lambda as the label? Yes. See draft-awduche-mpls-te-optical-01.txt. > If yes, can we say ' We can achieve optical switching or optical routing.'? It depends on how you define "optical switching or optical routing". > But I ever heard that it is impossible to achieve optical routing, > is it right? I guess folks who told you so may reconsider their opinion :-) Yakov. From owner-mpls@UU.NET Wed May 24 13:11: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 NAA09224 for ; Wed, 24 May 2000 13:11: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 QQiqoy15664; Wed, 24 May 2000 17:10:28 GMT Received: by mail-control.mail.uu.net id QQiqoy02220 for mpls-outgoing; Wed, 24 May 2000 17:09:58 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 QQiqoy02215 for ; Wed, 24 May 2000 17:09:53 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 QQiqoy03288 for ; Wed, 24 May 2000 13:09:44 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQiqoy25065 for ; Wed, 24 May 2000 17:09:43 GMT Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA12709; Wed, 24 May 2000 10:09:43 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id KAA02487; Wed, 24 May 2000 10:09:43 -0700 (PDT) Date: Wed, 24 May 2000 10:09:43 -0700 (PDT) Message-Id: <200005241709.KAA02487@cirrus.juniper.net> From: Dave Katz To: paul.mylotte@bt.com CC: mpls@UU.NET, pjw@ip-engineering.bt.com In-reply-to: (paul.mylotte@bt.com) Subject: Re: FW: scalability of LDP Sender: owner-mpls@UU.NET Precedence: bulk The stability of LDP under duress, like that of any complex protocol, is almost entirely dependent on the quality of the implementation. There is nothing inherent in LDP that would keep it from being stable with arbitrarily large topologies (by trading off convergence time). On the other hand, it is as susceptible to avalanche collapse as any other protocol if implemented naively. > * What is the stability of LDP as the number of LSRs increase? Given > that as the network gets larger and the number of LSRs increase, the > topology will always be changing due to circuit or hardware faults; can > LDP cope with an ever-changing topology? Compare this with the need > to have route dampening on large BGP networks. > > * Does LDP have similar scaling properties to IGPs? > > * Does LDP fail safe or are there unstable modes it can get into? > > * Have the scaling properties of LDP already been studied? > > * Is it worth BT investing effort in modelling the scaling properties > of LDP or has a lot of work been done on this already? Modelling has never been a useful predictor of the stability or scaling properties of real-world implementations. From owner-mpls@UU.NET Wed May 24 13:12: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 ESMTP id NAA09309 for ; Wed, 24 May 2000 13:12: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 QQiqoy23631; Wed, 24 May 2000 17:08:07 GMT Received: by mail-control.mail.uu.net id QQiqoy02108 for mpls-outgoing; Wed, 24 May 2000 17:07:39 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqoy02100 for ; Wed, 24 May 2000 17:07:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqoy05433 for ; Wed, 24 May 2000 13:07:03 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQiqoy12709 for ; Wed, 24 May 2000 17:07:02 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19364 for ; Wed, 24 May 2000 13:06:55 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19499 for ; Wed, 24 May 2000 13:06:56 -0400 (EDT) Message-ID: <392C0C39.2432EADB@marconi.com> Date: Wed, 24 May 2000 13:07:05 -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: MPLS Performance analysis..... References: <20000524045347.10424.qmail@web4801.mail.yahoo.com> <14636.980.167643.543102@rasputin.ce.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Florian-Daniel Otel wrote: > > All in all the relative performance analysis you want is irrelevant > IMHO: It all depends on the details of a specific implementation. So, > even that if, in theory, "MPLS switching is faster than IP forwarding > cause it's based on table indexing and not a longest-prefix match" (or > a similar mantra) I would take this type of statements with a grain > of salt. Remember, "the devil is in the details".. Also note that you can't move packets faster than line-rate. A modern PC running the router entirely in softwar can probably keep up with line-rate forwarding between two 10M ethernet ports. Which is also the best that even a highly optimized hardware-based MPLS box can do if it is only equipped with two 10M ethernet ports. (For that matter, the PC might even go faster, since it won't be running any signalling protocols in the wires.) Now, if you step up to a larger configuration - say, 48 ports of 100M Ethernet, or 16 ports of OC-3, you'll find that the PC can't possibly keep up will full line-rate. There are, however, IP routers that can keep up - as will the optimized hardware-based MPLS box. If you go to even larger configurations - say, 16 ports of OC-48, you will probably find that none of the IP routers can keep up with full line-rate, but I would expect many of the MPLS boxes to run at or close to this theoretical maximum. If you go even further, say, to 16 ports of OC-192, I don't think anybody's hardware can keep up, whether IP or MPLS. (At least not right now. Hardware is always improving.) What I'm getting at is simple: If you want to compare technologies, you need to take into consideration what your hardware is capable of and what your requirements are. For some combinations of requirements, hardware and system software, you will not see the same results that simulations and theories will predict. The theoretically "wose" technology may end up working better. Or you may notice no difference whatsoever. And for other combinations, the theoretical results will be absolutely correct. -- David From owner-mpls@UU.NET Wed May 24 13:13: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 NAA09332 for ; Wed, 24 May 2000 13:13: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 QQiqoy27157; Wed, 24 May 2000 17:12:44 GMT Received: by mail-control.mail.uu.net id QQiqoy02467 for mpls-outgoing; Wed, 24 May 2000 17:12:18 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 QQiqoy02455 for ; Wed, 24 May 2000 17:12: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 QQiqoy14264 for ; Wed, 24 May 2000 13:11:49 -0400 (EDT) Received: from fcs-nt1.futsoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: fcs-nt1.futsoft.com [38.242.189.2]) id QQiqoy16695 for ; Wed, 24 May 2000 17:11:48 GMT Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id ; Wed, 24 May 2000 09:59:50 -0700 Received: from rajeshs ([38.242.189.59]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id JAA28560; Wed, 24 May 2000 09:04:52 -0700 Received: by localhost with Microsoft MAPI; Wed, 24 May 2000 10:24:47 -0700 Message-Id: <01BFC56A.4979FD80.rajeshs@futsoft.com> From: Rajesh Kumar Reply-To: "rajeshs@futsoft.com" To: "'Stewart Pu'" , "mpls@uu.net" Subject: RE: Lambda Switching Date: Wed, 24 May 2000 10:24:47 -0700 Organization: Future Communications Software 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 There are some internet drafts focussing on optical networking and use of mpls in these networks. These will be useful places to begin your search. I found some drafts at http://ftp.sunsite.utk.edu/ftp/pub/internet-drafts/ The ones I've seen are: draft-fan-mpls-lambda-signaling-00.txt draft-ip-optical-framework-00.txt draft-awduche-mpls-te-optical-01.txt draft-kompella-mpls-optical-00.txt draft-basak-mpls-oxc-issues-01.txt Rajesh -----Original Message----- From: Stewart Pu [SMTP:pusu@nortelnetworks.com] Sent: Wednesday, May 24, 2000 3:05 AM To: mpls@uu.net Subject: Lambda Switching Hi, all, I have a question about MPLS. Is it possible for MPLS using lambda as the label? I mean, if DWDM technology can provide enough available lambda, can MPLS use lambda as the label? If yes, can we say ' We can achieve optical switching or optical routing.'? But I ever heard that it is impossible to achieve optical routing, is it right? Stewart << File: ATT00004.htm >> From owner-mpls@UU.NET Wed May 24 14:08: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 OAA10383 for ; Wed, 24 May 2000 14:08: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 QQiqpc03491; Wed, 24 May 2000 18:07:41 GMT Received: by mail-control.mail.uu.net id QQiqpc15749 for mpls-outgoing; Wed, 24 May 2000 18: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 QQiqpc15744 for ; Wed, 24 May 2000 18:07:12 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 QQiqpc21636 for ; Wed, 24 May 2000 14:06:47 -0400 (EDT) Received: from osf1.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQiqpc02678 for ; Wed, 24 May 2000 18:06:46 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id OAA07569; Wed, 24 May 2000 14:06:40 -0400 (EDT) Date: Wed, 24 May 2000 14:06:40 -0400 (EDT) From: Rajiv Papneja To: Stewart Pu cc: mpls@UU.NET Subject: Re: Lambda Switching In-Reply-To: <6514C2683A0CD311BB5F0000F8100284F0EA7D@zclbd003.asiapac.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Stewart, There are some links available on the MPL(ambda)S at the following site http://www.ail.gmu.edu/resources.htm (additional information will be available soon) Some more of these are available at the IETF site. Like 1)draft-ip-optical-framework-00.txt 2)draft-lang-mpls-lmp-00.txt 3)draft-lang-mpls-rsvp-oxc-00.txt Happy reading Rajiv On Wed, 24 May 2000, Stewart Pu wrote: > Hi, all, > > I have a question about MPLS. Is it possible for MPLS using lambda as the > label? I mean, if DWDM technology can provide enough available lambda, can > MPLS use lambda as the label? If yes, can we say ' We can achieve optical > switching or optical routing.'? But I ever heard that it is impossible to > achieve optical routing, is it right? > > Stewart > ******************************** 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 Wed May 24 14:10: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 OAA10411 for ; Wed, 24 May 2000 14:10: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 QQiqpc25936; Wed, 24 May 2000 18:09:47 GMT Received: by mail-control.mail.uu.net id QQiqpc15925 for mpls-outgoing; Wed, 24 May 2000 18:09: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 QQiqpc15918 for ; Wed, 24 May 2000 18:09: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 QQiqpc10279 for ; Wed, 24 May 2000 14:08:50 -0400 (EDT) Received: from NOD.RESTON.MCI.NET by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: nod.Reston.mci.net [166.45.6.38]) id QQiqpc04571 for ; Wed, 24 May 2000 18:08:50 GMT Received: from rbonica2 ([166.60.14.229]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JPS4I6FVUS8WW053@shoe.reston.mci.net> for mpls@UU.NET; Wed, 24 May 2000 14:08:50 EST Date: Wed, 24 May 2000 14:08:47 -0400 From: Ron Bonica Subject: RE: Question about MPLS deployment and Inter-opbility In-reply-to: To: David Wang , "'mpls@uu.net'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT > Are there any other service providers who is deploying and > planning to deploy MPLS into their network? > MPLS is also deployed in the vBNS. Ron Bonica vBNS Engineering From owner-mpls@UU.NET Wed May 24 14:50:33 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 OAA11009 for ; Wed, 24 May 2000 14:50: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 QQiqpf03150; Wed, 24 May 2000 18:49:53 GMT Received: by mail-control.mail.uu.net id QQiqpf28129 for mpls-outgoing; Wed, 24 May 2000 18:49:31 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 QQiqpf28124 for ; Wed, 24 May 2000 18:49: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 QQiqpf28020 for ; Wed, 24 May 2000 14:49:00 -0400 (EDT) Received: from osf1.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQiqpf02490 for ; Wed, 24 May 2000 18:48:59 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id OAA08200; Wed, 24 May 2000 14:42:43 -0400 (EDT) Date: Wed, 24 May 2000 14:42:43 -0400 (EDT) From: Rajiv Papneja To: David Wang cc: "'mpls@uu.net'" Subject: Re: Question about MPLS deployment and Inter-opbility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk David: I would like to mention that the Advanced Internet Lab (AIL) at George Mason University is undertaking Interoperability testing focused on MPLS. This effort is sponsored by major router vendors, ISPs, and testing equipment suppliers. The scope of the interoperability testing includes those referred to as "General" and "Specific" Testing. The General interoperability testing will be conducted on an on-going basis according to AIL test plans which are available to its sponsors. These test plans are based on the AIL Core Capability Set document which has input from the industry. The additional information about AIL and forthcoming events at AIL in near future are available under URL address http://www.ail.gmu.edu/ If there are any further questions regarding the lab, you may contact Dr. Bijan Jabbari, Director, Advanced Internet lab (mail to: bjabbari@gmu.edu) Regards Rajiv Papneja On Wed, 24 May 2000, David Wang wrote: > Dear Friends, > > >From the MPLS resource center I saw that UUnet is deploying MPLS into their > networks. Are there any other service providers who is deploying and > planning to deploy MPLS into their network? > > Is there any inter-opbility lab. where people can test the inter-opbility of > their MPLS implementation ? > > Thanks > David > ******************************** 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 Wed May 24 15:22: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 ESMTP id PAA11415 for ; Wed, 24 May 2000 15:22: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 QQiqph15813; Wed, 24 May 2000 19:21:08 GMT Received: by mail-control.mail.uu.net id QQiqph08738 for mpls-outgoing; Wed, 24 May 2000 19:20: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 QQiqph08729 for ; Wed, 24 May 2000 19:20: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 QQiqph02509 for ; Wed, 24 May 2000 15:20:02 -0400 (EDT) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6]) id QQiqph14841 for ; Wed, 24 May 2000 19:20:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed May 24 15:18:26 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn66.pa.bell-labs.com [135.250.1.66]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA15173; Wed, 24 May 2000 15:18:32 -0400 (EDT) Message-ID: <392C2BDF.9659935C@dnrc.bell-labs.com> Date: Wed, 24 May 2000 12:22:07 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: MPLS Performance analysis..... References: <00bb01bfc59f$4d58cb40$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 Kumar wrote: [..] > You are missing the whole point of MPLS in your simulation. > > MPLS transforms the problem of finding the next hop in the forwarding table > using in-exact match based on the destination IP address or a prefix to the > problem of finding an exact match of the label. The relevance of this observation on MPLS network performance is rapidly diminishing. Routers can be built that perform the IP header lookups fast enough to keep large pipes full, at which point whether it is an IP lookup or an MPLS lookup is irrelevant. [..] > Now moving on to CR-LDP effects. CR-LDP provides the ability to control the > traffic over certain routes quite similar to IP-source routing. This is relevant to the performance question. MPLS allows non-shortest paths to be established, and utilized - the key to optimal network-wide load balancing. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Wed May 24 16:27: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 ESMTP id QAA12430 for ; Wed, 24 May 2000 16:27: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 QQiqpl29155; Wed, 24 May 2000 20:26:03 GMT Received: by mail-control.mail.uu.net id QQiqpl22119 for mpls-outgoing; Wed, 24 May 2000 20:25:15 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqpl22112 for ; Wed, 24 May 2000 20:25:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqpl27969 for ; Wed, 24 May 2000 16:21:39 -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 QQiqpl26259 for ; Wed, 24 May 2000 20:21:38 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 NAA21040 for ; Wed, 24 May 2000 13:21:46 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA12400 for mpls@uu.net; Wed, 24 May 2000 16:21:37 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqoj09483 for ; Wed, 24 May 2000 13:24:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqoj08633 for ; Wed, 24 May 2000 09:24:20 -0400 (EDT) Received: from phoenix.ficon-tech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: phoenix.ficon-tech.com [209.125.90.2]) id QQiqoj16260 for ; Wed, 24 May 2000 13:24:20 GMT Received: from globespan.net (192.168.137.202) by phoenix.ficon-tech.com (Worldmail 1.3.167); 24 May 2000 09:34:45 -0400 Message-ID: <392BD7D5.1DABB151@globespan.net> Date: Wed, 24 May 2000 09:23:33 -0400 From: Rohit Chhapolia Organization: Globespan, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: neetug@daewoo.dti.daewoo.co.kr CC: mpls@UU.NET Subject: Re: LSP Merge issue(Using RSVP) References: <392A6873.BB3D15D0@daewoo.dti.daewoo.co.kr> <392A9391.D312AEAF@globespan.net> <392B57F1.7DB1597E@daewoo.dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I think the approach you have mentioned should work. However, what's the problem you are trying to solve here? Multiple LSPs for same session is useful for make-before-break scenarios. Here the first LSP will be released soon after second LSP is setup and so the extra label used between C to E is only for short duration. I don't think it is useful to have centralized policy servers for this purpose. Furthermore, this approach requires that you must have RRO and this RRO needs to be parsed and compared at the egress point to determine the merge point. One point: There is no need for E to allocate new label. It can send old label itself with modified FlowSpec. Rohit Neetu Gupta wrote: > > Please c the comments > > > Please see the comments below. > > > > Neetu Gupta wrote: > > > > > > Hello, > > > This topic has been discussed before. But, My query is bit different > > > > > > from the one previously discussed: > > > > > > Suppose we have the following setup: > > > > > > A > > > \ > > > \ > > > C===D===E > > > / > > > / > > > B > > > > > > Suppose that A sends Path message specifying tunnel endpoint address E. > > > Thus LSP 1 is created from A to E. > > > Now Suppose another Path Message from B and destined for E comes. > > > > > > Suppose , it is configured that LSP merging at C is possible > > > - Both Path messages have "Merge permitted" flag in Session > > > Attributes set > > > - Both Path Messages requesting for same Class of Service > > > > > > When the Path Message from B reaches E, E finds that there is already an > > > > > > LSP for the session, and since it knows that C can merge the LSPs, it'll > > > > > > assign a new label with the resources set for this LSP equal to LUB of > > > both the flowspecs(if style is Shared Explicit) or sum of both the > > > flowspecs(if style is FixedFilter) and delete the label of LSP1 > > > - E sends Resv Message to D with Flow Descriptor containing merged > > > flowspec and two Filterspec objects (one for A and one for B) and same > > > label to both . > > > > E can not send same label for both filterspecs. > > For E to send same label for both Filterspecs, it should know that C > > is capable of merging LSPs. Firstly, E does not know which node does the > > merging. Secondly, it does not know whether that node is merge capable. > > >>>> We have a centralized Policy Server that maintains the information that whether the LSR is capable of merging the LSPs or not. This information is > available to all the nodes in the MPLS Domain, so E already knows that what all nodes support VC Merging, Now if the Path Message contains RECORD_ROUTE Object > that contains the address of C also, then E can send a single label. > > > > > > > > - D assigns a new incoming label and remove the old label of LSP1 and > > > modify the flowspec with the one coming in the Resv Message and sends > > > the Resv Message to C. This Resv also specifies identical label values > > > for A and B, and flowdescriptor identical to the one coming in the Resv > > > Message from E. > > > - Since, C is the merge point. It assigns a new incoming label for B. > > > Thus at C, there will be two incoming labels , one for A and one for B. > > > It then sends Resv to B. > > > > > > Is this correct? Can we Merge the LSPs as specified above? > > > Please clarify > > > -neetu > > > > -- > > Rohit Chhapolia > > Globespan, Inc. > > mailto:rohit@globespan.net > > http://www.globespan.net > > -- Rohit Chhapolia Globespan, Inc. mailto:rohit@globespan.net http://www.globespan.net From owner-mpls@UU.NET Wed May 24 17:14: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 RAA13109 for ; Wed, 24 May 2000 17:14: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 QQiqpo11102; Wed, 24 May 2000 21:13:07 GMT Received: by mail-control.mail.uu.net id QQiqpo03791 for mpls-outgoing; Wed, 24 May 2000 21:12: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 QQiqpo03786 for ; Wed, 24 May 2000 21:12: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 QQiqpo03126 for ; Wed, 24 May 2000 17:12:28 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiqpo10588 for ; Wed, 24 May 2000 21:12:28 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id RAA19526 for ; Wed, 24 May 2000 17:12:28 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: Subject: RE: MPLS Performance analysis..... Date: Wed, 24 May 2000 17:16:13 -0400 Message-ID: <00bc01bfc5c5$4acde560$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <392C2BDF.9659935C@dnrc.bell-labs.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In the previous mail, Grenville Armitage writes: > The relevance of this observation on MPLS network performance > is rapidly diminishing. Routers can be built that perform the > IP header lookups fast enough to keep large pipes full, at which > point whether it is an IP lookup or an MPLS lookup is irrelevant. Yes. Core vendors have built necessary pipelined ASICs that can do wire speed forwarding at OC48 rates, or perhaps even at better speeds (?) with a forwarding table of over 50,000 plus prefixes. For that they had to implement some of the latest search techniques (such as controlled prefix expansions or similar) in HARDWARE. However, with the label look up, even low cost hardware can fill large pipes (just one add and one read instruction). Cheers, --brijesh Ennovate Networks Inc. From owner-mpls@UU.NET Wed May 24 17:53: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 RAA13349 for ; Wed, 24 May 2000 17:53: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 QQiqpr07146; Wed, 24 May 2000 21:53:00 GMT Received: by mail-control.mail.uu.net id QQiqpr06203 for mpls-outgoing; Wed, 24 May 2000 21:52:26 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqpr06170 for ; Wed, 24 May 2000 21:52:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqpr08185 for ; Wed, 24 May 2000 17:51:59 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiqpr27227 for ; Wed, 24 May 2000 21:51:59 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id RAA20296; Wed, 24 May 2000 17:51:51 -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 RAA20275; Wed, 24 May 2000 17:52:03 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200005242152.RAA20275@curtis-lt.avici.com> To: otel@ce.chalmers.se cc: B G Ramprasad Torati , mpls@UU.NET, ramp@sasi.com Reply-To: curtis@avici.com Subject: Re: MPLS Performance analysis..... In-reply-to: Your message of "Wed, 24 May 2000 18:31:16 +0200." <14636.980.167643.543102@rasputin.ce.chalmers.se> Date: Wed, 24 May 2000 17:52:03 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <14636.980.167643.543102@rasputin.ce.chalmers.se>, Florian-Daniel Ot el writes: > > > Hi > > I simulated the LDP and MPLS packet switching parts of > > MPLS by extending the network simulator 2. > > Now I want to do the performance analysis between the > > two forwarding paradigms( MPLS forwarding and normal > > IP forwarding). > > Well, with the risk of getting flamed, i would argue that if you want > to test _only_ the relative speed of MPLS switching vs. IP forwarding, > a simulated environment doesn't sound to be the most appropriate way of > doing this. > > Even more, assuming that you have access to 'real-world' code from a > vendor, comparing the relative speeds of the two forwarding paradigms > will be non-trivial: You will have to analyze the processing paths for > the two cases, install stubs in the software, etc. > > All in all the relative performance analysis you want is irrelevant > IMHO: It all depends on the details of a specific implementation. So, > even that if, in theory, "MPLS switching is faster than IP forwarding > cause it's based on table indexing and not a longest-prefix match" (or > a similar mantra) I would take this type of statements with a grain > of salt. Remember, "the devil is in the details".. > > > Cheers, > > Florian. Florian, The plain fact is that it just doesn't matter. The shortest speed of light delays in any WAN application is on the order of a few milliseconds. Queueing delay can be hundreds of milliseconds if the outbound interface is congested. Modern routers forward IP in a few 10s of microseconds (on fast interfaces). If the path is the same and the same queue is used, then the difference in forwarding speed between an IP route lookup and an MPLS label lookup isn't even measurable and in some (most?) routers the difference is exactly zero. Curtis From owner-mpls@UU.NET Wed May 24 18:11: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 SAA13498 for ; Wed, 24 May 2000 18:11: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 QQiqps18522; Wed, 24 May 2000 22:10:43 GMT Received: by mail-control.mail.uu.net id QQiqps15907 for mpls-outgoing; Wed, 24 May 2000 22:10: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 QQiqps15902 for ; Wed, 24 May 2000 22:10:13 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 QQiqps09660 for ; Wed, 24 May 2000 18:10:02 -0400 (EDT) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQiqps08842 for ; Wed, 24 May 2000 22:10:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed May 24 18:09:14 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA17151; Wed, 24 May 2000 18:09:21 -0400 (EDT) Message-ID: <392C53DF.A1B98EAB@dnrc.bell-labs.com> Date: Wed, 24 May 2000 15:12:47 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: bkumar@ennovatenetworks.com CC: mpls@UU.NET Subject: Re: MPLS Performance analysis..... References: <00bc01bfc5c5$4acde560$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 Kumar wrote: [..] > However, with the label look up, even > low cost hardware can fill large pipes (just one add and one read > instruction). My point is that such distinctions are falling (have fallen?) into just so much background noise compared to (a) the overall costs of operating a network, and (b) the traffic engineering capabilities of non-shortest path LSPs (which probably reduces operational costs far more over a year than the few $$ savings in hardware associated with the label lookup). Not that your observation is wrong, just probably not a key influence on "MPLS performance" overall. cheers, gja From owner-mpls@UU.NET Wed May 24 18:25:45 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 SAA13600 for ; Wed, 24 May 2000 18:25: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 QQiqpt27061; Wed, 24 May 2000 22:25:10 GMT Received: by mail-control.mail.uu.net id QQiqpt17050 for mpls-outgoing; Wed, 24 May 2000 22:24:48 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqpt17042 for ; Wed, 24 May 2000 22:24:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqpt11293 for ; Wed, 24 May 2000 18:24:32 -0400 (EDT) Received: from redbaron.nexabit.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQiqpt26583 for ; Wed, 24 May 2000 22:24:32 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id SAA11805; Wed, 24 May 2000 18:24:29 -0400 Received: from nexabit.com (saule.nexabit.com [135.17.241.201]) by bandito.nexabit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JG3T4TF5; Wed, 24 May 2000 18:24:29 -0400 Message-ID: <392C1E5D.8C4730D5@nexabit.com> Date: Wed, 24 May 2000 14:24:29 -0400 From: Greg Mirsky Organization: Lucent Technologies X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: MPLS Performance analysis..... References: <20000524045347.10424.qmail@web4801.mail.yahoo.com> <14636.980.167643.543102@rasputin.ce.chalmers.se> <392C0C39.2432EADB@marconi.com> Content-Type: multipart/alternative; boundary="------------C516BAF80DA04427DCC869C5" Sender: owner-mpls@UU.NET Precedence: bulk --------------C516BAF80DA04427DCC869C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Charlap wrote: > Florian-Daniel Otel wrote: > > > > All in all the relative performance analysis you want is irrelevant > > IMHO: It all depends on the details of a specific implementation. So, > > even that if, in theory, "MPLS switching is faster than IP forwarding > > cause it's based on table indexing and not a longest-prefix match" (or > > a similar mantra) I would take this type of statements with a grain > > of salt. Remember, "the devil is in the details".. > > Also note that you can't move packets faster than line-rate. > > A modern PC running the router entirely in softwar can probably keep up > with line-rate forwarding between two 10M ethernet ports. Which is also > the best that even a highly optimized hardware-based MPLS box can do if > it is only equipped with two 10M ethernet ports. (For that matter, the > PC might even go faster, since it won't be running any signalling > protocols in the wires.) > > Now, if you step up to a larger configuration - say, 48 ports of 100M > Ethernet, or 16 ports of OC-3, you'll find that the PC can't possibly > keep up will full line-rate. There are, however, IP routers that can > keep up - as will the optimized hardware-based MPLS box. > > If you go to even larger configurations - say, 16 ports of OC-48, you > will probably find that none of the IP routers can keep up with full > line-rate, but I would expect many of the MPLS boxes to run at or close > to this theoretical maximum. > > If you go even further, say, to 16 ports of OC-192, I don't think > anybody's hardware can keep up, whether IP or MPLS. (At least not right > now. Hardware is always improving.) > > I would strongly disagree with two statements presented above. > > What I'm getting at is simple: If you want to compare technologies, you > need to take into consideration what your hardware is capable of and > what your requirements are. > > For some combinations of requirements, hardware and system software, you > will not see the same results that simulations and theories will > predict. The theoretically "wose" technology may end up working > better. Or you may notice no difference whatsoever. And for other > combinations, the theoretical results will be absolutely correct. > > -- David -- 200 Nickerson Road Phone 508 786 2117 Marlborough, MA 01752 Fax 508 460 3332 Lucent Technologies gmirsky@lucent.com Core Routing, INS --------------C516BAF80DA04427DCC869C5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit David Charlap wrote:
Florian-Daniel Otel wrote:
>
> All in all the relative performance analysis you want is irrelevant
> IMHO: It all depends on the details of a specific implementation. So,
> even that if, in theory, "MPLS switching is faster than IP forwarding
> cause it's based on table indexing and not a longest-prefix match" (or
> a similar mantra) I would take this type of  statements with a grain
> of salt. Remember, "the devil is in the details"..

Also note that you can't move packets faster than line-rate.

A modern PC running the router entirely in softwar can probably keep up
with line-rate forwarding between two 10M ethernet ports.  Which is also
the best that even a highly optimized hardware-based MPLS box can do if
it is only equipped with two 10M ethernet ports.  (For that matter, the
PC might even go faster, since it won't be running any signalling
protocols in the wires.)

Now, if you step up to a larger configuration - say, 48 ports of 100M
Ethernet, or 16 ports of OC-3, you'll find that the PC can't possibly
keep up will full line-rate.  There are, however, IP routers that can
keep up - as will the optimized hardware-based MPLS box.

If you go to even larger configurations - say, 16 ports of OC-48, you
will probably find that none of the IP routers can keep up with full
line-rate, but I would expect many of the MPLS boxes to run at or close
to this theoretical maximum.

If you go even further, say, to 16 ports of OC-192, I don't think
anybody's hardware can keep up, whether IP or MPLS.  (At least not right
now.  Hardware is always improving.)
 

I would strongly disagree with two statements presented above.
 
What I'm getting at is simple:  If you want to compare technologies, you
need to take into consideration what your hardware is capable of and
what your requirements are.

For some combinations of requirements, hardware and system software, you
will not see the same results that simulations and theories will
predict.  The theoretically "wose" technology may end up working
better.  Or you may notice no difference whatsoever.  And for other
combinations, the theoretical results will be absolutely correct.

-- David

-- 
200 Nickerson Road        Phone 508 786 2117
Marlborough, MA 01752     Fax   508 460 3332
Lucent Technologies       gmirsky@lucent.com
Core Routing, INS
  --------------C516BAF80DA04427DCC869C5-- From owner-mpls@UU.NET Wed May 24 19:07: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 TAA13941 for ; Wed, 24 May 2000 19:07: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 QQiqpw22427; Wed, 24 May 2000 23:07:18 GMT Received: by mail-control.mail.uu.net id QQiqpw27844 for mpls-outgoing; Wed, 24 May 2000 23:06:48 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 QQiqpw27838 for ; Wed, 24 May 2000 23:06: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 QQiqpw01762 for ; Wed, 24 May 2000 19:06:12 -0400 (EDT) Received: from sean.ebone.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sean.ebone.net [195.158.227.211]) id QQiqpw21655 for ; Wed, 24 May 2000 23:06:12 GMT Received: by sean.ebone.net (Postfix, from userid 1113) id 460FB87A; Thu, 25 May 2000 01:06:11 +0200 (CEST) To: mpls@UU.NET Subject: Re: MPLS Performance analysis..... Message-Id: <20000524230611.460FB87A@sean.ebone.net> Date: Thu, 25 May 2000 01:06:11 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-mpls@UU.NET Precedence: bulk Several people write: > [lots of commentary about how wonderful MPLS is at making forwarding fast] You are analysing the performance of MPLS using the wrong metric. I think MPLS performs exactly as intended. Ipsilon basically died, and not even Nokia could revive it. UUNET found a new layer-2 religion, essentially killing backbone ATM. Many companies are distracted from actually learning how to do IP routing. Score: MPLS 3, Rest Of World 0. Sean. From owner-mpls@UU.NET Wed May 24 20:13: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 UAA14508 for ; Wed, 24 May 2000 20:13: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 QQiqqa00699; Thu, 25 May 2000 00:12:24 GMT Received: by mail-control.mail.uu.net id QQiqqa09254 for mpls-outgoing; Thu, 25 May 2000 00:12: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 QQiqqa09245 for ; Thu, 25 May 2000 00:11: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 QQiqqa08238 for ; Wed, 24 May 2000 20:11:39 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiqqa19041 for ; Thu, 25 May 2000 00:11:38 GMT Received: from kbalalap by alpha.tellium.com (SMI-8.6/SMI-SVR4) id UAA19227; Wed, 24 May 2000 20:05:34 -0400 From: "Krishna Bala" To: "Yakov Rekhter" , "Stewart Pu" Cc: Subject: RE: Lambda Switching Date: Wed, 24 May 2000 17:49:57 -0400 Message-ID: <002601bfc5ca$00ba7ab0$425cc697@tempest> 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <200005241706.KAA25802@omega.cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Stewart, If you define Optical Switching as the ability to switch large pipes in a circuit switched fashion .... yes, this is the core competence of optics. If you define Optical Routing as the ability to switch individual packets in a packet switched manner .... no, this is not the strength of optics. The biggest barrier to entry for optics here is the inability of optics to perform buffering. Large spools of fiber are used as "delay lines" to emulate buffering. Krishna Bala Tellium > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yakov > Rekhter > Sent: Wednesday, May 24, 2000 1:06 PM > To: Stewart Pu > Cc: mpls@UU.NET > Subject: Re: Lambda Switching > > > Stewart, > > > I have a question about MPLS. Is it possible for MPLS using > lambda as the > > label? I mean, if DWDM technology can provide enough available > lambda, can > > MPLS use lambda as the label? > > Yes. See draft-awduche-mpls-te-optical-01.txt. > > > If yes, can we say ' We can achieve optical switching or > optical routing.'? > > It depends on how you define "optical switching or optical routing". > > > But I ever heard that it is impossible to achieve optical routing, > > is it right? > > I guess folks who told you so may reconsider their opinion :-) > > Yakov. > > From owner-mpls@UU.NET Wed May 24 21:12: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 VAA15150 for ; Wed, 24 May 2000 21:12: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 QQiqqe04443; Thu, 25 May 2000 01:11:40 GMT Received: by mail-control.mail.uu.net id QQiqqe20276 for mpls-outgoing; Thu, 25 May 2000 01:11:22 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqqe20217 for ; Thu, 25 May 2000 01:11:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqqe23826 for ; Wed, 24 May 2000 21:00:39 -0400 (EDT) Received: from mail.krioukov.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cj114416-a.reston1.va.home.com [24.15.191.36]) id QQiqqe28029 for ; Thu, 25 May 2000 01:00:37 GMT Received: from VA1ENG128 (fw-1.winstar.com [207.86.108.130]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id UAA08664; Wed, 24 May 2000 20:40:02 -0400 From: "Dmitri Krioukov" To: "Krishna Bala" , "Yakov Rekhter" , "Stewart Pu" Cc: Subject: RE: Lambda Switching Date: Wed, 24 May 2000 21:15:24 -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.2919.6700 In-reply-to: <002601bfc5ca$00ba7ab0$425cc697@tempest> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit i have a question on optical buffering -- what are the available technologies here or links/references to them? (to be more precise: are they just pools of fiber or specially designed mirror boxes, etc.) thanks, -- dima. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Krishna > Bala > Sent: Wednesday, May 24, 2000 5:50 PM > To: Yakov Rekhter; Stewart Pu > Cc: mpls@UU.NET > Subject: RE: Lambda Switching > > > Stewart, > If you define Optical Switching as the ability to switch large pipes in a > circuit switched fashion .... yes, this is the core competence of optics. > > If you define Optical Routing as the ability to switch individual packets > in a packet switched manner .... no, this is not the strength of > optics. The > biggest barrier to entry for optics here is the inability of optics to > perform > buffering. Large spools of fiber are used as "delay lines" to emulate > buffering. > > > Krishna Bala > Tellium > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yakov > > Rekhter > > Sent: Wednesday, May 24, 2000 1:06 PM > > To: Stewart Pu > > Cc: mpls@UU.NET > > Subject: Re: Lambda Switching > > > > > > Stewart, > > > > > I have a question about MPLS. Is it possible for MPLS using > > lambda as the > > > label? I mean, if DWDM technology can provide enough available > > lambda, can > > > MPLS use lambda as the label? > > > > Yes. See draft-awduche-mpls-te-optical-01.txt. > > > > > If yes, can we say ' We can achieve optical switching or > > optical routing.'? > > > > It depends on how you define "optical switching or optical routing". > > > > > But I ever heard that it is impossible to achieve optical routing, > > > is it right? > > > > I guess folks who told you so may reconsider their opinion :-) > > > > Yakov. > > > > From owner-mpls@UU.NET Wed May 24 22:01: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 WAA16400 for ; Wed, 24 May 2000 22:01: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 QQiqqi03270; Thu, 25 May 2000 02:01:13 GMT Received: by mail-control.mail.uu.net id QQiqqi24625 for mpls-outgoing; Thu, 25 May 2000 02:00: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 QQiqqi24327 for ; Thu, 25 May 2000 02:00: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 QQiqqi00252 for ; Wed, 24 May 2000 22:00:18 -0400 (EDT) Received: from cis.ohio-state.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cis.ohio-state.edu [164.107.115.5]) id QQiqqi02576 for ; Thu, 25 May 2000 02:00:17 GMT Received: from iota.cis.ohio-state.edu (rjaganna@iota.cis.ohio-state.edu [164.107.112.17]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id WAA08687; Wed, 24 May 2000 22:00:17 -0400 (EDT) Received: from localhost (rjaganna@localhost) by iota.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id WAA19135; Wed, 24 May 2000 22:00:17 -0400 (EDT) X-Authentication-Warning: iota.cis.ohio-state.edu: rjaganna owned process doing -bs Date: Wed, 24 May 2000 22:00:17 -0400 (EDT) From: Ramesh Jagannathan To: Dmitri Krioukov cc: mpls@UU.NET Subject: RE: Lambda Switching In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Here are some good references to start with for optical buffering as well as optical switching: - Photonic Packet Switching: An overview; Rodney S. TUCKER and Wen De ZHONG; Invited Paper; Joint Special Issue on Photonics in Switching: Systems and Devices; IEICE Trans Electron., Vol. E82-C No.2 pp. 202-212; February 1999. URL: http://search.ieice.or.jp/ These references might also be useful: - Transparent optical packet switching: The European ACTS KEOPS project approach; Guillermot, Christian; et. al. Journal of Lightwave Technology v16 n12 1998 p.2117-2134. - Transparent Optical Packet Switching: Network Architecture and Demonstrators in the KEOPS project; Gambini, Piero; et al. IEEE Journal on Selected Areas in Communications v16 n7 1998 p.1245-1259. - Network and system concepts for optical packet switching; Renaud, Monique; et al. Proc. IEEE v82 Nov. 1994 pp. 1650-1667. Hope this would be helpful. Thanks, Ramesh Jagannathan. On Wed, 24 May 2000, Dmitri Krioukov wrote: > i have a question on optical buffering -- > what are the available technologies here > or links/references to them? (to be more > precise: are they just pools of fiber > or specially designed mirror boxes, etc.) > > thanks, > -- > dima. ----------------------------------------------+------------------------------ OFFICE | HOME 390 Dreese Laboratories | 30 East Lane Avenue 2015 Neil Avenue | Apt. #302 Columbus, OH-43210 | Columbus, OH-43201. Phone: 614-292-7344 | Phone: 614-421-9246 email: rjaganna@cis.ohio-state.edu | URL: http://www.cis.ohio-state.edu/~rjaganna | ----------------------------------------------+------------------------------ Don't work for recognition, do work worthy of recognition. ----------------------------------------------------------------------------- From owner-mpls@UU.NET Wed May 24 22:43: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 WAA17586 for ; Wed, 24 May 2000 22:43: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 QQiqqk28630; Thu, 25 May 2000 02:43:14 GMT Received: by mail-control.mail.uu.net id QQiqqk04049 for mpls-outgoing; Thu, 25 May 2000 02:42:53 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 QQiqqk04043 for ; Thu, 25 May 2000 02:42: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 QQiqqk03703 for ; Wed, 24 May 2000 22:42:36 -0400 (EDT) From: lijianping@mail.zte.com.cn Received: from mail.zhongxing.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) id QQiqqk27637 for ; Thu, 25 May 2000 02:41:34 GMT Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 482568EA.000ED5EF ; Thu, 25 May 2000 10:42:02 +0800 X-Lotus-FromDomain: ZTE_LTD To: mpls@UU.NET Message-ID: <482568EA.000E534E.00@mail.zhongxing.com> Date: Thu, 25 May 2000 10:36:28 +0800 Subject: mpls loop prevention Sender: owner-mpls@UU.NET Precedence: bulk Hi, I want to simulate "mpls loop prevention mechanism" in the mpls public source code, but I have one things not clear: that is: How to send thread object, in what encapsulation? Please advise me how to do this. Thanks in advance! Lijianping. From owner-mpls@UU.NET Wed May 24 23:27:12 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 XAA17804 for ; Wed, 24 May 2000 23:27:12 -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 QQiqqn22931; Thu, 25 May 2000 03:26:25 GMT Received: by mail-control.mail.uu.net id QQiqqn15062 for mpls-outgoing; Thu, 25 May 2000 03:25: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 QQiqqn15057 for ; Thu, 25 May 2000 03:25:40 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 QQiqqn06590 for ; Wed, 24 May 2000 23:25:18 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiqqn08688 for ; Thu, 25 May 2000 03:24:38 GMT Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id IAA24619; Thu, 25 May 2000 08:48:27 -0600 (GMT) Message-ID: <392C9CC6.7A46E37D@daewoo.dti.daewoo.co.kr> Date: Thu, 25 May 2000 08:53:51 +0530 From: Neetu Gupta Reply-To: neetug@daewoo.dti.daewoo.co.kr Organization: Daewoo Telecom X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Rohit Chhapolia CC: mpls@UU.NET Subject: Re: LSP Merge issue(Using RSVP) References: <392A6873.BB3D15D0@daewoo.dti.daewoo.co.kr> <392A9391.D312AEAF@globespan.net> <392B57F1.7DB1597E@daewoo.dti.daewoo.co.kr> <392BD7D5.1DABB151@globespan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit We want to provide VC Merge Support in the MPLS Domain. For differentiated Signalling, we creating LSPs between all the Edge Routers. so to reduce the number of labels, we want to provide VCMerge Support. Also c my comments below: Rohit Chhapolia wrote: > I think the approach you have mentioned should work. However, > what's the problem you are trying to solve here? Multiple > LSPs for same session is useful for make-before-break scenarios. > Here the first LSP will be released soon after second LSP is setup > and so the extra label used between C to E is only for short > duration. I don't think it is useful to have centralized policy > servers for this purpose. Furthermore, this approach requires > that you must have RRO and this RRO needs to be parsed and compared > at the egress point to determine the merge point. > > One point: > There is no need for E to allocate new label. It can send old > label itself with modified FlowSpec. > This can be done. > Rohit > > Neetu Gupta wrote: > > > > Please c the comments > > > > > Please see the comments below. > > > > > > Neetu Gupta wrote: > > > > > > > > Hello, > > > > This topic has been discussed before. But, My query is bit different > > > > > > > > from the one previously discussed: > > > > > > > > Suppose we have the following setup: > > > > > > > > A > > > > \ > > > > \ > > > > C===D===E > > > > / > > > > / > > > > B > > > > > > > > Suppose that A sends Path message specifying tunnel endpoint address E. > > > > Thus LSP 1 is created from A to E. > > > > Now Suppose another Path Message from B and destined for E comes. > > > > > > > > Suppose , it is configured that LSP merging at C is possible > > > > - Both Path messages have "Merge permitted" flag in Session > > > > Attributes set > > > > - Both Path Messages requesting for same Class of Service > > > > > > > > When the Path Message from B reaches E, E finds that there is already an > > > > > > > > LSP for the session, and since it knows that C can merge the LSPs, it'll > > > > > > > > assign a new label with the resources set for this LSP equal to LUB of > > > > both the flowspecs(if style is Shared Explicit) or sum of both the > > > > flowspecs(if style is FixedFilter) and delete the label of LSP1 > > > > - E sends Resv Message to D with Flow Descriptor containing merged > > > > flowspec and two Filterspec objects (one for A and one for B) and same > > > > label to both . > > > > > > E can not send same label for both filterspecs. > > > For E to send same label for both Filterspecs, it should know that C > > > is capable of merging LSPs. Firstly, E does not know which node does the > > > merging. Secondly, it does not know whether that node is merge capable. > > > > >>>> We have a centralized Policy Server that maintains the information that whether the LSR is capable of merging the LSPs or not. This information is > > available to all the nodes in the MPLS Domain, so E already knows that what all nodes support VC Merging, Now if the Path Message contains RECORD_ROUTE Object > > that contains the address of C also, then E can send a single label. > > > > > > > > > > > > - D assigns a new incoming label and remove the old label of LSP1 and > > > > modify the flowspec with the one coming in the Resv Message and sends > > > > the Resv Message to C. This Resv also specifies identical label values > > > > for A and B, and flowdescriptor identical to the one coming in the Resv > > > > Message from E. > > > > - Since, C is the merge point. It assigns a new incoming label for B. > > > > Thus at C, there will be two incoming labels , one for A and one for B. > > > > It then sends Resv to B. > > > > > > > > Is this correct? Can we Merge the LSPs as specified above? > > > > Please clarify > > > > -neetu > > > > > > -- > > > Rohit Chhapolia > > > Globespan, Inc. > > > mailto:rohit@globespan.net > > > http://www.globespan.net > > > > > > -- > Rohit Chhapolia > Globespan, Inc. > mailto:rohit@globespan.net > http://www.globespan.net From owner-mpls@UU.NET Thu May 25 02: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 CAA01194 for ; Thu, 25 May 2000 02: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 QQiqqz24461; Thu, 25 May 2000 06:15:43 GMT Received: by mail-control.mail.uu.net id QQiqqz20291 for mpls-outgoing; Thu, 25 May 2000 06:15: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 QQiqqz20286 for ; Thu, 25 May 2000 06:15: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 QQiqqz19530 for ; Thu, 25 May 2000 02:15:07 -0400 (EDT) Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQiqqz13822 for ; Thu, 25 May 2000 06:15:07 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id IAA29925; Thu, 25 May 2000 08:15:06 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id IAA21308; Thu, 25 May 2000 08:15:06 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14636.50410.52770.352863@rasputin.ce.chalmers.se> Date: Thu, 25 May 2000 08:15:06 +0200 (MEST) To: curtis@avici.com Cc: mpls@UU.NET, ramp@sasi.com Subject: Re: MPLS Performance analysis..... In-Reply-To: <200005242152.RAA20275@curtis-lt.avici.com> References: <14636.980.167643.543102@rasputin.ce.chalmers.se> <200005242152.RAA20275@curtis-lt.avici.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: otel@ce.chalmers.se Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I couldn't rezist to beat up the dead dog with just one more posting...;> > Florian, > The plain fact is that it just doesn't matter. The shortest speed of > light delays in any WAN application is on the order of a few > milliseconds. Queueing delay can be hundreds of milliseconds if the > outbound interface is congested. Modern routers forward IP in a few > 10s of microseconds (on fast interfaces). If the path is the same and > the same queue is used, then the difference in forwarding speed > between an IP route lookup and an MPLS label lookup isn't even > measurable and in some (most?) routers the difference is exactly zero. That was my point exactly when i said that this type of measurement, even done with production router software, is irrelevant. As some people already pointed out, IP routing software can be (and is) done as fast as MPLS switching, e.g. hardw implementation, pipelined ASICs, hashing, advanced searching techniques, routing table compression, etc, etc. It's a whole world here, i don't even dare to open this Pandorra's box here.. Back to the original posting, I really cannot imagine any non-trivial tests aiming to prove that 'MPLS is faster than IP' (yes, the statement doesn't make much sense). One such example might (arguably) be the ability to do source routing at lower costs than IP-in-IP tunneling/ IP source routing. Again, MPLS strongest points aren't performance but the network engineering capabilities it offers, > Curtis Cheers, Florian. From owner-mpls@UU.NET Thu May 25 04:46: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 EAA02037 for ; Thu, 25 May 2000 04:46: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 QQiqrj13981; Thu, 25 May 2000 08:45:16 GMT Received: by mail-control.mail.uu.net id QQiqri15178 for mpls-outgoing; Thu, 25 May 2000 08:44:46 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 QQiqri15169 for ; Thu, 25 May 2000 08:44: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 QQiqri23181 for ; Thu, 25 May 2000 04:44:24 -0400 (EDT) Received: from pacificpost.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 186-host253.in2net.com [209.53.186.253]) id QQiqri05125 for ; Thu, 25 May 2000 08:44:24 GMT Received: from pacificpost.com [192.168.2.51] by pacificpost.com (SMTPD32-5.05) id A93810C90140; Thu, 25 May 2000 01:50:00 -0700 From: "Khaled Elsayed" Reply-To: "Khaled Elsayed" Date: Thu, 25 May 100 01:50:01 -0700 To: mpls@UU.NET, B G Ramprasad Torati CC: ramp@sasi.com Subject: Re: MPLS Performance analysis..... Message-Id: <200005250150146.SM00129@pacificpost.com> Sender: owner-mpls@UU.NET Precedence: bulk As other people said, it is not surprising you would get the same results. You would need to come up with a scenario where if you use tradional routing versus proper traffic engineering as in MPLS, the difference in the peformance will be clear. However, your scenario should be as realistic as possible, i.e. it can happen in an IP-based network. This is the difficult part. The rest should be easy. BR, Khaled Elsayed ---------- Original Message ---------------------------------- From: B G Ramprasad Torati Date: Tue, 23 May 2000 21:53:47 -0700 (PDT) >Hi > >I simulated the LDP and MPLS packet switching parts of >MPLS by extending the network simulator 2. >Now I want to do the performance analysis between the >two forwarding paradigms( MPLS forwarding and normal >IP forwarding). > >For this I have taken an example topology and did the >following things. >1. Using CBR agent I calculated the delays by using >loss monitor as the sink of the CBR packets. >2. Using Ping agents I calculated the round trip time. > >I did those using both normal IP and MPLS with LDP. >But I didn't get any difference between those two >forwarding paradigms. I calculated the no. of packets >lost using CBR agents. Still I got the same >performance for both the above. I used both Link state >and Distance Vector dynamic roting protocols while >doing this analysis. > >So can anybody suggest how to do the performance >analysis. I am new to this, so please tell how exactly >I have to proceed in doing this analysis. > >Thanks and Regards, >Ramp > >__________________________________________________ >Do You Yahoo!? >Send instant messages & get email alerts with Yahoo! Messenger. >http://im.yahoo.com/ > > From owner-mpls@UU.NET Thu May 25 04:49: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 ESMTP id EAA02066 for ; Thu, 25 May 2000 04:49: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 QQiqrj06442; Thu, 25 May 2000 08:45:54 GMT Received: by mail-control.mail.uu.net id QQiqrj15369 for mpls-outgoing; Thu, 25 May 2000 08:45:27 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 QQiqrj15362 for ; Thu, 25 May 2000 08:45:15 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 QQiqri01177 for ; Thu, 25 May 2000 04:44:58 -0400 (EDT) Received: from pacificpost.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 186-host253.in2net.com [209.53.186.253]) id QQiqri05393 for ; Thu, 25 May 2000 08:44:58 GMT Received: from pacificpost.com [192.168.2.51] by pacificpost.com (SMTPD32-5.05) id A95A1B740072; Thu, 25 May 2000 01:50:34 -0700 From: "Khaled Elsayed" Reply-To: "Khaled Elsayed" Date: Thu, 25 May 100 01:50:34 -0700 To: mpls@UU.NET, B G Ramprasad Torati CC: ramp@sasi.com, khaled@ieee.org Subject: Re: MPLS Performance analysis..... Message-Id: <200005250150704.SM00129@pacificpost.com> Sender: owner-mpls@UU.NET Precedence: bulk As other people said, it is not surprising you would get the same results. You would need to come up with a scenario where if you use tradional routing versus proper traffic engineering as in MPLS, the difference in the peformance will be clear. However, your scenario should be as realistic as possible, i.e. it can happen in an IP-based network. This is the difficult part. The rest should be easy. BR, Khaled Elsayed ---------- Original Message ---------------------------------- From: B G Ramprasad Torati Date: Tue, 23 May 2000 21:53:47 -0700 (PDT) >Hi > >I simulated the LDP and MPLS packet switching parts of >MPLS by extending the network simulator 2. >Now I want to do the performance analysis between the >two forwarding paradigms( MPLS forwarding and normal >IP forwarding). > >For this I have taken an example topology and did the >following things. >1. Using CBR agent I calculated the delays by using >loss monitor as the sink of the CBR packets. >2. Using Ping agents I calculated the round trip time. > >I did those using both normal IP and MPLS with LDP. >But I didn't get any difference between those two >forwarding paradigms. I calculated the no. of packets >lost using CBR agents. Still I got the same >performance for both the above. I used both Link state >and Distance Vector dynamic roting protocols while >doing this analysis. > >So can anybody suggest how to do the performance >analysis. I am new to this, so please tell how exactly >I have to proceed in doing this analysis. > >Thanks and Regards, >Ramp > >__________________________________________________ >Do You Yahoo!? >Send instant messages & get email alerts with Yahoo! Messenger. >http://im.yahoo.com/ > > From owner-mpls@UU.NET Thu May 25 05:12:17 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 FAA02240 for ; Thu, 25 May 2000 05:12:17 -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 QQiqrk27342; Thu, 25 May 2000 09:10:45 GMT Received: by mail-control.mail.uu.net id QQiqrk25240 for mpls-outgoing; Thu, 25 May 2000 09:10:28 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqrk25223 for ; Thu, 25 May 2000 09:10:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqrk25467 for ; Thu, 25 May 2000 05:01:09 -0400 (EDT) Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQiqrk15522 for ; Thu, 25 May 2000 09:01:08 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id LAA17845; Thu, 25 May 2000 11:01:06 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id LAA21382; Thu, 25 May 2000 11:01:04 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14636.60368.720999.810741@rasputin.ce.chalmers.se> Date: Thu, 25 May 2000 11:01:04 +0200 (MEST) To: B G Ramprasad Torati Cc: curtis@avici.com, mpls@UU.NET Subject: Re: MPLS Performance analysis..... In-Reply-To: References: <14636.50410.52770.352863@rasputin.ce.chalmers.se> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: otel@ce.chalmers.se Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > What are the network engineering capabilities MPLS offers extra over IP. Well, it's a rather long story and I will not discuss them here. I suggest you do a bit of basic MPLS reading first. A good start can be the IEEE Communication Magazine issues of Dec. 1999 and Jan 2000 and IEEE Network Mag. of Mar/Apr 2000. They are general and recent enough to provide enough food for thougt. Alternatively, look for general MPLS white papers and presentations and read them w/ a critical eye. They should give you at least a couple of hints. > HOw I can show them using the simulation. I want to show how MPLS is > advantageous over normal IP in as many aspects as I can, using my MPLS > simulation (using ns). > So please help in this. Again, try to do some homeworks first and then ask more specific questions. For an good example on how a simulation environment was used to prove some of MPLS points please see http://www.cis.ohio-state.edu/~jain/papers/mpls-te-anal.htm > Thanks and Regards, > B G Ramprasad Torati Good luck, Florian. From owner-mpls@UU.NET Thu May 25 07:01: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 HAA03353 for ; Thu, 25 May 2000 07:01: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 QQiqrs25849; Thu, 25 May 2000 11:00:38 GMT Received: by mail-control.mail.uu.net id QQiqrs10051 for mpls-outgoing; Thu, 25 May 2000 11:00:09 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqrs10003 for ; Thu, 25 May 2000 11:00:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqrr02038 for ; Thu, 25 May 2000 06:54:41 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiqrr15589 for ; Thu, 25 May 2000 10:54:16 GMT Received: from param1 (seth [165.133.13.20]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id QAA01829 for ; Thu, 25 May 2000 16:10:00 -0600 (GMT) Message-ID: <021801bfc636$7bebfc60$140d85a5@dti.daewoo.co.kr> From: "Naveen Seth" To: Subject: MPLS domain - AS Date: Thu, 25 May 2000 16:16:07 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01BFC664.88B4E910" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0215_01BFC664.88B4E910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The definition of MPLS domain in the draft-ietf-mpls-arch-06.txt says = that the MPLS nodes are in one routing or administrative domain. 1. Does it imply that we cannot have 2 AS(Autonomous System) within the = same MPLS domain? 2. Is an MPLS domain contained within an AS?. 3. Can we have more than one MPLS domains within an AS? Naveen ------=_NextPart_000_0215_01BFC664.88B4E910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
The definition of MPLS domain in the=20 draft-ietf-mpls-arch-06.txt says that the MPLS nodes are in one = routing or=20 administrative domain.
 
1. Does it imply that we cannot have 2 AS(Autonomous = System)=20 within the same MPLS domain?
 
2. Is an MPLS domain contained within = an=20 AS?.
 
3. Can we have more than one MPLS domains = within an=20 AS?
 
Naveen
------=_NextPart_000_0215_01BFC664.88B4E910-- From owner-mpls@UU.NET Thu May 25 08:51: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 IAA02393 for ; Thu, 25 May 2000 08:51: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 QQiqrz29462; Thu, 25 May 2000 12:50:06 GMT Received: by mail-control.mail.uu.net id QQiqrz05389 for mpls-outgoing; Thu, 25 May 2000 12:49: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 QQiqrz05384 for ; Thu, 25 May 2000 12:49:34 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 QQiqrz15391 for ; Thu, 25 May 2000 08:49:19 -0400 (EDT) Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQiqrz21536 for ; Thu, 25 May 2000 12:49:19 GMT Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id OAA17839 for ; Thu, 25 May 2000 14:49:18 +0200 (MET DST) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id OAA21497; Thu, 25 May 2000 14:49:18 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14637.8526.593947.107314@rasputin.ce.chalmers.se> Date: Thu, 25 May 2000 14:49:18 +0200 (MEST) To: mpls@UU.NET Subject: RFC 2702 and LSP attributes X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: otel@ce.chalmers.se Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [This is a Jhonny-come-lately-question so if this was asked before, pls point me to the right source] Hello all, Regarding RFC 2702 i have two questions: 1) Section 5.8 "Preemtption attribute". Why there are defined four preemtion modes and then a discussion about the obvious impossible combinations ? Quite a few other attributes defined in prev subsections (e.g. "Path preference rule", "Resource affinity", "Adaptivity") are binary attributes, so the four preemtion modes could be simply implemented w/ two binary attributes "preemtor?" (yes/no) and "preemtable?" (yes/no). In addition to the simplicity there will be no need to state the obvious impossible combinations. (Well, i agree this is a post-mortem, potentially useless discussion but i'm actually wondering if it's not only a glitch and I'm missing something there ;) ) 2) RFC 2702 seems to me a rather lax framework for what LSP attributes are. Is there any other document describing in more detail what are LSP attributes (e.g. number of priority values, formats, etc) or each label distrib. proto is free to implement it however it sees fit as long as it is within the RFC 2702 framework and takes into consideration the link attributes as defined by the present "IGP Requirements for Traffic Engineering with MPLS" (i.e. the long-since-expired draft-li-mpls-igp-te-00.txt) ? Regards, Florian. From owner-mpls@UU.NET Thu May 25 10:24: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 ESMTP id KAA09136 for ; Thu, 25 May 2000 10:24: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 QQiqsf24324; Thu, 25 May 2000 14:23:11 GMT Received: by mail-control.mail.uu.net id QQiqsf28822 for mpls-outgoing; Thu, 25 May 2000 14:22: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 QQiqsf28804 for ; Thu, 25 May 2000 14:22: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 QQiqsf00714 for ; Thu, 25 May 2000 10:22:19 -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 QQiqsf01688 for ; Thu, 25 May 2000 14:22:18 GMT Received: from viper2.alleghenypower.com (root@localhost) by viper2.alleghenypower.com with ESMTP id KAA20379 for ; Thu, 25 May 2000 10:22:12 -0400 (EDT) Received: from smpprx01.alleghenypower.com (smtpgwy2.alleghenypower.com [10.2.117.13] (may be forged)) by viper2.alleghenypower.com with SMTP id KAA20372 for ; Thu, 25 May 2000 10:22:12 -0400 (EDT) Received: from 10.2.129.33 by smpprx01.alleghenypower.com (InterScan E-Mail VirusWall NT); Thu, 25 May 2000 10:00:04 -0400 (Eastern Daylight Time) Received: by smpxch01.alleghenypower.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 10:00:05 -0400 Message-ID: From: "Hull, Kenneth A." To: "'Dmitri Krioukov'" , Krishna Bala , Yakov Rekhter , Stewart Pu Cc: mpls@UU.NET Subject: RE: Lambda Switching Date: Thu, 25 May 2000 10:00:00 -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 I believe that true optical buffering without O-E-O conversion would have to accomplished via an optical delay line (ie. a pre-determined length of fiber). Ken -----Original Message----- From: Dmitri Krioukov [SMTP:dima@krioukov.net] Sent: Wednesday, May 24, 2000 9:15 PM To: Krishna Bala; Yakov Rekhter; Stewart Pu Cc: mpls@UU.NET Subject: RE: Lambda Switching i have a question on optical buffering -- what are the available technologies here or links/references to them? (to be more precise: are they just pools of fiber or specially designed mirror boxes, etc.) thanks, -- dima. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Krishna > Bala > Sent: Wednesday, May 24, 2000 5:50 PM > To: Yakov Rekhter; Stewart Pu > Cc: mpls@UU.NET > Subject: RE: Lambda Switching > > > Stewart, > If you define Optical Switching as the ability to switch large pipes in a > circuit switched fashion .... yes, this is the core competence of optics. > > If you define Optical Routing as the ability to switch individual packets > in a packet switched manner .... no, this is not the strength of > optics. The > biggest barrier to entry for optics here is the inability of optics to > perform > buffering. Large spools of fiber are used as "delay lines" to emulate > buffering. > > > Krishna Bala > Tellium > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yakov > > Rekhter > > Sent: Wednesday, May 24, 2000 1:06 PM > > To: Stewart Pu > > Cc: mpls@UU.NET > > Subject: Re: Lambda Switching > > > > > > Stewart, > > > > > I have a question about MPLS. Is it possible for MPLS using > > lambda as the > > > label? I mean, if DWDM technology can provide enough available > > lambda, can > > > MPLS use lambda as the label? > > > > Yes. See draft-awduche-mpls-te-optical-01.txt. > > > > > If yes, can we say ' We can achieve optical switching or > > optical routing.'? > > > > It depends on how you define "optical switching or optical routing". > > > > > But I ever heard that it is impossible to achieve optical routing, > > > is it right? > > > > I guess folks who told you so may reconsider their opinion :-) > > > > Yakov. > > > > From owner-mpls@UU.NET Thu May 25 10:33:12 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 KAA09397 for ; Thu, 25 May 2000 10:33: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 QQiqsg08245; Thu, 25 May 2000 14:31:28 GMT Received: by mail-control.mail.uu.net id QQiqsg29464 for mpls-outgoing; Thu, 25 May 2000 14:30: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 QQiqsg29456 for ; Thu, 25 May 2000 14:30: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 QQiqsg01725 for ; Thu, 25 May 2000 10:30: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 QQiqsg29506 for ; Thu, 25 May 2000 14:30: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 HAA08069 for ; Thu, 25 May 2000 07:30:23 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA15144 for mpls@uu.net; Thu, 25 May 2000 10:30:13 -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 QQiqri14962 for ; Thu, 25 May 2000 08:38: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 QQiqri22753 for ; Thu, 25 May 2000 04:38:45 -0400 (EDT) Received: from sasi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQiqri02125 for ; Thu, 25 May 2000 08:38:41 GMT Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id OAA08117; Thu, 25 May 2000 14:06:29 +0530 (IST) Received: from hpd11.sasi.com ([10.0.16.11]) by sasi.com; Thu, 25 May 2000 14:06:27 +0000 (IST) Received: from localhost (ramp@localhost) by hpd11.sasi.com (8.9.1/8.9.1) with ESMTP id OAA03565; Thu, 25 May 2000 14:15:30 +0530 (IST) Date: Thu, 25 May 2000 14:15:30 +0530 (IST) From: B G Ramprasad Torati To: Florian-Daniel Otel cc: curtis@avici.com, mpls@UU.NET Subject: Re: MPLS Performance analysis..... In-Reply-To: <14636.50410.52770.352863@rasputin.ce.chalmers.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk HI > > > I couldn't rezist to beat up the dead dog with just one more posting...;> > > > Florian, > > > The plain fact is that it just doesn't matter. The shortest speed of > > light delays in any WAN application is on the order of a few > > milliseconds. Queueing delay can be hundreds of milliseconds if the > > outbound interface is congested. Modern routers forward IP in a few > > 10s of microseconds (on fast interfaces). If the path is the same and > > the same queue is used, then the difference in forwarding speed > > between an IP route lookup and an MPLS label lookup isn't even > > measurable and in some (most?) routers the difference is exactly zero. > > > That was my point exactly when i said that this type of measurement, > even done with production router software, is irrelevant. As some > people already pointed out, IP routing software can be (and is) done > as fast as MPLS switching, e.g. hardw implementation, pipelined ASICs, > hashing, advanced searching techniques, routing table compression, etc, > etc. It's a whole world here, i don't even dare to open this > Pandorra's box here.. > > Back to the original posting, I really cannot imagine any non-trivial > tests aiming to prove that 'MPLS is faster than IP' (yes, the > statement doesn't make much sense). One such example might > (arguably) be the ability to do source routing at lower costs than > IP-in-IP tunneling/ IP source routing. > > Again, MPLS strongest points aren't performance but the network > engineering capabilities it offers, > > > Curtis What are the network engineering capabilities MPLS offers extra over IP. HOw I can show them using the simulation. I want to show how MPLS is advantageous over normal IP in as many aspects as I can, using my MPLS simulation (using ns). So please help in this. Thanks and Regards, B G Ramprasad Torati From owner-mpls@UU.NET Thu May 25 10:35: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 ESMTP id KAA09659 for ; Thu, 25 May 2000 10:35: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 QQiqsg00609; Thu, 25 May 2000 14:31:37 GMT Received: by mail-control.mail.uu.net id QQiqsg29479 for mpls-outgoing; Thu, 25 May 2000 14:30: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 QQiqsg29471 for ; Thu, 25 May 2000 14:30:48 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 QQiqsg00285 for ; Thu, 25 May 2000 10:30:35 -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 QQiqsg29724 for ; Thu, 25 May 2000 14:30:34 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 HAA08532 for ; Thu, 25 May 2000 07:30:42 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA15148 for mpls@uu.net; Thu, 25 May 2000 10:30: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 QQiqrj15795 for ; Thu, 25 May 2000 08: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 QQiqrj23725 for ; Thu, 25 May 2000 04:52:12 -0400 (EDT) Received: from sasi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQiqrj17353 for ; Thu, 25 May 2000 08:52:08 GMT Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id OAA08520; Thu, 25 May 2000 14:18:45 +0530 (IST) Received: from hpd11.sasi.com ([10.0.16.11]) by sasi.com; Thu, 25 May 2000 14:18:44 +0000 (IST) Received: from localhost (ramp@localhost) by hpd11.sasi.com (8.9.1/8.9.1) with ESMTP id OAA03586; Thu, 25 May 2000 14:27:51 +0530 (IST) Date: Thu, 25 May 2000 14:27:51 +0530 (IST) From: B G Ramprasad Torati To: Khaled Elsayed cc: mpls@UU.NET, B G Ramprasad Torati , khaled@ieee.org Subject: Re: MPLS Performance analysis..... In-Reply-To: <200005250150704.SM00129@pacificpost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can U suggest an example scenario of what U mentioned here with all the details of link bandwidths ,packet sizes, Type of packets ...etc. As I am new to this kind of analysis, I don't have any realistic scenario at present. Thank U very much B G Ramprasad Torati On Thu, 25 May 100, Khaled Elsayed wrote: > > As other people said, it is not surprising you would get the same results. You would need to come up with a scenario where if you use tradional routing versus proper traffic engineering as in MPLS, the difference in the peformance will be clear. However, your scenario should be as realistic as possible, i.e. it can happen in an IP-based network. This is the difficult part. The rest should be easy. > > BR, > > Khaled Elsayed > > > > ---------- Original Message ---------------------------------- > From: B G Ramprasad Torati > Date: Tue, 23 May 2000 21:53:47 -0700 (PDT) > > >Hi > > > >I simulated the LDP and MPLS packet switching parts of > >MPLS by extending the network simulator 2. > >Now I want to do the performance analysis between the > >two forwarding paradigms( MPLS forwarding and normal > >IP forwarding). > > > >For this I have taken an example topology and did the > >following things. > >1. Using CBR agent I calculated the delays by using > >loss monitor as the sink of the CBR packets. > >2. Using Ping agents I calculated the round trip time. > > > >I did those using both normal IP and MPLS with LDP. > >But I didn't get any difference between those two > >forwarding paradigms. I calculated the no. of packets > >lost using CBR agents. Still I got the same > >performance for both the above. I used both Link state > >and Distance Vector dynamic roting protocols while > >doing this analysis. > > > >So can anybody suggest how to do the performance > >analysis. I am new to this, so please tell how exactly > >I have to proceed in doing this analysis. > > > >Thanks and Regards, > >Ramp > > > >__________________________________________________ > >Do You Yahoo!? > >Send instant messages & get email alerts with Yahoo! Messenger. > >http://im.yahoo.com/ > > > > > From owner-mpls@UU.NET Thu May 25 10:58: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 KAA10481 for ; Thu, 25 May 2000 10:58: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 QQiqsh19200; Thu, 25 May 2000 14:57:26 GMT Received: by mail-control.mail.uu.net id QQiqsh01257 for mpls-outgoing; Thu, 25 May 2000 14:56:54 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 QQiqsh01244 for ; Thu, 25 May 2000 14:56:38 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 QQiqsh05083 for ; Thu, 25 May 2000 10:56:06 -0400 (EDT) Received: from smtp6.mindspring.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQiqsh25516 for ; Thu, 25 May 2000 14:56:06 GMT Received: from mindspring.com (user-33qtkes.dialup.mindspring.com [199.174.209.220]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id KAA03198; Thu, 25 May 2000 10:55:53 -0400 (EDT) Message-ID: <392D3FB0.4E2B6F2B@mindspring.com> Date: Thu, 25 May 2000 07:58:56 -0700 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: otel@ce.chalmers.se CC: mpls@UU.NET Subject: Re: RFC 2702 and LSP attributes References: <14637.8526.593947.107314@rasputin.ce.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Florian, RFC2702 specifies requirements, rather than a framework. The preemptor/preemptable requirement described implies the behavior you suggest, but - because RFC2702 was written to define requirements rather than specific behaviors - it does not restrict behavior to exactly this behavior. This is what a requirements document should do. To see why it might be useful to describe this requirement the way that it is described, consider that some one else may have a requirement to provide graduated levels of preemption capability. For example, I may wish to have "setup" and "hold" preemption priorities which are more flexible than a binary value. This would allow me to establish, for example, relatively low priority circuits which are difficult - but not impossible - to preempt. This is accomplished by setting a relatively low "setup" priority (to preclude preempting possibly more important circuits) and a higher "hold" priority (preventing preemption by another setup that is not - for example - much more important). This is useful for relatively short duration circuit setup where interruption is unacceptable once a circuit is established. It is simple to use this scheme to also satisfy requirements in the TER RFC (2702). Simply setting the "setup" and "hold" priorities appropriately gets the binary behavior you suggest. Because RFC2702 does not attempt to mandate specific behavior, it is possible to implement a more flexible approach that satisfies the requirements of this RFC. -- Eric Gray Florian-Daniel Otel wrote: > [This is a Jhonny-come-lately-question so if this was asked before, > pls point me to the right source] > > Hello all, > > Regarding RFC 2702 i have two questions: > > 1) Section 5.8 "Preemtption attribute". Why there are defined four > preemtion modes and then a discussion about the obvious impossible > combinations ? Quite a few other attributes defined in prev > subsections (e.g. "Path preference rule", "Resource affinity", > "Adaptivity") are binary attributes, so the four preemtion modes could > be simply implemented w/ two binary attributes "preemtor?" (yes/no) and > "preemtable?" (yes/no). In addition to the simplicity there will be no need > to state the obvious impossible combinations. > > (Well, i agree this is a post-mortem, potentially useless discussion > but i'm actually wondering if it's not only a glitch and I'm missing > something there ;) ) > > 2) RFC 2702 seems to me a rather lax framework for what LSP attributes are. Is > there any other document describing in more detail what are LSP > attributes (e.g. number of priority values, formats, etc) or each > label distrib. proto is free to implement it however it sees fit as > long as it is within the RFC 2702 framework and takes into consideration the > link attributes as defined by the present "IGP Requirements for > Traffic Engineering with MPLS" (i.e. the long-since-expired > draft-li-mpls-igp-te-00.txt) ? > > Regards, > > Florian. From owner-mpls@UU.NET Thu May 25 11:32: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 ESMTP id LAA11437 for ; Thu, 25 May 2000 11:32: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 QQiqsj18291; Thu, 25 May 2000 15:29:32 GMT Received: by mail-control.mail.uu.net id QQiqsj12557 for mpls-outgoing; Thu, 25 May 2000 15:29: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 QQiqsj12548 for ; Thu, 25 May 2000 15:28: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 QQiqsj09618 for ; Thu, 25 May 2000 11:28:37 -0400 (EDT) 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 QQiqsj17512 for ; Thu, 25 May 2000 15:28:36 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 KAA20543; Thu, 25 May 2000 10:25:34 -0500 (CDT) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA04900; Thu, 25 May 2000 10:25:30 -0500 (CDT) Received: by localhost with Microsoft MAPI; Thu, 25 May 2000 11:29:49 -0400 Message-ID: <01BFC63C.89657B90.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'ramp@sasi.com'" , "khaled@pacificpost.com" Cc: "mpls@UU.NET" , "ramp_mpls@yahoo.com" , "khaled@ieee.org" Subject: RE: MPLS Performance analysis..... Date: Thu, 25 May 2000 11:29:47 -0400 Organization: Tellabs Research Center 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 Ramprasad, It is unlikely that anyone will be able to give you a ready-made simulation scenario. I think Florian made some good suggestions on the readings. I think what is missing in your plan is a clearer objective. You sort of stated it when you said : > want to show how MPLS is > advantageous over normal IP in as many aspects as I can, using my MPLS > simulation (using ns). (I think it still might be useful to ask why you want to do this, and what is the final purpose of doing this exercise.) Assuming this is your aim, you have to ask yourself (a) in what respects is MPLS stated to be better than IP and (b) what would be a way to design a simulation to demonstrate that. As Brijesh mentioned in an earlier email, a worthwhile comparison is really to examine what MPLS provides in terms of traffic engineering capabilities relative to either pure IP routing, or IP routing augmented with some traffic engineering capabilities in the interior gateway protocols (IGP), such as equal-cost multipath, or metric tuning. If this is the aspect that one believes MPLS could be better in, then the following could be one simple way to go about it. So let's say that at a first-level you assume the following: (i) a network topology (the nodes, their locations) and parameters (the link capacities, and metrics). (ii) a traffic matrix for the network (that is, static demands; a simplistic scenario, but probably a good starting point, especially if you consider backbone networks that carry aggregated demands that are likely to be fairly constant [they might have some variation about a mean value, but one could assume for starters that the variation is small]). The aim of the comparison then could be to comapre the following (Brijesh already pointed this out) (a) The delay experienced by the traffic, with and without MPLS traffic engineering. (b) The total amount of traffic that could be served, with and without MPLS traffic engineering. (Given any traffic matrix, you may not be able to serve all of it, so you'd have to see how much of the demand you can serve in the two cases.) (We will ignore forwarding performance, since as people have pointed out, that is implementation dependent, and is not really a differetiator for MPLS anymore.) Please note, that to do this your simulation will, in addition, have to run some algorithm(s) that can decide exactly which MPLS LSPs to set up, and how much bandwidth to assign to each of them to serve the traffic demands specified in your traffic matrix. So in effect, what you will really be testing is the "goodness" of these LSP placement algorithms, because the better these algorithms are in finding "good" paths through the network (assuming that these paths can then be setup using MPLS signaling protocols), the better is likely to be the performance of the MPLS-based scheme relative to IP routing. -Vishal On Thursday, May 25, 2000 4:58 AM, ramp@sasi.com [SMTP:ramp@sasi.com] wrote: > Hi, > > > Can U suggest an example scenario of what U mentioned here with all the > details of link bandwidths ,packet sizes, Type of packets ...etc. As I am > new to this kind of analysis, I don't have any realistic scenario at > present. > > Thank U very much > B G Ramprasad Torati > On Thu, 25 May 100, Khaled Elsayed wrote: > > > > > As other people said, it is not surprising you would get the same results. You would need to > > come up with a scenario where if you use tradional routing versus proper traffic engineering as > > in MPLS, the difference in the peformance will be clear. However, your scenario should be as > > realistic as possible, i.e. it can happen in an IP-based network. This is the difficult part. The > > rest should be easy. > > > > BR, > > > > Khaled Elsayed > > > > > > > > ---------- Original Message ---------------------------------- > > From: B G Ramprasad Torati > > Date: Tue, 23 May 2000 21:53:47 -0700 (PDT) > > > > >Hi > > > > > >I simulated the LDP and MPLS packet switching parts of > > >MPLS by extending the network simulator 2. > > >Now I want to do the performance analysis between the > > >two forwarding paradigms( MPLS forwarding and normal > > >IP forwarding). > > > > > >For this I have taken an example topology and did the > > >following things. > > >1. Using CBR agent I calculated the delays by using > > >loss monitor as the sink of the CBR packets. > > >2. Using Ping agents I calculated the round trip time. > > > > > >I did those using both normal IP and MPLS with LDP. > > >But I didn't get any difference between those two > > >forwarding paradigms. I calculated the no. of packets > > >lost using CBR agents. Still I got the same > > >performance for both the above. I used both Link state > > >and Distance Vector dynamic roting protocols while > > >doing this analysis. > > > > > >So can anybody suggest how to do the performance > > >analysis. I am new to this, so please tell how exactly > > >I have to proceed in doing this analysis. > > > > > >Thanks and Regards, > > >Ramp > > > > > >__________________________________________________ > > >Do You Yahoo!? > > >Send instant messages & get email alerts with Yahoo! Messenger. > > >http://im.yahoo.com/ > > > > > > > > > From owner-mpls@UU.NET Thu May 25 13: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 NAA14381 for ; Thu, 25 May 2000 13: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 QQiqsq26812; Thu, 25 May 2000 17:13:14 GMT Received: by mail-control.mail.uu.net id QQiqsq08472 for mpls-outgoing; Thu, 25 May 2000 17:12:52 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqsq08466 for ; Thu, 25 May 2000 17:12:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqsq09403 for ; Thu, 25 May 2000 13:08:47 -0400 (EDT) Received: from 21cn.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [202.104.32.246]) id QQiqsq16845 for ; Thu, 25 May 2000 17:08:39 GMT Received: from 21cn.com([10.1.0.104]) by 21cn.com(JetMail 2.5.3.0) with SMTP id jm4392da7d8; Thu, 25 May 2000 17:06:20 -0000 Received: from wodc7-2.corprelay.mail.uu.net([192.48.96.69]) by 21cn.com(JetMail 2.3.2.6) with SMTP id /aimcque/jmail.rcv/4/jm938ff94f2; Thu, 20 Apr 2000 20:55:38 -0000 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 QQilty13997; Thu, 20 Apr 2000 20:35:53 GMT Received: by mail-control.mail.uu.net id QQilty16738 for mpls-outgoing; Thu, 20 Apr 2000 20:35:31 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 QQilty16730 for ; Thu, 20 Apr 2000 20:35: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 QQilty01052 for ; Thu, 20 Apr 2000 16:35:22 -0400 (EDT) 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 QQilty07442 for ; Thu, 20 Apr 2000 20:35:21 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 PAA11294; Thu, 20 Apr 2000 15:35:17 -0500 (CDT) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id PAA17952; Thu, 20 Apr 2000 15:35:12 -0500 (CDT) Received: by localhost with Microsoft MAPI; Thu, 20 Apr 2000 16:38:57 -0400 Message-ID: <01BFAAE6.ECA94720.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'dallan@nortelnetworks.com'" , "Ben.Mack-Crane@tellabs.com" Cc: "mpls@uu.net" , "Srinivas.Makam@tellabs.com" , "Changcheng.Huang@tellabs.com" , "Ken.Owens@tellabs.com" Subject: RE: draft-chang-mpls-path-protection Comments Date: Thu, 20 Apr 2000 16:38:56 -0400 Organization: Tellabs Research Center 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 Dave, I concur with Ben. Good thoughts all! Please see my comments below (unneeded text deleted below). -Vishal On Thursday, April 20, 2000 11:19 AM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] wrote: > Ben: > > Thanks for your comments. Rooting back through the other drafts, this > discussion should really be focused around the framework draft > . To my mind the issue is whether MPLS is a > black box and the very worst manifestation of a failure is a 'x' msec. > interruption of packet flow out of a particular interface, OR whether we > allow "less specific" box behaviors such as the packets keep flowing out of > the box, but it may be a different interface. Seems to me that there are > cases for both. I think what you mean above is different than what Ben alluded to in his reply to you. If I understand you, you are asking that the MPLS recovery cover the case not only of those problems where there is an actual break in traffic (treating LSR as a black box), but also those cases where there is no break in traffic, but things at the MPLS layer are messed up. My response is: absolutely! (In fact, Neil Harrison of BT in a response on the list a couple of days ago had made a very good characterization of the types of errors that may require protection/recovery, which I would recommend. If you haven't seen that one or cannot find it, pl. let me know. I'll forward it.) And, the framework document does allow for both these possibilities. In fact, a look at the types of errors (enumerated in the framework document) that could occur at the MPLS layer shows that they allow for things like misbranching, errored packets, misdirected packets, etc. If you feel there is something missing in the framework as it stands, please let us know. > > You are correct in noting that the PML is limiting, as > > a single egress point for the MPLS protection domain; > > however, removing this limitation requires some knowledge > > beyond that necessarily held by the MPLS layer. > > > Yes, there would have to be a path diversity test combined with some > link-state knowledge of the over all network to ensure that the alternate > egress point was appropriate. > > > There are two extensions that I can think of based on your > > comments (please let me know if I have misunderstood your > > comments). > > > > 1) The working and recovery paths never merge as LSPs. > > Instead, the recovery path terminates at an LER that is an > > acceptable alternative to the LER terminating the working > > path for the purpose of forwarding the FEC represented by > > the working path. > > > > In this case, the protection domain is still within a > > contiguous MPLS cloud > > > Effectively yes. We have not discussed fast failure detection, > propagation, and pre-planned alternate route mechanisms outside the MPLS > space. > > > (which BTW implies nothing in particular > > about administrative domains). > > > Agreed, however such things MAY exist, such as intercarrier > boundaries inside a contiguous MPLS space. That would be my only > observation. The boundary MAY not be technical and in the real world that is > what frequently happens. If there is some form of pre-emption, then it is > also useful to constrain the space to minimize the amount of traffic > distrupted. I got lost on the last sentence here. By pre-emption do you mean the usual --- pre-emption of low priority traffic on the protection path by working traffic once the protection path is brought into use? > > The protection mechanism > > still works with information available at the MPLS layer > > (fault detection, protection actions, etc.). However, selection > > of the recovery path (outside the scope of this ID) requires > > L3 knowledge to determine that the LER terminating the > > recovery path is acceptable. > > > I would broaden the definition as selection suggests to me explicit > routing, whereas increasing the reliabilty of implicit path construction > would imply intelligent pruning of options. To a certain extent, > conservative label retention in an implicit case implies some knowledge of > which LSPs would be more optimal than others, and sufficient information > should be available at the overall L3 layer (not just MPLS topolocy) to make > that determination. Again, I have a question. Why do you say that conservative label retention implies a knowledge of which LSPs are more optimal? > > In practice this may be an attractive option, although > > some thought may be required to apply this in an end-to-end > > recovery design for other than best effort traffic. > > > Yes, bang on!, to my mind there is two goals to this effort in > general. First is providing explicit recovery mechanisms for specific flows > that require specific service guaratees, and second is raising the > reliability bar overall. You're correct in identifying best effort, as e2e > RSVP reservations carried through such an "LSP tunnel" require explicit > black box behaviour to avoid the interruption of re-routing on a protection > switch (or establishing a new "deaggregator"). That is NOT the scenario that > I think a non-PML solution adds value to. Absolutely. Agreed. > > 2) The protection domain spans both MPLS hops and L3 hops. > > > Not sure how this really differs from '1' except the suggestion that > there are fast non-MPLS restoration mechanisms which require some overall > coordination. > > > Here the protection domain is not within a contiguous MPLS > > cloud, and recovery within such a protection domain may be > > complex. Since the protection domain includes both MPLS and > > L3 hops, fault detection and recovery actions may be significantly > > different depending on where a fault occurs (and the protection > > mechanism would require L3 knowledge in some cases). It may > > be difficult to guarantee uniform recovery performance across > > the entire protection domain. > > > > > I think in general it is easiest to think of this as concatenated > protection domains with redundancy at the domain boundary. Ultimately it is > a form of "Per-Hop Protection" ;-) as the lack of uniformity of mechanisms > makes explicit guarantees difficult but the performance is the best the > overall network can do. If we stick to that definition then there is really > no difference between 1 and 2. I like the concatenated protection idea. This is sort of what I had alluded to in an earlier email where I'd said that one may do protection of a multi-domain LSP (ie, an LSP that spans multiple MPLS domains one after another) on a segment by segment basis. Of course, the implication above is more general than that. > My summary would be: > > 1) We need to clarify overall the goals of MPLS restoration. Is it > explicit black box behavior or are we seeking a broader base of solutions > that dovetail into the overall network. I think the recovery framework document encompasses the broader definition. As before, if you feel something more is needed, let us know. > If we are discussing a broader base, > then a 1:1 or n:1 non-"lsp merging" solution has applicability. If we are > "black box" only as it works for all style of protections (1+1, n:1, 1:1), > all styles of traffic (best effort, diffserv and RSVP pinnned route) and is > measuable, then we'll have to tolerate less optimal e2e routing and topology > to get that. Personally, I'd like a bigger toolbox. I'd say that we are indeed discussing the broader base. And yes (now that I understand it more clearly), the non-LSP merging solution has applicability and should be mentioned in the mechanism draft. (The framework draft in any case does not refer to any particular solution(s).) > 2) I don't think we need to overload the recovery space by expanding > the protected domain beyond MPLS, only acknowledge that we may concatenate > protection mechanisms, they function autonomously, and may have multiple > points of attachment. Coordination of protection across multiple transport > technologies is out of scope if we are to make progress. Agreed. I would like to add, however, that with the recent on-going activity in the MPLS + crossconnects area, we might have to think about coordination at least across the MPLS and optical transport networks (since that may be an important case in practice). From owner-mpls@UU.NET Thu May 25 13:57: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 ESMTP id NAA16231 for ; Thu, 25 May 2000 13:57:57 -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 QQiqst01789; Thu, 25 May 2000 17:56:45 GMT Received: by mail-control.mail.uu.net id QQiqst11054 for mpls-outgoing; Thu, 25 May 2000 17:56: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 QQiqst11018 for ; Thu, 25 May 2000 17:56: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 QQiqst03165 for ; Thu, 25 May 2000 13:55:51 -0400 (EDT) Received: from auemail2.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQiqst00706 for ; Thu, 25 May 2000 17:55:50 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA10517 for ; Thu, 25 May 2000 13:55:50 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA10507; Thu, 25 May 2000 13:55:48 -0400 (EDT) Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA17232; Thu, 25 May 2000 13:55:41 -0400 (EDT) Message-ID: <392D6870.404A103D@lucent.com> Date: Thu, 25 May 2000 13:52:48 -0400 From: Yang Cao Organization: Lucent Technologies X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hull, Kenneth A." CC: "'Dmitri Krioukov'" , Krishna Bala , Yakov Rekhter , Stewart Pu , mpls@UU.NET Subject: Re: Lambda Switching References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I think that's only because a smarter and really practical solution has not come up yet. Yang "Hull, Kenneth A." wrote: > > I believe that true optical buffering without O-E-O conversion would have to > accomplished via an optical delay line (ie. a pre-determined length of > fiber). > > Ken > -----Original Message----- > From: Dmitri Krioukov [SMTP:dima@krioukov.net] > Sent: Wednesday, May 24, 2000 9:15 PM > To: Krishna Bala; Yakov Rekhter; Stewart Pu > Cc: mpls@UU.NET > Subject: RE: Lambda Switching > > i have a question on optical buffering -- > what are the available technologies here > or links/references to them? (to be more > precise: are they just pools of fiber > or specially designed mirror boxes, etc.) > > thanks, > -- > dima. > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Krishna > > Bala > > Sent: Wednesday, May 24, 2000 5:50 PM > > To: Yakov Rekhter; Stewart Pu > > Cc: mpls@UU.NET > > Subject: RE: Lambda Switching > > > > > > Stewart, > > If you define Optical Switching as the ability to switch large > pipes in a > > circuit switched fashion .... yes, this is the core competence of > optics. > > > > If you define Optical Routing as the ability to switch individual > packets > > in a packet switched manner .... no, this is not the strength of > > optics. The > > biggest barrier to entry for optics here is the inability of > optics to > > perform > > buffering. Large spools of fiber are used as "delay lines" to > emulate > > buffering. > > > > > > Krishna Bala > > Tellium > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Yakov > > > Rekhter > > > Sent: Wednesday, May 24, 2000 1:06 PM > > > To: Stewart Pu > > > Cc: mpls@UU.NET > > > Subject: Re: Lambda Switching > > > > > > > > > Stewart, > > > > > > > I have a question about MPLS. Is it possible for MPLS using > > > lambda as the > > > > label? I mean, if DWDM technology can provide enough available > > > lambda, can > > > > MPLS use lambda as the label? > > > > > > Yes. See draft-awduche-mpls-te-optical-01.txt. > > > > > > > If yes, can we say ' We can achieve optical switching or > > > optical routing.'? > > > > > > It depends on how you define "optical switching or optical > routing". > > > > > > > But I ever heard that it is impossible to achieve optical > routing, > > > > is it right? > > > > > > I guess folks who told you so may reconsider their opinion :-) > > > > > > Yakov. > > > > > > From owner-mpls@UU.NET Thu May 25 14:11: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 OAA16658 for ; Thu, 25 May 2000 14:11: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 QQiqsu20528; Thu, 25 May 2000 18:09:43 GMT Received: by mail-control.mail.uu.net id QQiqsu20510 for mpls-outgoing; Thu, 25 May 2000 18:09: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 QQiqsu20500 for ; Thu, 25 May 2000 18:09: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 QQiqsu01553 for ; Thu, 25 May 2000 14:09:00 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiqsu19872 for ; Thu, 25 May 2000 18:09:00 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id OAA00413; Thu, 25 May 2000 14:08:57 -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 OAA20822; Thu, 25 May 2000 14:09:12 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200005251809.OAA20822@curtis-lt.avici.com> To: "Naveen Seth" cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS domain - AS In-reply-to: Your message of "Thu, 25 May 2000 16:16:07 +0530." <021801bfc636$7bebfc60$140d85a5@dti.daewoo.co.kr> Date: Thu, 25 May 2000 14:09:11 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <021801bfc636$7bebfc60$140d85a5@dti.daewoo.co.kr>, "Naveen Seth" wri tes: > > 1. Does it imply that we cannot have 2 AS(Autonomous System) within the = > same MPLS domain? A common IGP is needed to exchange link state and traffic engineering information. If the two AS did share a common IGP, they would more likely be sub-AS within BGP confederations within a common AS. > 2. Is an MPLS domain contained within an AS?. Generally yes. Strictly speaking it doesn't have to be. > 3. Can we have more than one MPLS domains within an AS? Yes and this is expected to be quite common as MPLS TE capability moves closer to the edges of large provider networks and those providers want to limit the number of LSPs in the core. > Naveen Curtis From owner-mpls@UU.NET Thu May 25 14:11: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 ESMTP id OAA16681 for ; Thu, 25 May 2000 14:11: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 QQiqsu14481; Thu, 25 May 2000 18:10:05 GMT Received: by mail-control.mail.uu.net id QQiqsu20513 for mpls-outgoing; Thu, 25 May 2000 18:09:28 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 QQiqsu20502 for ; Thu, 25 May 2000 18:09:16 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 QQiqsu01557 for ; Thu, 25 May 2000 14:09:00 -0400 (EDT) Received: from mail2.disney.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.disney.com [204.128.192.16]) id QQiqsu13155 for ; Thu, 25 May 2000 18:09:00 GMT Received: from pain.corp.disney.com (root@pain.corp.disney.com [153.7.231.100]) by mail2.disney.com (8.9.1/8.9.1) with SMTP id LAA05702 for ; Thu, 25 May 2000 11:07:44 -0700 (PDT) Received: from 1crp299.corp.disney.com by pain.corp.disney.com with ESMTP; Thu, 25 May 2000 11:09:17 -0700 Received: by 1crp299.corp.disney.com with Internet Mail Service (5.5.2651.58) id ; Thu, 25 May 2000 11:08:56 -0700 Message-Id: From: "Holmes, David A." To: yangcao@lucent.com, KHULL@alleghenyenergy.com Cc: dima@krioukov.net, kbala@tellium.com, yakov@cisco.com, pusu@nortelnetworks.com, mpls@UU.NET Subject: RE: Lambda Switching Date: Thu, 25 May 2000 11:08:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk See the article "Advances in Photonic Packet Switching: An Overview" (S. Yao, B. Mukherjee, S. Dixit) in the February 2000 issue of IEEE Communications Magazine, for an overview of some approaches to optical buffering techniques. David -----Original Message----- From: Yang Cao [mailto:yangcao@lucent.com] Sent: Thursday, May 25, 2000 10:53 AM To: Hull, Kenneth A. Cc: 'Dmitri Krioukov'; Krishna Bala; Yakov Rekhter; Stewart Pu; mpls@UU.NET Subject: Re: Lambda Switching I think that's only because a smarter and really practical solution has not come up yet. Yang "Hull, Kenneth A." wrote: > > I believe that true optical buffering without O-E-O conversion would have to > accomplished via an optical delay line (ie. a pre-determined length of > fiber). > > Ken > -----Original Message----- > From: Dmitri Krioukov [SMTP:dima@krioukov.net] > Sent: Wednesday, May 24, 2000 9:15 PM > To: Krishna Bala; Yakov Rekhter; Stewart Pu > Cc: mpls@UU.NET > Subject: RE: Lambda Switching > > i have a question on optical buffering -- > what are the available technologies here > or links/references to them? (to be more > precise: are they just pools of fiber > or specially designed mirror boxes, etc.) > > thanks, > -- > dima. > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Krishna > > Bala > > Sent: Wednesday, May 24, 2000 5:50 PM > > To: Yakov Rekhter; Stewart Pu > > Cc: mpls@UU.NET > > Subject: RE: Lambda Switching > > > > > > Stewart, > > If you define Optical Switching as the ability to switch large > pipes in a > > circuit switched fashion .... yes, this is the core competence of > optics. > > > > If you define Optical Routing as the ability to switch individual > packets > > in a packet switched manner .... no, this is not the strength of > > optics. The > > biggest barrier to entry for optics here is the inability of > optics to > > perform > > buffering. Large spools of fiber are used as "delay lines" to > emulate > > buffering. > > > > > > Krishna Bala > > Tellium > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Yakov > > > Rekhter > > > Sent: Wednesday, May 24, 2000 1:06 PM > > > To: Stewart Pu > > > Cc: mpls@UU.NET > > > Subject: Re: Lambda Switching > > > > > > > > > Stewart, > > > > > > > I have a question about MPLS. Is it possible for MPLS using > > > lambda as the > > > > label? I mean, if DWDM technology can provide enough available > > > lambda, can > > > > MPLS use lambda as the label? > > > > > > Yes. See draft-awduche-mpls-te-optical-01.txt. > > > > > > > If yes, can we say ' We can achieve optical switching or > > > optical routing.'? > > > > > > It depends on how you define "optical switching or optical > routing". > > > > > > > But I ever heard that it is impossible to achieve optical > routing, > > > > is it right? > > > > > > I guess folks who told you so may reconsider their opinion :-) > > > > > > Yakov. > > > > > > From owner-mpls@UU.NET Thu May 25 14:33: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 OAA17400 for ; Thu, 25 May 2000 14:33: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 QQiqsw10043; Thu, 25 May 2000 18:32:47 GMT Received: by mail-control.mail.uu.net id QQiqsw22080 for mpls-outgoing; Thu, 25 May 2000 18:32:25 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqsw22063 for ; Thu, 25 May 2000 18:32:21 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqsv20854 for ; Thu, 25 May 2000 14:21:31 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiqsv00507 for ; Thu, 25 May 2000 18:21:30 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id OAA01680; Thu, 25 May 2000 14:21:29 -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 OAA20844; Thu, 25 May 2000 14:21:43 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200005251821.OAA20844@curtis-lt.avici.com> To: otel@ce.chalmers.se cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: RFC 2702 and LSP attributes In-reply-to: Your message of "Thu, 25 May 2000 14:49:18 +0200." <14637.8526.593947.107314@rasputin.ce.chalmers.se> Date: Thu, 25 May 2000 14:21:43 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <14637.8526.593947.107314@rasputin.ce.chalmers.se>, Florian-Daniel O tel writes: > > 1) Section 5.8 "Preemtption attribute". Why there are defined four > preemtion modes and then a discussion about the obvious impossible > combinations ? Quite a few other attributes defined in prev > subsections (e.g. "Path preference rule", "Resource affinity", > "Adaptivity") are binary attributes, so the four preemtion modes could > be simply implemented w/ two binary attributes "preemtor?" (yes/no) and > "preemtable?" (yes/no). In addition to the simplicity there will be no need > to state the obvious impossible combinations. RFC2702 is really a requirements document, not a protocol definition. The sample implementation are just samples and are described in RFC2702 as minimal implementations. For example, the Adaptivity attribute need not be binary. Parameters can be specified to provide finer control over how quickly an LSP reacts to a change in available resources. > 2) RFC 2702 seems to me a rather lax framework for what LSP attributes are. > Is there any other document describing in more detail what are LSP > attributes (e.g. number of priority values, formats, etc) or each > label distrib. proto is free to implement it however it sees fit as > long as it is within the RFC 2702 framework and takes into consideration the > link attributes as defined by the present "IGP Requirements for > Traffic Engineering with MPLS" (i.e. the long-since-expired > draft-li-mpls-igp-te-00.txt) ? See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt regarding your questions about "Preemtption attribute". Setup Priority The priority of the session with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session. Holding Priority The priority of the session with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session. Other parameters mentioned in RFC2702 (for example, the adaptivity parameter) need not be signalled since the decision to reroute is made at the ingress. Curtis From owner-mpls@UU.NET Thu May 25 14:51: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 ESMTP id OAA17783 for ; Thu, 25 May 2000 14:51: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 QQiqsx18561; Thu, 25 May 2000 18:49:58 GMT Received: by mail-control.mail.uu.net id QQiqsx23176 for mpls-outgoing; Thu, 25 May 2000 18:49: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 QQiqsx23168 for ; Thu, 25 May 2000 18:49: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 QQiqsx12141 for ; Thu, 25 May 2000 14:49:00 -0400 (EDT) Received: from viper2.alleghenypower.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: viper2.alleghenypower.com [198.77.48.2]) id QQiqsx17684 for ; Thu, 25 May 2000 18:48:59 GMT Received: from viper2.alleghenypower.com (root@localhost) by viper2.alleghenypower.com with ESMTP id OAA18775 for ; Thu, 25 May 2000 14:48:54 -0400 (EDT) Received: from smpprx01.alleghenypower.com (smtpgwy2.alleghenypower.com [10.2.117.13] (may be forged)) by viper2.alleghenypower.com with SMTP id OAA18767 for ; Thu, 25 May 2000 14:48:53 -0400 (EDT) Received: from 10.2.129.33 by smpprx01.alleghenypower.com (InterScan E-Mail VirusWall NT); Thu, 25 May 2000 14:21:30 -0400 (Eastern Daylight Time) Received: by smpxch01.alleghenypower.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 14:21:32 -0400 Message-ID: From: "Hull, Kenneth A." To: "'Holmes, David A.'" , yangcao@lucent.com Cc: dima@krioukov.net, kbala@tellium.com, yakov@cisco.com, pusu@nortelnetworks.com, mpls@UU.NET Subject: RE: Lambda Switching Date: Thu, 25 May 2000 14:21:30 -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 This reference is great for all the ways delay lines are being used. A question for Yang @ Lucent.: Is the MEMs technology based on slotted network design? See the article "Advances in Photonic Packet Switching: An Overview" (S. Yao, B. Mukherjee, S. Dixit) in the February 2000 issue of IEEE Communications Magazine, for an overview of some approaches to optical buffering techniques. David -----Original Message----- From: Yang Cao [mailto:yangcao@lucent.com] Sent: Thursday, May 25, 2000 10:53 AM To: Hull, Kenneth A. Cc: 'Dmitri Krioukov'; Krishna Bala; Yakov Rekhter; Stewart Pu; mpls@UU.NET Subject: Re: Lambda Switching I think that's only because a smarter and really practical solution has not come up yet. Yang "Hull, Kenneth A." wrote: > > I believe that true optical buffering without O-E-O conversion would have to > accomplished via an optical delay line (ie. a pre-determined length of > fiber). > > Ken > -----Original Message----- > From: Dmitri Krioukov [SMTP:dima@krioukov.net] > Sent: Wednesday, May 24, 2000 9:15 PM > To: Krishna Bala; Yakov Rekhter; Stewart Pu > Cc: mpls@UU.NET > Subject: RE: Lambda Switching > > i have a question on optical buffering -- > what are the available technologies here > or links/references to them? (to be more > precise: are they just pools of fiber > or specially designed mirror boxes, etc.) > > thanks, > -- > dima. > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Krishna > > Bala > > Sent: Wednesday, May 24, 2000 5:50 PM > > To: Yakov Rekhter; Stewart Pu > > Cc: mpls@UU.NET > > Subject: RE: Lambda Switching > > > > > > Stewart, > > If you define Optical Switching as the ability to switch large > pipes in a > > circuit switched fashion .... yes, this is the core competence of > optics. > > > > If you define Optical Routing as the ability to switch individual > packets > > in a packet switched manner .... no, this is not the strength of > > optics. The > > biggest barrier to entry for optics here is the inability of > optics to > > perform > > buffering. Large spools of fiber are used as "delay lines" to > emulate > > buffering. > > > > > > Krishna Bala > > Tellium > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Yakov > > > Rekhter > > > Sent: Wednesday, May 24, 2000 1:06 PM > > > To: Stewart Pu > > > Cc: mpls@UU.NET > > > Subject: Re: Lambda Switching > > > > > > > > > Stewart, > > > > > > > I have a question about MPLS. Is it possible for MPLS using > > > lambda as the > > > > label? I mean, if DWDM technology can provide enough available > > > lambda, can > > > > MPLS use lambda as the label? > > > > > > Yes. See draft-awduche-mpls-te-optical-01.txt. > > > > > > > If yes, can we say ' We can achieve optical switching or > > > optical routing.'? > > > > > > It depends on how you define "optical switching or optical > routing". > > > > > > > But I ever heard that it is impossible to achieve optical > routing, > > > > is it right? > > > > > > I guess folks who told you so may reconsider their opinion :-) > > > > > > Yakov. > > > > > > From owner-mpls@UU.NET Thu May 25 14:55:47 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 OAA17891 for ; Thu, 25 May 2000 14:55:47 -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 QQiqsx20807; Thu, 25 May 2000 18:52:38 GMT Received: by mail-control.mail.uu.net id QQiqsx23404 for mpls-outgoing; Thu, 25 May 2000 18:52: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 QQiqsx23395 for ; Thu, 25 May 2000 18:52:15 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 QQiqsx07212 for ; Thu, 25 May 2000 14:51:54 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQiqsx20136 for ; Thu, 25 May 2000 18:51:53 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 11:57:22 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D10@ICARIAN> From: Eric Gray To: "'curtis@avici.com'" , otel@ce.chalmers.se Cc: mpls@UU.NET Subject: RE: RFC 2702 and LSP attributes Date: Thu, 25 May 2000 11:57:22 -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 Curtis, The "binary" version of adaptivity does need to be signaled. This is done either by specifying a strict explicit route, or by "pinning" the route using some other mechanism. Otherwise, the decision to re-route is up to the last explicit hop before a loosely specified explicit next hop. For example, using RSVP-TE, a re-route occurs automatically for loosely specified hops because of PATH redirection. Finer tuning of "Adaptivity" is done by the ingress, either as a function of deciding when to re-route, or in specifying the explicit path more or less loosely in signaling. -- Eric Gray > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@avici.com] > Sent: Thursday, May 25, 2000 11:22 AM > To: otel@ce.chalmers.se > Cc: mpls@UU.NET > Subject: Re: RFC 2702 and LSP attributes > > > > In message > <14637.8526.593947.107314@rasputin.ce.chalmers.se>, Florian-Daniel O > tel writes: > > > > 1) Section 5.8 "Preemtption attribute". Why there are defined four > > preemtion modes and then a discussion about the obvious impossible > > combinations ? Quite a few other attributes defined in prev > > subsections (e.g. "Path preference rule", "Resource affinity", > > "Adaptivity") are binary attributes, so the four preemtion > modes could > > be simply implemented w/ two binary attributes "preemtor?" > (yes/no) and > > "preemtable?" (yes/no). In addition to the simplicity there > will be no need > > to state the obvious impossible combinations. > > RFC2702 is really a requirements document, not a protocol definition. > > The sample implementation are just samples and are described in > RFC2702 as minimal implementations. For example, the Adaptivity > attribute need not be binary. Parameters can be specified to provide > finer control over how quickly an LSP reacts to a change in available > resources. > > > 2) RFC 2702 seems to me a rather lax framework for what LSP > attributes are. > > Is there any other document describing in more detail what are LSP > > attributes (e.g. number of priority values, formats, etc) or each > > label distrib. proto is free to implement it however it sees fit as > > long as it is within the RFC 2702 framework and takes into > consideration the > > link attributes as defined by the present "IGP Requirements for > > Traffic Engineering with MPLS" (i.e. the long-since-expired > > draft-li-mpls-igp-te-00.txt) ? > > See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt regarding your questions > about "Preemtption attribute". > > Setup Priority > > The priority of the session with respect to taking > resources, > in the range of 0 to 7. The value 0 is the > highest priority. > The Setup Priority is used in deciding whether this > session can > preempt another session. > > Holding Priority > > The priority of the session with respect to holding > resources, > in the range of 0 to 7. The value 0 is the > highest priority. > Holding Priority is used in deciding whether this > session can > be preempted by another session. > > Other parameters mentioned in RFC2702 (for example, the adaptivity > parameter) need not be signalled since the decision to reroute is made > at the ingress. > > Curtis > From owner-mpls@UU.NET Thu May 25 17:06: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 RAA20732 for ; Thu, 25 May 2000 17:06: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 QQiqtg01273; Thu, 25 May 2000 21:04:37 GMT Received: by mail-control.mail.uu.net id QQiqtg27371 for mpls-outgoing; Thu, 25 May 2000 21:04:17 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 QQiqtg27366 for ; Thu, 25 May 2000 21:04:16 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 QQiqtg27330 for ; Thu, 25 May 2000 17:03:51 -0400 (EDT) Received: from alpha.dtix.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.dtix.com [198.62.174.1]) id QQiqtg00660 for ; Thu, 25 May 2000 21:03:48 GMT Received: from madhukar (beta.dtix.com [198.62.174.3]) by alpha.dtix.com (8.9.3/8.8.7) with SMTP id QAA16096 for ; Thu, 25 May 2000 16:17:11 -0400 Message-ID: <044d01bfc68c$34b288e0$cfae3ec6@dtix.com> From: "madhukar khare" To: Subject: LDP DoD/DU on ethernet/packet over sonet Date: Thu, 25 May 2000 17:00:00 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_044A_01BFC66A.A9E45610" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_044A_01BFC66A.A9E45610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I wanted an opinion on the mode LDP is being used to run on ethernet.=20 Do people prefer running downstream unsolicited over downstream on demand in deployment using ethernet or POS media, or either one is ok? --madhukar -- Madhukar Khare Digital Technology 55 Middlesex Turnpike Bedford MA 01730 mkhare@dtix.com ------=_NextPart_000_044A_01BFC66A.A9E45610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I wanted an opinion on the mode LDP is = being used=20 to run on ethernet.
Do people prefer = running downstream=20 unsolicited over downstream
on demand in deployment using ethernet or POS media, or either one
is ok?
 
--madhukar
 
--
Madhukar Khare
Digital Technology
55 Middlesex Turnpike
Bedford MA 01730
 
mkhare@dtix.com
 
 
 
------=_NextPart_000_044A_01BFC66A.A9E45610-- From owner-mpls@UU.NET Thu May 25 17:16: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 ESMTP id RAA20834 for ; Thu, 25 May 2000 17:16: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 QQiqtg17125; Thu, 25 May 2000 21:14:13 GMT Received: by mail-control.mail.uu.net id QQiqtg28226 for mpls-outgoing; Thu, 25 May 2000 21:13:56 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 QQiqtg28217 for ; Thu, 25 May 2000 21:13: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 QQiqtg08261 for ; Thu, 25 May 2000 17:13:35 -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 QQiqtg16605 for ; Thu, 25 May 2000 21:13:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA25455 for mpls@uu.net; Thu, 25 May 2000 17:13:34 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiqtg28186 for ; Thu, 25 May 2000 21:12:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqtg12269 for ; Thu, 25 May 2000 17:03:28 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQiqtg00488 for ; Thu, 25 May 2000 21:03:27 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA15438; Thu, 25 May 2000 14:03:11 -0700 (PDT) Message-Id: <4.3.1.2.20000526065341.00ae5a60@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 26 May 2000 07:02:53 +1000 To: "Naveen Seth" From: Jeremy Lawrence Subject: Re: MPLS domain - AS Cc: In-Reply-To: <021801bfc636$7bebfc60$140d85a5@dti.daewoo.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 16:16 05/25/2000 +0530, Naveen Seth wrote: >Hi, >The definition of MPLS domain in the draft-ietf-mpls-arch-06.txt says that the MPLS nodes are in one routing or administrative domain. > >1. Does it imply that we cannot have 2 AS(Autonomous System) within the same MPLS domain? This is possible only under very restricted circumstances. Consider the ASBRs of two adjacent ASes. If either or both ASBRs summarize eBGP routes before distributing them into their IGP, or if there is any other set-up where the IGP routes cover a set of FECs which differs from that of the eBGP routes (and this would almost always be the case), then the ASBRs cannot forward traffic based on the top-level label. A similar argument applies to TE tunnels. Some traffic usually will be either IP forwarded by the ASBR, or forwarded based on a non-top-level label (sections 10(a), 10(b), and the later part of 10(c) of http://www.ietf.org/internet-drafts/draft-rosen-rfc2547bis-01.txt describe MPLS applications where forwarding based on a non-top-level label will occur at an ASBR). So there would usually be 2-3 MPLS forwarding domains if there were two ASes: one for each of the two ASes, and possibly one for the link between the two ASBRs (in the case that labelled packets instead of Ip packets are forwarded between the two ASBRs). Also, it's likely that the ASBRs could not be ATM-LSRs, as ATM-LSRs typically have limited or no capability of manipulating label stacks or forwarding unlabelled IP traffic. Regards, Jeremy Lawrence From owner-mpls@UU.NET Thu May 25 23:16: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 XAA26986 for ; Thu, 25 May 2000 23:16: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 QQiquf15485; Fri, 26 May 2000 03:15:28 GMT Received: by mail-control.mail.uu.net id QQiquf12805 for mpls-outgoing; Fri, 26 May 2000 03:15:14 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQiquf12798 for ; Fri, 26 May 2000 03:15:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQique10397 for ; Thu, 25 May 2000 23:10:56 -0400 (EDT) Received: from mail.cic.tsinghua.edu.cn by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cic.tsinghua.edu.cn [166.111.4.11]) id QQique12724 for ; Fri, 26 May 2000 03:10:50 GMT Received: from ee ([166.111.64.36]) by mail.cic.tsinghua.edu.cn (8.8.7/8.8.7) with SMTP id LAA25208 for ; Fri, 26 May 2000 11:31:39 +0900 (CDT) Message-Id: <200005260231.LAA25208@mail.cic.tsinghua.edu.cn> Date: Fri, 26 May 2000 10:24:58 +0800 From: qtl To: "mpls@uu.net" Subject: digital wrapper! X-mailer: FoxMail 3.0 beta 2 [cn] 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 am wondering about if digital wrapper has any relation with digital wrapper?Anyone can help me about it?Thanks! Where can I find the document about digital wrapper! qtl qtl@263.net From owner-mpls@UU.NET Fri May 26 08:03: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 IAA12958 for ; Fri, 26 May 2000 08:03: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 QQiqvo21095; Fri, 26 May 2000 12:01:50 GMT Received: by mail-control.mail.uu.net id QQiqvo21307 for mpls-outgoing; Fri, 26 May 2000 12:01:15 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 QQiqvo21196 for ; Fri, 26 May 2000 12:01: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 QQiqvo08320 for ; Fri, 26 May 2000 08:00:58 -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 QQiqvo20479 for ; Fri, 26 May 2000 12:00:58 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Fri, 26 May 2000 12:54:39 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Fri, 26 May 2000 12:54:36 +0100 Message-ID: To: Vishal.Sharma@tellabs.com, ramp@sasi.com, khaled@pacificpost.com Cc: mpls@UU.NET, ramp_mpls@yahoo.com, khaled@ieee.org Subject: RE: MPLS Performance analysis..... Date: Fri, 26 May 2000 12:54:42 +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 You might also like to reflect not just on performance issues when all the network is 'up' (so this is in the QoS domain), but also the behaviour when part of the network goes 'down' (so this is in the availability domain........though there is a mutation of failures=>QoS impairments in the IP layer). And and early issue you hit is: "What are the defects that can occur in the MPLS layer, where are these specified in terms of entry/exit criteria and consequent actions, how are these detected, and how do we relate these to protection/restoration actions (esp when LSPs are nested)?" Regards, Neil > Ramprasad, > > It is unlikely that anyone will be able to give you a ready-made > simulation scenario. I think > Florian made some good suggestions on the readings. > > I think what is missing in your plan is a clearer objective. You sort of > stated > it when you said : > > want to show how MPLS is > > advantageous over normal IP in as many aspects as I can, using my MPLS > > simulation (using ns). > (I think it still might be useful to ask why you want to do this, and what > is the final purpose of doing this exercise.) > > Assuming this is your aim, you have to ask yourself (a) in what respects > is MPLS > stated to be better than IP and (b) what would be a way to design a > simulation > to demonstrate that. > > As Brijesh mentioned in an earlier email, a worthwhile comparison is > really > to examine what MPLS provides in terms of traffic engineering capabilities > relative to either pure IP routing, or IP routing augmented with some > traffic engineering capabilities in the interior gateway protocols (IGP), > such as > equal-cost multipath, or metric tuning. > > If this is the aspect that one believes MPLS could be better in, then the > following > could be one simple way to go about it. > > So let's say that at a first-level you assume the following: > (i) a network topology (the nodes, their locations) and parameters (the > link capacities, and > metrics). > (ii) a traffic matrix for the network (that is, static demands; a > simplistic scenario, but > probably > a good starting point, especially if you consider backbone networks that > carry aggregated > demands that are likely to be fairly constant [they might have some > variation about a mean > value, but one could assume for starters that the variation is small]). > > The aim of the comparison then could be to comapre the following (Brijesh > already pointed > this out) > (a) The delay experienced by the traffic, with and without MPLS traffic > engineering. > (b) The total amount of traffic that could be served, with and without > MPLS traffic engineering. > (Given any traffic matrix, you may not be able to serve all of it, so > you'd have to see > how much of the demand you can serve in the two cases.) > > (We will ignore forwarding performance, since as people have pointed out, > that is > implementation dependent, and is not really a differetiator for MPLS > anymore.) > > Please note, that to do this your simulation will, in addition, have to > run some algorithm(s) > that can decide exactly which MPLS LSPs to set up, and how much bandwidth > to assign > to each of them to serve the traffic demands specified in your traffic > matrix. > > So in effect, what you will really be testing is the "goodness" of these > LSP placement > algorithms, because the better these algorithms are in finding "good" > paths through > the network (assuming that these paths can then be setup using MPLS > signaling protocols), the > better is likely to be the performance of the MPLS-based scheme > relative to IP routing. > > -Vishal > > On Thursday, May 25, 2000 4:58 AM, ramp@sasi.com [SMTP:ramp@sasi.com] > wrote: > > Hi, > > > > > > Can U suggest an example scenario of what U mentioned here with all the > > details of link bandwidths ,packet sizes, Type of packets ...etc. As I > am > > new to this kind of analysis, I don't have any realistic scenario at > > present. > > > > Thank U very much > > B G Ramprasad Torati > > On Thu, 25 May 100, Khaled Elsayed wrote: > > > > > > > > As other people said, it is not surprising you would get the same > results. You would need to > > > come up with a scenario where if you use tradional routing versus > proper traffic engineering as > > > in MPLS, the difference in the peformance will be clear. However, your > scenario should be as > > > realistic as possible, i.e. it can happen in an IP-based network. This > is the difficult part. > The > > > rest should be easy. > > > > > > BR, > > > > > > Khaled Elsayed > > > > > > > > > > > > ---------- Original Message ---------------------------------- > > > From: B G Ramprasad Torati > > > Date: Tue, 23 May 2000 21:53:47 -0700 (PDT) > > > > > > >Hi > > > > > > > >I simulated the LDP and MPLS packet switching parts of > > > >MPLS by extending the network simulator 2. > > > >Now I want to do the performance analysis between the > > > >two forwarding paradigms( MPLS forwarding and normal > > > >IP forwarding). > > > > > > > >For this I have taken an example topology and did the > > > >following things. > > > >1. Using CBR agent I calculated the delays by using > > > >loss monitor as the sink of the CBR packets. > > > >2. Using Ping agents I calculated the round trip time. > > > > > > > >I did those using both normal IP and MPLS with LDP. > > > >But I didn't get any difference between those two > > > >forwarding paradigms. I calculated the no. of packets > > > >lost using CBR agents. Still I got the same > > > >performance for both the above. I used both Link state > > > >and Distance Vector dynamic roting protocols while > > > >doing this analysis. > > > > > > > >So can anybody suggest how to do the performance > > > >analysis. I am new to this, so please tell how exactly > > > >I have to proceed in doing this analysis. > > > > > > > >Thanks and Regards, > > > >Ramp > > > > > > > >__________________________________________________ > > > >Do You Yahoo!? > > > >Send instant messages & get email alerts with Yahoo! Messenger. > > > >http://im.yahoo.com/ > > > > > > > > > > > > > From owner-mpls@UU.NET Fri May 26 09:12: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 JAA14512 for ; Fri, 26 May 2000 09:12: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 QQiqvs12934; Fri, 26 May 2000 13:11:27 GMT Received: by mail-control.mail.uu.net id QQiqvs12363 for mpls-outgoing; Fri, 26 May 2000 13:10:54 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqvs12323 for ; Fri, 26 May 2000 13:10:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqvs19679 for ; Fri, 26 May 2000 09:08:35 -0400 (EDT) Received: from ihemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQiqvs10509 for ; Fri, 26 May 2000 13:08:35 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA21235 for ; Fri, 26 May 2000 09:08:34 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA21216; Fri, 26 May 2000 09:08:33 -0400 (EDT) Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA17215; Fri, 26 May 2000 09:08:31 -0400 (EDT) Message-ID: <392E7742.BB3CC86D@lucent.com> Date: Fri, 26 May 2000 09:08:18 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: qtl CC: "mpls@uu.net" Subject: Re: digital wrapper! References: <200005260231.LAA25208@mail.cic.tsinghua.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit qtl wrote: > > hi: > I am wondering about if digital wrapper has any relation with > digital wrapper?Anyone can help me about it?Thanks! Where can I find > the document about digital wrapper! > > qtl > qtl@263.net If you mean wave wrapper and digital wrapper, they are the same. For more information, you can check ANSI T1X1 web site. Yangguang From owner-mpls@UU.NET Fri May 26 10:21: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 ESMTP id KAA16173 for ; Fri, 26 May 2000 10:21: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 QQiqvx29319; Fri, 26 May 2000 14:20:45 GMT Received: by mail-control.mail.uu.net id QQiqvx27112 for mpls-outgoing; Fri, 26 May 2000 14:20:11 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 QQiqvx27098 for ; Fri, 26 May 2000 14:20: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 QQiqvx15445 for ; Fri, 26 May 2000 10:19:39 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQiqvx28276 for ; Fri, 26 May 2000 14:19:39 GMT Received: from oleary-lt (pm3-1-ppp9.juniper.net [207.79.80.10]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id HAA00770; Fri, 26 May 2000 07:18:34 -0700 (PDT) Message-Id: <4.2.0.58.20000526065653.02aaad50@garnet.juniper.net> X-Sender: doleary@garnet.juniper.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 26 May 2000 07:00:55 -0700 To: curtis@avici.com From: "dave o'leary" Subject: Re: MPLS Performance analysis..... Cc: mpls@UU.NET In-Reply-To: <200005242152.RAA20275@curtis-lt.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:52 PM 5/24/00 -0400, Curtis Villamizar wrote: >In message <14636.980.167643.543102@rasputin.ce.chalmers.se>, >Florian-Daniel Ot >el writes: > > > > > Hi > > > I simulated the LDP and MPLS packet switching parts of > > > MPLS by extending the network simulator 2. > > > Now I want to do the performance analysis between the > > > two forwarding paradigms( MPLS forwarding and normal > > > IP forwarding). > > > > Well, with the risk of getting flamed, i would argue that if you want > > to test _only_ the relative speed of MPLS switching vs. IP forwarding, > > a simulated environment doesn't sound to be the most appropriate way of > > doing this. > > > > Even more, assuming that you have access to 'real-world' code from a > > vendor, comparing the relative speeds of the two forwarding paradigms > > will be non-trivial: You will have to analyze the processing paths for > > the two cases, install stubs in the software, etc. > > > > All in all the relative performance analysis you want is irrelevant > > IMHO: It all depends on the details of a specific implementation. So, > > even that if, in theory, "MPLS switching is faster than IP forwarding > > cause it's based on table indexing and not a longest-prefix match" (or > > a similar mantra) I would take this type of statements with a grain > > of salt. Remember, "the devil is in the details".. > > > > > > Cheers, > > > > Florian. > > >Florian, > >The plain fact is that it just doesn't matter. The shortest speed of >light delays in any WAN application is on the order of a few >milliseconds. Queueing delay can be hundreds of milliseconds if the >outbound interface is congested. Modern routers forward IP in a few >10s of microseconds (on fast interfaces). If the path is the same and >the same queue is used, then the difference in forwarding speed >between an IP route lookup and an MPLS label lookup isn't even >measurable and in some (most?) routers the difference is exactly zero. > >Curtis In addition to latency considerations as outlined above, another concern relative to the performance of the lookup engine is the ability to keep up with line rates on the inbound side of the router, that is, if the lookup engine can't keep up with line rate, there needs to be a buffering mechanism on the router/switch ingress. The buffers by nature need to be limited in size and hence the possibility for packet/frame drops, which of course affect the network performance as seen by the end systems. dave From owner-mpls@UU.NET Fri May 26 10:32: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 ESMTP id KAA16453 for ; Fri, 26 May 2000 10:32: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 QQiqvy06373; Fri, 26 May 2000 14:31:07 GMT Received: by mail-control.mail.uu.net id QQiqvy27626 for mpls-outgoing; Fri, 26 May 2000 14:30:35 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqvy27621 for ; Fri, 26 May 2000 14:30:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiqvx27311 for ; Fri, 26 May 2000 10:22:07 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiqvx00429 for ; Fri, 26 May 2000 14:22:07 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id KAA11788 for ; Fri, 26 May 2000 10:22:07 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: Subject: RE: MPLS domain - AS Date: Fri, 26 May 2000 10:25:52 -0400 Message-ID: <001d01bfc71e$4c7efc00$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: <4.3.1.2.20000526065341.00ae5a60@bulkrate.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In his last mail, Jeremy Lawrence writes > At 16:16 05/25/2000 +0530, Naveen Seth wrote: > >Hi, > >The definition of MPLS domain in the > draft-ietf-mpls-arch-06.txt says that the MPLS nodes are in > one routing or administrative domain. > > > >1. Does it imply that we cannot have 2 AS(Autonomous System) > within the same MPLS domain? > > This is possible only under very restricted circumstances. Consider > the ASBRs of two adjacent ASes. If either or both ASBRs summarize > eBGP routes before distributing them into their IGP, or if there is > any other set-up where the IGP routes cover a set of FECs which > differs from that of the eBGP routes (and this would almost always > be the case), then the ASBRs cannot forward traffic based on the > top-level label. A similar argument applies to TE tunnels. Some > traffic usually will be either IP forwarded by the ASBR, or Well... This is inconsistent with the MPLS Arch document. A MPLS domain is defined in MPLS architecture document as "a contiguous set of nodes which operate MPLS routing and forwarding and WHICH ARE IN *ONE ROUTING OR ADMINISTRATIVE DOMAIN*". This means that a MPLS Domain, at most, can cover one Administrative Domain. Any other implementation (i.e., an MPLS domain being defined as part of two administrative domain) is not in line with this definition. Whether this should be the case or not, is all together different issue. Cheers, --brijesh Ennovate Networks Inc. From owner-mpls@UU.NET Fri May 26 12:39: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 MAA19749 for ; Fri, 26 May 2000 12:39: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 QQiqwg20206; Fri, 26 May 2000 16:38:09 GMT Received: by mail-control.mail.uu.net id QQiqwg22425 for mpls-outgoing; Fri, 26 May 2000 16:37: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 QQiqwg22415 for ; Fri, 26 May 2000 16:37: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 QQiqwg08865 for ; Fri, 26 May 2000 12:37:20 -0400 (EDT) Received: from mail.cic.tsinghua.edu.cn by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cic.tsinghua.edu.cn [166.111.4.11]) id QQiqwg01230 for ; Fri, 26 May 2000 16:37:14 GMT Received: from a ([166.111.180.27]) by mail.cic.tsinghua.edu.cn (8.8.7/8.8.7) with SMTP id BAA15318; Sat, 27 May 2000 01:41:59 +0900 (CDT) Message-Id: <200005261641.BAA15318@mail.cic.tsinghua.edu.cn> Date: Sat, 27 May 2000 0:40:57 +0800 From: qtl To: "mpls@uu.net" CC: "ietf@ietf.org" Subject: wave wrapper! X-mailer: FoxMail 3.0 beta 2 [cn] 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: How about digital wrapper(wave wrapper?) now?I want to know it! Where can I find the document about it? Thank you! From owner-mpls@UU.NET Fri May 26 23:31: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 XAA02198 for ; Fri, 26 May 2000 23:31: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 QQiqxy11116; Sat, 27 May 2000 03:30:36 GMT Received: by mail-control.mail.uu.net id QQiqxy05550 for mpls-outgoing; Sat, 27 May 2000 03:30:07 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQiqxy05545 for ; Sat, 27 May 2000 03:30:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiqxx29764 for ; Fri, 26 May 2000 23:23:27 -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 QQiqxx07118 for ; Sat, 27 May 2000 03:23:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA14262 for mpls@uu.net; Fri, 26 May 2000 23:23:25 -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 QQiqxx05227 for ; Sat, 27 May 2000 03:23: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 QQiqxx04716 for ; Fri, 26 May 2000 23:22:45 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQiqxx06816 for ; Sat, 27 May 2000 03:22:44 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id UAA22495; Fri, 26 May 2000 20:22:42 -0700 (PDT) Message-Id: <4.3.1.2.20000527130201.00af87d0@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 27 May 2000 13:22:25 +1000 To: From: Jeremy Lawrence Subject: RE: MPLS domain - AS Cc: In-Reply-To: <001d01bfc71e$4c7efc00$d001010a@tst.ennovatenetworks.com> References: <4.3.1.2.20000526065341.00ae5a60@bulkrate.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Someone else has privately pointed out that Brijesh and I are in violent agreement on this issue. :-) This is not quite true: we are generally in agreement, apart from one detail. Comments inline... At 10:25 05/26/2000 -0400, Brijesh Kumar wrote: >In his last mail, Jeremy Lawrence writes > > > At 16:16 05/25/2000 +0530, Naveen Seth wrote: > > >Hi, > > >The definition of MPLS domain in the > > draft-ietf-mpls-arch-06.txt says that the MPLS nodes are in > > one routing or administrative domain. > > > > > >1. Does it imply that we cannot have 2 AS(Autonomous System) > > within the same MPLS domain? > > > > This is possible only under very restricted circumstances. Consider > > the ASBRs of two adjacent ASes. If either or both ASBRs summarize > > eBGP routes before distributing them into their IGP, or if there is > > any other set-up where the IGP routes cover a set of FECs which > > differs from that of the eBGP routes (and this would almost always > > be the case), then the ASBRs cannot forward traffic based on the > > top-level label. A similar argument applies to TE tunnels. Some > > traffic usually will be either IP forwarded by the ASBR, or > >Well... This is inconsistent with the MPLS Arch document. No, it is consistent but unlikely - see below. >A MPLS domain is defined in MPLS architecture document as "a contiguous set >of nodes which operate MPLS routing and forwarding and WHICH ARE IN *ONE >ROUTING OR ADMINISTRATIVE DOMAIN*". > >This means that a MPLS Domain, at most, can cover one Administrative Domain. Agreed. >Any other implementation (i.e., an MPLS domain being defined as part of two >administrative domain) is not in line with this definition. Agreed. It is possible for two ASes to be in the same administrative domain. There are a small number of large SP networks which consist of more than one registered AS, and there are probably many more which use private ASes. In the unlikely case that an MPLS domain does extend across two ASes, the two ASes must have tightly coordinated routing, which would require that they are in the same administrative domain (at least in effect). Regards, Jeremy From owner-mpls@UU.NET Mon May 29 06:26: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 GAA28948 for ; Mon, 29 May 2000 06:26: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 QQirgj25313; Mon, 29 May 2000 10:23:23 GMT Received: by mail-control.mail.uu.net id QQirgj16945 for mpls-outgoing; Mon, 29 May 2000 10:22:54 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQirgj16940 for ; Mon, 29 May 2000 10:22:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQirgj17151 for ; Mon, 29 May 2000 06:22:33 -0400 (EDT) Received: from crid.u-bourgogne.fr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: crid.u-bourgogne.fr [192.134.59.59]) id QQirgj12545 for ; Mon, 29 May 2000 10:22:32 GMT Received: from curitiba.crid.u-bourgogne.fr (curitiba [192.168.1.10]) by crid.u-bourgogne.fr (8.9.3/8.9.3) with ESMTP id MAA12542 for ; Mon, 29 May 2000 12:23:01 +0200 (MET DST) Received: from curitiba (curitiba [192.168.1.10]) by curitiba.crid.u-bourgogne.fr (8.9.1b+Sun/8.9.1) with SMTP id MAA00972 for ; Mon, 29 May 2000 12:18:23 +0200 (MET DST) Message-Id: <200005291018.MAA00972@curitiba.crid.u-bourgogne.fr> Date: Mon, 29 May 2000 12:18:23 +0200 (MET DST) From: Zouhair ECHCHELH Reply-To: Zouhair ECHCHELH Subject: MPLS NIST Simulator To: mpls@UU.NET MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: 50PtbMDQF1VDQwylGrmT+w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id GAA28948 Hi, Anu idea about the MPLS NIST Simulator Extention are welcome. Thanks. Zouhair ECHCHELH Fonction : ATER Adresse: Université de Bourgogne E-mail : ze@crid.u-bourgogne.fr Laboratoire LIRSIA Tél(Labo): (33) 03 80 39 58 82 Faculté des Sciences Mirande Fax : (33) 03 80 39 58 87 9, allée Alain Savary Mobile : (33) 06 70 05 08 55 B.P. 47870 - 21078 Bureau : (33) 03 80 39 58 17 DIJON CEDEX - FRANCE. URL : http://recife.u-bourgogne.fr:8081/~echchelh From owner-mpls@UU.NET Mon May 29 07:18: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 ESMTP id HAA29350 for ; Mon, 29 May 2000 07:18:48 -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 QQirgn20671; Mon, 29 May 2000 11:16:07 GMT Received: by mail-control.mail.uu.net id QQirgn28592 for mpls-outgoing; Mon, 29 May 2000 11:15: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 QQirgn28586 for ; Mon, 29 May 2000 11:15: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 QQirgn13894 for ; Mon, 29 May 2000 07:15:28 -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 QQirgn27026 for ; Mon, 29 May 2000 11:15:27 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA07694 for mpls@uu.net; Mon, 29 May 2000 07:15:26 -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 QQirgn28369 for ; Mon, 29 May 2000 11:15: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 QQirgm12253 for ; Mon, 29 May 2000 07:14:55 -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 QQirgm19907 for ; Mon, 29 May 2000 11:14:55 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id EAA27610; Mon, 29 May 2000 04:14:22 -0700 (PDT) Message-Id: <200005291114.EAA27610@omega.cisco.com> To: smd@ebone.net (Sean Doran) cc: mpls@UU.NET Subject: Re: MPLS Performance analysis..... In-reply-to: Your message of "Thu, 25 May 2000 01:06:11 +0200." <20000524230611.460FB87A@sean.ebone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27608.959598861.1@cisco.com> Date: Mon, 29 May 2000 04:14:22 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Sean, > Several people write: > > > [lots of commentary about how wonderful MPLS is at making forwarding fast] > > You are analysing the performance of MPLS using the wrong metric. > I think MPLS performs exactly as intended. > Ipsilon basically died, and not even Nokia could revive it. > UUNET found a new layer-2 religion, essentially killing backbone ATM. > Many companies are distracted from actually learning how to do IP routing. Of course, for some folks the *one and only* way to move data is by looking at the IP header, and executing the longest match algorithm on the destination address in that header (aka "destination based routing"). Anything else (e.g., MPLS), *regardless* of its pragmatic value, is viewed as "religion", "distraction", etc... Yakov. From owner-mpls@UU.NET Mon May 29 17:20: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 RAA04088 for ; Mon, 29 May 2000 17:20: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 QQirib05405; Mon, 29 May 2000 21:16:54 GMT Received: by mail-control.mail.uu.net id QQirib27206 for mpls-outgoing; Mon, 29 May 2000 21:16: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 QQirib27197 for ; Mon, 29 May 2000 21:16: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 QQirib25440 for ; Mon, 29 May 2000 17:16: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 QQirib04723 for ; Mon, 29 May 2000 21:16:07 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA00253 for mpls@uu.net; Mon, 29 May 2000 17:16:07 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQirib27047 for ; Mon, 29 May 2000 21:15:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQirib03761 for ; Mon, 29 May 2000 17:15:20 -0400 (EDT) Received: from qhars002.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19]) id QQirib28041 for ; Mon, 29 May 2000 21:15:19 GMT Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Mon, 29 May 2000 22:14:01 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LWW4LQFV; Mon, 29 May 2000 22:14:02 +0100 Received: from nortelnetworks.com (LANDERSS [141.251.192.211]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L4PJHLJX; Mon, 29 May 2000 23:13:57 +0200 Message-ID: <3932DDD1.805FDAA7@nortelnetworks.com> Date: Mon, 29 May 2000 23:14:57 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: "Loa Andersson" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Sean Doran CC: mpls@UU.NET Subject: Re: MPLS Performance analysis..... References: <20000524230611.460FB87A@sean.ebone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sean Doran wrote: > > Several people write: > > > [lots of commentary about how wonderful MPLS is at making forwarding fast] > So comments are basically wrong, HW forwarding on IP header is exactly as fast as Label based forwarding- wired speed! BTW - who were the people that made those comments? > < snip> > UUNET found a new layer-2 religion, essentially killing backbone ATM. > Many companies are distracted from actually learning how to do IP routing. > Poor UU-net - they were converted to a non-sense religion. MPLS is not L2 it is L3. Or is the misunderstanding by those who try to explain what UU-net believes? /Loa > > Sean. -- Loa Andersson Director Routing Architecture Lab, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Mon May 29 22:48:02 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 WAA07751 for ; Mon, 29 May 2000 22:48: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 QQiriw13693; Tue, 30 May 2000 02:43:56 GMT Received: by mail-control.mail.uu.net id QQiriw27362 for mpls-outgoing; Tue, 30 May 2000 02:43:34 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 QQiriw27357 for ; Tue, 30 May 2000 02:43: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 QQiriw26373 for ; Mon, 29 May 2000 22:43:18 -0400 (EDT) Received: from mmu.edu.my by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ext-dns.mmu.edu.my [203.106.62.11]) id QQiriw06781 for ; Tue, 30 May 2000 02:43:17 GMT Received: from venus.cyber.mmu.edu.my (venus.cyber.mmu.edu.my [203.106.62.12]) by mmu.edu.my (8.9.1b+Sun/8.9.1) with ESMTP id KAA06216 for ; Tue, 30 May 2000 10:29:59 +0800 (MYT) Received: from mmu.edu.my ([10.100.38.28]) by venus.cyber.mmu.edu.my (8.8.8+Sun/8.8.8) with ESMTP id KAA14242 for ; Tue, 30 May 2000 10:41:14 +0800 (SGT) Message-ID: <393329E5.D5D9003C@mmu.edu.my> Date: Tue, 30 May 2000 02:39:33 +0000 From: Tan Su Wei Organization: Multimedia University X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: can egress know the ingress of a packet? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I'd a doubt on : In a mpls network domain, for a particular ingress-egress pair with multiple LSPs in between them, is it possible when a packet reach the engress node, the engress node will know the following: i. ) the ingress node ii.) the lsp it travel Thanks for any reply. Regards Tan Su Wei From owner-mpls@UU.NET Mon May 29 23:17: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 XAA07938 for ; Mon, 29 May 2000 23:17: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 QQiriz02040; Tue, 30 May 2000 03:16:24 GMT Received: by mail-control.mail.uu.net id QQiriz07840 for mpls-outgoing; Tue, 30 May 2000 03:15: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 QQiriz07807 for ; Tue, 30 May 2000 03: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 QQiriz29523 for ; Mon, 29 May 2000 23:15:42 -0400 (EDT) Received: from md3.vsnl.net.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: md3.vsnl.net.in [202.54.6.35]) id QQiriz03196 for ; Tue, 30 May 2000 03:15:39 GMT Received: from janapc (bay-72.pppmad.vsnl.net.in [203.197.134.244] (may be forged)) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id IAA08248; Tue, 30 May 2000 08:42:30 +0530 (IST) Message-ID: <007701bfc9e5$a0e94880$38c9a8c0@janapc> From: "Pathangi N Janardhanan" To: "Tan Su Wei" , References: <393329E5.D5D9003C@mmu.edu.my> Subject: Re: can egress know the ingress of a packet? Date: Tue, 30 May 2000 08:47:45 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > I'd a doubt on : > In a mpls network domain, for a particular ingress-egress pair > with multiple LSPs in between them, is it possible when a packet reach > the engress node, the engress node will know the following: > i. ) the ingress node > ii.) the lsp it travel > Either the label on the incoming packet or the combination of label and interface of the incoming packet can be used to identify the ingress/LSP of the incoming packet. Thanks Jana From owner-mpls@UU.NET Tue May 30 01:02: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 BAA09036 for ; Tue, 30 May 2000 01:02: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 QQirjg16692; Tue, 30 May 2000 05:01:07 GMT Received: by mail-control.mail.uu.net id QQirjg24423 for mpls-outgoing; Tue, 30 May 2000 05:00:43 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 QQirjg24278 for ; Tue, 30 May 2000 05:00: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 QQirjg16946 for ; Tue, 30 May 2000 01:00:34 -0400 (EDT) Received: from agni.wipinfo.soft.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: agni.wipinfo.soft.net [164.164.6.20]) id QQirjg13592 for ; Tue, 30 May 2000 05:00:23 GMT Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id KAA17528 for ; Tue, 30 May 2000 10:26:54 +0500 (GMT) Received: from platinum.mail.wipro.com ([192.168.223.18]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id KAA08884 for ; Tue, 30 May 2000 10:28:59 +0500 (GMT) Received: from [192.168.253.221] by platinum.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA1856 for ; Tue, 30 May 2000 10:30:49 +0530 Date: Tue, 30 May 2000 05:01:52 +0000 ( ) From: "Bhaskara Venkata Nookeswara Rao" X-Sender: bhaskara.peela@Bhaskara To: mpls@UU.NET Subject: Regd. Signaling protocols Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, What should be the basis for selecting/configuring a signaling protocol for MPLS LSP establishments if LSR is capable of both RSVP and LDP/CR-LDP? Is there any MIB which does support this configurability? Is it possible for an LSR to configure RSVP on one interface and LDP on another interface. regards bhaskar From owner-mpls@UU.NET Tue May 30 01:38: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 ESMTP id BAA13540 for ; Tue, 30 May 2000 01:38:08 -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 QQirji10704; Tue, 30 May 2000 05:36:52 GMT Received: by mail-control.mail.uu.net id QQirji02319 for mpls-outgoing; Tue, 30 May 2000 05:36: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 QQirji02299 for ; Tue, 30 May 2000 05:36:12 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 QQirji20312 for ; Tue, 30 May 2000 01:35:57 -0400 (EDT) Received: from md3.vsnl.net.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: md3.vsnl.net.in [202.54.6.35]) id QQirji07069 for ; Tue, 30 May 2000 05:35:55 GMT Received: from janapc (bay-71.pppmad.vsnl.net.in [203.197.134.159] (may be forged)) by md3.vsnl.net.in (8.9.3/8.9.3) with SMTP id LAA12712; Tue, 30 May 2000 11:01:53 +0530 (IST) Message-ID: <003101bfc92f$ef2ccdc0$38c9a8c0@janapc> From: "Pathangi N Janardhanan" To: "Bhaskara Venkata Nookeswara Rao" , References: Subject: Re: Regd. Signaling protocols Date: Mon, 29 May 2000 11:07:03 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > Hi, > > What should be the basis for selecting/configuring a signaling > protocol for MPLS LSP establishments if LSR is capable of both RSVP and > LDP/CR-LDP? Is there any MIB which does support this configurability? > > Is it possible for an LSR to configure RSVP on one interface > and LDP on another interface. Please look at the draft draft-wright-mpls-crldp-rsvpte-iw-00.txt Thanks Jana From owner-mpls@UU.NET Tue May 30 09:53: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 JAA28831 for ; Tue, 30 May 2000 09:53: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 QQirkp13462; Tue, 30 May 2000 13:52:22 GMT Received: by mail-control.mail.uu.net id QQirkp11010 for mpls-outgoing; Tue, 30 May 2000 13:52: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 QQirkp10985 for ; Tue, 30 May 2000 13:51: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 QQirkp08283 for ; Tue, 30 May 2000 09:51:45 -0400 (EDT) Received: from shrimp.baynetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns4.BayNetworks.COM [192.32.253.7]) id QQirkp12780 for ; Tue, 30 May 2000 13:51:45 GMT Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id JAA05766; Tue, 30 May 2000 09:45:56 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id JAA23346; Tue, 30 May 2000 09:56:07 -0400 (EDT) Received: from bubba.engeast (bubba [192.168.136.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id JAA11492; Tue, 30 May 2000 09:51:12 -0400 for Received: by bubba.engeast (SMI-8.6/SMI-SVR4) id JAA14478; Tue, 30 May 2000 09:51:12 -0400 From: dwilder@baynetworks.com (David Wilder) Message-Id: <200005301351.JAA14478@bubba.engeast> Subject: Re: Regd. Signaling protocols In-Reply-To: from Bhaskara Venkata Nookeswara Rao at "May 30, 2000 05:01:52 am" To: Bhaskara Venkata Nookeswara Rao Date: Tue, 30 May 2000 09:51:12 -0400 (EDT) CC: mpls@UU.NET X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 bhaskar, I would think that scaling (# of LSPs per MPLS I/F, port or box) and performance would be the main two factors. It should definitely be possible to configure RSVP on one MPLS I/F and LDP on another on an LSR. Dave > > Hi, > > What should be the basis for selecting/configuring a signaling > protocol for MPLS LSP establishments if LSR is capable of both RSVP and > LDP/CR-LDP? Is there any MIB which does support this configurability? > > Is it possible for an LSR to configure RSVP on one interface > and LDP on another interface. > > regards > bhaskar > > From owner-mpls@UU.NET Tue May 30 10:03: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 KAA29171 for ; Tue, 30 May 2000 10:03: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 QQirkq22924; Tue, 30 May 2000 14:02:22 GMT Received: by mail-control.mail.uu.net id QQirkq16587 for mpls-outgoing; Tue, 30 May 2000 14:01:46 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 QQirkq16540 for ; Tue, 30 May 2000 14:01:45 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 QQirkq20321 for ; Tue, 30 May 2000 10:01:34 -0400 (EDT) Received: from shrimp.baynetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns4.BayNetworks.COM [192.32.253.7]) id QQirkq21977 for ; Tue, 30 May 2000 14:01:34 GMT Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id JAA06065; Tue, 30 May 2000 09:55:44 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA23806; Tue, 30 May 2000 10:05:57 -0400 (EDT) Received: from bubba.engeast (bubba [192.168.136.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA13604; Tue, 30 May 2000 10:01:02 -0400 for Received: by bubba.engeast (SMI-8.6/SMI-SVR4) id KAA14504; Tue, 30 May 2000 10:01:01 -0400 From: dwilder@baynetworks.com (David Wilder) Message-Id: <200005301401.KAA14504@bubba.engeast> Subject: Re: can egress know the ingress of a packet? In-Reply-To: <393329E5.D5D9003C@mmu.edu.my> from Tan Su Wei at "May 30, 2000 02:39:33 am" To: Tan Su Wei Date: Tue, 30 May 2000 10:01:01 -0400 (EDT) CC: mpls@UU.NET X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 Can we use the Record route Object for this? Dave > Dear all, > > I'd a doubt on : > In a mpls network domain, for a particular ingress-egress pair > with multiple LSPs in between them, is it possible when a packet reach > the engress node, the engress node will know the following: > i. ) the ingress node > ii.) the lsp it travel > > Thanks for any reply. > > Regards > Tan Su Wei > > > From owner-mpls@UU.NET Tue May 30 10:34: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 ESMTP id KAA29854 for ; Tue, 30 May 2000 10:34: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 QQirks20056; Tue, 30 May 2000 14:32:04 GMT Received: by mail-control.mail.uu.net id QQirks22222 for mpls-outgoing; Tue, 30 May 2000 14:31: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 QQirks22216 for ; Tue, 30 May 2000 14:31: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 QQirks28380 for ; Tue, 30 May 2000 10:31: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 QQirks19019 for ; Tue, 30 May 2000 14:31:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA23653 for mpls@uu.net; Tue, 30 May 2000 10:31:08 -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 QQirks22091 for ; Tue, 30 May 2000 14:30: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 QQirks28122 for ; Tue, 30 May 2000 10:30:16 -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 QQirks18203 for ; Tue, 30 May 2000 14:30:14 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA21037; Tue, 30 May 2000 07:29:33 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 07:29:33 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4059D@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'dwilder@baynetworks.com'" , Tan Su Wei Cc: mpls@UU.NET Subject: RE: can egress know the ingress of a packet? Date: Tue, 30 May 2000 07:26:38 -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, I think in CR-LDP you may use LSP-ID TLV, which will give you the tunnel ingress and the LSP ID. And in RSVP-TE you may use the Sender Template Object, which will give you the same information. RRO may also be used in RSVP-TE, however you only will get the ingress LSR information that you need, but not which LSP it is coming from. Regards, -Shahram >-----Original Message----- >From: dwilder@baynetworks.com [mailto:dwilder@baynetworks.com] >Sent: Tuesday, May 30, 2000 10:01 AM >To: Tan Su Wei >Cc: mpls@UU.NET >Subject: Re: can egress know the ingress of a packet? > > >Can we use the Record route Object for this? > >Dave > >> Dear all, >> >> I'd a doubt on : >> In a mpls network domain, for a particular >ingress-egress pair >> with multiple LSPs in between them, is it possible when a >packet reach >> the engress node, the engress node will know the following: >> i. ) the ingress node >> ii.) the lsp it travel >> >> Thanks for any reply. >> >> Regards >> Tan Su Wei >> >> >> > From owner-mpls@UU.NET Tue May 30 10:39: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 ESMTP id KAA29947 for ; Tue, 30 May 2000 10:39: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 QQirks25996; Tue, 30 May 2000 14:36:53 GMT Received: by mail-control.mail.uu.net id QQirks22468 for mpls-outgoing; Tue, 30 May 2000 14:36: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 QQirks22463 for ; Tue, 30 May 2000 14:36: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 QQirks29474 for ; Tue, 30 May 2000 10:36:12 -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 QQirks23310 for ; Tue, 30 May 2000 14:36:11 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 HAA26291 for ; Tue, 30 May 2000 07:36:20 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA17732 for mpls@uu.net; Tue, 30 May 2000 10:36:10 -0400 (EDT) Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQirfc11580 for ; Mon, 29 May 2000 02:09:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQirfc11255 for ; Sun, 28 May 2000 22:09:41 -0400 (EDT) Received: from web1306.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web1306.mail.yahoo.com [128.11.23.156]) id QQirfc13636 for ; Mon, 29 May 2000 02:09:41 GMT Received: (qmail 2038 invoked by uid 60001); 29 May 2000 02:09:41 -0000 Message-ID: <20000529020941.2037.qmail@web1306.mail.yahoo.com> Received: from [202.247.6.31] by web1306.mail.yahoo.com; Sun, 28 May 2000 19:09:41 PDT Date: Sun, 28 May 2000 19:09:41 -0700 (PDT) From: Vikram Venkataraghavan Subject: ATM Switches as LSR encoding techniques To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk In the MPLS Architecture document (draft-ietf-mpls-arch-06), there are listed three encoding techniques for MPLS labels to encoded directly into the VPI/VCI fields in an ATM AAL5 header. 1. SVC Encoding 2. SVP Encoding 3. SVP Multipoint Encoding The document also points out that there is no interoperability mechanism between ATM LSRs that use different kinds of encoding. Please tell me which kind of encoding is prefered in the industry and why? (concerning the design of ATM LSRs) Thanks in advance, Vikram Venkataraghavan NEC America __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From owner-mpls@UU.NET Tue May 30 10:39: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 ESMTP id KAA29980 for ; Tue, 30 May 2000 10:39: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 QQirks24794; Tue, 30 May 2000 14:37:59 GMT Received: by mail-control.mail.uu.net id QQirks22508 for mpls-outgoing; Tue, 30 May 2000 14:37: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 QQirks22500 for ; Tue, 30 May 2000 14:37: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 QQirks29734 for ; Tue, 30 May 2000 10:37:15 -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 QQirks26508 for ; Tue, 30 May 2000 14:37:14 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 HAA22314 for ; Tue, 30 May 2000 07:37:21 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA17740 for mpls@uu.net; Tue, 30 May 2000 10:37:12 -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 QQirkq20930 for ; Tue, 30 May 2000 14:14: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 QQirkq24050 for ; Tue, 30 May 2000 10:14:04 -0400 (EDT) Received: from phoenix.ficon-tech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: phoenix.ficon-tech.com [209.125.90.2]) id QQirkq05870 for ; Tue, 30 May 2000 14:14:03 GMT Received: from globespan.net (192.168.137.202) by phoenix.ficon-tech.com (Worldmail 1.3.167); 30 May 2000 10:24:50 -0400 Message-ID: <3933CC4F.8F921066@globespan.net> Date: Tue, 30 May 2000 10:12:31 -0400 From: Rohit Chhapolia Organization: Globespan, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tan Su Wei CC: mpls@UU.NET Subject: Re: can egress know the ingress of a packet? References: <393329E5.D5D9003C@mmu.edu.my> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit To determine the ingress node, "Extended Tunnel ID" is useful. From RSVP-TE draft, Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier. Tan Su Wei wrote: > > Dear all, > > I'd a doubt on : > In a mpls network domain, for a particular ingress-egress pair > with multiple LSPs in between them, is it possible when a packet reach > the engress node, the engress node will know the following: > i. ) the ingress node > ii.) the lsp it travel > > Thanks for any reply. > > Regards > Tan Su Wei -- Rohit Chhapolia Globespan, Inc. mailto:rohit@globespan.net http://www.globespan.net From owner-mpls@UU.NET Tue May 30 10:52: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 ESMTP id KAA00280 for ; Tue, 30 May 2000 10:52:41 -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 QQirkt04060; Tue, 30 May 2000 14:50:39 GMT Received: by mail-control.mail.uu.net id QQirkt23243 for mpls-outgoing; Tue, 30 May 2000 14:49:59 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 QQirkt23233 for ; Tue, 30 May 2000 14:49: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 QQirkt21129 for ; Tue, 30 May 2000 10:49:24 -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 QQirkt02967 for ; Tue, 30 May 2000 14:49:17 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 KAA11684 for ; Tue, 30 May 2000 10:49:11 -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 KAA11689 for ; Tue, 30 May 2000 10:49:12 -0400 (EDT) Message-ID: <3933D509.3939A7F7@marconi.com> Date: Tue, 30 May 2000 10:49: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: can egress know the ingress of a packet? References: <393329E5.D5D9003C@mmu.edu.my> <3933CC4F.8F921066@globespan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Rohit Chhapolia wrote: > > To determine the ingress node, "Extended Tunnel ID" is useful. > > From RSVP-TE draft, > > Extended Tunnel ID > > A 32-bit identifier used in the SESSION that remains constant > over the life of the tunnel. Normally set to all zeros. > Ingress nodes that wish to narrow the scope of a SESSION to the > ingress-egress pair may place their IPv4 address here as a > globally unique identifier. I wouldn't use this for that purpose. Note that the draft says "may", not "must" or "shall". This use of extended tunnel ID, while recommended and common, is not a requirement. In theory, any value may be used as long as it uniquely identifies the sender withing the MPLS cloud. This ID could be something other than IP address. -- David From owner-mpls@UU.NET Tue May 30 11:00:45 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 LAA00472 for ; Tue, 30 May 2000 11:00: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 QQirkt10414; Tue, 30 May 2000 14:59:08 GMT Received: by mail-control.mail.uu.net id QQirkt23901 for mpls-outgoing; Tue, 30 May 2000 14:58: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 QQirkt23896 for ; Tue, 30 May 2000 14:58: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 QQirkt23033 for ; Tue, 30 May 2000 10:58:08 -0400 (EDT) Received: from domino.netia.pl by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: domino.netia.pl [195.114.160.130]) id QQirkt09460 for ; Tue, 30 May 2000 14:58:07 GMT Subject: MPLS - ATM interworking? To: mpls@UU.NET From: "Andrzej Czerczak" Date: Tue, 30 May 2000 16:35:33 +0200 Message-ID: X-MIMETrack: Serialize by Router on WaWarNotes/HeadQ(Release 5.0.3 (Intl)|21 March 2000) at 2000-05-30 16:58:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have 2 simple questions: Assume following (very probably) scenario: -customer router is connected to DSLAM and then to ATM edge switch (VC part of connection), and then through MPLS cloud (LSP part of connection) to other customer site. 1) is it possible, acc. to current MPLS specs to provide to customer SLA report using ATM traffic parameters descriptor? What can be other proposals for SLA reporting for customer? 2) just to mention, what about congestion indication (L2) from MPLS -> ATM direction, as one of the actions performed in MPLS net? Thanks for your comments. Andrzej From owner-mpls@UU.NET Tue May 30 11:25: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 LAA01198 for ; Tue, 30 May 2000 11:25: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 QQirkv13696; Tue, 30 May 2000 15:23:42 GMT Received: by mail-control.mail.uu.net id QQirkv04341 for mpls-outgoing; Tue, 30 May 2000 15:23:19 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 QQirkv04327 for ; Tue, 30 May 2000 15:23: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 QQirkv28342 for ; Tue, 30 May 2000 11:22: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 QQirkv12714 for ; Tue, 30 May 2000 15:22:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA02456 for mpls@uu.net; Tue, 30 May 2000 11:22: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 QQirkv04175 for ; Tue, 30 May 2000 15:22: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 QQirkv09789; Tue, 30 May 2000 11:21:45 -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 QQirkv11836; Tue, 30 May 2000 15:21:43 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01074; Tue, 30 May 2000 11:21:40 -0400 (EDT) Message-Id: <200005301521.LAA01074@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, te-wg@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wright-mpls-te-policy-00.txt Date: Tue, 30 May 2000 11:21:39 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks Author(s) : S. Wright, F. Reichmeyer, R. Jaeger, M. Gibson Filename : draft-wright-mpls-te-policy-00.txt Pages : 13 Date : 26-May-00 This document considers the application of policy based traffic engineering techniques to load-balancing in MPLS networks. The objective is not to mandate a specific policy, but to (a) provide an example of a policy based approach to a traffic engineering problem and (b) elucidate a range of potential policies related to load balancing as a traffic engineering objective as guidance for the development of a Policy Information Base (PIB) for MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wright-mpls-te-policy-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-wright-mpls-te-policy-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-wright-mpls-te-policy-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: <20000526105605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wright-mpls-te-policy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wright-mpls-te-policy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000526105605.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue May 30 12:04:48 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 MAA03031 for ; Tue, 30 May 2000 12:04:48 -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 QQirkx16091; Tue, 30 May 2000 15:58:53 GMT Received: by mail-control.mail.uu.net id QQirkx06443 for mpls-outgoing; Tue, 30 May 2000 15:57:00 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 QQirkx06429 for ; Tue, 30 May 2000 15:56: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 QQirkx16987 for ; Tue, 30 May 2000 11:56:15 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQirkx27013 for ; Tue, 30 May 2000 15:56:15 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:01:53 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D2E@ICARIAN> From: Eric Gray To: "'Pathangi N Janardhanan'" , Tan Su Wei Cc: mpls@UU.NET Subject: RE: can egress know the ingress of a packet? Date: Tue, 30 May 2000 09:01:50 -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 Jana, This is not always (or perhaps even generally) true. Information about ingresses for any LSP is lost at each merge point in the LSP. Given the importance of merging for MPLS scalability, it is probably not a good idea to count on an ability to recover information about ingress LSRs from label and incoming interface. -- Eric Gray > -----Original Message----- > From: Pathangi N Janardhanan [mailto:janar@netlab.hcltech.com] > Sent: Monday, May 29, 2000 8:18 PM > To: Tan Su Wei; mpls@UU.NET > Subject: Re: can egress know the ingress of a packet? > > > Hi, > > > I'd a doubt on : > > In a mpls network domain, for a particular ingress-egress > pair > > with multiple LSPs in between them, is it possible when a packet > reach > > the engress node, the engress node will know the following: > > i. ) the ingress node > > ii.) the lsp it travel > > > Either the label on the incoming packet or the combination of label > and interface of the > incoming packet can be used to identify the ingress/LSP of the > incoming packet. > > Thanks > Jana > > From owner-mpls@UU.NET Tue May 30 12:05: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 ESMTP id MAA03061 for ; Tue, 30 May 2000 12:05: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 QQirky21793; Tue, 30 May 2000 16:04:14 GMT Received: by mail-control.mail.uu.net id QQirky15131 for mpls-outgoing; Tue, 30 May 2000 16:03: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 QQirky15095 for ; Tue, 30 May 2000 16:03: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 QQirky18147 for ; Tue, 30 May 2000 12:01:05 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQirky18678 for ; Tue, 30 May 2000 16:01:04 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:06:43 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D2F@ICARIAN> From: Eric Gray To: "'Shahram Davari'" , "'dwilder@baynetworks.com'" , Tan Su Wei Cc: mpls@UU.NET Subject: RE: can egress know the ingress of a packet? Date: Tue, 30 May 2000 09:06:37 -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 Sharam, In CR-LDP, the LSP-ID TLV consists of an IP address of the ingress LSR and a locally unique identifier. Because it can be any address of the ingress LSR, it does not have to be an address the egress LSR will recognize (although it should be a "legal" address - i.e. not private or unregistered). Therefore, I'm not sure how useful it is to try to recapture information on the ingress LSR using the LSP-ID TLV. -- Eric Gray > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, May 30, 2000 7:27 AM > To: 'dwilder@baynetworks.com'; Tan Su Wei > Cc: mpls@UU.NET > Subject: RE: can egress know the ingress of a packet? > > > Hi, > > I think in CR-LDP you may use LSP-ID TLV, which will give you > the tunnel > ingress and the LSP ID. And in RSVP-TE you may use the Sender Template > Object, which will give you the same information. RRO may > also be used in > RSVP-TE, however you only will get the ingress LSR > information that you > need, but not which LSP it is coming from. > > Regards, > -Shahram > > >-----Original Message----- > >From: dwilder@baynetworks.com [mailto:dwilder@baynetworks.com] > >Sent: Tuesday, May 30, 2000 10:01 AM > >To: Tan Su Wei > >Cc: mpls@UU.NET > >Subject: Re: can egress know the ingress of a packet? > > > > > >Can we use the Record route Object for this? > > > >Dave > > > >> Dear all, > >> > >> I'd a doubt on : > >> In a mpls network domain, for a particular > >ingress-egress pair > >> with multiple LSPs in between them, is it possible when a > >packet reach > >> the engress node, the engress node will know the following: > >> i. ) the ingress node > >> ii.) the lsp it travel > >> > >> Thanks for any reply. > >> > >> Regards > >> Tan Su Wei > >> > >> > >> > > > From owner-mpls@UU.NET Tue May 30 12:10: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 ESMTP id MAA03187 for ; Tue, 30 May 2000 12:10: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 QQirky26134; Tue, 30 May 2000 16:08:11 GMT Received: by mail-control.mail.uu.net id QQirky15906 for mpls-outgoing; Tue, 30 May 2000 16:07: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 QQirky15900 for ; Tue, 30 May 2000 16:07: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 QQirky18984 for ; Tue, 30 May 2000 12:06:16 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQirky23966 for ; Tue, 30 May 2000 16:06:15 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:11:54 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D30@ICARIAN> From: Eric Gray To: "'Bhaskara Venkata Nookeswara Rao'" Cc: mpls@UU.NET Subject: RE: Regd. Signaling protocols Date: Tue, 30 May 2000 09:11:48 -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 Bhaskar, Perhaps the single biggest factor in determining the signaling protocol used by any LSR at each interface is the signaling protocol capabilities of its nearest neighbor on that interface. It's arguable that any implementation that is concerned about being inter- operable with other implementations (and useful in a larger number of scenarios) would include a capability to be configured on a per-interface basis for signaling protocol support. Some implementations are less concerned about interoperability concerns than others. -- Eric Gray > -----Original Message----- > From: Bhaskara Venkata Nookeswara Rao > [mailto:bhaskara.peela@wipro.com] > Sent: Monday, May 29, 2000 10:02 PM > To: mpls@UU.NET > Subject: Regd. Signaling protocols > > > > Hi, > > What should be the basis for selecting/configuring a signaling > protocol for MPLS LSP establishments if LSR is capable of > both RSVP and > LDP/CR-LDP? Is there any MIB which does support this configurability? > > Is it possible for an LSR to configure RSVP on one interface > and LDP on another interface. > > regards > bhaskar > > From owner-mpls@UU.NET Tue May 30 12:26: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 MAA03686 for ; Tue, 30 May 2000 12:26: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 QQirkz12507; Tue, 30 May 2000 16:23:54 GMT Received: by mail-control.mail.uu.net id QQirkz16997 for mpls-outgoing; Tue, 30 May 2000 16:23: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 QQirkz16986 for ; Tue, 30 May 2000 16:23: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 QQirkz22390 for ; Tue, 30 May 2000 12:22:31 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQirkz15607 for ; Tue, 30 May 2000 16:22:31 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:27:54 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D33@ICARIAN> From: Eric Gray To: "'Tan Su Wei'" Cc: mpls@UU.NET Subject: RE: can egress know the ingress of a packet? Date: Tue, 30 May 2000 09:27:50 -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 Tan Su Wei, It is possible to know the LSP traversed, only if the LSP is "identified". This is possible with either CR-LDP (using LSP-ID) or RSVP-TE (using SESSION). -- Eric Gray > -----Original Message----- > From: Tan Su Wei [mailto:swtan@mmu.edu.my] > Sent: Monday, May 29, 2000 7:40 PM > To: mpls@UU.NET > Subject: can egress know the ingress of a packet? > > > Dear all, > > I'd a doubt on : > In a mpls network domain, for a particular ingress-egress pair > with multiple LSPs in between them, is it possible when a packet reach > the engress node, the engress node will know the following: > i. ) the ingress node > ii.) the lsp it travel > > Thanks for any reply. > > Regards > Tan Su Wei > > > From owner-mpls@UU.NET Tue May 30 12:47: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 MAA04237 for ; Tue, 30 May 2000 12:47: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 QQirlb03739; Tue, 30 May 2000 16:46:02 GMT Received: by mail-control.mail.uu.net id QQirlb18291 for mpls-outgoing; Tue, 30 May 2000 16:45: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 QQirlb18286 for ; Tue, 30 May 2000 16:45: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 QQirla12946 for ; Tue, 30 May 2000 12:44:40 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQirla00225 for ; Tue, 30 May 2000 16:44:39 GMT Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA01079; Tue, 30 May 2000 09:44:00 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id JAA17897; Tue, 30 May 2000 09:44:00 -0700 (PDT) Date: Tue, 30 May 2000 09:44:00 -0700 (PDT) From: Kireeti Kompella Message-Id: <200005301644.JAA17897@kummer.juniper.net> To: dwilder@baynetworks.com, EGray@zaffire.com, Shahram_Davari@pmc-sierra.com, swtan@mmu.edu.my Subject: RE: can egress know the ingress of a packet? Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Perhaps we've gone off on an tangent here. The question as I understood it is "when a *data* packet arrives at the egress, can we know which ingress and which LSP it travelled on?" -- and the answer is, not without some extracurricular work. Tan, can you clarify your question? [I posted a reply to this earlier, but that seems to fallen into a blackhole.] Kireeti. > In CR-LDP, the LSP-ID TLV consists of an IP > address of the ingress LSR and a locally unique > identifier. Because it can be any address of the > ingress LSR, it does not have to be an address the > egress LSR will recognize (although it should be a > "legal" address - i.e. not private or unregistered). > > Therefore, I'm not sure how useful it is to > try to recapture information on the ingress LSR > using the LSP-ID TLV. > > -- > Eric Gray > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Tuesday, May 30, 2000 7:27 AM > > To: 'dwilder@baynetworks.com'; Tan Su Wei > > Cc: mpls@UU.NET > > Subject: RE: can egress know the ingress of a packet? > > > > > > Hi, > > > > I think in CR-LDP you may use LSP-ID TLV, which will give you > > the tunnel > > ingress and the LSP ID. And in RSVP-TE you may use the Sender Template > > Object, which will give you the same information. RRO may > > also be used in > > RSVP-TE, however you only will get the ingress LSR > > information that you > > need, but not which LSP it is coming from. > > > > Regards, > > -Shahram > > > > >-----Original Message----- > > >From: dwilder@baynetworks.com [mailto:dwilder@baynetworks.com] > > >Sent: Tuesday, May 30, 2000 10:01 AM > > >To: Tan Su Wei > > >Cc: mpls@UU.NET > > >Subject: Re: can egress know the ingress of a packet? > > > > > > > > >Can we use the Record route Object for this? > > > > > >Dave > > > > > >> Dear all, > > >> > > >> I'd a doubt on : > > >> In a mpls network domain, for a particular > > >ingress-egress pair > > >> with multiple LSPs in between them, is it possible when a > > >packet reach > > >> the engress node, the engress node will know the following: > > >> i. ) the ingress node > > >> ii.) the lsp it travel > > >> > > >> Thanks for any reply. > > >> > > >> Regards > > >> Tan Su Wei From owner-mpls@UU.NET Tue May 30 13:53: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 ESMTP id NAA05584 for ; Tue, 30 May 2000 13:53: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 QQirlf20842; Tue, 30 May 2000 17:50:44 GMT Received: by mail-control.mail.uu.net id QQirlf00078 for mpls-outgoing; Tue, 30 May 2000 17:50:08 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 QQirlf00063 for ; Tue, 30 May 2000 17:49: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 QQirlf08204 for ; Tue, 30 May 2000 13:49:50 -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 QQirlf20079 for ; Tue, 30 May 2000 17:49:50 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by ertpg14e1.nortelnetworks.com; Tue, 30 May 2000 13:30:45 -0400 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8GTB77J; Tue, 30 May 2000 13:30:40 -0400 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LQHBKNWR; Tue, 30 May 2000 13:30:40 -0400 Message-ID: <3933F9AC.CC40DB5C@americasm01.nt.com> Date: Tue, 30 May 2000 13:26:04 -0400 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vikram Venkataraghavan CC: mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques References: <20000529020941.2037.qmail@web1306.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ATM switches that I know about use the "SVC Encoding" technique. (In this technique, the top label is carried in the VPI and VCI field of the ATM header). However, there are routers with ATM cards that use a fourth technique: send all packets over a single VC and use the top label stack entry to carry the label. - Philip Vikram Venkataraghavan wrote: > > In the MPLS Architecture document > (draft-ietf-mpls-arch-06), there are listed three > encoding techniques for MPLS labels to encoded > directly into the VPI/VCI fields in an ATM AAL5 > header. > 1. SVC Encoding > 2. SVP Encoding > 3. SVP Multipoint Encoding > > The document also points out that there is no > interoperability mechanism between ATM LSRs that use > different kinds of encoding. > > Please tell me which kind of encoding is prefered in > the industry and why? (concerning the design of ATM > LSRs) > > Thanks in advance, > Vikram Venkataraghavan > NEC America From owner-mpls@UU.NET Tue May 30 15:05: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 PAA07433 for ; Tue, 30 May 2000 15:05: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 QQirlk27229; Tue, 30 May 2000 19:05:50 GMT Received: by mail-control.mail.uu.net id QQirlk22611 for mpls-outgoing; Tue, 30 May 2000 19:05: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 QQirlk22597 for ; Tue, 30 May 2000 19:04:59 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 QQirlk22252 for ; Tue, 30 May 2000 15:02:30 -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 QQirlk22279 for ; Tue, 30 May 2000 19:00:00 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11279 for ; Tue, 30 May 2000 14:55:23 -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 OAA16090 for ; Tue, 30 May 2000 14:55:21 -0400 (EDT) Message-ID: <39340EBA.EEA6A765@marconi.com> Date: Tue, 30 May 2000 14:55:54 -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: ATM Switches as LSR encoding techniques References: <20000529020941.2037.qmail@web1306.mail.yahoo.com> <3933F9AC.CC40DB5C@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Philip Matthews wrote: > > However, there are routers with ATM cards that use a fourth technique: > send all packets over a single VC and use the top label stack entry to > carry the label. AFAIK, this is not a legal technique. The only router I know that does this is only doing so because it doesn't actually claim support MPLS on ATM interfaces. What you're seeing is simply a side effect of running MPLS on an unsupported interface - when you do so, it takes POS- formatted data and blindly shoves it out a VC, just like it does for control traffic. (Note that this technique is not mentioned in the draft-ietf-mpls-arch-06.txt spec.) Even if would be legal, this fourth technique will not be very efficient on many hardware platforms. ATM backplanes are usually optimized for forwarding cells based on VP/VC numbers. They are not deisgned to run efficiently in a situation where they must reassemble (from the cells) each and every packet prior to making a forwarding decision. See also draft-ietf-mpls-atm-03.txt. -- David From owner-mpls@UU.NET Tue May 30 15:35:33 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 PAA08496 for ; Tue, 30 May 2000 15:35: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 QQirlm21136; Tue, 30 May 2000 19:35:33 GMT Received: by mail-control.mail.uu.net id QQirlm25055 for mpls-outgoing; Tue, 30 May 2000 19:34: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 QQirlm25022 for ; Tue, 30 May 2000 19:34: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 QQirlm28742 for ; Tue, 30 May 2000 15:34:28 -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 QQirlm20297 for ; Tue, 30 May 2000 19:34:27 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA12240 for mpls@uu.net; Tue, 30 May 2000 15:34:26 -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 QQirlm24991 for ; Tue, 30 May 2000 19:33: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 QQirlm13539 for ; Tue, 30 May 2000 15:33:39 -0400 (EDT) Received: from uniwest1.redstonecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.105.223.130]) id QQirlm21821 for ; Tue, 30 May 2000 19:33:39 GMT Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 15:36:58 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C59F61C@uniwest1.redstonecom.com> From: "Deshpande, Prasad" To: "'mpls@uu.net'" Date: Tue, 30 May 2000 15:36:57 -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 auth f18b04c4 subscribe mpls \ PDeshpande@unispheresolutions.com From owner-mpls@UU.NET Tue May 30 16:58: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 QAA10297 for ; Tue, 30 May 2000 16:58: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 QQirlr17088; Tue, 30 May 2000 20:58:11 GMT Received: by mail-control.mail.uu.net id QQirlr29245 for mpls-outgoing; Tue, 30 May 2000 20:57: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 QQirlr29239 for ; Tue, 30 May 2000 20:57: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 QQirlr14898 for ; Tue, 30 May 2000 16:57:29 -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 QQirlr16427 for ; Tue, 30 May 2000 20:57:29 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 NAA26055; Tue, 30 May 2000 13:57:35 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA18651; Tue, 30 May 2000 16:57:27 -0400 (EDT) Message-Id: <200005302057.QAA18651@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques In-reply-to: Your message of Tue, 30 May 2000 14:55:54 -0400. <39340EBA.EEA6A765@marconi.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: Tue, 30 May 2000 16:57:27 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Please note that routers with ATM cards are not ATM switches. Therefore, routers with ATM cards would not be expected to use the encodings defined for ATM switches. If two routers are connected to each other via an ATM VC, then of course they use the generic MPLS encapsulation when sending labeled packets over that VC, NOT the ATM-specific MPLS encapsulation. From owner-mpls@UU.NET Tue May 30 17:39: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 RAA11094 for ; Tue, 30 May 2000 17:39: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 QQirlu14778; Tue, 30 May 2000 21:39:43 GMT Received: by mail-control.mail.uu.net id QQirlu01751 for mpls-outgoing; Tue, 30 May 2000 21:39:12 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 QQirlu01744 for ; Tue, 30 May 2000 21:39: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 QQirlu06808 for ; Tue, 30 May 2000 17:38:51 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQirlu13886 for ; Tue, 30 May 2000 21:38:51 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id RAA27707; Tue, 30 May 2000 17:38:46 -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 RAA04307; Tue, 30 May 2000 17:38:40 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200005302138.RAA04307@curtis-lt.avici.com> To: "Loa Andersson" cc: Sean Doran , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS Performance analysis..... In-reply-to: Your message of "Mon, 29 May 2000 23:14:57 +0200." <3932DDD1.805FDAA7@nortelnetworks.com> Date: Tue, 30 May 2000 17:38:40 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3932DDD1.805FDAA7@nortelnetworks.com>, "Loa Andersson" writes: > > > Sean Doran wrote: > > > > Several people write: > > > > > [lots of commentary about how wonderful MPLS is at making forwarding fast] > > > So comments are basically wrong, HW forwarding on IP header is exactly > as fast as Label based forwarding- wired speed! > > BTW - who were the people that made those comments? Loa, I was one of those people. Doing the IP destination lookup is no longer a limiting factor for modern routers. Curtis From owner-mpls@UU.NET Tue May 30 18:47: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 ESMTP id SAA12334 for ; Tue, 30 May 2000 18:47: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 QQirlz25200; Tue, 30 May 2000 22:47:24 GMT Received: by mail-control.mail.uu.net id QQirlz14940 for mpls-outgoing; Tue, 30 May 2000 22:47: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 QQirlz14935 for ; Tue, 30 May 2000 22:46:59 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 QQirlz03174 for ; Tue, 30 May 2000 18:46:45 -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 QQirlz24711 for ; Tue, 30 May 2000 22:46:45 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 SAA00701 for ; Tue, 30 May 2000 18:46:42 -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 SAA03310 for ; Tue, 30 May 2000 18:46:42 -0400 (EDT) Message-ID: <393444F5.F0150C97@marconi.com> Date: Tue, 30 May 2000 18:47:17 -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: ATM Switches as LSR encoding techniques References: <200005302057.QAA18651@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 Eric Rosen wrote: > > Please note that routers with ATM cards are not ATM switches. > Therefore, routers with ATM cards would not be expected to use the > encodings defined for ATM switches. If two routers are connected to > each other via an ATM VC, then of course they use the generic MPLS > encapsulation when sending labeled packets over that VC, NOT the > ATM-specific MPLS encapsulation. Which deliberately makes the interface incompatible with an ATM switch running MPLS code. Why in the world would you want to use an ATM interface if it is incompatible with ATM switches? OK, so you can tunnel your LSP through an ATM VC. But why would you want to? If you've got ATM, use it. One of the big points about using MPLS is to have one unified control plane - if you're going to run MPLS through an ATM network that doesn't participat in MPLS, then you've just put back the layer you were trying to get rid of. Plus you've now added the overhead of two redundant layers of encapsulation where only one is necessary. -- David From owner-mpls@UU.NET Tue May 30 18:51:36 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 SAA12402 for ; Tue, 30 May 2000 18:51: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 QQirlz01229; Tue, 30 May 2000 22:51:36 GMT Received: by mail-control.mail.uu.net id QQirlz15176 for mpls-outgoing; Tue, 30 May 2000 22:51: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 QQirlz15168 for ; Tue, 30 May 2000 22:51: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 QQirlz16932 for ; Tue, 30 May 2000 18:51:10 -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 QQirlz27775 for ; Tue, 30 May 2000 22:51:09 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 SAA01049 for ; Tue, 30 May 2000 18:51:07 -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 SAA04032 for ; Tue, 30 May 2000 18:51:08 -0400 (EDT) Message-ID: <393445FE.BD4D9876@marconi.com> Date: Tue, 30 May 2000 18:51:42 -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: MPLS Performance analysis..... References: <200005302138.RAA04307@curtis-lt.avici.com> 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: > > I was one of those people. Doing the IP destination lookup is no > longer a limiting factor for modern routers. Depends on the speed. If you up the number and type of interfaces so that your fabric has to forward billions or trillions of packets per second, you will once again find differences in how the two forwarding engines (IP destination vs. label) perform. Regardless of how fast the chips run, an IP best-match lookup is an inherently more complicated operation than the integer-matching lookup required by something that forwards based on label (or VC or DLC). -- David From owner-mpls@UU.NET Tue May 30 19:22: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 ESMTP id TAA12846 for ; Tue, 30 May 2000 19:22: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 QQirmb15957; Tue, 30 May 2000 23:22:32 GMT Received: by mail-control.mail.uu.net id QQirmb25859 for mpls-outgoing; Tue, 30 May 2000 23:22:18 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 QQirmb25853 for ; Tue, 30 May 2000 23:22: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 QQirmb21336 for ; Tue, 30 May 2000 19:22:01 -0400 (EDT) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQirmb18625 for ; Tue, 30 May 2000 23:22:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue May 30 19:21:42 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA05642; Tue, 30 May 2000 19:21:27 -0400 (EDT) Message-ID: <39344DC2.5B3FC88D@dnrc.bell-labs.com> Date: Tue, 30 May 2000 16:24:50 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: MPLS Performance analysis..... References: <200005302138.RAA04307@curtis-lt.avici.com> <393445FE.BD4D9876@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David Charlap wrote: [..] > Regardless of how fast the chips run, an IP best-match lookup is an > inherently more complicated operation than the integer-matching lookup > required by something that forwards based on label (or VC or DLC). And regardless how much faster your label lookup is, if both approaches can fill the pipes one is interested in the issue is moot. Which I thought we'd already concluded. cheers, gja From owner-mpls@UU.NET Tue May 30 19:28: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 TAA12957 for ; Tue, 30 May 2000 19:28: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 QQirmb19955; Tue, 30 May 2000 23:28:59 GMT Received: by mail-control.mail.uu.net id QQirmb26195 for mpls-outgoing; Tue, 30 May 2000 23:28: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 QQirmb26190 for ; Tue, 30 May 2000 23:28: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 QQirmb21868 for ; Tue, 30 May 2000 19:28: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 QQirmb21959 for ; Tue, 30 May 2000 23:28:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA12064 for mpls@uu.net; Tue, 30 May 2000 19:28:25 -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 QQirmb26177 for ; Tue, 30 May 2000 23:27:54 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 QQirmb21780 for ; Tue, 30 May 2000 19:27:37 -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 QQirmb18909 for ; Tue, 30 May 2000 23:27:36 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 QAA23007; Tue, 30 May 2000 16:27:43 -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 QAA08237; Tue, 30 May 2000 16:27:46 -0700 (PDT) Message-ID: <39344F4D.B76288A6@cisco.com> Date: Tue, 30 May 2000 16:31:25 -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: David Charlap CC: mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques References: <200005302057.QAA18651@erosen-sun.cisco.com> <393444F5.F0150C97@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, > want to? If you've got ATM, use it. One of the big points about using > MPLS is to have one unified control plane - if you're going to run MPLS > through an ATM network that doesn't participat in MPLS, then you've just I am talking daily to all major ISPs worldwide deploying MPLS and nobody mentioned "unified control plane" as the reason to introduce MPLS into their network. The major reason is to be able to use applications which MPLS offers (Traffic Eng, MPLS-VPNs, Circuit Transport, Hierarchical Routing etc ...) And if you are stuck with ATM switches which don't support MPLS your only option is to use generic MPLS encaplsulation over PVC to pass the data through. Robert. > David Charlap wrote: > > Eric Rosen wrote: > > > > Please note that routers with ATM cards are not ATM switches. > > Therefore, routers with ATM cards would not be expected to use the > > encodings defined for ATM switches. If two routers are connected to > > each other via an ATM VC, then of course they use the generic MPLS > > encapsulation when sending labeled packets over that VC, NOT the > > ATM-specific MPLS encapsulation. > > Which deliberately makes the interface incompatible with an ATM switch > running MPLS code. > > Why in the world would you want to use an ATM interface if it is > incompatible with ATM switches? > > OK, so you can tunnel your LSP through an ATM VC. But why would you > want to? If you've got ATM, use it. One of the big points about using > MPLS is to have one unified control plane - if you're going to run MPLS > through an ATM network that doesn't participat in MPLS, then you've just > put back the layer you were trying to get rid of. Plus you've now added > the overhead of two redundant layers of encapsulation where only one is > necessary. > > -- David From owner-mpls@UU.NET Tue May 30 19:54: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 TAA13280 for ; Tue, 30 May 2000 19:54: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 QQirmd06754; Tue, 30 May 2000 23:54:32 GMT Received: by mail-control.mail.uu.net id QQirmd27685 for mpls-outgoing; Tue, 30 May 2000 23:53:58 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 QQirmd27680 for ; Tue, 30 May 2000 23:53:55 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 QQirmd24625 for ; Tue, 30 May 2000 19:53:50 -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 QQirmd03979 for ; Tue, 30 May 2000 23:53:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA14374 for mpls@uu.net; Tue, 30 May 2000 19:53:48 -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 QQirmd27667 for ; Tue, 30 May 2000 23:53:00 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 QQirmd24571 for ; Tue, 30 May 2000 19:52:41 -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 QQirmd03464 for ; Tue, 30 May 2000 23:52:40 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 16:51:48 -0700 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Subject: MPLS meeting minutes from Adelaide Date: Tue, 30 May 2000 16:51:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFCA92.04E47902" 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_01BFCA92.04E47902 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCA92.04E47902" ------_=_NextPart_001_01BFCA92.04E47902 Content-Type: text/plain; charset="iso-8859-1" Here are the draft meeting minutes from Adelaide. Apologies for the tardiness in getting these out; this was due to a combination of the travel plans of the chairs and our minute-taker, Tony Bogovic. Thanks to Tony for transcribing minutes. - Vijay ------_=_NextPart_001_01BFCA92.04E47902 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS meeting minutes from Adelaide

Here are the draft meeting minutes from = Adelaide.  Apologies for the tardiness in getting these out; this = was due to a combination of the travel plans of the chairs and our = minute-taker, Tony Bogovic.   Thanks to Tony for transcribing = minutes.

- Vijay

  ------_=_NextPart_001_01BFCA92.04E47902-- ------_=_NextPart_000_01BFCA92.04E47902 Content-Type: text/plain; name="minutes-mpls-adelaide.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="minutes-mpls-adelaide.txt" Content-Transfer-Encoding: quoted-printable Two MPLS WG sessions were held during the 47th IETF meeting in = Adelaide, Australia. The first session was held on Monday, March 27, = 2000 from 7:30pm until 10:00pm. The second session was held Wednesday, = March 29th from 9:00am through 11:00am. Vijay Srinivasan and George = Swallow chaired both sessions of the MPLS WG. The agenda for the first MPLS WG session appears as follows: Presenter Internet Draft Talk Duration Kompella draft-kompella-mpls-optical-00.txt 13 Lang draft-lang-mpls-rsvp-oxc-00.txt 13 Saha draft-saha-rsvp-optical-signaling-00.txt 13 Ashwood-Smith draft-fan-mpls-lambda-signaling-00.txt 13 Rajagopalan draft-tang-crldp-optical-00.txt 13 Bernstein draft-bernstein-mpls-sonet-00.txt 13 Mannie draft-mannie-mpls-sdh-control-00.txt 13 Kompella draft-kompella-mpls-bundle-00.txt 13 Lang draft-lang-mpls-lmp-00.txt 13 Swallow Discussion on organizing optical work 15 Ravikanth draft-vaananen-mpls-svc-diff-framework-00.txt 13 The agenda for the second MPLS WG session follows: Presenter Internet Draft Talk Duration=20 Davari draft-ietf-mpls-diff-ext-05.txt 13 Makam draft-makam-mpls-recovery-frmwrk-00.txt 13 Huang draft-chang-mpls-path-protection-00.txt 13 Matthews draft-farrel-mpls-ldp-ft-00.txt 10 draft-matthews-mpls-ldp-ibb-00.txt Kankkunen draft-kankkunen-vompls-fw-00.txt 2 Berger draft-berger-mpls-hdr-comp-00.txt 13 Swallow draft-swallow-mpls-simple-hdr-compress-00.txt 13 Heinanen draft-heinanen-mpls-splsp-00.txt 13 Iwata draft-fujita-mpls-crldp-crankback-00.txt 13 Wright draft-wright-policy-mpls-00.txt 13 Schrijvp draft-schrijvp-mpls-ldp-end-to-end-auth-00.txt 13 Sumimoto draft-sumimoto-mpls-vpn-interworking-00.txt 13 Srinivasan Last calls, charter discussion 8 The following captures the minutes of all the agenda items listed above = (in the same order): ----- 'Extensions to IS-IS/OSPF and RSVP in support of MPL(ambda)S', = , Kireeti Kompella Kireeti Kompella started off his presentation by discussing network = design considerations, but mentioned that the focus of the talk was on = forwarding adjacencies. He then listed a number of network design considerations. In = particular, he pointed out that network design, policy boundaries, and = administrative domains are all the customer's choice. Moreover, he = mentioned that the network model employed could be the overlay or = peer-to-peer models as well as a range of other models. Additional = network design considerations he discussed include: reliance on open = standards, multi-vendor network, training, MIBs, monitoring, = management, control, and simplified, unified tools.=20 He followed by listing a number of characteristics that Service = Providers (SPs) would like to realize in their network. Namely, a = unified approach, common paradigms, control procedures, leverage = technology advances, capacity planning, forwarding adjacencies, shared = risk avoidance, link bundling, and fast restoration. Then he discussed switching granularities. In particular, he = enumerated different switching options, i.e., labels, lambdas, channels = or sub-channels. In doing so, he posed the question 'what to switch'? = He followed by indicating that it depends where in the network it is: = LSR, ADM, OXC, etc. He mentioned that the key point was that at any = point in the network, you switch only one thing. Subsequently, he spoke about the appropriateness of using RSVP for = MPLambdaS. The rationale was that LSPs were more demanding than = lambda-switched paths, since LSPs are shorter lived than lambda = switched paths. The point being that if RSVP can handle LSPs, then it = can handle lambda switched paths. And, he said that the existence = proof was that MPLS/RSVP is already deployed in large networks. He went on to discuss forwarding adjacencies, which were a key part of = this draft. He described them as control driven and an LSP advertised = as a link in IS-IS or OSPF for the purpose of aggregating forwarding = state. In addition, he mentioned that they represented a new paradigm = that can be used for both MPLS LSPs or lambda switched paths. Further, he stated that the forwarding adjacencies represented a = paradigm for a hierarchical LSP structure in the following order: = packet switched LSPs, TCM-switched LSPs (SONET trails), lambda-switched = LSPs (Optical trails), fiber-switched LSPs. He also mentioned state = reduction, fate sharing, that it was useful for 'regular' LSPs, and = that it integrates LSPs, SONET trails, optical trails and = fiber-switched paths. He also described the new Traffic Engineering TLVs that were defined. = Namely, link type (extends the notion of termination capable and termination = incapable), link media type (changed label across objects), shared risk = link group, label request object, and add link media type = (OXC/ADM-specific).=20 He concluded his presentation by discussing the next steps for this = work. In addition to proposing to make this draft a MPLS WG document, = he said that he would incorporate comments from the mailing list and = produce version 01 of the draft. Also, he questioned whether this = draft should be divided into two.=20 During the question/answer period, Don Fedyk asked about the = constraints for a forwarding adjacency and mentioned that the = constraints are wide. To which, Kireeti Kompella replied that LSPs have = constraints, not forwarding adjacencies. They decided to take this = discussion off-line. Incidentally, questions on status of the draft were deferred towards = the end of the session, where the organization of the optical work was = discussed. ---- 'Extension to RSVP for Optical Networking', = , Jonathan Lang=20 Jonathan Lang began his presentation by highlighting a number of = optical networking requirements, including small trail establishment = latency, rapid failure detection/notification, rapid/intelligent trail = restoration, support for bi-directional trails, etc. =20 Then he covered the proposed extensions to RSVP for optical networking. = The first was the Label Suggestion Object. He stated that it reduces = trail establishment latency. This, he mentioned, was accomplished by = the upstream OXC suggesting a label to the downstream OXC, yet the = downstream OXC can ignore the label suggestion. The second extension = included Bi-directional Trail Establishment. He pointed out that it = reduces trail establishment latency and increases success probability. = He went on to say that when both of the above objects are used together = Label Contention Resolution is possible. He then proposed another extension, which is the Failure Notification = object. This extension impacts the restoration requirement. = Specifically, the need to react to network failures rapidly; = responsible nodes must be notified quickly and restoration decisions = made intelligently. Finally, he mentioned that a modification to the Bundle Message was = proposed in the draft. There were no questions. ---- 'RSVP Extensions for Signaling Optical Paths', = , Debanjan Saha Debanjan Saha started off by stating that the intent of this = contribution is to make RSVP more suitable for signaling light-paths. = Then he listed some requirements for light-paths, i.e., permanent, = bi-directional, protection and restoration light-paths. In this way, = extensions to RSVP can be proposed to satisfy these requirements. Then he mentioned that bi-directional light-paths are needed because = signaling twice is expensive. Also that SONET requires the forward and = backward paths to be on the same circuit pack and to avoid label = assignment collision. To accommodate bi-directional light-paths, he = proposed a new C-Type for the Label Request Object and a new C_Type for = the Label object. Further, he mentioned that protection and restoration are more complex. = He continued by indicating that new objects were needed for signaling = span protection mode. Moreover, he stated that two approaches could be = taken for path protection. Namely, the first approach is 1+1 style = dedicated backup paths, while the second is shared backup paths. = Moreover, he asserted that simple extensions could make that happen, = i.e., a new C_Type for the Session Attribute object. He concluded by summarizing his presentation. He mentioned that 3 RSVP = extensions were proposed to address specific requirements for signaling = light- paths - new C_Types for the Label Request and Label objects and = a new C_Type for the Session Attribute object. During q/a, George Swallow asked how do you know you can share the = bandwidth? To which, Debanjan responded that that could be achieved = with, e.g., a resource class in OSPF. ----- 'Extensions to CR-LDP and RSVP-TE for Optical Path Set-up', = , Peter Ashwood-Smith=20 This draft specifies extensions to RSVP-TE and CR-LDP for optical LSP = set-up. Peter Ashwood-Smith touched on some mechanisms, TLVs, and = objects that are required to support optical LSP setup.=20 At one point, he mentioned that the draft coined the term Composite = Labels. They allow the signaling protocol to set-up entire = fiber/lambda and/or sub-lambda paths employing a single end-to-end = mapping/resv message. Also, he mentioned that a particular problem is that there exist cases = of optical cross-connect that cannot do wavelength/waveband conversion. = Peter stated that a number of solutions exist, one of which includes = carrying a Label set of acceptable wavelengths (labels) in request/path = messages. Then he wrapped up his presentation by stating that goal one of the = draft was to specify a set of TLVs for RSVP-TE and CR-LDP for flat and = composite optical/time etc. labels. And, to make sure that is a = superset of all present and predicted future hardware. There were no questions. ---- 'Extensions to CR-LDP for Path Establishment in Optical Networks', = , Bala Rajagopalan Bala Rajagopalan kicked-off his presentation by mentioning that this = work does not take into account the interworking scenarios; that it is = solely based on the implementations Tellium wanted to perform. Then he identified the new extensions this draft specifies. They = include: signaling port ID, signaling optical switched path ID, = signaling both end-points of the path being established, path = attributes, and signaling requirements for both span and path = protection. Moreover, he identified some new TLVs such as Route_Record = (records the path being set up at port level); he mentioned that the = ingress node initiates this TLV. Finally, he discussed bi-directional = path setup, where two adjacent OXCs form a Master/salve relationship. There were no questions. --- 'Some Comments on the Use of MPLS Traffic Engineering for SONET/SDH = Path Establishment', , Greg = Bernstein Greg Bernstein began his presentation by stating that there is interest = in the use of an IP based control plane for a circuit switched = infrastructure. He then cited lambda switching, fiber switching, = SONET/SDH paths, and so forth. Moreover, he asserted that the contents = of the 'pipes' may or may not be IP traffic, in fact, it may or may not = be known. As a result, he said that different provisioning modes are = desired, i.e., end system initiated (w/o knowledge of network = topology), network management initiated (w/o end system, SPLSPs), and = the service layer as peer (e.g., IP router controls lower layer = connections). Subsequently, after motivating the topic of the draft, Greg spoke about = MPLS application decomposition. He broke it up into information needed = to compute paths, information that only needs to be known between = adjacent switches, information that all switches in the path need to = know, and information intended only for end systems of the path. Greg then went into a quick review of SONET signals. He stated that = they were all bi-directional. And, restricted in concatenation = variations, which include standard concatenation, arbitrary = concatenation, and virtual concatenation. Finally, he pointed out some additional considerations such as = connection bundling, the routing of multiple STS-1s along the same = route at the same time, degrees of transparency, STE, LTE, PLR, line = protection types, etc. There were no questions. ----- 'MPLS for SDH Control', , Eric = Mannie Eric Mannie began his presentation by asserting that a wavelength is = still expensive, thus, there is a need to multiplex separated pipes. = As a result, he continued, SDH/SONET will continue to be a huge market = in the medium-term. In addition, he mentioned that MPLS could be used to dynamically = control SDH paths. The idea being to employ the signaling plane of = MPLS + IP or ATM routing + SDH switching. Also, he stated that SDH = defines a multiplexing structure that can be controlled by MPLS to = switch. He then pointed out that the draft covers the following SDH = aspects: STM-N and lower order signal switching and virtual and = contiguous concatenation. Further, he discussed labels in this context. Namely, that a label = identifies a part of a SDH path not a frame and that there is one = multiplex table per interface. He also mentioned two feasible label = allocation approaches: 1) sequential label allocation, i.e., = independent of any SDH semantic, and 2) hierarchical label based on SDH = multiplex. Then he discussed the benefits of using multiplex entry = names as labels. That it identifies directly signal type and position = and allows easy debugging (does not need to know the matching to = debug). He also talked about multiplex entry notation and coding, and followed = that with examples of operations such as LSP tunneling could be used to = sub-structure a signal and could also establish an LSP inside an = existing LSP. An example he provided was that of downstream on demand = allocation, where simple SDH CAC and periodic multiplex = checking/re-synchronization could be employed. In addition, he talked about routing and signaling for SDH. For = routing of SDH paths, he mentioned that the multiplex table at each I/F = must be known. He also discussed SDH signal concatenation of AU-4 and = TU-2 and interconnection of different signals such as VC-3, TUG-2, = VC-11. He mentioned the impact on the signaling protocol is that = source routing is required with a label list/range and that the = exchange of signaling and routing messages are over SDH. His conclusions were that SDH paths can be dynamically established and = released, and that MPLS provides a suitable signaling plane for SDH = control. He mentioned that the draft explains how and discusses issues. = He also said that the draft will be extended to cover SONET, SONET-SDG = conversion, sub STM-0 (if needed), CR-LDP and RSVP-TE extensions to = cover SDH signaling, and OSPF and IS-IS extensions to cover SDH = routing. No questions were asked of the speaker. ---- 'Link Bundling in MPLS Traffic Engineering', = , Kireeti Kompella Kireeti began by describing the concept of link bundling. That is, a = pair of LSRs may be connected by multiple, parallel links, and from a = MPLS traffic engineering perspective for the expressed purpose of = scalability, treating all these links as a single link may be = desirable. He pointed out two link bundling alternatives: 1) finer granularity is = achieved when each link in the bundle is numbered. Alternatively, 2) = by advertising a single link, coarser traffic engineering results with = less IGP information needed, thus, fewer IP addresses are required; the = trade-off being the loss of information for each individual link.=20 Then he introduced TLVs for link bundling including: maximum LSP = bandwidth, maximum bandwidth available to an LSP at a given priority = level, maximum bandwidth of component links, maximum of {link = bandwidth, unreserved bandwidth} over all component links, etc. Further, he specified the procedures needed to accomplish this. That = is, RSVP must track unreserved bandwidth at each priority for each = component link and report maximum LSP bandwidth to the IGP; IS-IS/OSPF = will advertise summary information, and CSPF for an LSP with bandwidth = b and setup priority p (ignoring all links whose max LSP bandwidth at p = is less than b). He also enumerated the applicability of link bundling to multiple = parallel TE links, multiple lambdas in a fiber, multiple channels in a = TDM link, etc. He concluded by pointing out the next steps for this draft and making a = proposal. He said that the draft would be updated by including = clarifications and a usage example. Then he proposed to make it a MPLS = working group document. In the q/a period, Don Fedyk said that he likes the idea of link = bundling, but then he inquired about why the floating point numbers = increased from 8 to 16; he believes it should remain at 8. Kireeti = responded by indicating that due to capacity planning, 16 floating = point numbers are required. --- 'Link Management Protocol (LMP)', , = Jonathan Lang Jonathan Lang said that this draft describes a new protocol that is = being proposed for link provisioning and fault isolation. He started out by specifying the need for link management. Then he = cited a few examples illustrative of the diversity of OXCs configured = with IP links. In particular, he pointed to two: 1) a single = bi-directional control channel spanning OXCs, and 2) a number of = unidirectional user bearer channels. He then covered the four main functions LMP comprises. The first was = control channel management. He stated that a bi-directional control = channel is required per IP link. He also mentioned a number of other = characteristics: that the backup control channels are pre-configured, = control channel implementation is unrestricted, and use of a Hello = protocol. He described in more detail the Hello protocol. = Specifically, a unicast Hello message is periodically transmitted, = contains sender's Hello interval, contains sequences numbers = (SendSeqNum, RecSeqNum), and it detects a node reboot. The second function was link connectivity verification. He stated that = the requirements include the user bearer channels are opaque until = allocated and messages are sent/received over any bearer channel. For = verification, initial configuration and periodic validation of free = bearer channels and (fiber, lambda) Label exchange. Then he described = how to initiate link connectivity verification. That is, BeginVerify = initiates process (c), BeginVerifyAck signals start of Test procedure = (c), Test procedure (3-way handshake, and EndVerify terminates process. The third feature of LMP is a LabelSummary exchange. He stated that it = synchronizes label matching and correlates link properties, and = exchanges when labels or link properties are changed, and so forth. Finally, he concluded his presentation by describing fault localization = - the fourth function of LMP. He mentioned that it isolates link and = channel failures and initiates protection/restoration mechanisms. During q/a, Peter Ashwood-Smith asked if monitoring an individual = wavelength itself disturbs it in any way? Jonathan Lang answered = affirmatively that that is the tradeoff between power and of knowing = the health of your channels and bearer channels. ----- Discussion on MPLS extensions in support of Optical Networks, George = Swallow Rob Coltun, the Routing Area Director, mentioned that all the = contributions thus far are outside the charter of the MPLS WG. He went = on to say that no actions could be taken at this point with respect to = the above drafts. He proceeded with a clarification that, not that the = drafts are not appropriate for the MPLS WG, but that they are outside = of the WG's charter. Also, he stated that a good portion of drafts are = applicable to MPLS, in fact, that optimize MPLS. George Swallow suggested that the charter reflect this work, and once = that is accomplished, the charter will be sent to IESG for approval. He = also stated that getting the optical work going is very orthogonal to = the LDP, CR-LDP, and RSVP-TE Internet Drafts. Rob Coltun also mentioned that what contributions fall into what = particular WGs besides the MPLS WG, such as the IPO WG, is yet another = consideration.=20 Someone else raised the point that an interim step would be if the = co-authors would combine their drafts as well as to get issues = discussed on the MPLS WG mailing list. That these steps would be = unofficial until the IESG approves the new MPLS direction. Bilel = Jamoussi added that he agrees that the co-authors should get together = and try to combine the contributions. Subsequently, George Swallow made the suggestion that before the next = MPLS WG session at this IETF meeting, the co-authors of the above = drafts should get together and discuss how their work can be combined. = He believes that a small number of conflicts exist.=20 ---- A Framework for Service Differentiation in MPLS Networks, = , Muckai Girish=20 Muckai Girish initially covered the contributions of this draft. He = mentioned that it creates a framework for service differentiation, = discusses a set of services, identifies traffic management element = functions in various network elements, and so forth.=20 Then he went on to describe the framework for services in more detail. = In particular, he mentioned that the framework is described by two = components: the traffic contract and the service objectives. He = asserted that one can create a lot of services based on these = components such as best effort service, bounded loss service, enhanced = best effort service, etc. In discussing how the services are implemented, he mentioned that = control and data plane mechanisms are required. For example, control = plane mechanisms include triggers and policy and admission control, = while data plane mechanisms can comprise of a label-forwarding = paradigm. He then identified particular network elements/devices such as hosts, = MPLS edge nodes, CPE routers, MPLS core routers, etc. Having done = that, Muckai specified the mandatory functions in Service Provider = border routers, which included admission policy, admission control, = direct and indirect mapping, policing/marking, shaping, aggregation, = queue management, scheduling, and classification policy. He concluded his talk by focussing on the future actions related to = this work. He suggested that this draft be a MPLS WG document if the WG = believes that it is useful. Also, he wanted to solicit comments and = input and contributions from others to improve and extend the draft. = Ultimately, his aim was to have this document eventually published as = an informational RFC. Consequently, George Swallow then said that this work is outside the = charter of the MPLS WG. --- 'MPLS Support of Differentiated Services', = , Shahram Davari Shahram Davari began his presentation by providing a history of how = this work developed. He noted that the current draft had gone through = five instantiations, where each version benefited from comments made by = the working group. He then proceeded to describe two models for DS Behavior. Namely, the = first is the uniform model, where a tunnel's ingress PHB is the same as = the packet's PHB; he mentioned that this model is the default and it is = useful when transiting the same administrative domain. The second is = the tunnel model, where a tunnel's PHB may be different from a packet's = PHB. Moreover, the packet's PHB is preserved and restored. Subsequently, Shahram discussed the E-LSPs, configured and signaled, = that are defined in the draft. On the one hand, in the configured = E-LSP, the PHB <=3D> EXP mapping is configured in each LSR. On the = other hand, for the signaled E-LSP, the PHB <=3D> EXP mapping is = signaled for all BAs support. He also mentioned that support for = signaled E0-LSP is optional, and that a new DiffServ object for = Signaled E-LSP was defined. Shahram also remarked that support was added for LAN/802.1 in the = draft, of which 3 scenarios exist. That is, 1) LAN/802.1 switches = between two LSRs; 2) LAN/802.1 interface between two LSRs, where no = LAN/802.1 switches are present, and 3) MPLS enabled LAN switches, which = he stated is not currently defined in the IETF and therefore is not = considered in this draft. Further, he disclosed that some new Error Status Codes (e.g., Error = Type and Unsupport PHB) were introduced in the draft. And, that the = per-LSP bandwidth signaling was clarified in the draft, particularly = noting the purposes of bandwidth signaling; i.e., DiffServ LSP = admission control, adjusting DiffServ provisioned resources (e.g. PSC = scheduling weight), no per-LSP or per-flow scheduling is required, and = E-LSP BW refers to all transported PSCs. Shahram wrapped up his presentation by indicating that all the open = issues of the second version of the draft were resolved, and all the = comments on v03 and 04 were incorporated (i.e., bandwidth signaling and = push/pop behavior), except one request to add an extension for = signaling per PHB/per-PSC bandwidth at E-LSP setup. He also mentioned = that the next step would be to release version 05 of the draft in the = next 1-2 weeks. During the Q/A, Lou Berger thought that extra wording was needed in the = draft that discusses the compatibility issues between nodes that are = DiffServ and non-DiffServ enabled. Shahram agreed to look it over.=20 ---- 'Framework for MPLS-based Recovery', = , Vas Makam Vas Makam initially covered the purpose and contribution of this draft. = He stated that the purpose was to form a consensus on terminology, = requirements, and recovery models. Then he went on to discuss the MPLS = protection objectives; some of which include: facilitate fast recovery = of working traffic; maximize network reliability and availability; = allow protection of traffic at various granularities, and maintain = switching actions in separate MPLS protection domains independent of = each other. Subsequently, he went over new terminology that was added to draft, = such as Path Switch LSR (PSL), Path Merge LSR (PML), Working Path, = Recovery Path, and Protection Domain. Having gone through some = terminology, he then covered MPLS recovery requirements, which include = mechanisms to configure recovery (enable or not enabled) and perform = recovery at PSL and PML upon failure detection or the receipt of FIS, = etc. Moreover, Vas also cited some comparison criteria that can be = employed such as recovery time, full restoration time, and backup = capacity. Vas concluded by citing some expected updates to the drafts and next = steps for this work. The coming updates include: cover switch-"back" = to loosely explicit routed paths, add requirements on alarm = correlation, add to the objectives that the protection algorithm should = be scalable, and add a note that not every alternative mentioned is = implemented. As for next steps, Vas mentioned that after feedback from = the MPLS WG and the corresponding mailing list, any issues would be = clarified and resolved. He then proposed to move this draft to a MPLS = WG document. Consequently, George Swallow said that that suggestion = would be put on the MPLS WG mailing list. George also mentioned that = the 1+1 case requires 2 variants.=20 Also, Vijay Srinivasan indicated that this work was also inserted in = the MPLS WG charter but was not yet approved. George Swallow remarked = that the work on protection switching was implicit to the traffic = engineering text already in the charter so no new words were required = to cover this work. =20 --- 'A Path Protection/Restoration Mechanism for MPLS Networks', = , Changcheng Huang Changcheng Huang started his presentation by stating the purpose of = this work. Namely, the purpose is to propose a path protection = mechanism for MPLS that is fast, scalable, bandwidth efficient, and = allows for path merging. He also outlined the key features of this = proposal, i.e., Liveness Message, Reverse Notification Tree, = Lightweight Notification, and to minimize delay. Subsequently, he = described two configurations in more detail: 1) Reverse Notification = Tree (RNT), and 2) the hop-by-hop approach. He then spoke about further issues being explored vis-=E0-vis this = work. In particular, enhancing scalability by aggregating information = about faults and investigating tunneling or nesting approaches in = relation to 'legacy' LSRs. Moreover, handling multiple faults was = another item, i.e., he expressed a need to identify all scenarios, and = for each scenario, to indicate which approach (if any) will work. He wrapped-up his presentation by focussing on the next steps for this = work. They include soliciting feedback from the MPLS WG mailing list = and then moving to a MPLS WG document, to consider extensions to RSVP = and LDP/CR-LDP to facilitate implementation, and to consider how this = work may apply to the optical case. Afterwards, George Swallow mentioned that there has not been much = feedback from the MPLS WG mailing list concerning this work, and he = believes that before it becomes a MPLS WG document, more discussion on = the mailing list needs to take place. Also, Shahram Davari asked whether RNT is manually configured. = Changcheng's response was no, not necessarily, it can also be = configured through signaling extensions. ----- LDP Fault Tolerance, & = , Philip Matthews At the outset, Philip mentioned that both drafts, = & = , addressing LDP/CR-LDP fault = tolerance will be combined. Then went into a description of fault = tolerance. Subsequently, he put forward two applications that can make use of this = work. First, a hitless on-card software upgrade: the old stack can be = running, while upgrading the LDP and/or TCP stack on the card. Second, = an application that is intended to control redundancy, assuming a = router with separate control and data planes. For example, forwarding = is accomplished on the interface cards, while LDP signaling on the = control card; thereby, the backup control card can be ready to take = over immediately if the primary control card fails. However, he = pointed out some problems with this approach, i.e., because LDP runs on = TCP, it is very difficult to keep the TCP connection alive when doing = this switch. Further, he then stated how the two drafts were similar and how they = differed. Both drafts have a common framework that goes as follows: = allow the old TCP connection to die, continue to forward labeled = traffic, then establish new TCP connection and in LDP initialization = say 'continue old LDP session'. However, he pointed out that the two = drafts differ in their ACK scheme. He proceeded to discuss how each = draft ACK scheme works: on the one hand, = extends implicit acknowledgements = already present in the LDP protocol; in this way, neighbors know which = messages have been received and which have been lost. On the other = hand, carries an application-level = sequence number in the LDP Message ID and adds an ACT TLV to message, = etc. He also mentioned that both methods work and each approach have their = pros and cons. The disadvantage for = is that it forces one style of use = for the Message ID field, while is = less future-proof to protocol extensions. Also, he pointed out that a combined draft would use certain aspects of = one draft and other aspects of the other draft such as the explicit ACK = approach from would be used as = well as it would take the idea of FT and non-FT labels from = . Moreover, he mentioned that a new = sequence number TLV is being added in the combined draft. He said to = refer to messages being sent to the MPLS WG mailing list for more = details. Finally, he stated that their intent is to add an optional extension to = LDP, to produce a combined draft in time for the next IETF meeting in = Pittsburgh, and that they will ask that the combined draft become a = MPLS WG document at that meeting, aiming for a standards track RFC.=20 During the Q/A period, Rob Coltun asked the speaker to differentiate = between failure detection and a time-out. Due to time limitations, = they were asked to take this up on the mailing list. -- 'Voice over MPLS Framework', , Anti = Kankkunen At the outset, Anti Kankkunen mentioned that he was only allotted 2 = minutes to present the VoMPLS draft and that that was not enough time = to present any details concerning the draft. As a result, he pointed = out where to locate the draft, and he also wanted to convey the idea = behind VoMPLS. That is, the use of MPLS as an efficient transport of = VoIP services with predictable QoS/GoS in an IP / MPLS network, where = voice over MPLS is equivalent to VoIP over MPLS. --- 'MPLS/IP Header Compression', , Lou = Berger Lou Berger began by enumerating the objectives of the MPLS/IP header = compression draft. In particular, to enable header compression for MPLS = encapsulated traffic and to optimize for maximum compression. He = mentioned that end-to-end compression was not a requirement and that it = was targeted at 'lower speed' links, where lower speed was not = specified but was hardware-specific.=20 He mentioned that the key consideration was whether MPLS headers are = compressed. He went on to cover two options: 1) end-to-end with header = compression over MPLS, and 2) link-by-link with compression of MPLS/IP = headers. Subsequently, he discussed the pros and cons of each approach, = concluding that both are reasonable depending on the application. He then outlined the basic approach. That is, it begins with standard = IP header compression, then support for compression of MPLS packets is = added, where the first draft preserves the standard compression header = (2 bytes, 4 bytes when UDP checksums are used, and +1 byte per EXP = field change). He stated that it does not increase with more MPLS = headers. And, that the second draft, = , defines PPP link layer = support, which parallels RFC 2509 (IP header compression over PPP). He concluded by highlighting two issues. First, the bit naming = collision with draft-koren-avt-crtp-enhace-01.txt, and second, he = remarked that it was not clear which IETF working group this work = should proceed in.=20 --- 'Simple Header Compression', = , George Swallow=20 George Swallow enumerated the motivating factors that lead to this = work. Namely, that in VoIP, headers account for a significant portion = of the packet. And, for networks in which voice traffic dominates, = significant bandwidth savings can be achieved by compressing headers. = He then remarked that a trade-off between less bandwidth efficiency for = better processing efficiency exists. He went on to say that this could = be done from access point to access point, where allowing compression = on access links without requiring edge routers to perform header = compression. He also stated that the same techniques are being = employed in PacketCable.=20 Further, he described the actual compression technique, mentioning that = the technique operates without the need for re-synchronization, that = the MPLS label serves as the Context ID, and so forth. =20 George then proceeded to list some draft refinements. Namely, he noted = that 3 flags were used for MPLS TTL, inferring length from received = MTU, and for re-computing checksum. And, he also mentioned that the = SCID (Sub-context ID) had two purposes: 1) to allow multiplexing across = an LSP, and 2) to handle simple format variations in a packet stream. During the Q/A period, Shahram Davari asked how does this technique = handles label merging? George's response was that the setup was = accomplished via RSVP signaling, thus, merging is not permitted.=20 George Swallow then posed a question to Rob Coltun, who is the Area = Director of the Routing Area. He asked what should be done with the = draft he presented as well as Lou Berger's draft on the same subject. = Rob's initial response was to defer that decision until VoMPLS BOF. = Lou Berger then mentioned that the generic header compression schemes = are not MPLS specific, thus, he had a 'strong opinion' that this work = should reside in the IETF Generic WG. Rob then inquired about the = operational demand for this work. Finally, it was decided that this = work will be done in the MPLS WG and that it will be described in the = MPLS WG charter.=20 ---- 'Soft Permanent LSPs for CR-LDP', , = Juha Heinanen=20 Juha Heinanen began his presentation by stating that this idea is = similar to soft PVCs in FR and ATM networks. And, because MPLS does not = have such a capability, that this was an effort to introduce it. He then went on to define a Soft Permanent LSP (SPLSP). He mentioned = that it is a permanent LSP that originates or terminates at an = interface of an MPLS node. Moreover, that it is owned and = (re)established by the originating MPLS node, and that labels at = originating and terminating interfaces are determined by the = originator. He also gave a few SPLSP examples. Subsequently, he discussed the motivation of SPLSPs. He mentioned that = some of the scenarios where SPLSPs would be useful to employ include: = when an MPLS domain does not want to exchange MPLS control information = with another domain, an MPLS CPE does not implement an MPLS control = plane, or an MPLS domain wants to dynamically re-establish an LSP = without notifying its user. Juha then provided some particulars concerning the draft. He mentioned = that the draft discusses a SPLSP CR-LDP implementation, where setup is = achieved using a Label Request Message in which the Label TLV carries = the label requested at the terminating interface. And the terminating = interface is identified by an IP address carried in the last ER-HOP. = He also mentioned that the interface and label selection at the = originating node is a local matter. He concluded by stating that he strongly feels that supporting SPLSP = capability is needed one way or another. During q/a, someone commented about MPLS being uni-directional, but = most applications, he stated, use bi-directional flows. He went on to = ask if there was a way to get that reverse path setup. Juha mentioned = that he does not see a problem in accomplishing that. Also Rob Coltun mentioned that this would be an ideal talk for the = TEWG. Juha responded by stating that he does not believe in the merits = of traffic engineering, rather that he prescribes to shortest path = approaches. --- 'Crankback Routing Extensions for CR-LDP', = , Atsushi Iwata Atsushi Iwata began his presentation by asking the question why is = crankback required. He asserted that crankback routing is a powerful = technique for rerouting upon setup blocking. That it is useful for = end-to-end LSP restoration. And, that it requires notifying the = upstream LSR of the location of a blocked link or node. He then stated that the focus of his talk is specifying the extension = to CRLDP to support crankback routing. He noted that this could be = extended to RSVP-TE as well. =20 Subsequently, he pointed out some behaviors of the rerouting TLV. That = it is included in a notification message. And, in the LSP failure case, = upon an end-to-end restoration, the rerouting TLV is included in a = label withdraw message. He also mentioned that identifying blocked links or nodes is necessary. = For this, two kinds of identification are employed. One approach is a = protocol-independent identifier and the other is protocol dependent = identifier, both are specified in the draft.=20 He concluded his presentation by requesting that this draft covering a = crankback extension for CR-LDP be accepted as a MPLS WG document or to = merge it with for inclusion in the = crankback/restoration section. To this, George Swallow said that he = would prefer to hold off making this draft a MPLS WG document until = some of the other related work starts maturing, since specific TLVs = will probably change. --- 'Requirements for Policy Enabled MPLS', = , S. Wright S. Wright initially reviewed some aspects of Policy Based Networks = (PBNs). In particular, he stated that the policy and rap WGs developed = the PBN architecture. Moreover, the Policy Information Base (PIB) is = stored in the policy repository. And, the PIB is a higher level = abstraction than MID. He went on to point out that policy is also relevant to MPLS networks. = He mentioned that the rationale for such a combination included = consistency (e.g., align with DiffServ PIB work), integration, = controllability, flexibility and MPLS abstraction. He then cited a few policy examples related to MPLS. That is, LSP = admission policies and LSP life cycle policies, where a PBN example is = LSRs as PEPs. Also, he stated that it should be possible to policy = enable an MPLS network; the main implication being that PIB elements = correspond to MPLS concepts and MPLS MIB elements (e.g. LSPs). He concluded by saying that he wanted to bring this policy work to the = attention of the MPLS WG to gauge if this work was appropriate. The = consensus in the WG was that it is worth working on, thus, = contributions in this area related to MPLS should be brought to the = MPLS WG. Moreover, George Swallow stated that policy and MPLS are two = things that have very much in common and much to do with each other, so = it is worth working on. --- 'End to End Authentication for LDP', = , Peter Schrijvp, Yves = T'Joens The speaker mentioned that the objective of the draft was to describe = two procedures to authenticate. Namely, procedure 1 was = challenge-based, while procedure 2 was based on a Digital Certificate = and Digital Signature. Then, two questions were posed to the MPLS WG. That is, should this be = seen as framework today, to be technically detailed with various = methods, and does the MPLS WG want to take this work up? A discussion then ensued on this topic. First, George Swallow asked if = anyone in the MPLS WG sees any immediate need for this functionality. = Vijay Srinivasan then mentioned that someone else proposed = authentication capabilities of RSVP. George followed by stating that = RSVP authentication is not MPLS specific. This discussion was = postponed until the charter discussion is discussed towards the end of = this MPLS WG session. --- 'MPLS VPN Interworking', , = Junichi Sumimoto Junichi Sumimoto began his presentation by posing the question why VPN = interworking was necessary. He then proceeded to answer the question = by stating that a number of different MPLS VPN solutions have been = developed; this was due to lack of a standard specification for MPLS = VPNs. Thus, he concluded that a MPLS VPN interworking method that = enables a VPN service over MPLS networks is definitely required. He declared that the Interworking Model assumes an MPLS network to be = the base for providing VPN services. He went on to enumerate three = service assumptions that are provided by MPLS VPNs. Namely, 1) = security support, 2) QoS calls support, and 3) dynamic routing = information distribution. Moreover, he then listed the three = functional capabilities (FCs) (refer to draft) that are required at the = interworking interface to enable the interworking of the three = services. He also showed the implementation methods for the three FCs = and discussed how an extranet is constructed. =20 Junichi concluded his presentation by asserting that a MPLS VPN = interworking method to enable a VPN over MPLS is definitely needed. = Moreover, that the presentation focused on a static interworking = solution for the purposes of a faster deployment cycle, and dynamic = interworking will be discussed in the future. During the q/a period, Bilel Jamoussi mentioned that VPN work is = outside the charter of the MPLS WG. This led Rob Coltun to add that = starting a MPLS VPN effort to document the few methods being = implemented in the market would be worthwhile to do. In addition, he = stated that that effort would not have the charter to select a = particular method. Marco Carugi also mentioned that realizing interoperability among = various MPLS VPN approaches is very important to France Telecom. He = went on to say that ITU SG13 Q20 is studying this very issue. In fact, = he mentioned that they are convening a meeting in Paris from May 29 = through June 2, 2000 to discuss this very topic. Also, he said that = IETF representation in the ITU on this matter would be very helpful = indeed. George Swallow mentioned that the VPN effort is more general since not = all VPN solutions are MPLS based. Bilel Jamoussi added that this work = should be referred to as 'Network-based VPNs', since it is more = general.=20 Also, with regard to Junichi's presentation, the WG decided that this = work is best suited for the VPN BOF (or prospective WG), not the MPLS = WG. ---- Charter Discussion, Vijay Srinivasan =20 Vijay Srinivasan led off the discussion concerning the MPLS WG charter. = He started out by mentioning that he sent out an update to the charter = the evening before the start of this MPLS WG session and proceeded to = describe some aspects of what was written.=20 Joel Halpern then pointed out that a mismatch exists between the goals = and the 10 items listed in the charter. He proceeded by pointing out an = example, i.e., the charter states that 'Mar 00 - produce a doc which = defines support of DiffServ over MPLS networks'; he mentioned that this = does not match any of the 10 items above that statement.=20 Bilel Jamoussi then asked if the framework document was still useful, = since it expired a long time ago. He continued by pointing out that it = is low in the MPLS WG priority queue. Subsequently, Juha Heinanen asked about the status of the label = encapsulation draft. To which, Rob Coltun responded that = interdependency exists among a number of MPLS WG drafts. In particular, = he mentioned that until the LDP draft moves forward, the label = encapsulation draft could not proceed. George Swallow then volunteered = that Bob Thomas should have a new LDP draft out in mid-April. He = continued by indicating that the IESG provided some comments that will = be accommodated by making the necessary changes in the LDP draft; = George mentioned that Bob will do this in coordination with the other = co-authors of that document. George believes that this should be done = by sometime in April. In other words, that the LDP draft will be = re-submitted to the IESG in April 2000. Rob Coltun then asked about the status of the MPLS Framework draft. = The response was that the person that was moving that draft forward was = overcome by events so unless somebody in the MPLS WG volunteers to tie = up the loose ends and polish the document, it will not move forward. In addition, Vijay wanted to gauge the reaction of the MPLS WG on the = header compression work, i.e., whether it is an appropriate work item = for the group. The upshot was that there was consensus to perform work = in that area. George Swallow then asked a related question about the work in policy = and authentication. Someone suggested that coordination with the rest = of the IETF was necessary. Bilel Jamoussi then added that policy helps = in managing MPLS networks. There was also some issue about the connection between policy and = authentication, which led someone to say that policy and authentication = are different, thus, there was no need to combine them, rather to treat = them as two separate work items. After this discussion, George Swallow and Vijay Srinivasan took action = items to add authentication, policy, and compression to the MPLS WG = charter. At this point, the 47th IETF MPLS WG meeting was concluded. ------_=_NextPart_000_01BFCA92.04E47902-- From owner-mpls@UU.NET Tue May 30 20:22: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 UAA13701 for ; Tue, 30 May 2000 20:22: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 QQirmf20068; Wed, 31 May 2000 00:22:51 GMT Received: by mail-control.mail.uu.net id QQirmf08308 for mpls-outgoing; Wed, 31 May 2000 00:22: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 QQirmf08301 for ; Wed, 31 May 2000 00: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 QQirmf27749 for ; Tue, 30 May 2000 20:22:07 -0400 (EDT) Received: from kiwi.equinix.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [207.20.85.65]) id QQirmf22546 for ; Wed, 31 May 2000 00:22:07 GMT Received: from silicon.corp.equinix.com (silicon [172.16.3.99]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id RAA19326; Tue, 30 May 2000 17:21:45 -0700 (PDT) Received: by silicon.corp.equinix.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 17:21:44 -0700 Message-ID: <29C363D591B1D211B6BF0090273C2380E15DD8@silicon.corp.equinix.com> From: Lane Patterson To: "'Jeremy Lawrence'" , mpls@UU.NET Cc: bkumar@ennovatenetworks.com Subject: RE: MPLS domain - AS Date: Tue, 30 May 2000 17:21:44 -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 The proposed application of MPLS across public exchange point switches/LSRs (for example http://www.nanog.org/mtg-0002/feldman.html) is an example that stretches the definition of "administrative domain". In this case, the administrative domain is not the AS, it is the common practices and coordination necessary by exchange point participants. The primary motivation for this is to provide higher-speed and layer-2 agnostic interfaces as a means of public peering, although there is little if any operational experience in this area. The implementation is likely two-hop [IXP LSR, peer LER/LSR] explicit route LSPs using signalling and static routes, no IGP. Regards, -Lane -----Original Message----- From: Jeremy Lawrence [mailto:jlawrenc@cisco.com] Sent: Friday, May 26, 2000 8:22 PM To: mpls@UU.NET Cc: bkumar@ennovatenetworks.com Subject: RE: MPLS domain - AS Someone else has privately pointed out that Brijesh and I are in violent agreement on this issue. :-) This is not quite true: we are generally in agreement, apart from one detail. Comments inline... At 10:25 05/26/2000 -0400, Brijesh Kumar wrote: >In his last mail, Jeremy Lawrence writes > > > At 16:16 05/25/2000 +0530, Naveen Seth wrote: > > >Hi, > > >The definition of MPLS domain in the > > draft-ietf-mpls-arch-06.txt says that the MPLS nodes are in > > one routing or administrative domain. > > > > > >1. Does it imply that we cannot have 2 AS(Autonomous System) > > within the same MPLS domain? > > > > This is possible only under very restricted circumstances. Consider > > the ASBRs of two adjacent ASes. If either or both ASBRs summarize > > eBGP routes before distributing them into their IGP, or if there is > > any other set-up where the IGP routes cover a set of FECs which > > differs from that of the eBGP routes (and this would almost always > > be the case), then the ASBRs cannot forward traffic based on the > > top-level label. A similar argument applies to TE tunnels. Some > > traffic usually will be either IP forwarded by the ASBR, or > >Well... This is inconsistent with the MPLS Arch document. No, it is consistent but unlikely - see below. >A MPLS domain is defined in MPLS architecture document as "a contiguous set >of nodes which operate MPLS routing and forwarding and WHICH ARE IN *ONE >ROUTING OR ADMINISTRATIVE DOMAIN*". > >This means that a MPLS Domain, at most, can cover one Administrative Domain. Agreed. >Any other implementation (i.e., an MPLS domain being defined as part of two >administrative domain) is not in line with this definition. Agreed. It is possible for two ASes to be in the same administrative domain. There are a small number of large SP networks which consist of more than one registered AS, and there are probably many more which use private ASes. In the unlikely case that an MPLS domain does extend across two ASes, the two ASes must have tightly coordinated routing, which would require that they are in the same administrative domain (at least in effect). Regards, Jeremy From owner-mpls@UU.NET Tue May 30 20:54: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 UAA14030 for ; Tue, 30 May 2000 20:54: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 QQirmh10212; Wed, 31 May 2000 00:54:04 GMT Received: by mail-control.mail.uu.net id QQirmh09720 for mpls-outgoing; Wed, 31 May 2000 00:53: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 QQirmh09715 for ; Wed, 31 May 2000 00:53: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 QQirmh00949 for ; Tue, 30 May 2000 20:53: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 QQirmh09727 for ; Wed, 31 May 2000 00:53:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA18742 for mpls@uu.net; Tue, 30 May 2000 20:53: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 QQirmh09704 for ; Wed, 31 May 2000 00:53: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 QQirmh18173 for ; Tue, 30 May 2000 20:52:51 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQirmh09421 for ; Wed, 31 May 2000 00:52:51 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp138-208.cisco.com [144.254.138.208]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id RAA11522; Tue, 30 May 2000 17:46:41 -0700 (PDT) Message-Id: <4.3.1.2.20000531103947.00af9b40@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 31 May 2000 10:46:21 +1000 To: mpls@UU.NET From: Jeremy Lawrence Subject: Re: ATM Switches as LSR encoding techniques Cc: rraszuk@cisco.com In-Reply-To: <39344F4D.B76288A6@cisco.com> References: <200005302057.QAA18651@erosen-sun.cisco.com> <393444F5.F0150C97@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 16:31 05/30/2000 -0700, Robert Raszuk wrote: >David, > > > want to? If you've got ATM, use it. One of the big points about using > > MPLS is to have one unified control plane - if you're going to run MPLS > > through an ATM network that doesn't participat in MPLS, then you've just > >I am talking daily to all major ISPs worldwide deploying MPLS and nobody >mentioned "unified control plane" as the reason to introduce MPLS into >their network. The major reason is to be able to use applications which >MPLS offers (Traffic Eng, MPLS-VPNs, Circuit Transport, Hierarchical >Routing etc ...) > >And if you are stuck with ATM switches which don't support MPLS your >only option is to use generic MPLS encaplsulation over PVC to pass the >data through. Some of the carriers I talk to do see an IP routing/MPLS control plane for ATM as an advantage, but not necessarily a dominant one. So, while their medium-term plans do include use of full ATM MPLS, use of generic MPLS over PVCs meets their requirements in the short term. Jeremy From owner-mpls@UU.NET Tue May 30 21: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 VAA14126 for ; Tue, 30 May 2000 21: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 QQirmi16420; Wed, 31 May 2000 01:05:17 GMT Received: by mail-control.mail.uu.net id QQirmi19327 for mpls-outgoing; Wed, 31 May 2000 01:04: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 QQirmi19322 for ; Wed, 31 May 2000 01:04: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 QQirmi19417 for ; Tue, 30 May 2000 21:04:26 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQirmi15857 for ; Wed, 31 May 2000 01:04:26 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 18:10:05 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D4B@ICARIAN> From: Eric Gray To: "'rraszuk@cisco.com'" , David Charlap Cc: mpls@UU.NET Subject: RE: ATM Switches as LSR encoding techniques Date: Tue, 30 May 2000 18:09:57 -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 Robert, See in-line comment. > -----Original Message----- > From: Robert Raszuk [mailto:rraszuk@cisco.com] > Sent: Tuesday, May 30, 2000 4:31 PM > To: David Charlap > Cc: mpls@UU.NET > Subject: Re: ATM Switches as LSR encoding techniques > > > > David, > > > want to? If you've got ATM, use it. One of the big points about using > > MPLS is to have one unified control plane - if you're going to run MPLS > > through an ATM network that doesn't participat in MPLS, then you've just > > I am talking daily to all major ISPs worldwide deploying MPLS and nobody > mentioned "unified control plane" as the reason to introduce MPLS into > their network. The major reason is to be able to use applications which > MPLS offers (Traffic Eng, MPLS-VPNs, Circuit Transport, Hierarchical > Routing etc ...) This assertion sounds a little strange. All of these things are things that exist and can be supported using ATM (for example). Yet people you're talking to want them using MPLS. Perhaps the unified control plane issue is not as orthogonal as you think? > ... > > Robert. > > > ... > > > > -- David > From owner-mpls@UU.NET Tue May 30 21:06:00 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 VAA14137 for ; Tue, 30 May 2000 21:05: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 QQirmi17042; Wed, 31 May 2000 01:06:00 GMT Received: by mail-control.mail.uu.net id QQirmi19371 for mpls-outgoing; Wed, 31 May 2000 01:05: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 QQirmi19361 for ; Wed, 31 May 2000 01:05: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 QQirmi19546 for ; Tue, 30 May 2000 21:05:26 -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 QQirmi13497 for ; Wed, 31 May 2000 01:05:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA19794 for mpls@uu.net; Tue, 30 May 2000 21:05:25 -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 QQirmi19331 for ; Wed, 31 May 2000 01:04: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 QQirmi19423 for ; Tue, 30 May 2000 21:04:31 -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 QQirmi15891 for ; Wed, 31 May 2000 01:04:31 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 SAA10866; Tue, 30 May 2000 18:04:38 -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 SAA08259; Tue, 30 May 2000 18:04:41 -0700 (PDT) Message-ID: <39346603.4621D78F@cisco.com> Date: Tue, 30 May 2000 18:08:19 -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: Andrzej Czerczak CC: mpls@UU.NET Subject: Re: MPLS - ATM interworking? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Andrzej, > 1) is it possible, acc. to current MPLS specs to provide to customer SLA > report using ATM traffic parameters descriptor? What can be other proposals > for SLA reporting for customer? There are scalable way to guarantee the delivery of packets in the mpls network (guaranteed bandwith tunnels) but I don't think that descring them with ATM traffic parameters is compatible. > 2) just to mention, what about congestion indication (L2) from MPLS -> ATM > direction, as one of the actions performed in MPLS net? Have you read draft MPLS Support of Differentiated Services draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN (explicit congestion notification) on a per LSP basis using the EXP bits in the shim header ? Currently this is the most attractive option, but I am not aware of any implementation support this today. R. > Andrzej Czerczak wrote: > > Hi, > > I have 2 simple questions: > Assume following (very probably) scenario: > -customer router is connected to DSLAM and then to ATM edge switch (VC part > of connection), and then through MPLS cloud (LSP part of connection) to > other customer site. > > 1) is it possible, acc. to current MPLS specs to provide to customer SLA > report using ATM traffic parameters descriptor? What can be other proposals > for SLA reporting for customer? > 2) just to mention, what about congestion indication (L2) from MPLS -> ATM > direction, as one of the actions performed in MPLS net? > > Thanks for your comments. > Andrzej From owner-mpls@UU.NET Tue May 30 21:22: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 ESMTP id VAA14249 for ; Tue, 30 May 2000 21:22: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 QQirmj23581; Wed, 31 May 2000 01:22:55 GMT Received: by mail-control.mail.uu.net id QQirmj20451 for mpls-outgoing; Wed, 31 May 2000 01:22: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 QQirmj20446 for ; Wed, 31 May 2000 01:22:13 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 QQirmj21503 for ; Tue, 30 May 2000 21:22: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 QQirmj23091 for ; Wed, 31 May 2000 01:22:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA21515 for mpls@uu.net; Tue, 30 May 2000 21:22: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 QQirmj20425 for ; Wed, 31 May 2000 01:21: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 QQirmj21445 for ; Tue, 30 May 2000 21:21:21 -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 QQirmj22681 for ; Wed, 31 May 2000 01:21:20 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 SAA06564; Tue, 30 May 2000 18:21:29 -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 SAA08272; Tue, 30 May 2000 18:21:30 -0700 (PDT) Message-ID: <393469F5.1437926D@cisco.com> Date: Tue, 30 May 2000 18:25:09 -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: Eric Gray CC: David Charlap , mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques References: <9A564CC874B5D3118FB9009027B0A6622D7D4B@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, > All of these things are things that exist and can be > supported using ATM (for example). Yet people you're > talking to want them using MPLS. That is true that all of them can be provisioned with ATM today. But the problem is that using L2 (or any kind of tunneling) for TE, for VPN or even for Circuit Transport scales very poorly. Once you provisioned hundred or maybe thousand of VC your operations people are starting to suffer from lack of control and maintenance nightmare. That from the provider point of view. From the customer point of view things don't look nice either when he needs to peer with hundreds of his own routers (the VPN case) rather then with one (or two for redundancy) residing on his provider edge. What MPLS gives you is the freedom to use L3 to deliver all of those services without touching the underling L2. In fact you build your core only once and don't need to modify it when customer is added/deleted or when he requesting new service. > Perhaps the unified control plane issue is not as orthogonal as you think? As a matter of fact no later then last friday I was talking to large telco shop which are deploying ATM + MPLS and they have cleary stated that they want to run both PNNI + LDP. The reason being is that this ATM backbone will be still serving the SVC/Soft-PVC connections while in the same time be a mpsl aware transport for IP traffic. R. > Eric Gray wrote: > > Robert, > > See in-line comment. > > > -----Original Message----- > > From: Robert Raszuk [mailto:rraszuk@cisco.com] > > Sent: Tuesday, May 30, 2000 4:31 PM > > To: David Charlap > > Cc: mpls@UU.NET > > Subject: Re: ATM Switches as LSR encoding techniques > > > > > > > > David, > > > > > want to? If you've got ATM, use it. One of the big points about using > > > MPLS is to have one unified control plane - if you're going to run MPLS > > > through an ATM network that doesn't participat in MPLS, then you've just > > > > I am talking daily to all major ISPs worldwide deploying MPLS and nobody > > mentioned "unified control plane" as the reason to introduce MPLS into > > their network. The major reason is to be able to use applications which > > MPLS offers (Traffic Eng, MPLS-VPNs, Circuit Transport, Hierarchical > > Routing etc ...) > > This assertion sounds a little strange. > > All of these things are things that exist and can be > supported using ATM (for example). Yet people you're > talking to want them using MPLS. Perhaps the unified > control plane issue is not as orthogonal as you think? > > > > ... > > > > Robert. > > > > > > ... > > > > > > -- David > > From owner-mpls@UU.NET Tue May 30 21:40:45 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 VAA14423 for ; Tue, 30 May 2000 21:40: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 QQirmk03872; Wed, 31 May 2000 01:40:45 GMT Received: by mail-control.mail.uu.net id QQirmk21212 for mpls-outgoing; Wed, 31 May 2000 01:40: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 QQirmk21207 for ; Wed, 31 May 2000 01:40: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 QQirmk06003 for ; Tue, 30 May 2000 21:40:07 -0400 (EDT) Received: from mmu.edu.my by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ext-dns.mmu.edu.my [203.106.62.11]) id QQirmk03288 for ; Wed, 31 May 2000 01:40:02 GMT Received: from venus.cyber.mmu.edu.my (venus.cyber.mmu.edu.my [203.106.62.12]) by mmu.edu.my (8.9.1b+Sun/8.9.1) with ESMTP id JAA29207; Wed, 31 May 2000 09:26:42 +0800 (MYT) Received: from swtan.cyber.mmu.edu.my ([10.100.35.59]) by venus.cyber.mmu.edu.my (8.8.8+Sun/8.8.8) with SMTP id JAA08523; Wed, 31 May 2000 09:37:57 +0800 (SGT) Message-ID: <00e701bfc9df$52d2cd20$3b23640a@cyber.mmu.edu.my> From: "Tan Su Wei" To: "Kireeti Kompella" , , , Cc: References: <200005301644.JAA17897@kummer.juniper.net> Subject: Re: can egress know the ingress of a packet? Date: Tue, 30 May 2000 09:32:38 +0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear All, Thanks for answering my question. As Kireeti wrote: > Perhaps we've gone off on an tangent here. The question > as I understood it is "when a *data* packet arrives at > the egress, can we know which ingress and which LSP it > travelled on?" -- and the answer is, not without some > extracurricular work. > > Tan, can you clarify your question? and my question is exactly as above. I'm sorry if there is any misunderstanding. For the posted answer from Mr. Eric Gray It is possible to know the LSP traversed, only if the LSP is "identified". This is possible with either CR-LDP (using LSP-ID) or RSVP-TE (using SESSION). Lets if the LSP is "identified" using either lspid or session object (during the LSP setup time, right?) , to know the lsp and ingress the *data* packet from, is that mean we need adding a field in the data packet on this information? (Maybe ip header option field?). Since information get from the incoming label and interface might be incorrect when there is LSP merge. Is my interpretation correct? Thank you for your reply. Regards Tan Su Wei From owner-mpls@UU.NET Tue May 30 21:44: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 VAA14650 for ; Tue, 30 May 2000 21:44: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 QQirmk08396; Wed, 31 May 2000 01:44:12 GMT Received: by mail-control.mail.uu.net id QQirmk21496 for mpls-outgoing; Wed, 31 May 2000 01:43: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 QQirmk21487 for ; Wed, 31 May 2000 01:43: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 QQirmk06310 for ; Tue, 30 May 2000 21:43:09 -0400 (EDT) Received: from mail03.rapidsite.net by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: mail03.rapidsite.net [207.158.192.52]) id QQirmk07754 for ; Wed, 31 May 2000 01:43:09 GMT Received: from www.adventnetworks.com (207.158.252.140) by mail03.rapidsite.net (RS ver 1.0.56s) with SMTP id 015441098; Tue, 30 May 2000 21:42:52 -0400 (EDT) Reply-To: From: "Robert Johnson" To: Cc: Subject: RE: ATM Switches as LSR encoding techniques Date: Tue, 30 May 2000 20:31:23 -0500 Message-ID: <000401bfcaa1$ad795a60$2a01a8c0@rjohnson> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <39344F4D.B76288A6@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Disposition-Notification-To: "Robert Johnson" X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I am talking daily to all major ISPs worldwide deploying MPLS and nobody > mentioned "unified control plane" as the reason to introduce MPLS into > their network. The major reason is to be able to use applications which > MPLS offers (Traffic Eng, MPLS-VPNs, Circuit Transport, Hierarchical > Routing etc ...) How do you find the time? :) Regardless, you forgot the most important motivator for many ISP MPLS implementations: politics. All of the applications that you mentioned were possible (note they were possible, not necessarily easy) using ATM. However, those ISPs that used ATM in this fashion and are now moving to MPLS, for whatever reasons, need a unified control plane. Alternatively, I suppose they could just throw away all of their old gear and buy a completely new network. :) > And if you are stuck with ATM switches which don't support MPLS your > only option is to use generic MPLS encaplsulation over PVC to pass the > data through. I would hate to be "stuck" with such switches. :) However, often you are only "stuck" with the hardware while there is a firmware upgrade path to provide MPLS functionality. Again, there is always the new network option. :) Robert Johnson Director of Network Architecture Advent Networks (512) 397-4914 From owner-mpls@UU.NET Tue May 30 21:55: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 VAA15400 for ; Tue, 30 May 2000 21:55: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 QQirml14893; Wed, 31 May 2000 01:55:38 GMT Received: by mail-control.mail.uu.net id QQirml22197 for mpls-outgoing; Wed, 31 May 2000 01:55: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 QQirml22192 for ; Wed, 31 May 2000 01:55: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 QQirml07444 for ; Tue, 30 May 2000 21:54:57 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQirml14446 for ; Wed, 31 May 2000 01:54:56 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 19:00:36 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D4D@ICARIAN> From: Eric Gray To: "'Tan Su Wei'" , Kireeti Kompella , dwilder@baynetworks.com, Eric Gray , Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: can egress know the ingress of a packet? Date: Tue, 30 May 2000 19:00:27 -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 Tan, No information is added to the IP header to aid in determining what LSP it is to be propagated on except for the MPLS label (which is prepended as part of the MPLS stack and is not part of the IP header). When the last useful label is removed from a data packet (either by popping it or by using an explicit NULL label), there is no longer any way to positively identify the LSP that it was forwarded on. I had the impression - because of the way that you asked your question - that you were trying to find out how LSP information might be inferred from the label on a packet. Again, (and as Kireeti already pointed out) it cannot be easily inferred from the IP packet once all useful label information is gone. I doubt that it can be determined absolutely at that point through much less than magic. -- Eric Gray > -----Original Message----- > From: Tan Su Wei [mailto:swtan@mmu.edu.my] > Sent: Monday, May 29, 2000 7:33 PM > To: Kireeti Kompella; dwilder@baynetworks.com; EGray@zaffire.com; > Shahram_Davari@pmc-sierra.com > Cc: mpls@UU.NET > Subject: Re: can egress know the ingress of a packet? > > > Dear All, > Thanks for answering my question. > As Kireeti wrote: > > Perhaps we've gone off on an tangent here. The question > > as I understood it is "when a *data* packet arrives at > > the egress, can we know which ingress and which LSP it > > travelled on?" -- and the answer is, not without some > > extracurricular work. > > > > Tan, can you clarify your question? > > and my question is exactly as above. I'm sorry if there is any > misunderstanding. > For the posted answer from Mr. Eric Gray > > It is possible to know the LSP traversed, only if > the LSP is "identified". This is possible with either > CR-LDP (using LSP-ID) or RSVP-TE (using SESSION). > > Lets if the LSP is "identified" using either lspid or session > object (during > the LSP setup time, right?) , to know the lsp and ingress the > *data* packet > from, is that mean we need adding a field in the data packet on this > information? (Maybe ip header option field?). > Since information get from the incoming label and interface might be > incorrect when there is LSP merge. > Is my interpretation correct? > > Thank you for your reply. > > Regards > Tan Su Wei > > From owner-mpls@UU.NET Wed May 31 00:21: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 ESMTP id AAA17977 for ; Wed, 31 May 2000 00:21:48 -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 QQirmv05715; Wed, 31 May 2000 04:21:47 GMT Received: by mail-control.mail.uu.net id QQirmv27248 for mpls-outgoing; Wed, 31 May 2000 04:21: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 QQirmv27239 for ; Wed, 31 May 2000 04:21: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 QQirmv23917 for ; Wed, 31 May 2000 00:21:04 -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 QQirmv01529 for ; Wed, 31 May 2000 04:21:03 GMT Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 21:20:57 -0700 Message-ID: From: Arun Viswanathan To: "'Vikram Venkataraghavan'" , mpls@UU.NET Subject: RE: ATM Switches as LSR encoding techniques Date: Tue, 30 May 2000 21:20:56 -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 Vikram, > In the MPLS Architecture document > (draft-ietf-mpls-arch-06), there are listed three > encoding techniques for MPLS labels to encoded > directly into the VPI/VCI fields in an ATM AAL5 > header. > 1. SVC Encoding > 2. SVP Encoding > 3. SVP Multipoint Encoding Only SVC encoding is spec-ed out as a proposed standard. See draft-ietf-mpls-atm-03.txt. The other two scheme didn't move forward for lack of interest in the community, > > The document also points out that there is no > interoperability mechanism between ATM LSRs that use > different kinds of encoding. and interoperability being the main issue. Hope that answers your question. -arun From owner-mpls@UU.NET Wed May 31 01:43: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 BAA23379 for ; Wed, 31 May 2000 01:43: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 QQirna18406; Wed, 31 May 2000 05:43:18 GMT Received: by mail-control.mail.uu.net id QQirna10242 for mpls-outgoing; Wed, 31 May 2000 05:42: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 QQirna10237 for ; Wed, 31 May 2000 05:42: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 QQirna20534 for ; Wed, 31 May 2000 01:42:38 -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 QQirna17998 for ; Wed, 31 May 2000 05:42:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA08494 for mpls@uu.net; Wed, 31 May 2000 01:42:36 -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 QQirna10212 for ; Wed, 31 May 2000 05:42:12 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 QQirna20512 for ; Wed, 31 May 2000 01:42:02 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQirna15755 for ; Wed, 31 May 2000 05:42:02 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp138-208.cisco.com [144.254.138.208]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id WAA27110; Tue, 30 May 2000 22:42:00 -0700 (PDT) Message-Id: <4.3.1.2.20000531151158.00afc2f0@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 31 May 2000 15:41:40 +1000 To: mpls@UU.NET From: Jeremy Lawrence Subject: RE: MPLS domain - AS Cc: Lane Patterson In-Reply-To: <29C363D591B1D211B6BF0090273C2380E15DD8@silicon.corp.equini x.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Another example (thanks to Rob Raszuk) is with the multi-provider application of BGP+MPLS VPNs: section 10 of http://www.ietf.org/internet-drafts/draft-rosen-rfc2547bis-01.txt As described earlier, there are usually no *top-level* LSPs established across the two (or more) provider ASes involved, so it can be argued that 1. the two ASes are separate administrative domains. However there are some LSPs established across the two ASes, at a lower level in the label stack. So, it can be argued that 2. the two ASes are the same administrative domain, in so far as the two providers agree to allow lower-level LSPs to be established across the two ASes I think that (1) and (2) are both true, which implies that different definitions of the boundary of the administrative domains can exist with respect to different levels in the label stack. It is also (in hindsight) obvious that different MPLS domain boundaries can exist with respect to different levels of the label stack. Jeremy At 17:21 05/30/2000 -0700, Lane Patterson wrote: >The proposed application of MPLS across public exchange point switches/LSRs >(for example http://www.nanog.org/mtg-0002/feldman.html) is an example that >stretches the definition of "administrative domain". In this case, the >administrative domain is not the AS, it is the common practices and >coordination necessary by exchange point participants. > >The primary motivation for this is to provide higher-speed and layer-2 >agnostic interfaces as a means of public peering, although there is little >if any operational experience in this area. > >The implementation is likely two-hop [IXP LSR, peer LER/LSR] explicit route >LSPs using signalling and static routes, no IGP. > >Regards, >-Lane > From owner-mpls@UU.NET Wed May 31 06:23: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 GAA02516 for ; Wed, 31 May 2000 06:23: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 QQirnt16541; Wed, 31 May 2000 10:23:25 GMT Received: by mail-control.mail.uu.net id QQirnt09925 for mpls-outgoing; Wed, 31 May 2000 10:22: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 QQirnt09920 for ; Wed, 31 May 2000 10:22: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 QQirnt20595 for ; Wed, 31 May 2000 06:22:37 -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 QQirnt15859 for ; Wed, 31 May 2000 10:22:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA19749 for mpls@uu.net; Wed, 31 May 2000 06:22: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 QQirnt09895 for ; Wed, 31 May 2000 10:22: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 QQirnt29652 for ; Wed, 31 May 2000 06:22:07 -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 QQirnt15604 for ; Wed, 31 May 2000 10:22:06 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02450; Wed, 31 May 2000 06:22:03 -0400 (EDT) Message-Id: <200005311022.GAA02450@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-07.txt Date: Wed, 31 May 2000 06:22:03 -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 : LDP Specification Author(s) : L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas Filename : draft-ietf-mpls-ldp-07.txt Pages : 135 Date : 30-May-00 An overview of Multi Protocol Label Switching (MPLS) is provided in [FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths [LDPAPPLIC]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-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-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-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: <20000530095827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000530095827.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed May 31 07:05: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 HAA03340 for ; Wed, 31 May 2000 07:05: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 QQirnw08767; Wed, 31 May 2000 11:05:33 GMT Received: by mail-control.mail.uu.net id QQirnw16127 for mpls-outgoing; Wed, 31 May 2000 11:05:02 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 QQirnw16061 for ; Wed, 31 May 2000 11:04: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 QQirnw03528 for ; Wed, 31 May 2000 07:04: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 QQirnw08263 for ; Wed, 31 May 2000 11:04:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA22167 for mpls@uu.net; Wed, 31 May 2000 07:04:45 -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 QQirnw15731 for ; Wed, 31 May 2000 11:04: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 QQirnw24530 for ; Wed, 31 May 2000 07:04:14 -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 QQirnw07235 for ; Wed, 31 May 2000 11:04:14 GMT Received: from focal.cisco.com (focal.cisco.com [171.69.204.16]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA22133 for ; Wed, 31 May 2000 07:04:13 -0400 (EDT) Received: (rhthomas@localhost) by focal.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id HAA08106; Wed, 31 May 2000 07:04:13 -0400 (EDT) Date: Wed, 31 May 2000 07:04:13 -0400 (EDT) Message-Id: <200005311104.HAA08106@focal.cisco.com> From: Bob Thomas To: mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-07.txt Sender: owner-mpls@UU.NET Precedence: bulk A new version of the LDP spec has been posted as draft-ietf-mpls-ldp-07.txt. This draft addresses issues raised during the IESG LDP last call as well a few other issues. The following two files may be helpful in reviewing this revision. They may be retrieved via anonymous ftp from: host: ftpeng.cisco.com, files: rhthomas/ldp-07.changes rhthomas/draft-ietf-mpls-ldp-07.txt.change_bars - ldp-07.changes This file briefly summarizes each issue raised during the IESG LDP last call and describes how each was addressed in draft-ietf-mpls-ldp-07.txt. - draft-ietf-mpls-ldp-07.txt.change_bars This is draft-ietf-mpls-ldp-07.txt with manually added change bars. The change bars are keyed to the issues in ldp-07.changes. Bob From owner-mpls@UU.NET Wed May 31 09:05: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 JAA07894 for ; Wed, 31 May 2000 09:05: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 QQiroe19873; Wed, 31 May 2000 13:05:43 GMT Received: by mail-control.mail.uu.net id QQiroe13845 for mpls-outgoing; Wed, 31 May 2000 13:05: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 QQiroe13762 for ; Wed, 31 May 2000 13:05:01 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 QQiroe11513 for ; Wed, 31 May 2000 09:04:48 -0400 (EDT) Received: from redbaron.nexabit.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQiroe19208 for ; Wed, 31 May 2000 13:04:47 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id JAA11313; Wed, 31 May 2000 09:04:46 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 09:04:46 -0400 Message-ID: From: Greg Mirsky To: David Charlap , mpls@UU.NET Subject: RE: MPLS Performance analysis..... Date: Wed, 31 May 2000 09:04:45 -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 David, complicated not necessarily means slow. It's doable and it's done. Regards, Greg > -----Original Message----- > From: David Charlap [SMTP:david.charlap@marconi.com] > Sent: Tuesday, May 30, 2000 6:52 PM > To: mpls@UU.NET > Subject: Re: MPLS Performance analysis..... > > Curtis Villamizar wrote: > > > > I was one of those people. Doing the IP destination lookup is no > > longer a limiting factor for modern routers. > > Depends on the speed. If you up the number and type of interfaces so > that your fabric has to forward billions or trillions of packets per > second, you will once again find differences in how the two forwarding > engines (IP destination vs. label) perform. > > Regardless of how fast the chips run, an IP best-match lookup is an > inherently more complicated operation than the integer-matching lookup > required by something that forwards based on label (or VC or DLC). > > -- David From owner-mpls@UU.NET Wed May 31 09:29: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 JAA08837 for ; Wed, 31 May 2000 09:29: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 QQirof05848; Wed, 31 May 2000 13:29:49 GMT Received: by mail-control.mail.uu.net id QQirof20394 for mpls-outgoing; Wed, 31 May 2000 13:29: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 QQirof20389 for ; Wed, 31 May 2000 13:29:15 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 QQirof23975 for ; Wed, 31 May 2000 09:29:07 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQirof05583 for ; Wed, 31 May 2000 13:29:07 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id JAA15705; Wed, 31 May 2000 09:29:02 -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 JAA05208; Wed, 31 May 2000 09:29:20 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200005311329.JAA05208@curtis-lt.avici.com> To: David Charlap cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: ATM Switches as LSR encoding techniques In-reply-to: Your message of "Tue, 30 May 2000 18:47:17 EDT." <393444F5.F0150C97@marconi.com> Date: Wed, 31 May 2000 09:29:20 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <393444F5.F0150C97@marconi.com>, David Charlap writes: > Eric Rosen wrote: > > > > Please note that routers with ATM cards are not ATM switches. > > Therefore, routers with ATM cards would not be expected to use the > > encodings defined for ATM switches. If two routers are connected to > > each other via an ATM VC, then of course they use the generic MPLS > > encapsulation when sending labeled packets over that VC, NOT the > > ATM-specific MPLS encapsulation. > > Which deliberately makes the interface incompatible with an ATM switch > running MPLS code. That's OK? ;-) It's actually not a deliberate incompatibility. It has not been expressed as a customer requirement, at least for our customer base. > Why in the world would you want to use an ATM interface if it is > incompatible with ATM switches? Transition from legacy ATM backbones in which the ATM switches just provide VCs and don't know about MPLS. Curtis From owner-mpls@UU.NET Wed May 31 09:44: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 JAA09503 for ; Wed, 31 May 2000 09:44: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 QQirog15499; Wed, 31 May 2000 13:44:19 GMT Received: by mail-control.mail.uu.net id QQirog21225 for mpls-outgoing; Wed, 31 May 2000 13:44: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 QQirog21220 for ; Wed, 31 May 2000 13:43: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 QQirog19167 for ; Wed, 31 May 2000 09:43:37 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQirog15623 for ; Wed, 31 May 2000 13:43:37 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id JAA16827; Wed, 31 May 2000 09:43:33 -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 JAA05230; Wed, 31 May 2000 09:43:51 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200005311343.JAA05230@curtis-lt.avici.com> To: David Charlap cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS Performance analysis..... In-reply-to: Your message of "Tue, 30 May 2000 18:51:42 EDT." <393445FE.BD4D9876@marconi.com> Date: Wed, 31 May 2000 09:43:50 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <393445FE.BD4D9876@marconi.com>, David Charlap writes: > Curtis Villamizar wrote: > > > > I was one of those people. Doing the IP destination lookup is no > > longer a limiting factor for modern routers. > > Depends on the speed. If you up the number and type of interfaces so > that your fabric has to forward billions or trillions of packets per > second, you will once again find differences in how the two forwarding > engines (IP destination vs. label) perform. The forwarding decision needs to be made independently on each forwarding card if you want to build a scalable router. This way the amount of parallelism grows as the number of interfaces grows. If the IP forwarding decision is part of the fabric, that's simply a design mistake if very large scalability is a design goal. > Regardless of how fast the chips run, an IP best-match lookup is an > inherently more complicated operation than the integer-matching lookup > required by something that forwards based on label (or VC or DLC). If you can do it in a few clock cycles in an microprogammed engine, and its faster than the packet arrival rate it doesn't matter. As Greg Mirsky already pointed out, its been done in routers (from multiple sources). > -- David Curtis From owner-mpls@UU.NET Wed May 31 10:36: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 ESMTP id KAA12129 for ; Wed, 31 May 2000 10:36: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 QQirok22179; Wed, 31 May 2000 14:36:13 GMT Received: by mail-control.mail.uu.net id QQirok03542 for mpls-outgoing; Wed, 31 May 2000 14:35: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 QQirok03537 for ; Wed, 31 May 2000 14:35:36 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 QQirok00215 for ; Wed, 31 May 2000 10:35:27 -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 QQirok21491 for ; Wed, 31 May 2000 14:35:27 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 KAA26667; Wed, 31 May 2000 10:35:24 -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 KAA19711; Wed, 31 May 2000 10:35:24 -0400 (EDT) Message-ID: <39352352.259ADF2F@marconi.com> Date: Wed, 31 May 2000 10:36:02 -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: rraszuk@cisco.com CC: Eric Gray , mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques References: <9A564CC874B5D3118FB9009027B0A6622D7D4B@ICARIAN> <393469F5.1437926D@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 Raszuk wrote: >> >> All of these things are things that exist and can be supported using >> ATM (for example). Yet people you're talking to want them using >> MPLS. > > That is true that all of them can be provisioned with ATM today. But > the problem is that using L2 (or any kind of tunneling) for TE, for > VPN or even for Circuit Transport scales very poorly. Once you > provisioned hundred or maybe thousand of VC your operations people are > starting to suffer from lack of control and maintenance nightmare. And this same nightmare doesn't exist if you provision hundreds or thousands of LSPs through that exact same network? -- David From owner-mpls@UU.NET Wed May 31 11:03: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 ESMTP id LAA13124 for ; Wed, 31 May 2000 11:03: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 QQirom12261; Wed, 31 May 2000 15:03:36 GMT Received: by mail-control.mail.uu.net id QQirom09268 for mpls-outgoing; Wed, 31 May 2000 15:02: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 QQirom08931 for ; Wed, 31 May 2000 15:02: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 QQirom06133 for ; Wed, 31 May 2000 11:02:31 -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 QQirom11239 for ; Wed, 31 May 2000 15:02:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA17080 for mpls@uu.net; Wed, 31 May 2000 11:02:30 -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 QQirom07569 for ; Wed, 31 May 2000 15:01: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 QQirol10799 for ; Wed, 31 May 2000 10:58:15 -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 QQirol05692 for ; Wed, 31 May 2000 14:58:14 GMT Received: from cisco.com (rraszuk-dsl1.cisco.com [10.19.31.90]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA02222; Wed, 31 May 2000 07:58:11 -0700 (PDT) Message-ID: <393536C4.C63F46A1@cisco.com> Date: Wed, 31 May 2000 08:59:00 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: rraszuk@cisco.com, Eric Gray , mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques References: <9A564CC874B5D3118FB9009027B0A6622D7D4B@ICARIAN> <393469F5.1437926D@cisco.com> <39352352.259ADF2F@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > And this same nightmare doesn't exist if you provision hundreds or > thousands of LSPs through that exact same network? When you provision let's say TE tunnels (in not all but in the most cases) you are not building them from your customer interface to customer interface on the other end of your network. What you are building is a set of tunnels to interconnect your own boxes with (either edge-egde or middle-edge or any other possible combination) but always within you domain. That itself reduces the number of LSPs versus VCs very dramatically. In MPLS-VPN by using for example prefix based label stacking you don't need to provision any LSP/VC to create very large VPNs across your core. Of course one may argue that instead of building L3 networks with IGPs just flat or hierarchical PNNI should be used in a closed provider network to achive the same. Unfortunately by looking at the current industry trends, dominance of IP and proven scalbility of BGP & IGPs in the Internet I don't think that this option is practical. R. > David Charlap wrote: > > Robert Raszuk wrote: > >> > >> All of these things are things that exist and can be supported using > >> ATM (for example). Yet people you're talking to want them using > >> MPLS. > > > > That is true that all of them can be provisioned with ATM today. But > > the problem is that using L2 (or any kind of tunneling) for TE, for > > VPN or even for Circuit Transport scales very poorly. Once you > > provisioned hundred or maybe thousand of VC your operations people are > > starting to suffer from lack of control and maintenance nightmare. > > And this same nightmare doesn't exist if you provision hundreds or > thousands of LSPs through that exact same network? > > -- David From owner-mpls@UU.NET Wed May 31 11:04: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 LAA13142 for ; Wed, 31 May 2000 11:04: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 QQirom13000; Wed, 31 May 2000 15:04:13 GMT Received: by mail-control.mail.uu.net id QQirom10325 for mpls-outgoing; Wed, 31 May 2000 15:03: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 QQirom10182 for ; Wed, 31 May 2000 15:03:49 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 QQirom11776 for ; Wed, 31 May 2000 11:02:51 -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 QQirom11458 for ; Wed, 31 May 2000 15:02:50 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 IAA05334 for ; Wed, 31 May 2000 08:02:59 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA19410 for mpls@uu.net; Wed, 31 May 2000 11:02:48 -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 QQirod07964 for ; Wed, 31 May 2000 12:50: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 QQirod09199 for ; Wed, 31 May 2000 08:50:41 -0400 (EDT) Received: from ns01.newbridge.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQirod10596 for ; Wed, 31 May 2000 12:50:40 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id IAA18412 for ; Wed, 31 May 2000 08:44:19 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdDAATlle9_; Wed May 31 08:44:14 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Wed, 31 May 2000 08:50:38 -0400 Received: from newbridge.com ([138.120.6.166]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA7389; Wed, 31 May 2000 08:50:42 -0400 Message-Id: <39350977.CD3114FA@newbridge.com> Date: Wed, 31 May 2000 08:45:44 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: erosen@cisco.com CC: David Charlap , mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques References: <200005302057.QAA18651@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 Eric, Eric Rosen wrote: > Please note that routers with ATM cards are not ATM switches. Therefore, > routers with ATM cards would not be expected to use the encodings defined > for ATM switches. If two routers are connected to each other via an ATM VC, > then of course they use the generic MPLS encapsulation when sending labeled > packets over that VC, NOT the ATM-specific MPLS encapsulation. Is there any plan for router vendors to use the encodings defined for ATM switches in the near future? This will hurt the interoperability of LSRs in the long run. Cheers, Hansen From owner-mpls@UU.NET Wed May 31 11:27: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 LAA13855 for ; Wed, 31 May 2000 11:27: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 QQiron00287; Wed, 31 May 2000 15:27:33 GMT Received: by mail-control.mail.uu.net id QQiron16347 for mpls-outgoing; Wed, 31 May 2000 15:26: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 QQiron16337 for ; Wed, 31 May 2000 15:26:52 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 QQiron11392 for ; Wed, 31 May 2000 11:26:42 -0400 (EDT) Received: from owa.metrored.com.ar by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [200.41.136.131]) id QQiron25504 for ; Wed, 31 May 2000 15:26:28 GMT Received: by owa.metrored.com.ar with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 12:24:52 -0300 Message-ID: From: =?iso-8859-1?Q?=22Bugallo=2C_Hern=E1n=22?= To: "'mpls@UU.NET'" Subject: MPLS-COS settings - Date: Tue, 30 May 2000 21:03:34 -0300 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 LAA13855 > Hello, all > > I have problems to set up COS (muti-vc mode) over my MPLS lab.- > I´m using the lastest IOS version. > Any body know how can I set this class of service mode on Cisco 7200 > routers. > > Thanks a lot, > _\\|//_ > ( O-O ) > /)~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~(\ > // Hernán Bugallo \\ > _(( Gcia de Tecnología & Networking ))_ > (((\\ /) MetroRED Telecomunicaciones (\ //))) > (\\\\\_// Paseo Colon 505 - 5º Piso \\_/////) > \ / (Buenos Aires)- ARGENTINA C.P.:(1063) \ / > \ / Tel: +(5411) +4344-7700 +(7829) \ / > \ _/ oooO \_ / > / /~~~~~~~~~~~~~~~~~~( )~~Oooo~~~~~~~~~~~~~~~~\ \ > / / \ ( ( ) \ \ > / / \_) ) / \ \ > (_/ > From owner-mpls@UU.NET Wed May 31 11:36: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 ESMTP id LAA14143 for ; Wed, 31 May 2000 11:36: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 QQiroo02860; Wed, 31 May 2000 15:36:29 GMT Received: by mail-control.mail.uu.net id QQiroo16880 for mpls-outgoing; Wed, 31 May 2000 15: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 QQiroo16875 for ; Wed, 31 May 2000 15:35: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 QQiroo18616 for ; Wed, 31 May 2000 11:35:36 -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 QQiroo02106 for ; Wed, 31 May 2000 15:35:36 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 IAA26339; Wed, 31 May 2000 08:35:44 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA19529; Wed, 31 May 2000 11:35:34 -0400 (EDT) Message-Id: <200005311535.LAA19529@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: David Charlap , Hansen Chan cc: mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques In-reply-to: Your message of Tue, 30 May 2000 18:47:17 -0400. <393444F5.F0150C97@marconi.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, 31 May 2000 11:35:33 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> Which deliberately makes the interface incompatible with an ATM David> switch running MPLS code. That's a bit like saying that an ethernet interface is incompatible with a token ring switch. That's true, but of no consequence. If you're connecting to an ATM-LSR, you use an LC-ATM interface. If you're connecting to an ATM switch which is not an ATM-LSR, you don't. (These terms are clearly defined in draft-ietf-mpls-atm-03.txt.) David> Why in the world would you want to use an ATM interface if it is David> incompatible with ATM switches? The real question is why would you want to use an ATM interface if the ATM switch at the other end is not an ATM-LSR. I think the answer is obvious -- that might be what you have to do to get your connectivity. Hansen> Is there any plan for router vendors to use the encodings defined Hansen> for ATM switches in the near future? This will hurt the Hansen> interoperability of LSRs in the long run. Generally routers are capable of handling different kinds of interfaces. Thus one would expect them to be able to handle the generic encapsulation as well as the ATM-specific encapsulation. From owner-mpls@UU.NET Wed May 31 11:52: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 ESMTP id LAA14514 for ; Wed, 31 May 2000 11:52:43 -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 QQirop14012; Wed, 31 May 2000 15:52:17 GMT Received: by mail-control.mail.uu.net id QQirop17884 for mpls-outgoing; Wed, 31 May 2000 15:51: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 QQirop17874 for ; Wed, 31 May 2000 15:51: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 QQirop21622 for ; Wed, 31 May 2000 11:51: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 QQirop13018 for ; Wed, 31 May 2000 15:51:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA26316 for mpls@uu.net; Wed, 31 May 2000 11:51:11 -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 QQirop17748 for ; Wed, 31 May 2000 15:50: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 QQirop16207 for ; Wed, 31 May 2000 11:50:01 -0400 (EDT) Received: from no-worries.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: no-worries.cisco.com [144.254.148.250]) id QQirop16147 for ; Wed, 31 May 2000 15:49:58 GMT Received: from DAPATTERLAPTOP (dapatter-isdn1.cisco.com [171.70.160.89]) by no-worries.cisco.com (8.8.8+Sun/8.8.8) with SMTP id BAA14559; Thu, 1 Jun 2000 01:49:46 +1000 (EST) From: "Darren Patterson" To: =?iso-8859-1?Q?Bugallo=2C_Hern=E1n?= , Subject: RE: MPLS-COS settings - Date: Wed, 31 May 2000 23:45:36 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Enable the command tag-switching atm multi-vc, there will also be a several commands tag-switching atm cos for setting the bandwidth: SGP-LSC1(config-if)#tag-switching atm cos ? available Select weight for class available control Select weight for class control premium Select weight for class premium standard Select weight for class standard SGP-LSC1(config-if)#tag-switching atm cos av SGP-LSC1(config-if)#tag-switching atm cos available ? <0-100> total weight for all classes must not exceed 100 SGP-LSC1(config-if)#tag-switching atm cos available regards > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bugallo, > Hernán > Sent: Wednesday, 31 May 2000 8:04 AM > To: 'mpls@UU.NET' > Subject: MPLS-COS settings - > > > > > Hello, all > > > > I have problems to set up COS (muti-vc mode) over my MPLS lab.- > > I´m using the lastest IOS version. > > Any body know how can I set this class of service mode on Cisco 7200 > > routers. > > > > Thanks a lot, > > _\\|//_ > > ( O-O ) > > /)~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~(\ > > // Hernán Bugallo \\ > > _(( Gcia de Tecnología & Networking ))_ > > (((\\ /) MetroRED Telecomunicaciones (\ //))) > > (\\\\\_// Paseo Colon 505 - 5º Piso \\_/////) > > \ / (Buenos Aires)- ARGENTINA C.P.:(1063) \ / > > \ / Tel: +(5411) +4344-7700 +(7829) \ / > > \ _/ oooO \_ / > > / /~~~~~~~~~~~~~~~~~~( )~~Oooo~~~~~~~~~~~~~~~~\ \ > > / / \ ( ( ) \ \ > > / / \_) ) / \ \ > > (_/ > > From owner-mpls@UU.NET Wed May 31 12:00: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 MAA14785 for ; Wed, 31 May 2000 12:00: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 QQiroq23449; Wed, 31 May 2000 16:00:17 GMT Received: by mail-control.mail.uu.net id QQirop18262 for mpls-outgoing; Wed, 31 May 2000 15:59: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 QQirop18246 for ; Wed, 31 May 2000 15:59: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 QQirop22988 for ; Wed, 31 May 2000 11: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 QQirop21985 for ; Wed, 31 May 2000 15:58:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA27624 for mpls@uu.net; Wed, 31 May 2000 11:58:38 -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 QQirop18186 for ; Wed, 31 May 2000 15:57: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 QQirop17532 for ; Wed, 31 May 2000 11:56:14 -0400 (EDT) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQirop16783 for ; Wed, 31 May 2000 15:56:13 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.9]) by ogma.cisco.com (Postfix) with ESMTP id 3801AB7; Wed, 31 May 2000 17:56:12 +0200 (MET DST) Received: from jguichar-8kcdt.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA13282; Wed, 31 May 2000 17:56:10 +0200 (MET DST) Message-Id: <200005311556.RAA13282@london.cisco.com> X-Sender: jguichar@uk.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 31 May 2000 16:54:47 +0100 To: "Darren Patterson" , Bugallo@cisco.com, =?iso-8859-1?Q?Hern=E1n?= , From: Jim Guichard Subject: RE: MPLS-COS settings - In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14785 also review : http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120 t/120t5/cos.htm At 23:45 31/05/2000 +0800, Darren Patterson wrote: >Enable the command tag-switching atm multi-vc, there will also be a several >commands tag-switching atm cos for setting the bandwidth: > >SGP-LSC1(config-if)#tag-switching atm cos ? > available Select weight for class available > control Select weight for class control > premium Select weight for class premium > standard Select weight for class standard > >SGP-LSC1(config-if)#tag-switching atm cos av >SGP-LSC1(config-if)#tag-switching atm cos available ? > <0-100> total weight for all classes must not exceed 100 > >SGP-LSC1(config-if)#tag-switching atm cos available > >regards > >> -----Original Message----- >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bugallo, >> Hernán >> Sent: Wednesday, 31 May 2000 8:04 AM >> To: 'mpls@UU.NET' >> Subject: MPLS-COS settings - >> >> >> >> > Hello, all >> > >> > I have problems to set up COS (muti-vc mode) over my MPLS lab.- >> > I´m using the lastest IOS version. >> > Any body know how can I set this class of service mode on Cisco 7200 >> > routers. >> > >> > Thanks a lot, >> > _\\|//_ >> > ( O-O ) >> > /)~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~(\ >> > // Hernán Bugallo \\ >> > _(( Gcia de Tecnología & Networking ))_ >> > (((\\ /) MetroRED Telecomunicaciones (\ //))) >> > (\\\\\_// Paseo Colon 505 - 5º Piso \\_/////) >> > \ / (Buenos Aires)- ARGENTINA C.P.:(1063) \ / >> > \ / Tel: +(5411) +4344-7700 +(7829) \ / >> > \ _/ oooO \_ / >> > / /~~~~~~~~~~~~~~~~~~( )~~Oooo~~~~~~~~~~~~~~~~\ \ >> > / / \ ( ( ) \ \ >> > / / \_) ) / \ \ >> > (_/ >> > > Jim Guichard CCIE #2069 Network Design Consultant EMEA +44 (0)181 756 8806 Mobile: +44 802 809763 From owner-mpls@UU.NET Wed May 31 12:09: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 MAA15154 for ; Wed, 31 May 2000 12:09: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 QQiroq25992; Wed, 31 May 2000 16:09:13 GMT Received: by mail-control.mail.uu.net id QQiroq27531 for mpls-outgoing; Wed, 31 May 2000 16: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 QQiroq27492 for ; Wed, 31 May 2000 16:08:28 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 QQiroq24587 for ; Wed, 31 May 2000 12:07:13 -0400 (EDT) Received: from nero.doit.wisc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQiroq24555 for ; Wed, 31 May 2000 16:07:13 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id LAA03900; Wed, 31 May 2000 11:06:44 -0500 Message-ID: <20000531110643.D3674@doit.wisc.edu> Date: Wed, 31 May 2000 11:06:43 -0500 From: "James R. Leu" To: Jim Guichard , Darren Patterson , Bugallo@cisco.com, =?iso-8859-1?Q?Hern=E1n?= , mpls@UU.NET Subject: Re: MPLS-COS settings - Reply-To: jleu@mindspring.com References: <200005311556.RAA13282@london.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.93.2 In-Reply-To: <200005311556.RAA13282@london.cisco.com>; from Jim Guichard on Wed, May 31, 2000 at 04:54:47PM +0100 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit This is not a public forum for Cisco tech support. Please Take this discussion offline. Thank you, Jim -- James R. Leu On Wed, May 31, 2000 at 04:54:47PM +0100, Jim Guichard wrote: > At 23:45 31/05/2000 +0800, Darren Patterson wrote: > > > >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bugallo, > >> Hernán > >> Sent: Wednesday, 31 May 2000 8:04 AM > >> To: 'mpls@UU.NET' > >> Subject: MPLS-COS settings - > >> > >> From owner-mpls@UU.NET Wed May 31 12:13: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 ESMTP id MAA15255 for ; Wed, 31 May 2000 12:13: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 QQiroq02899; Wed, 31 May 2000 16:13:51 GMT Received: by mail-control.mail.uu.net id QQiroq28468 for mpls-outgoing; Wed, 31 May 2000 16:13: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 QQiroq28461 for ; Wed, 31 May 2000 16:12: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 QQiroq24907 for ; Wed, 31 May 2000 12:09:02 -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 QQiroq25734 for ; Wed, 31 May 2000 16:09:01 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 JAA19157 for ; Wed, 31 May 2000 09:09:10 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA19613 for mpls@uu.net; Wed, 31 May 2000 12:08: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 QQiroq23966 for ; Wed, 31 May 2000 16:05: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 QQiroq24044 for ; Wed, 31 May 2000 12:04:01 -0400 (EDT) Received: from nmg4.csi.cam.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: nmg4.csi.cam.ac.uk [131.111.12.28]) id QQiroq26035 for ; Wed, 31 May 2000 16:04:00 GMT Received: from mjc64 by nmg4.csi.cam.ac.uk with local (Exim 3.13 #1) id 12xAyB-00000q-00; Wed, 31 May 2000 17:03:47 +0100 From: Martin Cooper To: Sean Doran Cc: mpls@UU.NET Subject: MPLS Performance analysis..... Message-Id: Date: Wed, 31 May 2000 17:03:47 +0100 Sender: owner-mpls@UU.NET Precedence: bulk Sean Doran writes: > Several people write: > > > [lots of commentary about how wonderful MPLS is at making forwarding fast] > > You are analysing the performance of MPLS using the wrong metric. > I think MPLS performs exactly as intended. > Ipsilon basically died, and not even Nokia could revive it. > UUNET found a new layer-2 religion, essentially killing backbone ATM. > Many companies are distracted from actually learning how to do IP routing. > > Score: MPLS 3, Rest Of World 0. As a relative newcomer to the church of MPLS (I have read the prolific works-in-progress of AWD at any rate...), it seems to me that the alleged performance benefits are not so much supposed to be found in the label-switching over packet switching paradigm-shift per se, but in the de- coupling of end-to-end path-selection from the extremely dynamic hop-by-hop routing information, and the more stable re-routing of end-to-end constraint-based paths thus enabled (but without ATMs slow-moving standardisation process and bandwidth-overhead related baggage). On the other hand, destination-prefix based IP routing is quintessentially a hop-by-hop algorithm that doesn't concern itself with end-to-end constraint-based path- selection bar a few TOS bits, so maybe you care not about CBPS? M. From owner-mpls@UU.NET Wed May 31 12:31: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 ESMTP id MAA15861 for ; Wed, 31 May 2000 12:31:48 -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 QQiros11718; Wed, 31 May 2000 16:31:47 GMT Received: by mail-control.mail.uu.net id QQiros00412 for mpls-outgoing; Wed, 31 May 2000 16:31: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 QQiros00370 for ; Wed, 31 May 2000 16:31: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 QQiros24400 for ; Wed, 31 May 2000 12:30:34 -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 QQiros10695 for ; Wed, 31 May 2000 16:30: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 JAA04950; Wed, 31 May 2000 09:30: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 MAA19672; Wed, 31 May 2000 12:30:28 -0400 (EDT) Message-Id: <200005311630.MAA19672@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Eric Gray cc: "'rraszuk@cisco.com'" , David Charlap , mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques In-reply-to: Your message of Tue, 30 May 2000 18:09:57 -0700. <9A564CC874B5D3118FB9009027B0A6622D7D4B@ICARIAN> 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, 31 May 2000 12:30:27 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk EricGray> All of these things are things that exist and can be supported EricGray> using ATM (for example). Yet people you're talking to want them EricGray> using MPLS. Perhaps the unified control plane issue is not as EricGray> orthogonal as you think? There are a number of reasons for preferring MPLS to ATM that don't have much to do with the control plane: ATM's cell-switching overhead, ATM's scalability problems having to do with lack of multipoint-to-point capability, the scalability problems of having to have n**2 connections among the n routers on the ATM network, ATM's dependence on a particular data link layer, the inability of most ATM switches to handle native IP packets at all, etc. IMHO, it's the scaling issues rather than the more abstract "unified control plane" issues which are driving the market. Many of the things which can in theory be done with ATM are difficult to do in practice because of the scaling limitations. But I would agree that there are also important reasons that do have to do with unifying the control plane: I think the need to support an ATM routing and addressing infrastructure which is independent from the IP routing and addressing infrastructure is a problem, one which MPLS doesn't have. I don't know though how much the customers really care about this. Some folks have made a fetish out of this drive for a unified control plane, arguing that what is really needed is the one true grand unified protocol that does absolutely everything. I think what Robert is saying is that this fetish is not something which derives from customer needs. From owner-mpls@UU.NET Wed May 31 13:34:00 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 NAA17492 for ; Wed, 31 May 2000 13:34:00 -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 QQirow27157; Wed, 31 May 2000 17:33:58 GMT Received: by mail-control.mail.uu.net id QQirow13187 for mpls-outgoing; Wed, 31 May 2000 17:33: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 QQirow13165 for ; Wed, 31 May 2000 17:33:27 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 QQirow06343 for ; Wed, 31 May 2000 13:33:18 -0400 (EDT) Received: from domino.netia.pl by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: domino.netia.pl [195.114.160.130]) id QQirow26634 for ; Wed, 31 May 2000 17:33:17 GMT Message-ID: To: rraszuk@cisco.com Cc: "mpls" Subject: Re:Re: MPLS - ATM interworking? From: "Andrzej Czerczak" Date: Wed, 31 May 2000 19:33:13 +0200 X-MIMETrack: Serialize by Router on WaWarNotes/HeadQ(Release 5.0.3 (Intl)|21 March 2000) at 2000-05-31 19:33:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Robert, First of all thanks for your comments. >Have you read draft MPLS Support of Differentiated Services >draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN >(explicit congestion notification) on a per LSP basis using the EXP bits >in the shim header ? Currently this is the most attractive option, but I > am not aware of any implementation support this today. a) Document draft-ietf-mpls-diff-ext-04.txt does not not define the usage of ECN. b) Taking into account label merging capabilites of LSRs, how can determine to which ingress LSP to to send Congestion Notification? c) Where can I find: Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS", draft-ietf-mpls-ecn-00.txt? What I'd like to say is, that at least during first phases of implementations (before entire infrastructure will become IP) interworking of MPLS core and ATM edge will be important, but I could not find a proposal of how to do interworking between them. Andrzej From owner-mpls@UU.NET Wed May 31 13:47: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 NAA17880 for ; Wed, 31 May 2000 13:47:12 -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 QQirox06531; Wed, 31 May 2000 17:47:09 GMT Received: by mail-control.mail.uu.net id QQirox13829 for mpls-outgoing; Wed, 31 May 2000 17:46: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 QQirox13821 for ; Wed, 31 May 2000 17:46: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 QQirox12152 for ; Wed, 31 May 2000 13:46:05 -0400 (EDT) Received: from domino.netia.pl by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: domino.netia.pl [195.114.160.130]) id QQirox05587 for ; Wed, 31 May 2000 17:46:04 GMT Subject: Re:Re: MPLS - ATM interworking? To: rraszuk@cisco.com Cc: mpls@UU.NET From: "Andrzej Czerczak" Date: Wed, 31 May 2000 19:46:01 +0200 Message-ID: X-MIMETrack: Serialize by Router on WaWarNotes/HeadQ(Release 5.0.3 (Intl)|21 March 2000) at 2000-05-31 19:46:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Robert, First of all thanks for your comments. >Have you read draft MPLS Support of Differentiated Services >draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN >(explicit congestion notification) on a per LSP basis using the EXP bits >in the shim header ? Currently this is the most attractive option, but I > am not aware of any implementation support this today. a) Document draft-ietf-mpls-diff-ext-04.txt does not not define the usage of ECN. b) Taking into account label merging capabilites of LSRs, how can determine to which ingress LSP to to send Congestion Notification? c) Where can I find: Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS", draft-ietf-mpls-ecn-00.txt? What I'd like to say is, that at least during first phases of implementations (before entire infrastructure will become IP) interworking of MPLS core and ATM edge will be important, but I could not find a proposal of how to do interworking between them. Andrzej From owner-mpls@UU.NET Wed May 31 14:44: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 OAA19953 for ; Wed, 31 May 2000 14:44: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 QQirpa11902; Wed, 31 May 2000 18:44:03 GMT Received: by mail-control.mail.uu.net id QQirpa25874 for mpls-outgoing; Wed, 31 May 2000 18:43: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 QQirpa25869 for ; Wed, 31 May 2000 18:43:12 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 QQirpa20335 for ; Wed, 31 May 2000 14:41:47 -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 QQirpa15440 for ; Wed, 31 May 2000 18:41:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA24298 for mpls@uu.net; Wed, 31 May 2000 14:41:45 -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 QQirpa25833 for ; Wed, 31 May 2000 18:41: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 QQirpa22348 for ; Wed, 31 May 2000 14:36:56 -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 QQirpa11811 for ; Wed, 31 May 2000 18:36:55 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA05229; Wed, 31 May 2000 11:36:45 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 11:36:45 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405A4@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Andrzej Czerczak'" , rraszuk@cisco.com Cc: mpls@UU.NET Subject: RE: Re: MPLS - ATM interworking? Date: Wed, 31 May 2000 11:33:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFCB2F.2C1C23AA" 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_01BFCB2F.2C1C23AA Content-Type: text/plain; charset="iso-8859-1" Andrzej, 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is attached to this email. 2)Congestion Notification is and end-to-end signal which is meant to be used by TCP. You don't need to know the ingress LSR or even the LSP from which the congested packet is received. The receiver may send the congestion notification to the sender using source IP address, either through another LSP or even through normal IP hop-by-hop routing. Regards, -Shahram >-----Original Message----- >From: Andrzej Czerczak [mailto:Andrzej_Czerczak/HeadQ@netia.pl] >Sent: Wednesday, May 31, 2000 1:46 PM >To: rraszuk@cisco.com >Cc: mpls@UU.NET >Subject: Re:Re: MPLS - ATM interworking? > > > >Robert, >First of all thanks for your comments. > >>Have you read draft MPLS Support of Differentiated Services >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN >>(explicit congestion notification) on a per LSP basis using >the EXP bits >>in the shim header ? Currently this is the most attractive >option, but I >> am not aware of any implementation support this today. > > > >a) Document draft-ietf-mpls-diff-ext-04.txt does not not >define the usage >of ECN. > >b) Taking into account label merging capabilites of LSRs, how >can determine >to which ingress LSP to to send Congestion Notification? > >c) Where can I find: > >Ramakrishnan et al., "A Proposal to Incorporate ECN in > MPLS", draft-ietf-mpls-ecn-00.txt? > > > >What I'd like to say is, that at least during first phases of >implementations (before entire infrastructure will become IP) >interworking >of MPLS core and ATM edge will be important, but I could not find a >proposal of how to do interworking between them. > > > >Andrzej > > > > > > ------_=_NextPart_000_01BFCB2F.2C1C23AA Content-Type: text/plain; name="draft-mpls-ecn-00.txt" Content-Disposition: attachment; filename="draft-mpls-ecn-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force K. K. Ramakrishnan, AT&T = Research INTERNET DRAFT Sally Floyd, = ACIRI draft-mpls-ecn-00.txt Bruce Davie, = Cisco June = 1999 Expires: Dec = 1999 A Proposal to Incorporate ECN in MPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract We propose the addition of ECN to MPLS switching. ECN enables end- end congestion control without necessarily depending on packet loss as the sole indicator of congestion. The proposal suggests having a single bit in the MPLS header to indicate ECN, and simple signaling at the time of setting up the LSP (Label Switched Path) for indication of ECN capability. This allows for incorporation of ECN = in MPLS in a coordinated manner with IP and also in a backwards compatible fashion. Ramakrishnan et. al [Page = 1] draft-mpls-ecn A Proposal to Incorporate ECN in MPLS June = 1999 1. Introduction. ECN (Explicit Congestion Notification) [ECN] has been proposed as an addition to IP to provide an indication of congestion. With the addition of active queue management (e.g., RED [RFC2309]) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a Congestion Experienced (CE) bit in the IP header of packets from ECN-capable transport protocols. Active queue management mechanisms in the router may use one of several methods for indicating congestion to end-nodes. One is to = use packet drops, as is currently done. However, active queue = management allows the router to separate policies of queueing or dropping packets from the policies for indicating congestion. Thus, active queue management allows routers to use the Congestion Experienced (CE) bit in a packet header as an indication of congestion, instead of relying solely on packet drops. Active queue management not only avoids packet losses for congestion indication, but also attempts to control the average queue sizes at routers by using ECN or packet drops to provide an indication of the onset of congestion. With the cooperation of transport protocols, = the indication of incipient congestion may be used to minimize significant queue build-up and thus reduce queueing delays, variability in queueing delay and additional packet losses. With ECN-capable routers and transport protocols, packet drops are not required for these indications of congestion. Applications that are sensitive to the delay or loss of one or more individual packets are expected to benefit from the use of ECN. Interactive traffic such as telnet, web-browsing, and transfer of audio and video data can be sensitive to packet losses (using an unreliable data delivery transport such as UDP) or to the increased latency of the packet caused by the need to retransmit the packet after a loss (for reliable data delivery such as TCP). The use of = ECN by end-systems and participation of intermediate nodes in the = network in ECN would potentially help these applications. 1.1. Motivation for use of ECN with MPLS Many of the features of MPLS, such as traffic engineering (to take advantage of multiple paths and balance the load on them), explicit routing and QoS routing are motivated by the desire to improve the overall performance of an IP network. MPLS also aims to support the QoS models that are available for IP, such as Integrated Services = and Differentiated Services. Ramakrishnan et. al [Page = 2] draft-mpls-ecn A Proposal to Incorporate ECN in MPLS June = 1999 Given the motivation to provide better performance and QoS assurances, we believe it is desirable that we utilize techniques that help manage queueing better, and minimize losses. Label Switched Routers (LSRs) are already expected to incorporate active queue management methods such as RED. As a result, the incremental effort involved in the addition of ECN is likely to be small in many cases. We believe the benefits from ECN of better overall = performance for a wide range of applications because of reduced packet loss (especially those using non-TCP transports) and reduced queueing delay is sufficiently significant. Furthermore, there seems to be no reasons for LSRs to lack this capability as it becomes available in other (non-label switched) IP routers. 2. Overview of ECN This section briefly outlines the addition of ECN to the IP protocol as specified in RFC 2481. RFC 2481 specifies two bits in the ECN field in the IP header, the ECN-Capable Transport (ECT) bit and the Congestion Experienced (CE) bit. The ECT bit is set by the data sender to indicate that the end-points of the transport protocol are ECN-capable. The CE bit is set by the router to indicate congestion to the end nodes. Routers that have a packet arriving at a full queue would drop the packet, just as they do now. RFC 2481 also specifies the use of ECN in the TCP transport = protocol. For an ECN-capable TCP connection, when the TCP receiver receives a data packet with the CE bit set, the receiver conveys that information to the TCP sender using a bit in the TCP header. TCP senders react to the congestion indication by decreasing their congestion window. Thus, the early indication of congestion allows the sender TCP to reduce the load placed on the network, without the need to drop a packet. Because the use of ECN at the transport = level is not affected by the MPLS header, this aspect of ECN is not discussed further in this document. 2.1. Opportunities to take Advantage of ECN In the past, it has often been the desire of datalink layers to provide a congestion indication to the end-systems, so that end- system transport protocols may react by reducing the load. However, even though Frame-Relay and ATM have had an indicator for congestion indication, the match with the ECN indication has not been ideal. In these cases, marking the congestion indication was left to implementation or was based on instantaneous queue occupancy. This was the case with both Forward Explicit Congestion Notification (FECN) in Frame-Relay networks and Explicit Forward Congestion Indication (EFCI) in ATM. Ramakrishnan et. al [Page = 3] draft-mpls-ecn A Proposal to Incorporate ECN in MPLS June = 1999 With MPLS LSRs, it is expected that they will implement the algorithms needed to determine an average queue size, as specified with RED and other active queue management algorithms. Thus, a congestion indication in MPLS based on the average queue size will = be better matched to the ECN semantics. We thus propose that the same policies for indicating congestion be used in LSRs. The egress LSR = of a label switched path (LSP) would then "fold" the congestion indication seen in the MPLS header into the forwarded IP packet. Thus, each of the LSRs also now has a means of indicating congestion to the end-systems. 3. A One-Bit ECN Field in the MPLS Header As described in Section 2, RFC 2481 uses a two-bit ECN field for IP. The original ECN proposal in [F94] discussed both a one-bit and a two-bit implementation for ECN in the IP header. This document proposes a one-bit ECN field for the MPLS header, because of our desire to conserve space in the header, and the ability to use signaling at the time of setting up the label switched path (LSP) to overcome the need for the second bit. We propose that this bit = should be one of the three experimental bits defined in [R99]. We note that by using only one of these bits, we leave two available for = diff-serv drop preference, as described in [LeF99]. The ECN field has to encode three separate states: not ECT; ECT but not CE; and ECT with CE. The two-bit implementation specified in = RFC 2481 implements these three separate states using two bits in the IP ECN field, the ECT bit and the CE bit. Section 9.2 of [F94] also discusses a one-bit approach where the two functions of ECT and CE are overloaded in a single bit. For this bit, one value indicates "ECT but not CE", and the other value indicates "either not ECT, or ECT with CE". 4. Role of Ingress and Egress MPLS LSRs When the LSP is set up, the ingress and egress LSRs use signaling to indicate whether or not to participate in ECN. We envisage this as an extension to any of the existing MPLS label distribution mechanisms such as LDP or RSVP. Such signaling allows ingress and egress LSRs on an LSP to determine if all LSRs along the LSP are capable of supporting ECN. Details of these signaling mechanisms constitute work in progress and will be described in a later version of this draft. The ingress LSR observes the IP ECN field in a packet to set the = MPLS ECN field in accordance with the following table (Table 1): Ramakrishnan et. al [Page = 4] draft-mpls-ecn A Proposal to Incorporate ECN in MPLS June = 1999 ECN-Capable IP ECN Field MPLS LSP? MPLS ECN Field ------------ --------- -------------- (1) Not ECT YES Not ECT, or ECT+CE (2) ECT, not CE YES ECT, not CE (3) ECT, CE YES ECT, not CE (4) --- NO Not ECT, or ECT+CE Table 1.: Translation from the IP ECN Field to the MPLS ECN = Field at Ingress. An ingress LSR using ECN would set the MPLS ECN field to "ECT but = not CE" when the IP ECN field indicates "ECT", whether or not the CE bit was set in the IP ECN field, and would have to *always* set the MPLS ECN field to "either not ECT, or ECT with CE" otherwise. Similarly, an ingress LSR not using ECN would *always* set the MPLS ECN field = to "either not ECT, or ECT with CE", whether or not the IP ECN field = was set to "ECT". When the packet reaches the end of the LSP, the egress LSR now has = to "fold" the MPLS ECN field back into the IP ECN header of the packet. The egress LSR knows whether the LSP is ECN-Capable or not. On the received packet, the MPLS header indicates whether congestion was experienced or not. The main row to examine in the following table (Table 2) is Row 5. It shows that the received packet has the ECN field in the MPLS header indicating congestion or that the packet flowed over a non-ECN capable LSP. However, because of the signaling at the time the LSP was set up, we know that the MPLS LSP was ECN capable. In addition, the IP ECN field was set to "ECT". Thus, the MPLS ECN field is interpreted as indicating ECT+CE (congestion was experienced in the MPLS LSP). The IP ECN field of the packet = received indicates that the transport is ECN capable (ECT) and that it had = not experienced congestion earlier (not CE) before entering the LSP. = The IP ECN field of the forwarded packet therefore has to be set by the egress LSR to indicate congestion (CE). Thus, congestion experienced in the MPLS LSP is now successfully carried in the IP ECN field onwards to the end-system. Row 1 of Table 2 shows that the MPLS ECN field indicates no congestion was experienced in the LSP. Thus, the IP ECN field of the packet is left unchanged. Similarly, when the original IP ECN field indicates the transport is not ECN capable or already indicates congestion was experienced, then the the IP ECN field of the packet is left unchanged. Ramakrishnan et. al [Page = 5] draft-mpls-ecn A Proposal to Incorporate ECN in MPLS June = 1999 MPLS Old IP ECN-Capable New IP ECN Field ECN Field MPLS LSP? ECN Field ------------ --------- ----- --------- (1) ECT, not CE --- --- Unchanged. (2) not ECT, or ECT+CE Not ECT --- Unchanged. (3) not ECT, or ECT+CE ECT, CE --- Unchanged. (4) not ECT, or ECT+CE ECT, not CE NO Not possible. (5) not ECT, or ECT+CE ECT, not CE YES ECT, CE Table 2.: Translation from MPLS ECN Field back to IP ECN Field at Egress The reason that the use of a one-bit ECN field in the MPLS header does not introduce ambiguity is that it is accompanied by the original two-bit IP ECN field, along with a prior agreement about whether the MPLS LSP was or was not ECN-Capable. 5. Role of Switches in marking ECN MPLS ECN Field ECN-Capable MPLS MPLS LSP? Congestion Action -------------- ------------- --------------- (1) Not ECT, or ECT+CE No Packet dropped. (2) Not ECT, or ECT+CE Yes Packet dropped. (3) ECT, not CE Yes MPLS ECN Field changed = to "not ECT, or ECT+CE" (4) ECT, not CE No Not Possible Table 3.: Effect of MPLS ECN Field on Congestion Action at = Switch. The congestion action taken at an LSR is based on the knowledge at the LSR of whether or not the LSP is ECN capable. This is known through signaling. If the LSP is not ECN capable, the packet is dropped as per the existing rules followed at the LSR (i.e., based = on RED). If the LSP is ECN capable, and the MPLS ECN field shows that the packet is ECN-capable but has not experienced congestion = upstream on the LSP, then the MPLS ECN field is changed to indicate = congestion (i.e., the encoding of "Not ECT, or ECT+CE"). If the packet has indeed experienced congestion upstream, the packet is dropped. This is an inescapable consequence of the single-bit MPLS ECN field combined with internal LSRs not looking at the IP ECN field. One functional limitation of the one-bit ECN implementation for MPLS is that once an LSR "sets" the CE state in an ECT MPLS packet, subsequent LSRs along the MPLS path cannot determine whether the packet is or is not ECN-Capable (without using the IP ECN field). Although LSRs may be able to look at the IP header (potentially with some performance impact), we do not require it. Thus, subsequent Ramakrishnan et. al [Page = 6] draft-mpls-ecn A Proposal to Incorporate ECN in MPLS June = 1999 LSRs would have to drop that packet in order to indicate congestion to the end nodes, rather than using ECN. 6. Role of Signaling to communicate ECN capability One requirement for the one-bit ECN implementation for MPLS is that the egress LSR needs information from the ingress LSR in order to determine how to interpret the MPLS ECN Field. In particular, for a packet at the egress of the MPLS LSP whose IP ECN field indicates "ECT, not CE" and whose MPLS ECN field indicates "not ECT, or ECT+CE", the egress LSR of the MPLS LSP has to be able to determine whether to set the CE bit in the forwarded packet's IP ECN field = upon decapsulation. To do this, the egress LSR has to know whether or = not the ingress LSR originally set the MPLS ECN field to "ECT but not CE". This can be determined using information in the IP ECN header, assuming that the ingress LSR has previously informed the egress LSR whether it is or is not using ECN. Thus, an ingress and egress LSR would have to negotiate whether or not they are using ECN-Capability for the MPLS tunnel. Note only the ingress and egress LSRs have to examine the IP ECN header of the packet. Based on the negotiation at the time the LSP is set up, the ingress LSR knows what the MPLS ECN field should be set to on incoming packets, especially for downstream allocation of the MPLS LSP: if = the egress LSR is ECN capable and the LSRs upstream are also ECN = capable, then the ingress LSR knows to initially set the MPLS ECN field to "ECT but not CE" when the IP ECN field indicated "ECT". If the LSRs in the MPLS LSP are not ECN capable, then the ingress LSR always = sets the MPLS ECN bit to "not ECT or ECT+CE". The egress LSR, knowing = that the LSP is ECN capable through signaling, folds the MPLS ECN field into the outgoing IP ECN field according to Table 2. 7. Summary We have proposed that MPLS LSRs exploit the capability provided in Explicit Congestion Notification (ECN) to provide an early = indication of congestion without depending solely on packet dropping as a means of congestion indication. Given that MPLS LSRs are likely to use = some form of active queue management, the use of ECN potentially improves the service obtained in an MPLS LSP with respect to packet loss and end-end delay. The proposal requires the use of a single bit in the MPLS header for indicating congestion, and signaling while setting = up the LSP. The signaling provides the indication to the ingress and egress LSRs the action they need to take with respect to ECN: the initialization of the MPLS ECN field at the ingress and the folding of the MPLS ECN indication into the forwarded IP packet's ECN field at the egress. Ramakrishnan et. al [Page = 7] draft-mpls-ecn A Proposal to Incorporate ECN in MPLS June = 1999 8. References [ECN] The ECN Web Page, URL "http://www.aciri.org/floyd/ecn.html". [F94] Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23. URL "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z". [FBR99] Floyd, Black, and Ramakrishnan, IPsec Interactions with ECN, internet-draft draft-ipsec-ecn-00.txt, April 1999. URL "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ipsec- ecn-00.txt". [LeF99] Le Faucheur, F., et al., "MPLS Support of Differentiated Services over PPP links", internet draft, = draft-lefaucheur-mpls-diff- ppp-00.txt, June 1999. URL "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-lefaucheur- mpls-diff-ppp-00.txt" [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, = C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998. [RFC2481] K. K. Ramakrishnan and Sally Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999. URL "ftp://ftp.isi.edu/in-notes/rfc2481.txt". [R99] Rosen, E., et al., "MPLS Label Stack Encoding", internet = draft, draft-ietf-mpls-label-encaps-04.txt, April 1999. URL "http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-mpls- label-encaps-04.txt". 9. Security Considerations Security considerations are equivalent to those for normal IP ECN = and ECN with IPsec, which are discussed extensively in [FBR99]. AUTHORS' ADDRESSES Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI) Phone: +1 (510) 642-4274 x189 Email: floyd@aciri.org URL: http://www-nrg.ee.lbl.gov/floyd/ Ramakrishnan et. al [Page = 8] draft-mpls-ecn A Proposal to Incorporate ECN in MPLS June = 1999 K. K. Ramakrishnan AT&T Labs. Research Phone: +1 (973) 360-8766 Email: kkrama@research.att.com URL: http://www.research.att.com/info/kkrama Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: bsd@cisco.com This draft was created in June 1999. It expires December 1999. Ramakrishnan et. al [Page = 9] ------_=_NextPart_000_01BFCB2F.2C1C23AA-- From owner-mpls@UU.NET Wed May 31 15:06: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 ESMTP id PAA20694 for ; Wed, 31 May 2000 15:06: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 QQirpc26777; Wed, 31 May 2000 19:06:19 GMT Received: by mail-control.mail.uu.net id QQirpc06152 for mpls-outgoing; Wed, 31 May 2000 19:05: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 QQirpc06146 for ; Wed, 31 May 2000 19:05: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 QQirpc28271 for ; Wed, 31 May 2000 15:02:21 -0400 (EDT) Received: from sean.ebone.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sean.ebone.net [195.158.227.211]) id QQirpc00958 for ; Wed, 31 May 2000 19:02:21 GMT Received: by sean.ebone.net (Postfix, from userid 1113) id BCF0A882; Wed, 31 May 2000 21:02:19 +0200 (CEST) To: Martin Cooper Cc: mpls@UU.NET Subject: Re: MPLS Performance analysis..... References: From: Sean Doran Date: 31 May 2000 21:02:19 +0200 Message-ID: <52u2feczlw.fsf@sean.ebone.net> Lines: 77 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Martin Cooper writes: > the de-coupling of end-to-end path-selection from the > extremely dynamic hop-by-hop routing information MPLS is a condensation of a GRE-like data-in-IP encapsulation header, plus some related control planes to lay out an SSR (strict source route) across a routed, packet-switched network. Perhaps it would be more precise to describe it as an encapsulation header which is regenerated at each hop, rather like a GRE-like packet whose header on the "head end" (or ingress) router has an destination address of a loopback address on an immediate neighbour router. This second router in the path removes the encapsulation header and then re-encapsulates the data in a new GRE-like header with a loopback address of the next router towards the "tail end" (or egress) router, which will actually process the data part. Now use RSVP to coordinate the choice from a number of loopback addresses to build a path out of a concatenation of these tunnels, and tadah, you get a nastygram from one of the high priests of MPLS that you have just reinvented MPLS only with alot of extra bytes of overhead per packet. When you point that the IP overhead lets one choose between doing SSR ER and two different modes of LSR ER (both of which require router cooperation -- one mode requires the decap-reencap dance above, the other merely processing of the LSRR option), you may end up in a nasty fight, being reminded that one of the reasons people don't like ATM is that there is lots of overhead. Of course, the model for VPNs is relatively little traffic at much higher than normal cost compared to best-efforts Internet transit connectivity, so the overhead doesn't seem to matter much. Also, not everyone needs to do heavy duty TE on huge-volume traffic, and thus can choose the operational overhead of deploying MPLS versus the per-packet overhead of a GRE-like encapsulation header. Another neat detail that annoys MPLS folks is that if you do not keep your encapsulation header's IP ttl tiny, you don't have to do an RSVP song and dance or play the pre-provisioned-back-up-path game, and suchlike. Great for VPNs, where you don't really need to do ER at all, you just want to isolate the inside data from the routers in the "core". > the more stable re-routing of end-to-end > constraint-based paths thus enabled You are emulating a circuit-switched network on a packet-switched one, no matter how you slice things; if your underlying logical layer in a hybrid MPLS/IP core changes, both MPLS and IP have to reconverge, and this is generally not so ships-in-the-night (i.e., typically MPLS is reliant upon the topology discovery protocol IP uses). Extra stability here can only come through a time-to-converge trade-off. As some else said: MPLS is L3, not L2. > On the other hand, destination-prefix based IP routing > is quintessentially a hop-by-hop algorithm How is MPLS any different? >(but without ATMs slow-moving standardisation > process and bandwidth-overhead related baggage). Ah, you're new to the IETF, too? Welcome! Sean. From owner-mpls@UU.NET Wed May 31 15:16: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 ESMTP id PAA20938 for ; Wed, 31 May 2000 15:16: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 QQirpd10448; Wed, 31 May 2000 19:16:24 GMT Received: by mail-control.mail.uu.net id QQirpd06895 for mpls-outgoing; Wed, 31 May 2000 19:16: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 QQirpd06883 for ; Wed, 31 May 2000 19:15: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 QQirpd27296 for ; Wed, 31 May 2000 15:15:27 -0400 (EDT) Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQirpd03328 for ; Wed, 31 May 2000 19:15:26 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 May 2000 12:13:08 -0700 Message-ID: <337055FBC675D311A85D00508B5A9C4F2542C4@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'Shahram Davari'" Cc: mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Date: Wed, 31 May 2000 12:13:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCB34.40E32D52" 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_01BFCB34.40E32D52 Content-Type: text/plain Shahram, the draft-ietf-mpls-ecn-00.txt does not say anything about ECN usage and applications, but only about ECN support and definition in an MPLS network, the things are quite different. So, I have the same question: where I can find Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS", draft-ietf-mpls-ecn-00.txt? Also, I do believe that the ECN in an MPLS network works on resource types (LSPs) quite different than native IP flows. So, the source address is not that useful here, albeit in an ECN schema in pure IP networks. ECN in an MPLS network is supposed to signal congestion in an edge-to-edge fashion (different from end-to-end) where the LERs could cooperate on that. Absolutely, I want to associate LSPs with congestion dynamics to eventually slow them down. How can I do that? That's the question. Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 31, 2000 11:34 AM > To: 'Andrzej Czerczak'; rraszuk@cisco.com > Cc: mpls@UU.NET > Subject: RE: Re: MPLS - ATM interworking? > > Andrzej, > > 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is attached to > this email. > > 2)Congestion Notification is and end-to-end signal which is meant to be > used > by TCP. You don't need to know the ingress LSR or even the LSP from which > the congested packet is received. The receiver may send the congestion > notification to the sender using source IP address, either through another > LSP or even through normal IP hop-by-hop routing. > > Regards, > -Shahram > > > > > >-----Original Message----- > >From: Andrzej Czerczak [mailto:Andrzej_Czerczak/HeadQ@netia.pl] > >Sent: Wednesday, May 31, 2000 1:46 PM > >To: rraszuk@cisco.com > >Cc: mpls@UU.NET > >Subject: Re:Re: MPLS - ATM interworking? > > > > > > > >Robert, > >First of all thanks for your comments. > > > >>Have you read draft MPLS Support of Differentiated Services > >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN > >>(explicit congestion notification) on a per LSP basis using > >the EXP bits > >>in the shim header ? Currently this is the most attractive > >option, but I > >> am not aware of any implementation support this today. > > > > > > > >a) Document draft-ietf-mpls-diff-ext-04.txt does not not > >define the usage > >of ECN. > > > >b) Taking into account label merging capabilites of LSRs, how > >can determine > >to which ingress LSP to to send Congestion Notification? > > > >c) Where can I find: > > > >Ramakrishnan et al., "A Proposal to Incorporate ECN in > MPLS", draft-ietf-mpls-ecn-00.txt? > > > > > > > >What I'd like to say is, that at least during first phases of > >implementations (before entire infrastructure will become IP) > >interworking > >of MPLS core and ATM edge will be important, but I could not find a > >proposal of how to do interworking between them. > > > > > > > >Andrzej > > > > > > > > > > > > > << File: draft-mpls-ecn-00.txt >> ------_=_NextPart_001_01BFCB34.40E32D52 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Re: MPLS - ATM interworking?

Shahram,

    the draft-ietf-mpls-ecn-00.txt does = not say anything about ECN usage and applications, but only about ECN = support and definition in an MPLS network, the things are quite = different. So, I have the same question: where I can find Ramakrishnan = et al., "A Proposal to Incorporate ECN in MPLS", = draft-ietf-mpls-ecn-00.txt?

    Also, I do believe that the ECN in an = MPLS network works on resource types (LSPs) quite different than native = IP flows. So, the source address is not that useful here, albeit in an = ECN schema in pure IP networks.

    ECN in an MPLS network is supposed to = signal congestion in an edge-to-edge fashion (different from = end-to-end) where the LERs could cooperate on that.

    Absolutely, I want to associate LSPs = with congestion dynamics to eventually slow them down. How can I do = that? That's the question.

Sergio

    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   Shahram Davari = [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:   Wednesday, May 31, 2000 11:34 AM
    To:     'Andrzej Czerczak'; rraszuk@cisco.com
    Cc:     mpls@UU.NET
    Subject:       = RE: Re: MPLS - ATM = interworking?

    Andrzej,

    1)ECN usage is defined in = draft-ietf-mpls-ecn-00.txt, which is attached to
    this email.

    2)Congestion Notification is and = end-to-end signal which is meant to be used
    by TCP. You don't need to know = the ingress LSR or even the LSP from which
    the congested packet is = received. The receiver may send the congestion
    notification to the sender = using source IP address, either through another
    LSP or even through normal IP = hop-by-hop routing.

    Regards,
    -Shahram




    >-----Original = Message-----
    >From: Andrzej Czerczak = [mailto:Andrzej_Czerczak/= HeadQ@netia.pl]
    >Sent: Wednesday, May 31, = 2000 1:46 PM
    >To: = rraszuk@cisco.com
    >Cc: mpls@UU.NET
    >Subject: Re:Re: MPLS - ATM = interworking?
    >
    >
    >
    >Robert,
    >First of all thanks for = your comments.
    >
    >>Have you read draft = MPLS Support of Differentiated Services
    >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to = use the ECN
    >>(explicit congestion = notification) on a per LSP basis using
    >the EXP bits
    >>in the shim header ? = Currently this is the most attractive
    >option, but I
    >> am not aware of any = implementation support this today.
    >
    >
    >
    >a) Document = draft-ietf-mpls-diff-ext-04.txt does not not
    >define the usage
    >of ECN.
    >
    >b) Taking into account = label merging capabilites of LSRs, how
    >can determine
    >to which ingress LSP to to = send Congestion Notification?
    >
    >c) Where can I find:
    >
    >Ramakrishnan et al., = "A Proposal to Incorporate ECN in
    >   MPLS", = draft-ietf-mpls-ecn-00.txt?

    >
    >
    >
    >What I'd like to say is, = that at least during first phases of
    >implementations (before = entire infrastructure will become IP)
    >interworking
    >of MPLS core and ATM edge = will be important, but I could not find a
    >proposal of how to do = interworking between them.
    >
    >
    >
    >Andrzej
    >
    >
    >
    >
    >
    >
     << File: = draft-mpls-ecn-00.txt >>

------_=_NextPart_001_01BFCB34.40E32D52-- From owner-mpls@UU.NET Wed May 31 15:22: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 PAA21223 for ; Wed, 31 May 2000 15:22: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 QQirpd08501; Wed, 31 May 2000 19:22:25 GMT Received: by mail-control.mail.uu.net id QQirpd07304 for mpls-outgoing; Wed, 31 May 2000 19:21: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 QQirpd07294 for ; Wed, 31 May 2000 19:21: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 QQirpd28588 for ; Wed, 31 May 2000 15:21:19 -0400 (EDT) Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQirpd07662 for ; Wed, 31 May 2000 19:21:19 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 May 2000 12:19:00 -0700 Message-ID: <337055FBC675D311A85D00508B5A9C4F2542C5@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'Shahram Davari'" Cc: mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Date: Wed, 31 May 2000 12:18:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCB35.12DF6A00" 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_01BFCB35.12DF6A00 Content-Type: text/plain; charset="iso-8859-1" Sorry, in my previous e-mail I meant draft-ietf-mpls-diff-ext-04.txt does not say anything about ECN ..., the problem is that I have not received any draft-ietf-mpls-ecn-00.txt. Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: CATANZARITI Sergio FTR&D/TI > [SMTP:sergio.catanzariti@rd.francetelecom.com] > Sent: Wednesday, May 31, 2000 12:13 PM > To: 'Shahram Davari' > Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: RE: Re: MPLS - ATM interworking? > > Shahram, > > the draft-ietf-mpls-ecn-00.txt does not say anything about ECN usage > and applications, but only about ECN support and definition in an MPLS > network, the things are quite different. So, I have the same question: > where I can find Ramakrishnan et al., "A Proposal to Incorporate ECN in > MPLS", draft-ietf-mpls-ecn-00.txt? > > Also, I do believe that the ECN in an MPLS network works on resource > types (LSPs) quite different than native IP flows. So, the source address > is not that useful here, albeit in an ECN schema in pure IP networks. > > ECN in an MPLS network is supposed to signal congestion in an > edge-to-edge fashion (different from end-to-end) where the LERs could > cooperate on that. > > Absolutely, I want to associate LSPs with congestion dynamics to > eventually slow them down. How can I do that? That's the question. > > Sergio > > -------------------------------------------------------------------- > > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 31, 2000 11:34 AM > To: 'Andrzej Czerczak'; rraszuk@cisco.com > Cc: mpls@UU.NET > Subject: RE: Re: MPLS - ATM interworking? > > Andrzej, > > 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is > attached to > this email. > > 2)Congestion Notification is and end-to-end signal which is meant to > be used > by TCP. You don't need to know the ingress LSR or even the LSP from which > the congested packet is received. The receiver may send the congestion > notification to the sender using source IP address, either through another > > LSP or even through normal IP hop-by-hop routing. > > Regards, > -Shahram > > > > > >-----Original Message----- > >From: Andrzej Czerczak [ ] > >Sent: Wednesday, May 31, 2000 1:46 PM > >To: rraszuk@cisco.com > >Cc: mpls@UU.NET > >Subject: Re:Re: MPLS - ATM interworking? > > > > > > > >Robert, > >First of all thanks for your comments. > > > >>Have you read draft MPLS Support of Differentiated Services > >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN > >>(explicit congestion notification) on a per LSP basis using > >the EXP bits > >>in the shim header ? Currently this is the most attractive > >option, but I > >> am not aware of any implementation support this today. > > > > > > > >a) Document draft-ietf-mpls-diff-ext-04.txt does not not > >define the usage > >of ECN. > > > >b) Taking into account label merging capabilites of LSRs, how > >can determine > >to which ingress LSP to to send Congestion Notification? > > > >c) Where can I find: > > > >Ramakrishnan et al., "A Proposal to Incorporate ECN in > > MPLS", draft-ietf-mpls-ecn-00.txt? > > > > > > > > >What I'd like to say is, that at least during first phases of > >implementations (before entire infrastructure will become IP) > >interworking > >of MPLS core and ATM edge will be important, but I could not find a > >proposal of how to do interworking between them. > > > > > > > >Andrzej > > > > > > > > > > > > > << File: draft-mpls-ecn-00.txt >> > ------_=_NextPart_001_01BFCB35.12DF6A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Re: MPLS - ATM interworking?

    Sorry, in my previous e-mail I = meant draft-ietf-mpls-diff-ext-04.txt does not say anything = about ECN ...,
    the problem is that I have not = received any draft-ietf-mpls-ecn-00.txt.

    Sergio


    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   CATANZARITI Sergio FTR&D/TI = [SMTP:sergio.catanzariti@rd.francetelecom.com]
    Sent:   Wednesday, May 31, 2000 12:13 PM
    To:     'Shahram Davari'
    Cc:     mpls@UU.NET; 'Andrzej Czerczak'; = rraszuk@cisco.com
    Subject:       = RE: Re: MPLS - ATM = interworking?

    Shahram, =

            the draft-ietf-mpls-ecn-00.txt does not say anything = about ECN usage and applications, but only about ECN support and = definition in an MPLS network, the things are quite different. So, I = have the same question: where I can find Ramakrishnan et al., "A = Proposal to Incorporate ECN in MPLS", = draft-ietf-mpls-ecn-00.txt?

            Also, I do believe that the ECN in an MPLS network works = on resource types (LSPs) quite different than native IP flows. So, the = source address is not that useful here, albeit in an ECN schema in pure = IP networks.

            ECN in an MPLS network is supposed to signal congestion = in an edge-to-edge fashion (different from end-to-end) where the LERs = could cooperate on that.

            Absolutely, I want to associate LSPs with congestion = dynamics to eventually slow them down. How can I do that? That's the = question.

    Sergio =

            ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior = Project Manager, Technology Integration
    France = Telecom R&D
    1000 = Marina Boulevard Suite 300
    Brisbane CA 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com<= BR> ---------------------------------------------------------= -----------


            -----Original Message-----
    From:=A0=A0 Shahram Davari = [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:=A0=A0 Wednesday, May 31, 2000 11:34 AM
    To:=A0=A0=A0=A0 = 'Andrzej Czerczak'; = rraszuk@cisco.com
    Cc:=A0=A0=A0=A0 = mpls@UU.NET
    Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Re: MPLS - ATM = interworking?

            Andrzej,

            1)ECN usage is defined in = draft-ietf-mpls-ecn-00.txt, which is attached to
    this email.

            2)Congestion Notification is and end-to-end signal = which is meant to be used
    by TCP. You don't need to = know the ingress LSR or even the LSP from which
    the congested packet is = received. The receiver may send the congestion
    notification to the sender = using source IP address, either through another
    LSP or even through normal = IP hop-by-hop routing.

            Regards,
    -Shahram




            >-----Original Message-----
    >From: Andrzej Czerczak = [ <mailto:Andrzej_Czerczak/= HeadQ@netia.pl>]
    >Sent: Wednesday, May 31, = 2000 1:46 PM
    >To: = rraszuk@cisco.com
    >Cc: = mpls@UU.NET
    >Subject: Re:Re: MPLS - = ATM interworking?
    >
    >
    >
    >Robert,
    >First of all thanks for = your comments.
    >
    >>Have you read draft = MPLS Support of Differentiated Services
    >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to = use the ECN
    >>(explicit congestion = notification) on a per LSP basis using
    >the EXP bits
    >>in the shim header ? = Currently this is the most attractive
    >option, but I
    >> am not aware of any = implementation support this today.
    >
    >
    >
    >a) Document = draft-ietf-mpls-diff-ext-04.txt does not not
    >define the usage
    >of ECN.
    >
    >b) Taking into account = label merging capabilites of LSRs, how
    >can determine
    >to which ingress LSP to = to send Congestion Notification?
    >
    >c) Where can I = find:
    >
    >Ramakrishnan et al., = "A Proposal to Incorporate ECN in
    >=A0=A0 MPLS", = draft-ietf-mpls-ecn-00.txt?

            >
    >
    >
    >What I'd like to say is, = that at least during first phases of
    >implementations (before = entire infrastructure will become IP)
    >interworking
    >of MPLS core and ATM = edge will be important, but I could not find a
    >proposal of how to do = interworking between them.
    >
    >
    >
    >Andrzej
    >
    >
    >
    >
    >
    >
    =A0<< File: = draft-mpls-ecn-00.txt >>=20

------_=_NextPart_001_01BFCB35.12DF6A00-- From owner-mpls@UU.NET Wed May 31 15:28: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 PAA21421 for ; Wed, 31 May 2000 15:28: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 QQirpd12486; Wed, 31 May 2000 19:28:12 GMT Received: by mail-control.mail.uu.net id QQirpd07645 for mpls-outgoing; Wed, 31 May 2000 19:27: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 QQirpd07616 for ; Wed, 31 May 2000 19:27:38 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 QQirpd02722 for ; Wed, 31 May 2000 15:27:20 -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 QQirpd18122 for ; Wed, 31 May 2000 19:27:19 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA02425 for mpls@uu.net; Wed, 31 May 2000 15:27:18 -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 QQirpd07534 for ; Wed, 31 May 2000 19:26: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 QQirpd29429 for ; Wed, 31 May 2000 15:26:17 -0400 (EDT) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQirpd17399 for ; Wed, 31 May 2000 19:26:17 GMT Received: from cisco.com (rraszuk-dsl1.cisco.com [10.19.31.90]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA09544; Wed, 31 May 2000 12:25:47 -0700 (PDT) Message-ID: <3935757D.25086E19@cisco.com> Date: Wed, 31 May 2000 13:26:37 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: CATANZARITI Sergio FTR&D/TI CC: "'Shahram Davari'" , mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com Subject: Re: MPLS - ATM interworking? References: <337055FBC675D311A85D00508B5A9C4F2542C5@u-mail.rd.francetelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Just simple yahoo query would do: http://www.ics.forth.gr/ICS/acti/netgroup/documents/mpls/draft-ietf-mpls-ecn-00.txt R. > CATANZARITI Sergio FTR&D/TI wrote: > > Sorry, in my previous e-mail I meant draft-ietf-mpls-diff-ext-04.txt > does not say anything about ECN ..., > the problem is that I have not received any draft-ietf-mpls-ecn-00.txt. > > Sergio > > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > -----Original Message----- > From: CATANZARITI Sergio FTR&D/TI > [SMTP:sergio.catanzariti@rd.francetelecom.com] > Sent: Wednesday, May 31, 2000 12:13 PM > To: 'Shahram Davari' > Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: RE: Re: MPLS - ATM interworking? > > Shahram, > > the draft-ietf-mpls-ecn-00.txt does not say anything about ECN > usage and applications, but only about ECN support and definition in an > MPLS network, the things are quite different. So, I have the same > question: where I can find Ramakrishnan et al., "A Proposal to > Incorporate ECN in MPLS", draft-ietf-mpls-ecn-00.txt? > > Also, I do believe that the ECN in an MPLS network works on > resource types (LSPs) quite different than native IP flows. So, the > source address is not that useful here, albeit in an ECN schema in pure > IP networks. > > ECN in an MPLS network is supposed to signal congestion in an > edge-to-edge fashion (different from end-to-end) where the LERs could > cooperate on that. > > Absolutely, I want to associate LSPs with congestion dynamics to > eventually slow them down. How can I do that? That's the question. > > Sergio > > > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 31, 2000 11:34 AM > To: 'Andrzej Czerczak'; rraszuk@cisco.com > Cc: mpls@UU.NET > Subject: RE: Re: MPLS - ATM interworking? > > Andrzej, > > 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is > attached to > this email. > > 2)Congestion Notification is and end-to-end signal which is > meant to be used > by TCP. You don't need to know the ingress LSR or even the LSP from > which > the congested packet is received. The receiver may send the congestion > notification to the sender using source IP address, either through > another > LSP or even through normal IP hop-by-hop routing. > > Regards, > -Shahram > > >-----Original Message----- > >From: Andrzej Czerczak [ ] > >Sent: Wednesday, May 31, 2000 1:46 PM > >To: rraszuk@cisco.com > >Cc: mpls@UU.NET > >Subject: Re:Re: MPLS - ATM interworking? > > > > > > > >Robert, > >First of all thanks for your comments. > > > >>Have you read draft MPLS Support of Differentiated Services > >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN > >>(explicit congestion notification) on a per LSP basis using > >the EXP bits > >>in the shim header ? Currently this is the most attractive > >option, but I > >> am not aware of any implementation support this today. > > > > > > > >a) Document draft-ietf-mpls-diff-ext-04.txt does not not > >define the usage > >of ECN. > > > >b) Taking into account label merging capabilites of LSRs, how > >can determine > >to which ingress LSP to to send Congestion Notification? > > > >c) Where can I find: > > > >Ramakrishnan et al., "A Proposal to Incorporate ECN in > > MPLS", draft-ietf-mpls-ecn-00.txt? > > > > > > > > >What I'd like to say is, that at least during first phases of > >implementations (before entire infrastructure will become IP) > >interworking > >of MPLS core and ATM edge will be important, but I could not find a > >proposal of how to do interworking between them. > > > > > > > >Andrzej > > > > > > > > > > > > > << File: draft-mpls-ecn-00.txt >> From owner-mpls@UU.NET Wed May 31 15:30:33 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 PAA21482 for ; Wed, 31 May 2000 15:30: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 QQirpe20659; Wed, 31 May 2000 19:30:32 GMT Received: by mail-control.mail.uu.net id QQirpe07784 for mpls-outgoing; Wed, 31 May 2000 19:30: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 QQirpe07749 for ; Wed, 31 May 2000 19:30: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 QQirpd00183 for ; Wed, 31 May 2000 15:29:41 -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 QQirpd13901 for ; Wed, 31 May 2000 19:29:40 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 MAA08841; Wed, 31 May 2000 12:29: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 PAA20605; Wed, 31 May 2000 15:29:38 -0400 (EDT) Message-Id: <200005311929.PAA20605@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Sean Doran cc: Martin Cooper , mpls@UU.NET Subject: Re: MPLS Performance analysis..... In-reply-to: Your message of 31 May 2000 21:02:19 +0200. <52u2feczlw.fsf@sean.ebone.net> 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, 31 May 2000 15:29:37 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Sean> you get a nastygram from one of the high priests of MPLS that you have Sean> just reinvented MPLS only with alot of extra bytes of overhead per Sean> packet. I think that what the nastygram would actually say is that you haven't really invented or reinvented anything yet, but that when you actually work out all the details, you will not only find that your encapsulation overhead is five times as large, but that you end up with no less operational overhead and probably with considerably more. But of course, time will tell ... From owner-mpls@UU.NET Wed May 31 15:45: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 ESMTP id PAA22116 for ; Wed, 31 May 2000 15:45: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 QQirpf00933; Wed, 31 May 2000 19:45:53 GMT Received: by mail-control.mail.uu.net id QQirpf08627 for mpls-outgoing; Wed, 31 May 2000 19:45: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 QQirpf08622 for ; Wed, 31 May 2000 19:45:10 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 QQirpe02936 for ; Wed, 31 May 2000 15:44:03 -0400 (EDT) Received: from sean.ebone.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sean.ebone.net [195.158.227.211]) id QQirpe29717 for ; Wed, 31 May 2000 19:44:02 GMT Received: by sean.ebone.net (Postfix, from userid 1113) id 2A9F4882; Wed, 31 May 2000 21:44:02 +0200 (CEST) To: erosen@cisco.com Subject: Re: MPLS Performance analysis..... Cc: mpls@UU.NET Message-Id: <20000531194402.2A9F4882@sean.ebone.net> Date: Wed, 31 May 2000 21:44:02 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-mpls@UU.NET Precedence: bulk Eric Rosen writes - | I think that what the nastygram would actually say is that you haven't | really invented or reinvented anything yet, but that when you actually work | out all the details, you will not only find that your encapsulation overhead | is five times as large, but that you end up with no less operational | overhead and probably with considerably more. The nastygrams tend to come from the other High Priest. -:) (I guess he and I are allowed to call each other names over the occasional thing, since we tend to agree about so much else). Actually, despite my own religiousness, I would agree that if you actually wanted to do large amounts of SSR-style ER and were sensitive to overhead, that you probably would be crazy to do it with other than MPLS. Of course, that does not imply that doing large amounts of SSR-style ER in itself is not crazy, in my opinion. Sean. From owner-mpls@UU.NET Wed May 31 15:49: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 PAA22276 for ; Wed, 31 May 2000 15:49: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 QQirpf03500; Wed, 31 May 2000 19:49:10 GMT Received: by mail-control.mail.uu.net id QQirpf08826 for mpls-outgoing; Wed, 31 May 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 QQirpf08821 for ; Wed, 31 May 2000 19:48:31 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 QQirpf03684 for ; Wed, 31 May 2000 15:48:10 -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 QQirpf26188 for ; Wed, 31 May 2000 19:48:10 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 MAA21227 for ; Wed, 31 May 2000 12:48:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA20676 for mpls@uu.net; Wed, 31 May 2000 15:48:08 -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 QQirpe08400 for ; Wed, 31 May 2000 19:42:59 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 QQirpe02738 for ; Wed, 31 May 2000 15:42:34 -0400 (EDT) Received: from nmg4.csi.cam.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: nmg4.csi.cam.ac.uk [131.111.12.28]) id QQirpe28891 for ; Wed, 31 May 2000 19:42:33 GMT Received: from mjc64 by nmg4.csi.cam.ac.uk with local (Exim 3.13 #1) id 12xENr-0000KE-00; Wed, 31 May 2000 20:42:31 +0100 From: Martin Cooper To: Sean Doran Cc: mpls@UU.NET Subject: Re: MPLS Performance analysis..... Message-Id: Date: Wed, 31 May 2000 20:42:31 +0100 Sender: owner-mpls@UU.NET Precedence: bulk Sean Doran writes: > MPLS is a condensation of a GRE-like data-in-IP > encapsulation header, plus some related control planes to > lay out an SSR (strict source route) across a routed, > packet-switched network. I must say that I visualise TE-tunnels as a lot of GRE tunnels with static routes on each router nailing the next-hops down, and with a control plane to change the statics for provisioning. > When you point that the IP overhead lets one choose > between doing SSR ER and two different modes of LSR ER > (both of which require router cooperation -- one mode > requires the decap-reencap dance above, the other merely > processing of the LSRR option), you may end up in a nasty > fight, being reminded that one of the reasons people don't > like ATM is that there is lots of overhead. Assuming Cisco kit though, don't IP packets with options get punted by CEF to the process-switching path, or am I thinking of non-CEF IOS versions? > You are emulating a circuit-switched network on a > packet-switched one, no matter how you slice things; > if your underlying logical layer in a hybrid MPLS/IP > core changes, both MPLS and IP have to reconverge, > and this is generally not so ships-in-the-night (i.e., > typically MPLS is reliant upon the topology discovery > protocol IP uses). Extra stability here can only come > through a time-to-converge trade-off. I'm not sure I buy this -- are you sure that's how it works? I was under the impression the hop-by-hop path of a tunnel was somehow nailed down at each hop (like you might want to with an EBGP-multihop peering route) to prevent routing instabilities ripping up your pre- established paths? > How is MPLS any different? Well, given the above uncertainty? Certainly it sounds a bit unstable if the TE-tunnels have to rely on local routing-table convergence before they can be used for traffic. > Ah, you're new to the IETF, too? Welcome! Rough consensus and working code so I hear... sounds good if that's really how it works... :-) M. From owner-mpls@UU.NET Wed May 31 15:56: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 ESMTP id PAA22638 for ; Wed, 31 May 2000 15:56: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 QQirpf02012; Wed, 31 May 2000 19:56:17 GMT Received: by mail-control.mail.uu.net id QQirpf09106 for mpls-outgoing; Wed, 31 May 2000 19:55: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 QQirpf09100 for ; Wed, 31 May 2000 19:55: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 QQirpf07210 for ; Wed, 31 May 2000 15:53: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 QQirpf00174 for ; Wed, 31 May 2000 19:53:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA07564 for mpls@uu.net; Wed, 31 May 2000 15:53:40 -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 QQirpf09055 for ; Wed, 31 May 2000 19:53:17 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 QQirpf04653 for ; Wed, 31 May 2000 15:52:44 -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 QQirpf06038 for ; Wed, 31 May 2000 19:52:44 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA09636; Wed, 31 May 2000 12:52:41 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 12:52:42 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405A5@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'CATANZARITI Sergio FTR&D/TI'" , Shahram Davari Cc: mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Date: Wed, 31 May 2000 12:49:43 -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, 1) Please check RFC 2481 for the definition and usage of ECN. 2) As far as I know there is currently no proposal to use ECN bits in an Edge-to-Edge level. The intention of Sally Floyd's draft was that ECN to be used with TCP (end-to-end). Regards, Shahram -----Original Message----- From: CATANZARITI Sergio FTR&D/TI [mailto:sergio.catanzariti@rd.francetelecom.com] Sent: Wednesday, May 31, 2000 3:13 PM To: 'Shahram Davari' Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Shahram, the draft-ietf-mpls-ecn-00.txt does not say anything about ECN usage and applications, but only about ECN support and definition in an MPLS network, the things are quite different. So, I have the same question: where I can find Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS", draft-ietf-mpls-ecn-00.txt? Also, I do believe that the ECN in an MPLS network works on resource types (LSPs) quite different than native IP flows. So, the source address is not that useful here, albeit in an ECN schema in pure IP networks. ECN in an MPLS network is supposed to signal congestion in an edge-to-edge fashion (different from end-to-end) where the LERs could cooperate on that. Absolutely, I want to associate LSPs with congestion dynamics to eventually slow them down. How can I do that? That's the question. Sergio -------------------------------------------------------------------- Sergio Catanzariti Senior Project Manager, Technology Integration France Telecom R&D 1000 Marina Boulevard Suite 300 Brisbane CA 94005 Tel. 650-875-1526 Fax. 650-875-1505 email:sergio.catanzariti@rd.francetelecom.com -------------------------------------------------------------------- -----Original Message----- From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, May 31, 2000 11:34 AM To: 'Andrzej Czerczak'; rraszuk@cisco.com Cc: mpls@UU.NET Subject: RE: Re: MPLS - ATM interworking? Andrzej, 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is attached to this email. 2)Congestion Notification is and end-to-end signal which is meant to be used by TCP. You don't need to know the ingress LSR or even the LSP from which the congested packet is received. The receiver may send the congestion notification to the sender using source IP address, either through another LSP or even through normal IP hop-by-hop routing. Regards, -Shahram >-----Original Message----- >From: Andrzej Czerczak [ mailto:Andrzej_Czerczak/HeadQ@netia.pl ] >Sent: Wednesday, May 31, 2000 1:46 PM >To: rraszuk@cisco.com >Cc: mpls@UU.NET >Subject: Re:Re: MPLS - ATM interworking? > > > >Robert, >First of all thanks for your comments. > >>Have you read draft MPLS Support of Differentiated Services >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN >>(explicit congestion notification) on a per LSP basis using >the EXP bits >>in the shim header ? Currently this is the most attractive >option, but I >> am not aware of any implementation support this today. > > > >a) Document draft-ietf-mpls-diff-ext-04.txt does not not >define the usage >of ECN. > >b) Taking into account label merging capabilites of LSRs, how >can determine >to which ingress LSP to to send Congestion Notification? > >c) Where can I find: > >Ramakrishnan et al., "A Proposal to Incorporate ECN in > MPLS", draft-ietf-mpls-ecn-00.txt? > > > >What I'd like to say is, that at least during first phases of >implementations (before entire infrastructure will become IP) >interworking >of MPLS core and ATM edge will be important, but I could not find a >proposal of how to do interworking between them. > > > >Andrzej > > > > > > << File: draft-mpls-ecn-00.txt >> From owner-mpls@UU.NET Wed May 31 16:07:33 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 QAA23251 for ; Wed, 31 May 2000 16:07: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 QQirpg15883; Wed, 31 May 2000 20:07:32 GMT Received: by mail-control.mail.uu.net id QQirpg18849 for mpls-outgoing; Wed, 31 May 2000 20:06: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 QQirpg18839 for ; Wed, 31 May 2000 20:06: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 QQirpg06680 for ; Wed, 31 May 2000 16:03:58 -0400 (EDT) Received: from u-mail.rd.francetelecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQirpg13571 for ; Wed, 31 May 2000 20:03:57 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 May 2000 13:01:23 -0700 Message-ID: <337055FBC675D311A85D00508B5A9C4F2542C6@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'Shahram Davari'" Cc: mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Date: Wed, 31 May 2000 13:01:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCB3A.FEC955D4" 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_01BFCB3A.FEC955D4 Content-Type: text/plain; charset="iso-8859-1" Thanks, I knew that RFC. But, it does not solve the original question that was ECN application in an MPLS network and its usage. Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 31, 2000 12:50 PM > To: 'CATANZARITI Sergio FTR&D/TI'; Shahram Davari > Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: RE: Re: MPLS - ATM interworking? > > Hi, > > 1) Please check RFC 2481 for the definition and usage of ECN. > 2) As far as I know there is currently no proposal to use ECN bits in an > Edge-to-Edge level. The intention of Sally Floyd's draft was that ECN to > be > used with TCP (end-to-end). > > Regards, > Shahram > > -----Original Message----- > From: CATANZARITI Sergio FTR&D/TI > [mailto:sergio.catanzariti@rd.francetelecom.com] > Sent: Wednesday, May 31, 2000 3:13 PM > To: 'Shahram Davari' > Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: RE: Re: MPLS - ATM interworking? > > > > Shahram, > > the draft-ietf-mpls-ecn-00.txt does not say anything about ECN usage > and applications, but only about ECN support and definition in an MPLS > network, the things are quite different. So, I have the same question: > where > I can find Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS", > draft-ietf-mpls-ecn-00.txt? > > Also, I do believe that the ECN in an MPLS network works on resource > types (LSPs) quite different than native IP flows. So, the source address > is > not that useful here, albeit in an ECN schema in pure IP networks. > > ECN in an MPLS network is supposed to signal congestion in an > edge-to-edge fashion (different from end-to-end) where the LERs could > cooperate on that. > > Absolutely, I want to associate LSPs with congestion dynamics to > eventually slow them down. How can I do that? That's the question. > > Sergio > > -------------------------------------------------------------------- > > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 31, 2000 11:34 AM > To: 'Andrzej Czerczak'; rraszuk@cisco.com > Cc: mpls@UU.NET > Subject: RE: Re: MPLS - ATM interworking? > > Andrzej, > > 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is > attached to > this email. > > 2)Congestion Notification is and end-to-end signal which is meant to > be used > by TCP. You don't need to know the ingress LSR or even the LSP from which > the congested packet is received. The receiver may send the congestion > notification to the sender using source IP address, either through another > > LSP or even through normal IP hop-by-hop routing. > > Regards, > -Shahram > > > > > >-----Original Message----- > >From: Andrzej Czerczak [ mailto:Andrzej_Czerczak/HeadQ@netia.pl > ] > >Sent: Wednesday, May 31, 2000 1:46 PM > >To: rraszuk@cisco.com > >Cc: mpls@UU.NET > >Subject: Re:Re: MPLS - ATM interworking? > > > > > > > >Robert, > >First of all thanks for your comments. > > > >>Have you read draft MPLS Support of Differentiated Services > >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN > >>(explicit congestion notification) on a per LSP basis using > >the EXP bits > >>in the shim header ? Currently this is the most attractive > >option, but I > >> am not aware of any implementation support this today. > > > > > > > >a) Document draft-ietf-mpls-diff-ext-04.txt does not not > >define the usage > >of ECN. > > > >b) Taking into account label merging capabilites of LSRs, how > >can determine > >to which ingress LSP to to send Congestion Notification? > > > >c) Where can I find: > > > >Ramakrishnan et al., "A Proposal to Incorporate ECN in > > MPLS", draft-ietf-mpls-ecn-00.txt? > > > > > > > > >What I'd like to say is, that at least during first phases of > >implementations (before entire infrastructure will become IP) > >interworking > >of MPLS core and ATM edge will be important, but I could not find a > >proposal of how to do interworking between them. > > > > > > > >Andrzej > > > > > > > > > > > > > << File: draft-mpls-ecn-00.txt >> ------_=_NextPart_001_01BFCB3A.FEC955D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Re: MPLS - ATM interworking?

Thanks, I knew that RFC. But, it does = not solve the original question that was ECN application in an MPLS = network and its usage.

Sergio

    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   Shahram Davari = [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:   Wednesday, May 31, 2000 12:50 PM
    To:     'CATANZARITI Sergio FTR&D/TI'; Shahram Davari
    Cc:     mpls@UU.NET; 'Andrzej Czerczak'; = rraszuk@cisco.com
    Subject:       = RE: Re: MPLS - ATM = interworking?

    Hi,
     
    1) Please check RFC 2481 for = the definition and usage of ECN.
    2) As far as I know there is = currently no proposal to use ECN bits in an
    Edge-to-Edge level. The = intention of Sally Floyd's draft was that ECN to be
    used with TCP (end-to-end). =
     
    Regards,
    Shahram

    -----Original = Message-----
    From: CATANZARITI Sergio = FTR&D/TI
    [mailto:sergio.ca= tanzariti@rd.francetelecom.com]
    Sent: Wednesday, May 31, 2000 = 3:13 PM
    To: 'Shahram Davari'
    Cc: mpls@UU.NET; 'Andrzej = Czerczak'; rraszuk@cisco.com
    Subject: RE: Re: MPLS - ATM = interworking?



    Shahram,

            the draft-ietf-mpls-ecn-00.txt does not say = anything about ECN usage
    and applications, but only = about ECN support and definition in an MPLS
    network, the things are quite = different. So, I have the same question: where
    I can find Ramakrishnan et al., = "A Proposal to Incorporate ECN in MPLS",
    draft-ietf-mpls-ecn-00.txt?

            Also, I do believe that the ECN in an MPLS network = works on resource
    types (LSPs) quite different = than native IP flows. So, the source address is
    not that useful here, albeit in = an ECN schema in pure IP networks.

            ECN in an MPLS network is supposed to signal = congestion in an
    edge-to-edge fashion (different = from end-to-end) where the LERs could
    cooperate on that.

            Absolutely, I want to associate LSPs with = congestion dynamics to
    eventually slow them down. How = can I do that? That's the question.

    Sergio

            -------------------------------------------------------------------= -

    Sergio Catanzariti
    Senior Project Manager, = Technology Integration
    France Telecom R&D
    1000 Marina Boulevard Suite 300 =
    Brisbane CA 94005
    Tel. 650-875-1526
    Fax. 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com
    -------------------------------------------------------------------= -


            -----Original Message-----
    From:   Shahram = Davari [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:   Wednesday, = May 31, 2000 11:34 AM
    To:     = 'Andrzej Czerczak'; rraszuk@cisco.com
    Cc:     = mpls@UU.NET
    Subject:        RE: Re: MPLS - = ATM interworking?

            Andrzej,

            1)ECN usage is defined in = draft-ietf-mpls-ecn-00.txt, which is
    attached to
    this email.

            2)Congestion Notification is and end-to-end signal = which is meant to
    be used
    by TCP. You don't need to know = the ingress LSR or even the LSP from which
    the congested packet is = received. The receiver may send the congestion
    notification to the sender = using source IP address, either through another
    LSP or even through normal IP = hop-by-hop routing.

            Regards,
    -Shahram




            >-----Original Message-----
    >From: Andrzej Czerczak = [ mailto:Andrzej_Czerczak/= HeadQ@netia.pl
    <mailto:Andrzej_Czerczak/= HeadQ@netia.pl> ] =
    >Sent: Wednesday, May 31, = 2000 1:46 PM
    >To: rraszuk@cisco.com =
    >Cc: mpls@UU.NET
    >Subject: Re:Re: MPLS - ATM = interworking?
    >
    >
    >
    >Robert,
    >First of all thanks for = your comments.
    >
    >>Have you read draft = MPLS Support of Differentiated Services
    >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to = use the ECN
    >>(explicit congestion = notification) on a per LSP basis using
    >the EXP bits
    >>in the shim header ? = Currently this is the most attractive
    >option, but I
    >> am not aware of any = implementation support this today.
    >
    >
    >
    >a) Document = draft-ietf-mpls-diff-ext-04.txt does not not
    >define the usage
    >of ECN.
    >
    >b) Taking into account = label merging capabilites of LSRs, how
    >can determine
    >to which ingress LSP to to = send Congestion Notification?
    >
    >c) Where can I find: =
    >
    >Ramakrishnan et al., = "A Proposal to Incorporate ECN in
    >   MPLS", = draft-ietf-mpls-ecn-00.txt?

            >
    >
    >
    >What I'd like to say is, = that at least during first phases of
    >implementations (before = entire infrastructure will become IP)
    >interworking
    >of MPLS core and ATM edge = will be important, but I could not find a
    >proposal of how to do = interworking between them.
    >
    >
    >
    >Andrzej
    >
    >
    >
    >
    >
    >
     << File: = draft-mpls-ecn-00.txt >>

------_=_NextPart_001_01BFCB3A.FEC955D4-- From owner-mpls@UU.NET Wed May 31 16:08: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 QAA23314 for ; Wed, 31 May 2000 16:08: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 QQirpg10571; Wed, 31 May 2000 20:08:33 GMT Received: by mail-control.mail.uu.net id QQirpg18887 for mpls-outgoing; Wed, 31 May 2000 20:08: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 QQirpg18876 for ; Wed, 31 May 2000 20:08:03 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 QQirpg07106 for ; Wed, 31 May 2000 16:06:30 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQirpg15098 for ; Wed, 31 May 2000 20:06: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 QAA04393; Wed, 31 May 2000 16:05:45 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Sean Doran'" , "'Martin Cooper'" Cc: Subject: RE: MPLS Performance analysis..... Date: Wed, 31 May 2000 16:09:31 -0400 Message-ID: <008f01bfcb3c$2243acc0$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: <52u2feczlw.fsf@sean.ebone.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In his previous message, Sean Doran writes > -----Original Message----- > Martin Cooper writes: > > > the de-coupling of end-to-end path-selection from the > > extremely dynamic hop-by-hop routing information > > MPLS is a condensation of a GRE-like data-in-IP > encapsulation header, plus some related control planes to > lay out an SSR (strict source route) across a routed, > packet-switched network. > > > On the other hand, destination-prefix based IP routing > > is quintessentially a hop-by-hop algorithm > > How is MPLS any different? You are absolutely right. When MPLS work started the enhancing the speed of IP route look up was a key motivator behind the technology. IP route look up speed no longer being an issue in core gateways, it doesn't really matter if you provision your source routes using CR-LDP for certain traffic (or whatever else you have), or by going to each router in the network and creating suitable entries (manually or auto-magically under the control of a TE process) in the routers so that a particular class of traffic goes over a statically configured path. If there are no traffic engineering requirements, as you rightly pointed out, MPLS will not bring any additional benefits that can't be provided using other technologies. But the core assumption is, lots of TE is required. Cheers, --brijesh From owner-mpls@UU.NET Wed May 31 16:20: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 QAA23744 for ; Wed, 31 May 2000 16:20: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 QQirph25378; Wed, 31 May 2000 20:20:46 GMT Received: by mail-control.mail.uu.net id QQirph19734 for mpls-outgoing; Wed, 31 May 2000 20:20: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 QQirph19727 for ; Wed, 31 May 2000 20:20:14 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 QQirph09199 for ; Wed, 31 May 2000 16:17:46 -0400 (EDT) Received: from sean.ebone.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sean.ebone.net [195.158.227.211]) id QQirph23113 for ; Wed, 31 May 2000 20:17:46 GMT Received: by sean.ebone.net (Postfix, from userid 1113) id AC20C882; Wed, 31 May 2000 22:17:45 +0200 (CEST) To: bkumar@ennovatenetworks.com Subject: RE: MPLS Performance analysis..... Cc: mpls@UU.NET Message-Id: <20000531201745.AC20C882@sean.ebone.net> Date: Wed, 31 May 2000 22:17:45 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-mpls@UU.NET Precedence: bulk Brijesh - | ... using CR-LDP for certain traffic (or whatever else you have), | or by going to each router in the network and creating suitable entries | (manually or auto-magically under the control of a TE process) in the | routers so that a particular class of traffic goes over a statically | configured path. One thing over which I am sometimes accused of being provocative is the question of whether one can take the control plane (i.e., the manual or automagic process that behaves in a CR-LDP or RSVP fashion) and use it with a "label" that is in effect an IP datagram. I think it can, and that it addresses the possibility that this: | the core assumption is, lots of TE is required. is only partly true (i.e., "lots" but not nearly as much as normal best-efforts Internet traffic _in some situations_. (Such as a well-provisioned backbone's core)). Sean. From owner-mpls@UU.NET Wed May 31 16:42: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 ESMTP id QAA24477 for ; Wed, 31 May 2000 16:42:55 -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 QQirpi10440; Wed, 31 May 2000 20:42:55 GMT Received: by mail-control.mail.uu.net id QQirpi20668 for mpls-outgoing; Wed, 31 May 2000 20:42: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 QQirpi20663 for ; Wed, 31 May 2000 20:42: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 QQirpi13796 for ; Wed, 31 May 2000 16:42:05 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQirpi09811 for ; Wed, 31 May 2000 20:42:04 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id QAA04815; Wed, 31 May 2000 16:41:43 -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 QAA06227; Wed, 31 May 2000 16:40:58 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200005312040.QAA06227@curtis-lt.avici.com> To: CATANZARITI Sergio FTR&D/TI cc: "'Shahram Davari'" , mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com Reply-To: curtis@avici.com Subject: Re: MPLS - ATM interworking? In-reply-to: Your message of "Wed, 31 May 2000 12:13:07 PDT." <337055FBC675D311A85D00508B5A9C4F2542C4@u-mail.rd.francetelecom.com> Date: Wed, 31 May 2000 16:40:58 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <337055FBC675D311A85D00508B5A9C4F2542C4@u-mail.rd.francetelecom.com> , CATANZARITI Sergio FTR&D/TI writes: > > ECN in an MPLS network is supposed to signal congestion in an > edge-to-edge fashion (different from end-to-end) where the LERs could > cooperate on that. Shahram already pointed to RFC2481 and draft-ietf-mpls-ecn-00.txt but perhaps a brief explanation will help. When an LSP is set up as ECN capable, the underlying traffic must be capable of supporting end-to-end ECN as specified in RFC2481. This means the L3PID in the MPLS setup must indicate IPv4 (or IPv6, but let discuss IPv4 for the moment). For each IPv4 packet arriving at the ingress, if the IPv4 header indicates that the packet has the ECT (ECN-Capable Transport) bit is set and the CE bit is not (Congestion Experienced), then the MPLS ECN bit is set. If later an LSR implementing active queue management (for example RED, Random Early Detection) experiences congestion and would have dropped a packet, if the MPLS ECN bit is set, then it is cleared. Note that at a second congestion point, an actual drop would occur, unlike the two bit scheme. At the egress where the POP occurs, if the MPLS ECN bit is clear and the ECT bit is set in the underlying IP header, then the CE bit is set in the IP header. Same would apply to IPv4 or any other protocol that implements a compatible ECN scheme (currently there are no others). > Absolutely, I want to associate LSPs with congestion dynamics to > eventually slow them down. How can I do that? That's the question. ECN != ABR ECN != EFCI There is no ABR for MPLS. To the extent that MPLS differs from ATM, the differences are (mostly) intentional and IMHO ommision of an ABR like capability (given that ABR didn't work well in IP networks due to interactions between the ABR feedback loop and the TCP end-to-end feedback loop) is also intentional and it should stay that way. Curtis From owner-mpls@UU.NET Wed May 31 17:09: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 ESMTP id RAA25059 for ; Wed, 31 May 2000 17:09: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 QQirpk28366; Wed, 31 May 2000 21:09:37 GMT Received: by mail-control.mail.uu.net id QQirpk01172 for mpls-outgoing; Wed, 31 May 2000 21:09:08 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 QQirpk01162 for ; Wed, 31 May 2000 21:08:59 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 QQirpk18635 for ; Wed, 31 May 2000 17:08:38 -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 QQirpk27331 for ; Wed, 31 May 2000 21:08:31 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 31 May 2000 17:01:08 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 17:01:08 -0400 Message-ID: From: "Bilel Jamoussi" To: "'erosen@cisco.com'" , Eric Gray Cc: "'rraszuk@cisco.com'" , David Charlap , mpls@UU.NET Subject: RE: ATM Switches as LSR encoding techniques Date: Wed, 31 May 2000 17:00:55 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCB43.5766BC42" 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_01BFCB43.5766BC42 Content-Type: text/plain; charset="iso-8859-1" This thread is getting off-balance. There are pros and cons to every technology. MPLS provides and evolution path from today's networks and if implemented right on ATM hardware, can take advantage of its many advanced capabilities. a) ATM cell-switching overhead is getting overblown compared to other transports. Look at any voice over packet implementation today ATM is still the most efficient transport. In addition, when considering the advanced Traffic Management (a.k.a. QOS) capabilities of ATM hardware, the cell-tax becomes a very insignificant overhead compared to what you have to do to get to a similar QoS level with other equipment. b) multipoint-to-point: VC-merge capable ATM LSRs support this today. Most ISP demand for TE-LSPs is point-to-point. c) n**2 connections: There is a threshold when this becomes a significant issue. d) OA&M and network management: MPLS still has some work to do to address these issues. How many implementations are out there without a MIB? Bilel. -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Wednesday, May 31, 2000 12:30 PM To: Eric Gray Cc: 'rraszuk@cisco.com'; David Charlap; mpls@UU.NET Subject: Re: ATM Switches as LSR encoding techniques EricGray> All of these things are things that exist and can be supported EricGray> using ATM (for example). Yet people you're talking to want them EricGray> using MPLS. Perhaps the unified control plane issue is not as EricGray> orthogonal as you think? There are a number of reasons for preferring MPLS to ATM that don't have much to do with the control plane: ATM's cell-switching overhead, ATM's scalability problems having to do with lack of multipoint-to-point capability, the scalability problems of having to have n**2 connections among the n routers on the ATM network, ATM's dependence on a particular data link layer, the inability of most ATM switches to handle native IP packets at all, etc. IMHO, it's the scaling issues rather than the more abstract "unified control plane" issues which are driving the market. Many of the things which can in theory be done with ATM are difficult to do in practice because of the scaling limitations. But I would agree that there are also important reasons that do have to do with unifying the control plane: I think the need to support an ATM routing and addressing infrastructure which is independent from the IP routing and addressing infrastructure is a problem, one which MPLS doesn't have. I don't know though how much the customers really care about this. Some folks have made a fetish out of this drive for a unified control plane, arguing that what is really needed is the one true grand unified protocol that does absolutely everything. I think what Robert is saying is that this fetish is not something which derives from customer needs. ------_=_NextPart_001_01BFCB43.5766BC42 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ATM Switches as LSR encoding techniques

This thread is getting off-balance. There are pros = and cons
to every technology. MPLS provides and evolution = path from
today's networks and if implemented right on ATM = hardware,
can take advantage of its many advanced = capabilities.

a) ATM cell-switching overhead is getting overblown = compared
   to other transports. Look at any voice = over packet
   implementation today ATM is still the = most efficient
   transport.

   In addition, when considering the = advanced
   Traffic Management (a.k.a. QOS) = capabilities of ATM hardware,
   the cell-tax becomes a very = insignificant overhead compared to
   what you have to do to get to a similar = QoS level with other
   equipment.

b) multipoint-to-point: VC-merge capable ATM LSRs = support
   this today. Most ISP demand for TE-LSPs = is point-to-point.

c) n**2 connections: There is a threshold when this = becomes
   a significant issue.

d) OA&M and network management: MPLS still has = some work to do
   to address these issues. How many = implementations are out there
   without a MIB?

Bilel.

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com]
Sent: Wednesday, May 31, 2000 12:30 PM
To: Eric Gray
Cc: 'rraszuk@cisco.com'; David Charlap; = mpls@UU.NET
Subject: Re: ATM Switches as LSR encoding = techniques



EricGray> All of  these things  are = things that  exist and can  be supported
EricGray> using ATM (for  example).  = Yet people you're talking  to want them
EricGray> using MPLS.   Perhaps = the  unified control plane  issue is  not as
EricGray> orthogonal as you think?

There are  a number of  reasons for = preferring  MPLS to ATM that  don't have
much  to do  with the  control = plane:  ATM's cell-switching  overhead, ATM's
scalability  problems   having  = to  do  with   lack  of  = multipoint-to-point
capability,  the scalability  problems = of  having to  have  n**2 connections
among the  n routers on  the ATM = network,  ATM's dependence on  a particular
data link  layer, the  inability of  = most ATM switches  to handle  native IP
packets at  all, etc.  IMHO,  it's = the scaling  issues rather than  the more
abstract "unified control plane" issues&nbs= p; which are driving the market.  Many
of the things  which can in theory be  = done with ATM are difficult  to do in
practice because of the scaling limitations.

But I would agree  that there are also important = reasons that  do have to do
with unifying the control plane: I  think the = need to support an ATM routing
and addressing infrastructure  which is = independent from the  IP routing and
addressing  infrastructure is  a = problem,  one which  MPLS doesn't  have.  I
don't know though how much the customers really care = about this.

Some folks have made a fetish out of this drive for a = unified control plane,
arguing that  what is really needed  is = the one true  grand unified protocol
that does absolutely everything.  I think what = Robert is saying is that this
fetish is not something which derives from customer = needs.

------_=_NextPart_001_01BFCB43.5766BC42-- From owner-mpls@UU.NET Wed May 31 17:13: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 ESMTP id RAA25098 for ; Wed, 31 May 2000 17:13: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 QQirpk01123; Wed, 31 May 2000 21:13:01 GMT Received: by mail-control.mail.uu.net id QQirpk01445 for mpls-outgoing; Wed, 31 May 2000 21:12: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 QQirpk01439 for ; Wed, 31 May 2000 21:12: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 QQirpk20430 for ; Wed, 31 May 2000 17:09: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 QQirpk27911 for ; Wed, 31 May 2000 21:09:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA20021 for mpls@uu.net; Wed, 31 May 2000 17:09:14 -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 QQirpk01150 for ; Wed, 31 May 2000 21:08: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 QQirpk19712 for ; Wed, 31 May 2000 17:06:39 -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 QQirpk25680 for ; Wed, 31 May 2000 21:06:38 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA14361; Wed, 31 May 2000 14:06:36 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 14:06:37 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405A7@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'CATANZARITI Sergio FTR&D/TI'" , Shahram Davari Cc: mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Date: Wed, 31 May 2000 14:03:36 -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, As I said there is currently no ECN application in MPLS networks, rather there is ECN processing in MPLS networks for TCP applications. I think you agree that ECN is useful because it can control congestion without dropping packets, which leads to higher BW utilization (i.e., does not waste BW with the packets which are dropped). This goal is achieved by reducing the TCP transmission window. If I understand correctly, what you are proposing is that an ingress LSR may be able to use the ECN notification to divert some of the traffic to other LSPs (i.e., balance the load across multiple LSPs), which leads also to higher BW utilization. In other words ECN notification may be as an input to the Constraint-Based routing algorithm, which runs on the ingress LSRs. However, the same objective can be achieved by feeding back the current congestion status information in LSRs to the ingress LSRs, using the LSP feedback mechanism (check out section 7 of http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-00.txt). , or even with extensions to IGPs. Using this mechanism you won't need the ECN bits and ECN notification for the edge-to-edge congestion control, because the congestion information is available locally on each LSR and the feed-back is also generated locally. Does this answer your question? Regards, -Shahram [Shahram Davari] -----Original Message----- From: CATANZARITI Sergio FTR&D/TI [mailto:sergio.catanzariti@rd.francetelecom.com] Sent: Wednesday, May 31, 2000 4:01 PM To: 'Shahram Davari' Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Thanks, I knew that RFC. But, it does not solve the original question that was ECN application in an MPLS network and its usage. Sergio -------------------------------------------------------------------- Sergio Catanzariti Senior Project Manager, Technology Integration France Telecom R&D 1000 Marina Boulevard Suite 300 Brisbane CA 94005 Tel. 650-875-1526 Fax. 650-875-1505 email:sergio.catanzariti@rd.francetelecom.com -------------------------------------------------------------------- -----Original Message----- From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, May 31, 2000 12:50 PM To: 'CATANZARITI Sergio FTR&D/TI'; Shahram Davari Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Hi, 1) Please check RFC 2481 for the definition and usage of ECN. 2) As far as I know there is currently no proposal to use ECN bits in an Edge-to-Edge level. The intention of Sally Floyd's draft was that ECN to be used with TCP (end-to-end). Regards, Shahram -----Original Message----- From: CATANZARITI Sergio FTR&D/TI [ mailto:sergio.catanzariti@rd.francetelecom.com ] Sent: Wednesday, May 31, 2000 3:13 PM To: 'Shahram Davari' Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com Subject: RE: Re: MPLS - ATM interworking? Shahram, the draft-ietf-mpls-ecn-00.txt does not say anything about ECN usage and applications, but only about ECN support and definition in an MPLS network, the things are quite different. So, I have the same question: where I can find Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS", draft-ietf-mpls-ecn-00.txt? Also, I do believe that the ECN in an MPLS network works on resource types (LSPs) quite different than native IP flows. So, the source address is not that useful here, albeit in an ECN schema in pure IP networks. ECN in an MPLS network is supposed to signal congestion in an edge-to-edge fashion (different from end-to-end) where the LERs could cooperate on that. Absolutely, I want to associate LSPs with congestion dynamics to eventually slow them down. How can I do that? That's the question. Sergio -------------------------------------------------------------------- Sergio Catanzariti Senior Project Manager, Technology Integration France Telecom R&D 1000 Marina Boulevard Suite 300 Brisbane CA 94005 Tel. 650-875-1526 Fax. 650-875-1505 email:sergio.catanzariti@rd.francetelecom.com -------------------------------------------------------------------- -----Original Message----- From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, May 31, 2000 11:34 AM To: 'Andrzej Czerczak'; rraszuk@cisco.com Cc: mpls@UU.NET Subject: RE: Re: MPLS - ATM interworking? Andrzej, 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is attached to this email. 2)Congestion Notification is and end-to-end signal which is meant to be used by TCP. You don't need to know the ingress LSR or even the LSP from which the congested packet is received. The receiver may send the congestion notification to the sender using source IP address, either through another LSP or even through normal IP hop-by-hop routing. Regards, -Shahram >-----Original Message----- >From: Andrzej Czerczak [ mailto:Andrzej_Czerczak/HeadQ@netia.pl < mailto:Andrzej_Czerczak/HeadQ@netia.pl > ] >Sent: Wednesday, May 31, 2000 1:46 PM >To: rraszuk@cisco.com >Cc: mpls@UU.NET >Subject: Re:Re: MPLS - ATM interworking? > > > >Robert, >First of all thanks for your comments. > >>Have you read draft MPLS Support of Differentiated Services >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN >>(explicit congestion notification) on a per LSP basis using >the EXP bits >>in the shim header ? Currently this is the most attractive >option, but I >> am not aware of any implementation support this today. > > > >a) Document draft-ietf-mpls-diff-ext-04.txt does not not >define the usage >of ECN. > >b) Taking into account label merging capabilites of LSRs, how >can determine >to which ingress LSP to to send Congestion Notification? > >c) Where can I find: > >Ramakrishnan et al., "A Proposal to Incorporate ECN in > MPLS", draft-ietf-mpls-ecn-00.txt? > > > >What I'd like to say is, that at least during first phases of >implementations (before entire infrastructure will become IP) >interworking >of MPLS core and ATM edge will be important, but I could not find a >proposal of how to do interworking between them. > > > >Andrzej > > > > > > << File: draft-mpls-ecn-00.txt >> From owner-mpls@UU.NET Wed May 31 17:40: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 RAA25543 for ; Wed, 31 May 2000 17:40: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 QQirpm11974; Wed, 31 May 2000 21:40:39 GMT Received: by mail-control.mail.uu.net id QQirpm02944 for mpls-outgoing; Wed, 31 May 2000 21:40: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 QQirpm02939 for ; Wed, 31 May 2000 21:40:14 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 QQirpm24498 for ; Wed, 31 May 2000 17:39:48 -0400 (EDT) Received: from u-mail.rd.francetelecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQirpm18766 for ; Wed, 31 May 2000 21:39:47 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 May 2000 14:37:28 -0700 Message-ID: <337055FBC675D311A85D00508B5A9C4F2542C7@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'Shahram Davari'" Cc: mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com, CATANZARITI Sergio FTR&D/TI Subject: RE: Re: MPLS - ATM interworking? Date: Wed, 31 May 2000 14:37:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCB48.6AE1EA1C" 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_01BFCB48.6AE1EA1C Content-Type: text/plain; charset="iso-8859-1" >As I said there is currently no ECN application in MPLS networks, rather >there is ECN processing in MPLS networks for TCP applications. Oh, thank you. I wanted just to be reassured about that, so there is no ECN value add unique to MPLS that we already do not know for pure IP networks, with all the related ECN debates (TCP misbehavior, UDP-based multimedia flows independence) > I think you agree that ECN is useful because it can control congestion > without dropping packets, which leads to higher BW utilization (i.e., does > not waste BW with the packets which are dropped). This goal is achieved by > reducing the TCP transmission window. Sure. It is that I have still difficulty to see the relationship between TCP flows and LSPs aggregates, but that is my problem not yours. >Using this mechanism you won't need the ECN >bits and ECN notification for the edge-to-edge congestion control, because >the congestion information is available locally on each LSR and the >feed-back is also generated locally. Thanks for having pointed it out. That is where I am more interested as LSPs provider. Regards, Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 31, 2000 2:04 PM > To: 'CATANZARITI Sergio FTR&D/TI'; Shahram Davari > Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: RE: Re: MPLS - ATM interworking? > > Hi, > > As I said there is currently no ECN application in MPLS networks, rather > there is ECN processing in MPLS networks for TCP applications. > > I think you agree that ECN is useful because it can control congestion > without dropping packets, which leads to higher BW utilization (i.e., does > not waste BW with the packets which are dropped). This goal is achieved > by > reducing the TCP transmission window. > > If I understand correctly, what you are proposing is that an ingress LSR > may > be able to use the ECN notification to divert some of the traffic to other > LSPs (i.e., balance the load across multiple LSPs), which leads also to > higher BW utilization. In other words ECN notification may be as an input > to > the Constraint-Based routing algorithm, which runs on the ingress LSRs. > > However, the same objective can be achieved by feeding back the current > congestion status information in LSRs to the ingress LSRs, using the LSP > feedback mechanism (check out section 7 of > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-00.txt). > , > or > even with extensions to IGPs. Using this mechanism you won't need the ECN > bits and ECN notification for the edge-to-edge congestion control, because > the congestion information is available locally on each LSR and the > feed-back is also generated locally. > > Does this answer your question? > > Regards, > -Shahram > > > > > > > > [Shahram Davari] > -----Original Message----- > From: CATANZARITI Sergio FTR&D/TI > [mailto:sergio.catanzariti@rd.francetelecom.com] > Sent: Wednesday, May 31, 2000 4:01 PM > To: 'Shahram Davari' > Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: RE: Re: MPLS - ATM interworking? > > > > Thanks, I knew that RFC. But, it does not solve the original question that > was ECN application in an MPLS network and its usage. > > Sergio > > -------------------------------------------------------------------- > > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 31, 2000 12:50 PM > To: 'CATANZARITI Sergio FTR&D/TI'; Shahram Davari > Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: RE: Re: MPLS - ATM interworking? > > Hi, > > 1) Please check RFC 2481 for the definition and usage of ECN. > 2) As far as I know there is currently no proposal to use ECN bits in an > Edge-to-Edge level. The intention of Sally Floyd's draft was that ECN to > be > used with TCP (end-to-end). > > Regards, > Shahram > > -----Original Message----- > From: CATANZARITI Sergio FTR&D/TI > [ mailto:sergio.catanzariti@rd.francetelecom.com > ] > Sent: Wednesday, May 31, 2000 3:13 PM > To: 'Shahram Davari' > Cc: mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: RE: Re: MPLS - ATM interworking? > > > > Shahram, > > the draft-ietf-mpls-ecn-00.txt does not say anything about > ECN usage > and applications, but only about ECN support and definition in an MPLS > network, the things are quite different. So, I have the same question: > where > > I can find Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS", > draft-ietf-mpls-ecn-00.txt? > > Also, I do believe that the ECN in an MPLS network works on > resource > types (LSPs) quite different than native IP flows. So, the source address > is > > not that useful here, albeit in an ECN schema in pure IP networks. > > ECN in an MPLS network is supposed to signal congestion in > an > edge-to-edge fashion (different from end-to-end) where the LERs could > cooperate on that. > > Absolutely, I want to associate LSPs with congestion > dynamics to > eventually slow them down. How can I do that? That's the question. > > Sergio > > > -------------------------------------------------------------------- > > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 31, 2000 11:34 AM > To: 'Andrzej Czerczak'; rraszuk@cisco.com > Cc: mpls@UU.NET > Subject: RE: Re: MPLS - ATM interworking? > > Andrzej, > > 1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which > is > attached to > this email. > > 2)Congestion Notification is and end-to-end signal which is > meant to > be used > by TCP. You don't need to know the ingress LSR or even the LSP from which > the congested packet is received. The receiver may send the congestion > notification to the sender using source IP address, either through another > > LSP or even through normal IP hop-by-hop routing. > > Regards, > -Shahram > > > > > >-----Original Message----- > >From: Andrzej Czerczak [ mailto:Andrzej_Czerczak/HeadQ@netia.pl > > < mailto:Andrzej_Czerczak/HeadQ@netia.pl > > ] > >Sent: Wednesday, May 31, 2000 1:46 PM > >To: rraszuk@cisco.com > >Cc: mpls@UU.NET > >Subject: Re:Re: MPLS - ATM interworking? > > > > > > > >Robert, > >First of all thanks for your comments. > > > >>Have you read draft MPLS Support of Differentiated Services > >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN > >>(explicit congestion notification) on a per LSP basis using > >the EXP bits > >>in the shim header ? Currently this is the most attractive > >option, but I > >> am not aware of any implementation support this today. > > > > > > > >a) Document draft-ietf-mpls-diff-ext-04.txt does not not > >define the usage > >of ECN. > > > >b) Taking into account label merging capabilites of LSRs, how > >can determine > >to which ingress LSP to to send Congestion Notification? > > > >c) Where can I find: > > > >Ramakrishnan et al., "A Proposal to Incorporate ECN in > > MPLS", draft-ietf-mpls-ecn-00.txt? > > > > > > > > >What I'd like to say is, that at least during first phases of > >implementations (before entire infrastructure will become IP) > >interworking > >of MPLS core and ATM edge will be important, but I could not find a > >proposal of how to do interworking between them. > > > > > > > >Andrzej > > > > > > > > > > > > > << File: draft-mpls-ecn-00.txt >> > ------_=_NextPart_001_01BFCB48.6AE1EA1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Re: MPLS - ATM interworking?

    >As I said there is currently = no ECN application in MPLS networks, rather
    >there is ECN processing in = MPLS networks for TCP applications.

Oh, thank you. I wanted just to be = reassured about that, so there is no ECN value add unique to MPLS that = we already do not know for pure IP networks, with all the related ECN = debates (TCP misbehavior, UDP-based multimedia flows = independence)

    > I think you agree that ECN = is useful because it can control congestion
    > without dropping packets, = which leads to higher BW utilization (i.e., does
    > not waste BW with the = packets which are dropped). This goal is achieved  by
    > reducing the TCP = transmission window.

    Sure. It is that I have still = difficulty to see the relationship between TCP flows and LSPs = aggregates, but that is my problem not yours.

    >Using this mechanism you = won't need the ECN
    >bits and ECN notification = for the edge-to-edge congestion control, because
    >the congestion information = is available locally on each LSR and the
    >feed-back is also generated = locally.

Thanks for having pointed it out. That = is where I am more interested as LSPs provider.

Regards,
Sergio



    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   Shahram Davari = [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:   Wednesday, May 31, 2000 2:04 PM
    To:     'CATANZARITI Sergio FTR&D/TI'; Shahram Davari
    Cc:     mpls@UU.NET; 'Andrzej Czerczak'; = rraszuk@cisco.com
    Subject:       = RE: Re: MPLS - ATM = interworking?

    Hi,
     
    As I said there is currently no = ECN application in MPLS networks, rather
    there is ECN processing in MPLS = networks for TCP applications.
     
    I think you agree that ECN is = useful because it can control congestion
    without dropping packets, which = leads to higher BW utilization (i.e., does
    not waste BW with the packets = which are dropped). This goal is achieved  by
    reducing the TCP transmission = window.
     
    If I understand correctly, what = you are proposing is that an ingress LSR may
    be able to use the ECN = notification to divert some of the traffic to other
    LSPs (i.e., balance the load = across multiple LSPs), which leads also to
    higher BW utilization. In other = words ECN notification may be as an input to
    the Constraint-Based routing = algorithm, which runs on the ingress LSRs.
     
    However, the same objective can = be achieved by feeding back the current
    congestion status information = in LSRs to the ingress LSRs, using the LSP
    feedback mechanism (check out = section 7 of
    http://www.ietf.org/internet-drafts/draft-ietf-mpls-te= -feed-00.txt).
    <http://www.ietf.org/internet-drafts/draft-ietf-mpls-te= -feed-00.txt)>  , or
    even with extensions to IGPs. = Using this mechanism you won't need the ECN
    bits and ECN notification for = the edge-to-edge congestion control, because
    the congestion information is = available locally on each LSR and the
    feed-back is also generated = locally.
     
    Does this answer your = question?
     
    Regards,
    -Shahram
     
     
     
     
     
     

    [Shahram Davari]
     -----Original = Message-----
    From: CATANZARITI Sergio = FTR&D/TI
    [mailto:sergio.ca= tanzariti@rd.francetelecom.com]
    Sent: Wednesday, May 31, 2000 = 4:01 PM
    To: 'Shahram Davari'
    Cc: mpls@UU.NET; 'Andrzej = Czerczak'; rraszuk@cisco.com
    Subject: RE: Re: MPLS - ATM = interworking?



    Thanks, I knew that RFC. But, it = does not solve the original question that
    was ECN application in an MPLS = network and its usage.

    Sergio

            -------------------------------------------------------------------= -

    Sergio Catanzariti
    Senior Project Manager, = Technology Integration
    France Telecom R&D
    1000 Marina Boulevard Suite 300 =
    Brisbane CA 94005
    Tel. 650-875-1526
    Fax. 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com
    -------------------------------------------------------------------= -


            -----Original Message-----
    From:   Shahram = Davari [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:   Wednesday, = May 31, 2000 12:50 PM
    To:     = 'CATANZARITI Sergio FTR&D/TI'; Shahram Davari
    Cc:     = mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com
    Subject:        RE: Re: MPLS - = ATM interworking?

            Hi,
     
    1) Please check RFC 2481 for = the definition and usage of ECN.
    2) As far as I know there is = currently no proposal to use ECN bits in an
    Edge-to-Edge level. The = intention of Sally Floyd's draft was that ECN to be
    used with TCP (end-to-end). =
     
    Regards,
    Shahram

            -----Original Message-----
    From: CATANZARITI Sergio = FTR&D/TI
    [ mailto:sergio.ca= tanzariti@rd.francetelecom.com
    <mailto:sergio.ca= tanzariti@rd.francetelecom.com> ]
    Sent: Wednesday, May 31, 2000 = 3:13 PM
    To: 'Shahram Davari'
    Cc: mpls@UU.NET; 'Andrzej = Czerczak'; rraszuk@cisco.com
    Subject: RE: Re: MPLS - ATM = interworking?



            Shahram,

                    the = draft-ietf-mpls-ecn-00.txt does not say anything about
    ECN usage
    and applications, but only = about ECN support and definition in an MPLS
    network, the things are quite = different. So, I have the same question: where

    I can find Ramakrishnan et al., = "A Proposal to Incorporate ECN in MPLS",
    draft-ietf-mpls-ecn-00.txt? =

                    Also, I = do believe that the ECN in an MPLS network works on
    resource
    types (LSPs) quite different = than native IP flows. So, the source address is

    not that useful here, albeit in = an ECN schema in pure IP networks.

                    ECN in = an MPLS network is supposed to signal congestion in
    an
    edge-to-edge fashion (different = from end-to-end) where the LERs could
    cooperate on that.

                    = Absolutely, I want to associate LSPs with congestion
    dynamics to
    eventually slow them down. How = can I do that? That's the question.

            Sergio

           =20
    -------------------------------------------------------------------= -

            Sergio Catanzariti
    Senior Project Manager, = Technology Integration
    France Telecom R&D
    1000 Marina Boulevard Suite 300 =
    Brisbane CA 94005
    Tel. 650-875-1526
    Fax. 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com
    -------------------------------------------------------------------= -


                    = -----Original Message-----
    From:   Shahram = Davari [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:   Wednesday, = May 31, 2000 11:34 AM
    To:     = 'Andrzej Czerczak'; rraszuk@cisco.com
    Cc:     = mpls@UU.NET
    Subject:        RE: Re: MPLS - = ATM interworking?

                    = Andrzej,

                    1)ECN = usage is defined in draft-ietf-mpls-ecn-00.txt, which
    is
    attached to
    this email.

                    = 2)Congestion Notification is and end-to-end signal which is
    meant to
    be used
    by TCP. You don't need to know = the ingress LSR or even the LSP from which
    the congested packet is = received. The receiver may send the congestion
    notification to the sender = using source IP address, either through another
    LSP or even through normal IP = hop-by-hop routing.

                    = Regards,
    -Shahram




                    = >-----Original Message-----
    >From: Andrzej Czerczak = [ mailto:Andrzej_Czerczak/= HeadQ@netia.pl
    <mailto:Andrzej_Czerczak/= HeadQ@netia.pl> 
    < mailto:Andrzej_Czerczak/= HeadQ@netia.pl
    <mailto:Andrzej_Czerczak/= HeadQ@netia.pl> = > ]
    >Sent: Wednesday, May 31, = 2000 1:46 PM
    >To: rraszuk@cisco.com =
    >Cc: mpls@UU.NET
    >Subject: Re:Re: MPLS - ATM = interworking?
    >
    >
    >
    >Robert,
    >First of all thanks for = your comments.
    >
    >>Have you read draft = MPLS Support of Differentiated Services
    >>draft-ietf-mpls-diff-ext-04.txt where we are proposing to = use the ECN
    >>(explicit congestion = notification) on a per LSP basis using
    >the EXP bits
    >>in the shim header ? = Currently this is the most attractive
    >option, but I
    >> am not aware of any = implementation support this today.
    >
    >
    >
    >a) Document = draft-ietf-mpls-diff-ext-04.txt does not not
    >define the usage
    >of ECN.
    >
    >b) Taking into account = label merging capabilites of LSRs, how
    >can determine
    >to which ingress LSP to to = send Congestion Notification?
    >
    >c) Where can I find: =
    >
    >Ramakrishnan et al., = "A Proposal to Incorporate ECN in
    >   MPLS", = draft-ietf-mpls-ecn-00.txt?

                    > =
    >
    >
    >What I'd like to say is, = that at least during first phases of
    >implementations (before = entire infrastructure will become IP)
    >interworking
    >of MPLS core and ATM edge = will be important, but I could not find a
    >proposal of how to do = interworking between them.
    >
    >
    >
    >Andrzej
    >
    >
    >
    >
    >
    >
     << File: = draft-mpls-ecn-00.txt >>

------_=_NextPart_001_01BFCB48.6AE1EA1C-- From owner-mpls@UU.NET Wed May 31 17: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 ESMTP id RAA25753 for ; Wed, 31 May 2000 17:56: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 QQirpn22414; Wed, 31 May 2000 21:56:26 GMT Received: by mail-control.mail.uu.net id QQirpn03980 for mpls-outgoing; Wed, 31 May 2000 21:56: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 QQirpn03965 for ; Wed, 31 May 2000 21:56:05 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 QQirpn27870 for ; Wed, 31 May 2000 17:55:27 -0400 (EDT) Received: from u-mail.rd.francetelecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQirpn29093 for ; Wed, 31 May 2000 21:55:26 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 May 2000 14:53:08 -0700 Message-ID: <337055FBC675D311A85D00508B5A9C4F2542C8@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'curtis@avici.com'" Cc: "'Shahram Davari'" , mpls@UU.NET, "'Andrzej Czerczak'" , rraszuk@cisco.com, CATANZARITI Sergio FTR&D/TI Subject: RE: MPLS - ATM interworking? Date: Wed, 31 May 2000 14:53:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCB4A.9A8605DA" 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_01BFCB4A.9A8605DA Content-Type: text/plain Curtis, >ECN != ABR >ECN != EFCI Really? I thought they were the same thing. It is my fault, I should have continued my education, instead of dropping out at the elementary school and play soccer :-) Seriously, I believe that the ABR difficulties were related to the fact that it was an end-to-end mechanism rather than an edge-to-edge, so it followed the destiny of native end-to-end ATM applications. But that is "acqua passata", let us move on. My only point is that as a provider I have to configure, monitor, doing something with my Lisps-based ECN bits at my edge router, without giving me any possibility to act on that, and that does not sound very appealing to me. To an end customer (mine, I mean), that is a different story. Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Curtis Villamizar [SMTP:curtis@avici.com] > Sent: Wednesday, May 31, 2000 1:41 PM > To: CATANZARITI Sergio FTR&D/TI > Cc: 'Shahram Davari'; mpls@UU.NET; 'Andrzej Czerczak'; rraszuk@cisco.com > Subject: Re: MPLS - ATM interworking? > > > In message > <337055FBC675D311A85D00508B5A9C4F2542C4@u-mail.rd.francetelecom.com> > , CATANZARITI Sergio FTR&D/TI writes: > > > > ECN in an MPLS network is supposed to signal congestion in an > > edge-to-edge fashion (different from end-to-end) where the LERs could > > cooperate on that. > > Shahram already pointed to RFC2481 and draft-ietf-mpls-ecn-00.txt but > perhaps a brief explanation will help. > > When an LSP is set up as ECN capable, the underlying traffic must be > capable of supporting end-to-end ECN as specified in RFC2481. This > means the L3PID in the MPLS setup must indicate IPv4 (or IPv6, but let > discuss IPv4 for the moment). For each IPv4 packet arriving at the > ingress, if the IPv4 header indicates that the packet has the ECT > (ECN-Capable Transport) bit is set and the CE bit is not (Congestion > Experienced), then the MPLS ECN bit is set. > > If later an LSR implementing active queue management (for example RED, > Random Early Detection) experiences congestion and would have dropped > a packet, if the MPLS ECN bit is set, then it is cleared. Note that > at a second congestion point, an actual drop would occur, unlike the > two bit scheme. At the egress where the POP occurs, if the MPLS ECN > bit is clear and the ECT bit is set in the underlying IP header, then > the CE bit is set in the IP header. > > Same would apply to IPv4 or any other protocol that implements a > compatible ECN scheme (currently there are no others). > > > Absolutely, I want to associate LSPs with congestion dynamics to > > eventually slow them down. How can I do that? That's the question. > > ECN != ABR > ECN != EFCI > > There is no ABR for MPLS. To the extent that MPLS differs from ATM, > the differences are (mostly) intentional and IMHO ommision of an ABR > like capability (given that ABR didn't work well in IP networks due to > interactions between the ABR feedback loop and the TCP end-to-end > feedback loop) is also intentional and it should stay that way. > > Curtis ------_=_NextPart_001_01BFCB4A.9A8605DA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: MPLS - ATM interworking?

Curtis,

    >ECN !=3D ABR
    >ECN !=3D EFCI

    Really? I thought they were the = same thing. It is my fault, I should have continued my education, = instead of dropping out at the elementary school and play soccer = :-)

    Seriously, I believe that the = ABR difficulties were related to the fact that it was an end-to-end = mechanism rather than an edge-to-edge, so it followed the destiny of = native end-to-end ATM applications.

    But that is "acqua = passata", let us move on.

    My only point is that as a = provider I have to configure, monitor, doing something with my = Lisps-based ECN bits at my edge router, without giving me any = possibility to act on that, and that does not sound very appealing to = me. To an end customer (mine, I mean), that is a different = story.

    Sergio


    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   Curtis Villamizar = [SMTP:curtis@avici.com]
    Sent:   Wednesday, May 31, 2000 1:41 PM
    To:     CATANZARITI Sergio FTR&D/TI
    Cc:     'Shahram Davari'; mpls@UU.NET; 'Andrzej Czerczak'; = rraszuk@cisco.com
    Subject:       = Re: MPLS - ATM interworking?


    In message = <337055FBC675D311A85D00508B5A9C4F2542C4@u-mail.rd.francetelecom.com&g= t;
    , CATANZARITI Sergio = FTR&D/TI writes:
    >
    > =       ECN in an MPLS network is supposed to = signal congestion in an
    > edge-to-edge fashion = (different from end-to-end) where the LERs could
    > cooperate on that.

    Shahram already pointed to = RFC2481 and draft-ietf-mpls-ecn-00.txt but
    perhaps a brief explanation = will help.

    When an LSP is set up as ECN = capable, the underlying traffic must be
    capable of supporting = end-to-end ECN as specified in RFC2481.  This
    means the L3PID in the MPLS = setup must indicate IPv4 (or IPv6, but let
    discuss IPv4 for the = moment).  For each IPv4 packet arriving at the
    ingress, if the IPv4 header = indicates that the packet has the ECT
    (ECN-Capable Transport) bit is = set and the CE bit is not (Congestion
    Experienced), then the MPLS ECN = bit is set.

    If later an LSR implementing = active queue management (for example RED,
    Random Early Detection) = experiences congestion and would have dropped
    a packet, if the MPLS ECN bit = is set, then it is cleared.  Note that
    at a second congestion point, = an actual drop would occur, unlike the
    two bit scheme.  At the = egress where the POP occurs, if the MPLS ECN
    bit is clear and the ECT bit is = set in the underlying IP header, then
    the CE bit is set in the IP = header.

    Same would apply to IPv4 or any = other protocol that implements a
    compatible ECN scheme = (currently there are no others).

    > =       Absolutely, I want to associate LSPs = with congestion dynamics to
    > eventually slow them down. = How can I do that? That's the question.

    ECN !=3D ABR
    ECN !=3D EFCI

    There is no ABR for MPLS.  = To the extent that MPLS differs from ATM,
    the differences are (mostly) = intentional and IMHO ommision of an ABR
    like capability (given that ABR = didn't work well in IP networks due to
    interactions between the ABR = feedback loop and the TCP end-to-end
    feedback loop) is also = intentional and it should stay that way.

    Curtis

------_=_NextPart_001_01BFCB4A.9A8605DA-- From owner-mpls@UU.NET Wed May 31 22:02: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 WAA00731 for ; Wed, 31 May 2000 22:02: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 QQirqe20654; Thu, 1 Jun 2000 02:02:18 GMT Received: by mail-control.mail.uu.net id QQirqe28834 for mpls-outgoing; Thu, 1 Jun 2000 02:01: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 QQirqe28694 for ; Thu, 1 Jun 2000 02:01: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 QQirqe29891 for ; Wed, 31 May 2000 22:01: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 QQirqe16724 for ; Thu, 1 Jun 2000 02:01:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA15282 for mpls@uu.net; Wed, 31 May 2000 22:01: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 QQirqe27854 for ; Thu, 1 Jun 2000 02:01:31 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 QQirqe28245 for ; Wed, 31 May 2000 22:01:21 -0400 (EDT) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQirqe20018 for ; Thu, 1 Jun 2000 02:01:21 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-59.cisco.com [144.254.139.59]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id TAA26316; Wed, 31 May 2000 19:00:06 -0700 (PDT) Message-Id: <4.3.1.2.20000601114522.00ad5b40@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 01 Jun 2000 11:58:59 +1000 To: From: Jeremy Lawrence Subject: RE: MPLS Performance analysis..... Cc: "'Sean Doran'" , "'Martin Cooper'" , In-Reply-To: <008f01bfcb3c$2243acc0$d001010a@tst.ennovatenetworks.com> References: <52u2feczlw.fsf@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 16:09 05/31/2000 -0400, Brijesh Kumar wrote: [...] >When MPLS work started the enhancing the speed of IP route look up was a key >motivator behind the technology. Not really, except in the mind of certain marketers who yelled "[Company X] is only doing MPLS because they can't get their routers working fast enough". Company X, in the meantime, knew that MPLS was only a marginal performance improvement over a good IPv4 longest-prefix match implementation. :) There is one grain of truth in that fast IPv6 longest-prefix match algorithms are harder to come by, and MPLS was considered as a solution to that problem. Jeremy