From owner-mpls@UU.NET Thu Mar 1 01:22:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14213 for ; Thu, 1 Mar 2001 01:22:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkekv15319; Thu, 1 Mar 2001 06:21:53 GMT Received: by mail-control.mail.uu.net id QQkekv21824 for mpls-outgoing; Thu, 1 Mar 2001 06:21:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkekv21768 for ; Thu, 1 Mar 2001 06:21:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkekv09959 for ; Thu, 1 Mar 2001 06:20:39 GMT Received: from mx1out.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.253.51]) id QQkekv24294 for ; Thu, 1 Mar 2001 06:20:39 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id BAA28085; Thu, 1 Mar 2001 01:20:38 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id BAA1905755; Thu, 1 Mar 2001 01:20:38 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Thu, 1 Mar 2001 01:20:38 -0500 From: Vijay Gill X-X-Sender: To: Kireeti Kompella cc: Subject: Re: Expanded ERO draft In-Reply-To: <200102272224.OAA27375@kummer.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 27 Feb 2001, Kireeti Kompella wrote: > As Yakov said, no concrete reason for adding the router ID has been > given. However, we've wasted enough time and bandwidth. Let's put > this to vote: > > Who all think that adding a router ID to the unnumbered ERO subobject > would be beneficial? A simple yes, no or don't care, please. I would listen to what the people who are implementing this have to say on the subject. I particularly don't care about the bandwidth/extra bytes argument, but as a service provider, I do care that the people who are implementing this do this in the simplest way possible. It makes for robust code and I like robust code because getting up in the AM really really annoys me. So my vote ranking system would go like this ;) People who are writing this code (developers): 10x People who are the protocol architects: 2x Other people: 1x Lets hear it from the implementors: thank you /vijay From owner-mpls@UU.NET Thu Mar 1 01:48:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16972 for ; Thu, 1 Mar 2001 01:48:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkekx18190; Thu, 1 Mar 2001 06:48:14 GMT Received: by mail-control.mail.uu.net id QQkekx24370 for mpls-outgoing; Thu, 1 Mar 2001 06:47:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkekx24358 for ; Thu, 1 Mar 2001 06:47:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkekx17661 for ; Thu, 1 Mar 2001 06:47:41 GMT Received: from mx1out.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.253.51]) id QQkekx14624 for ; Thu, 1 Mar 2001 06:47:41 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id BAA28381; Thu, 1 Mar 2001 01:47:40 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id BAA1955453; Thu, 1 Mar 2001 01:47:39 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Thu, 1 Mar 2001 01:47:39 -0500 From: Vijay Gill X-X-Sender: To: Jim Boyle , Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt In-Reply-To: <0E2DFCE7E586904DA0F583CB5EAD73CC031290@WATERTOWN.litchfieldcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 27 Feb 2001, Dave Danenberg wrote: > Jim, > > Thanx for your input. It sounds like you'd like to see the same sort of > statistical information from the emulated SONET that folks are > accustomed to seeing from SONET networking equipment. I like that too > (from years of developing telecomm equipment for service providers). I am slow on the uptake here, but excuse me if I'm getting this wrong: there are people who are trying to implement SONET private line over asynchronous IP transport (including MPLS)? From talking with people who were implementing Private Line at the DS-1/DS-3 level over OC-12 trunked ATM switches, and hearing about the problems they encountered, I am not sure if this is something worth spending time on. MPLS barely functions as an adequate traffic engineering tool, lets get that right before we go off trying to stuff everything under the sun into MPLS. More stuff you add, the more resources you spend implementing new features instead of trying to fix bugs, and more stuff there is to break. Of course this has no technical content germane to the discussion, these are some thoughts from someone who has to run and support this mess. thank you /vijay From owner-mpls@UU.NET Thu Mar 1 03:25:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28199 for ; Thu, 1 Mar 2001 03:25:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeld16385; Thu, 1 Mar 2001 08:25:06 GMT Received: by mail-control.mail.uu.net id QQkeld04852 for mpls-outgoing; Thu, 1 Mar 2001 08:24:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeld04835 for ; Thu, 1 Mar 2001 08:24:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeld25463 for ; Thu, 1 Mar 2001 08:24:15 GMT Received: from front1m.grolier.fr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: front1m.grolier.fr [195.36.216.51]) id QQkeld13477 for ; Thu, 1 Mar 2001 08:24:15 GMT Received: from nico (nas11-155.wms.club-internet.fr [213.44.38.155]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id JAA14382 for ; Thu, 1 Mar 2001 09:24:12 +0100 (MET) Message-ID: <009d01c0a228$ddea8660$e0262cd5@nico> Reply-To: "Weinberg Nicolas" From: "Weinberg Nicolas" To: References: Subject: Question about scientific works Date: Thu, 1 Mar 2001 09:23:15 +0100 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 Hi everybody, I currently try to find out where scientific work and research about MPLS is done : universities, vendor's labs ?... Is there a URL with such info ? Thanks N Weinberg 04 91 08 44 59 nikoz@club-internet.fr Marseille, France From owner-mpls@UU.NET Thu Mar 1 06:07:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29406 for ; Thu, 1 Mar 2001 06:07:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkelo08263; Thu, 1 Mar 2001 11:07:02 GMT Received: by mail-control.mail.uu.net id QQkelo03677 for mpls-outgoing; Thu, 1 Mar 2001 11:06:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkelo03668 for ; Thu, 1 Mar 2001 11:06:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkelo00997 for ; Thu, 1 Mar 2001 11:05:59 GMT Received: from x86unx3.comp.nus.edu.sg by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: x86unx3.comp.nus.edu.sg [137.132.90.2]) id QQkelo17488 for ; Thu, 1 Mar 2001 11:05:57 GMT Received: from decunx.comp.nus.edu.sg (kaleelaz@decunx-m.comp.nus.edu.sg [137.132.90.9]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with ESMTP id TAA10656 for ; Thu, 1 Mar 2001 19:05:54 +0800 (GMT-8) Received: from localhost (kaleelaz@localhost) by decunx.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id TAA29123 for ; Thu, 1 Mar 2001 19:05:54 +0800 (SST) Date: Thu, 1 Mar 2001 19:05:54 +0800 (SST) From: Kaleelazhicathu R R Kumar To: mpls@UU.NET Subject: ECN in MPLS!! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk hi, is there any new draft which is a successor of draft-ietf-mpls-ecn-00.txt, which talks about proposal to incorporate ECN in MPLS?? "Man who drive like hell is bound to get there!" confucius From owner-mpls@UU.NET Thu Mar 1 07:47:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01703 for ; Thu, 1 Mar 2001 07:47:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkelv15248; Thu, 1 Mar 2001 12:46:16 GMT Received: by mail-control.mail.uu.net id QQkelv26491 for mpls-outgoing; Thu, 1 Mar 2001 12:45:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkelv26483 for ; Thu, 1 Mar 2001 12:45:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkelv12546 for ; Thu, 1 Mar 2001 12:45:41 GMT Received: from wiprom2mx2.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQkelv13977 for ; Thu, 1 Mar 2001 12:45:36 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id SAA03280 for ; Thu, 1 Mar 2001 18:54:59 +0530 Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA6AEB; Thu, 1 Mar 2001 16:39:38 +0530 Date: Thu, 1 Mar 2001 16:47:26 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: Kaleelazhicathu R R Kumar cc: mpls@UU.NET Subject: Re: ECN in MPLS!! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 1 Mar 2001, Kaleelazhicathu R R Kumar wrote: > hi, > is there any new draft which is a successor of > draft-ietf-mpls-ecn-00.txt, which talks about proposal to incorporate ECN Yes, there is a draft draft-shayman-mpls-ecn-00.txt, not excatly successor.. Thanks Chetan S > in MPLS?? > > > > "Man who drive like hell is bound to get there!" > confucius > > > > > > > > > > > From owner-mpls@UU.NET Thu Mar 1 09:43:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05440 for ; Thu, 1 Mar 2001 09:43:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemc09205; Thu, 1 Mar 2001 14:42:00 GMT Received: by mail-control.mail.uu.net id QQkemc08552 for mpls-outgoing; Thu, 1 Mar 2001 14:41:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkemc08494 for ; Thu, 1 Mar 2001 14:41:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkemc24396 for ; Thu, 1 Mar 2001 14:40:05 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkemc13993 for ; Thu, 1 Mar 2001 14:40: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 GAA12411 for ; Thu, 1 Mar 2001 06:40:20 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02339 for mpls@uu.net; Thu, 1 Mar 2001 09:40:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkejg04521 for ; Wed, 28 Feb 2001 20:08:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkejg00074 for ; Wed, 28 Feb 2001 20:08:27 GMT Received: from web12810.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web12810.mail.yahoo.com [216.136.174.97]) id QQkejg02442 for ; Wed, 28 Feb 2001 20:08:26 GMT Message-ID: <20010228200826.92714.qmail@web12810.mail.yahoo.com> Received: from [152.148.114.81] by web12810.mail.yahoo.com; Wed, 28 Feb 2001 12:08:26 PST Date: Wed, 28 Feb 2001 12:08:26 -0800 (PST) From: narakasura Dumbo Subject: RSVP & OSPF-TE ... To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I have a couple of questions 1. How do we signal the "color" (32 colors that can be assigned to a link, Katz OSPF-TE draft) using RSVP-TE ? Is this addressed somewhere ? 2. Is there a plan to add interface index as part of OSPF-TE ? Is yes, when is it expected to be available ? Thanks Pappai __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Thu Mar 1 09:44:01 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05486 for ; Thu, 1 Mar 2001 09:44:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemc19420; Thu, 1 Mar 2001 14:42:14 GMT Received: by mail-control.mail.uu.net id QQkemc08577 for mpls-outgoing; Thu, 1 Mar 2001 14:41:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkemc08566 for ; Thu, 1 Mar 2001 14:41:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkemc02855 for ; Thu, 1 Mar 2001 14:41:02 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkemc24956 for ; Thu, 1 Mar 2001 14:41: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 GAA14619 for ; Thu, 1 Mar 2001 06:41:19 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02353 for mpls@uu.net; Thu, 1 Mar 2001 09:41:00 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkemc07486 for ; Thu, 1 Mar 2001 14:32:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkemc05637 for ; Thu, 1 Mar 2001 14:32:09 GMT Received: from web12806.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web12806.mail.yahoo.com [216.136.174.41]) id QQkemc25929 for ; Thu, 1 Mar 2001 14:32:09 GMT Message-ID: <20010301143207.59913.qmail@web12806.mail.yahoo.com> Received: from [152.148.114.81] by web12806.mail.yahoo.com; Thu, 01 Mar 2001 06:32:07 PST Date: Thu, 1 Mar 2001 06:32:07 -0800 (PST) From: Narakasura Dumbo Subject: Re: RSVP & OSPF-TE ... To: Tatsuya Yanagibashi Cc: narakasura Dumbo , mpls@UU.NET In-Reply-To: <3A9D9A60.D8F0C57E@cosinecom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Tatsuya, Thanks for the reply. My question is where is this "color" constraint carried in the RSVP PATH message ? Thanks Pappai --- Tatsuya Yanagibashi wrote: > Pappai, > > narakasura Dumbo wrote: > > > > I have a couple of questions > > > > 1. How do we signal the "color" (32 colors that > > can be assigned to a link, Katz OSPF-TE draft) > > using RSVP-TE ? Is this addressed somewhere > ? > > Conceptually the information of TE such like a > "color" is used for > calculating the PATH under administrative > constraints in MPLS cloud. > Currently CSPF is able to handle its calculation. > After its computation > and calculation, Ingress LSR is going to SIGNAL by > using RSVP-TE or > CR-LDP with ER(O) along the path by CSPF > calculation. > > Rgds, > Tatsuya > > -- > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > +----+----+ Tatsuya Yanagibashi > > |.. .| | > |_~__| | Network Consultant > | .. |~~_~| CoSine Communications > Inc. > | . | | > +----+----+ e-mail: > tyanagibashi@cosinecom.com > C o S i n e Phone # +81-3-5219-1292 > Communications Fax # +81-3-5219-1201 > > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Thu Mar 1 09:48:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05667 for ; Thu, 1 Mar 2001 09:48:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemc27530; Thu, 1 Mar 2001 14:42:55 GMT Received: by mail-control.mail.uu.net id QQkemc08584 for mpls-outgoing; Thu, 1 Mar 2001 14:41:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkemc08571 for ; Thu, 1 Mar 2001 14:41:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkemc15073 for ; Thu, 1 Mar 2001 14:40:53 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkemc24755 for ; Thu, 1 Mar 2001 14:40: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 GAA14480 for ; Thu, 1 Mar 2001 06:41:11 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02349 for mpls@uu.net; Thu, 1 Mar 2001 09:40:51 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkekd08245 for ; Thu, 1 Mar 2001 01:50:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkekd04569 for ; Thu, 1 Mar 2001 01:50:04 GMT Received: from smtp.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQkekd19100 for ; Thu, 1 Mar 2001 01:50:03 GMT Received: from tom ([10.110.9.163]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G9HWXF02.Y0I for ; Thu, 1 Mar 2001 09:46:27 +0800 Message-ID: <001801c0a1f1$fc96b7a0$a3096e0a@tom.huawei.com> From: "zhang" To: Subject: help for ldp state machine Date: Thu, 1 Mar 2001 09:50:24 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C0A235.09BFB920" 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_0015_01C0A235.09BFB920 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Dear Mr(Mrs), would you please answer my questions? First,the ldp state machine is same as cr-ldp state machine, isn't it? Second, in 'LDP State Machine'(draft-ietf-mpls-ldp-state-03.txt), Trigger Control Block contains what information? =20 Third,3.1.5.1 State -- "IDLE" =20 State: IDLE =20 Event: LDP Request =20 New State: Depends upon the action routine. =20 Actions: =20 If this LSR is the LSP Egress or Proxy Egress [2] =20 Then: Choose an upstream label, connect this upstream label to the local IP forwarding module, allocate the resources, send the LDP-MAPPING upstream with the upstream label, and go to the new state `ESTABLISHED'. =20 else Obtain a next hop (or interface) with the FEC specified in the LDP-REQUEST, propagate the LDP-REQUEST, with newly assigned Message ID by this LSR, towards the obtained next hop, and go to the new state `RESPONSE_AWAITED'. =20 If the LSR uses the independent control mode [2], choose an upstream label, connect this upstream label to the local IP forwarding module, go to the ESTABLISHED state and send an LDP- MAPPING upstream with the upstream label. =20 If unable to process the request for any reason, issue an LDP-NAK to the sender with the appropriate error code, go to IDLE and delete the LSP Control Block. I think ESTABLISHED should be RESPONSE_AWAITED, is it true? =20 Thank you very much. =20 regards, Zhang Huachen ------=_NextPart_000_0015_01C0A235.09BFB920 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Dear=20 Mr(Mrs),
  would you=20 please answer my questions?
 First,the ldp=20 state machine is same as cr-ldp state machine, isn't = it?
 Second, in=20 'LDP State = Machine'(draft-ietf-mpls-ldp-state-03.txt),
Trigger Control=20 Block contains what information?
 
Third,3.1.5.1 State = --=20 "IDLE"
 
 State:         = =20 IDLE
 
 Event:         = =20 LDP Request
 
 New=20 State:      Depends upon the action=20 routine.
 
 Actions:
 
   If this = LSR is the=20 LSP Egress or Proxy Egress [2]
 
  =20 Then:
     Choose an upstream label, connect this = upstream label to the local
     IP forwarding = module,=20 allocate the resources, send the LDP-MAPPING
     = upstream with the upstream label, and go to the new=20 state
     `ESTABLISHED'.
 
  =20 else
     Obtain a next hop (or interface) with = the FEC=20 specified in the
     LDP-REQUEST, propagate the=20 LDP-REQUEST, with newly assigned Message
     ID = by this=20 LSR, towards the obtained next hop, and go to the=20 new
     state = `RESPONSE_AWAITED'.
 
     If the=20 LSR uses the independent control mode [2], choose = an
    =20 upstream label, connect this upstream label to the local=20 IP
     forwarding module, go to the=20 ESTABLISHED state and send an=20 LDP-
     MAPPING upstream with the upstream=20 label.
 
   If = unable to process=20 the request for any reason, issue an LDP-NAK to
   the = sender with=20 the appropriate error code, go to IDLE and delete the
   = LSP=20 Control Block.
I think=20 ESTABLISHED  should be RESPONSE_AWAITED, = is it=20 true?
 
Thank = you very=20 much.
 
regards,
Zhang=20 Huachen
------=_NextPart_000_0015_01C0A235.09BFB920-- From owner-mpls@UU.NET Thu Mar 1 10:04:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06294 for ; Thu, 1 Mar 2001 10:04:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeme08303; Thu, 1 Mar 2001 15:01:13 GMT Received: by mail-control.mail.uu.net id QQkeme12419 for mpls-outgoing; Thu, 1 Mar 2001 15:00:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeme12108 for ; Thu, 1 Mar 2001 15:00:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeme03045 for ; Thu, 1 Mar 2001 15:00:20 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQkeme02075 for ; Thu, 1 Mar 2001 15:00:19 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f21EwUe03974; Thu, 1 Mar 2001 09:58:30 -0500 (EST) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Mar 2001 09:53:37 -0500 Message-ID: <0CD7D73C734BD411AEE100B0D0220404DFDDBE@mail1.tellium.com> From: Bala Rajagopalan To: "'Vijay Gill'" Cc: mpls@UU.NET Subject: RE: Expanded ERO draft Date: Thu, 1 Mar 2001 09:53:35 -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 Vijay: This weighting system is a good idea. In fact, I think the weighting should be applied to votes on all contentious proposals. I would also add the following weights to your suggestion: - People who are writing code (developers): 10x - People who really aren't writing code, but claiming to do so: 0x - People who vaguely claim that some "customers" want the feature: 0x - People who aren't aware of the issue, but simply support one proposal or another to please somebody: 0x - People who are the protocol architects: 2x - Other people: 1x The only trouble with this scheme is, you may not have any votes left to count. But then, who cares? (as witnessed by lack of response to this voting call). BR - Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Vijay Gill [mailto:vijay@umbc.edu] > Sent: Thursday, March 01, 2001 1:21 AM > To: Kireeti Kompella > Cc: mpls@UU.NET > Subject: Re: Expanded ERO draft > > > On Tue, 27 Feb 2001, Kireeti Kompella wrote: > > > As Yakov said, no concrete reason for adding the router ID has been > > given. However, we've wasted enough time and bandwidth. Let's put > > this to vote: > > > > Who all think that adding a router ID to the unnumbered ERO > subobject > > would be beneficial? A simple yes, no or don't care, please. > > I would listen to what the people who are implementing this > have to say on > the subject. I particularly don't care about the bandwidth/extra bytes > argument, but as a service provider, I do care that the people who are > implementing this do this in the simplest way possible. It makes for > robust code and I like robust code because getting up in the AM really > really annoys me. > > So my vote ranking system would go like this ;) > > People who are writing this code (developers): 10x > People who are the protocol architects: 2x > Other people: 1x > > Lets hear it from the implementors: > > thank you > > /vijay > From owner-mpls@UU.NET Thu Mar 1 10:41:15 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07542 for ; Thu, 1 Mar 2001 10:41:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemg13825; Thu, 1 Mar 2001 15:38:11 GMT Received: by mail-control.mail.uu.net id QQkemg29370 for mpls-outgoing; Thu, 1 Mar 2001 15:37:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkemg29323 for ; Thu, 1 Mar 2001 15:37:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkemg23142 for ; Thu, 1 Mar 2001 15:36:15 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkemg28503 for ; Thu, 1 Mar 2001 15:36:15 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id CD47A94006; Thu, 1 Mar 2001 10:36:14 -0500 (EST) Message-ID: <3A9E6C6E.99ADBA1D@sandburst.com> Date: Thu, 01 Mar 2001 10:36:14 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: zhang Cc: mpls@UU.NET Subject: Re: help for ldp state machine References: <001801c0a1f1$fc96b7a0$a3096e0a@tom.huawei.com> Content-Type: multipart/alternative; boundary="------------ADB7D7448B8778FFD86E94F9" Sender: owner-mpls@UU.NET Precedence: bulk --------------ADB7D7448B8778FFD86E94F9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhang, Zeroeth question: Sure, be glad to. :-) First question: Yes. Second question: The contents of the trigger control block are implementation dependent. The basic idea is that some event caused the sending of a label request message and the trigger control block is used to asynchronously tie the causal event to the eventual response. Third question: No. Whenever the local LSR sends a label mapping. the LSP is established from its perspective. -- Eric Gray You wrote: > Dear Mr(Mrs), would you please answer my questions? First,the ldp > state machine is same as cr-ldp state machine, isn't it? Second, in > 'LDP State Machine'(draft-ietf-mpls-ldp-state-03.txt),Trigger Control > Block contains what information? Third,3.1.5.1 State -- > "IDLE" State: IDLE Event: LDP Request New > State: Depends upon the action routine. Actions: If this LSR > is the LSP Egress or Proxy Egress [2] Then: > Choose an upstream label, connect this upstream label to the > local > IP forwarding module, allocate the resources, send the > LDP-MAPPING > upstream with the upstream label, and go to the new state > `ESTABLISHED'. else > Obtain a next hop (or interface) with the FEC specified in the > LDP-REQUEST, propagate the LDP-REQUEST, with newly assigned > Message > ID by this LSR, towards the obtained next hop, and go to the new > state `RESPONSE_AWAITED'. If the LSR uses the independent > control mode [2], choose an > upstream label, connect this upstream label to the local IP > forwarding module, go to the ESTABLISHED state and send an LDP- > MAPPING upstream with the upstream label. If unable to process > the request for any reason, issue an LDP-NAK to > the sender with the appropriate error code, go to IDLE and delete > the > LSP Control Block. > I think ESTABLISHED should be RESPONSE_AWAITED, is it true? Thank you > very much. regards,Zhang Huachen --------------ADB7D7448B8778FFD86E94F9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Zhang,

    Zeroeth question: Sure, be glad to.  :-)

    First question: Yes.

    Second question: The contents of the trigger control block
are implementation dependent.  The basic idea is that some
event caused the sending of a label request message and the
trigger control block is used to asynchronously tie the causal
event to the eventual response.

    Third question: No. Whenever the local LSR sends a label
mapping. the LSP is established from its perspective.

--
Eric Gray

You wrote:

 Dear Mr(Mrs),  would you please answer my questions? First,the ldp state machine is same as cr-ldp state machine, isn't it? Second, in 'LDP State Machine'(draft-ietf-mpls-ldp-state-03.txt),Trigger Control Block contains what information? Third,3.1.5.1 State -- "IDLE"  State:          IDLE  Event:          LDP Request  New State:      Depends upon the action routine.  Actions:    If this LSR is the LSP Egress or Proxy Egress [2]    Then:
     Choose an upstream label, connect this upstream label to the local
     IP forwarding module, allocate the resources, send the LDP-MAPPING
     upstream with the upstream label, and go to the new state
     `ESTABLISHED'.    else
     Obtain a next hop (or interface) with the FEC specified in the
     LDP-REQUEST, propagate the LDP-REQUEST, with newly assigned Message
     ID by this LSR, towards the obtained next hop, and go to the new
     state `RESPONSE_AWAITED'.      If the LSR uses the independent control mode [2], choose an
     upstream label, connect this upstream label to the local IP
     forwarding module, go to the ESTABLISHED state and send an LDP-
     MAPPING upstream with the upstream label.    If unable to process the request for any reason, issue an LDP-NAK to
   the sender with the appropriate error code, go to IDLE and delete the
   LSP Control Block.
I think ESTABLISHED  should be RESPONSE_AWAITED, is it true? Thank you very much. regards,Zhang Huachen
--------------ADB7D7448B8778FFD86E94F9-- From owner-mpls@UU.NET Thu Mar 1 11:24:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09039 for ; Thu, 1 Mar 2001 11:24:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemj15846; Thu, 1 Mar 2001 16:22:36 GMT Received: by mail-control.mail.uu.net id QQkemj19752 for mpls-outgoing; Thu, 1 Mar 2001 16:22:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkemj19716 for ; Thu, 1 Mar 2001 16:21:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkemj10211 for ; Thu, 1 Mar 2001 16:21:50 GMT Received: from edgeflow.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.191.40.82]) id QQkemj14615 for ; Thu, 1 Mar 2001 16:21:50 GMT Received: from edgsvr01.edgeflow.edgeflow.com ([10.0.1.10]) by watchdog.edgeflow.com with ESMTP id <119042>; Thu, 1 Mar 2001 11:21:40 -0500 Received: by edgsvr01.edgeflow.edgeflow.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Mar 2001 11:18:14 -0500 Message-ID: <89E067900D3FA84A97495C71556140E41B6020@edgsvr01.edgeflow.edgeflow.com> From: Martin Dubuc To: "'mpls@UU.NET'" Subject: draft-dubuc-mpls-bundle-mib-00.txt Date: Thu, 1 Mar 2001 11:18:13 -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 The first version of the Link Bundling MIB is available at: http://www.ietf.org/internet-drafts/draft-dubuc-mpls-bundle-mib-00.txt Martin Dubuc edgeflow Inc. From owner-mpls@UU.NET Thu Mar 1 11:26:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09131 for ; Thu, 1 Mar 2001 11:26:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemj13708; Thu, 1 Mar 2001 16:21:13 GMT Received: by mail-control.mail.uu.net id QQkemj19661 for mpls-outgoing; Thu, 1 Mar 2001 16:20:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkemj19656 for ; Thu, 1 Mar 2001 16:20:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkemj05913 for ; Thu, 1 Mar 2001 16:20:00 GMT Received: from edgeflow.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.191.40.82]) id QQkemj26491 for ; Thu, 1 Mar 2001 16:20:00 GMT Received: from edgsvr01.edgeflow.edgeflow.com ([10.0.1.10]) by watchdog.edgeflow.com with ESMTP id <119041>; Thu, 1 Mar 2001 11:19:55 -0500 Received: by edgsvr01.edgeflow.edgeflow.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Mar 2001 11:16:29 -0500 Message-ID: <89E067900D3FA84A97495C71556140E41B601F@edgsvr01.edgeflow.edgeflow.com> From: Martin Dubuc To: "'mpls@UU.NET'" Subject: draft-dubuc-lmp-mib-01.txt Date: Thu, 1 Mar 2001 11:16:28 -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 The new version of the LMP MIB is available at: http://www.ietf.org/internet-drafts/draft-dubuc-lmp-mib-01.txt Martin Dubuc edgeflow Inc. From owner-mpls@UU.NET Thu Mar 1 11:58:36 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10619 for ; Thu, 1 Mar 2001 11:58:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeml19260; Thu, 1 Mar 2001 16:56:55 GMT Received: by mail-control.mail.uu.net id QQkeml22565 for mpls-outgoing; Thu, 1 Mar 2001 16:56:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeml22555 for ; Thu, 1 Mar 2001 16:56:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeml08614 for ; Thu, 1 Mar 2001 16:54:49 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeml05239 for ; Thu, 1 Mar 2001 16:54:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA28419 for mpls@uu.net; Thu, 1 Mar 2001 11:54:47 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeml22410 for ; Thu, 1 Mar 2001 16:54:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeml18670 for ; Thu, 1 Mar 2001 16:53:02 GMT Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prattle.redback.com [155.53.12.9]) id QQkeml12622 for ; Thu, 1 Mar 2001 16:53:02 GMT Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 5084C39BC2E; Thu, 1 Mar 2001 08:52:56 -0800 (PST) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id IAA06568; Thu, 1 Mar 2001 08:52:55 -0800 (PST) Date: Thu, 1 Mar 2001 08:52:55 -0800 From: Rahul Aggarwal To: Vijay Gill Cc: Kireeti Kompella , mpls@UU.NET Subject: Re: Expanded ERO draft Message-ID: <20010301085255.B6015@malt.redback.com> References: <200102272224.OAA27375@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from vijay@umbc.edu on Thu, Mar 01, 2001 at 01:20:38AM -0500 Sender: owner-mpls@UU.NET Precedence: bulk This is coming from a developer : ) I was in favor of adding a router id to the unnumbered ERO subobject when the subject was discussed on the list a while back. Its cleaner to implement. At the same time I think most of the information in the expanded ERO draft is redundant. An informational doc on the current usage will be of more value than adding new objects all over the place. Some rewording in the RSVP-TE draft will also help. Its a yes to adding a router id to the unnumbered ERO subobject. thanks, rahul On Thu, Mar 01, 2001 at 01:20:38AM -0500, Vijay Gill wrote: > On Tue, 27 Feb 2001, Kireeti Kompella wrote: > > > As Yakov said, no concrete reason for adding the router ID has been > > given. However, we've wasted enough time and bandwidth. Let's put > > this to vote: > > > > Who all think that adding a router ID to the unnumbered ERO subobject > > would be beneficial? A simple yes, no or don't care, please. > > I would listen to what the people who are implementing this have to say on > the subject. I particularly don't care about the bandwidth/extra bytes > argument, but as a service provider, I do care that the people who are > implementing this do this in the simplest way possible. It makes for > robust code and I like robust code because getting up in the AM really > really annoys me. > > So my vote ranking system would go like this ;) > > People who are writing this code (developers): 10x > People who are the protocol architects: 2x > Other people: 1x > > Lets hear it from the implementors: > > thank you > > /vijay > From owner-mpls@UU.NET Thu Mar 1 12:02:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10873 for ; Thu, 1 Mar 2001 12:02:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemm24563; Thu, 1 Mar 2001 17:00:36 GMT Received: by mail-control.mail.uu.net id QQkemm24543 for mpls-outgoing; Thu, 1 Mar 2001 17:00:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkemm23796 for ; Thu, 1 Mar 2001 17:00:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeml07558 for ; Thu, 1 Mar 2001 16:59:11 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkeml07961 for ; Thu, 1 Mar 2001 16:59:11 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f21GxAb12120 for ; Thu, 1 Mar 2001 17:59:10 +0100 (MET) Received: from alcatel.be ([138.203.169.199]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A02.005D4817; Thu, 1 Mar 2001 17:58:53 +0100 Message-ID: <3A9E7FD3.BC0A0454@alcatel.be> Date: Thu, 01 Mar 2001 17:58:59 +0100 From: Paul Moore Organization: Alcatel Bell X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Question about mplsTunnelTable in TE MIB, draft 5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Looking at the mplsTunnelTable in the TE MIB, draft 05, I've noticed the mplsPathInUse object, defined as follows: mplsTunnelPathInUse OBJECT-TYPE SYNTAX MplsPathIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This value denotes the configured path that was chosen for this tunnel. This value reflects the secondary index into the TunnelHopTable. This path may not exactly match the one in the ARHopTable due to the fact that some CSPF modification may have taken place. See the ARHopTable for the actual path being taken by the tunnel. A value of zero denotes that no path is currently in use or available." ::= { mplsTunnelEntry 30 } Since there is a separate entry in the mplsTunnelTable for each tunnel instance, and each tunnel instance can have only one configured path associated with it, why is this extra index into the mplsTunnelHopTable also necessary? Surely the mplsTunnelHopTableIndex is sufficient to uniquely identify the explicit route? Or is it a way to indicate which tunnel instance is the currently active one, in the case where multiple instances of a tunnel have been configured? Many thanks, Paul -- Paul Moore Alcatel Bell +32 3 450 3536 paul-patrick.moore@alcatel.be From owner-mpls@UU.NET Thu Mar 1 12:09:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11047 for ; Thu, 1 Mar 2001 12:09:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemm20527; Thu, 1 Mar 2001 17:02:33 GMT Received: by mail-control.mail.uu.net id QQkemm01139 for mpls-outgoing; Thu, 1 Mar 2001 17:02:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkemm00538 for ; Thu, 1 Mar 2001 17:02:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkemm24549 for ; Thu, 1 Mar 2001 17:01:48 GMT Received: from alemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQkemm12851 for ; Thu, 1 Mar 2001 17:01:47 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA12023 for ; Thu, 1 Mar 2001 12:01:47 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA12015; Thu, 1 Mar 2001 12:01:46 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA12759; Thu, 1 Mar 2001 12:01:30 -0500 (EST) Message-ID: <3A9E806A.334C53EC@lucent.com> Date: Thu, 01 Mar 2001 12:01:30 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Rahul Aggarwal CC: Vijay Gill , Kireeti Kompella , mpls@UU.NET Subject: Re: Expanded ERO draft References: <200102272224.OAA27375@kummer.juniper.net> <20010301085255.B6015@malt.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Exactly what I think it should be. Yangguang Rahul Aggarwal wrote: > > This is coming from a developer : ) > > I was in favor of adding a router id to the unnumbered ERO subobject > when the subject was discussed on the list a while back. Its cleaner > to implement. > > At the same time I think most of the information in the expanded ERO > draft is redundant. An informational doc on the current usage > will be of more value than adding new objects all over the > place. Some rewording in the RSVP-TE draft will also help. > > Its a yes to adding a router id to the unnumbered ERO subobject. > > thanks, > rahul > > On Thu, Mar 01, 2001 at 01:20:38AM -0500, Vijay Gill wrote: > > On Tue, 27 Feb 2001, Kireeti Kompella wrote: > > > > > As Yakov said, no concrete reason for adding the router ID has been > > > given. However, we've wasted enough time and bandwidth. Let's put > > > this to vote: > > > > > > Who all think that adding a router ID to the unnumbered ERO subobject > > > would be beneficial? A simple yes, no or don't care, please. > > > > I would listen to what the people who are implementing this have to say on > > the subject. I particularly don't care about the bandwidth/extra bytes > > argument, but as a service provider, I do care that the people who are > > implementing this do this in the simplest way possible. It makes for > > robust code and I like robust code because getting up in the AM really > > really annoys me. > > > > So my vote ranking system would go like this ;) > > > > People who are writing this code (developers): 10x > > People who are the protocol architects: 2x > > Other people: 1x > > > > Lets hear it from the implementors: > > > > thank you > > > > /vijay > > From owner-mpls@UU.NET Thu Mar 1 12:20:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11469 for ; Thu, 1 Mar 2001 12:20:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemn22334; Thu, 1 Mar 2001 17:19:46 GMT Received: by mail-control.mail.uu.net id QQkemn11071 for mpls-outgoing; Thu, 1 Mar 2001 17:19:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkemn11058 for ; Thu, 1 Mar 2001 17:19:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkemn02840 for ; Thu, 1 Mar 2001 17:18:22 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkemn15573 for ; Thu, 1 Mar 2001 17:18:21 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f21HIKT14243 for ; Thu, 1 Mar 2001 18:18:20 +0100 (MET) Received: from alcatel.be ([138.203.169.199]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A02.005F0C9F; Thu, 1 Mar 2001 18:18:11 +0100 Message-ID: <3A9E845A.9430FC87@alcatel.be> Date: Thu, 01 Mar 2001 18:18:18 +0100 From: Paul Moore Organization: Alcatel Bell X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Bandwidth question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The MPLS MIB has the table, mplsTrafficParamTable which describes bandwidth allocation for in- and out-segments. The TE MIB also has the table, mplsTunnelResourceTable, which allows the bandwidth required for a tunnel to be specified. Both tables indicate that they can be pointed to multiple times, to indicate that the specified resource should be shared. How would this work in practice, in the case where an operator is trying to set up traffic engineered tunnels? Preseumably, he would specify the bandwidth required, and allow signalling to ensure that the tunnel is set up, ensuring that the various constraints such as bandwidth or explicit route are satisfied. The bandwidth constraint in this case would appear as an entry in the mplsTunnelResourceTable. What then is the purpose of the mplsTrafficParamTable? Is is filled in/updated for each in-and out-segment when the tunnel is finally established? In that case, why should an entry in the table be pointed to multiple times? Or does this table imply that further configuration is required? Confused, Paul From owner-mpls@UU.NET Thu Mar 1 12:23:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11641 for ; Thu, 1 Mar 2001 12:23:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemn26516; Thu, 1 Mar 2001 17:22:28 GMT Received: by mail-control.mail.uu.net id QQkemn11655 for mpls-outgoing; Thu, 1 Mar 2001 17:21:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkemn11626 for ; Thu, 1 Mar 2001 17:21:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkemn19780 for ; Thu, 1 Mar 2001 17:20:20 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkemn20463 for ; Thu, 1 Mar 2001 17:20:19 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 09:19:48 -0800 Message-ID: From: Vach Kompella To: "'mpls@uu.net'" Subject: RE: Expanded ERO draft Date: Thu, 1 Mar 2001 09:19:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk My vote (I didn't see dev. manager, but I run the group that's implementing it, so I speak on their behalf) would be to throw the router ID in there. I think it's great for debugging, too. You can look at an inflight ERO and know exactly what it is supposed to do, without reference to a TED or an LSDB. However, I would rather see a single ERO rather than both an ERO and an EERO, and the mess of having to deal with interoperability, backwards compatibility. -Vach -----Original Message----- From: Rahul Aggarwal [mailto:rahul@redback.com] Sent: Thursday, March 01, 2001 8:53 AM To: Vijay Gill Cc: Kireeti Kompella; mpls@UU.NET Subject: Re: Expanded ERO draft This is coming from a developer : ) I was in favor of adding a router id to the unnumbered ERO subobject when the subject was discussed on the list a while back. Its cleaner to implement. At the same time I think most of the information in the expanded ERO draft is redundant. An informational doc on the current usage will be of more value than adding new objects all over the place. Some rewording in the RSVP-TE draft will also help. Its a yes to adding a router id to the unnumbered ERO subobject. thanks, rahul On Thu, Mar 01, 2001 at 01:20:38AM -0500, Vijay Gill wrote: > On Tue, 27 Feb 2001, Kireeti Kompella wrote: > > > As Yakov said, no concrete reason for adding the router ID has been > > given. However, we've wasted enough time and bandwidth. Let's put > > this to vote: > > > > Who all think that adding a router ID to the unnumbered ERO subobject > > would be beneficial? A simple yes, no or don't care, please. > > I would listen to what the people who are implementing this have to say on > the subject. I particularly don't care about the bandwidth/extra bytes > argument, but as a service provider, I do care that the people who are > implementing this do this in the simplest way possible. It makes for > robust code and I like robust code because getting up in the AM really > really annoys me. > > So my vote ranking system would go like this ;) > > People who are writing this code (developers): 10x > People who are the protocol architects: 2x > Other people: 1x > > Lets hear it from the implementors: > > thank you > > /vijay > From owner-mpls@UU.NET Thu Mar 1 13:17:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14302 for ; Thu, 1 Mar 2001 13:17:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkemq29266; Thu, 1 Mar 2001 18:10:48 GMT Received: by mail-control.mail.uu.net id QQkemq02482 for mpls-outgoing; Thu, 1 Mar 2001 18:10:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkemq02465 for ; Thu, 1 Mar 2001 18:10:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkemq23706 for ; Thu, 1 Mar 2001 18:10:00 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkemq01608 for ; Thu, 1 Mar 2001 18:10:00 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA00383; Thu, 1 Mar 2001 10:09:56 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 10:09:56 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA09450A@avalon.pluris.com> From: Puneet Agarwal To: "'Shahram Davari'" , "'Eric Gray'" Cc: Puneet Agarwal , "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Subject: RE: New TTL Draft Date: Thu, 1 Mar 2001 10:09:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric/Shahram, The draft addresses "all" forms of TTL processing in MPLS networks. The non-hierarchical case is just a special case of the general problem addressed in the draft. And Shahram, I will still go with my proposal which I have cut and pasted here. The reason is that I believe this is a concise and non-repetitive way of describing Pop and subsequent operations. This captures the fact that you can do Pops recursively and that you have to process the exposed packet (IP or MPLS) again to determine the operation (Swap/Swap+Push/PHP/PHP+Push/Pop). 4) Pop : This is the terminating point of an LSP tunnel, in which, first the top label is popped and then the packet is forwarded based on the lower label (or exposed IP header). Note that this operation can occur recursively. The iTTL is updated as explained in section 2.3. The outgoing TTL would be determined by the last non "Pop" operation performed on the packet. -Puneet >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Wednesday, February 28, 2001 8:41 AM >To: 'Eric Gray' >Cc: 'Puneet Agarwal'; 'mpls@uu.net'; 'flefauch@cisco.com'; >'liwwu@cisco.com'; 'bsd@cisco.com'; Bora Akyol >Subject: RE: New TTL Draft > > >Hi Eric, > > >> I see no reason why Puneet's draft should affect TTL processing >> in intermediate LSRs. I believe this is well defined elsewhere. > >Sure, but first the authors should decide what is the >objective of this draft? Is it explaining the TTL processing >after pop or push, in other words is it explaining the TTL >processing at tunnel ingress/egress/penultimate? or is it a >general TTL processing draft that explains TTL processing at >any node be it intermediate or tunnel ingress/egress/penultimate? > >It seems that the authors intend to talk only about tunnel >ingress/egress/penultimate TTL processing. If that is the case >then the draft is misleading because neither the title nor the >text reflect this. Also section 2.3 second paragraph talks >about iTTL determination for push/"SWAP"/php. Which means it >is talking about iTTL determination for a "SWAP" case too, >which is intermediate TTL processing. > >> By the way, an LSR that pops a label is not an intermediate LSR >> with respect to the LSP for which that label applied. >> > >Yes, I guess I know that. > >Thanks, >-Shahram > From owner-mpls@UU.NET Thu Mar 1 15:37:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21951 for ; Thu, 1 Mar 2001 15:37:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkena17073; Thu, 1 Mar 2001 20:36:50 GMT Received: by mail-control.mail.uu.net id QQkena18791 for mpls-outgoing; Thu, 1 Mar 2001 20:36:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkena18784 for ; Thu, 1 Mar 2001 20:36:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkena16113 for ; Thu, 1 Mar 2001 20:35:18 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkena13639 for ; Thu, 1 Mar 2001 20:35:17 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 MAA18507; Thu, 1 Mar 2001 12:35:32 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA03469; Thu, 1 Mar 2001 15:35:14 -0500 (EST) Message-Id: <200103012035.PAA03469@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Bora Akyol cc: akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" Subject: Re: New TTL Draft In-reply-to: Your message of Fri, 23 Feb 2001 07:48:35 -0800. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 01 Mar 2001 15:35:14 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21951 From the draft: > This document describes TTL processing in hierarchical MPLS > networks. We believe that this document adds details that have not > been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods > presented in this document complement [MPLS-DS]. I think it would be helpful for the draft authors to say explicitly where this draft: 1. corrects errors in the RFCs 2. modifies the functionality specified in the RFCS 3. adds new functionality not specified in the RFCs 4. adds details to clarify what is specified in the RFCs. That is, let's try to make sure that we all agree about what changes/ additions are being proposed, and why. It is true that the RFCs are not very clear about the way to handle the case where one doesn't want to percolate the TTL through the label stack ("pipe model"?). Whether the "pipe model" and the "uniform model" always (or ever) need to be distinguished through signalling is another matter. Is the assumption that a service provider might make a different decision for every individual LSP? (In the case of "ordinary" LDP, I think this is somewhat unlikely, and the signalling unnecessary.) From owner-mpls@UU.NET Thu Mar 1 16:37:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24667 for ; Thu, 1 Mar 2001 16:37:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkend18369; Thu, 1 Mar 2001 21:21:10 GMT Received: by mail-control.mail.uu.net id QQkend08369 for mpls-outgoing; Thu, 1 Mar 2001 21:20:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkend08356 for ; Thu, 1 Mar 2001 21:20:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkend13660 for ; Thu, 1 Mar 2001 21:20:22 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkend17145 for ; Thu, 1 Mar 2001 21:20:22 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA24753; Thu, 1 Mar 2001 13:20:37 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA03622; Thu, 1 Mar 2001 16:20:19 -0500 (EST) Message-Id: <200103012120.QAA03622@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Bora Akyol cc: akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" Subject: Re: New TTL Draft In-reply-to: Your message of Fri, 23 Feb 2001 07:48:35 -0800. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 01 Mar 2001 16:20:19 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Consider the following way of handling TTL at the push/pop points: 1. when a label is pushed on a packet, its TTL field is set to either one less than the iTTL, OR to a configured value; 2. when a label is popped off a packet, the TTL field of the newly exposed label or IP header is set to the minimum of (a) one less than the iTTL and (b) the existing value of the field (this rule is needed in order to prevent a TTL from getting longer as a packet travels). Then the pipe model can be provided by having a sufficiently large configured value (e.g., 255) in step 1 (given certain assumptions about the length of the LSP). It's kind of heuristic, but it usually works, it doesn't complicate the pop processing any more than is absolutely necessary, and it doesn't rely on signalling (only the head end needs to know the model). I believe there are certain implementations that work this way. From owner-mpls@UU.NET Thu Mar 1 17:07:00 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25729 for ; Thu, 1 Mar 2001 17:07:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeng14665; Thu, 1 Mar 2001 22:06:12 GMT Received: by mail-control.mail.uu.net id QQkeng27636 for mpls-outgoing; Thu, 1 Mar 2001 22:05:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeng26926 for ; Thu, 1 Mar 2001 22:05:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeng23473 for ; Thu, 1 Mar 2001 22:04:44 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeng29575 for ; Thu, 1 Mar 2001 22:04:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA28057 for mpls@uu.net; Thu, 1 Mar 2001 17:04:42 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeng22350 for ; Thu, 1 Mar 2001 22:04:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeng27907 for ; Thu, 1 Mar 2001 22:03:48 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkeng10106 for ; Thu, 1 Mar 2001 22:03:48 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA27403; Thu, 1 Mar 2001 17:03:10 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (rtp-dial-2-17.cisco.com [10.83.96.17]) by bucket.cisco.com (Mirapoint) with ESMTP id AAL14141; Thu, 1 Mar 2001 17:03:44 -0500 (EST) Message-Id: <4.3.2.7.2.20010301170615.01aa4d98@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Mar 2001 17:06:54 -0500 To: "Mallikarjun MLR" , From: "Thomas D. Nadeau" Subject: Re: How to map LDP sessions to FTN table? In-Reply-To: <000b01c0a147$a50b6030$6ee8a8c0@hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:00 AM 2/28/2001 +0530, Mallikarjun MLR wrote: > The LDP MIB specifies tables for mapping LDP sessions to InSegment > Entries, >OutSegment Entries > and Cross-Connect Entries. Should there be a table for mapping > originating >LDP LSPs (the LSR is the > Ingress LSR for the LSP) to entries in the FTN Table and FTN map > Table? Or >do FTN table and > FTN Map table contain only user-configured entries? Are you referring to tables in the MPLS-FTN-MIB or in the MPLS-LDP-MIB? --Tom From owner-mpls@UU.NET Thu Mar 1 17:36:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26779 for ; Thu, 1 Mar 2001 17:36:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeni00204; Thu, 1 Mar 2001 22:35:50 GMT Received: by mail-control.mail.uu.net id QQkeni02237 for mpls-outgoing; Thu, 1 Mar 2001 22:35:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeni02232 for ; Thu, 1 Mar 2001 22:35:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeni27486 for ; Thu, 1 Mar 2001 22:35:21 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeni29458 for ; Thu, 1 Mar 2001 22:35:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA00836 for mpls@uu.net; Thu, 1 Mar 2001 17:35:20 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeni02191 for ; Thu, 1 Mar 2001 22:34:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeni23794 for ; Thu, 1 Mar 2001 22:34:10 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkeni08483 for ; Thu, 1 Mar 2001 22:34:10 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA29164; Thu, 1 Mar 2001 17:33:17 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (rtp-dial-2-17.cisco.com [10.83.96.17]) by bucket.cisco.com (Mirapoint) with ESMTP id AAL14726; Thu, 1 Mar 2001 17:33:42 -0500 (EST) Message-Id: <4.3.2.7.2.20010301173300.01a726e8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Mar 2001 17:36:53 -0500 To: Paul Moore , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Bandwidth question In-Reply-To: <3A9E845A.9430FC87@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >The MPLS MIB has the table, mplsTrafficParamTable which describes >bandwidth allocation for in- and out-segments. The TE MIB also has the >table, mplsTunnelResourceTable, which allows the bandwidth required for >a tunnel to be specified. Both tables indicate that they can be pointed >to multiple times, to indicate that the specified resource should be >shared. > >How would this work in practice, in the case where an operator is trying >to set up traffic engineered tunnels? Preseumably, he would specify the >bandwidth required, and allow signalling to ensure that the tunnel is >set up, ensuring that the various constraints such as bandwidth or >explicit route are satisfied. The bandwidth constraint in this case >would appear as an entry in the mplsTunnelResourceTable. > >What then is the purpose of the mplsTrafficParamTable? Is is filled >in/updated for each in-and out-segment when the tunnel is finally >established? In that case, why should an entry in the table be pointed >to multiple times? Or does this table imply that further configuration >is required? Paul, you are correct that in practice, I have only seen folks point at this table on a 1-to-1 basis. In theory, it was originally thought that when setting up bi-directional tunnels, that it would be possible to allocate the same resources (sort of like using a VPI for both tunnels). Speaking for my implementation, For every tunnel instance I always point it at its own resource entry because each instance may have different bandwidth constraints. Making this assumption makes the implementation much easier. Hope that helps lessen your confusion. --Tom From owner-mpls@UU.NET Thu Mar 1 17:53:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27308 for ; Thu, 1 Mar 2001 17:53:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkenj28112; Thu, 1 Mar 2001 22:52:27 GMT Received: by mail-control.mail.uu.net id QQkenj04317 for mpls-outgoing; Thu, 1 Mar 2001 22:52:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkenj04277 for ; Thu, 1 Mar 2001 22:51:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkenj26252 for ; Thu, 1 Mar 2001 22:51:03 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkenj25571 for ; Thu, 1 Mar 2001 22:51:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA02439 for mpls@uu.net; Thu, 1 Mar 2001 17:51:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkenj04174 for ; Thu, 1 Mar 2001 22:50:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkenj20400 for ; Thu, 1 Mar 2001 22:50:22 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkenj08929 for ; Thu, 1 Mar 2001 22:50:22 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA00043; Thu, 1 Mar 2001 17:49:44 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (rtp-dial-2-17.cisco.com [10.83.96.17]) by bucket.cisco.com (Mirapoint) with ESMTP id AAL14970; Thu, 1 Mar 2001 17:50:18 -0500 (EST) Message-Id: <4.3.2.7.2.20010301175146.01a81498@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Mar 2001 17:53:29 -0500 To: Vijay Gill , From: "Thomas D. Nadeau" Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt In-Reply-To: References: <0E2DFCE7E586904DA0F583CB5EAD73CC031290@WATERTOWN.litchfieldcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > > Thanx for your input. It sounds like you'd like to see the same sort of > > statistical information from the emulated SONET that folks are > > accustomed to seeing from SONET networking equipment. I like that too > > (from years of developing telecomm equipment for service providers). > >I am slow on the uptake here, but excuse me if I'm getting this wrong: >there are people who are trying to implement SONET private line over >asynchronous IP transport (including MPLS)? > > From talking with people who were implementing Private Line at the >DS-1/DS-3 level over OC-12 trunked ATM switches, and hearing about the >problems they encountered, I am not sure if this is something worth >spending time on. Perhaps you could fill us in on those inadequacies? >MPLS barely functions as an adequate traffic engineering tool, I think that is necessarily true. I know of several very successful deployments. --Tom >lets get >that right before we go off trying to stuff everything under the sun into >MPLS. More stuff you add, the more resources you spend implementing new >features instead of trying to fix bugs, and more stuff there is to break. > >Of course this has no technical content germane to the discussion, these >are some thoughts from someone who has to run and support this mess. > >thank you > >/vijay From owner-mpls@UU.NET Thu Mar 1 19:04:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28926 for ; Thu, 1 Mar 2001 19:04:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeno12645; Fri, 2 Mar 2001 00:02:43 GMT Received: by mail-control.mail.uu.net id QQkeno03001 for mpls-outgoing; Fri, 2 Mar 2001 00:02:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeno02865 for ; Fri, 2 Mar 2001 00:02:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeno00497 for ; Fri, 2 Mar 2001 00:01:42 GMT Received: from yarilo.pluris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeno11205 for ; Fri, 2 Mar 2001 00:01:42 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA01744; Thu, 1 Mar 2001 16:01:32 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: References: Date: Thu, 1 Mar 2001 15:59:08 -0800 To: Vijay Gill From: Bora Akyol Subject: Re: Expanded ERO draft Cc: Kireeti Kompella , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk We ( I partially and a few others) implemented this and this why we wrote the draft. We think it makes implementation easier by removing an abstract node lookup and by removing any assumptions on what gets processed when: E.g unnumbered interfaces always refer to the egress interface coming out of the router. I did not co-author this draft just for the sake of writing an internet draft. Bora At 1:20 AM -0500 3/1/01, Vijay Gill wrote: >On Tue, 27 Feb 2001, Kireeti Kompella wrote: > >> As Yakov said, no concrete reason for adding the router ID has been >> given. However, we've wasted enough time and bandwidth. Let's put >> this to vote: >> >> Who all think that adding a router ID to the unnumbered ERO subobject >> would be beneficial? A simple yes, no or don't care, please. > >I would listen to what the people who are implementing this have to say on >the subject. I particularly don't care about the bandwidth/extra bytes >argument, but as a service provider, I do care that the people who are >implementing this do this in the simplest way possible. It makes for >robust code and I like robust code because getting up in the AM really >really annoys me. > >So my vote ranking system would go like this ;) > >People who are writing this code (developers): 10x >People who are the protocol architects: 2x >Other people: 1x > >Lets hear it from the implementors: > >thank you > >/vijay From owner-mpls@UU.NET Thu Mar 1 19:07:34 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28987 for ; Thu, 1 Mar 2001 19:07:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeno16469; Fri, 2 Mar 2001 00:05:21 GMT Received: by mail-control.mail.uu.net id QQkeno10122 for mpls-outgoing; Fri, 2 Mar 2001 00:04:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeno10096 for ; Fri, 2 Mar 2001 00:04:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeno18009 for ; Fri, 2 Mar 2001 00:04:40 GMT Received: from yarilo.pluris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeno15493 for ; Fri, 2 Mar 2001 00:04:40 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA02031; Thu, 1 Mar 2001 16:04:39 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: References: Date: Thu, 1 Mar 2001 16:02:16 -0800 To: Vach Kompella From: Bora Akyol Subject: RE: Expanded ERO draft Cc: "'mpls@uu.net'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk having the router id in addition to at least the egress interface ID helps by eliminating abstract node lookups and just simplifies ERO processing. If WG will adopt this as a new ERO as opposed to defining an EERO, then be it. Bora At 9:19 AM -0800 3/1/01, Vach Kompella wrote: >My vote (I didn't see dev. manager, but I run the group that's implementing >it, so I speak on their behalf) would be to throw the router ID in there. I >think it's great for debugging, too. You can look at an inflight ERO and >know exactly what it is supposed to do, without reference to a TED or an >LSDB. > >However, I would rather see a single ERO rather than both an ERO and an >EERO, and the mess of having to deal with interoperability, backwards >compatibility. > >-Vach > >-----Original Message----- >From: Rahul Aggarwal [mailto:rahul@redback.com] >Sent: Thursday, March 01, 2001 8:53 AM >To: Vijay Gill >Cc: Kireeti Kompella; mpls@UU.NET >Subject: Re: Expanded ERO draft > > >This is coming from a developer : ) > >I was in favor of adding a router id to the unnumbered ERO subobject >when the subject was discussed on the list a while back. Its cleaner >to implement. > >At the same time I think most of the information in the expanded ERO >draft is redundant. An informational doc on the current usage >will be of more value than adding new objects all over the >place. Some rewording in the RSVP-TE draft will also help. > >Its a yes to adding a router id to the unnumbered ERO subobject. > >thanks, >rahul > > > >On Thu, Mar 01, 2001 at 01:20:38AM -0500, Vijay Gill wrote: >> On Tue, 27 Feb 2001, Kireeti Kompella wrote: >> >> > As Yakov said, no concrete reason for adding the router ID has been >> > given. However, we've wasted enough time and bandwidth. Let's put >> > this to vote: >> > >> > Who all think that adding a router ID to the unnumbered ERO subobject >> > would be beneficial? A simple yes, no or don't care, please. >> >> I would listen to what the people who are implementing this have to say on >> the subject. I particularly don't care about the bandwidth/extra bytes >> argument, but as a service provider, I do care that the people who are >> implementing this do this in the simplest way possible. It makes for >> robust code and I like robust code because getting up in the AM really >> really annoys me. >> >> So my vote ranking system would go like this ;) >> >> People who are writing this code (developers): 10x >> People who are the protocol architects: 2x > > Other people: 1x > > > > Lets hear it from the implementors: > > > > thank you > > > > /vijay > > From owner-mpls@UU.NET Thu Mar 1 22:17:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03645 for ; Thu, 1 Mar 2001 22:17:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeob24361; Fri, 2 Mar 2001 03:16:46 GMT Received: by mail-control.mail.uu.net id QQkeob06239 for mpls-outgoing; Fri, 2 Mar 2001 03:16:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeob06198 for ; Fri, 2 Mar 2001 03:16:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeob14217 for ; Fri, 2 Mar 2001 03:16:11 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeob23122 for ; Fri, 2 Mar 2001 03:16:11 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA17335; Thu, 1 Mar 2001 19:15:59 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 19:15:59 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA09450B@avalon.pluris.com> From: Puneet Agarwal To: "'erosen@cisco.com'" , Bora Akyol Cc: akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" Subject: RE: New TTL Draft Date: Thu, 1 Mar 2001 19:15:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric, Thanks for your comments. My comments are inline. -Puneet [...] > >From the draft: > >> This document describes TTL processing in hierarchical MPLS >> networks. We believe that this document adds details that have not >> been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods >> presented in this document complement [MPLS-DS]. > > >I think it would be helpful for the draft authors to say >explicitly where >this draft: > >1. corrects errors in the RFCs > >2. modifies the functionality specified in the RFCS > >3. adds new functionality not specified in the RFCs > >4. adds details to clarify what is specified in the RFCs. > >That is, let's try to make sure that we all agree about >what changes/ >additions are being proposed, and why. > >It is true that the RFCs are not very clear about the way to >handle the case >where one doesn't want to percolate the TTL through the >label stack ("pipe >model"?). This is a good point. We will add this to the next revision of the draft. Briefly, the draft addresses TTL issues related to Pipe mode tunnels, hierarchical tunnels (any mix of pipe/uniform) and TTL processing for PHP - these in our opinion have not been specified in any another draft/rfc. TTL processing for non-hierarchical uniform model LSPs are generally covered in [MPLS-ENCAPS] but restated in the current draft for completeness and clarity. > >Whether the "pipe model" and the "uniform model" always (or >ever) need to be >distinguished through signalling is another matter. Is the >assumption that >a service provider might make a different decision for every >individual LSP? >(In the case of "ordinary" LDP, I think this is somewhat >unlikely, and the >signalling unnecessary.) > It is hard for me to comment on how varied the service provider deployments might be. It is unlikely that a provider would have different model LSPs within their own networks but should we restrict him/her from doing so by not providing the appropriate signaling mechanisms? -Puneet > > > > > > > > From owner-mpls@UU.NET Thu Mar 1 23:52:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06318 for ; Thu, 1 Mar 2001 23:52:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeoh20796; Fri, 2 Mar 2001 04:52:18 GMT Received: by mail-control.mail.uu.net id QQkeoh27417 for mpls-outgoing; Fri, 2 Mar 2001 04:51:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeoh27410 for ; Fri, 2 Mar 2001 04:51:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeoh12430 for ; Fri, 2 Mar 2001 04:50:06 GMT Received: from hclhprnd.hclt.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkeoh13159 for ; Fri, 2 Mar 2001 04:50:03 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id KAA16728; Fri, 2 Mar 2001 10:44:03 +0530 Received: from MALLIKPC ([192.168.232.110]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GC5PNZ3F; Fri, 2 Mar 2001 10:19:35 +0530 Message-ID: <004e01c0a2d4$5c1a2e40$6ee8a8c0@hclt.com> From: "Mallikarjun MLR" To: "Thomas D. Nadeau" Cc: References: <4.3.2.7.2.20010301170615.01aa4d98@bucket.cisco.com> Subject: Re: How to map LDP sessions to FTN table? Date: Fri, 2 Mar 2001 10:20:39 +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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Thomas D. Nadeau To: Mallikarjun MLR ; Sent: Friday, March 02, 2001 3:36 AM Subject: Re: How to map LDP sessions to FTN table? > At 11:00 AM 2/28/2001 +0530, Mallikarjun MLR wrote: > > The LDP MIB specifies tables for mapping LDP sessions to InSegment > > Entries, > >OutSegment Entries > > and Cross-Connect Entries. Should there be a table for mapping > > originating > >LDP LSPs (the LSR is the > > Ingress LSR for the LSP) to entries in the FTN Table and FTN map > > Table? Or > >do FTN table and > > FTN Map table contain only user-configured entries? > > Are you referring to tables in the MPLS-FTN-MIB or > in the MPLS-LDP-MIB? > > --Tom > I am referring to tables in both the MIBs. There are tables in MPLS-LDP-MIB to map to tables in the MPLS-LSR-MIB. Similarly, should there be tables in MPLS-LDP-MIB to map to tables in the MPLS-FTN-MIB? - Mallikarjun From owner-mpls@UU.NET Thu Mar 1 23:54:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06339 for ; Thu, 1 Mar 2001 23:54:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeoh17135; Fri, 2 Mar 2001 04:53:19 GMT Received: by mail-control.mail.uu.net id QQkeoh27485 for mpls-outgoing; Fri, 2 Mar 2001 04:53:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeoh27469 for ; Fri, 2 Mar 2001 04:52:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeoh19278 for ; Fri, 2 Mar 2001 04:52:21 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeoh20861 for ; Fri, 2 Mar 2001 04:52:20 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA26683; Thu, 1 Mar 2001 20:52:12 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 20:52:12 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA09450C@avalon.pluris.com> From: Puneet Agarwal To: "'erosen@cisco.com'" , Bora Akyol Cc: akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" Subject: RE: New TTL Draft Date: Thu, 1 Mar 2001 20:52:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, Please see my comments inline. -Puneet > >Consider the following way of handling TTL at the push/pop points: > >1. when a label is pushed on a packet, its TTL field is set >to either one > less than the iTTL, OR to a configured value; (i) It is unclear from the description if the label/ip-packet on which you pushed the new label(s) had its TTL modified to one less than iTTL. I believe that the encapsulated header ttl should be set to one less than iTTL for your case 2(b) to work and not cause a packet to potentially loop indefinitely. > >2. when a label is popped off a packet, the TTL field of the >newly exposed > label or IP header is set to the minimum of (a) one less >than the iTTL > and (b) the existing value of the field (this rule is >needed in order to > prevent a TTL from getting longer as a packet travels). > >Then the pipe model can be provided by having a >sufficiently large >configured value (e.g., 255) in step 1 (given certain >assumptions about the >length of the LSP). > >It's kind of heuristic, but it usually works, it doesn't >complicate the pop >processing any more than is absolutely necessary, and it >doesn't rely on >signalling (only the head end needs to know the model). (ii) The egress could choose to treat every popped label as a "pipe" model LSP in our description and achieve behaviour equivalent to 2(b). I think your behavior specified in 2 (b) still requires that (i) is true. The lack of a method for signalling the tunnel mode is, IMHO, an oversight in the mpls-diff draft. This should be fixed regardless of our TTL draft. In fact, I would content that our draft is one more reason why it should be fixed. > >I believe there are certain implementations that work this way. > I have no problems with certain implementations working the way you have outlined above. I am sure there are other implementations that work just a bit differently. The problem is that the specifications (or lack thereof) lack sufficient details for multiple vendors to implement a consistent mechanism for processing TTLs. This is what our draft seeks to address & clarify and marry that to the tunnel models described in the mpls-diff draft. I am sure that as our draft matures, we can/will add clauses to accomodate existing implementation if they do not break the models in egregious manner - depending of course on the consensus within this group. Thanks. -Puneet > > > > > From owner-mpls@UU.NET Thu Mar 1 23:57:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06387 for ; Thu, 1 Mar 2001 23:57:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeoh24427; Fri, 2 Mar 2001 04:57:11 GMT Received: by mail-control.mail.uu.net id QQkeoh27739 for mpls-outgoing; Fri, 2 Mar 2001 04:56:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeoh27732 for ; Fri, 2 Mar 2001 04:56:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeoh08570; Fri, 2 Mar 2001 04:56:36 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeoh28595; Fri, 2 Mar 2001 04:56:36 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA27009; Thu, 1 Mar 2001 20:56:33 -0800 (PST) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id UAA26962; Thu, 1 Mar 2001 20:56:33 -0800 (PST) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs Date: Thu, 1 Mar 2001 20:56:33 -0800 (PST) From: Bora Akyol To: Vishal Sharma cc: "'te-wg@uu.net'" , "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: Re: Standards for IP stats collection? (corrected) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Vishal I don't think that there are such standards for routers. I know that some routers store such data on flash cards for later retrieval and some on hard disks. I would be curious to see how people are storing this data and for how long? Bora On Thu, 1 Mar 2001, Vishal Sharma wrote: > Hello All, > > For the TDM world, GR-253 lays out strict standards for > the length of time that a carrier-class box should collect > and store statistics on-board, for retrieval later. The > number is something like 15-min intervals for 3 days. > The purpose supposedly is that if the connection to the EMS > dies, the box at least should allow the provider to recover > statistics data from it. > > My question is: what are similar standards (or existing > best practices) in the IP carrier community today? How much > statistics-related information do carriers like to have from > IP boxes? > What would carriers like to have? > > (The only reference I could find on this was Blain Christian's > draft > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t > xt) > > Are there others? > Do people (read carriers) have any thoughts or suggestions or > pointers? > > Thanks, > > -Vishal > From owner-mpls@UU.NET Fri Mar 2 00:16:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06629 for ; Fri, 2 Mar 2001 00:16:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeoj15805; Fri, 2 Mar 2001 05:15:55 GMT Received: by mail-control.mail.uu.net id QQkeoj14327 for mpls-outgoing; Fri, 2 Mar 2001 05:15:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeoj14319 for ; Fri, 2 Mar 2001 05:15:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeoi18779; Fri, 2 Mar 2001 05:14:50 GMT Received: from femail11.sdc1.sfba.home.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail11.sdc1.sfba.home.com [24.0.95.107]) id QQkeoi14412; Fri, 2 Mar 2001 05:14:50 GMT Received: from c1052242a ([24.19.208.28]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010302051449.WFKW10024.femail11.sdc1.sfba.home.com@c1052242a>; Thu, 1 Mar 2001 21:14:49 -0800 Reply-To: From: "Manohar Naidu Ellanti" To: "Bora Akyol" , "Vishal Sharma" Cc: "'te-wg@uu.net'" , "'mpls@uu.net'" , Subject: RE: Standards for IP stats collection? (corrected) Date: Thu, 1 Mar 2001 21:14:18 -0800 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit It will be interesting to see if there is a need for TDM world operational features to be carried into MPLS world. I think the reason for 15 minutes etc PM counters for things like Severely Errored Seconds etc was to deduce the quality of transmission line and use this to feed into link cost. For instance realiability metric could be based on such information for the link. For LSPs does it really make sense ? to have TDM world operational features. There is not even CRC or any header information to determine if MPLS packet was received correctly. It is more at lower layers. It would be nice to see some useful features carried forward and avoid unnecessary requirements from GR-XXX. -Manohar -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora Akyol Sent: Thursday, March 01, 2001 8:57 PM To: Vishal Sharma Cc: 'te-wg@uu.net'; 'mpls@uu.net'; 'ccamp@ops.ietf.org' Subject: Re: Standards for IP stats collection? (corrected) Vishal I don't think that there are such standards for routers. I know that some routers store such data on flash cards for later retrieval and some on hard disks. I would be curious to see how people are storing this data and for how long? Bora On Thu, 1 Mar 2001, Vishal Sharma wrote: > Hello All, > > For the TDM world, GR-253 lays out strict standards for > the length of time that a carrier-class box should collect > and store statistics on-board, for retrieval later. The > number is something like 15-min intervals for 3 days. > The purpose supposedly is that if the connection to the EMS > dies, the box at least should allow the provider to recover > statistics data from it. > > My question is: what are similar standards (or existing > best practices) in the IP carrier community today? How much > statistics-related information do carriers like to have from > IP boxes? > What would carriers like to have? > > (The only reference I could find on this was Blain Christian's > draft > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t > xt) > > Are there others? > Do people (read carriers) have any thoughts or suggestions or > pointers? > > Thanks, > > -Vishal > From owner-mpls@UU.NET Fri Mar 2 00:52:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07230 for ; Fri, 2 Mar 2001 00:52:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeol08129; Fri, 2 Mar 2001 05:52:14 GMT Received: by mail-control.mail.uu.net id QQkeol16985 for mpls-outgoing; Fri, 2 Mar 2001 05:51:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeol16980 for ; Fri, 2 Mar 2001 05:51:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeol06175 for ; Fri, 2 Mar 2001 05:51:03 GMT Received: from mx1out.umbc.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.253.51]) id QQkeol29514 for ; Fri, 2 Mar 2001 05:51:03 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id AAA27551; Fri, 2 Mar 2001 00:51:02 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id AAA1834199; Fri, 2 Mar 2001 00:51:01 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Fri, 2 Mar 2001 00:51:01 -0500 From: Vijay Gill X-X-Sender: To: "Thomas D. Nadeau" cc: Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt In-Reply-To: <4.3.2.7.2.20010301175146.01a81498@bucket.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 1 Mar 2001, Thomas D. Nadeau wrote: > > From talking with people who were implementing Private Line at the > >DS-1/DS-3 level over OC-12 trunked ATM switches, and hearing about the > >problems they encountered, I am not sure if this is something worth > >spending time on. > > Perhaps you could fill us in on those inadequacies? Actually, what the hell was I thinking... Must have been the late hour. Emululating SONET/SDH over mpls is something that has been long overdue. I am are eagerly awaiting delivery of this service. I apologise for wasting valuable time of the WG. /vijay From owner-mpls@UU.NET Fri Mar 2 06:56:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26567 for ; Fri, 2 Mar 2001 06:56:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepj11673; Fri, 2 Mar 2001 11:56:05 GMT Received: by mail-control.mail.uu.net id QQkepj10462 for mpls-outgoing; Fri, 2 Mar 2001 11:55:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkepj10451 for ; Fri, 2 Mar 2001 11:55:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkepj29275 for ; Fri, 2 Mar 2001 11:55:02 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkepj27701 for ; Fri, 2 Mar 2001 11:55:01 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA11755 for mpls@uu.net; Fri, 2 Mar 2001 06:55:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkepj10432 for ; Fri, 2 Mar 2001 11:54:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkepj07954 for ; Fri, 2 Mar 2001 11:54:01 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkepj25842 for ; Fri, 2 Mar 2001 11:54:00 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26212; Fri, 2 Mar 2001 06:53:58 -0500 (EST) Message-Id: <200103021153.GAA26212@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-crlsp-modify-03.txt Date: Fri, 02 Mar 2001 06:53:57 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LSP Modification Using CR-LDP Author(s) : J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, L. Li Filename : draft-ietf-mpls-crlsp-modify-03.txt Pages : 10 Date : 01-Mar-01 After a CR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP [2]. This contribution presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP using CR-LDP [3] without service interruption. The LSP modification feature can be supported by CR-LDP by use of the _modify_ value for the _action indicator flag_ in the LSPID TLV [3]. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crlsp-modify-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-crlsp-modify-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-crlsp-modify-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: <20010301141759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crlsp-modify-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crlsp-modify-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010301141759.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 2 06:56:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26591 for ; Fri, 2 Mar 2001 06:56:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepj29940; Fri, 2 Mar 2001 11:56:12 GMT Received: by mail-control.mail.uu.net id QQkepj10467 for mpls-outgoing; Fri, 2 Mar 2001 11:55:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkepj10454 for ; Fri, 2 Mar 2001 11:55:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkepj01818 for ; Fri, 2 Mar 2001 11:54:42 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkepj27109 for ; Fri, 2 Mar 2001 11:54:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA11734 for mpls@uu.net; Fri, 2 Mar 2001 06:54:41 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkepj10424 for ; Fri, 2 Mar 2001 11:54:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkepj25921 for ; Fri, 2 Mar 2001 11:53:57 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkepj25717 for ; Fri, 2 Mar 2001 11:53:55 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26185; Fri, 2 Mar 2001 06:53:53 -0500 (EST) Message-Id: <200103021153.GAA26185@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-ft-01.txt Date: Fri, 02 Mar 2001 06:53:53 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Fault Tolerance for LDP and CR-LDP Author(s) : A. Farrel, P. Brittain, P. Matthews, E. Gray Filename : draft-ietf-mpls-ldp-ft-01.txt Pages : 30 Date : 01-Mar-01 MPLS systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the switching hardware and TCP, are implementation specific. This document identifies issues in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The extensions described here are equally applicable to CR-LDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-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-ldp-ft-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-ldp-ft-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: <20010301141750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-ft-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-ft-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010301141750.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 2 08:06:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28077 for ; Fri, 2 Mar 2001 08:06:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepo20567; Fri, 2 Mar 2001 13:05:31 GMT Received: by mail-control.mail.uu.net id QQkepo15052 for mpls-outgoing; Fri, 2 Mar 2001 13:05:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkepo15042 for ; Fri, 2 Mar 2001 13:05:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkepo06714 for ; Fri, 2 Mar 2001 13:04:34 GMT Received: from prithvi.siliconsystems.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.85.131]) id QQkepo19290 for ; Fri, 2 Mar 2001 13:04:31 GMT Received: from mail.siliconsystems.co.in (mail.siliconsystems.co.in [172.19.32.5]) by prithvi.siliconsystems.co.in (8.9.1a+p1/8.9.1/d: thinkit.m4,v 1.5 2000/06/09 23:40:41 dmccart Exp $) with ESMTP id NAA12884; Fri, 2 Mar 2001 13:04:02 GMT Received: from siliconsystems.co.in (opal.siliconsystems.co.in [172.19.32.37]) by mail.siliconsystems.co.in (8.9.3/8.9.3) with ESMTP id SAA10230; Fri, 2 Mar 2001 18:47:01 +0530 (IST) Message-ID: <3A9F9C7F.D7819345@siliconsystems.co.in> Date: Fri, 02 Mar 2001 18:43:35 +0530 From: Sachin Doshi X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: mpls@UU.NET Subject: Re: New TTL Draft References: <3A9403E0.AC0BEA27@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bora, Some query's : 1. In section 2.4 u have covered MPLS routed packets? What about packets which come to a LSR, but which are not directed to him (i mean the MAC address of the packet was not this LSR's address. I think it is a valid scenerio). Should TTL be decremented for such packets? 2. In your later discussions, you said that you would like to keep a value "N", by which the TTL should be decremented. Will it not be a problem with MCAST traffic, for which we may like to keep a smaller TTL value, so that it should not go out of an organization. Because of this multiple TTL decrement it will not reach to the intended recepients. regards. sachin Bora Akyol wrote: > Note that we (Puneet and I) just posted an Internet Draft on TTL > handling in hierarchical MPLS networks. > > The internet draft is titled: draft-agarwal-mpls-ttl-00.txt > > http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt > > We welcome any comments, > > Bora Akyol From owner-mpls@UU.NET Fri Mar 2 09:20:36 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00183 for ; Fri, 2 Mar 2001 09:20:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkept02187; Fri, 2 Mar 2001 14:18:59 GMT Received: by mail-control.mail.uu.net id QQkept06790 for mpls-outgoing; Fri, 2 Mar 2001 14:18:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkept06783 for ; Fri, 2 Mar 2001 14:18:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkept12690 for ; Fri, 2 Mar 2001 14:18:02 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkept19211 for ; Fri, 2 Mar 2001 14:18:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA22060 for mpls@uu.net; Fri, 2 Mar 2001 09:18:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkept06753 for ; Fri, 2 Mar 2001 14:17:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkept17995 for ; Fri, 2 Mar 2001 14:17:09 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkept25345 for ; Fri, 2 Mar 2001 14:17:07 GMT Received: from flefauch-8kcdt.cisco.com (dhcp-nic-val-26-100.cisco.com [64.103.26.100]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA23350; Fri, 2 Mar 2001 15:16:03 +0100 (MET) Message-Id: <200103021416.PAA23350@cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 02 Mar 2001 15:13:28 +0100 To: Puneet Agarwal From: Francois Le Faucheur Subject: RE: New TTL Draft Cc: "'erosen@cisco.com'" , Bora Akyol , akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA09450C@avalon.pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Puneet, >The lack of a method for signalling the tunnel mode is, IMHO, an oversight >in the mpls-diff draft. This should be fixed regardless of our TTL draft. In >fact, I would content that our draft is one more reason why it should be >fixed. >> The decision to not signal the tunneling mode in the mpls-diff draft is not an oversight. This very point was actually discussed on the list and a conscious decision was made to not specify it at that point it time. As you said in another mail, it is unclear that there is a short term requirement for service providers to support different tunneling mode on a per LSP basis. There is however a clear requirement for service providers to be able to support a different tunneling mode on a per ingress/egress customer interface (ie customer 1 wants to be treated in Pipe model, customer 2 wants to be treated in Uniform model). Based on this we decided to : (1) make sure the spec supports the clear short term requirement (ie configuration of tunnel mode on a per interface basis) (2) not specify mechanisms for a potential-only requirement (ie tunnel mode signaling) (3) make sure the spec is open to adding tunnel mode signaling later if required BTW, there are many other options/extensions that have been proposed for the mpls-diff draft along the way and we tried to use a similar approach and stick to what was clearly required as opposed to what may be useful later. Now, if you know of service providers that have a clear short term requirement for supporting tunneling mode on a per LSP basis, then please let us know and then you could specify signaling in a separate document. Cheers Francois _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Fri Mar 2 09:33:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00530 for ; Fri, 2 Mar 2001 09:33:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepu26820; Fri, 2 Mar 2001 14:32:14 GMT Received: by mail-control.mail.uu.net id QQkepu07799 for mpls-outgoing; Fri, 2 Mar 2001 14:31:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkepu07793 for ; Fri, 2 Mar 2001 14:31:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkepu12333 for ; Fri, 2 Mar 2001 14:30:15 GMT Received: from smtp1.cluster.oleane.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.cluster.oleane.net [195.25.12.16]) id QQkepu13953 for ; Fri, 2 Mar 2001 14:30:15 GMT Received: from oleane (dyn-1-1-086.Vin.dialup.oleane.fr [195.25.4.86]) by smtp1.cluster.oleane.net with SMTP id f22EUEk64014 for ; Fri, 2 Mar 2001 15:30:14 +0100 (CET) Message-ID: <005d01c0a325$505c0820$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP over WDM Networks Date: Fri, 2 Mar 2001 15:30:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C0A32D.B1E4EDC0" 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_005A_01C0A32D.B1E4EDC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In the fast moving IP and fibre environments, IPoW ' 01 (IP over WDM = Networks) aims at presenting an up-to-date state of the art in the = design of new Internet network architectures. A call for proposals is online at:=20 http://www.upperside.fr/baipow.htm ------=_NextPart_000_005A_01C0A32D.B1E4EDC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
In the fast moving IP and fibre environments, = IPoW ' 01 (IP over WDM Networks) aims at presenting an=20 up-to-date state of the art in the design of new Internet network=20 architectures.
A call for proposals is online = at: 
 
http://www.upperside.fr/baipo= w.htm
------=_NextPart_000_005A_01C0A32D.B1E4EDC0-- From owner-mpls@UU.NET Fri Mar 2 10:08:13 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02169 for ; Fri, 2 Mar 2001 10:08:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepw25244; Fri, 2 Mar 2001 15:06:51 GMT Received: by mail-control.mail.uu.net id QQkepw24947 for mpls-outgoing; Fri, 2 Mar 2001 15:06:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkepw24833 for ; Fri, 2 Mar 2001 15:06:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkepw19008 for ; Fri, 2 Mar 2001 15:05:26 GMT Received: from WATERTOWN.litchfieldcomm.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 121.125.252.64.snet.net [64.252.125.121]) id QQkepw11940 for ; Fri, 2 Mar 2001 15:05:24 GMT Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Date: Fri, 2 Mar 2001 10:06:00 -0500 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC03129B@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: draft-danenberg-sonet-ces-mpls-mib-00.txt Thread-Index: AcCjKkqUihPeE17oSCq8AmdUIFftAQ== content-class: urn:content-classes:message From: "Dave Danenberg" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 To: "David Zelig" , "Jim Boyle" Cc: , , "Thomas D. Nadeau" , "Andrew G. Malis (E-mail)" , "tom k. johnson" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02169 Dave/Jim, We've considered your input on CEM statistics reporting and certainly agree that they are good recommendations. We consider this an open issue. But instead of immediately trying to solve it via the email list, we're thinking of raising it as an issue at the PWOT session at the upcoming IETF meeting. Then we'll gather and consider any more input, before distributing a proposal for better CEM stats. It looks like others are interested in TDM-like stats in the IP world. Did you see the thread on MPLS email under the subject heading "RE: Standards for IP stats collection? (corrected)" ? -- Dave Danenberg -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Dave Danenberg Sent: Wednesday, February 28, 2001 9:16 AM To: David Zelig; Thomas D. Nadeau; Jim Boyle; Andrew G. Malis (E-mail) Cc: mpls@UU.NET; tom k. johnson Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt David Zelig, Jim, Tom, Andy, Deriving SONET-like statistics from the CEM function is worth exploring further. As David Zelig points out, the CEM operation at the ends of the tunnel can monitor the path's B3 (BIP) byte. Although it may be tempting to piggyback on existing functionality (B3), this technique would not be able to easily discern between the errors introduced before the path reached the CEM (Ac-A in the example) and the errors introduced within the tunnel (A-Z). The CEM operation (at A) could regenerate B3, but that would violate the integrity of the path's own error statistics. So I think the way to look at this problem is by thinking of the CEM operation as what it really is - an emulated SONET 'line' carrying the path as its payload. As a 'line', the CEM could generate and terminate its own BIP. This BIP, could then be used to create the same quality and format of statistics as folks expect from SONET. For CEM to support its own payload BIP, a new field would be required in the CEM header. So this needs to carefully considered. If we were to do this, we also need to decide if the CEM payload BIP should be calculated on path or on packet delineations (i.e., calculated on the previous path frame just as B3 does, or on the CEM header to end of packet). (We'll forward this issue to the PWOT email list) Dave Danenberg -----Original Message----- From: David Zelig [mailto:Davidz@corrigent.com] Sent: Wednesday, February 28, 2001 2:11 AM To: 'Thomas D. Nadeau'; Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Tom, Dave and Jim, In order to detect payload defects at the STS level there are BIP checking on the path overhead. If an operator want to check errors generated by the CEM operation it may be simpler (and more understood) to monitor the B3 byte for errors in both ends of the tunnel. This can be done on the example below on the interface on the IP edge device. It is very hard to manipulate CEM errors to payload errors, and if the customer bought SONET service (and sign on SONET SLA) the PM should be on SONET "language" and measured at the SONET level. Sure we must cover all potential CEM errors in order to enable detecting the cause of the errors, especially for the case of problems caused by mis-configuration.I think that we need to deliver interval data for all PM related errors, and for events count. David -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, February 28, 2001 5:49 AM To: Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt At 08:02 PM 2/27/2001 -0500, Dave Danenberg wrote: >Jim, > >Thanx for your input. It sounds like you'd like to see the same sort of >statistical information from the emulated SONET that folks are >accustomed to seeing from SONET networking equipment. I like that too >(from years of developing telecomm equipment for service providers). > >Although I was considering second order counts (errored seconds) or >trends (15 minute, 24 hour interval data), I decided to start with just >simple counts - and see what folks think. > >Andy's CEM does not detect errors over the CEM payload, but it does >detect errors within the CEM header (the CEM MIB counts them with >mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps >CEM header error rates can be extrapolated to indicate payload errors >rates. Due to the nature of CEM, other types of errors are detectable >(buffer errors, missing packets, etc). Assuming CEM equipment can >process this raw info into some nice statistics, another set of objects >can be added to the CEM MIB. > >So, I'd like to include the type of statistical info you suggest as well >as your "reason for last down" idea. Would you like to see interval data >as well? > >What do you think Tom? If you agree, I can come up with another set of >objects and send it to Jim (and mpls email) for comment. Yes, as I mentioned earlier, I think these things are a good idea. Lets work on them and get our ideas back out to the list shortly. --Tom >Dave > > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle >Sent: Tuesday, February 27, 2001 2:24 PM >To: Thomas D. Nadeau >Cc: mpls@UU.NET >Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > >pretend you are a service provider, a customer calls in and says he's >seeing errors on his service (in particular, bip violalations in POH). > >He is directly connected to your network via port A. >On the far end, he connects to a clec, which hands it off to you at port >Z. He connects to a CLEC adm on port Z'. His path terminating >equipment >(maybe a router) is port Ac, and Zc, such that the service looks like: > >Ac-A-[IP]-Z-CLEC-Z'-Zc > >Looking at lines Ac-A and Z-CLEC shows clean lines. > >How does the operator determine if his IP network is to blame, or the >CLECs network is to blame? > >i'd recomend a few things: > >o) Andy's draft should have some sort of way to determine if there are >bit >errors hapenning across the IP network that affect the service >payload. This would provide the same sort of delineation of where a >problem is occuring by looking at LOHs in more traditional transport >network. > >o) your mib should include analogues to the SONET mib, such as bip-8 >violations, errored seconds, etc... (working off memory here). > >o) addition of a "reason for last down" might be nice. > >This way, when you, as the service provider, replies that "it's not our >problem, must be the clec", they can say at least go look at it later to >see if they were telling the truth. > >As usual, excellent attention paid to the configuration aspects. > >regards, > >Jim > > >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > > > > Hi, > > > > FYI a new MIB for managing SONET/SDH Circuit Emulation > > Service Over MPLS has been posted. It should be available > > shortly via the IETF's web site. In the meantime, it is available > > at the following web/ftp link. As usual, comments are welcome. > > > > >ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces - >mpls-mib-00.txt > > > > --Tom > > From owner-mpls@UU.NET Fri Mar 2 10:12:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02410 for ; Fri, 2 Mar 2001 10:12:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepw01828; Fri, 2 Mar 2001 15:11:13 GMT Received: by mail-control.mail.uu.net id QQkepw25855 for mpls-outgoing; Fri, 2 Mar 2001 15:10:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkepw25850 for ; Fri, 2 Mar 2001 15:10:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkepw15193 for ; Fri, 2 Mar 2001 15:10:12 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkepw18623 for ; Fri, 2 Mar 2001 15:10:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA27719 for mpls@uu.net; Fri, 2 Mar 2001 10:10:10 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkepw25533 for ; Fri, 2 Mar 2001 15:09:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkepw29825 for ; Fri, 2 Mar 2001 15:08:55 GMT Received: from brixcorp2.brixnet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.122.27.34]) id QQkepw22147 for ; Fri, 2 Mar 2001 15:08:50 GMT Received: by BRIXCORP2 with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 10:08:49 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7FD8@BRIXCORP2> From: "Cucchiara, Joan" To: "'Mallikarjun MLR'" , "Thomas D. Nadeau" Cc: mpls@UU.NET Subject: RE: How to map LDP sessions to FTN table? Date: Fri, 2 Mar 2001 10:08:44 -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 > > ----- Original Message ----- > From: Thomas D. Nadeau > To: Mallikarjun MLR ; > Sent: Friday, March 02, 2001 3:36 AM > Subject: Re: How to map LDP sessions to FTN table? > > > > At 11:00 AM 2/28/2001 +0530, Mallikarjun MLR wrote: > > > The LDP MIB specifies tables for mapping LDP sessions > to InSegment > > > Entries, > > >OutSegment Entries > > > and Cross-Connect Entries. Should there be a table for mapping > > > originating > > >LDP LSPs (the LSR is the > > > Ingress LSR for the LSP) to entries in the FTN Table > and FTN map > > > Table? Or > > >do FTN table and > > > FTN Map table contain only user-configured entries? > > > > Are you referring to tables in the MPLS-FTN-MIB or > > in the MPLS-LDP-MIB? > > > > --Tom > > Hello Mallikarjun, > > I am referring to tables in both the MIBs. There are > tables in MPLS-LDP-MIB > to map to > tables in the MPLS-LSR-MIB. Similarly, should there be tables in > MPLS-LDP-MIB to map to > tables in the MPLS-FTN-MIB? The LSR MIB and the LDP MIB were being worked on in relatively the same time frame. The FTN MIB was later, and so mapping tables of this sort were not included in the LDP MIB. -Joan > > - Mallikarjun > > From owner-mpls@UU.NET Fri Mar 2 10:40:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03633 for ; Fri, 2 Mar 2001 10:40:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepy29020; Fri, 2 Mar 2001 15:39:42 GMT Received: by mail-control.mail.uu.net id QQkepy29009 for mpls-outgoing; Fri, 2 Mar 2001 15:39:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkepy29004 for ; Fri, 2 Mar 2001 15:39:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkepy03736 for ; Fri, 2 Mar 2001 15:39:12 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkepy09372 for ; Fri, 2 Mar 2001 15:38:46 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 HAA07725 for ; Fri, 2 Mar 2001 07:38:49 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA06133 for mpls@uu.net; Fri, 2 Mar 2001 10:38:29 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkepy28491 for ; Fri, 2 Mar 2001 15:31:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkepy02236 for ; Fri, 2 Mar 2001 15:30:46 GMT Received: from uadvg137.cms.usa.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: uadvg137.cms.usa.net [165.212.11.137]) id QQkepy14513 for ; Fri, 2 Mar 2001 15:30:46 GMT Received: (qmail 9652 invoked by uid 0); 2 Mar 2001 15:30:45 -0000 Received: USA.NET MXFirewall, messaging filters applied; Fri, 02 Mar 2001 15:30:45 GMT Received: from talent [216.229.43.221] by ca37 (ASMTP/tmartin@gvnw.com) via mtad (53CM.1200.1.06) with ESMTP id 847FcBPEO0078M37; Fri, 02 Mar 2001 15:30:41 GMT Message-ID: <001801c0a32d$ba181490$8f3918ac@talent> From: "terry martin" To: , "Bora Akyol" , "Vishal Sharma" Cc: "'te-wg@uu.net'" , "'mpls@uu.net'" , References: Subject: Re: Standards for IP stats collection? (corrected) Date: Fri, 2 Mar 2001 07:30:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit RMON is the only protocol standard that dictates information collection requirements. That is the only IP service that is structured to collect trend stats. I think it is also 15 minute intervals for 3-5 days depending on how much memory you get in the unit. There are structure requirements for collection, type of traffic collected and how it is presented. Need sources- let me know Terry Martin MS Telecommunication Engineering Senior Consultant tmartin@gvnw.com 503-612-4422 ----- Original Message ----- From: "Manohar Naidu Ellanti" To: "Bora Akyol" ; "Vishal Sharma" Cc: "'te-wg@uu.net'" ; "'mpls@uu.net'" ; Sent: Thursday, March 01, 2001 9:14 PM Subject: RE: Standards for IP stats collection? (corrected) > It will be interesting to see if there is a need for TDM world operational > features to be carried into MPLS world. > > I think the reason for 15 minutes etc PM counters for things like Severely > Errored Seconds etc was to deduce the quality of transmission line and use > this to feed into link cost. For instance realiability metric could be based > on such information for the link. > > For LSPs does it really make sense ? to have TDM world operational features. > There is not even CRC or any header information to determine if MPLS packet > was received correctly. It is more at lower layers. It would be nice to see > some useful features carried forward and avoid unnecessary requirements from > GR-XXX. > > -Manohar > > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora > Akyol > Sent: Thursday, March 01, 2001 8:57 PM > To: Vishal Sharma > Cc: 'te-wg@uu.net'; 'mpls@uu.net'; 'ccamp@ops.ietf.org' > Subject: Re: Standards for IP stats collection? (corrected) > > > Vishal > > I don't think that there are such standards for routers. I know that some > routers store such data on flash cards for later retrieval and some on > hard disks. > > I would be curious to see how people are storing this data and for how > long? > > Bora > > > On Thu, 1 Mar 2001, Vishal Sharma wrote: > > > Hello All, > > > > For the TDM world, GR-253 lays out strict standards for > > the length of time that a carrier-class box should collect > > and store statistics on-board, for retrieval later. The > > number is something like 15-min intervals for 3 days. > > The purpose supposedly is that if the connection to the EMS > > dies, the box at least should allow the provider to recover > > statistics data from it. > > > > My question is: what are similar standards (or existing > > best practices) in the IP carrier community today? How much > > statistics-related information do carriers like to have from > > IP boxes? > > What would carriers like to have? > > > > (The only reference I could find on this was Blain Christian's > > draft > > > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t > > xt) > > > > Are there others? > > Do people (read carriers) have any thoughts or suggestions or > > pointers? > > > > Thanks, > > > > -Vishal > > > > From owner-mpls@UU.NET Fri Mar 2 10:56:32 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04038 for ; Fri, 2 Mar 2001 10:56:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepz10603; Fri, 2 Mar 2001 15:54:44 GMT Received: by mail-control.mail.uu.net id QQkepz00870 for mpls-outgoing; Fri, 2 Mar 2001 15:54:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkepz00862 for ; Fri, 2 Mar 2001 15:54:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkepz15995 for ; Fri, 2 Mar 2001 15:53:29 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQkepz19247 for ; Fri, 2 Mar 2001 15:53:29 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 QAA20246; Fri, 2 Mar 2001 16:53:06 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA10372; Fri, 2 Mar 2001 16:52:33 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 16:52:34 +0100 Message-ID: From: Heiles Juergen To: "'Dave Danenberg'" , David Zelig , Jim Boyle Cc: mpls@UU.NET, pwot@ietf.org, "Thomas D. Nadeau" , "Andrew G. Malis (E-mail)" , "tom k. johnson" Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Date: Fri, 2 Mar 2001 16:52:31 +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 It is interesting to see the increased interest in the supervision features of the "expensive, complicated, ..." TDM=Sonet/SDH system as soon as it is going carrier class. By the way Sonet/SDH offers already a feature for supervison of a sub-network connections of a STS-SPE (VC). It is called tandem connection monitoring TCM. It basically determines the failure/bit error status at the start of the sub-network connection, transports it via an overhead byte (N1) to the end of the sub-network connection and compares it with the status there (bit -errors at start - bit erros at end= bit errors of sub-network connection). In additon it provides its own trace for conenctivity supervision. In any case supervision at the MPLS layer is of interest (see the discussion on MPLS OAM), which however should be independent of the client signals. Concerning CEM over MPLS for CBR signals like a STS-SPE/VC in general I share some of the doubts expressed in a previous mail, specifically for clock jitter and wander. The MPLS transport could result in excessive pointer justification of the STS-SPE or VT outside the Sonet/SDH specifications. Regards Juergen > -----Original Message----- > From: Dave Danenberg [SMTP:dave_danenberg@litchfieldcomm.com] > Sent: Friday, March 02, 2001 4:06 PM > To: David Zelig; Jim Boyle > Cc: mpls@UU.NET; pwot@ietf.org; Thomas D. Nadeau; Andrew G. Malis (E-mail); tom k. johnson > Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt > > Dave/Jim, > > We've considered your input on CEM statistics reporting and certainly > agree that they are good recommendations. We consider this an open > issue. But instead of immediately trying to solve it via the email list, > we're thinking of raising it as an issue at the PWOT session at the > upcoming IETF meeting. Then we'll gather and consider any more input, > before distributing a proposal for better CEM stats. > > It looks like others are interested in TDM-like stats in the IP world. > Did you see the thread on MPLS email under the subject heading "RE: > Standards for IP stats collection? (corrected)" ? > > -- Dave Danenberg > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Dave > Danenberg > Sent: Wednesday, February 28, 2001 9:16 AM > To: David Zelig; Thomas D. Nadeau; Jim Boyle; Andrew G. Malis (E-mail) > Cc: mpls@UU.NET; tom k. johnson > Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > David Zelig, Jim, Tom, Andy, > > Deriving SONET-like statistics from the CEM function is worth exploring > further. As David Zelig points out, the CEM operation at the ends of the > tunnel can monitor the path's B3 (BIP) byte. Although it may be tempting > to piggyback on existing functionality (B3), this technique would not be > able to easily discern between the errors introduced before the path > reached the CEM (Ac-A in the example) and the errors introduced within > the tunnel (A-Z). The CEM operation (at A) could regenerate B3, but that > would violate the integrity of the path's own error statistics. So I > think the way to look at this problem is by thinking of the CEM > operation as what it really is - an emulated SONET 'line' carrying the > path as its payload. As a 'line', the CEM could generate and terminate > its own BIP. This BIP, could then be used to create the same quality and > format of statistics as folks expect from SONET. > > For CEM to support its own payload BIP, a new field would be required in > the CEM header. So this needs to carefully considered. If we were to do > this, we also need to decide if the CEM payload BIP should be calculated > on path or on packet delineations (i.e., calculated on the previous path > frame just as B3 does, or on the CEM header to end of packet). > > (We'll forward this issue to the PWOT email list) > > Dave Danenberg > > > -----Original Message----- > From: David Zelig [mailto:Davidz@corrigent.com] > Sent: Wednesday, February 28, 2001 2:11 AM > To: 'Thomas D. Nadeau'; Dave Danenberg; Jim Boyle > Cc: mpls@UU.NET > Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > Tom, Dave and Jim, > > In order to detect payload defects at the STS level there are BIP > checking > on the path overhead. If an operator want to check errors generated by > the > CEM operation it may be simpler (and more understood) to monitor the B3 > byte > for errors in both ends of the tunnel. This can be done on the example > below > on the interface on the IP edge device. > > It is very hard to manipulate CEM errors to payload errors, and if the > customer bought SONET service (and sign on SONET SLA) the PM should be > on > SONET "language" and measured at the SONET level. > > Sure we must cover all potential CEM errors in order to enable detecting > the > cause of the errors, especially for the case of problems caused by > mis-configuration.I think that we need to deliver interval data for all > PM > related errors, and for events count. > > David > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, February 28, 2001 5:49 AM > To: Dave Danenberg; Jim Boyle > Cc: mpls@UU.NET > Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > At 08:02 PM 2/27/2001 -0500, Dave Danenberg wrote: > >Jim, > > > >Thanx for your input. It sounds like you'd like to see the same sort of > >statistical information from the emulated SONET that folks are > >accustomed to seeing from SONET networking equipment. I like that too > >(from years of developing telecomm equipment for service providers). > > > >Although I was considering second order counts (errored seconds) or > >trends (15 minute, 24 hour interval data), I decided to start with just > >simple counts - and see what folks think. > > > >Andy's CEM does not detect errors over the CEM payload, but it does > >detect errors within the CEM header (the CEM MIB counts them with > >mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps > >CEM header error rates can be extrapolated to indicate payload errors > >rates. Due to the nature of CEM, other types of errors are detectable > >(buffer errors, missing packets, etc). Assuming CEM equipment can > >process this raw info into some nice statistics, another set of objects > >can be added to the CEM MIB. > > > >So, I'd like to include the type of statistical info you suggest as > well > >as your "reason for last down" idea. Would you like to see interval > data > >as well? > > > >What do you think Tom? If you agree, I can come up with another set of > >objects and send it to Jim (and mpls email) for comment. > > Yes, as I mentioned earlier, I think these things are a > good idea. Lets work on them and get our ideas back out to the > list shortly. > > --Tom > > > > > >Dave > > > > > >-----Original Message----- > >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim > Boyle > >Sent: Tuesday, February 27, 2001 2:24 PM > >To: Thomas D. Nadeau > >Cc: mpls@UU.NET > >Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > > > > > >pretend you are a service provider, a customer calls in and says he's > >seeing errors on his service (in particular, bip violalations in POH). > > > >He is directly connected to your network via port A. > >On the far end, he connects to a clec, which hands it off to you at > port > >Z. He connects to a CLEC adm on port Z'. His path terminating > >equipment > >(maybe a router) is port Ac, and Zc, such that the service looks like: > > > >Ac-A-[IP]-Z-CLEC-Z'-Zc > > > >Looking at lines Ac-A and Z-CLEC shows clean lines. > > > >How does the operator determine if his IP network is to blame, or the > >CLECs network is to blame? > > > >i'd recomend a few things: > > > >o) Andy's draft should have some sort of way to determine if there are > >bit> > >errors hapenning across t> he IP network that affect the service > >payload. This would provide the same sort of delineation of where a > >problem is occuring by looking at LOHs in more traditional transport > >network. > > > >o) your mib should include analogues to the SONET mib, such as bip-8 > >violations, errored seconds, etc... (working off memory here). > > > >o) addition of a "reason for last down" might be nice. > > > >This way, when you, as the service provider, replies that "it's not our > >problem, must be the clec", they can say at least go look at it later > to > >see if they were telling the truth. > > > >As usual, excellent attention paid to the configuration aspects. > > > >regards, > > > >Jim > > > > > >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > > > > > > > Hi, > > > > > > FYI a new MIB for managing SONET/SDH Circuit Emulation > > > Service Over MPLS has been posted. It should be available > > > shortly via the IETF's web site. In the meantime, it is available > > > at the following web/ftp link. As usual, comments are welcome. > > > > > > > >ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces > - > >mpls-mib-00.txt > > > > > > --Tom > > > From owner-mpls@UU.NET Fri Mar 2 11:01:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04283 for ; Fri, 2 Mar 2001 11:01:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkepz16694; Fri, 2 Mar 2001 15:58:18 GMT Received: by mail-control.mail.uu.net id QQkepz01254 for mpls-outgoing; Fri, 2 Mar 2001 15:58:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkepz01235 for ; Fri, 2 Mar 2001 15:57:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkepz27263 for ; Fri, 2 Mar 2001 15:57:14 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkepz26751 for ; Fri, 2 Mar 2001 15:57: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 HAA23632; Fri, 2 Mar 2001 07:57:24 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA06215; Fri, 2 Mar 2001 10:57:06 -0500 (EST) Message-Id: <200103021557.KAA06215@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Puneet Agarwal cc: Bora Akyol , akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" Subject: Re: New TTL Draft In-reply-to: Your message of Thu, 01 Mar 2001 19:15:58 -0800. <17C81AD1F1FED411991E006008F6D1CA09450B@avalon.pluris.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 02 Mar 2001 10:57:06 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Puneet> Briefly, the draft addresses TTL issues related to Pipe mode Puneet> tunnels, hierarchical tunnels (any mix of pipe/uniform) and TTL Puneet> processing for PHP - these in our opinion have not been specified in Puneet> any another draft/rfc It seems to me that for the uniform model, this is covered in section 2.4 of RFC 3032. Puneet> It is unlikely that a provider would have different model LSPs Puneet> within their own networks but should we restrict him/her from doing Puneet> so by not providing the appropriate signaling mechanisms? Yes. If we think a signaling mechanism is unlikely to be used, there's not much point in having it. (It is true that the MPLS specs are full of stuff that is unlikely to be used, because the WG couldn't reach consensus on which things are likely and which are unlikely. But I'm not sure that's the case here.) Also, there is an impact in the forwarding path if we make the TTL processing more complex than it needs to be, by adding more optional behaviors. From owner-mpls@UU.NET Fri Mar 2 11:46:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06230 for ; Fri, 2 Mar 2001 11:46:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqc10336; Fri, 2 Mar 2001 16:44:41 GMT Received: by mail-control.mail.uu.net id QQkeqc20398 for mpls-outgoing; Fri, 2 Mar 2001 16:44:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqc20372 for ; Fri, 2 Mar 2001 16:44:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeqc23090 for ; Fri, 2 Mar 2001 16:43:39 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkeqc18167 for ; Fri, 2 Mar 2001 16:43:39 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 1151B94006; Fri, 2 Mar 2001 11:43:39 -0500 (EST) Message-ID: <3A9FCDBA.29EA9DE9@sandburst.com> Date: Fri, 02 Mar 2001 11:43:39 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Sachin Doshi Cc: Bora Akyol , mpls@UU.NET Subject: Re: New TTL Draft References: <3A9403E0.AC0BEA27@sandburst.com> <3A9F9C7F.D7819345@siliconsystems.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sachin, Routers only decrement TTL for packets they route. Bridges never decrement TTL. Decrementing by a value other than one would be a network administrator configured value. In all likelyhood, the value used for TTL in multicast traffic within an enterprise would also be a network administrator configured value. There should be no issue with unwanted TTL expiry of packets within an enterprise. Also, it might be desirable for the network adminsitrator to deliberately configure a TTL decrement other than one, at border routers (for example), to ensure that multicast packets do not escape. However, there are other ways to do this. -- Eric Gray You wrote: > Hi Bora, > Some query's : > > 1. In section 2.4 u have covered MPLS routed packets? What about packets > which come to a LSR, but which are not directed to him (i mean the > MAC address of the packet was not this LSR's address. I think it is a > valid scenerio). Should TTL be decremented for such packets? > > 2. In your later discussions, you said that you would like to keep a > value "N", by which the TTL should be decremented. Will it not be a > problem with MCAST traffic, for which we may like to keep a smaller > TTL value, so that it should not go out of an organization. Because of > this multiple TTL decrement it will not reach to the intended > recepients. > > regards. > sachin > > Bora Akyol wrote: > > > Note that we (Puneet and I) just posted an Internet Draft on TTL > > handling in hierarchical MPLS networks. > > > > The internet draft is titled: draft-agarwal-mpls-ttl-00.txt > > > > http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt > > > > We welcome any comments, > > > > Bora Akyol From owner-mpls@UU.NET Fri Mar 2 11:48:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06332 for ; Fri, 2 Mar 2001 11:48:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqd12964; Fri, 2 Mar 2001 16:46:30 GMT Received: by mail-control.mail.uu.net id QQkeqd20766 for mpls-outgoing; Fri, 2 Mar 2001 16:45:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeqd20752 for ; Fri, 2 Mar 2001 16:45:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqc26565 for ; Fri, 2 Mar 2001 16:44:38 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqc23257 for ; Fri, 2 Mar 2001 16:44:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA09280 for mpls@uu.net; Fri, 2 Mar 2001 11:44:37 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqc20366 for ; Fri, 2 Mar 2001 16:44:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqc22604 for ; Fri, 2 Mar 2001 16:43:27 GMT Received: from procyon.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQkeqc08617 for ; Fri, 2 Mar 2001 16:43:27 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA11221; Fri, 2 Mar 2001 08:42:23 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BNPND>; Fri, 2 Mar 2001 08:45:54 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AD7@BBY1EXM01> From: Shahram Davari To: "'erosen@cisco.com'" , Bora Akyol Cc: akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" Subject: RE: New TTL Draft Date: Fri, 2 Mar 2001 08:45:52 -0800 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 Eric, > 1. when a label is pushed on a packet, its TTL field is set > to either one > less than the iTTL, OR to a configured value; > > 2. when a label is popped off a packet, the TTL field of > the newly exposed > label or IP header is set to the minimum of (a) one less > than the iTTL > and (b) the existing value of the field (this rule is > needed in order to > prevent a TTL from getting longer as a packet travels). > TTL processing mode at the egress of a tunnel MUST be the same TTL processing mode as the ingress of that tunnel. By that I mean if the ingress of a tunnel is processing TTL in Pipe mode, then the egress MUST also process it in Pipe mode. If we observe this rule it is impossible for a TTL to become larger as a packet travels. The only case that TTL may increase is when you process the ingress as Pipe model and the egress as uniform model. Yours, -Shahram From owner-mpls@UU.NET Fri Mar 2 12:04:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06958 for ; Fri, 2 Mar 2001 12:04:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqe02948; Fri, 2 Mar 2001 17:03:30 GMT Received: by mail-control.mail.uu.net id QQkeqe00424 for mpls-outgoing; Fri, 2 Mar 2001 17:03:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqe00263 for ; Fri, 2 Mar 2001 17:03:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeqe07748 for ; Fri, 2 Mar 2001 17:02:35 GMT Received: from mail.net-work.ne.jp by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.net-work.ne.jp [210.228.101.12]) id QQkeqe01069 for ; Fri, 2 Mar 2001 17:02:34 GMT Received: from [192.168.0.2] (ppp129.net-work.ne.jp [210.228.101.129]) by mail.net-work.ne.jp (8.9.3/3.7W) with ESMTP id CAA93222; Sat, 3 Mar 2001 02:00:52 +0900 (JST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106 Date: Sat, 03 Mar 2001 02:01:06 +0900 Subject: Re: New TTL Draft From: "S.Matsushima" To: Puneet Agarwal , "'Shahram Davari'" , "'Eric Gray'" CC: "'mpls@uu.net'" , "'flefauch@cisco.com'" , "'liwwu@cisco.com'" , "'bsd@cisco.com'" , Bora Akyol Message-ID: In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA09450A@avalon.pluris.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I think you can consider following situation: "TTL processing in intermediate LSR of LSP cut off points." Is it clear? -- Satoru Matsushima on 01.3.2 3:09 AM, Puneet Agarwal at puneet@pluris.com wrote: > Eric/Shahram, > > The draft addresses "all" forms of TTL processing in MPLS networks. The > non-hierarchical case is just a special case of the general problem > addressed in the draft. > > And Shahram, I will still go with my proposal which I have cut and pasted > here. The reason is that I believe this is a concise and non-repetitive way > of describing Pop and subsequent operations. This captures the fact that you > can do Pops recursively and that you have to process the exposed packet (IP > or MPLS) again to determine the operation (Swap/Swap+Push/PHP/PHP+Push/Pop). > > 4) Pop : This is the terminating point of an LSP tunnel, in > which, first the top label is popped and then the packet is > forwarded based on the lower label (or exposed IP header). > Note that this operation can occur recursively. The iTTL is > updated as explained in section 2.3. The outgoing TTL would > be determined by the last non "Pop" operation performed > on the packet. > > -Puneet > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Wednesday, February 28, 2001 8:41 AM >> To: 'Eric Gray' >> Cc: 'Puneet Agarwal'; 'mpls@uu.net'; 'flefauch@cisco.com'; >> 'liwwu@cisco.com'; 'bsd@cisco.com'; Bora Akyol >> Subject: RE: New TTL Draft >> >> >> Hi Eric, >> >> >>> I see no reason why Puneet's draft should affect TTL processing >>> in intermediate LSRs. I believe this is well defined elsewhere. >> >> Sure, but first the authors should decide what is the >> objective of this draft? Is it explaining the TTL processing >> after pop or push, in other words is it explaining the TTL >> processing at tunnel ingress/egress/penultimate? or is it a >> general TTL processing draft that explains TTL processing at >> any node be it intermediate or tunnel ingress/egress/penultimate? >> >> It seems that the authors intend to talk only about tunnel >> ingress/egress/penultimate TTL processing. If that is the case >> then the draft is misleading because neither the title nor the >> text reflect this. Also section 2.3 second paragraph talks >> about iTTL determination for push/"SWAP"/php. Which means it >> is talking about iTTL determination for a "SWAP" case too, >> which is intermediate TTL processing. >> >>> By the way, an LSR that pops a label is not an intermediate LSR >>> with respect to the LSP for which that label applied. >>> >> >> Yes, I guess I know that. >> >> Thanks, >> -Shahram >> From owner-mpls@UU.NET Fri Mar 2 12:07:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07086 for ; Fri, 2 Mar 2001 12:07:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqe11425; Fri, 2 Mar 2001 17:07:04 GMT Received: by mail-control.mail.uu.net id QQkeqe06719 for mpls-outgoing; Fri, 2 Mar 2001 17:06:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqe06563 for ; Fri, 2 Mar 2001 17:06:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqe01754 for ; Fri, 2 Mar 2001 17:06:06 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqe27649 for ; Fri, 2 Mar 2001 17:06:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA12769 for mpls@uu.net; Fri, 2 Mar 2001 12:06:03 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqe05306 for ; Fri, 2 Mar 2001 17:05:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqe14865 for ; Fri, 2 Mar 2001 17:05:36 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkeqe26707 for ; Fri, 2 Mar 2001 17:05:35 GMT Received: from tappan-w2k.cisco.com (tappan-frame1.cisco.com [10.83.99.42]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA09650; Fri, 2 Mar 2001 12:04:42 -0500 (EST) Message-Id: <4.3.2.7.2.20010302115355.00b82d00@pilgrim.cisco.com> X-Sender: tappan@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Mar 2001 12:04:02 -0500 To: Shahram Davari From: Dan Tappan Subject: RE: New TTL Draft Cc: "'erosen@cisco.com'" , Bora Akyol , akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" , "'mpls@uu.net'" In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AD7@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 08:45 AM 3/2/2001 -0800, Shahram Davari wrote: >Hi Eric, > > > > 1. when a label is pushed on a packet, its TTL field is set > > to either one > > less than the iTTL, OR to a configured value; > > > > 2. when a label is popped off a packet, the TTL field of > > the newly exposed > > label or IP header is set to the minimum of (a) one less > > than the iTTL > > and (b) the existing value of the field (this rule is > > needed in order to > > prevent a TTL from getting longer as a packet travels). > > > >TTL processing mode at the egress of a tunnel MUST be the same TTL >processing mode as the ingress of that tunnel. By that I mean if the >ingress of a tunnel is processing TTL in Pipe mode, then the egress MUST >also process it in Pipe mode. If we observe this rule it is impossible for >a TTL to become larger as a packet travels. The only case that TTL may >increase is when you process the ingress as Pipe model and the egress as >uniform model. if you are trying to infer that this rule is not necessary, then I beg to differ 1. Even given your rule above, improper configuration (or bugs) at either end could cause it to be violated 2. Even given a requirement for agreement at the two ends[*], it is possible that a bug at intermediate processing could cause an MPLS TTL to end up larger than the IP TTL. The rule 2 above is simply a requirement for any correctly robust implementation. [*] Note that there are many operational benefits to _not_ requiring agreement between the two ends -- with a mp2p LSP it may be desirable to have different behavior depending on where the packet enters the LSP -- even with a p2p LSP, it may be desirable to have different behavior on a per-packet basis. For example, one might want traceroute to show hops of the LSP iff the traceroute probe originated on the ELSR. From owner-mpls@UU.NET Fri Mar 2 12:12:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07332 for ; Fri, 2 Mar 2001 12:12:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqe18436; Fri, 2 Mar 2001 17:11:58 GMT Received: by mail-control.mail.uu.net id QQkeqe08717 for mpls-outgoing; Fri, 2 Mar 2001 17:11:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeqe08696 for ; Fri, 2 Mar 2001 17:11:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqe18762 for ; Fri, 2 Mar 2001 17:10:59 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkeqe07133 for ; Fri, 2 Mar 2001 17:10:59 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00464; Fri, 2 Mar 2001 12:10:54 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA09742; Fri, 2 Mar 2001 12:10:57 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 12:10:55 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01B0BBAD@whq-msgusr-02.pit.comms.marconi.com> From: "Punj, Arun" To: "'Vach Kompella'" , "'mpls@uu.net'" Subject: RE: Expanded ERO draft Date: Fri, 2 Mar 2001 12:10:53 -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 > My vote (I didn't see dev. manager, but I run the group > that's implementing > it, so I speak on their behalf) would be to throw the router > ID in there. I > think it's great for debugging, too. You can look at an > inflight ERO and > know exactly what it is supposed to do, without reference to > a TED or an > LSDB. I entirely concur with the views above. I think it helps in debugging if you can just capture an *inflight* ERO and deduce its path. Also to me simplicitly is a more important virtue than conciseness. Hey by the way, I have not implemented any code for close to a year. So my vote is 1x - Yes. > > However, I would rather see a single ERO rather than both an > ERO and an > EERO, and the mess of having to deal with interoperability, backwards > compatibility. Not too sure about merging EERO and ERO - for the very reason mentioned above. Arun > > -Vach > From owner-mpls@UU.NET Fri Mar 2 12:50:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09256 for ; Fri, 2 Mar 2001 12:50:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqh08270; Fri, 2 Mar 2001 17:49:43 GMT Received: by mail-control.mail.uu.net id QQkeqh13288 for mpls-outgoing; Fri, 2 Mar 2001 17:49:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqh13276 for ; Fri, 2 Mar 2001 17:49:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqh24845 for ; Fri, 2 Mar 2001 17:48:39 GMT Received: from femail11.sdc1.sfba.home.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail11.sdc1.sfba.home.com [24.0.95.107]) id QQkeqh14894 for ; Fri, 2 Mar 2001 17:48:38 GMT Received: from c1052242a ([24.19.208.28]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010302174837.YJLR10024.femail11.sdc1.sfba.home.com@c1052242a>; Fri, 2 Mar 2001 09:48:37 -0800 Reply-To: From: "Manohar Naidu Ellanti" To: "Dave Danenberg" , "David Zelig" , "Jim Boyle" Cc: , , "Thomas D. Nadeau" , "Andrew G. Malis \(E-mail\)" , "tom k. johnson" Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Date: Fri, 2 Mar 2001 09:48:05 -0800 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <0E2DFCE7E586904DA0F583CB5EAD73CC03129B@WATERTOWN.litchfieldcomm.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I have a basic point to make . Why is transport of T3/T1 over MPLS networks related to SONET? CEM draft and the related MIB draft start with a header 'SONET/SDH circuit emulation ... '. -Manohar -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Dave Danenberg Sent: Friday, March 02, 2001 7:06 AM To: David Zelig; Jim Boyle Cc: mpls@UU.NET; pwot@ietf.org; Thomas D. Nadeau; Andrew G. Malis (E-mail); tom k. johnson Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Dave/Jim, We've considered your input on CEM statistics reporting and certainly agree that they are good recommendations. We consider this an open issue. But instead of immediately trying to solve it via the email list, we're thinking of raising it as an issue at the PWOT session at the upcoming IETF meeting. Then we'll gather and consider any more input, before distributing a proposal for better CEM stats. It looks like others are interested in TDM-like stats in the IP world. Did you see the thread on MPLS email under the subject heading "RE: Standards for IP stats collection? (corrected)" ? -- Dave Danenberg -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Dave Danenberg Sent: Wednesday, February 28, 2001 9:16 AM To: David Zelig; Thomas D. Nadeau; Jim Boyle; Andrew G. Malis (E-mail) Cc: mpls@UU.NET; tom k. johnson Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt David Zelig, Jim, Tom, Andy, Deriving SONET-like statistics from the CEM function is worth exploring further. As David Zelig points out, the CEM operation at the ends of the tunnel can monitor the path's B3 (BIP) byte. Although it may be tempting to piggyback on existing functionality (B3), this technique would not be able to easily discern between the errors introduced before the path reached the CEM (Ac-A in the example) and the errors introduced within the tunnel (A-Z). The CEM operation (at A) could regenerate B3, but that would violate the integrity of the path's own error statistics. So I think the way to look at this problem is by thinking of the CEM operation as what it really is - an emulated SONET 'line' carrying the path as its payload. As a 'line', the CEM could generate and terminate its own BIP. This BIP, could then be used to create the same quality and format of statistics as folks expect from SONET. For CEM to support its own payload BIP, a new field would be required in the CEM header. So this needs to carefully considered. If we were to do this, we also need to decide if the CEM payload BIP should be calculated on path or on packet delineations (i.e., calculated on the previous path frame just as B3 does, or on the CEM header to end of packet). (We'll forward this issue to the PWOT email list) Dave Danenberg -----Original Message----- From: David Zelig [mailto:Davidz@corrigent.com] Sent: Wednesday, February 28, 2001 2:11 AM To: 'Thomas D. Nadeau'; Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Tom, Dave and Jim, In order to detect payload defects at the STS level there are BIP checking on the path overhead. If an operator want to check errors generated by the CEM operation it may be simpler (and more understood) to monitor the B3 byte for errors in both ends of the tunnel. This can be done on the example below on the interface on the IP edge device. It is very hard to manipulate CEM errors to payload errors, and if the customer bought SONET service (and sign on SONET SLA) the PM should be on SONET "language" and measured at the SONET level. Sure we must cover all potential CEM errors in order to enable detecting the cause of the errors, especially for the case of problems caused by mis-configuration.I think that we need to deliver interval data for all PM related errors, and for events count. David -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, February 28, 2001 5:49 AM To: Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt At 08:02 PM 2/27/2001 -0500, Dave Danenberg wrote: >Jim, > >Thanx for your input. It sounds like you'd like to see the same sort of >statistical information from the emulated SONET that folks are >accustomed to seeing from SONET networking equipment. I like that too >(from years of developing telecomm equipment for service providers). > >Although I was considering second order counts (errored seconds) or >trends (15 minute, 24 hour interval data), I decided to start with just >simple counts - and see what folks think. > >Andy's CEM does not detect errors over the CEM payload, but it does >detect errors within the CEM header (the CEM MIB counts them with >mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps >CEM header error rates can be extrapolated to indicate payload errors >rates. Due to the nature of CEM, other types of errors are detectable >(buffer errors, missing packets, etc). Assuming CEM equipment can >process this raw info into some nice statistics, another set of objects >can be added to the CEM MIB. > >So, I'd like to include the type of statistical info you suggest as well >as your "reason for last down" idea. Would you like to see interval data >as well? > >What do you think Tom? If you agree, I can come up with another set of >objects and send it to Jim (and mpls email) for comment. Yes, as I mentioned earlier, I think these things are a good idea. Lets work on them and get our ideas back out to the list shortly. --Tom >Dave > > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle >Sent: Tuesday, February 27, 2001 2:24 PM >To: Thomas D. Nadeau >Cc: mpls@UU.NET >Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > >pretend you are a service provider, a customer calls in and says he's >seeing errors on his service (in particular, bip violalations in POH). > >He is directly connected to your network via port A. >On the far end, he connects to a clec, which hands it off to you at port >Z. He connects to a CLEC adm on port Z'. His path terminating >equipment >(maybe a router) is port Ac, and Zc, such that the service looks like: > >Ac-A-[IP]-Z-CLEC-Z'-Zc > >Looking at lines Ac-A and Z-CLEC shows clean lines. > >How does the operator determine if his IP network is to blame, or the >CLECs network is to blame? > >i'd recomend a few things: > >o) Andy's draft should have some sort of way to determine if there are >bit >errors hapenning across the IP network that affect the service >payload. This would provide the same sort of delineation of where a >problem is occuring by looking at LOHs in more traditional transport >network. > >o) your mib should include analogues to the SONET mib, such as bip-8 >violations, errored seconds, etc... (working off memory here). > >o) addition of a "reason for last down" might be nice. > >This way, when you, as the service provider, replies that "it's not our >problem, must be the clec", they can say at least go look at it later to >see if they were telling the truth. > >As usual, excellent attention paid to the configuration aspects. > >regards, > >Jim > > >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > > > > Hi, > > > > FYI a new MIB for managing SONET/SDH Circuit Emulation > > Service Over MPLS has been posted. It should be available > > shortly via the IETF's web site. In the meantime, it is available > > at the following web/ftp link. As usual, comments are welcome. > > > > >ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces - >mpls-mib-00.txt > > > > --Tom > > From owner-mpls@UU.NET Fri Mar 2 12:53:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09395 for ; Fri, 2 Mar 2001 12:53:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqh12387; Fri, 2 Mar 2001 17:52:38 GMT Received: by mail-control.mail.uu.net id QQkeqh13718 for mpls-outgoing; Fri, 2 Mar 2001 17:52:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqh13668 for ; Fri, 2 Mar 2001 17:51:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqh29864 for ; Fri, 2 Mar 2001 17:50:48 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeqh09982 for ; Fri, 2 Mar 2001 17:50:47 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id JAA03175; Fri, 2 Mar 2001 09:50:37 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <3A9F9C7F.D7819345@siliconsystems.co.in> References: <3A9403E0.AC0BEA27@sandburst.com> <3A9F9C7F.D7819345@siliconsystems.co.in> Date: Fri, 2 Mar 2001 09:48:00 -0800 To: Sachin Doshi From: Bora Akyol Subject: Re: New TTL Draft Cc: Bora Akyol , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 6:43 PM +0530 3/2/01, Sachin Doshi wrote: >Hi Bora, > Some query's : > >1. In section 2.4 u have covered MPLS routed packets? What about packets >which come to a LSR, but which are not directed to him (i mean the >MAC address of the packet was not this LSR's address. I think it is a >valid scenerio). Should TTL be decremented for such packets? If this is a bridge then the box should not care about this, if this is a router and it received a packet that was intented for it, this is an error. >2. In your later discussions, you said that you would like to keep a >value "N", by which the TTL should be decremented. Will it not be a >problem with MCAST traffic, for which we may like to keep a smaller >TTL value, so that it should not go out of an organization. Because of >this multiple TTL decrement it will not reach to the intended >recepients. N is configurable. Bora >regards. > sachin > > >Bora Akyol wrote: > >> Note that we (Puneet and I) just posted an Internet Draft on TTL >> handling in hierarchical MPLS networks. >> >> The internet draft is titled: draft-agarwal-mpls-ttl-00.txt >> >> http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt > > > > We welcome any comments, > > > > Bora Akyol From owner-mpls@UU.NET Fri Mar 2 13:18:47 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10648 for ; Fri, 2 Mar 2001 13:18:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqj13252; Fri, 2 Mar 2001 18:18:01 GMT Received: by mail-control.mail.uu.net id QQkeqj00804 for mpls-outgoing; Fri, 2 Mar 2001 18:17:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeqj00796 for ; Fri, 2 Mar 2001 18:17:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqj12529 for ; Fri, 2 Mar 2001 18:16:58 GMT Received: from prithvi.siliconsystems.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.85.131]) id QQkeqj11116 for ; Fri, 2 Mar 2001 18:16:55 GMT Received: from mail.siliconsystems.co.in (mail.siliconsystems.co.in [172.19.32.5]) by prithvi.siliconsystems.co.in (8.9.1a+p1/8.9.1/d: thinkit.m4,v 1.5 2000/06/09 23:40:41 dmccart Exp $) with ESMTP id SAA18598; Fri, 2 Mar 2001 18:16:29 GMT Received: from siliconsystems.co.in (opal.siliconsystems.co.in [172.19.32.37]) by mail.siliconsystems.co.in (8.9.3/8.9.3) with ESMTP id XAA10619; Fri, 2 Mar 2001 23:59:28 +0530 (IST) Message-ID: <3A9FE5BA.31D494DD@siliconsystems.co.in> Date: Fri, 02 Mar 2001 23:56:02 +0530 From: Sachin Doshi X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: mpls@UU.NET Subject: Re: New TTL Draft References: <3A9403E0.AC0BEA27@sandburst.com> <3A9F9C7F.D7819345@siliconsystems.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > At 6:43 PM +0530 3/2/01, Sachin Doshi wrote: > >Hi Bora, > > Some query's : > > > >1. In section 2.4 u have covered MPLS routed packets? What about packets > >which come to a LSR, but which are not directed to him (i mean the > >MAC address of the packet was not this LSR's address. I think it is a > >valid scenerio). Should TTL be decremented for such packets? > > If this is a bridge then the box should not care about this, if this > is a router and it received a packet that was intented for it, this should it not be was "not" > > is an error. > To support that this may not be a invalid scenerio here is an example: LDP says that after becoming alive LSR sends periodic hello messages to peers. Suppose there was a configuration, where R1,R2 and R3 were on the same LAN. R1 and R3 are connected through R2. (R1 and R3 are MPLS aware, but R2 is not). So for all LSP's between R1 and R3, R2 acts as a switch. Now i replace R2 with an MPLS aware router. During the time it negotiates with R1 and R3 through LDP, it will still get packets which were directed from R1 to R3 and which will be carrying R3's MAC address. For this period what should R2 do? should it switch ackets based on the L2 address or should it look for the MPLS label and try to switch the packets? regards, sachin From owner-mpls@UU.NET Fri Mar 2 13:53:57 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12545 for ; Fri, 2 Mar 2001 13:53:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeql19908; Fri, 2 Mar 2001 18:52:54 GMT Received: by mail-control.mail.uu.net id QQkeql03693 for mpls-outgoing; Fri, 2 Mar 2001 18:52:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeql03688 for ; Fri, 2 Mar 2001 18:52:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeql29847 for ; Fri, 2 Mar 2001 18:52:00 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f162.law12.hotmail.com [64.4.19.162]) id QQkeql28690 for ; Fri, 2 Mar 2001 18:52:00 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 10:51:59 -0800 Received: from 63.107.222.199 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 02 Mar 2001 18:51:59 GMT X-Originating-IP: [63.107.222.199] From: "Brian Hou" To: mpls@UU.NET Cc: mpls-ops@mplsrc.com Subject: GMPLS extensions to IGP protocols Date: Fri, 02 Mar 2001 18:51:59 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Mar 2001 18:51:59.0837 (UTC) FILETIME=[DCC768D0:01C0A349] Sender: owner-mpls@UU.NET Precedence: bulk Hi: Are there any IETF drafts that discuss the GMPLS extensions to IGPs such as OSFT and ISIS? Thanks! Brian Hou _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Fri Mar 2 14:23:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14066 for ; Fri, 2 Mar 2001 14:23:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqn08418; Fri, 2 Mar 2001 19:22:18 GMT Received: by mail-control.mail.uu.net id QQkeqn21541 for mpls-outgoing; Fri, 2 Mar 2001 19:21:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqn21533 for ; Fri, 2 Mar 2001 19:21:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeqn00543 for ; Fri, 2 Mar 2001 19:21:38 GMT Received: from mason2.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkeqn07449 for ; Fri, 2 Mar 2001 19:21:38 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id OAA10836; Fri, 2 Mar 2001 14:21:20 -0500 (EST) Date: Fri, 2 Mar 2001 14:21:19 -0500 (EST) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Brian Hou cc: mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: GMPLS extensions to IGP protocols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Brian, Here are the links to two drafts: http://search.ietf.org/internet-drafts/draft-kompella-ospf-gmpls-extensions-00.txt http://search.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-01.txt -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** On Fri, 2 Mar 2001, Brian Hou wrote: > Hi: > > Are there any IETF drafts that discuss the GMPLS extensions to IGPs such as > OSFT and ISIS? > > Thanks! > > Brian Hou > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > From owner-mpls@UU.NET Fri Mar 2 14:28:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14293 for ; Fri, 2 Mar 2001 14:28:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqn15872; Fri, 2 Mar 2001 19:27:35 GMT Received: by mail-control.mail.uu.net id QQkeqn21971 for mpls-outgoing; Fri, 2 Mar 2001 19:27:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqn21966 for ; Fri, 2 Mar 2001 19:27:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqn10964 for ; Fri, 2 Mar 2001 19:26:28 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkeqn00936 for ; Fri, 2 Mar 2001 19:26:28 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA14434; Fri, 2 Mar 2001 11:26:26 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id LAA16080; Fri, 2 Mar 2001 11:26:26 -0800 (PST) Date: Fri, 2 Mar 2001 11:26:26 -0800 (PST) From: Kireeti Kompella Message-Id: <200103021926.LAA16080@kummer.juniper.net> To: mpls@UU.NET, vkompella@JasmineNetworks.com Subject: RE: Expanded ERO draft In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Hi Vach, > I > think it's great for debugging, too. You can look at an inflight ERO and > know exactly what it is supposed to do, without reference to a TED or an > LSDB. Okay, I buy this argument -- it makes trouble shooting easier. We've added Router ID to the unnumbered ERO subobject (see version 01, just shipped to the IETF). Does this cover it? So, about EERO, the remaining questions are: 1) Why have router IDs for numbered subobjects? 2) Why have ingress and egress ids *all* the time? For the one case of multiple multiaccess interfaces on a common subnet, use two ERO subobjects. If you agree that the above two are not needed, we don't need a new EERO object. Kireeti. From owner-mpls@UU.NET Fri Mar 2 14:33:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14494 for ; Fri, 2 Mar 2001 14:33:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqo12303; Fri, 2 Mar 2001 19:32:28 GMT Received: by mail-control.mail.uu.net id QQkeqo22382 for mpls-outgoing; Fri, 2 Mar 2001 19:31:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqo22377 for ; Fri, 2 Mar 2001 19:31:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqo23198 for ; Fri, 2 Mar 2001 19:30:57 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkeqo09590 for ; Fri, 2 Mar 2001 19:30:57 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA14749; Fri, 2 Mar 2001 11:30:56 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id LAA16157; Fri, 2 Mar 2001 11:30:56 -0800 (PST) Date: Fri, 2 Mar 2001 11:30:56 -0800 (PST) From: Kireeti Kompella Message-Id: <200103021930.LAA16157@kummer.juniper.net> To: bthou@hotmail.com, mpls@UU.NET Subject: Re: GMPLS extensions to IGP protocols Cc: mpls-ops@mplsrc.com In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk > Are there any IETF drafts that discuss the GMPLS extensions to IGPs such as > OSFT and ISIS? draft-ietf-isis-gmpls-extensions-02.txt draft-kompella-ospf-gmpls-extensions-01.txt Kireeti. From owner-mpls@UU.NET Fri Mar 2 14:38:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14668 for ; Fri, 2 Mar 2001 14:38:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqo29245; Fri, 2 Mar 2001 19:37:08 GMT Received: by mail-control.mail.uu.net id QQkeqo23023 for mpls-outgoing; Fri, 2 Mar 2001 19:36:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqo23015 for ; Fri, 2 Mar 2001 19:36:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqo12450 for ; Fri, 2 Mar 2001 19:35:08 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqo17398 for ; Fri, 2 Mar 2001 19:35:07 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA01486 for mpls@uu.net; Fri, 2 Mar 2001 14:35:06 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqo22677 for ; Fri, 2 Mar 2001 19:34:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeqo28019 for ; Fri, 2 Mar 2001 19:33:40 GMT Received: from prattle.redback.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prattle.redback.com [155.53.12.9]) id QQkeqo24485 for ; Fri, 2 Mar 2001 19:33:39 GMT Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id C8DF74847B3; Fri, 2 Mar 2001 11:33:28 -0800 (PST) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id LAA29106; Fri, 2 Mar 2001 11:33:28 -0800 (PST) Date: Fri, 2 Mar 2001 11:33:28 -0800 From: Rahul Aggarwal To: Kireeti Kompella Cc: mpls@UU.NET, vkompella@JasmineNetworks.com Subject: Re: Expanded ERO draft Message-ID: <20010302113328.E27170@malt.redback.com> References: <200103021926.LAA16080@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103021926.LAA16080@kummer.juniper.net>; from kireeti@juniper.net on Fri, Mar 02, 2001 at 11:26:26AM -0800 Sender: owner-mpls@UU.NET Precedence: bulk On Fri, Mar 02, 2001 at 11:26:26AM -0800, Kireeti Kompella wrote: > Hi Vach, > > > I > > think it's great for debugging, too. You can look at an inflight ERO and > > know exactly what it is supposed to do, without reference to a TED or an > > LSDB. > > Okay, I buy this argument -- it makes trouble shooting easier. > > We've added Router ID to the unnumbered ERO subobject (see version 01, > just shipped to the IETF). Does this cover it? That is great. > > So, about EERO, the remaining questions are: > 1) Why have router IDs for numbered subobjects? > 2) Why have ingress and egress ids *all* the time? For the one > case of multiple multiaccess interfaces on a common subnet, > use two ERO subobjects. > > If you agree that the above two are not needed, we don't need a new > EERO object. I don't think the above two are needed. We don't need a new EERO object. thanks, rahul > > Kireeti. From owner-mpls@UU.NET Fri Mar 2 14:49:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15110 for ; Fri, 2 Mar 2001 14:49:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqp12752; Fri, 2 Mar 2001 19:48:34 GMT Received: by mail-control.mail.uu.net id QQkeqp23875 for mpls-outgoing; Fri, 2 Mar 2001 19:47:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqp23836 for ; Fri, 2 Mar 2001 19:47:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqp29332; Fri, 2 Mar 2001 19:46:26 GMT Received: from hoemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkeqp08473; Fri, 2 Mar 2001 19:46:25 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA08033; Fri, 2 Mar 2001 14:46:24 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA08006; Fri, 2 Mar 2001 14:46:24 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 20:46:23 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0B775448@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'te-wg@uu.net'" , Vishal Sharma Cc: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: RE: Standards for IP stats collection? (corrected) Date: Fri, 2 Mar 2001 20:46:19 +0100 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 wonder why we need to have this posted to 3 mailing lists. I suggest that after this email we just stick to te-wg. In RFC2493 we have defined a set of Textual Conventions for this sort of 15-minute interval history. They are meant for general use. Up till now, only RFC2495, 2496, 2558 and 2662 use them. Bert > ---------- > From: Vishal Sharma[SMTP:vishal@JasmineNetworks.com] > Sent: Friday, March 02, 2001 4:32 AM > To: 'te-wg@uu.net' > Cc: 'mpls@uu.net'; 'ccamp@ops.ietf.org' > Subject: Standards for IP stats collection? (corrected) > > Hello All, > > For the TDM world, GR-253 lays out strict standards for > the length of time that a carrier-class box should collect > and store statistics on-board, for retrieval later. The > number is something like 15-min intervals for 3 days. > The purpose supposedly is that if the connection to the EMS > dies, the box at least should allow the provider to recover > statistics data from it. > > My question is: what are similar standards (or existing > best practices) in the IP carrier community today? How much > statistics-related information do carriers like to have from > IP boxes? > What would carriers like to have? > > (The only reference I could find on this was Blain Christian's > draft > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00 > .t > xt) > > Are there others? > Do people (read carriers) have any thoughts or suggestions or > pointers? > > Thanks, > > -Vishal > From owner-mpls@UU.NET Fri Mar 2 15:15:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16151 for ; Fri, 2 Mar 2001 15:15:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqq10885; Fri, 2 Mar 2001 20:14:13 GMT Received: by mail-control.mail.uu.net id QQkeqq10307 for mpls-outgoing; Fri, 2 Mar 2001 20:13:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqq10302 for ; Fri, 2 Mar 2001 20:13:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeqq00757 for ; Fri, 2 Mar 2001 20:12:57 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkeqq18496 for ; Fri, 2 Mar 2001 20:12:56 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 MAA24678 for ; Fri, 2 Mar 2001 12:13:14 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA06939 for mpls@uu.net; Fri, 2 Mar 2001 15:12:54 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqq10143 for ; Fri, 2 Mar 2001 20:10:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqq22287 for ; Fri, 2 Mar 2001 20:09:10 GMT Received: from shared1-mail.whowhere.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: shared1-qin.whowhere.com [209.185.123.111]) id QQkeqq29648 for ; Fri, 2 Mar 2001 20:09:09 GMT Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Fri Mar 2 12:08:54 2001 To: mpls@UU.NET Date: Fri, 02 Mar 2001 20:38:54 +0030 From: "Manoj Kumar Juneja" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: manoj.juneja@eudoramail.com X-Mailer: MailCity Service Subject: Question about wavebandId X-Sender-Ip: 38.204.3.195 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, In draft "draft-ietf-mpls-generalized-signalling-01.txt", it is mentioned that wavebandId (32 bits) is selected by the sender and reused in all the subsequent messages. What all subsequent messages is it mentioning to ? Thanks, manoj. Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-mpls@UU.NET Fri Mar 2 15:20:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16375 for ; Fri, 2 Mar 2001 15:20:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqr23794; Fri, 2 Mar 2001 20:19:13 GMT Received: by mail-control.mail.uu.net id QQkeqr10956 for mpls-outgoing; Fri, 2 Mar 2001 20:18:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqr10946 for ; Fri, 2 Mar 2001 20:18:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqr11860 for ; Fri, 2 Mar 2001 20:18:12 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkeqr24692 for ; Fri, 2 Mar 2001 20:18:11 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 MAA17580 for ; Fri, 2 Mar 2001 12:18:27 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA06991 for mpls@uu.net; Fri, 2 Mar 2001 15:18:10 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeqq10329 for ; Fri, 2 Mar 2001 20:13:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqq13208; Fri, 2 Mar 2001 20:12:41 GMT Received: from pluto.ipass.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluto.ipass.net [198.79.53.5]) id QQkeqq07376; Fri, 2 Mar 2001 20:12:41 GMT Received: from ieee.org (adsl-80-205-79.rdu.bellsouth.net [65.80.205.79]) by pluto.ipass.net (8.9.3/8.9.3) with ESMTP id PAA22619; Fri, 2 Mar 2001 15:12:26 -0500 (EST) Message-ID: <3A9FFBF5.5C5834E6@ieee.org> Date: Fri, 02 Mar 2001 15:00:53 -0500 From: "Richard W. Tibbs" Reply-To: rtibbs@ieee.org X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "'te-wg@uu.net'" , Vishal Sharma , "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: Re: Standards for IP stats collection? (corrected) References: <2413FED0DFE6D111B3F90008C7FA61FB0B775448@nl0006exch002u.nl.lucent.com> Content-Type: multipart/mixed; boundary="------------47981B162FD3952DE8717AA4" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------47981B162FD3952DE8717AA4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have weighed in with opinions on this subject before, so again -- IP statistics collection can be divided into two areas: Traffic characteristics, and Performance characteristics. The IPPM wg as well as ITU Y.1540/1541 focus almost exclusively on the second area. Unless te-wg or ccamp can give greater effort in the first area, there is truly a hole in the fabric of traffic engineering, IMHO. Blaine's draft, which I am contributing to, seems to be a possibile point to start. One point I return to (ad nauseum, I know) is the need to understand traffic characteristics on time scales as small as seconds. 15-minute intervals were fine for best-effort. Not so fine anymore, I think. "Wijnen, Bert (Bert)" wrote: > I wonder why we need to have this posted to 3 mailing lists. > I suggest that after this email we just stick to te-wg. > > In RFC2493 we have defined a set of Textual Conventions for > this sort of 15-minute interval history. > They are meant for general use. > > Up till now, only RFC2495, 2496, 2558 and 2662 use them. > > Bert > > > ---------- > > From: Vishal Sharma[SMTP:vishal@JasmineNetworks.com] > > Sent: Friday, March 02, 2001 4:32 AM > > To: 'te-wg@uu.net' > > Cc: 'mpls@uu.net'; 'ccamp@ops.ietf.org' > > Subject: Standards for IP stats collection? (corrected) > > > > Hello All, > > > > For the TDM world, GR-253 lays out strict standards for > > the length of time that a carrier-class box should collect > > and store statistics on-board, for retrieval later. The > > number is something like 15-min intervals for 3 days. > > The purpose supposedly is that if the connection to the EMS > > dies, the box at least should allow the provider to recover > > statistics data from it. > > > > My question is: what are similar standards (or existing > > best practices) in the IP carrier community today? How much > > statistics-related information do carriers like to have from > > IP boxes? > > What would carriers like to have? > > > > (The only reference I could find on this was Blain Christian's > > draft > > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00 > > .t > > xt) > > > > Are there others? > > Do people (read carriers) have any thoughts or suggestions or > > pointers? > > > > Thanks, > > > > -Vishal > > -- http://www.makesystems.com --------------47981B162FD3952DE8717AA4 Content-Type: text/x-vcard; charset=us-ascii; name="rtibbs.vcf" Content-Description: Card for Richard W. Tibbs Content-Disposition: attachment; filename="rtibbs.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Tibbs;Richard tel;cell:919.412.4129 tel;home:919.787.4387 tel;work:919.412.4129 x-mozilla-html:FALSE version:2.1 email;internet:rtibbs@ieee.org adr;quoted-printable:;;3408 Cherry Lane=0D=0A;Raleigh;NC;27607; fn:Dr. Richard Tibbs end:vcard --------------47981B162FD3952DE8717AA4-- From owner-mpls@UU.NET Fri Mar 2 15:48:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17801 for ; Fri, 2 Mar 2001 15:48:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqt11337; Fri, 2 Mar 2001 20:47:11 GMT Received: by mail-control.mail.uu.net id QQkeqt13359 for mpls-outgoing; Fri, 2 Mar 2001 20:46:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeqt13351 for ; Fri, 2 Mar 2001 20:46:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqt29716 for ; Fri, 2 Mar 2001 20:46:22 GMT Received: from femail11.sdc1.sfba.home.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail11.sdc1.sfba.home.com [24.0.95.107]) id QQkeqt10103 for ; Fri, 2 Mar 2001 20:46:22 GMT Received: from c1052242a ([24.19.208.28]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010302204621.ZGOE10024.femail11.sdc1.sfba.home.com@c1052242a>; Fri, 2 Mar 2001 12:46:21 -0800 Reply-To: From: "Manohar Naidu Ellanti" To: "tom k. johnson" , "Dave Danenberg" , "David Zelig" , "Jim Boyle" Cc: , , "Thomas D. Nadeau" , "Andrew G. Malis \(E-mail\)" Subject: RE: [PWOT] RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Date: Fri, 2 Mar 2001 12:45:49 -0800 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <0E2DFCE7E586904DA0F583CB5EAD73CC030E14@WATERTOWN.litchfieldcomm.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, It would be nice to have the problem definition before looking at the details of CEM. To me SONET STS-N(Nc) signal transport over MPLS networks is the problem that the CEM draft seem to address and I have reservations about that. I think SONET/SDH CEM solution assumes that the client equipment connected to an MPLS network is interfacing on a OC-N interface. What if the client equipment is interfacing to MPLS network on T3/T1 interface. How is such client signal (DS1/DS3) transported if the CEM is very explicit about SONET/SDH ? Isn't it a goal to keep TDM to the network boundaries only and not have TDM aggregation creep into the core of MPLS network? I think it is more of a network architectural issue and I think carriers can help us with the problem definition. -Manohar -----Original Message----- From: tom k. johnson [mailto:tom_johnson@litchfieldcomm.com] Sent: Friday, March 02, 2001 12:28 PM To: ellanti@home.com; Dave Danenberg; David Zelig; Jim Boyle Cc: mpls@UU.NET; pwot@ietf.org; Thomas D. Nadeau; Andrew G. Malis (E-mail) Subject: RE: [PWOT] RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Manohar. Dave's draft MIB is tied directly to draft-malis-sonet-ces-mpls-03.txt. The scope of both drafts so far is SONET emulation over MPLS. Regards. -Tom -----Original Message----- From: pwot-admin@ietf.org [mailto:pwot-admin@ietf.org]On Behalf Of Manohar Naidu Ellanti Sent: Friday, March 02, 2001 12:48 PM To: Dave Danenberg; David Zelig; Jim Boyle Cc: mpls@UU.NET; pwot@ietf.org; Thomas D. Nadeau; Andrew G. Malis (E-mail); tom k. johnson Subject: [PWOT] RE: draft-danenberg-sonet-ces-mpls-mib-00.txt I have a basic point to make . Why is transport of T3/T1 over MPLS networks related to SONET? CEM draft and the related MIB draft start with a header 'SONET/SDH circuit emulation ... '. -Manohar -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Dave Danenberg Sent: Friday, March 02, 2001 7:06 AM To: David Zelig; Jim Boyle Cc: mpls@UU.NET; pwot@ietf.org; Thomas D. Nadeau; Andrew G. Malis (E-mail); tom k. johnson Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Dave/Jim, We've considered your input on CEM statistics reporting and certainly agree that they are good recommendations. We consider this an open issue. But instead of immediately trying to solve it via the email list, we're thinking of raising it as an issue at the PWOT session at the upcoming IETF meeting. Then we'll gather and consider any more input, before distributing a proposal for better CEM stats. It looks like others are interested in TDM-like stats in the IP world. Did you see the thread on MPLS email under the subject heading "RE: Standards for IP stats collection? (corrected)" ? -- Dave Danenberg -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Dave Danenberg Sent: Wednesday, February 28, 2001 9:16 AM To: David Zelig; Thomas D. Nadeau; Jim Boyle; Andrew G. Malis (E-mail) Cc: mpls@UU.NET; tom k. johnson Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt David Zelig, Jim, Tom, Andy, Deriving SONET-like statistics from the CEM function is worth exploring further. As David Zelig points out, the CEM operation at the ends of the tunnel can monitor the path's B3 (BIP) byte. Although it may be tempting to piggyback on existing functionality (B3), this technique would not be able to easily discern between the errors introduced before the path reached the CEM (Ac-A in the example) and the errors introduced within the tunnel (A-Z). The CEM operation (at A) could regenerate B3, but that would violate the integrity of the path's own error statistics. So I think the way to look at this problem is by thinking of the CEM operation as what it really is - an emulated SONET 'line' carrying the path as its payload. As a 'line', the CEM could generate and terminate its own BIP. This BIP, could then be used to create the same quality and format of statistics as folks expect from SONET. For CEM to support its own payload BIP, a new field would be required in the CEM header. So this needs to carefully considered. If we were to do this, we also need to decide if the CEM payload BIP should be calculated on path or on packet delineations (i.e., calculated on the previous path frame just as B3 does, or on the CEM header to end of packet). (We'll forward this issue to the PWOT email list) Dave Danenberg -----Original Message----- From: David Zelig [mailto:Davidz@corrigent.com] Sent: Wednesday, February 28, 2001 2:11 AM To: 'Thomas D. Nadeau'; Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Tom, Dave and Jim, In order to detect payload defects at the STS level there are BIP checking on the path overhead. If an operator want to check errors generated by the CEM operation it may be simpler (and more understood) to monitor the B3 byte for errors in both ends of the tunnel. This can be done on the example below on the interface on the IP edge device. It is very hard to manipulate CEM errors to payload errors, and if the customer bought SONET service (and sign on SONET SLA) the PM should be on SONET "language" and measured at the SONET level. Sure we must cover all potential CEM errors in order to enable detecting the cause of the errors, especially for the case of problems caused by mis-configuration.I think that we need to deliver interval data for all PM related errors, and for events count. David -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, February 28, 2001 5:49 AM To: Dave Danenberg; Jim Boyle Cc: mpls@UU.NET Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt At 08:02 PM 2/27/2001 -0500, Dave Danenberg wrote: >Jim, > >Thanx for your input. It sounds like you'd like to see the same sort of >statistical information from the emulated SONET that folks are >accustomed to seeing from SONET networking equipment. I like that too >(from years of developing telecomm equipment for service providers). > >Although I was considering second order counts (errored seconds) or >trends (15 minute, 24 hour interval data), I decided to start with just >simple counts - and see what folks think. > >Andy's CEM does not detect errors over the CEM payload, but it does >detect errors within the CEM header (the CEM MIB counts them with >mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps >CEM header error rates can be extrapolated to indicate payload errors >rates. Due to the nature of CEM, other types of errors are detectable >(buffer errors, missing packets, etc). Assuming CEM equipment can >process this raw info into some nice statistics, another set of objects >can be added to the CEM MIB. > >So, I'd like to include the type of statistical info you suggest as well >as your "reason for last down" idea. Would you like to see interval data >as well? > >What do you think Tom? If you agree, I can come up with another set of >objects and send it to Jim (and mpls email) for comment. Yes, as I mentioned earlier, I think these things are a good idea. Lets work on them and get our ideas back out to the list shortly. --Tom >Dave > > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle >Sent: Tuesday, February 27, 2001 2:24 PM >To: Thomas D. Nadeau >Cc: mpls@UU.NET >Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt > > > >pretend you are a service provider, a customer calls in and says he's >seeing errors on his service (in particular, bip violalations in POH). > >He is directly connected to your network via port A. >On the far end, he connects to a clec, which hands it off to you at port >Z. He connects to a CLEC adm on port Z'. His path terminating >equipment >(maybe a router) is port Ac, and Zc, such that the service looks like: > >Ac-A-[IP]-Z-CLEC-Z'-Zc > >Looking at lines Ac-A and Z-CLEC shows clean lines. > >How does the operator determine if his IP network is to blame, or the >CLECs network is to blame? > >i'd recomend a few things: > >o) Andy's draft should have some sort of way to determine if there are >bit >errors hapenning across the IP network that affect the service >payload. This would provide the same sort of delineation of where a >problem is occuring by looking at LOHs in more traditional transport >network. > >o) your mib should include analogues to the SONET mib, such as bip-8 >violations, errored seconds, etc... (working off memory here). > >o) addition of a "reason for last down" might be nice. > >This way, when you, as the service provider, replies that "it's not our >problem, must be the clec", they can say at least go look at it later to >see if they were telling the truth. > >As usual, excellent attention paid to the configuration aspects. > >regards, > >Jim > > >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote: > > > > > Hi, > > > > FYI a new MIB for managing SONET/SDH Circuit Emulation > > Service Over MPLS has been posted. It should be available > > shortly via the IETF's web site. In the meantime, it is available > > at the following web/ftp link. As usual, comments are welcome. > > > > >ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces - >mpls-mib-00.txt > > > > --Tom > > _______________________________________________ pwot mailing list pwot@ietf.org http://www.ietf.org/mailman/listinfo/pwot From owner-mpls@UU.NET Fri Mar 2 15:53:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18139 for ; Fri, 2 Mar 2001 15:53:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqt19999; Fri, 2 Mar 2001 20:52:52 GMT Received: by mail-control.mail.uu.net id QQkeqt13777 for mpls-outgoing; Fri, 2 Mar 2001 20:52:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqt13772 for ; Fri, 2 Mar 2001 20:52:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeqt05370 for ; Fri, 2 Mar 2001 20:52:27 GMT Received: from tcb.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQkeqt19357 for ; Fri, 2 Mar 2001 20:52:26 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 NAA02376; Fri, 2 Mar 2001 13:51:34 -0700 Message-Id: <200103022051.NAA02376@tcb.net> X-Mailer: exmh version 2.0.3 To: ellanti@home.com cc: mpls@UU.NET, pwot@ietf.org From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: [PWOT] RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Mar 2001 13:51:33 -0700 Sender: owner-mpls@UU.NET Precedence: bulk See Section 10 of Andy's -03 draft. As mentioned, additional work needs to be done to support DS-n and other services. -danny > I think SONET/SDH CEM solution assumes that the client equipment connected > to an MPLS network is interfacing on a OC-N interface. What if the client > equipment is interfacing to MPLS network on T3/T1 interface. How is such > client signal (DS1/DS3) transported if the CEM is very explicit about > SONET/SDH ? Isn't it a goal to keep TDM to the network boundaries only and > not have TDM aggregation creep into the core of MPLS network? I think it is > more of a network architectural issue and I think carriers can help us with > the problem definition. From owner-mpls@UU.NET Fri Mar 2 15:58:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18419 for ; Fri, 2 Mar 2001 15:58:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqt06635; Fri, 2 Mar 2001 20:57:04 GMT Received: by mail-control.mail.uu.net id QQkeqt14132 for mpls-outgoing; Fri, 2 Mar 2001 20:56:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqt14105 for ; Fri, 2 Mar 2001 20:56:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqt24555 for ; Fri, 2 Mar 2001 20:55:31 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqt03267 for ; Fri, 2 Mar 2001 20:55:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA12721 for mpls@uu.net; Fri, 2 Mar 2001 15:55:30 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqt13998 for ; Fri, 2 Mar 2001 20:55:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqt11140; Fri, 2 Mar 2001 20:54:55 GMT Received: from netmail2.alcatel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkeqt02202; Fri, 2 Mar 2001 20:54:54 GMT Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA29827; Fri, 2 Mar 2001 14:54:53 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f22KoML20731; Fri, 2 Mar 2001 14:50:22 -0600 (CST) Message-ID: <3AA00763.1ECF8188@usa.alcatel.com> Date: Fri, 02 Mar 2001 14:49:39 -0600 From: "Sambasiva R. Mantha" Organization: Alcatel USA X-Mailer: Mozilla 4.73 [en]C-ANS 1.02 (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: terry martin CC: ellanti@home.com, Bora Akyol , Vishal Sharma , "'te-wg@uu.net'" , "'mpls@uu.net'" , ccamp@ops.ietf.org Subject: Re: Standards for IP stats collection? (corrected) References: <001801c0a32d$ba181490$8f3918ac@talent> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I would like to correct a little bit regarding GR-253. The GR-253 requires 8 hours of 15-minute registers and 7 one-day registers and not 3-5 days. This means that a SONET must have 33 15-minute registers (32 registers for previous 8 hours and 1 for current 15 minutes) and 7 1-day (previous day) registers. I would agree with Manohar that these PM registers are an over-kill for LSPs as they really donot contribute anything to the traffic flowing through the NE. Sambu terry martin wrote: > RMON is the only protocol standard that dictates information collection > requirements. That is the only IP service that is structured to collect > trend stats. I think it is also 15 minute intervals for 3-5 days depending > on how much memory you get in the unit. > > There are structure requirements for collection, type of traffic collected > and how it is presented. > > Need sources- let me know > > Terry Martin MS Telecommunication Engineering > Senior Consultant > tmartin@gvnw.com > 503-612-4422 > > ----- Original Message ----- > From: "Manohar Naidu Ellanti" > To: "Bora Akyol" ; "Vishal Sharma" > > Cc: "'te-wg@uu.net'" ; "'mpls@uu.net'" ; > > Sent: Thursday, March 01, 2001 9:14 PM > Subject: RE: Standards for IP stats collection? (corrected) > > > It will be interesting to see if there is a need for TDM world operational > > features to be carried into MPLS world. > > > > I think the reason for 15 minutes etc PM counters for things like Severely > > Errored Seconds etc was to deduce the quality of transmission line and use > > this to feed into link cost. For instance realiability metric could be > based > > on such information for the link. > > > > For LSPs does it really make sense ? to have TDM world operational > features. > > There is not even CRC or any header information to determine if MPLS > packet > > was received correctly. It is more at lower layers. It would be nice to > see > > some useful features carried forward and avoid unnecessary requirements > from > > GR-XXX. > > > > -Manohar > > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora > > Akyol > > Sent: Thursday, March 01, 2001 8:57 PM > > To: Vishal Sharma > > Cc: 'te-wg@uu.net'; 'mpls@uu.net'; 'ccamp@ops.ietf.org' > > Subject: Re: Standards for IP stats collection? (corrected) > > > > > > Vishal > > > > I don't think that there are such standards for routers. I know that some > > routers store such data on flash cards for later retrieval and some on > > hard disks. > > > > I would be curious to see how people are storing this data and for how > > long? > > > > Bora > > > > > > On Thu, 1 Mar 2001, Vishal Sharma wrote: > > > > > Hello All, > > > > > > For the TDM world, GR-253 lays out strict standards for > > > the length of time that a carrier-class box should collect > > > and store statistics on-board, for retrieval later. The > > > number is something like 15-min intervals for 3 days. > > > The purpose supposedly is that if the connection to the EMS > > > dies, the box at least should allow the provider to recover > > > statistics data from it. > > > > > > My question is: what are similar standards (or existing > > > best practices) in the IP carrier community today? How much > > > statistics-related information do carriers like to have from > > > IP boxes? > > > What would carriers like to have? > > > > > > (The only reference I could find on this was Blain Christian's > > > draft > > > > > > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t > > > xt) > > > > > > Are there others? > > > Do people (read carriers) have any thoughts or suggestions or > > > pointers? > > > > > > Thanks, > > > > > > -Vishal > > > > > > > From owner-mpls@UU.NET Fri Mar 2 16:09:45 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18978 for ; Fri, 2 Mar 2001 16:09:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkequ18514; Fri, 2 Mar 2001 21:08:41 GMT Received: by mail-control.mail.uu.net id QQkequ29873 for mpls-outgoing; Fri, 2 Mar 2001 21:08:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkequ29731 for ; Fri, 2 Mar 2001 21:07:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkequ26594 for ; Fri, 2 Mar 2001 21:05:51 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkequ08237 for ; Fri, 2 Mar 2001 21:05:50 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA19699; Fri, 2 Mar 2001 13:05:50 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <200103021926.LAA16080@kummer.juniper.net> References: <200103021926.LAA16080@kummer.juniper.net> Date: Fri, 2 Mar 2001 13:03:10 -0800 To: Kireeti Kompella From: Bora Akyol Subject: RE: Expanded ERO draft Cc: mpls@UU.NET, vkompella@JasmineNetworks.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk Kireeti There are two reasons why it would be a good idea to add the router ID to the ERO for numbered interfaces as well: 1) It makes the ERO consistent between numbered and unnumbered objects. (Ok, this is a consistency issue) 2) It makes Abstract node lookup as described in RSVP-TE simpler for the most common type objects (/32) as in you don't need to do it at all. 3) By using the router ID in the numbered subobjects one can easily catch errors in TE database, helps troubleshooting also in this case. It makes the common path processing faster. Regarding having both ingress and egress IDs. I still think that this makes the ERO very precise and removes any ambiguity in creation of these objects. For example, we currently create the egress interfaces out of each node as the ERO, but we don't have any problem creating an object that leaves nothing to guess-work. Regardless, you can achieve the same thing by adding two ERO subobjects which wastes even more bytes than our proposal. Instead, we can make the (I/E) bits on our draft to signal three possibilities: - Both exist and are unnumbered - I exists and is unnumbered - I exists and is numbered (I may be missing a case here). So one can easily omit the ingress interface ID. To summarize, here is what I am proposing: I) Add router ID to both numbered and unnumbered subobjects. II) Improve the word alignments of the ERO subobjects as described in EERO. I will be happy with (I). Bora At 11:26 AM -0800 3/2/01, Kireeti Kompella wrote: >Hi Vach, > >> I >> think it's great for debugging, too. You can look at an inflight ERO and >> know exactly what it is supposed to do, without reference to a TED or an >> LSDB. > >Okay, I buy this argument -- it makes trouble shooting easier. > >We've added Router ID to the unnumbered ERO subobject (see version 01, >just shipped to the IETF). Does this cover it? > >So, about EERO, the remaining questions are: >1) Why have router IDs for numbered subobjects? >2) Why have ingress and egress ids *all* the time? For the one > case of multiple multiaccess interfaces on a common subnet, > use two ERO subobjects. > >If you agree that the above two are not needed, we don't need a new >EERO object. > >Kireeti. From owner-mpls@UU.NET Fri Mar 2 16:19:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19485 for ; Fri, 2 Mar 2001 16:19:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqv25468; Fri, 2 Mar 2001 21:18:27 GMT Received: by mail-control.mail.uu.net id QQkeqv01479 for mpls-outgoing; Fri, 2 Mar 2001 21:18:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqv01470 for ; Fri, 2 Mar 2001 21:18:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqv29117 for ; Fri, 2 Mar 2001 21:17:01 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkeqv15383 for ; Fri, 2 Mar 2001 21:17: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 QAA20692 for ; Fri, 2 Mar 2001 16:16:57 -0500 (EST) 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 QAA13969 for ; Fri, 2 Mar 2001 16:17:00 -0500 (EST) Message-ID: <3AA00DC6.4F90A4EB@marconi.com> Date: Fri, 02 Mar 2001 16:16:54 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP-TE draft-08 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George Swallow wrote: > > Version -08 of the RSVP-TE draft contains updates based on > the IESG last call. They are summarized below. > > ...George > >> Hello RSVP Tunnel Editors, >> >> here are the IESG's comments on >> >> >> 1) The null/best-effort service has already been advanced as a >> PS. The CoS object in the RSVP-TE (draft >> draft-ietf-mpls-rsvp-lsp-tunnel-07.txt) has an object that >> essentially serves the same purpose. The CoS object can also >> provide indications of better than BE traffic, but such >> indications can also be provided via the objects described in >> draft-ietf-mpls-diff-ext-07.txt. The IESG would like the now >> redundant CoS object removed from the RSVP-TE draft > > Section removed. Why was this summarily deleted without any discussion? Those implementations that have not yet implemented the DiffServ draft are now forced to implement it in order to signal best-effort tunnels, because the mechanism formerly employed has disappeared without any warning whatsoever. -- David From owner-mpls@UU.NET Fri Mar 2 16:22:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19734 for ; Fri, 2 Mar 2001 16:22:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqv23470; Fri, 2 Mar 2001 21:21:03 GMT Received: by mail-control.mail.uu.net id QQkeqv01692 for mpls-outgoing; Fri, 2 Mar 2001 21:20:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqv01687 for ; Fri, 2 Mar 2001 21:20:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqv05964 for ; Fri, 2 Mar 2001 21:20:07 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkeqv28062 for ; Fri, 2 Mar 2001 21:20:06 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 NAA06458 for ; Fri, 2 Mar 2001 13:20:21 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA07169 for mpls@uu.net; Fri, 2 Mar 2001 16:20:04 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqv01514 for ; Fri, 2 Mar 2001 21:18:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqv04518; Fri, 2 Mar 2001 21:18:15 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQkeqv17843; Fri, 2 Mar 2001 21:18:15 GMT Received: from mailhost.avici.com (jdube-pc.avici.com [10.2.20.235]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id f22LHSJ05219; Fri, 2 Mar 2001 16:17:28 -0500 (EST) Message-ID: <3AA00E95.29D6626D@mailhost.avici.com> Date: Fri, 02 Mar 2001 16:20:21 -0500 From: Joseph Dube X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sambasiva R. Mantha" CC: terry martin , ellanti@home.com, Bora Akyol , Vishal Sharma , "'te-wg@uu.net'" , "'mpls@uu.net'" , ccamp@ops.ietf.org Subject: Re: Standards for IP stats collection? (corrected) References: <001801c0a32d$ba181490$8f3918ac@talent> <3AA00763.1ECF8188@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Routers with POS interfaces usually implement the SONET-MIB ( rfc1595 or rfc2558) which require a minimum of 4 intervals, default to 32 intervals, with a maximum of 96 intervals (24 hours) of sonet data. This is in addition to the "current" 15 minute interval. "Sambasiva R. Mantha" wrote: > I would like to correct a little bit regarding GR-253. The GR-253 requires 8 > hours of 15-minute registers and 7 one-day registers and not 3-5 days. This > means that a SONET must have 33 15-minute registers (32 registers for previous 8 > hours and 1 for current 15 minutes) and 7 1-day (previous day) registers. > I would agree with Manohar that these PM registers are an over-kill for LSPs as > they really donot contribute anything to the traffic flowing through the NE. > > Sambu > > terry martin wrote: > > > RMON is the only protocol standard that dictates information collection > > requirements. That is the only IP service that is structured to collect > > trend stats. I think it is also 15 minute intervals for 3-5 days depending > > on how much memory you get in the unit. > > > > There are structure requirements for collection, type of traffic collected > > and how it is presented. > > > > Need sources- let me know > > > > Terry Martin MS Telecommunication Engineering > > Senior Consultant > > tmartin@gvnw.com > > 503-612-4422 > > > > ----- Original Message ----- > > From: "Manohar Naidu Ellanti" > > To: "Bora Akyol" ; "Vishal Sharma" > > > > Cc: "'te-wg@uu.net'" ; "'mpls@uu.net'" ; > > > > Sent: Thursday, March 01, 2001 9:14 PM > > Subject: RE: Standards for IP stats collection? (corrected) > > > > > It will be interesting to see if there is a need for TDM world operational > > > features to be carried into MPLS world. > > > > > > I think the reason for 15 minutes etc PM counters for things like Severely > > > Errored Seconds etc was to deduce the quality of transmission line and use > > > this to feed into link cost. For instance realiability metric could be > > based > > > on such information for the link. > > > > > > For LSPs does it really make sense ? to have TDM world operational > > features. > > > There is not even CRC or any header information to determine if MPLS > > packet > > > was received correctly. It is more at lower layers. It would be nice to > > see > > > some useful features carried forward and avoid unnecessary requirements > > from > > > GR-XXX. > > > > > > -Manohar > > > > > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora > > > Akyol > > > Sent: Thursday, March 01, 2001 8:57 PM > > > To: Vishal Sharma > > > Cc: 'te-wg@uu.net'; 'mpls@uu.net'; 'ccamp@ops.ietf.org' > > > Subject: Re: Standards for IP stats collection? (corrected) > > > > > > > > > Vishal > > > > > > I don't think that there are such standards for routers. I know that some > > > routers store such data on flash cards for later retrieval and some on > > > hard disks. > > > > > > I would be curious to see how people are storing this data and for how > > > long? > > > > > > Bora > > > > > > > > > On Thu, 1 Mar 2001, Vishal Sharma wrote: > > > > > > > Hello All, > > > > > > > > For the TDM world, GR-253 lays out strict standards for > > > > the length of time that a carrier-class box should collect > > > > and store statistics on-board, for retrieval later. The > > > > number is something like 15-min intervals for 3 days. > > > > The purpose supposedly is that if the connection to the EMS > > > > dies, the box at least should allow the provider to recover > > > > statistics data from it. > > > > > > > > My question is: what are similar standards (or existing > > > > best practices) in the IP carrier community today? How much > > > > statistics-related information do carriers like to have from > > > > IP boxes? > > > > What would carriers like to have? > > > > > > > > (The only reference I could find on this was Blain Christian's > > > > draft > > > > > > > > > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t > > > > xt) > > > > > > > > Are there others? > > > > Do people (read carriers) have any thoughts or suggestions or > > > > pointers? > > > > > > > > Thanks, > > > > > > > > -Vishal > > > > > > > > > > From owner-mpls@UU.NET Fri Mar 2 16:23:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19750 for ; Fri, 2 Mar 2001 16:23:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqv26142; Fri, 2 Mar 2001 21:22:14 GMT Received: by mail-control.mail.uu.net id QQkeqv01796 for mpls-outgoing; Fri, 2 Mar 2001 21:21:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqv01771 for ; Fri, 2 Mar 2001 21:21:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqv09060 for ; Fri, 2 Mar 2001 21:19:41 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqv20510 for ; Fri, 2 Mar 2001 21:19:36 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA16030 for mpls@uu.net; Fri, 2 Mar 2001 16:19:36 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeqv01564 for ; Fri, 2 Mar 2001 21:19:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqv04789 for ; Fri, 2 Mar 2001 21:16:55 GMT Received: from shell-beach.layer8.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQkeqv15197 for ; Fri, 2 Mar 2001 21:16:54 GMT Received: (qmail 38265 invoked by uid 1000); 2 Mar 2001 21:11:06 -0000 Date: Fri, 2 Mar 2001 13:11:06 -0800 From: Ben Black To: Bora Akyol Cc: Kireeti Kompella , mpls@UU.NET, vkompella@JasmineNetworks.com Subject: Re: Expanded ERO draft Message-ID: <20010302131105.A37750@layer8.net> References: <200103021926.LAA16080@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from akyol@pluris.com on Fri, Mar 02, 2001 at 01:03:10PM -0800 Sender: owner-mpls@UU.NET Precedence: bulk On Fri, Mar 02, 2001 at 01:03:10PM -0800, Bora Akyol wrote: > 1) It makes the ERO consistent between numbered and unnumbered > objects. (Ok, this is a consistency issue) Ok. > 2) It makes Abstract node lookup as described in RSVP-TE simpler for > the most common type objects (/32) as in you don't need to do it at > all. Doesn't introducing a special case contradict your argument for consistency above? Ben From owner-mpls@UU.NET Fri Mar 2 16:28:16 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19951 for ; Fri, 2 Mar 2001 16:28:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqv22478; Fri, 2 Mar 2001 21:26:40 GMT Received: by mail-control.mail.uu.net id QQkeqv02392 for mpls-outgoing; Fri, 2 Mar 2001 21:26:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqv02363 for ; Fri, 2 Mar 2001 21:25:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqv27099; Fri, 2 Mar 2001 21:25:26 GMT Received: from texmail.tx.uniant.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [205.158.221.6]) id QQkeqv05543; Fri, 2 Mar 2001 21:25:26 GMT Received: by texmail with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 15:25:54 -0600 Message-ID: <6D4ABF859F61D411AC5C00B0D03D7EC705F9BE@texmail> From: Michael Waldo To: "'Sambasiva R. Mantha'" , terry martin Cc: ellanti@home.com, Bora Akyol , Vishal Sharma , "'te-wg@uu.net'" , "'mpls@uu.net'" , ccamp@ops.ietf.org Subject: RE: Standards for IP stats collection? (corrected) Date: Fri, 2 Mar 2001 15:25:53 -0600 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 Sounds right for the 15-minute counters, but only current and 1 previous day counters are required for each monitored parameter. R6-301 [634v2], GR-253-CORE, Issue 3, September 2000 R6-297 [634v2], GR-253-CORE, Issue 2, December 1995, Revision 2, January 1999 -Waldo -----Original Message----- From: Sambasiva R. Mantha [mailto:sambu.mantha@usa.alcatel.com] Sent: Friday, March 02, 2001 2:50 PM To: terry martin Cc: ellanti@home.com; Bora Akyol; Vishal Sharma; 'te-wg@uu.net'; 'mpls@uu.net'; ccamp@ops.ietf.org Subject: Re: Standards for IP stats collection? (corrected) I would like to correct a little bit regarding GR-253. The GR-253 requires 8 hours of 15-minute registers and 7 one-day registers and not 3-5 days. This means that a SONET must have 33 15-minute registers (32 registers for previous 8 hours and 1 for current 15 minutes) and 7 1-day (previous day) registers. I would agree with Manohar that these PM registers are an over-kill for LSPs as they really donot contribute anything to the traffic flowing through the NE. Sambu terry martin wrote: > RMON is the only protocol standard that dictates information collection > requirements. That is the only IP service that is structured to collect > trend stats. I think it is also 15 minute intervals for 3-5 days depending > on how much memory you get in the unit. > > There are structure requirements for collection, type of traffic collected > and how it is presented. > > Need sources- let me know > > Terry Martin MS Telecommunication Engineering > Senior Consultant > tmartin@gvnw.com > 503-612-4422 > > ----- Original Message ----- > From: "Manohar Naidu Ellanti" > To: "Bora Akyol" ; "Vishal Sharma" > > Cc: "'te-wg@uu.net'" ; "'mpls@uu.net'" ; > > Sent: Thursday, March 01, 2001 9:14 PM > Subject: RE: Standards for IP stats collection? (corrected) > > > It will be interesting to see if there is a need for TDM world operational > > features to be carried into MPLS world. > > > > I think the reason for 15 minutes etc PM counters for things like Severely > > Errored Seconds etc was to deduce the quality of transmission line and use > > this to feed into link cost. For instance realiability metric could be > based > > on such information for the link. > > > > For LSPs does it really make sense ? to have TDM world operational > features. > > There is not even CRC or any header information to determine if MPLS > packet > > was received correctly. It is more at lower layers. It would be nice to > see > > some useful features carried forward and avoid unnecessary requirements > from > > GR-XXX. > > > > -Manohar > > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora > > Akyol > > Sent: Thursday, March 01, 2001 8:57 PM > > To: Vishal Sharma > > Cc: 'te-wg@uu.net'; 'mpls@uu.net'; 'ccamp@ops.ietf.org' > > Subject: Re: Standards for IP stats collection? (corrected) > > > > > > Vishal > > > > I don't think that there are such standards for routers. I know that some > > routers store such data on flash cards for later retrieval and some on > > hard disks. > > > > I would be curious to see how people are storing this data and for how > > long? > > > > Bora > > > > > > On Thu, 1 Mar 2001, Vishal Sharma wrote: > > > > > Hello All, > > > > > > For the TDM world, GR-253 lays out strict standards for > > > the length of time that a carrier-class box should collect > > > and store statistics on-board, for retrieval later. The > > > number is something like 15-min intervals for 3 days. > > > The purpose supposedly is that if the connection to the EMS > > > dies, the box at least should allow the provider to recover > > > statistics data from it. > > > > > > My question is: what are similar standards (or existing > > > best practices) in the IP carrier community today? How much > > > statistics-related information do carriers like to have from > > > IP boxes? > > > What would carriers like to have? > > > > > > (The only reference I could find on this was Blain Christian's > > > draft > > > > > > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t > > > xt) > > > > > > Are there others? > > > Do people (read carriers) have any thoughts or suggestions or > > > pointers? > > > > > > Thanks, > > > > > > -Vishal > > > > > > > From owner-mpls@UU.NET Fri Mar 2 16:28:43 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19974 for ; Fri, 2 Mar 2001 16:28:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqv08986; Fri, 2 Mar 2001 21:27:43 GMT Received: by mail-control.mail.uu.net id QQkeqv02563 for mpls-outgoing; Fri, 2 Mar 2001 21:27:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqv02525 for ; Fri, 2 Mar 2001 21:27:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqv21605 for ; Fri, 2 Mar 2001 21:26:54 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkeqv07705 for ; Fri, 2 Mar 2001 21:26:52 GMT Received: from [172.16.55.141] ([172.16.55.141]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA21228; Fri, 2 Mar 2001 13:26:41 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: In-Reply-To: <20010302131105.A37750@layer8.net> References: <200103021926.LAA16080@kummer.juniper.net> <20010302131105.A37750@layer8.net> Date: Fri, 2 Mar 2001 13:24:04 -0800 To: Ben Black From: Bora Akyol Subject: Re: Expanded ERO draft Cc: Bora Akyol , Kireeti Kompella , mpls@UU.NET, vkompella@JasmineNetworks.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 1:11 PM -0800 3/2/01, Ben Black wrote: >On Fri, Mar 02, 2001 at 01:03:10PM -0800, Bora Akyol wrote: >> 1) It makes the ERO consistent between numbered and unnumbered >> objects. (Ok, this is a consistency issue) > >Ok. > >> 2) It makes Abstract node lookup as described in RSVP-TE simpler for >> the most common type objects (/32) as in you don't need to do it at > > all. > >Doesn't introducing a special case contradict your argument for >consistency above? > > >Ben This is a good point. Once you agree to add the router ID, it takes a few lines of code to diffentiate between /32 subobjects and others. In our EERO draft, this is why we separated out Abstract Node and Loose route subobjects from the strict subobjects. But if you want to use the ERO, then if you have a non-/32 subobject you can safely ignore the router ID. Alternatively, we can merge the EERO with ERO and end up with something along the lines: 1) Create separate Abstract Node and Loose Route subobjects as described in EERO draft. 2) Add router ID to both strict numbered and unnumbered subobjects. This will result in a more consistent solution. Just out of curiousity, how often does one encounter either Loose or Abstract Node subobjects in real networks? Bora From owner-mpls@UU.NET Fri Mar 2 16:59:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21534 for ; Fri, 2 Mar 2001 16:59:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqx00435; Fri, 2 Mar 2001 21:57:41 GMT Received: by mail-control.mail.uu.net id QQkeqx05552 for mpls-outgoing; Fri, 2 Mar 2001 21:57:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqx05544 for ; Fri, 2 Mar 2001 21:57:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqx04753 for ; Fri, 2 Mar 2001 21:56:04 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqx17471 for ; Fri, 2 Mar 2001 21:56:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA21866 for mpls@uu.net; Fri, 2 Mar 2001 16:56:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqx05464 for ; Fri, 2 Mar 2001 21:55:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqx00142 for ; Fri, 2 Mar 2001 21:55:23 GMT Received: from viva.vivacenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: viva.vivacenetworks.com [208.36.16.5] (may be forged)) id QQkeqx16557 for ; Fri, 2 Mar 2001 21:55:23 GMT Received: from AMALIS.vivacenet.com [216.112.176.96] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A65B36A035E; Fri, 02 Mar 2001 13:53:31 -0800 Message-Id: <5.0.2.1.2.20010302164958.03c0eda0@viva.vivacenet.com> X-Sender: Andy.Malis@viva.vivacenet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 02 Mar 2001 16:53:24 -0500 To: From: "Andrew G. Malis" Subject: RE: [PWOT] RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Cc: "tom k. johnson" , "Dave Danenberg" , "David Zelig" , "Jim Boyle" , , , "Thomas D. Nadeau" , "Andrew G. Malis \(E-mail\)" In-Reply-To: References: <0E2DFCE7E586904DA0F583CB5EAD73CC030E14@WATERTOWN.litchfieldcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Manohar, Your viewpoint is appreciated. I've already included this topic area (support for DS-N) in the open issues section of draft-malis-sonet-ces-mpls-03.txt. I'm looking forward to further discussion on the list and at Minneapolis to see if we can reach consensus on the requirements and candidate implementation solutions. Thanks, Andy ------- At 3/2/2001 12:45 PM -0800, Manohar Naidu Ellanti wrote: >Tom, > >It would be nice to have the problem definition before looking at the >details of CEM. To me SONET STS-N(Nc) signal transport over MPLS networks >is the problem that the CEM draft seem to address and I have reservations >about that. > >I think SONET/SDH CEM solution assumes that the client equipment connected >to an MPLS network is interfacing on a OC-N interface. What if the client >equipment is interfacing to MPLS network on T3/T1 interface. How is such >client signal (DS1/DS3) transported if the CEM is very explicit about >SONET/SDH ? Isn't it a goal to keep TDM to the network boundaries only and >not have TDM aggregation creep into the core of MPLS network? I think it is >more of a network architectural issue and I think carriers can help us with >the problem definition. > > >-Manohar From owner-mpls@UU.NET Fri Mar 2 17:13:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22169 for ; Fri, 2 Mar 2001 17:13:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqy11937; Fri, 2 Mar 2001 22:13:16 GMT Received: by mail-control.mail.uu.net id QQkeqy21869 for mpls-outgoing; Fri, 2 Mar 2001 22:12:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqy21861 for ; Fri, 2 Mar 2001 22:12:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqy17844 for ; Fri, 2 Mar 2001 22:11:02 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqy08875 for ; Fri, 2 Mar 2001 22:11:01 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA23525 for mpls@uu.net; Fri, 2 Mar 2001 17:11:00 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqy21625 for ; Fri, 2 Mar 2001 22:10:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeqy11151 for ; Fri, 2 Mar 2001 22:08:47 GMT Received: from viva.vivacenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: viva.vivacenetworks.com [208.36.16.5] (may be forged)) id QQkeqy05570 for ; Fri, 2 Mar 2001 22:08:46 GMT Received: from AMALIS.vivacenet.com [216.112.176.96] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A8EBD370336; Fri, 02 Mar 2001 14:04:27 -0800 Message-Id: <5.0.2.1.2.20010302165404.04d66bd8@viva.vivacenet.com> X-Sender: Andy.Malis@viva.vivacenet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 02 Mar 2001 17:04:19 -0500 To: Heiles Juergen From: "Andrew G. Malis" Subject: Re: [PWOT] RE: draft-danenberg-sonet-ces-mpls-mib-00.txt Cc: "'Dave Danenberg'" , David Zelig , Jim Boyle , mpls@UU.NET, pwot@ietf.org, "Thomas D. Nadeau" , "Andrew G. Malis (E-mail)" , "tom k. johnson" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Heiles, >Concerning CEM over MPLS for CBR signals like a STS-SPE/VC in general I >share some of the doubts expressed in a previous mail, specifically for >clock jitter and wander. The MPLS transport could result in excessive >pointer justification of the STS-SPE or VT outside the Sonet/SDH >specifications. As you have probably noticed, one of the areas that still needs more fleshing out in draft-malis-sonet-ces-mpls-03.txt are the underlying QoS requirements for the MPLS transport. Of course, the QoS you can get is dependent on the capabilities of the MPLS LSRs - best effort forwarding only is obviously insufficient. The more interesting question is what IS sufficient in the transport network to be able to meet the generally accepted requirements for bit error rates, clock jitter and wander, etc., and how large do the jitter buffers need to be at the receiver? Of course, using the EF codepoint in either an E-LSP or L-LSP is the obvious starting point, but that will still be dependent on the network operators allocating sufficient resources for EF traffic in their networks so that the emulated SONET circuits perform adequately. It may end up being an iterative process, at least at first, in order to get it right. Regarding jitter buffers, most people I've discussed this with seem to think that about 10-15 ms worth of buffering should be more than sufficient. I appreciate any other thoughts you may have. Cheers, Andy From owner-mpls@UU.NET Fri Mar 2 17:20:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22410 for ; Fri, 2 Mar 2001 17:20:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqz24003; Fri, 2 Mar 2001 22:19:28 GMT Received: by mail-control.mail.uu.net id QQkeqz22435 for mpls-outgoing; Fri, 2 Mar 2001 22:19:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqz22429 for ; Fri, 2 Mar 2001 22:19:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqz27976 for ; Fri, 2 Mar 2001 22:19:02 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqz29893 for ; Fri, 2 Mar 2001 22:19:01 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA24719 for mpls@uu.net; Fri, 2 Mar 2001 17:19:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqz22419 for ; Fri, 2 Mar 2001 22:18:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeqz18138 for ; Fri, 2 Mar 2001 22:17:39 GMT Received: from tnnt3.tachion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQkeqz27256 for ; Fri, 2 Mar 2001 22:17:39 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Mar 2001 17:00:26 -0500 Message-ID: <5E7936641DC2D411B89900D0B7B92FBB0FA432@TNNT3> From: Cheenu Srinivasan To: "'mpls@uu.net'" Cc: "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" Subject: draft-ietf-mpls-te-mib-06.txt posted Date: Fri, 2 Mar 2001 17:00:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A364.2FD52EB2" 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_01C0A364.2FD52EB2 Content-Type: text/plain; charset="iso-8859-1" An updated version of MPLS-TE-MIB has been posted as draft-ietf-mpls-te-mib-06.txt and should appear on the IETF website shortly. This incorporates last call comments on this mailing list. Thanks. Cheenu ------_=_NextPart_001_01C0A364.2FD52EB2 Content-Type: text/html; charset="iso-8859-1" draft-ietf-mpls-te-mib-06.txt posted

An updated version of MPLS-TE-MIB has been posted as
draft-ietf-mpls-te-mib-06.txt and should appear on
the IETF website shortly. This incorporates last
call comments on this mailing list. Thanks.

Cheenu

------_=_NextPart_001_01C0A364.2FD52EB2-- From owner-mpls@UU.NET Fri Mar 2 17:30:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22693 for ; Fri, 2 Mar 2001 17:30:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqz17492; Fri, 2 Mar 2001 22:29:57 GMT Received: by mail-control.mail.uu.net id QQkeqz23146 for mpls-outgoing; Fri, 2 Mar 2001 22:29:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeqz23140 for ; Fri, 2 Mar 2001 22:29:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqz11771 for ; Fri, 2 Mar 2001 22:28:05 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkeqz11857 for ; Fri, 2 Mar 2001 22:28:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA25916 for mpls@uu.net; Fri, 2 Mar 2001 17:28:04 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkeqz23017 for ; Fri, 2 Mar 2001 22:27:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqz16429 for ; Fri, 2 Mar 2001 22:26:53 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkeqz10190 for ; Fri, 2 Mar 2001 22:26:52 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA24233 for ; Fri, 2 Mar 2001 17:26:52 -0500 (EST) Message-Id: <200103022226.RAA24233@pilgrim.cisco.com> To: mpls@UU.NET Subject: WG Last call Date: Fri, 02 Mar 2001 17:26:51 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message begins a last call on draft-ietf-mpls-diff-ext-08.txt The last call closes March 16, midnite GMT. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Mar 2 19:02:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25091 for ; Fri, 2 Mar 2001 19:02:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkerg04749; Sat, 3 Mar 2001 00:02:07 GMT Received: by mail-control.mail.uu.net id QQkerg19198 for mpls-outgoing; Sat, 3 Mar 2001 00:01:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkerg19169 for ; Sat, 3 Mar 2001 00:01:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkerg22947 for ; Sat, 3 Mar 2001 00:00:10 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkerg02814 for ; Sat, 3 Mar 2001 00:00: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 TAA00130 for ; Fri, 2 Mar 2001 19:00:06 -0500 (EST) 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 TAA08109 for ; Fri, 2 Mar 2001 19:00:09 -0500 (EST) Message-ID: <3AA03402.6E881C4E@marconi.com> Date: Fri, 02 Mar 2001 19:00:02 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: WG Last call References: <200103022226.RAA24233@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George Swallow wrote: > > This message begins a last call on > > draft-ietf-mpls-diff-ext-08.txt > > The last call closes March 16, midnite GMT. I've several problems with it. I apologize for not mentioning them until now, but I had not read it until now. In section 5.3, it says: If a DIFFSERV object is not present in the Path message, the LSR SHOULD interpret this as a request for an E-LSP using the Preconfigured EXP<-->PHB Mapping. This is bad. This means that a non-DiffServ message will be interpreted differently if received by a DS-capable router vs. a non-DS-capable router. If the DIFFSERV object is missing, the message should be processed as it would by a router that has not implemented the diff-ext draft at all. I realize that there is an "override option", but this looks to me like a hack. This override option behavior should be the only behavior, because it is impossible to signal a non-DS LSP through a DS-capable router without it. ------------ The second problem involves the use of this draft in conjunction with the latest changes to RSVP-TE (version -08). Version -08 eleimates the COS service type from the TSPEC and FLOWSPEC objects. The DS draft requires that COS-type objects be used in order to signal an L-LSP without bandwidth reservations. With the current revisions of these two drafts, this type of LSP can not be signalled at all. It effectively makes it impossible to use RSVP-TE to signal a best-effort LSP (either E-LSP or L-LSP) Either the COS-type TSpec must be put back in RSVP-TE, or the DS draft must be updated to provide a means for singalling a best-effort LSP. ------------- A third problem involves the fact that the SENDER_TSPEC is now optional in a Path message. This means that routers conforming to this spec will be generating messages that non-DS-capable routers will be forced to reject. The RSVP-TE draft still states that SENDER_TSPEC is a mandatory object. There is no mention of whether a FLOWSPEC is optional in Resv messages. If the COS C-Type is eliminated, then FLOWSPEC must become optional, if a best-effort LSP is possible, since presence of an IntServ FLOWSPEC will indicate a bandwidth reservation. This will create a similar incompatibility as with the absence of SENDER_TSPEC in Path messages. It seems to me that routers implementing this draft will be unable to interoperate with routers that do not implement it. IMO, this is unacceptible. -- David From owner-mpls@UU.NET Fri Mar 2 19:19:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25303 for ; Fri, 2 Mar 2001 19:19:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkerh27892; Sat, 3 Mar 2001 00:18:45 GMT Received: by mail-control.mail.uu.net id QQkerh02044 for mpls-outgoing; Sat, 3 Mar 2001 00:18:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkerh02034 for ; Sat, 3 Mar 2001 00:17:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkerh22916 for ; Sat, 3 Mar 2001 00:17:49 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe19.law9.hotmail.com [64.4.8.123]) id QQkerh02452 for ; Sat, 3 Mar 2001 00:17:49 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 16:17:48 -0800 X-Originating-IP: [64.228.250.32] From: "mpls36@hotmail" To: Date: Fri, 2 Mar 2001 19:30:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Message-ID: X-OriginalArrivalTime: 03 Mar 2001 00:17:48.0851 (UTC) FILETIME=[60E63830:01C0A377] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA25303 unsubscribe From owner-mpls@UU.NET Fri Mar 2 22:47:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00624 for ; Fri, 2 Mar 2001 22:47:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkerv20506; Sat, 3 Mar 2001 03:47:10 GMT Received: by mail-control.mail.uu.net id QQkerv01154 for mpls-outgoing; Sat, 3 Mar 2001 03:46:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkerv01102 for ; Sat, 3 Mar 2001 03:46:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkerv06272 for ; Sat, 3 Mar 2001 03:46:13 GMT Received: from cad.zju.edu.cn by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQkerv19182 for ; Sat, 3 Mar 2001 03:46:11 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 303 for ; Fri, 2 Mar 2001 22:07:27 +0800 Message-ID: <3A9FA8C8.C7E0A89C@cad.zju.edu.cn> Date: Fri, 02 Mar 2001 22:06:00 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Loop detection in RFC3036 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit if it has been asked before , execuse for my stupid question please. I'm reading rfc3036 to learn some basics of LSP building. while in 2.8.3 , it is said -- "Note that in a network where only non-merge capable LSRs are present, Path Vectors are passed downstream from ingress to egress, and are not passed upstream. Even when merge is supported, Path Vectors need not be passed upstream along an LSP which is known to reach the egress. When an LSR experiences a change of next hop, it need pass Path Vectors upstream only when it cannot tell from the hop count that the change of next hop does not result in a loop. " As it said MPLS just support downstream determined lable distribution, as I think it means any LDP packet should be first transmitted from downstream to upstream. why here states " Path Vectors are passed downstreams from ingress to egree and are not passwd upstream" ? why is it related to label merge ? James shen From owner-mpls@UU.NET Sat Mar 3 00:18:00 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01463 for ; Sat, 3 Mar 2001 00:17:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeqq15141; Fri, 2 Mar 2001 20:11:49 GMT Received: by mail-control.mail.uu.net id QQkeqq10199 for mpls-outgoing; Fri, 2 Mar 2001 20:11:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkeqq10176 for ; Fri, 2 Mar 2001 20:11:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeqq07856 for ; Fri, 2 Mar 2001 20:10:52 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkeqq03282 for ; Fri, 2 Mar 2001 20:10: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 MAA11743 for ; Fri, 2 Mar 2001 12:11:06 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA06909 for mpls@uu.net; Fri, 2 Mar 2001 15:10:48 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeqp23721 for ; Fri, 2 Mar 2001 19:45:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkeqp13585 for ; Fri, 2 Mar 2001 19:45:04 GMT Received: from netreference.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netreference.com [206.181.70.94]) id QQkeqp10408 for ; Fri, 2 Mar 2001 19:45:03 GMT Received: from ILAZAR2KP.mplsrc.com (206.181.70.74) by netreference.com with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 3 Mar 2001 15:58:33 +0100 Message-Id: <5.0.2.1.2.20010302144337.049d1898@mail.mplsrc.com> X-Sender: ilazar@mplsrc.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 02 Mar 2001 14:44:10 -0500 To: "Brian Hou" , mpls@UU.NET From: Irwin Lazar Subject: Re: GMPLS extensions to IGP protocols Cc: mpls-ops@mplsrc.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk these have been added to www.mplsrc.com/drafts.shtml irwin At 06:51 PM 3/2/2001 +0000, Brian Hou wrote: >Hi: > >Are there any IETF drafts that discuss the GMPLS extensions to IGPs such >as OSFT and ISIS? > >Thanks! > >Brian Hou >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Sat Mar 3 08:23:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18674 for ; Sat, 3 Mar 2001 08:23:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQketh21646; Sat, 3 Mar 2001 13:23:08 GMT Received: by mail-control.mail.uu.net id QQketh07720 for mpls-outgoing; Sat, 3 Mar 2001 13:22:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQketh07708 for ; Sat, 3 Mar 2001 13:22:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQketh18652 for ; Sat, 3 Mar 2001 13:22:24 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQketh20802 for ; Sat, 3 Mar 2001 13:22:23 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f23DLYf08522; Sat, 3 Mar 2001 14:21:43 +0100 (MET) Received: from alcatel.be ([138.203.253.200]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A04.00495BAA; Sat, 3 Mar 2001 14:21:17 +0100 Message-ID: <3AA0EE64.4CD03BB7@alcatel.be> Date: Sat, 03 Mar 2001 14:15:17 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: puneet@pluris.com CC: mpls@UU.NET, Bora Akyol , Francois Le Faucheur , liwwu@cisco.com, pierre.debuysscher@alcatel.be, Marijke Coenen , finizoll@sh.bel.alcatel.be Subject: New TTL Draft Content-Type: multipart/mixed; boundary="------------DDB55BA5C34136846F8E8D88" Sender: owner-mpls@UU.NET Precedence: bulk Dit is een multi-gedeelten-bericht in MIME-formaat. --------------DDB55BA5C34136846F8E8D88 Content-Type: multipart/alternative; boundary="------------6C9E4A93621B6216088CD032" --------------6C9E4A93621B6216088CD032 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Puneeth, Your reply below states the following: > In fact, even non > ingress/PH/egress LSRs may also need to know the LSP model to support > features, like "fast reroute", offered by some vendors. > What would be the difference for the 'fast reroute' feature if the LSP complies with the pipe or uniform model respectively? Kind regards, Francis. ----------------- http://cell.onecall.net/mhonarc/mpls/2001-Feb/msg00285.html --------------6C9E4A93621B6216088CD032 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Puneeth,

Your reply below states the following: 

In fact, even non
ingress/PH/egress LSRs may also need to know the LSP model to support
features, like "fast reroute", offered by some vendors.


What would be the difference for the 'fast reroute' feature if the LSP complies with the pipe or uniform model respectively?

Kind regards,

    Francis.

-----------------

http://cell.onecall.net/mhonarc/mpls/2001-Feb/msg00285.html --------------6C9E4A93621B6216088CD032-- --------------DDB55BA5C34136846F8E8D88 Content-Type: text/html; charset=us-ascii; name="msg00285.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msg00285.html" Content-Base: "http://cell.onecall.net/mhonarc/mpls/2 001-Feb/msg00285.html" Content-Location: "http://cell.onecall.net/mhonarc/mpls/2 001-Feb/msg00285.html" Content-Transfer-Encoding: 7bit New TTL Draft

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New TTL Draft


Eric,

Thanks for your comments. My comments are inline.

-Puneet

[...]
>> [...]
>> >
>> >    Finally, what is the mechanism which the PHP uses to determine
>> >whether or not the LSP is using the pipe or the uniform model?  I am
>> >not sure this information is currently available.
>>
>> You may be right. I looked through 
>"draft-ietf-mpls-diff-ext-08.txt", but
>> did not see any method to signal the model (pipe or uniform) 
>associated with
>> the LSP, using either RSVP or LDP. If it is a missing piece, 
>then I hope
>> that it will be addressed by the authors of that draft.
>
>This would address the case where you are just
>addressing the disparity between DS usage and
>TTL.  But what about the more general case -
>i.e. - where DS is not involved?
>
>The answer that how the PH knows this is out
>of scope, might be good enough, but I would like
>to know what people are thinking.  I am not sure
>that configuration makes sense since it is not
>necessarily clear in every case which LSRs are
>going to end up being the penultimate hop for
>which LSPs.  It really doesn't make a lot of
>sense to punt the issue if the current answer
>to the question "how could we make it work?" is
>"magic"...
>

You are correct. In my earlier reply I overlooked the fact that this could
be used in non DS cases.

The issue is in some sense broader than just PH knowing the model of the
LSP. The ingress and the egress LSRs also need to know the model (pipe or
uniform) of the LSP so they can consistent in their handling of TTL. The
ideal solution would be to add a new object to the PATH message (for RSVP)
indicating the LSP model being used so that ingress/PH/egress LSRs can be
consistent. Something similar can be done for LDP. In fact, even non
ingress/PH/egress LSRs may also need to know the LSP model to support
features, like "fast reroute", offered by some vendors.

I think you and I agree that there is a hole. I am not convinced that our
TTL draft is the correct place to define the signalling mechanism outlined
above. I can certainly look into addressing this is in a separate draft
depending on the response from the authors of
"draft-ietf-mpls-diff-ext-08.txt".

Hence I would rather add text to our TTL draft to the effect that "how the
LSR knows the model of any LSP is outside the scope of this draft".

-Puneet


>>
>>
>> -Puneet
>>
>> [...]
>
>--
>Eric Gray
>
>

  • Follow-Ups:
    • New TTL Draft
      • From: "S.Matsushima" <satoru@japan-telecom.co.jp>
--------------DDB55BA5C34136846F8E8D88-- From owner-mpls@UU.NET Sat Mar 3 08:38:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18743 for ; Sat, 3 Mar 2001 08:38:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQketi10759; Sat, 3 Mar 2001 13:38:19 GMT Received: by mail-control.mail.uu.net id QQketi08667 for mpls-outgoing; Sat, 3 Mar 2001 13:37:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQketi08662 for ; Sat, 3 Mar 2001 13:37:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQketi23155 for ; Sat, 3 Mar 2001 13:37:45 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQketi13823 for ; Sat, 3 Mar 2001 13:37:44 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f23DbBk08808; Sat, 3 Mar 2001 14:37:11 +0100 (MET) Received: from alcatel.be ([138.203.253.200]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A04.004ACC0B; Sat, 3 Mar 2001 14:37:01 +0100 Message-ID: <3AA0F214.D2A9CA47@alcatel.be> Date: Sat, 03 Mar 2001 14:31:00 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: puneet@pluris.com CC: mpls@UU.NET, Bora Akyol , Francois Le Faucheur , liwwu@cisco.com, Shahram Davari , Bruce Davie , pierre.debuysscher@alcatel.be, Marijke Coenen , finizoll@sh.bel.alcatel.be Subject: Comments on draft-agarwal-mpls-ttl-00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Puneet, Please find included some comments to your draft draft-agarwal-mpls-ttl-00. Kind regards, Francis. -------------- 1) Section 2.2. The text states that oTTL = iTTL -1 and that it is checked whether oTTL is greater than 0. However, this does not cover the receipt of an (erroneous) MPLS packet with a TTL of 0. In this case setting oTTL = iTTL - 1, would result in a oTTL value different from 0. So the MPLS packet would still pass the oTTL check while it should not have. Therefore, I propose to check the iTTL, rather than the oTTL: * A check is done whether or not the iTTL value is strictly larger than 1. This check on the iTTL value should only be done once it has been determined that the packet is routed (as an IP or MPLS packet) to a next node. 2) Section 2.2. The text states that 'the oTTL check is performed only if an outgoing TTL is set to oTTL'. However, this is inconsistent with the statement in section 2.4 - 3rd bullet: "PHP case - The oTTL check should be performed irrespective of whether the oTTL is used in any outgoing label / IP header". 3) Section 2.3. The text states that '... we are performing a push / swap / PHP, then the iTTL is the TTL ...'. I propose to remove the 'push' since this is irrelevant for the incoming TTL determination; the push is handled in section 2.4 (outgoing TTL determination). From owner-mpls@UU.NET Sat Mar 3 10:06:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20030 for ; Sat, 3 Mar 2001 10:06:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQketo24895; Sat, 3 Mar 2001 15:06:14 GMT Received: by mail-control.mail.uu.net id QQketo14008 for mpls-outgoing; Sat, 3 Mar 2001 15:05:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQketo14003 for ; Sat, 3 Mar 2001 15:05:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQketo01861 for ; Sat, 3 Mar 2001 15:04:07 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQketo15443 for ; Sat, 3 Mar 2001 15:04:06 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f23F1hB10187; Sat, 3 Mar 2001 16:01:47 +0100 (MET) Received: from alcatel.be ([138.203.253.200]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A04.005288D8; Sat, 3 Mar 2001 16:01:31 +0100 Message-ID: <3AA105E3.2B83004C@alcatel.be> Date: Sat, 03 Mar 2001 15:55:31 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: eric.gray@sandburst.com CC: akyol@akyol.org, mpls@UU.NET, Prakash <"Prakash K ;"@alcatel.be>, pierre.debuysscher@alcatel.be, Marijke Coenen , finizoll@sh.bel.alcatel.be Subject: New TTL Draft Content-Type: multipart/mixed; boundary="------------08195C15BD7F5BBF48CAFEDE" Sender: owner-mpls@UU.NET Precedence: bulk Dit is een multi-gedeelten-bericht in MIME-formaat. --------------08195C15BD7F5BBF48CAFEDE Content-Type: multipart/alternative; boundary="------------1AF96F277A4DF2468B7A58C1" --------------1AF96F277A4DF2468B7A58C1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Eric, In the discussion below you propose the possibility to decrement the TTL with N units. You indicate that the reason for doing this, is the following: > > > There are practical reasons for decrementing TTL by more > > >than one (a high-cost or low-bandwidth link, for example) > > >when it is desirable to accelerate the aging of possibly looping > > >packets. A higher TTL decrement punishes all packets that use > > >the link, but it punishes looping packets much more. > High-cost and low-bandwidth links should be used carefully in a network. But why would one like to accelerate the aging for packets received on a high-cost or low-bandwidth link? Kind regards, Francis. -------------- http://cell.onecall.net/mhonarc/mpls/2001-Feb/msg00316.html --------------1AF96F277A4DF2468B7A58C1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello Eric,

In the discussion below you propose the possibility to decrement the TTL with N units. You indicate that the reason for doing this, is the following: 

> >    There are practical reasons for decrementing TTL by more
> >than one (a high-cost or low-bandwidth link, for example)
> >when it is desirable to accelerate the aging of possibly looping
> >packets.  A higher TTL decrement punishes all packets that use
> >the link, but it punishes looping packets much more.


High-cost and low-bandwidth links should be used carefully in a network. But why would one like to accelerate the aging for packets received on a high-cost or low-bandwidth link?

Kind regards,

    Francis.

--------------

http://cell.onecall.net/mhonarc/mpls/2001-Feb/msg00316.html --------------1AF96F277A4DF2468B7A58C1-- --------------08195C15BD7F5BBF48CAFEDE Content-Type: text/html; charset=us-ascii; name="msg00316.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msg00316.html" Content-Base: "http://cell.onecall.net/mhonarc/mpls/2 001-Feb/msg00316.html" Content-Location: "http://cell.onecall.net/mhonarc/mpls/2 001-Feb/msg00316.html" Content-Transfer-Encoding: 7bit New TTL Draft

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New TTL Draft


Hi Shahram,

Thanks for your comments. My comments are inline.

-Puneet

>
>Hi Puneet/Eric,
>
>1)You are right we have not described how to signal Pipe/short 
>pipe/uniform models. Since our draft is in its last call and 
>can't be changed substantially, I propose that we get together 
>to write a separate I-D to address the CR-LDP/RSVP-TE 
>extensions for signaling the tunneling model.

Agreed. We can take this up privately with each other.

>
>2) Section 2.4 does not discuss an important case that is: 
>egress processing of tunnels, i.e. pop and forwarding the 
>packet as MPLS. 

Pop (or Egress Pop to distinguish from PHP) is actually covered in section
2.3. The possibly operation when forwarding the packet as MPLS are covered
in the 3 bullets  of section 2.4. Combine section 2.3 and the relevant
section of 2.4 and I think your concern about the missing case should be
answered. Hence as far as I can see the case is convered, but please let me
know if you still think that it is not addressed.
>
>3)As you may know, version -08 of our draft has introduced two 
>types of Pipe tunnels a) Short pipe and b) Pipe. The short 
>pipe is what was called the "pipe" in version -07. But the new 
>"pipe" model is a bit different, in the sense that all the 
>egress processing is done based on top label. So your 
>description of TTL processing for the pipe model remains valid 
>for "short pipe" (except that you need to describe the egress 
>processing too, see bullet 2 above), but you need to define 
>another TTL processing rule for the "pipe", which is:  the top 
>label TTL is decremented and checked, while the lower label 
>TTL (unchanged) is used for forwarding the packet. 

We had based our draft on -07 version of the mpls-diff draft. I will take
into account the -08 version (where the new model nomenclature was
introduced) and update our spec accordingly.

-Puneet
>
>Yours,
>-Shahram
>
>
>
>
>> -----Original Message-----
>> From: Puneet Agarwal [mailto:puneet@pluris.com]
>> Sent: Friday, February 23, 2001 4:53 PM
>> To: 'Eric Gray'
>> Cc: 'mpls@uu.net'; 'flefauch@cisco.com'; 'liwwu@cisco.com';
>> 'bsd@cisco.com'; Shahram Davari; Bora Akyol
>> Subject: RE: New TTL Draft
>> 
>> 
>> Eric,
>> 
>> Comments inline.
>> 
>> >-----Original Message-----
>> >From: Eric Gray [mailto:eric.gray@sandburst.com]
>> >Sent: Friday, February 23, 2001 9:34 AM
>> >To: Bora Akyol
>> >Cc: akyol@akyol.org; djiang1@lucent.com; B, Prakash K (Prakash);
>> >'mpls@uu.net'
>> >Subject: Re: New TTL Draft
>> >
>> >
>> >Bora/Puneet,
>> >
>> >    Some comments.
>> >
>> >    In section 2.4, item 3 - PHP does not necessarily expose an
>> >IP header.  The text in this section is not clear in this respect
>> >- possibly because of the textual construct "IP-Header/label".
>> >It might be somewhat clearer if you use "header" and add a
>> >paragraph stating that the PHP exposed header may be either
>> >an IP header or an MPLS label and the appropriate oTTL  is
>> >written to the corresponding TTL field of this PHP exposed
>> >header.
>> 
>> I agree. We will change the wording in the next rev of the draft. 
>> >
>> >    Also, in this section, why is oTTL set to the TTL of the
>> >exposed header if it is not used for anything?
>> 
>> Good point. We do not need to set this. This was a leftover 
>> from some text
>> we took out of section 2.5 at the last moment that used this 
>> information. We
>> will fix this in the next rev.
>> >
>> >    In addition, if your actually specifying a behavior (rather than
>> >an architecture), I believe you need to allow that the TTL may
>> >be decremented by a number other than one.  RFC 791 states
>> >that RFC is decremented by at least one.  Your draft states in
>> >several places that iTTL is decremented (I assume that the
>> >underscore in these cases is meant to be a minus sign) by one.
>> 
>> The underscore is indeed supposed to be a minus. Will be 
>> fixed in the next
>> rev.
>> I have no problems in allowing the iTTL to be decremented by 
>> more than one.
>> I will change the text to state that the iTTL should be 
>> decremented by "N",
>> where "N" is user configured and is greater than 0. The 
>> default value of "N"
>> should be 1.
>> 
>> >
>> >    There are practical reasons for decrementing TTL by more
>> >than one (a high-cost or low-bandwidth link, for example)
>> >when it is desirable to accelerate the aging of possibly looping
>> >packets.  A higher TTL decrement punishes all packets that use
>> >the link, but it punishes looping packets much more.
>> >
>> >    Finally, what is the mechanism which the PHP uses to determine
>> >whether or not the LSP is using the pipe or the uniform model?  I am
>> >not sure this information is currently available.
>> 
>> You may be right. I looked through 
>> "draft-ietf-mpls-diff-ext-08.txt", but
>> did not see any method to signal the model (pipe or uniform) 
>> associated with
>> the LSP, using either RSVP or LDP. If it is a missing piece, 
>> then I hope
>> that it will be addressed by the authors of that draft.
>> 
>> -Puneet
>> 
>> >
>> >--
>> >Eric Gray
>> >
>> >Bora Akyol wrote:
>> >
>> >> Note that we (Puneet and I) just posted an Internet Draft on TTL
>> >> handling in hierarchical MPLS networks.
>> >>
>> >> The internet draft is titled: draft-agarwal-mpls-ttl-00.txt
>> >>
>> >> 
>> http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt
>> >>
>> >> We welcome any comments,
>> >>
>> >> Bora Akyol
>> >
>> 
>

--------------08195C15BD7F5BBF48CAFEDE-- From owner-mpls@UU.NET Sat Mar 3 13:54:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23241 for ; Sat, 3 Mar 2001 13:54:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkeud17235; Sat, 3 Mar 2001 18:53:46 GMT Received: by mail-control.mail.uu.net id QQkeud14532 for mpls-outgoing; Sat, 3 Mar 2001 18:53:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkeud14526 for ; Sat, 3 Mar 2001 18:53:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkeud19457; Sat, 3 Mar 2001 18:52:49 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQkeud11568; Sat, 3 Mar 2001 18:52:48 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Sat, 3 Mar 2001 18:50:18 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id <1PCPW03V>; Sat, 3 Mar 2001 18:51:38 -0000 Message-ID: To: sambu.mantha@usa.alcatel.com, tmartin@gvnw.com, bwijnen@lucent.com Cc: ellanti@home.com, akyol@pluris.com, vishal@JasmineNetworks.com, te-wg@UU.NET, mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Standards for IP stats collection? (corrected) Date: Sat, 3 Mar 2001 18:51:42 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Bert....I can understand your earlier comment (wrt wanting limiting WG coverage), but I can probably understand why Vishal wrote to several lists: - IP need its own perf management regime - MPLS ditto - GMPLS ditto....and there can be several layer networks involved here, eg SDH (which has several distinct internal layer networks) and OTN. This is unavoidable as each of the above create layer networks that must be managed in their own right. And to do a proper job its not simply QoS Perf stats that are at issue for operators, its more like this: 1 user-plane and control-plane need their own OAM once dealing with CO paths, eg GMPLS/MPLS-ER-LSPs, since one cannot assume user/control-plane congruence of function or routing....so they are independent. In the user-plane one must have an initial clear view of defects (entry/exit criteria) and their handling (ie correct consequent actions). For an operator this is an operational must-have. 2 After above, the next issue is availability. This has to be defined before QoS metrics/objectives can be considered. Why? QoS metrics are only valid when a path is in the up-state, otherwise the QoS metrics have no viable time-base and/or can get (statistically) distorted by events which should be regarded as down-time ....so up/down-state transitions need to be clearly identified next. Note - this issue is not clear-cut for the IP layer when dealing with destination-based hop-hop routing. Indeed, there are very difficult issues with failures mutating into QoS hits which I have raised on the MPLS list before which make availability analysis of the IP layer impossible (IMO) for the *network* (ie as subnetwork partitioned allocations of a global reference connection) except on a true end-end basis. 3 Now we can consider QoS.....but be careful. It costs money to measure/collect/process (in OSS) these....every technology I have been involved with has started with a large metric wish-list that gets whittled down to something more pragmatic later. My advice is that these should be of 2 types of QoS metric collection: (i) ad hoc 'sw-on' function for trouble-shooting as needed by operational people, or the continuous measurement of 'important' paths, and (ii) general network population sampling (to get overall network trends and spot latent anomolous behaviour). 4 policing/re-classification actions need monitoring. 5 nodal/link utilisations need monitoring and fed to a TE function and the design/forecasting cycle. So one needs a framework, where these pieces relate but where one piece does not attempt to the job of all the others. BTW - We (ie me/Shahram Davari/Ben Mack-Crane/Peter Willis) have just posted an ID for MPLS user-plane which deals with 1 and 2 above. neil > -----Original Message----- > From: Sambasiva R. Mantha [mailto:sambu.mantha@usa.alcatel.com] > Sent: 02 March 2001 20:50 > To: terry martin > Cc: ellanti@home.com; Bora Akyol; Vishal Sharma; 'te-wg@uu.net'; > 'mpls@uu.net'; ccamp@ops.ietf.org > Subject: Re: Standards for IP stats collection? (corrected) > > > I would like to correct a little bit regarding GR-253. The > GR-253 requires 8 > hours of 15-minute registers and 7 one-day registers and not > 3-5 days. This > means that a SONET must have 33 15-minute registers (32 > registers for previous 8 > hours and 1 for current 15 minutes) and 7 1-day (previous > day) registers. > I would agree with Manohar that these PM registers are an > over-kill for LSPs as > they really donot contribute anything to the traffic flowing > through the NE. > > Sambu > > > terry martin wrote: > > > RMON is the only protocol standard that dictates > information collection > > requirements. That is the only IP service that is > structured to collect > > trend stats. I think it is also 15 minute intervals for > 3-5 days depending > > on how much memory you get in the unit. > > > > There are structure requirements for collection, type of > traffic collected > > and how it is presented. > > > > Need sources- let me know > > > > Terry Martin MS Telecommunication Engineering > > Senior Consultant > > tmartin@gvnw.com > > 503-612-4422 > > > > ----- Original Message ----- > > From: "Manohar Naidu Ellanti" > > To: "Bora Akyol" ; "Vishal Sharma" > > > > Cc: "'te-wg@uu.net'" ; "'mpls@uu.net'" ; > > > > Sent: Thursday, March 01, 2001 9:14 PM > > Subject: RE: Standards for IP stats collection? (corrected) > > > > > It will be interesting to see if there is a need for TDM > world operational > > > features to be carried into MPLS world. > > > > > > I think the reason for 15 minutes etc PM counters for > things like Severely > > > Errored Seconds etc was to deduce the quality of > transmission line and use > > > this to feed into link cost. For instance realiability > metric could be > > based > > > on such information for the link. > > > > > > For LSPs does it really make sense ? to have TDM world operational > > features. > > > There is not even CRC or any header information to > determine if MPLS > > packet > > > was received correctly. It is more at lower layers. It > would be nice to > > see > > > some useful features carried forward and avoid > unnecessary requirements > > from > > > GR-XXX. > > > > > > -Manohar > > > > > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On > Behalf Of Bora > > > Akyol > > > Sent: Thursday, March 01, 2001 8:57 PM > > > To: Vishal Sharma > > > Cc: 'te-wg@uu.net'; 'mpls@uu.net'; 'ccamp@ops.ietf.org' > > > Subject: Re: Standards for IP stats collection? (corrected) > > > > > > > > > Vishal > > > > > > I don't think that there are such standards for routers. > I know that some > > > routers store such data on flash cards for later > retrieval and some on > > > hard disks. > > > > > > I would be curious to see how people are storing this > data and for how > > > long? > > > > > > Bora > > > > > > > > > On Thu, 1 Mar 2001, Vishal Sharma wrote: > > > > > > > Hello All, > > > > > > > > For the TDM world, GR-253 lays out strict standards for > > > > the length of time that a carrier-class box should collect > > > > and store statistics on-board, for retrieval later. The > > > > number is something like 15-min intervals for 3 days. > > > > The purpose supposedly is that if the connection to the EMS > > > > dies, the box at least should allow the provider to recover > > > > statistics data from it. > > > > > > > > My question is: what are similar standards (or existing > > > > best practices) in the IP carrier community today? How much > > > > statistics-related information do carriers like to have from > > > > IP boxes? > > > > What would carriers like to have? > > > > > > > > (The only reference I could find on this was Blain Christian's > > > > draft > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-christian-tewg-me asurement-00.t > > > xt) > > > > > > Are there others? > > > Do people (read carriers) have any thoughts or suggestions or > > > pointers? > > > > > > Thanks, > > > > > > -Vishal > > > > > > > From owner-mpls@UU.NET Sun Mar 4 00:39:31 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03110 for ; Sun, 4 Mar 2001 00:39:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkevu10559; Sun, 4 Mar 2001 05:38:57 GMT Received: by mail-control.mail.uu.net id QQkevu11184 for mpls-outgoing; Sun, 4 Mar 2001 05:38:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkevu11177 for ; Sun, 4 Mar 2001 05:38:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkevu11689 for ; Sun, 4 Mar 2001 05:37:08 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkevu02123 for ; Sun, 4 Mar 2001 05:37:07 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id VAA14507; Sat, 3 Mar 2001 21:36:39 -0800 (PST) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id VAA29883; Sat, 3 Mar 2001 21:36:39 -0800 (PST) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs Date: Sat, 3 Mar 2001 21:36:38 -0800 (PST) From: Bora Akyol To: Francis Arts cc: akyol@pluris.com, puneet@pluris.com, mpls@UU.NET, Francois Le Faucheur , liwwu@cisco.com, Shahram Davari , Bruce Davie , pierre.debuysscher@alcatel.be, Marijke Coenen , finizoll@sh.bel.alcatel.be Subject: Re: Comments on draft-agarwal-mpls-ttl-00 In-Reply-To: <3AA0F214.D2A9CA47@alcatel.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Sat, 3 Mar 2001, Francis Arts wrote: > > Puneet, > > Please find included some comments to your draft > draft-agarwal-mpls-ttl-00. > > Kind regards, > > Francis. > > -------------- > > 1) Section 2.2. > > The text states that oTTL = iTTL -1 and that it is checked whether oTTL > is greater than 0. > > However, this does not cover the receipt of an (erroneous) MPLS packet > with a TTL of 0. In this case setting oTTL = iTTL - 1, would result in a > oTTL value different from 0. So the MPLS packet would still pass the > oTTL check while it should not have. > > Therefore, I propose to check the iTTL, rather than the oTTL: > * A check is done whether or not the iTTL value is strictly larger than > 1. This check on the iTTL value should only be done once it has been > determined that the packet is routed (as an IP or MPLS packet) to a next > node. Francis, I believe the text says to check for oTTL > 0/ > > > 2) Section 2.2. > > The text states that 'the oTTL check is performed only if an outgoing > TTL is set to oTTL'. > > However, this is inconsistent with the statement in section 2.4 - 3rd > bullet: "PHP case - The oTTL check should be performed irrespective of > whether the oTTL is used in any outgoing label / IP header". This will be fixed in the next version of the draft. > > > 3) Section 2.3. > > The text states that '... we are performing a push / swap / PHP, then > the iTTL is the TTL ...'. We put the word "push" there to clearly differentiate against the "POP" case. Even when you are pushing, you still need to determine the iTTL so that you can determine the TTL for the label that is being pushed. > > I propose to remove the 'push' since this is irrelevant for the incoming > TTL determination; the push is handled in section 2.4 (outgoing TTL > determination). > From owner-mpls@UU.NET Sun Mar 4 01:46:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07976 for ; Sun, 4 Mar 2001 01:46:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkevz06636; Sun, 4 Mar 2001 06:45:39 GMT Received: by mail-control.mail.uu.net id QQkevz00672 for mpls-outgoing; Sun, 4 Mar 2001 06:45:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkevy00457 for ; Sun, 4 Mar 2001 06:44:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkevy27601 for ; Sun, 4 Mar 2001 06:44:14 GMT Received: from mail.eis.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.41.97.131]) id QQkevy04898 for ; Sun, 4 Mar 2001 06:44:12 GMT Received: from uucp-relay-delhi.ernet.in (vikram.doe.ernet.in [202.41.100.90]) by mail.eis.ernet.in (Netscape Messaging Server 4.15) with ESMTP id G9NVZH02.Z3W; Sun, 4 Mar 2001 12:11:41 +0500 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id MAA27216; Sun, 4 Mar 2001 12:14:26 -0500 (GMT) >Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id LAA13913; Sun, 4 Mar 2001 11:50:38 -0500 Message-ID: <3AA1DDC7.866189AE@cdotd.ernet.in> Date: Sun, 04 Mar 2001 11:46:39 +0530 From: Alok Tripathi Reply-To: alokt@cdotd.ernet.in Organization: C_DOT X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: alok_tripathi@chequemail.com Subject: MPLS traffic engineering query. Content-Transfer-Encoding: 7bit Received: from cdotd by vikram.doe.ernet.in; Sun, 4 Mar 2001 12:14 GMT Content-Type: text/plain; charset=RESERVED Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi *, I have a query on the MPLS traffic engineering application. The route of a TE tunnel is determined by either static definition or a "constraint based routeing" (CBR) calculation on the tunnel head end. Signalling mechanism then sets up the LSP based on the calculated route. Since CBR computation requires the full topology information , which gets hidden across OSPF areas & domains, How do we extend the Traffic Engineering beyond :-- 1.a single OSPF area in case of a large ISP ? 2.Across the domains ? Thanks in advance. Alok Tripathi, Research Engineer, Centre for Development of Telematics, C-DOT Akbar Bhawan, Chanakyapuri, New Delhi, India. From owner-mpls@UU.NET Sun Mar 4 09:50:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11443 for ; Sun, 4 Mar 2001 09:50:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkexf23190; Sun, 4 Mar 2001 14:50:00 GMT Received: by mail-control.mail.uu.net id QQkexf01225 for mpls-outgoing; Sun, 4 Mar 2001 14:49:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkexf01218 for ; Sun, 4 Mar 2001 14:49:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkexf19225 for ; Sun, 4 Mar 2001 14:48:47 GMT Received: from imchub1.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imchub1.cosinecom.com [63.88.104.18]) id QQkexf21531 for ; Sun, 4 Mar 2001 14:48:47 GMT Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Sun, 4 Mar 2001 06:48:56 -0800 Received: from cosinecom.com (172.17.144.245 [172.17.144.245]) by exchsrv1.cosinecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQ0GB43Y; Sun, 4 Mar 2001 06:46:01 -0800 From: Tatsuya Yanagibashi Cc: Narakasura Dumbo , mpls@UU.NET Message-ID: <3AA255B1.F61698@cosinecom.com> Date: Sun, 04 Mar 2001 23:48:17 +0900 X-Mailer: Mozilla 4.75 [ja] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 Subject: Re: RSVP & OSPF-TE ... References: <20010301143207.59913.qmail@web12806.mail.yahoo.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Pappai, What I am understanding is "color" is not carried in RSVP PATH message. As I menthioned you before, it is used for establishment of traffic engineering LSP. By using OSPF-TE, for example, netowrk administrator can gether some traffic engineering information in addition to normal link state database. "Color" is one of object of traffic engineering information. I think that this "color" is designed for categorize each link between LSR for traffic engineering purpose. Generally TE LSP is able to established manually(explicitly) or dynamically(CSPF). If dynamic TE LSP setup is prefered by configration, you can specify that "color" as administrative constraint for TE LSP. I am not sure which vendor has implemented this feature, though. Appreciate any comments. Thanks. Regards, Tatsuya Yanagibashi Narakasura Dumbo wrote: > > Hi Tatsuya, > > Thanks for the reply. > > My question is where is this "color" constraint > carried in the RSVP PATH message ? > > Thanks > Pappai > > --- Tatsuya Yanagibashi > wrote: > > Pappai, > > > > narakasura Dumbo wrote: > > > > > > I have a couple of questions > > > > > > 1. How do we signal the "color" (32 colors that > > > can be assigned to a link, Katz OSPF-TE draft) > > > using RSVP-TE ? Is this addressed somewhere > > ? > > > > Conceptually the information of TE such like a > > "color" is used for > > calculating the PATH under administrative > > constraints in MPLS cloud. > > Currently CSPF is able to handle its calculation. > > After its computation > > and calculation, Ingress LSR is going to SIGNAL by > > using RSVP-TE or > > CR-LDP with ER(O) along the path by CSPF > > calculation. > > > > Rgds, > > Tatsuya > > > > -- > > > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > +----+----+ Tatsuya Yanagibashi > > > > |.. .| | > > |_~__| | Network Consultant > > | .. |~~_~| CoSine Communications > > Inc. > > | . | | > > +----+----+ e-mail: > > tyanagibashi@cosinecom.com > > C o S i n e Phone # +81-3-5219-1292 > > Communications Fax # +81-3-5219-1201 > > > > > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +----+----+ Tatsuya Yanagibashi |.. .| | |_~__| | Network Consultant | .. |~~_~| CoSine Communications Inc. | . | | +----+----+ e-mail: tyanagibashi@cosinecom.com C o S i n e Phone # +81-3-5219-1292 Communications Fax # +81-3-5219-1201 /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-mpls@UU.NET Mon Mar 5 01:05:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20599 for ; Mon, 5 Mar 2001 01:05:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkezo21394; Mon, 5 Mar 2001 06:04:06 GMT Received: by mail-control.mail.uu.net id QQkezo00200 for mpls-outgoing; Mon, 5 Mar 2001 06:03:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkezo00189 for ; Mon, 5 Mar 2001 06:03:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkezo18862 for ; Mon, 5 Mar 2001 06:03:33 GMT Received: from mail.marhold.at by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.marhold.at [194.152.126.85]) id QQkezo09441 for ; Mon, 5 Mar 2001 06:03:32 GMT Received: from AMARHOLD ([192.168.1.36]) by mail.marhold.at (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id at; Mon, 5 Mar 2001 07:12:44 +0100 From: "Alexander Marhold" To: "Tatsuya Yanagibashi" Cc: "Narakasura Dumbo" , Subject: RE: RSVP & OSPF-TE ... Date: Mon, 5 Mar 2001 07:03:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <3AA255B1.F61698@cosinecom.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The "Colour" is implemented in Cisco IOS Traffic Engineering on a link you can specify: xxx (config-if)# mpls traffic-eng attribute-flags 0x00000012 and on the tunnel-interface: yyy (config-if)# tunnel mpls traffic-eng affinity 0x00000012 mask 0x000000ff the affinity longword (32bit) on the tunnel must match the attribute-flags on each link for the bits which are set to 1 in the mask The CSPF checks each link for this match before considering that link for TE-SPF calculation. As was already said correctly, this "Colour" is not transported ( as it has no use) via RSVP but the link "Colour(s)" are transported via ISIS or OSPF together with the bandwidth information with best regards Alexander Marhold Senior Consultant PRO IN -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Tatsuya Yanagibashi Sent: Sunday, March 04, 2001 3:48 PM Cc: Narakasura Dumbo; mpls@UU.NET Subject: Re: RSVP & OSPF-TE ... Pappai, What I am understanding is "color" is not carried in RSVP PATH message. As I menthioned you before, it is used for establishment of traffic engineering LSP. By using OSPF-TE, for example, netowrk administrator can gether some traffic engineering information in addition to normal link state database. "Color" is one of object of traffic engineering information. I think that this "color" is designed for categorize each link between LSR for traffic engineering purpose. Generally TE LSP is able to established manually(explicitly) or dynamically(CSPF). If dynamic TE LSP setup is prefered by configration, you can specify that "color" as administrative constraint for TE LSP. I am not sure which vendor has implemented this feature, though. Appreciate any comments. Thanks. Regards, Tatsuya Yanagibashi Narakasura Dumbo wrote: > > Hi Tatsuya, > > Thanks for the reply. > > My question is where is this "color" constraint > carried in the RSVP PATH message ? > > Thanks > Pappai > > --- Tatsuya Yanagibashi > wrote: > > Pappai, > > > > narakasura Dumbo wrote: > > > > > > I have a couple of questions > > > > > > 1. How do we signal the "color" (32 colors that > > > can be assigned to a link, Katz OSPF-TE draft) > > > using RSVP-TE ? Is this addressed somewhere > > ? > > > > Conceptually the information of TE such like a > > "color" is used for > > calculating the PATH under administrative > > constraints in MPLS cloud. > > Currently CSPF is able to handle its calculation. > > After its computation > > and calculation, Ingress LSR is going to SIGNAL by > > using RSVP-TE or > > CR-LDP with ER(O) along the path by CSPF > > calculation. > > > > Rgds, > > Tatsuya > > > > -- > > > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > +----+----+ Tatsuya Yanagibashi > > > > |.. .| | > > |_~__| | Network Consultant > > | .. |~~_~| CoSine Communications > > Inc. > > | . | | > > +----+----+ e-mail: > > tyanagibashi@cosinecom.com > > C o S i n e Phone # +81-3-5219-1292 > > Communications Fax # +81-3-5219-1201 > > > > > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +----+----+ Tatsuya Yanagibashi |.. .| | |_~__| | Network Consultant | .. |~~_~| CoSine Communications Inc. | . | | +----+----+ e-mail: tyanagibashi@cosinecom.com C o S i n e Phone # +81-3-5219-1292 Communications Fax # +81-3-5219-1201 /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-mpls@UU.NET Mon Mar 5 03:54:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09166 for ; Mon, 5 Mar 2001 03:54:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkezz29250; Mon, 5 Mar 2001 08:53:36 GMT Received: by mail-control.mail.uu.net id QQkezz12129 for mpls-outgoing; Mon, 5 Mar 2001 08:53:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkezz12120 for ; Mon, 5 Mar 2001 08:53:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkezz12493 for ; Mon, 5 Mar 2001 08:52:21 GMT Received: from mail.eis.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.41.97.131]) id QQkezz10759 for ; Mon, 5 Mar 2001 08:52:17 GMT Received: from uucp-relay-delhi.ernet.in (vikram.doe.ernet.in [202.41.100.90]) by mail.eis.ernet.in (Netscape Messaging Server 4.15) with ESMTP id G9PWKU00.20A; Mon, 5 Mar 2001 14:19:42 +0500 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id OAA02019; Mon, 5 Mar 2001 14:22:28 -0500 (GMT) >Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id OAA27347; Mon, 5 Mar 2001 14:01:45 -0500 Message-ID: <3AA34E03.CA983CC7@cdotd.ernet.in> Date: Mon, 05 Mar 2001 13:57:47 +0530 From: Alok Tripathi Reply-To: alokt@cdotd.ernet.in Organization: C_DOT X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: alok_tripathi@chequemail.com, mpls@UU.NET Subject: Re: MPLS traffic engineering query. References: Content-Transfer-Encoding: 7bit Received: from cdotd by vikram.doe.ernet.in; Mon, 5 Mar 2001 14:22 GMT Content-Type: text/plain; charset=RESERVED Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > There has been a few internet drafts on addressing TE across multiple > OSPF/ISIS areas. Not much interest in the WG however. Thanks for your reply. I wonder whether there is no requirement for TE tunnels to span across multiple OSPF areas or AS domains ? If there is then what is the mechanism for that ? Also how do we define the inter-domain traffic enginering model ? Thanks in advance. Regards, Alok Tripathi, Research Engineer, C-DOT, Delhi, India. From owner-mpls@UU.NET Mon Mar 5 04:30:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09573 for ; Mon, 5 Mar 2001 04:30:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfab24328; Mon, 5 Mar 2001 09:29:19 GMT Received: by mail-control.mail.uu.net id QQkfab29594 for mpls-outgoing; Mon, 5 Mar 2001 09:28:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfab29588 for ; Mon, 5 Mar 2001 09:28:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfab20318 for ; Mon, 5 Mar 2001 09:28:46 GMT Received: from solen.ce.chalmers.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: solen.ce.chalmers.se [129.16.20.244]) id QQkfab23517 for ; Mon, 5 Mar 2001 09:28:45 GMT Received: from timotej.ce.chalmers.se (timotej.ce.chalmers.se [129.16.20.39]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id KAA27840; Mon, 5 Mar 2001 10:28:45 +0100 (MET) Received: (from otel@localhost) by timotej.ce.chalmers.se (8.8.8/8.8.8) id KAA23210; Mon, 5 Mar 2001 10:28:44 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15011.23628.550762.201542@timotej.ce.chalmers.se> Date: Mon, 5 Mar 2001 10:28:44 +0100 (MET) From: Florian-Daniel Otel To: mpls@UU.NET Cc: otel@ce.chalmers.se Subject: LMP over switched Ethernet X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Florian-Daniel Otel Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I am intrested about the LMP capability to detect a failing router behind an Ethernet switch. From a (very) quick skim (read: grep) through the LMP draft I got the impression that -- as it uses IP encoded messages for the control channel (in this case identical w/ the data channel) -- it will work and LMP does detect a failing router behind an Eth. switch. Is this right or am I missing something ? Florian From owner-mpls@UU.NET Mon Mar 5 06:30:05 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10378 for ; Mon, 5 Mar 2001 06:30:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfaj10480; Mon, 5 Mar 2001 11:28:07 GMT Received: by mail-control.mail.uu.net id QQkfaj07568 for mpls-outgoing; Mon, 5 Mar 2001 11:27:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfaj07554 for ; Mon, 5 Mar 2001 11:27:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfaj07834; Mon, 5 Mar 2001 11:27:19 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQkfaj28914; Mon, 5 Mar 2001 11:27:19 GMT Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP; Mon, 5 Mar 2001 11:08:16 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Mon, 5 Mar 2001 11:09:46 -0000 Message-ID: To: rtibbs@ieee.org Cc: te-wg@UU.NET, mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Standards for IP stats collection? (corrected) Date: Mon, 5 Mar 2001 11:09:47 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Richard, thanks for your comments....my response below: > I think (but am not quite sure from your wording) that you > find the goal of > separating > failure analysis at the physical/link layers from > availabiltiy & QoS at the IP > layer unattainable. NH=> Sorry I was not clear Richard. One can separate availability and QoS for CO entities. How easy this is in practice depends on whether one has started with a clear architectural understanding of the nature of the problem, and thus ensures that functional measurements (of defects) are based on pragmatic OAM tools, cf how difficult availability measurements are for ATM (ie after 10 years study this could not be done.....since it was based on some fundamental architectural errors of judgement at the outset (and BTW too much emphasis on the I.356 QoS metric wish-list that would never be cost-effective to measure) that made it too complex to solve) vs what is in our recent MPLS draft. With a CNLS layer the problem is not clear-cut due to the intrinsic dependency of the user-plane on a stable/valid control-plane.....this is *not* necessarily a weakness, nor should it be viewed as such (indeed it is a strength for *certain* types of traffic). The simple fact is that CO networks and CNLS networks behave differently. In the former we have the opportunity to separate availability and QoS and in the latter we can't (at least within the network, as ad hoc partitions of some HRX - hypothetical reference connection) except on an end-end basis. The basic behaviour difference here is that on failure: - CO fabrics only affect the customers whose traffic is carried by the failed trail(s), ie this traffic dies, and other non-affected customer traffic sees no avail/QoS deterioration; - CNLS fabrics mutate failures into QoS hits since the overall traffic demand is not constrained post-failure.....DiffServ then skews this relationship (noting that there is no relationship between a traffic's survivability requirements and its up-state QoS requirements, eg voice must go EF for delay/jitter transfer requirements, but whether a *given* voice traffic source is mission critical (ie must survive on failure) or not cannot be inferred from the DS codepoints alone. This can be expanded to AF classes, ie there is no QoS/survivabiity relationship. > My view is that these functions of network state are > inter-related and to seek > to make them > independent is quixotic. > Here is a view: > The various layers below IP will have outage phenomena. These > are measurable, > albeit imperfectly. > Both control-plane and data-plane will have outage phenomena. > These are > measurable, I think. NH=> Yes they are. The key issue is whether one affects the other. In CNLS fabrics this is an intrinsic behaviour, in CO fabrics it does not have to be. For example, in plain IP the user-plane is effectively 'dead' for as long as the IGP is incorrectly converged (eg post failure), whereas in ER-MPLS or GMPLS (for example) there can be disjoint routed user/control-planes (indeed, in GMPLS the control-plane will use a logically seperate network from the user-plane, whose only survivability design cues *must* come from the 'duct' layer), and in particular a key operator requirement here is that failures of the control-plane *must not* affect the user-plane. > ("Outage" includes route stability loss during convergence, > for conventional IP > routing. Ex.: Vern Paxsons 1996 paper on internet routing behavior.) NH=> Yes, but that is not the whole story. It is the fact that post-failure/re-convergence there is no reduction in the traffic offered, but rather a sharing of reduced network resource over the same traffic demand. It is this fact (coupled to the harder (to measure) initial outage event) that creates a real difficulty of separation of availability and QoS specification. Indeed, this looks quite problematical for VPNs *if* we do not have the ability to decouple VPN topological/resource survival (of LSPs) from basic forwarding treatment (of packet aggregates from multiple different VPNs). > MPLS will have separate, but commensurate outage behavior > (despite fast > reroute). NH=> True for LSPs based on an IGP, eg LDP. Not necessarily true for ER-LSPs based on RSVP or CR_LDP. And certainly not true for GMPLS when we consider SDH/OTN fabrics. > All of this feeds into the analysis of QoS at the IP layerand above. NH=> True....but I would put it a different way. A client layer network *inherits* the performance of *all* the server layers below it...and then adds its own performance impairments, which are only relevant to the client layer considered. This relationship recurses upwards. The inheritance is not linear in some cases, eg a us/ms error event in SDH can create several seconds of outage in some client layers.....the actual behaviour depends on the robustness of the client layer framing, and especially the server->client adaptation functions, eg if ATM was a client of SDH then one can create a loss of cell delineation event which can lead to a variable ATM layer outage depending on what OAM functions are active (and in some cases user traffic activity). > QoS is both an IP connection availability (reachability) > issue, as well as a > packet loss, delay etc. issue. > Up/down state transitions can generally cause both (a) > reachability loss, and > (b) data loss. > So, *given adequate measurement and characterization* of the > phenomena, > I don't see it as impossible. If this is naive, why? NH=> Yes you can measure both IP availability and QoS but you can do so only reliably/consistently at the end-points, ie the true source/sink of the IP 'connection' one is considering. We cannot partition that end-end IP 'connection' since any arbitrary partitions we create cannot be regarded as permanent, ie the routing can change post-failure (or indeed if new routes are injected in the IGP/BGP). This makes the definition of a global HRX with end-end metric/objectives apportioned (on some basis, eg proportional to length) amongst consitutent subnetwork partitions impossible....thus we cannot realistically relate network availability/QoS to individual customers on a subnetwork/partitioned basis. > > > > > 3 Now we can consider QoS.....but be careful. It > costs money to > > measure/collect/process (in OSS) these....every technology > I have been > > involved with has started with a large metric wish-list > that gets whittled > > down to something more pragmatic later. My advice is that > these should be > > of 2 types of QoS metric collection: (i) ad hoc 'sw-on' function for > > trouble-shooting as needed by operational people, or the continuous > > measurement of 'important' paths, and (ii) general network > population > > sampling (to get overall network trends and spot latent anomolous > > behaviour). > > Yes. The problem as I see it here is that many of the > measurement stds impose > invasive problems on the network. RMON and general polling > via SNMP are > examples. NH=> The overriding concern I have as an operator is the measurement cost/benefit ratio. I have seen (too many times) over-enthusiastic and unrealistic QoS measurement requirements stated (usually by those who do not have to pay for it!) *and* a lack of attention to what is really important to operators/customers, eg is it 'working'? can we detect/diagnose defects? can we clearly articulate/measure availability? > > > BTW - We (ie me/Shahram Davari/Ben Mack-Crane/Peter Willis) > have just posted NH=> I should have also added Hiroshi Ohta (NTT) to the authour list....sorry Hiroshi from missing you off initially. > > an ID for MPLS user-plane which deals with 1 and 2 above. > > I would be interested in a link to your draft. NH=> http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt Note that some of the more complex diagrams are missing in here....if you want to see these let me know off-list (to properly understand the flow charts of near/far-end defect processing of LSPs and how to distinguish a short-break from an unavailability event you may need them). I have also noted several typos that will need correcting when the ID gets up-issued. From owner-mpls@UU.NET Mon Mar 5 06:50:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11624 for ; Mon, 5 Mar 2001 06:50:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfal18306; Mon, 5 Mar 2001 11:48:06 GMT Received: by mail-control.mail.uu.net id QQkfal09232 for mpls-outgoing; Mon, 5 Mar 2001 11:47:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfal09227 for ; Mon, 5 Mar 2001 11:47:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfal29913 for ; Mon, 5 Mar 2001 11:46:56 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfal28518 for ; Mon, 5 Mar 2001 11:46:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA18860 for mpls@uu.net; Mon, 5 Mar 2001 06:46:54 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfal09081 for ; Mon, 5 Mar 2001 11:46:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfal06403 for ; Mon, 5 Mar 2001 11:45:46 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfal26690 for ; Mon, 5 Mar 2001 11:45:45 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11168; Mon, 5 Mar 2001 06:45:43 -0500 (EST) Message-Id: <200103051145.GAA11168@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-cr-ldp-05.txt Date: Mon, 05 Mar 2001 06:45:43 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Constraint-Based LSP Setup using LDP Author(s) : B. Jamoussi et al. Filename : draft-ietf-mpls-cr-ldp-05.txt Pages : 38 Date : 02-Mar-01 Label Distribution Protocol (LDP) is defined in [1] for distribution of labels inside one MPLS domain. One of the most important services that may be offered using MPLS in general and LDP in particular is support for constraint-based routing of traffic across the routed network. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. For instance, an LSP can be setup based on explicit route constraints, QoS constraints, and other constraints. Constraint-based routing (CR) is a mechanism used to meet Traffic Engineering requirements that have been proposed by [2], [3] and [4]. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CR-LSPs). Other uses for CR-LSPs include MPLS-based VPNs [5]. More information about the applicability of CR-LDP can be found in [6]. This draft specifies mechanisms and TLVs for support of CR-LSPs using LDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-05.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-cr-ldp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-cr-ldp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010302132229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-cr-ldp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-cr-ldp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302132229.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Mar 5 06:57:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11767 for ; Mon, 5 Mar 2001 06:57:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfal11652; Mon, 5 Mar 2001 11:56:36 GMT Received: by mail-control.mail.uu.net id QQkfal09806 for mpls-outgoing; Mon, 5 Mar 2001 11:56:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfal09769 for ; Mon, 5 Mar 2001 11:56:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfal20488 for ; Mon, 5 Mar 2001 11:55:44 GMT Received: from cad.zju.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQkfal11914 for ; Mon, 5 Mar 2001 11:55:42 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 346 for ; Mon, 5 Mar 2001 19:25:54 +0800 Message-ID: <3AA37780.1449A1E5@cad.zju.edu.cn> Date: Mon, 05 Mar 2001 19:24:48 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Loop detection in RFC3036 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thank you. But, why it states " Path Vectors are passed downstreams from ingress to egree and are not passwd upstream"? Is that only means the lable request LDP message ? > The loop detection depends on hop count, but hop count is not valid in > the presence of label merging. > > > On Fri, Mar 02, 2001 at 10:06:00PM +0800, shen jing wrote: > > if it has been asked before , execuse for my stupid question please. > > > > I'm reading rfc3036 to learn some basics of LSP building. > > > > while in 2.8.3 , it is said -- > > > > "Note that in a network where only non-merge capable LSRs are present, > > > > Path Vectors are passed downstream from ingress to egress, and are > > not passed upstream. Even when merge is supported, Path Vectors need > > > > not be passed upstream along an LSP which is known to reach the > > egress. When an LSR experiences a change of next hop, it need pass > > Path Vectors upstream only when it cannot tell from the hop count > > that the change of next hop does not result in a loop. " > > > > As it said MPLS just support downstream determined lable distribution, > > as I think > > it means any LDP packet should be first transmitted from downstream to > > upstream. why here states " Path Vectors are passed downstreams from > > ingress to egree and are not passwd upstream" ? why is it related to > > label merge ? > > > > James shen > > From owner-mpls@UU.NET Mon Mar 5 09:01:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14876 for ; Mon, 5 Mar 2001 09:01:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfau14171; Mon, 5 Mar 2001 14:00:30 GMT Received: by mail-control.mail.uu.net id QQkfat18327 for mpls-outgoing; Mon, 5 Mar 2001 13:59:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfat18314 for ; Mon, 5 Mar 2001 13:59:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfat21018 for ; Mon, 5 Mar 2001 13:58:56 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkfat08819 for ; Mon, 5 Mar 2001 13:58:56 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 FAA15581 for ; Mon, 5 Mar 2001 05:59:13 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA16245 for mpls@uu.net; Mon, 5 Mar 2001 08:58:54 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkerq11431 for ; Sat, 3 Mar 2001 02:36:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkerq26472 for ; Sat, 3 Mar 2001 02:36:05 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f122.law14.hotmail.com [64.4.21.122]) id QQkerq00602 for ; Sat, 3 Mar 2001 02:36:05 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Mar 2001 18:36:04 -0800 Received: from 38.204.3.195 by lw14fd.law14.hotmail.msn.com with HTTP; Sat, 03 Mar 2001 02:36:04 GMT X-Originating-IP: [38.204.3.195] From: "!! !!" To: mpls@UU.NET Subject: questions on GMPLS-00.txt and ldp-ouni drafts Date: Sat, 03 Mar 2001 02:36:04 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Mar 2001 02:36:04.0485 (UTC) FILETIME=[B17B8350:01C0A38A] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Pls. help me with the following: There was some discussion on the mailing list to include the signal type field in the generalized label request TLV. Has any decision been taken yet? (GMPLS functional specifications.) Besides this, I have one doubt. The paragraph below from LDP Optical UNI draft, doesn't specify clearly what all parameters from the Label Request msg. received over UNI would be used in framing the GMPLS Label Request when received by the edge optical node. How about Destination Id TLV and Source Id TLV? ..... After passing the edge optical network verification process, the edge optical network constructs the generalized MPLS message for lightpath aetup across the optical network. The generalized Label Request Message extracts information from the O-UNI Label Request Message with regard to the Generalized Label Request TLV, the Suggested Label TLV, and the Label Set TLV, whenever applicable. The methods and procedures described in [4] are then followed for end-to-end path setup. ..... Pls. clarify. Pls. correct me if something has been overlooked. Thanks. raju _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Mar 5 09:04:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15048 for ; Mon, 5 Mar 2001 09:04:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfau15350; Mon, 5 Mar 2001 14:02:49 GMT Received: by mail-control.mail.uu.net id QQkfau26251 for mpls-outgoing; Mon, 5 Mar 2001 14:02:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfau26145 for ; Mon, 5 Mar 2001 14:02:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfau18251 for ; Mon, 5 Mar 2001 14:01:51 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfau16347 for ; Mon, 5 Mar 2001 14:01: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 GAA06350 for ; Mon, 5 Mar 2001 06:02:07 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA16265 for mpls@uu.net; Mon, 5 Mar 2001 09:01:48 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkeug02829 for ; Sat, 3 Mar 2001 19:43:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkeug08403; Sat, 3 Mar 2001 19:42:46 GMT Received: from pluto.ipass.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluto.ipass.net [198.79.53.5]) id QQkeug19984; Sat, 3 Mar 2001 19:42:46 GMT Received: from ieee.org (adsl-80-203-217.rdu.bellsouth.net [65.80.203.217]) by pluto.ipass.net (8.9.3/8.9.3) with ESMTP id OAA02738; Sat, 3 Mar 2001 14:42:28 -0500 (EST) Message-ID: <3AA145C2.511CC497@ieee.org> Date: Sat, 03 Mar 2001 14:28:02 -0500 From: "Richard W. Tibbs" Reply-To: rtibbs@ieee.org X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: sambu.mantha@usa.alcatel.com, tmartin@gvnw.com, bwijnen@lucent.com, ellanti@home.com, akyol@pluris.com, vishal@JasmineNetworks.com, te-wg@UU.NET, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Standards for IP stats collection? (corrected) References: Content-Type: multipart/mixed; boundary="------------B61D069BAF8B007E254C294F" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------B61D069BAF8B007E254C294F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Neil -- your comments on inter-relation between failure modes and QOS are very on target. You are right that the issues are a pandora's box, but I don't find the availability analysis of the IP layer quite as hopeless. I have a few comments below. I would appreciate anyone's responses as to the "hopelessness index" of this problem. neil.2.harrison@bt.com wrote: > Bert....I can understand your earlier comment (wrt wanting limiting WG > coverage), but I can probably understand why Vishal wrote to several lists: > - IP need its own perf management regime > - MPLS ditto > - GMPLS ditto....and there can be several layer networks involved > here, eg SDH (which has several distinct internal layer networks) and OTN. > > This is unavoidable as each of the above create layer networks that must be > managed in their own right. And to do a proper job its not simply QoS Perf > stats that are at issue for operators, its more like this: > > 1 user-plane and control-plane need their own OAM once dealing with CO > paths, eg GMPLS/MPLS-ER-LSPs, since one cannot assume user/control-plane > congruence of function or routing....so they are independent. In the > user-plane one must have an initial clear view of defects (entry/exit > criteria) and their handling (ie correct consequent actions). For an > operator this is an operational must-have. > > 2 After above, the next issue is availability. This has to be defined > before QoS metrics/objectives can be considered. Why? QoS metrics are only > valid when a path is in the up-state, otherwise the QoS metrics have no > viable time-base and/or can get (statistically) distorted by events which > should be regarded as down-time ....so up/down-state transitions need to be > clearly identified next. Note - this issue is not clear-cut for the IP > layer when dealing with destination-based hop-hop routing. Indeed, there > are very difficult issues with failures mutating into QoS hits which I have > raised on the MPLS list before which make availability analysis of the IP > layer impossible (IMO) for the *network* (ie as subnetwork partitioned > allocations of a global reference connection) except on a true end-end > basis. I think (but am not quite sure from your wording) that you find the goal of separating failure analysis at the physical/link layers from availabiltiy & QoS at the IP layer unattainable. My view is that these functions of network state are inter-related and to seek to make them independent is quixotic. Here is a view: The various layers below IP will have outage phenomena. These are measurable, albeit imperfectly. Both control-plane and data-plane will have outage phenomena. These are measurable, I think. ("Outage" includes route stability loss during convergence, for conventional IP routing. Ex.: Vern Paxsons 1996 paper on internet routing behavior.) MPLS will have separate, but commensurate outage behavior (despite fast reroute). All of this feeds into the analysis of QoS at the IP layerand above. QoS is both an IP connection availability (reachability) issue, as well as a packet loss, delay etc. issue. Up/down state transitions can generally cause both (a) reachability loss, and (b) data loss. So, *given adequate measurement and characterization* of the phenomena, I don't see it as impossible. If this is naive, why? > > > 3 Now we can consider QoS.....but be careful. It costs money to > measure/collect/process (in OSS) these....every technology I have been > involved with has started with a large metric wish-list that gets whittled > down to something more pragmatic later. My advice is that these should be > of 2 types of QoS metric collection: (i) ad hoc 'sw-on' function for > trouble-shooting as needed by operational people, or the continuous > measurement of 'important' paths, and (ii) general network population > sampling (to get overall network trends and spot latent anomolous > behaviour). Yes. The problem as I see it here is that many of the measurement stds impose invasive problems on the network. RMON and general polling via SNMP are examples. > > > 4 policing/re-classification actions need monitoring. > > 5 nodal/link utilisations need monitoring and fed to a TE function and > the design/forecasting cycle. > > So one needs a framework, where these pieces relate but where one piece does > not attempt to the job of all the others. > > BTW - We (ie me/Shahram Davari/Ben Mack-Crane/Peter Willis) have just posted > an ID for MPLS user-plane which deals with 1 and 2 above. I would be interested in a link to your draft. > > > neil > > > -----Original Message----- > > From: Sambasiva R. Mantha [mailto:sambu.mantha@usa.alcatel.com] > > Sent: 02 March 2001 20:50 > > To: terry martin > > Cc: ellanti@home.com; Bora Akyol; Vishal Sharma; 'te-wg@uu.net'; > > 'mpls@uu.net'; ccamp@ops.ietf.org > > Subject: Re: Standards for IP stats collection? (corrected) > > > > > > I would like to correct a little bit regarding GR-253. The > > GR-253 requires 8 > > hours of 15-minute registers and 7 one-day registers and not > > 3-5 days. This > > means that a SONET must have 33 15-minute registers (32 > > registers for previous 8 > > hours and 1 for current 15 minutes) and 7 1-day (previous > > day) registers. > > I would agree with Manohar that these PM registers are an > > over-kill for LSPs as > > they really donot contribute anything to the traffic flowing > > through the NE. > > > > Sambu > > > > > > terry martin wrote: > > > > > RMON is the only protocol standard that dictates > > information collection > > > requirements. That is the only IP service that is > > structured to collect > > > trend stats. I think it is also 15 minute intervals for > > 3-5 days depending > > > on how much memory you get in the unit. > > > > > > There are structure requirements for collection, type of > > traffic collected > > > and how it is presented. > > > > > > Need sources- let me know > > > > > > Terry Martin MS Telecommunication Engineering > > > Senior Consultant > > > tmartin@gvnw.com > > > 503-612-4422 > > > > > > ----- Original Message ----- > > > From: "Manohar Naidu Ellanti" > > > To: "Bora Akyol" ; "Vishal Sharma" > > > > > > Cc: "'te-wg@uu.net'" ; "'mpls@uu.net'" ; > > > > > > Sent: Thursday, March 01, 2001 9:14 PM > > > Subject: RE: Standards for IP stats collection? (corrected) > > > > > > > It will be interesting to see if there is a need for TDM > > world operational > > > > features to be carried into MPLS world. > > > > > > > > I think the reason for 15 minutes etc PM counters for > > things like Severely > > > > Errored Seconds etc was to deduce the quality of > > transmission line and use > > > > this to feed into link cost. For instance realiability > > metric could be > > > based > > > > on such information for the link. > > > > > > > > For LSPs does it really make sense ? to have TDM world operational > > > features. > > > > There is not even CRC or any header information to > > determine if MPLS > > > packet > > > > was received correctly. It is more at lower layers. It > > would be nice to > > > see > > > > some useful features carried forward and avoid > > unnecessary requirements > > > from > > > > GR-XXX. > > > > > > > > -Manohar > > > > > > > > > > > > -----Original Message----- > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On > > Behalf Of Bora > > > > Akyol > > > > Sent: Thursday, March 01, 2001 8:57 PM > > > > To: Vishal Sharma > > > > Cc: 'te-wg@uu.net'; 'mpls@uu.net'; 'ccamp@ops.ietf.org' > > > > Subject: Re: Standards for IP stats collection? (corrected) > > > > > > > > > > > > Vishal > > > > > > > > I don't think that there are such standards for routers. > > I know that some > > > > routers store such data on flash cards for later > > retrieval and some on > > > > hard disks. > > > > > > > > I would be curious to see how people are storing this > > data and for how > > > > long? > > > > > > > > Bora > > > > > > > > > > > > On Thu, 1 Mar 2001, Vishal Sharma wrote: > > > > > > > > > Hello All, > > > > > > > > > > For the TDM world, GR-253 lays out strict standards for > > > > > the length of time that a carrier-class box should collect > > > > > and store statistics on-board, for retrieval later. The > > > > > number is something like 15-min intervals for 3 days. > > > > > The purpose supposedly is that if the connection to the EMS > > > > > dies, the box at least should allow the provider to recover > > > > > statistics data from it. > > > > > > > > > > My question is: what are similar standards (or existing > > > > > best practices) in the IP carrier community today? How much > > > > > statistics-related information do carriers like to have from > > > > > IP boxes? > > > > > What would carriers like to have? > > > > > > > > > > (The only reference I could find on this was Blain Christian's > > > > > draft > > > > > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-christian-tewg-me > asurement-00.t > > > > xt) > > > > > > > > Are there others? > > > > Do people (read carriers) have any thoughts or suggestions or > > > > pointers? > > > > > > > > Thanks, > > > > > > > > -Vishal > > > > > > > > > > -- http://www.makesystems.com --------------B61D069BAF8B007E254C294F Content-Type: text/x-vcard; charset=us-ascii; name="rtibbs.vcf" Content-Description: Card for Richard W. Tibbs Content-Disposition: attachment; filename="rtibbs.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Tibbs;Richard tel;cell:919.412.4129 tel;home:919.787.4387 tel;work:919.412.4129 x-mozilla-html:FALSE version:2.1 email;internet:rtibbs@ieee.org adr;quoted-printable:;;3408 Cherry Lane=0D=0A;Raleigh;NC;27607; fn:Dr. Richard Tibbs end:vcard --------------B61D069BAF8B007E254C294F-- From owner-mpls@UU.NET Mon Mar 5 09:06:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15130 for ; Mon, 5 Mar 2001 09:06:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfau18537; Mon, 5 Mar 2001 14:04:32 GMT Received: by mail-control.mail.uu.net id QQkfau00789 for mpls-outgoing; Mon, 5 Mar 2001 14:04:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfau00010 for ; Mon, 5 Mar 2001 14:03:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfau08103 for ; Mon, 5 Mar 2001 14:03:28 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkfau16731 for ; Mon, 5 Mar 2001 14:03:28 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA18605 for ; Mon, 5 Mar 2001 06:03:45 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA16283 for mpls@uu.net; Mon, 5 Mar 2001 09:03:26 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfaa28473 for ; Mon, 5 Mar 2001 09:13:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfaa00794; Mon, 5 Mar 2001 09:13:03 GMT Received: from plinius.intec2.rug.ac.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: plinius.intec2.rug.ac.be [157.193.122.4]) id QQkfaa03975; Mon, 5 Mar 2001 09:13:03 GMT Received: from intec.rug.ac.be (daisne.intec2.rug.ac.be [157.193.122.92]) by plinius.intec2.rug.ac.be (Postfix) with ESMTP id 00336EEAB; Mon, 5 Mar 2001 10:12:26 +0100 (CET) Message-ID: <3AA3587A.EF29CAC6@intec.rug.ac.be> Date: Mon, 05 Mar 2001 10:12:27 +0100 From: Steven Van den Berghe X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Vishal Sharma Cc: "'te-wg@uu.net'" , "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: Re: Standards for IP stats collection? (corrected) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, As far as i know, there is currently no effort for bringing together the work being done by various MIB-authors (including the on the list discussed RMON) and the work done for active measurements by the IPPM-WG, into general requirements or an architecture for performing measurements for any higher purpose (including traffic engineering). I've tried to initiate some activity on this with http://search.ietf.org/internet-drafts/draft-svdberg-temon-00.txt (unfortunately the server contains a version with quite some errors, so i've attached the corrected one to this mail). Although sub-IP area enhancements will bring quite some additional input for the measurement issue, i've limited myself to IP-level. My feeling is, that this might be a starting point for some general measurement architecture and hooks should be provided to enable extensions using lower-level information. Furthermore, the IPPM-WG is highly interested in the metrics and measurements as they are required by other WG, so they might also be interested in this discussion. Best regards, Steven Vishal Sharma wrote: > Hello All, > > For the TDM world, GR-253 lays out strict standards for > the length of time that a carrier-class box should collect > and store statistics on-board, for retrieval later. The > number is something like 15-min intervals for 3 days. > The purpose supposedly is that if the connection to the EMS > dies, the box at least should allow the provider to recover > statistics data from it. > > My question is: what are similar standards (or existing > best practices) in the IP carrier community today? How much > statistics-related information do carriers like to have from > IP boxes? > What would carriers like to have? > > (The only reference I could find on this was Blain Christian's > draft > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t > xt) > > Are there others? > Do people (read carriers) have any thoughts or suggestions or > pointers? > > Thanks, > > -Vishal -- Steven Van den Berghe steven.vandenberghe@intec.rug.ac.be Workgroup Broadband-Networks Department Information Technology Ghent University - Belgium Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* I feel like a genocidal maniac when emacs asks me if I want to kill 10789 characters. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-mpls@UU.NET Mon Mar 5 09:07:06 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15152 for ; Mon, 5 Mar 2001 09:07:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfau04934; Mon, 5 Mar 2001 14:05:27 GMT Received: by mail-control.mail.uu.net id QQkfau03112 for mpls-outgoing; Mon, 5 Mar 2001 14:05:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfau02905 for ; Mon, 5 Mar 2001 14:04:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfau24025 for ; Mon, 5 Mar 2001 14:03:09 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkfau16055 for ; Mon, 5 Mar 2001 14:03:09 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 GAA18399 for ; Mon, 5 Mar 2001 06:03:26 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA16279 for mpls@uu.net; Mon, 5 Mar 2001 09:03:07 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkexw02735 for ; Sun, 4 Mar 2001 19:08:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkexw05538 for ; Sun, 4 Mar 2001 19:07:58 GMT From: ahussain@eng.utoledo.edu Received: from strange.eng.utoledo.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: strange.eng.utoledo.edu [131.183.18.8]) id QQkexw03275 for ; Sun, 4 Mar 2001 19:07:58 GMT Received: from ni101304.pop3.eng.utoledo.edu (NI101304.ni.utoledo.edu [131.183.16.172]) by strange.eng.utoledo.edu (8.9.3/8.9.3/1.1) with ESMTP id OAA25563; Sun, 4 Mar 2001 14:06:59 -0500 (EST) Message-Id: <5.0.2.1.0.20010304140634.00a88050@pop3.eng.utoledo.edu> X-Sender: ahussain@pop3.eng.utoledo.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 04 Mar 2001 14:06:59 -0500 To: ahussain@eng.utoledo.edu Subject: Fwd: MPLS simulator Cc: jlawrenc@cisco.com, mpls@UU.NET, kishore@ind.alcatel.com, Pramoda.Nallur@ind.alcatel.com, Manu.Prakash@ind.alcatel.com, Pramoda.Nallur@ind.alcatel.com, jzou@mars.iol.unh.edu, Dilip.Pandit@ind.alcatel.com, Jahaapanah@netscape.net, ayyangar@apollo.mctr.umbc.edu, SJONES@iirltd.co.uk, jplang@calient.net, pms_tech@yahoo.com, cvkrao@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Date: Sun, 04 Mar 2001 13:54:36 -0500 >To: SJONES@iirltd.co.uk >From: ahussain@pop3.eng.utoledo.edu >Subject: MPLS simulator >Cc: ahussain > > >>Date: Sun, 04 Mar 2001 13:53:15 -0500 >>To: jleu@laurelnetworks.com >>From: ahussain@pop3.eng.utoledo.edu >>Subject: MPLS simulator >> >>Hi, >> I am new to the MPLS world. I will be doing my MS project in MPLS. >> Since you have profound knowledge about it, i would like u to help me out. >> Please let me know if an MPLS simulator is available. If u have one >> please mail it to me. >> >>Please give me comments on the following: >> "Modifying a code the simulates an IP switch into one that simulates MPLS" >> >>Regards, >> Abrar. From owner-mpls@UU.NET Mon Mar 5 09:16:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15416 for ; Mon, 5 Mar 2001 09:16:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfav24484; Mon, 5 Mar 2001 14:15:38 GMT Received: by mail-control.mail.uu.net id QQkfav05110 for mpls-outgoing; Mon, 5 Mar 2001 14:15:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfav05103 for ; Mon, 5 Mar 2001 14:15:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfau22983 for ; Mon, 5 Mar 2001 14:10:24 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkfau14868 for ; Mon, 5 Mar 2001 14:10:23 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA00169 for ; Mon, 5 Mar 2001 09:10:22 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA00151; Mon, 5 Mar 2001 09:10:21 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA18608; Mon, 5 Mar 2001 09:10:20 -0500 (EST) Message-ID: <3AA39E4D.2D87665D@lucent.com> Date: Mon, 05 Mar 2001 09:10:21 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: mpls@UU.NET Subject: Re: Expanded ERO draft References: <200103021926.LAA16080@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, > > We've added Router ID to the unnumbered ERO subobject (see version 01, > just shipped to the IETF). Does this cover it? Fine for conventional MPLS. But still not enough for circuit switched networks, for example, optical network. > > So, about EERO, the remaining questions are: > 1) Why have router IDs for numbered subobjects? > 2) Why have ingress and egress ids *all* the time? For the one > case of multiple multiaccess interfaces on a common subnet, > use two ERO subobjects. > > If you agree that the above two are not needed, we don't need a new > EERO object. Sure. Yangguang From owner-mpls@UU.NET Mon Mar 5 09:17:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15488 for ; Mon, 5 Mar 2001 09:17:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfav09717; Mon, 5 Mar 2001 14:16:49 GMT Received: by mail-control.mail.uu.net id QQkfav05310 for mpls-outgoing; Mon, 5 Mar 2001 14:16:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfav05250 for ; Mon, 5 Mar 2001 14:16:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfau16300 for ; Mon, 5 Mar 2001 14:13:49 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfau20973 for ; Mon, 5 Mar 2001 14:13:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA03119 for mpls@uu.net; Mon, 5 Mar 2001 09:13:48 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfau04807 for ; Mon, 5 Mar 2001 14:13:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfau12210 for ; Mon, 5 Mar 2001 14:11:55 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkfau17412 for ; Mon, 5 Mar 2001 14:11:51 GMT Received: from flefauch-8kcdt.cisco.com (dhcp-nic-val-26-100.cisco.com [64.103.26.100]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA28348; Mon, 5 Mar 2001 15:10:23 +0100 (MET) Message-Id: <200103051410.PAA28348@cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 05 Mar 2001 15:07:47 +0100 To: awduche@movaz.com, lberger@movaz.com, dhg@juniper.net, tonyl@home.net, vsriniva@cosine.com, swallow@cisco.com From: Francois Le Faucheur Subject: Status of COS Service in rsvp-lsp-tunnel-08.txt Cc: mpls@UU.NET, bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram64@lucent.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi, david.charlap@marconi.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello, This is a request for clarification regarding the use of the "Class of Service" service in rsvp-lsp-tunnel-08.txt. The motivation is to ensure that "diff-ext-xx.txt" is consistent with "rsvp-lsp-tunnel-yy.txt". As pointed out by David below, section 4.8 on COS Tspec and Flowspec (which existed in rsvp-lsp-tunnel-07.txt) has been removed in rsvp-lsp-tunnel-08.txt. However, the "COS service" is still mentioned in the text (both section 2.3 and section 2.6 still refer to the removed section 4.8). For instance: " Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-08.txt February 2001 2.3. Service Classes This document does not restrict the type of Integrated Service requests for reservations. However, an implementation SHOULD support the Controlled-Load service [4] and the Class-of-Service service, see Section 4.8. " Can you clarify what is the intended status re COS service: - was section 4.8 inadvertently removed? - was section 4.8 deliberately removed? Then: - what is the method to signal LSPs without bandwidth reservations? - is there some text that I missed clarifying this? - should section 2.3 and section 2.6 then not be modified to remove reference to 4.8? - am I looking at a version which is out-of-date? BTW, the intent of diff-ext is simply to align with whatever is specified in rsvp-lsp regarding signaling for LSP without reservations. The reason we need to discuss it in diff-ext is that we need to clarify the relationship of bandwidth reservations with the new "Diff-Serv" object. Apologies if this has already been discussed on the alias. thanks for pointing me to the relevant thread then. Thanks Francois >Date: Fri, 02 Mar 2001 19:00:02 -0500 >From: David Charlap >X-Mailer: Mozilla 4.76 [en] (WinNT; U) >X-Accept-Language: en-US,en-GB,en >To: mpls@UU.NET >Subject: Re: WG Last call >Sender: owner-mpls@UU.NET > >------------ > >The second problem involves the use of this draft in conjunction with >the latest changes to RSVP-TE (version -08). Version -08 eleimates the >COS service type from the TSPEC and FLOWSPEC objects. > >The DS draft requires that COS-type objects be used in order to signal >an L-LSP without bandwidth reservations. With the current revisions of >these two drafts, this type of LSP can not be signalled at all. It >effectively makes it impossible to use RSVP-TE to signal a best-effort >LSP (either E-LSP or L-LSP) > >Either the COS-type TSpec must be put back in RSVP-TE, or the DS draft >must be updated to provide a means for singalling a best-effort LSP. > >------------- _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Mon Mar 5 09:25:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15627 for ; Mon, 5 Mar 2001 09:25:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfav12573; Mon, 5 Mar 2001 14:24:35 GMT Received: by mail-control.mail.uu.net id QQkfav05891 for mpls-outgoing; Mon, 5 Mar 2001 14:24:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfav05873 for ; Mon, 5 Mar 2001 14:24:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfav17076 for ; Mon, 5 Mar 2001 14:19:18 GMT Received: from cad.zju.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cad.zju.edu.cn [210.32.131.2]) id QQkfav14645 for ; Mon, 5 Mar 2001 14:19:15 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 259; Mon, 5 Mar 2001 21:56:41 +0800 Message-ID: <3AA39ADC.C132D6CA@cad.zju.edu.cn> Date: Mon, 05 Mar 2001 21:55:40 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Wenjing Chu CC: djiang1@lucent.com, mpls@UU.NET Subject: Re:MPLS over native ATM and some other ideas References: <36EF020032CFD411B7B400508B55E5901663D3@milan.turinnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thank you much for your help. But, would you please give a little more help? (execuse for my tedious explanation on my work below ) As I know, MPOA or LANE can be used to transmit IP traffic over ATM network. But, I think they all derives much overhead, MPLS is a protocol which can be used to give IP network the ability to simulate those happened in circuit switch network, esp. QoS. I do want to do some research on QoS enabled multimedia (graphics and video) transmission over a pure IP network, but only linux boxes, a Cabletron ATM switch and serval Ethernet hub/switch are available. As I think MPLS is a very good technique which will possibly be one of key technique for future network, I planned a MPLS enabled experiment system for QoS enabled multimedia transmission(shown as follows ) Linux Server ----- Linux Router ---------Linux Router -----Linux Client ^ ^ ^ | | | Ethernet ATM Ethernet I want to use RSVP as end-to-end QoS signaling procotol, while MPLS enabled network provides transmission service to multimedia streams ( including Linux Server,Linux Client and linux router). Point-to-point, multicast and multipoint-to-point QoS service to video stream is the target to be realized. I think this model covers the current state of Internet (ATM backbone is now a widely used link layer technique, while IP dominate the network layer). To enable QoS and TE support, upgrading ATM switch software to enable MPLS control plane is not always the best solution to ISPs( I'm not sure). I think there should be two other possible ways to deal with it. The first is a overlayed model, such as IP/MPLS/ATM , by mapping LDP/RSVP to PNNI and encapsulating MPLS packet by AAL5 we can easily upgrade nowaday's system. The second method is RSVP-- DiffServ--ATM (or MPLS), in which user application signal edge router by using RSVP, and RSVP message is tunnelled through DiffServ network to its destination. In core network DiffServ is mapped to native ATM or MPLS service. I planned to try the first way when I posted the first message. But now I'm not sure wether I'm in a right way , am I in the wrong direction? Would you please do me a little more favor on giving some advice ? Thank you very much and long for your help. Jing Shen Email: jshen@cad.zju.edu.cn > What for? > What you are trying to do seems so unnecessary? If you have ATM, IP/ATM will > do. But the whole purpose of implementing MPLS (well, part of) is to avoid > ATM. In your case however, MPLS is not used for much purpose. > > Wenjing > > -----Original Message----- > From: shen jing [mailto:jshen@cad.zju.edu.cn] > Sent: Tuesday, February 27, 2001 7:18 PM > To: Guang Xiaoming; mpls@UU.NET > Subject: Question on MPLS over native ATM > > Hi : > > I met some problem with my work, would you please give me some hints? > > I'm thinking about connect IP host through ATM by using MPLS, which > provide both fast transmission and QoS support to multimedia streams. > > I can not modify the control plane software installed in > ATM switch, so I have to use MPLS on end host while native ATM > in that switch. Is there any possiblity to integrate MPLS and ATM > in a layered model ? > > IP --- MPLS -- ATM---------ATM --- MPLS--IP > ^ > ^ ^ > | > | | > MPLS over Native MPLS over > ATM ATM ATM > > Is there any draft on this topic ? or any person has implement > a solution? > > Thanks a lot. > > Shen From owner-mpls@UU.NET Mon Mar 5 09:31:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15765 for ; Mon, 5 Mar 2001 09:31:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfaw24546; Mon, 5 Mar 2001 14:30:26 GMT Received: by mail-control.mail.uu.net id QQkfav06297 for mpls-outgoing; Mon, 5 Mar 2001 14:29:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfav06290 for ; Mon, 5 Mar 2001 14:29:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfav17930 for ; Mon, 5 Mar 2001 14:28:45 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkfav21054 for ; Mon, 5 Mar 2001 14:28:45 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 JAA11930 for ; Mon, 5 Mar 2001 09:28:44 -0500 (EST) 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 JAA11918; Mon, 5 Mar 2001 09:28:44 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA21404; Mon, 5 Mar 2001 09:28:42 -0500 (EST) Message-ID: <3AA3A29B.A59316CD@lucent.com> Date: Mon, 05 Mar 2001 09:28:43 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com Subject: FYI: Three GMPLS related IDs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, FYI, three GMPLS related IDs have been submitted. Architecture: http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-00.txt Signaling: http://www.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-request-01.txt http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-reorg-00.txt Comments are welcomed. Thanks, Yangguang From owner-mpls@UU.NET Mon Mar 5 10:10:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17451 for ; Mon, 5 Mar 2001 10:10:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfay07226; Mon, 5 Mar 2001 15:09:36 GMT Received: by mail-control.mail.uu.net id QQkfay23907 for mpls-outgoing; Mon, 5 Mar 2001 15:08:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfay23628 for ; Mon, 5 Mar 2001 15:08:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfay16659; Mon, 5 Mar 2001 15:08:25 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkfay05091; Mon, 5 Mar 2001 15:08:24 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f25F8N005272; Mon, 5 Mar 2001 16:08:23 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A06.0052E4D0; Mon, 5 Mar 2001 16:05:25 +0100 Message-ID: <3AA3AB34.C8E4B51B@alcatel.be> Date: Mon, 05 Mar 2001 16:05:24 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: te-wg@UU.NET, mpls@UU.NET Subject: new draft on multicast traffic engineering with mpls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit FYI http://search.ietf.org/internet-drafts/draft-ooms-mpls-multicast-te-00.txt Abstract There are several reasons for operators to construct multicast trees by another means than multicast routing protocols. This document lists these reasons and describes 2 ways of building a multicast traffic-engineered tree: root-initiated tree and leaf-initiated tree. Finally it defines extensions to CR-LDP to support MPLS multicast traffic engineering. -- Dirk Ooms mailto:dirk.ooms@alcatel.be tel:+32 3 2404732 Network Strategy Group (NSG) http://aww.alcatel.com/nsg Alcatel http://www.alcatel.com From owner-mpls@UU.NET Mon Mar 5 10:14:19 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17691 for ; Mon, 5 Mar 2001 10:14:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfay16435; Mon, 5 Mar 2001 15:11:59 GMT Received: by mail-control.mail.uu.net id QQkfay24469 for mpls-outgoing; Mon, 5 Mar 2001 15:11:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfay24423 for ; Mon, 5 Mar 2001 15:11:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfay28812 for ; Mon, 5 Mar 2001 15:11:03 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfay00447 for ; Mon, 5 Mar 2001 15:11:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA10391 for mpls@uu.net; Mon, 5 Mar 2001 10:11:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfay24233 for ; Mon, 5 Mar 2001 15:10:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfay13065 for ; Mon, 5 Mar 2001 15:09:49 GMT Received: from ims002.dcat.ops.broadbandoffice.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: external00.dca55.ops.bbo.com [64.47.146.7]) id QQkfay07316 for ; Mon, 5 Mar 2001 15:09:38 GMT Received: from nfloat.movaz.com (63.222.119.178 [63.222.119.178]) by ims002.dcat.ops.broadbandoffice.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFP1GBTY; Mon, 5 Mar 2001 10:09:35 -0500 Message-Id: <4.3.2.7.2.20010305091506.00c0fad0@mo-ex> X-Sender: lou@mo-ex X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Mar 2001 10:09:22 -0500 To: Francois Le Faucheur X-Sybari-Space: 00000000 00000000 00000000 From: Lou Berger Subject: Re: Status of COS Service in rsvp-lsp-tunnel-08.txt Cc: awduche@movaz.com, lberger@movaz.com, dhg@juniper.net, tonyl@home.net, vsriniva@cosine.com, swallow@cisco.com, mpls@UU.NET, bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram64@lucent.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi, david.charlap@marconi.com In-Reply-To: <200103051410.PAA28348@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Francois, David, Here's my (limited) understanding of the issue. A while back two separate ways of specifying BE/CoS service made it into drafts. One of which was the CoS object in the rsvp-lsp draft. The other, while I think came later in time, made it through the IETF process first and has been standardized in RFCs2997 and 2996. This result was that the CoS object served the same purpose of an existing standards track RFC. Having two ways to signal the same thing really doesn't make sense, and since they got there first, we loose. While the decision is painful now, I think it's better than the alternative. Having some more words on this in draft certainly makes sense. (Eric G. made this point privately.) This is just my opinion and perspective... Lou At 09:07 AM 3/5/01, Francois Le Faucheur wrote: >Hello, > >This is a request for clarification regarding the use of the "Class of >Service" service in rsvp-lsp-tunnel-08.txt. >The motivation is to ensure that "diff-ext-xx.txt" is consistent with >"rsvp-lsp-tunnel-yy.txt". > >As pointed out by David below, section 4.8 on COS Tspec and Flowspec (which >existed in rsvp-lsp-tunnel-07.txt) has been removed in >rsvp-lsp-tunnel-08.txt. However, the "COS service" is still mentioned in >the text (both section 2.3 and section 2.6 still refer to the removed >section 4.8). For instance: > >" >Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-08.txt February 2001 > >2.3. Service Classes > > This document does not restrict the type of Integrated Service > requests for reservations. However, an implementation SHOULD support > the Controlled-Load service [4] and the Class-of-Service service, see > Section 4.8. >" > >Can you clarify what is the intended status re COS service: > - was section 4.8 inadvertently removed? > - was section 4.8 deliberately removed? Then: > - what is the method to signal LSPs without bandwidth > reservations? > - is there some text that I missed clarifying this? > - should section 2.3 and section 2.6 then not be modified > to remove >reference to 4.8? > - am I looking at a version which is out-of-date? > > >BTW, the intent of diff-ext is simply to align with whatever is specified >in rsvp-lsp regarding signaling for LSP without reservations. The reason we >need to discuss it in diff-ext is that we need to clarify the relationship >of bandwidth reservations with the new "Diff-Serv" object. > >Apologies if this has already been discussed on the alias. thanks for >pointing me to the relevant thread then. > >Thanks > >Francois > > >Date: Fri, 02 Mar 2001 19:00:02 -0500 > >From: David Charlap > >X-Mailer: Mozilla 4.76 [en] (WinNT; U) > >X-Accept-Language: en-US,en-GB,en > >To: mpls@UU.NET > >Subject: Re: WG Last call > >Sender: owner-mpls@UU.NET > > > > >------------ > > > >The second problem involves the use of this draft in conjunction with > >the latest changes to RSVP-TE (version -08). Version -08 eleimates the > >COS service type from the TSPEC and FLOWSPEC objects. > > > >The DS draft requires that COS-type objects be used in order to signal > >an L-LSP without bandwidth reservations. With the current revisions of > >these two drafts, this type of LSP can not be signalled at all. It > >effectively makes it impossible to use RSVP-TE to signal a best-effort > >LSP (either E-LSP or L-LSP) > > > >Either the COS-type TSpec must be put back in RSVP-TE, or the DS draft > >must be updated to provide a means for singalling a best-effort LSP. > > > >------------- > > >_________________________________________________________________ >Francois Le Faucheur >Development Engineer, IOS Layer 3 Services >Cisco Systems >Office Phone: +33 4 92 96 75 64 >Home Office Phone: +33 4 92 94 00 78 >Mobile : +33 6 89 108 159 >Vmail: +33 1 58 04 62 66 >Fax: +33 4 92 96 79 08 >Email: flefauch@cisco.com >_________________________________________________________________ >Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France >_________________________________________________________________ From owner-mpls@UU.NET Mon Mar 5 10:23:45 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18035 for ; Mon, 5 Mar 2001 10:23:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfaz29498; Mon, 5 Mar 2001 15:22:44 GMT Received: by mail-control.mail.uu.net id QQkfaz26306 for mpls-outgoing; Mon, 5 Mar 2001 15:22:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfaz26263 for ; Mon, 5 Mar 2001 15:22:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfaz11079 for ; Mon, 5 Mar 2001 15:22:18 GMT Received: from x86unx3.comp.nus.edu.sg by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: x86unx3.comp.nus.edu.sg [137.132.90.2]) id QQkfaz06849 for ; Mon, 5 Mar 2001 15:22:17 GMT Received: from decunx.comp.nus.edu.sg (kaleelaz@decunx-m.comp.nus.edu.sg [137.132.90.9]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with ESMTP id WAA12890; Mon, 5 Mar 2001 22:29:37 +0800 (GMT-8) Received: from localhost (kaleelaz@localhost) by decunx.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id WAA28225; Mon, 5 Mar 2001 22:29:35 +0800 (SST) Date: Mon, 5 Mar 2001 22:29:35 +0800 (SST) From: Kaleelazhicathu R R Kumar To: ahussain@eng.utoledo.edu cc: jlawrenc@cisco.com, mpls@UU.NET, kishore@ind.alcatel.com, Pramoda.Nallur@ind.alcatel.com, Manu.Prakash@ind.alcatel.com, Pramoda.Nallur@ind.alcatel.com, jzou@mars.iol.unh.edu, Dilip.Pandit@ind.alcatel.com, Jahaapanah@netscape.net, ayyangar@apollo.mctr.umbc.edu, SJONES@iirltd.co.uk, jplang@calient.net, pms_tech@yahoo.com, cvkrao@yahoo.com Subject: Re: Fwd: MPLS simulator In-Reply-To: <5.0.2.1.0.20010304140634.00a88050@pop3.eng.utoledo.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk u can check the NS network simulator at www.isi.edu/nsnam/ns which has the MPLS module added to it. Please check the site for more details. Renjish "Man who drive like hell is bound to get there!" confucius On Sun, 4 Mar 2001 ahussain@eng.utoledo.edu wrote: > > >Date: Sun, 04 Mar 2001 13:54:36 -0500 > >To: SJONES@iirltd.co.uk > >From: ahussain@pop3.eng.utoledo.edu > >Subject: MPLS simulator > >Cc: ahussain > > > > > >>Date: Sun, 04 Mar 2001 13:53:15 -0500 > >>To: jleu@laurelnetworks.com > >>From: ahussain@pop3.eng.utoledo.edu > >>Subject: MPLS simulator > >> > >>Hi, > >> I am new to the MPLS world. I will be doing my MS project in MPLS. > >> Since you have profound knowledge about it, i would like u to help me out. > >> Please let me know if an MPLS simulator is available. If u have one > >> please mail it to me. > >> > >>Please give me comments on the following: > >> "Modifying a code the simulates an IP switch into one that simulates MPLS" > >> > >>Regards, > >> Abrar. > > From owner-mpls@UU.NET Mon Mar 5 12:04:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21538 for ; Mon, 5 Mar 2001 12:04:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfbg20056; Mon, 5 Mar 2001 17:03:08 GMT Received: by mail-control.mail.uu.net id QQkfbg27151 for mpls-outgoing; Mon, 5 Mar 2001 17:02:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfbg27127 for ; Mon, 5 Mar 2001 17:02:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfbg24887 for ; Mon, 5 Mar 2001 17:02:09 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkfbg21587 for ; Mon, 5 Mar 2001 17:02: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 MAA20004 for ; Mon, 5 Mar 2001 12:02:07 -0500 (EST) 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 MAA05654 for ; Mon, 5 Mar 2001 12:02:07 -0500 (EST) Message-ID: <3AA3C694.3DE26199@marconi.com> Date: Mon, 05 Mar 2001 12:02:12 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Status of COS Service in rsvp-lsp-tunnel-08.txt References: <4.3.2.7.2.20010305091506.00c0fad0@mo-ex> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lou Berger wrote: > > Here's my (limited) understanding of the issue. A while back > two separate ways of specifying BE/CoS service made it into drafts. > One of which was the CoS object in the rsvp-lsp draft. The other, > while I think came later in time, made it through the IETF process > first and has been standardized in RFCs2997 and 2996. This result was > that the CoS object served the same purpose of an existing standards > track RFC. Having two ways to signal the same thing really doesn't > make sense, and since they got there first, we loose. While the > decision is painful now, I think it's better than the alternative. > Having some more words on this in draft certainly makes sense. (Eric > G. made this point privately.) Thanks. RFC 2997 allows RSVP to signal best-effor without using DiffServ extensions. Replacing support for COS with Null-IntServ will be a bit annoying in places, but not nearly as difficult as implementing the diff-ext draft. Which working group developed 2997? I don't remember seeing anything about it here or on the RSVP list. (Maybe it was on the IntServ list? I'm not subscribed to that one.) With respect to the MPLS drafts (RSVP-TE and diff-ext), these RFCs should definitely be referenced, since they appear to have become hard requirements. -- David From owner-mpls@UU.NET Mon Mar 5 12:48:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23809 for ; Mon, 5 Mar 2001 12:48:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfau02403; Mon, 5 Mar 2001 14:04:20 GMT Received: by mail-control.mail.uu.net id QQkfau00685 for mpls-outgoing; Mon, 5 Mar 2001 14:03:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfau29982 for ; Mon, 5 Mar 2001 14:03:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfau06315 for ; Mon, 5 Mar 2001 14:02:30 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfau17322 for ; Mon, 5 Mar 2001 14:02: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 GAA06779 for ; Mon, 5 Mar 2001 06:02:46 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA16273 for mpls@uu.net; Mon, 5 Mar 2001 09:02:28 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkext15517 for ; Sun, 4 Mar 2001 18:28:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkext01511 for ; Sun, 4 Mar 2001 18:27:52 GMT Received: from snipe.prod.itd.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: snipe.prod.itd.earthlink.net [207.217.120.62]) id QQkext11538 for ; Sun, 4 Mar 2001 18:27:52 GMT Received: from computer.earthlink.net (user-2ivemeo.dialup.mindspring.com [165.247.89.216]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id KAA25021; Sun, 4 Mar 2001 10:27:37 -0800 (PST) Message-Id: <4.3.2.7.2.20010304133046.00c17260@mail.earthlink.net> X-Sender: ilazar@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 04 Mar 2001 13:31:41 -0500 To: Rajiv Papneja , Brian Hou From: Irwin Lazar Subject: Re: GMPLS extensions to IGP protocols Cc: mpls@UU.NET, mpls-ops@mplsrc.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Both of the below drafts have been updated. The latest versions are: http://search.ietf.org/internet-drafts/draft-kompella-ospf-gmpls-extensions-01.txt http://search.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-02.txt At 02:21 PM 3/2/2001 -0500, Rajiv Papneja wrote: >Hi Brian, > > Here are the links to two drafts: > >http://search.ietf.org/internet-drafts/draft-kompella-ospf-gmpls-extensions-00.txt >http://search.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-01.txt > > -Rajiv > >******************************** >Rajiv Papneja (GRA) >Advanced Internet Laboratory >George Mason University, >G10, Johnson Center, >Fairfax, VA 22030-4444 >Tel: 703.993.4703 >email: rpapneja@osf1.gmu.edu >******************************** > > >On Fri, 2 Mar 2001, Brian Hou wrote: > > > Hi: > > > > Are there any IETF drafts that discuss the GMPLS extensions to IGPs > such as > > OSFT and ISIS? > > > > Thanks! > > > > Brian Hou > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > > > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Mon Mar 5 13:01:43 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24698 for ; Mon, 5 Mar 2001 13:01:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfbk06501; Mon, 5 Mar 2001 18:00:50 GMT Received: by mail-control.mail.uu.net id QQkfbk13501 for mpls-outgoing; Mon, 5 Mar 2001 18:00:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfbk12748 for ; Mon, 5 Mar 2001 18:00:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfbj11354 for ; Mon, 5 Mar 2001 17:59:31 GMT Received: from pulsar.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 200-139.adsl6.netlojix.net [207.71.200.139] (may be forged)) id QQkfbj04204 for ; Mon, 5 Mar 2001 17:59:31 GMT Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2653.19) id <1QR78PPX>; Mon, 5 Mar 2001 09:57:18 -0800 Message-ID: From: Jonathan Lang To: "'Florian-Daniel Otel'" , mpls@UU.NET Subject: RE: LMP over switched Ethernet Date: Mon, 5 Mar 2001 09:57:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Florian, Yes, you are correct. LMP Hellos (encapsulated in IP) will not be detected from the failed router. Thanks, Jonathan > -----Original Message----- > From: Florian-Daniel Otel [mailto:otel@ce.chalmers.se] > Sent: Monday, March 05, 2001 1:29 AM > To: mpls@UU.NET > Cc: otel@ce.chalmers.se > Subject: LMP over switched Ethernet > > > > > All, > > > I am intrested about the LMP capability to detect a failing router > behind an Ethernet switch. From a (very) quick skim (read: grep) > through the LMP draft I got the impression that -- as it uses IP > encoded messages for the control channel (in this case identical w/ > the data channel) -- it will work and LMP does detect a failing > router behind an Eth. switch. > > > Is this right or am I missing something ? > > Florian > From owner-mpls@UU.NET Mon Mar 5 13:04:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25456 for ; Mon, 5 Mar 2001 13:04:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfbk12830; Mon, 5 Mar 2001 18:02:01 GMT Received: by mail-control.mail.uu.net id QQkfbk15263 for mpls-outgoing; Mon, 5 Mar 2001 18:01:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfbk14825 for ; Mon, 5 Mar 2001 18:01:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfbk26768 for ; Mon, 5 Mar 2001 18:00:24 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfbk10378 for ; Mon, 5 Mar 2001 18:00:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA23691 for mpls@uu.net; Mon, 5 Mar 2001 13:00:23 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfbj10723 for ; Mon, 5 Mar 2001 17:59:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfbj02743 for ; Mon, 5 Mar 2001 17:58:54 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkfbj16682 for ; Mon, 5 Mar 2001 17:58:53 GMT Received: from lir.cisco.com (lir.cisco.com [161.44.172.144]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA10772; Mon, 5 Mar 2001 12:58:13 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA24962; Mon, 5 Mar 2001 11:39:04 -0500 (EST) Message-Id: <200103051639.LAA24962@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Francois Le Faucheur cc: awduche@movaz.com, lberger@movaz.com, dhg@juniper.net, tonyl@home.net, vsriniva@cosine.com, swallow@cisco.com, mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram64@lucent.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi, david.charlap@marconi.com, swallow@cisco.com Subject: Re: Status of COS Service in rsvp-lsp-tunnel-08.txt In-reply-to: Your message of "Mon, 05 Mar 2001 15:07:47 +0100." <200103051410.PAA28348@cisco.com> Date: Mon, 05 Mar 2001 11:39:04 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Francois - My error on the dangling references. I'll issue an updated draft with pointers to the "Null Service Type", RFC 2997. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Mar 5 13:37:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26837 for ; Mon, 5 Mar 2001 13:37:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfbm11719; Mon, 5 Mar 2001 18:36:48 GMT Received: by mail-control.mail.uu.net id QQkfbm28042 for mpls-outgoing; Mon, 5 Mar 2001 18:36:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfbm27980 for ; Mon, 5 Mar 2001 18:36:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfbm13520 for ; Mon, 5 Mar 2001 18:34:13 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfbm25261 for ; Mon, 5 Mar 2001 18:34:13 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 KAA10839 for ; Mon, 5 Mar 2001 10:34:29 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA00898 for mpls@uu.net; Mon, 5 Mar 2001 13:34:11 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfbl27161 for ; Mon, 5 Mar 2001 18:16:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfbl23218 for ; Mon, 5 Mar 2001 18:16:48 GMT Received: from shared1-mail.whowhere.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: shared1-qin.whowhere.com [209.185.123.111]) id QQkfbl04340 for ; Mon, 5 Mar 2001 18:16:47 GMT Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Mon Mar 5 10:16:35 2001 To: mpls@UU.NET Date: Mon, 05 Mar 2001 18:46:35 +0030 From: "Manoj Kumar Juneja" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: manoj.juneja@eudoramail.com X-Expiredinmiddle: true X-Mailer: MailCity Service Subject: Fwd: Question about wavebandId X-Sender-Ip: 38.204.3.195 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I am again sending the following doubt regarding wavebandId. Please help. In draft "draft-ietf-mpls-generalized-signalling-01.txt", it is mentioned that wavebandId (32 bits) is selected by the sender and reused in all the subsequent messages. What all subsequent messages is it mentioning to ? Thanks, manoj. Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com --------- End Forwarded Message --------- Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-mpls@UU.NET Tue Mar 6 01:10:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19804 for ; Tue, 6 Mar 2001 01:10:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfdg00121; Tue, 6 Mar 2001 06:09:11 GMT Received: by mail-control.mail.uu.net id QQkfdg20376 for mpls-outgoing; Tue, 6 Mar 2001 06:08:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfdg20370 for ; Tue, 6 Mar 2001 06:08:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfdg08099 for ; Tue, 6 Mar 2001 06:08:11 GMT Received: from web9407.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web9407.mail.yahoo.com [216.136.129.23]) id QQkfdg27851 for ; Tue, 6 Mar 2001 06:08:10 GMT Message-ID: <20010306060809.74922.qmail@web9407.mail.yahoo.com> Received: from [202.75.160.213] by web9407.mail.yahoo.com; Mon, 05 Mar 2001 22:08:09 PST Date: Mon, 5 Mar 2001 22:08:09 -0800 (PST) From: Somasundaram Subject: Re: Fwd: MPLS simulator To: Kaleelazhicathu R R Kumar , ahussain@eng.utoledo.edu, mpls@UU.NET Cc: jlawrenc@cisco.com, mpls@UU.NET, kishore@ind.alcatel.com, Pramoda.Nallur@ind.alcatel.com, Manu.Prakash@ind.alcatel.com, jzou@mars.iol.unh.edu, Dilip.Pandit@ind.alcatel.com, Jahaapanah@netscape.net, ayyangar@apollo.mctr.umbc.edu, SJONES@iirltd.co.uk, jplang@calient.net, pms_tech@yahoo.com, cvkrao@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk You may download the MPLS patch from http://www.raonet.com/introduction.shtml rgds soma --- Kaleelazhicathu R R Kumar wrote: > > u can check the NS network simulator at > www.isi.edu/nsnam/ns which has > the MPLS module added to it. Please check the site > for more details. > > Renjish > > > "Man who drive like hell is bound to get there!" > confucius > > > > > > > > > > > > On Sun, 4 Mar 2001 ahussain@eng.utoledo.edu wrote: > > > > > >Date: Sun, 04 Mar 2001 13:54:36 -0500 > > >To: SJONES@iirltd.co.uk > > >From: ahussain@pop3.eng.utoledo.edu > > >Subject: MPLS simulator > > >Cc: ahussain > > > > > > > > >>Date: Sun, 04 Mar 2001 13:53:15 -0500 > > >>To: jleu@laurelnetworks.com > > >>From: ahussain@pop3.eng.utoledo.edu > > >>Subject: MPLS simulator > > >> > > >>Hi, > > >> I am new to the MPLS world. I will be doing my > MS project in MPLS. > > >> Since you have profound knowledge about it, i > would like u to help me out. > > >> Please let me know if an MPLS simulator is > available. If u have one > > >> please mail it to me. > > >> > > >>Please give me comments on the following: > > >> "Modifying a code the simulates an IP switch > into one that simulates MPLS" > > >> > > >>Regards, > > >> Abrar. > > > > > __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Tue Mar 6 01:10:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19827 for ; Tue, 6 Mar 2001 01:10:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfdg15634; Tue, 6 Mar 2001 06:09:14 GMT Received: by mail-control.mail.uu.net id QQkfdg20381 for mpls-outgoing; Tue, 6 Mar 2001 06:08:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfdg20371 for ; Tue, 6 Mar 2001 06:08:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfdg08055 for ; Tue, 6 Mar 2001 06:08:10 GMT Received: from web9407.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web9407.mail.yahoo.com [216.136.129.23]) id QQkfdg24133 for ; Tue, 6 Mar 2001 06:08:10 GMT Message-ID: <20010306060809.74922.qmail@web9407.mail.yahoo.com> Received: from [202.75.160.213] by web9407.mail.yahoo.com; Mon, 05 Mar 2001 22:08:09 PST Date: Mon, 5 Mar 2001 22:08:09 -0800 (PST) From: Somasundaram Subject: Re: Fwd: MPLS simulator To: Kaleelazhicathu R R Kumar , ahussain@eng.utoledo.edu, mpls@UU.NET Cc: jlawrenc@cisco.com, mpls@UU.NET, kishore@ind.alcatel.com, Pramoda.Nallur@ind.alcatel.com, Manu.Prakash@ind.alcatel.com, jzou@mars.iol.unh.edu, Dilip.Pandit@ind.alcatel.com, Jahaapanah@netscape.net, ayyangar@apollo.mctr.umbc.edu, SJONES@iirltd.co.uk, jplang@calient.net, pms_tech@yahoo.com, cvkrao@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk You may download the MPLS patch from http://www.raonet.com/introduction.shtml rgds soma --- Kaleelazhicathu R R Kumar wrote: > > u can check the NS network simulator at > www.isi.edu/nsnam/ns which has > the MPLS module added to it. Please check the site > for more details. > > Renjish > > > "Man who drive like hell is bound to get there!" > confucius > > > > > > > > > > > > On Sun, 4 Mar 2001 ahussain@eng.utoledo.edu wrote: > > > > > >Date: Sun, 04 Mar 2001 13:54:36 -0500 > > >To: SJONES@iirltd.co.uk > > >From: ahussain@pop3.eng.utoledo.edu > > >Subject: MPLS simulator > > >Cc: ahussain > > > > > > > > >>Date: Sun, 04 Mar 2001 13:53:15 -0500 > > >>To: jleu@laurelnetworks.com > > >>From: ahussain@pop3.eng.utoledo.edu > > >>Subject: MPLS simulator > > >> > > >>Hi, > > >> I am new to the MPLS world. I will be doing my > MS project in MPLS. > > >> Since you have profound knowledge about it, i > would like u to help me out. > > >> Please let me know if an MPLS simulator is > available. If u have one > > >> please mail it to me. > > >> > > >>Please give me comments on the following: > > >> "Modifying a code the simulates an IP switch > into one that simulates MPLS" > > >> > > >>Regards, > > >> Abrar. > > > > > __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Tue Mar 6 04:30:55 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05773 for ; Tue, 6 Mar 2001 04:30:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfdt00244; Tue, 6 Mar 2001 09:26:46 GMT Received: by mail-control.mail.uu.net id QQkfdt17990 for mpls-outgoing; Tue, 6 Mar 2001 09:26:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfdt17954 for ; Tue, 6 Mar 2001 09:26:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfdt18245 for ; Tue, 6 Mar 2001 09:25:14 GMT Received: from mail.commverge.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.commverge.com [203.161.226.141]) id QQkfdt14349 for ; Tue, 6 Mar 2001 09:25:13 GMT Received: from cgd (bt-214-053.bta.net.cn [202.106.214.53]) by mail.commverge.com (Mirapoint) with ESMTP id AAF12187 (AUTH frankcheng); Tue, 6 Mar 2001 17:24:02 +0800 (HKT) From: "chengguangdong" To: , Subject: How to integrate MPLS and IPSec in IP VPN Date: Tue, 6 Mar 2001 17:23:01 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA05773 Hi All, Our customer want to build VPN based MPLS but he needs the traffic must be encrypted before they go to PE routers. In order to provide confidentiality and any to any connection, the CE routers must be IPSec full meshed , this would be nightmare for a VPN with hundreds CE routers and conflicts with the advantage of MPLS VPN----simple provisioning. So what are the solutions. I will be very appreciated if I can get your answer. Best Regards, Cheng Guang Dong From owner-mpls@UU.NET Tue Mar 6 05:05:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06013 for ; Tue, 6 Mar 2001 05:05:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfdv28620; Tue, 6 Mar 2001 09:58:48 GMT Received: by mail-control.mail.uu.net id QQkfdv20250 for mpls-outgoing; Tue, 6 Mar 2001 09:58:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfdv20245 for ; Tue, 6 Mar 2001 09:58:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfdv03253 for ; Tue, 6 Mar 2001 09:58:15 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkfdv17430 for ; Tue, 6 Mar 2001 09:58:14 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Tue, 6 Mar 2001 09:46:16 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id <1PCP5SZ9>; Tue, 6 Mar 2001 09:44:45 -0000 Message-ID: To: satoru@japan-telecom.co.jp, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: New TTL Draft Date: Tue, 6 Mar 2001 09:44:39 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Satoru/Shahram.....trying catch up on the mail backlog I have just got round to reading this. My take: 1 I agree with the '1-hop' concept in here since it is architecturally correct. That is, if one creates a trail at layer N say, then each link connection in that trail (ie between 2 adjacent nodes at layer N) is created by a server trail at layer N-1. This process recurses for the layer N-1 trail and so on to the duct. In other words, a trail at layer N has no visibiluty, and indeed should not have visibility, of all the constituent server layers (which may also be different technologies) that lie underneath it. Hence, from a client layer perspective a link connection can never be anything but a single hop, and the TTL setting of each trail should be an independent consideration. 2 Wrt to detecting defects that can affect LSPs please check out the ID that was just posted (by Shahram) on MPLS OAM. Note that this is aimed at explicitly routed pt-pt LSPs and not plain LDP LSPs. http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt I hope you find this of some value. regards, neil > -----Original Message----- > From: S.Matsushima [mailto:satoru@japan-telecom.co.jp] > Sent: 28 February 2001 12:56 > To: Shahram_Davari@pmc-sierra.com > Cc: puneet@pluris.com; eric.gray@sandburst.com; mpls@UU.NET; > flefauch@cisco.com; liwwu@cisco.com; bsd@cisco.com; akyol@pluris.com > Subject: RE: New TTL Draft > > > Shahram, > > This is Satoru Matsushima. > > > Hi All, > > > > Interestingly a similar draft was posted today: > > > > > http://www.ietf.org/internet-drafts/draft-satoru-mpls-1hop-lsp-00.txt > > Thanks,:-) > Actually, this draft consist of three elements: > > - TTL Processing expansion. > - Label distribution method for 1-hop LSP. > - The possible to "LSP KeepAlive" using 1-hop LSP. > > So, this draft was not only TTL processing, and it was stated about > for using 1-hop LSP. Because, I had to describe these elements when I > tried to write about realizing 1-hop LSP in this draft. > > I think Puneet's draft(and after discussion in ML) described very well > TTL procesing for hierarchical LSP, but the 1-hop LSP(Pipe model LSP) > is not a thing only for Diff-Serv. It is very usefull for MPLS/VPN > operators. (I'm a MPLS/VPN operator.;-) > Therefore, I think TTL processing expansion should be described more > generally and be careful in label distribution mode; DU or DoD. > (we call "Cloud model" and "Per LSP model") > > "LSP KeepAlive" ability is extremely important for the applications > which use LSP but cannnot know the state of LSP itself(for instance, > BGP/MPLS VPNs). > I described a method of "LSP KeepAlive" using 1-hop LSP in this draft. > How do you think about this? > > > regards, > > -- > Satoru Matsushima From owner-mpls@UU.NET Tue Mar 6 06:54:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08326 for ; Tue, 6 Mar 2001 06:54:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfed29421; Tue, 6 Mar 2001 11:52:56 GMT Received: by mail-control.mail.uu.net id QQkfed27627 for mpls-outgoing; Tue, 6 Mar 2001 11:52:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfed27622 for ; Tue, 6 Mar 2001 11:52:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfed24467 for ; Tue, 6 Mar 2001 11:51:53 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfed27151 for ; Tue, 6 Mar 2001 11:51:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA12558 for mpls@uu.net; Tue, 6 Mar 2001 06:51:50 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfed27571 for ; Tue, 6 Mar 2001 11:51:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfed17225 for ; Tue, 6 Mar 2001 11:51:07 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfed26064 for ; Tue, 6 Mar 2001 11:51:07 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07894; Tue, 6 Mar 2001 06:51:07 -0500 (EST) Message-Id: <200103061151.GAA07894@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-recovery-frmwrk-02.txt Date: Tue, 06 Mar 2001 06:51:06 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Framework for MPLS-based Recovery Author(s) : V. Sharma et al. Filename : draft-ietf-mpls-recovery-frmwrk-02.txt Pages : 33 Date : 05-Mar-01 Multi-protocol label switching (MPLS) [1] integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling [2], [3], [4], [5], [6], [7] support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-recovery-frmwrk-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010305132100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-recovery-frmwrk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132100.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Mar 6 08:23:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10911 for ; Tue, 6 Mar 2001 08:23:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfej19450; Tue, 6 Mar 2001 13:22:48 GMT Received: by mail-control.mail.uu.net id QQkfej07046 for mpls-outgoing; Tue, 6 Mar 2001 13:22:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfej07039 for ; Tue, 6 Mar 2001 13:22:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfej16985 for ; Tue, 6 Mar 2001 13:21:50 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQkfej23688 for ; Tue, 6 Mar 2001 13:21:46 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 OAA19814; Tue, 6 Mar 2001 14:21:34 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA15167; Tue, 6 Mar 2001 14:21:03 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Mar 2001 14:21:02 +0100 Message-ID: From: Hummel Heinrich To: "'chengguangdong'" , nbvpn@bbo.com, mpls@UU.NET Subject: AW: How to integrate MPLS and IPSec in IP VPN Date: Tue, 6 Mar 2001 14:21:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA10911 Hi Cheng, All of the current models depend on full mesh inter-site connectivity. But watch out for my contribution draft-hummel-ppvpn-tunnel-systems-00.txt. It deals with computing, establishing,testing, tearing down minimal VPN-tunnel systems, which e.g. form trees (without roots), rings, meshy graphs. Hereby it is assumed that any tunnel (PE-to-PE / CE-to-CE) may also be used as transit tunnel. I can show you a simulation where in a network of 300 nodes and 550 links 100 site-nodes are interconnected either by a tree/ring system of 99/100 bidirectional tunnels which consume 160/213 LSP-hops or however by 100 Dijkstra trees whereby each of them comprises 200 links in average. IMHO, only physical full mesh is still worse than virtual full mesh. But 100x200 = 20,000 LSP-hops is still too much compared with 160 or 213 LSP-hops. And this is only for one such VPN. Some service provider will have more than one customer. When I presented a similar contribution to ITU-T SG 13 Q11 it became obvious that I am aiming for a new VPN model, whereby the cost savings are worth the effort. Furthermore, the tunnels may be CE-to-CE as well. I hope that the MPLS Forum (which meets right now in New Orleans) is adopting a MPLS UNI initiative, so that a user (here the CE) will soon be enabled to request a CE-to-CE MPLS-layer-2 tunnel across the service provider network. This will promote secured, customer-based VPNs ! Best Regards, Heinrich Hummel Siemens > -----Urspr> üngliche Nachricht----- > Von: chengguangdong [SMTP:frankcheng@commverge.com] > Gesendet am: Dienstag, 6. März 2001 10:23 > An: nbvpn@bbo.com; mpls@UU.NET > Betreff: How to integrate MPLS and IPSec in IP VPN > > Hi All, > Our customer want to build VPN based MPLS but he needs the traffic must be encrypted before they go to PE routers. In order to provide confidentiality and any to any connection, the CE routers must be IPSec full meshed , this would be nightmare for a VPN with hundreds CE routers and conflicts with the advantage of MPLS VPN----simple provisioning. > So what are the solutions. I will be very appreciated if I can get your answer. > > Best Regards, > Cheng Guang Dong From owner-mpls@UU.NET Tue Mar 6 09:58:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13762 for ; Tue, 6 Mar 2001 09:58:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfep12894; Tue, 6 Mar 2001 14:57:40 GMT Received: by mail-control.mail.uu.net id QQkfep29982 for mpls-outgoing; Tue, 6 Mar 2001 14:57:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfep29974 for ; Tue, 6 Mar 2001 14:57:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfep09495 for ; Tue, 6 Mar 2001 14:56:07 GMT Received: from gw.tropicnetworks.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.tropicnetworks.com [209.87.233.9]) id QQkfep09099 for ; Tue, 6 Mar 2001 14:56:06 GMT Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for cmr1.ash.ops.us.uu.net [198.5.241.39]) with SMTP; 6 Mar 2001 14:57:14 UT Received: from cr437225a ([10.1.2.190]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAAFE; Tue, 6 Mar 2001 09:58:13 -0500 From: "Sudhakar Ganti" To: , Cc: Subject: RE: MPLS traffic engineering query. Date: Tue, 6 Mar 2001 09:54:14 -0500 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.2911.0) In-reply-to: <3AA1DDC7.866189AE@cdotd.ernet.in> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Alok, Please see the URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-ccamp-multi-area-te-reqmts-00. txt It addresses these concerns -Sudhakar -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Alok Tripathi Sent: Sunday, March 04, 2001 1:17 AM To: mpls@UU.NET Cc: alok_tripathi@chequemail.com Subject: MPLS traffic engineering query. Hi *, I have a query on the MPLS traffic engineering application. The route of a TE tunnel is determined by either static definition or a "constraint based routeing" (CBR) calculation on the tunnel head end. Signalling mechanism then sets up the LSP based on the calculated route. Since CBR computation requires the full topology information , which gets hidden across OSPF areas & domains, How do we extend the Traffic Engineering beyond :-- 1.a single OSPF area in case of a large ISP ? 2.Across the domains ? Thanks in advance. Alok Tripathi, Research Engineer, Centre for Development of Telematics, C-DOT Akbar Bhawan, Chanakyapuri, New Delhi, India. From owner-mpls@UU.NET Tue Mar 6 10:43:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14968 for ; Tue, 6 Mar 2001 10:43:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfes17186; Tue, 6 Mar 2001 15:42:04 GMT Received: by mail-control.mail.uu.net id QQkfes20907 for mpls-outgoing; Tue, 6 Mar 2001 15:41:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfes20886 for ; Tue, 6 Mar 2001 15:41:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfes10195 for ; Tue, 6 Mar 2001 15:41:11 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfes15787 for ; Tue, 6 Mar 2001 15:41:11 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 HAA05591 for ; Tue, 6 Mar 2001 07:41:29 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA01723 for mpls@uu.net; Tue, 6 Mar 2001 10:41:09 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfbr19470 for ; Mon, 5 Mar 2001 19:51:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfbr24930 for ; Mon, 5 Mar 2001 19:50:54 GMT Received: from shared1-mail.whowhere.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: shared1-qin.whowhere.com [209.185.123.111]) id QQkfbr15460 for ; Mon, 5 Mar 2001 19:50:53 GMT Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Mon Mar 5 11:50:39 2001 To: mpls@UU.NET Date: Mon, 05 Mar 2001 20:20:39 +0030 From: "Manoj Kumar Juneja" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: manoj.juneja@eudoramail.com X-Mailer: MailCity Service Subject: Doubt about waveband Label X-Sender-Ip: 38.204.3.195 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, In draft "draft-ietf-mpls-generalized-signalling-01.txt", it is mentioned that for waveband switching, the genralized label has the format (wavebandId - start label - end label). When the label request message is received on incoming interface, how to identify that the waveand label is requested ? Is it the LSP encoding type or some other parameter in label request message ? Please help. Thanks, manoj. Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-mpls@UU.NET Tue Mar 6 13:49:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21594 for ; Tue, 6 Mar 2001 13:49:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfff27697; Tue, 6 Mar 2001 18:48:14 GMT Received: by mail-control.mail.uu.net id QQkfff22405 for mpls-outgoing; Tue, 6 Mar 2001 18:47:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfff22397 for ; Tue, 6 Mar 2001 18:47:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfff16335 for ; Tue, 6 Mar 2001 18:45:33 GMT Received: from smtp015.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp015.mail.yahoo.com [216.136.173.59]) id QQkfff08361 for ; Tue, 6 Mar 2001 18:45:32 GMT Received: from unknown (HELO c123294a) (38.169.12.100) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Mar 2001 18:45:32 -0000 X-Apparently-From: Message-ID: <001a01c0a66d$04d1fa90$2b1e0a0a@c123294a> From: "Jing Zeng" To: "chengguangdong" , , References: Subject: Re: How to integrate MPLS and IPSec in IP VPN Date: Tue, 6 Mar 2001 10:40:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi cheng, If the IPSEC function is added on CE router,it is CPE based IPSEC VPN solution.You can try network based VPN solution. Add VPN concentrator(such as Cisco 5000) between CE and PE to support thousands of VPN.It is easy to configure and provision. Or use SMS(subscriber management system) box from Shasta/Nortel or Cosine to add IPSEC VPN Service. Best Regards Jing Zeng ----- Original Message ----- From: "chengguangdong" To: ; Sent: Tuesday, March 06, 2001 1:23 AM Subject: How to integrate MPLS and IPSec in IP VPN > Hi All, > Our customer want to build VPN based MPLS but he needs the traffic must be encrypted before they go to PE routers. In order to provide confidentiality and any to any connection, the CE routers must be IPSec full meshed , this would be nightmare for a VPN with hundreds CE routers and conflicts with the advantage of MPLS VPN----simple provisioning. > So what are the solutions. I will be very appreciated if I can get your answer. > > Best Regards, > Cheng Guang Dong > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-mpls@UU.NET Tue Mar 6 13:58:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22256 for ; Tue, 6 Mar 2001 13:58:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfff24700; Tue, 6 Mar 2001 18:56:51 GMT Received: by mail-control.mail.uu.net id QQkfff22907 for mpls-outgoing; Tue, 6 Mar 2001 18:56:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfff22898 for ; Tue, 6 Mar 2001 18:56:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfff11656 for ; Tue, 6 Mar 2001 18:56:09 GMT From: djiang1@lucent.com Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkfff23618 for ; Tue, 6 Mar 2001 18:56:08 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 NAA00232 for ; Tue, 6 Mar 2001 13:56:08 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA00216 for ; Tue, 6 Mar 2001 13:56:07 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA23499; Tue, 6 Mar 2001 13:56:06 -0500 (EST) Subject: Re: How to integrate MPLS and IPSec in IP VPN To: mpls@UU.NET Date: Tue, 6 Mar 2001 13:52:23 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 03/06/2001 13:52:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk ---------------------- Forwarded by Jane Jiang/HQ/Yurie on 03/06/2001 01:55 PM --------------------------- Jane Jiang 03/06/2001 08:34 AM To: "chengguangdong" cc: Subject: Re: How to integrate MPLS and IPSec in IP VPN (Document link: Jane Jiang) Hi Cheng Guang Dong, MPLS VPN and IPsec are two different things. They should not conflict with each other. If you do IPsec in tunnel mode, i.e., fully hide your customer's traffic at the CPE routers and then do MPLS forwarding based on the CPE router addresses, then you should be able to achieve MPLS VPN and IPsec at the same time. Regards, Jane D. Jiang "chengguangdong" @UU.NET on 03/06/2001 04:23:01 AM Sent by: owner-mpls@UU.NET To: , cc: Subject: How to integrate MPLS and IPSec in IP VPN Hi All, Our customer want to build VPN based MPLS but he needs the traffic must be encrypted before they go to PE routers. In order to provide confidentiality and any to any connection, the CE routers must be IPSec full meshed , this would be nightmare for a VPN with hundreds CE routers and conflicts with the advantage of MPLS VPN----simple provisioning. So what are the solutions. I will be very appreciated if I can get your answer. Best Regards, Cheng Guang Dong From owner-mpls@UU.NET Tue Mar 6 14:29:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23808 for ; Tue, 6 Mar 2001 14:29:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkffh28298; Tue, 6 Mar 2001 19:28:44 GMT Received: by mail-control.mail.uu.net id QQkffh11173 for mpls-outgoing; Tue, 6 Mar 2001 19:28:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkffh11164 for ; Tue, 6 Mar 2001 19:28:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkffh21758 for ; Tue, 6 Mar 2001 19:28:05 GMT Received: from seralph10.essex.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: seralph10.essex.ac.uk [155.245.240.160]) id QQkffh27262 for ; Tue, 6 Mar 2001 19:28:05 GMT Received: from so-15354-x0.essex.ac.uk ([155.245.127.138] helo=so-18688-xo.china.com) by seralph10.essex.ac.uk with esmtp (Exim 3.13 #1) id 14aN7m-0003ow-00 for mpls@UU.NET; Tue, 06 Mar 2001 19:27:58 +0000 Message-Id: <5.0.2.1.2.20010306192919.00aaa210@pop.china.com> Date: Tue, 06 Mar 2001 19:30:03 +0000 To: mpls@UU.NET From: Norman Ng Subject: Network Restoration Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi to all, I am new mpls technology and I would like to know more about the network restoration and protection in MPLS. Could anyone let me know more information or references in this area. Also I have some queries, what happens if a MPLS network has a span failure or node failure in say a mesh network? Does it performs convergence like in OSPF?? If restoration is performed, how fast does it takes? Can this area be improved upon as I am looking into for an area to work on for my thesis. Thanks in advance for helping. Warmest Regards, Norman From owner-mpls@UU.NET Tue Mar 6 14:58:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25127 for ; Tue, 6 Mar 2001 14:58:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkffj11044; Tue, 6 Mar 2001 19:56:58 GMT Received: by mail-control.mail.uu.net id QQkffj13396 for mpls-outgoing; Tue, 6 Mar 2001 19:56:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkffj13387 for ; Tue, 6 Mar 2001 19:56:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkffj03816 for ; Tue, 6 Mar 2001 19:55:38 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkffj20931 for ; Tue, 6 Mar 2001 19:55:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA11994 for mpls@uu.net; Tue, 6 Mar 2001 14:55:32 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkffj13293 for ; Tue, 6 Mar 2001 19:54:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkffj24506 for ; Tue, 6 Mar 2001 19:54:22 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkffj17821 for ; Tue, 6 Mar 2001 19:54:21 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Mar 2001 11:53:52 -0800 Message-ID: From: Vishal Mishra To: "'eric.gray@sandburst.com'" , "'Francis Arts'" Cc: "'mpls@UU.NET'" , Vishal Sharma , Vach Kompella Subject: Re: New TTL Draft. Date: Tue, 6 Mar 2001 11:53:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello All, Besides the reasons specified below, there are several other situations in which it is desirable to decrement TTL by N. According to the MPLS architecture, any label distribution protocol can be used for LSP setup. Therefore, assume an MPLS cloud, which is built over IP (no ATM/Frame Relay for now). Let us also assume that this MPLS cloud is composed of LSRs that use RSVP and/or LDP as their Label Distribution (and therefore LSP setup) Protocols. Now an administrator wants to setup an LSP using RSVP, but realizes that the path is passing through a non-RSVP (say LDP) cloud. Since IP-TTL counts the number of IP hops, and RSVP-TTL counts the number of RSVP hops, therefore the presence of a Non-RSVP cloud is detected by the next RSVP hop, and LSP setup fails, with Path Tear messages being replied back to the sender(s). Therefore, now the administrator would like to connect the RSVP clouds with a 'Single IP Hop' LSP so that, To RSVP, the Multi-MPLS-Hop LSP 'looks' like a Single-IP-Hop. To achieve this, the Ingress LER should be able to setup the LSP, and 'tell' the Egress, not to copy MPLS-TTL into IP-TTL. Instead, it (Ingress LER) would be decrementing the TTL by N (In this example: N=1, by configuration). Do we have any mechanism in RSVP and/or LDP to configure/negotiate the 'IP-Hop length' (say N) of an LSP, so that Ingress LER decrements the IP TTL (by N), and Egress LER does not copy MPLS-TTL into IP-TTL ? I don't think so, although it can be done at the time of LSP setup. If this needs to be supported in RSVP and LDP, then for RSVP, we would need a new 'OPTIONAL' RSVP object (say IP_HOP_LENGTH), and for LDP, we would need a new 'OPTIONAL' TLV (say IP_HOP_LENGTH). I feel that the potential of MPLS TTL field is not being fully utilized by the existing MPLS mechanisms. e.g. We can control the 'perceived' length of an LSP using the above proposed mechanism. There lies the power of MPLS ;-), and the value addition of the presence of multiple TTL fields in the MPLS-IP-Packet !! Awaiting Comments ... Vishal. --- Francis Arts wrote: > > Hello Eric, > > In the discussion below you propose the possibility to decrement the TTL > with N units. You indicate that the reason for doing this, is the following: >> There are practical reasons for decrementing TTL by more than one >> (a high-cost or low-bandwidth link, for example) when it is desirable to >> accelerate the aging of possibly looping packets. A higher TTL >> decrement punishes all packets that use the link, but it punishes looping >> packets much more. http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt From owner-mpls@UU.NET Tue Mar 6 21:55:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08462 for ; Tue, 6 Mar 2001 21:55:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfgl21461; Wed, 7 Mar 2001 02:54:41 GMT Received: by mail-control.mail.uu.net id QQkfgl09814 for mpls-outgoing; Wed, 7 Mar 2001 02:54:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfgl09809 for ; Wed, 7 Mar 2001 02:53:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfgl28467 for ; Wed, 7 Mar 2001 02:53:16 GMT Received: from zrtps06u.us.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) id QQkfgl19754 for ; Wed, 7 Mar 2001 02:53:16 GMT Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f272q8l17073 for ; Tue, 6 Mar 2001 21:52:08 -0500 (EST) Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Tue, 6 Mar 2001 20:52:50 -0600 Received: from zsc4c004.us.nortel.com ([47.81.138.49]) by zsc4c000.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GLW7NVQ4; Tue, 6 Mar 2001 18:52:48 -0800 Received: from tsenevir-2 (archt29c.us.nortel.com [47.134.242.149]) by zsc4c004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1AMWNZXX; Tue, 6 Mar 2001 18:52:46 -0800 Message-Id: <3.0.32.20010306184632.00c603e0@Zsc4c004.us.nortel.com> X-Sender: tsenevir@Zsc4c004.us.nortel.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 06 Mar 2001 18:46:33 -0800 To: chengguangdong , mpls X-Sybari-Space: 00000000 00000000 00000000 From: "Tissa Senevirathne" Subject: Re: How to integrate MPLS and IPSec in IP VPN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk You are bringing up an very appropriate point. The moment you start discussing many-to-many inter-connections, no longer IPSec unicast is applicable. True you can have seperate SA for each site, but that is not going to scale. What you really neeed is Group SA that is being worked out at multicast security working group. I am going to speak on this exact topic in the upcoming IETF (if I am given an oppertunity). Most importantly if you require protocol agnostic VPN services, IPSec is no longer applicabale We havve published some work related to Secure MPLS, may be that helps for now if you need encryption of MPLS payloads. (http://www.mplsrc.com/drafts.shtml - see under secure MPLS) Coupled this with Group SA provides an answer to your problem. Which I am sure many would come across very soon Let me know if you need any further information Thanks Tissa 408-565-2571 At 05:23 PM 3/6/01 +0800, chengguangdong wrote: >Hi All, >Our customer want to build VPN based MPLS but he needs the traffic must be encrypted before they go to PE routers. In order to provide confidentiality and any to any connection, the CE routers must be IPSec full meshed , this would be nightmare for a VPN with hundreds CE routers and conflicts with the advantage of MPLS VPN----simple provisioning. >So what are the solutions. I will be very appreciated if I can get your answer. > >Best Regards, >Cheng Guang Dong > > From owner-mpls@UU.NET Tue Mar 6 23:48:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11590 for ; Tue, 6 Mar 2001 23:48:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfgt06280; Wed, 7 Mar 2001 04:47:15 GMT Received: by mail-control.mail.uu.net id QQkfgt17245 for mpls-outgoing; Wed, 7 Mar 2001 04:46:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfgt17240 for ; Wed, 7 Mar 2001 04:46:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfgt09454 for ; Wed, 7 Mar 2001 04:46:28 GMT Received: from satoru.prism by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.128.193]) id QQkfgt09315 for ; Wed, 7 Mar 2001 04:46:27 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.1/8.11.1) with ESMTP id f274iOX00542; Wed, 7 Mar 2001 13:44:24 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: neil.2.harrison@bt.com Cc: satoru@japan-telecom.co.jp, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: New TTL Draft In-Reply-To: References: X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010307134424O.satoru@japan-telecom.co.jp> Date: Wed, 07 Mar 2001 13:44:24 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 99 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, Thanks for your comments, and please see my comments in line. From: neil.2.harrison@bt.com Subject: RE: New TTL Draft Date: Tue, 6 Mar 2001 09:44:39 -0000 > Satoru/Shahram.....trying catch up on the mail backlog I have just got round > to reading this. My take: > > 1 I agree with the '1-hop' concept in here since it is architecturally > correct. That is, if one creates a trail at layer N say, then each link > connection in that trail (ie between 2 adjacent nodes at layer N) is created > by a server trail at layer N-1. This process recurses for the layer N-1 > trail and so on to the duct. In other words, a trail at layer N has no > visibiluty, and indeed should not have visibility, of all the constituent > server layers (which may also be different technologies) that lie underneath > it. Hence, from a client layer perspective a link connection can never be > anything but a single hop, and the TTL setting of each trail should be an > independent consideration. Thanks, I agree too. I think we need to more carefully describe TTL processing on layerd(hierarchical) environment. > 2 Wrt to detecting defects that can affect LSPs please check out the > ID that was just posted (by Shahram) on MPLS OAM. Note that this is aimed > at explicitly routed pt-pt LSPs and not plain LDP LSPs. > http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt > I hope you find this of some value. I have just read your draft. I think this OAM method should be have each LSR to detect LSP defect. Is it right? Our "KeepAlive" does not depend on particular method. It depend on "1-hop" method and IP as compared with OAM.(Is it CCAMP charter?) And OAM has some useful function.(FDI,BDI,P) But I think all of the MPLS signalling depend on IP, so "KeepAlive" does not cause more problem(ie interoperability issue). Regards, -- Satoru Matsushima > > -----Original Message----- > > From: S.Matsushima [mailto:satoru@japan-telecom.co.jp] > > Sent: 28 February 2001 12:56 > > To: Shahram_Davari@pmc-sierra.com > > Cc: puneet@pluris.com; eric.gray@sandburst.com; mpls@UU.NET; > > flefauch@cisco.com; liwwu@cisco.com; bsd@cisco.com; akyol@pluris.com > > Subject: RE: New TTL Draft > > > > > > Shahram, > > > > This is Satoru Matsushima. > > > > > Hi All, > > > > > > Interestingly a similar draft was posted today: > > > > > > > > http://www.ietf.org/internet-drafts/draft-satoru-mpls-1hop-lsp-00.txt > > > > Thanks,:-) > > Actually, this draft consist of three elements: > > > > - TTL Processing expansion. > > - Label distribution method for 1-hop LSP. > > - The possible to "LSP KeepAlive" using 1-hop LSP. > > > > So, this draft was not only TTL processing, and it was stated about > > for using 1-hop LSP. Because, I had to describe these elements when I > > tried to write about realizing 1-hop LSP in this draft. > > > > I think Puneet's draft(and after discussion in ML) described very well > > TTL procesing for hierarchical LSP, but the 1-hop LSP(Pipe model LSP) > > is not a thing only for Diff-Serv. It is very usefull for MPLS/VPN > > operators. (I'm a MPLS/VPN operator.;-) > > Therefore, I think TTL processing expansion should be described more > > generally and be careful in label distribution mode; DU or DoD. > > (we call "Cloud model" and "Per LSP model") > > > > "LSP KeepAlive" ability is extremely important for the applications > > which use LSP but cannnot know the state of LSP itself(for instance, > > BGP/MPLS VPNs). > > I described a method of "LSP KeepAlive" using 1-hop LSP in this draft. > > How do you think about this? > > > > > > regards, > > > > -- > > Satoru Matsushima > > From owner-mpls@UU.NET Wed Mar 7 04:36:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28629 for ; Wed, 7 Mar 2001 04:36:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfhm15835; Wed, 7 Mar 2001 09:35:47 GMT Received: by mail-control.mail.uu.net id QQkfhm20798 for mpls-outgoing; Wed, 7 Mar 2001 09:35:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfhm20792 for ; Wed, 7 Mar 2001 09:35:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfhm09329; Wed, 7 Mar 2001 09:35:02 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQkfhm16806; Wed, 7 Mar 2001 09:35:01 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA19119; Wed, 7 Mar 2001 10:34:53 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA26643; Wed, 7 Mar 2001 10:34:20 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Mar 2001 10:34:20 +0100 Message-ID: From: Hummel Heinrich To: "'Dirk Ooms'" , te-wg@UU.NET, mpls@UU.NET Subject: AW: new draft on multicast traffic engineering with mpls Date: Wed, 7 Mar 2001 10:34:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA28629 Dirk, in my draft-hummel-ppvpn-tunnel systems-00.txt I provide an algorithm for computing a minimal tree between n given nodes. It selects from the n*(n-1)/2 candidate routes between any two of the n nodes those n-1 routes which are shortest but which assure that all nodes are contiguously interconnected. A comparison with normal Dijkstra: Given: Network with 300 nodes and 550 links. 1 Root node and 99 leaf nodes. The Dijkstra tree (shortest path between root and any leaf ) uses 204 links. The minimal tree uses 160 links. I could imagine a multicast model, whereby a minimal skeleton tree is formed based on the early subscribers (rather than to have a "single point skeleton tree called RP" ) and where further JOIN requests build subtrees rooted at the (closest) leaf node of the initial skeleton tree. Heinrich > -----Urspr> üngliche Nachricht----- > Von: Dirk Ooms [SMTP:Dirk.Ooms@alcatel.be] > Gesendet am: Montag, 5. März 2001 16:05 > An: te-wg@UU.NET; mpls@UU.NET > Betreff: new draft on multicast traffic engineering with mpls > > FYI > > http://search.ietf.org/internet-drafts/draft-ooms-mpls-multicast-te-00.txt > > Abstract > > There are several reasons for operators to construct multicast trees > by another means than multicast routing protocols. This document > lists these reasons and describes 2 ways of building a multicast > traffic-engineered tree: root-initiated tree and leaf-initiated tree. > Finally it defines extensions to CR-LDP to support MPLS multicast > traffic engineering. > > > -- > Dirk Ooms mailto:dirk.ooms@alcatel.be > tel:+32 3 2404732 > Network Strategy Group (NSG) http://aww.alcatel.com/nsg > Alcatel http://www.alcatel.com From owner-mpls@UU.NET Wed Mar 7 04:59:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28793 for ; Wed, 7 Mar 2001 04:59:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfhn16730; Wed, 7 Mar 2001 09:59:21 GMT Received: by mail-control.mail.uu.net id QQkfhn22601 for mpls-outgoing; Wed, 7 Mar 2001 09:58:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfhn22596 for ; Wed, 7 Mar 2001 09:58:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfhn27840 for ; Wed, 7 Mar 2001 09:58:48 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQkfhn19300 for ; Wed, 7 Mar 2001 09:58:48 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA23111; Wed, 7 Mar 2001 10:58:44 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA06974; Wed, 7 Mar 2001 10:58:15 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Mar 2001 10:58:14 +0100 Message-ID: From: Hummel Heinrich To: "'Dirk Ooms'" , davidm@galileo.co.il Cc: "'mpls'" Subject: AW: MPLS Multicast - Forwarding Plane Date: Wed, 7 Mar 2001 10:58:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA28793 Because not every NHLFE, i.e. not every LSR, can support Multicast, I expressed my regrets some time ago not to have a "Multicast-Bit" in the label (nor in G-MPLS labels). Heinrich Hummel > -----Urspr> üngliche Nachricht----- > Von: Dirk Ooms [SMTP:Dirk.Ooms@alcatel.be] > Gesendet am: Montag, 12. Februar 2001 12:42 > An: davidm@galileo.co.il > Cc: 'mpls' > Betreff: Re: MPLS Multicast - Forwarding Plane > > David, > > Can you be more specific on the detail you are looking for? > > dirk > > David Melman wrote: > > > > RFC 3031 MPLS Architecture briefly mentions the forwarding plane processing in section 4.8. "MPLS and Multicast": > > > > "When a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label. If the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children." > > > > Is this addressed in any more detail in any other draft? > > > > Thanks, > > > > David > > -- From owner-mpls@UU.NET Wed Mar 7 05:07:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28852 for ; Wed, 7 Mar 2001 05:07:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfho19742; Wed, 7 Mar 2001 10:06:10 GMT Received: by mail-control.mail.uu.net id QQkfho07843 for mpls-outgoing; Wed, 7 Mar 2001 10:05:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfho07831 for ; Wed, 7 Mar 2001 10:05:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfho10265; Wed, 7 Mar 2001 10:04:18 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkfho26568; Wed, 7 Mar 2001 10:04:17 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f279uew06917; Wed, 7 Mar 2001 10:56:40 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A08.00369875; Wed, 7 Mar 2001 10:56:19 +0100 Message-ID: <3AA605C2.76BDE1C3@alcatel.be> Date: Wed, 07 Mar 2001 10:56:18 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Hummel Heinrich CC: te-wg@UU.NET, mpls@UU.NET Subject: Re: AW: new draft on multicast traffic engineering with mpls References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQkfho19742 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA28852 Heinrich, Indeed, plenty of bandwidth can be saved by constructing other than shortest-path trees. In my view the algorithm itself is not subject to standardization (as long as it is not executed in a distributed fashion), only the signaling to establish the trees is. Anyway I'll wait for the announcement of your draft to further comment. dirk Hummel Heinrich wrote: > > Dirk, > > in my draft-hummel-ppvpn-tunnel systems-00.txt I provide an algorithm for computing a minimal tree between n given nodes. > It selects from the n*(n-1)/2 candidate routes between any two of the n nodes those n-1 routes which are shortest but which > assure that all nodes are contiguously interconnected. > > A comparison with normal Dijkstra: > Given: Network with 300 nodes and 550 links. > 1 Root node and 99 leaf nodes. > The Dijkstra tree (shortest path between root and any leaf ) uses 204 links. > The minimal tree uses 160 links. > > I could imagine a multicast model, whereby a minimal skeleton tree is formed based on the early subscribers (rather than to have > a "single point skeleton tree called RP" ) and where further JOIN requests build subtrees rooted at the (closest) leaf node of the initial skeleton tree. > > Heinrich > > > -----Urspr> üngliche Nachricht----- > > Von: Dirk Ooms [SMTP:Dirk.Ooms@alcatel.be] > > Gesendet am: Montag, 5. März 2001 16:05 > > An: te-wg@UU.NET; mpls@UU.NET > > Betreff: new draft on multicast traffic engineering with mpls > > > > FYI > > > > http://search.ietf.org/internet-drafts/draft-ooms-mpls-multicast-te-00.txt > > > > Abstract > > > > There are several reasons for operators to construct multicast trees > > by another means than multicast routing protocols. This document > > lists these reasons and describes 2 ways of building a multicast > > traffic-engineered tree: root-initiated tree and leaf-initiated tree. > > Finally it defines extensions to CR-LDP to support MPLS multicast > > traffic engineering. > > > > > > -- > > Dirk Ooms mailto:dirk.ooms@alcatel.be > > tel:+32 3 2404732 > > Network Strategy Group (NSG) http://aww.alcatel.com/nsg > > Alcatel http://www.alcatel.com -- Dirk Ooms mailto:dirk.ooms@alcatel.be tel:+32 3 2404732 Network Strategy Group (NSG) http://aww.alcatel.com/nsg Alcatel http://www.alcatel.com From owner-mpls@UU.NET Wed Mar 7 05:41:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29094 for ; Wed, 7 Mar 2001 05:41:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfhq13572; Wed, 7 Mar 2001 10:41:15 GMT Received: by mail-control.mail.uu.net id QQkfhq10467 for mpls-outgoing; Wed, 7 Mar 2001 10:40:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfhq10462 for ; Wed, 7 Mar 2001 10:40:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfhq06884 for ; Wed, 7 Mar 2001 10:40:31 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkfhq12635 for ; Wed, 7 Mar 2001 10:40:30 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Wed, 7 Mar 2001 10:31:13 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 7 Mar 2001 10:29:40 -0000 Message-ID: To: satoru@japan-telecom.co.jp Cc: Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: New TTL Draft Date: Wed, 7 Mar 2001 10:29:30 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Satoru, Thanks for your response/observations....please see answers and further comments below: S.Matsushima [mailto:satoru@japan-telecom.co.jp] wrote on 07 March 2001 04:44: > > 1 I agree with the '1-hop' concept in here since it is > architecturally > > correct. That is, if one creates a trail at layer N say, > then each link > > connection in that trail (ie between 2 adjacent nodes at > layer N) is created > > by a server trail at layer N-1. This process recurses for > the layer N-1 > > trail and so on to the duct. In other words, a trail at > layer N has no > > visibility, and indeed should not have visibility, of all > the constituent > > server layers (which may also be different technologies) > that lie underneath > > it. Hence, from a client layer perspective a link > connection can never be > > anything but a single hop, and the TTL setting of each > trail should be an > > independent consideration. > > Thanks, I agree too. > I think we need to more carefully describe TTL processing on > layerd(hierarchical) environment. NH=> This is true. An obvious example of why virtualisation of lower layer topologies is important is the case of protection-switching/restoration. Here, the restored link connection at layer N say is still 1-hop (from the perspective of that layer), but the *new* trail (ie the new prot-switched LSP) at layer N-1 is likely to have a new number of hops (ie link connections) at layer N-1. There is no reason why the layer N LSP should be aware of this, and from a layered architectural perspective indeed it should not. > > > 2 Wrt to detecting defects that can affect LSPs please > check out the > > ID that was just posted (by Shahram) on MPLS OAM. Note > that this is aimed > > at explicitly routed pt-pt LSPs and not plain LDP LSPs. > > http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt > > I hope you find this of some value. > > I have just read your draft. I think this OAM method should be have > each LSR to detect LSP defect. Is it right? NH=> It depends on where the defect is originally sourced. If it comes from a layer network *below* the MPLS fabric (eg SDH) then the 1st LSR downstream of the server (SDH) failure will be informed of the server failure (by an FDI signal....AIS in SDH say) and so the defect will be detected, and propagated via server(SDH)->client(MPLS) adaptation, from that LSR upwards (into all affected LSPs in a recursive manner as explained in the draft). If however the defect is sourced from within the MPLS fabric (so this could be a simple break, mismerging, swapped LSPs..) then this will *only* be detected at the LSP trail termination point of the lowest LSP affected (by the appropriate aberration of the CV flow). LSRs *before* the LSP sink point of this lowest layer LSP will not detect such a defect......this is correct architectural behaviour. Obviously all higher client layer LSPs (of the lowest LSP affected) which span the failure will also be affected, and this is the point of why the FDI has to propagate upwards through the relevant server->client adaptation points (at LSP sinks) to stop alarm storms....which could be geographically/organisationally distant from the original failure point. > Our "KeepAlive" does not depend on particular method. It depend > on "1-hop" method and IP as compared with OAM.(Is it CCAMP charter?) NH=> I am not sure which WG should deal with this.....but OAM is an intrinsic function of any layer network technology that should be addressed by whoever is specifying that technology. The difference between our methods is that yours addresses LSP link connections (ie below MPLS fabric defects only) whereas our OAM work takes the trail perspective (ie between LSP source and sink) and also adds some extra defect handling and diagnostic capabilities....as indeed you note in the line directly below here: > And OAM has some useful function.(FDI,BDI,P) > > But I think all of the MPLS signalling depend on IP, so "KeepAlive" > does not cause more problem(ie interoperability issue). NH=> I see no interoperability issues either. From owner-mpls@UU.NET Wed Mar 7 07:49:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01742 for ; Wed, 7 Mar 2001 07:49:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfhz00754; Wed, 7 Mar 2001 12:48:49 GMT Received: by mail-control.mail.uu.net id QQkfhz18942 for mpls-outgoing; Wed, 7 Mar 2001 12:48:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfhz18931 for ; Wed, 7 Mar 2001 12:48:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfhz14729 for ; Wed, 7 Mar 2001 12:46:47 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfhz05934 for ; Wed, 7 Mar 2001 12:46:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA23585 for mpls@uu.net; Wed, 7 Mar 2001 07:46:42 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfhz18774 for ; Wed, 7 Mar 2001 12:46:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfhz00264 for ; Wed, 7 Mar 2001 12:45:57 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfhz04843 for ; Wed, 7 Mar 2001 12:45:57 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01330; Wed, 7 Mar 2001 07:45:56 -0500 (EST) Message-Id: <200103071245.HAA01330@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-crldp-unnum-01.txt Date: Wed, 07 Mar 2001 07:45:56 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Signalling Unnumbered Links in CR-LDP Author(s) : K. Kompella, Y. Rekhter, A. Kullberg Filename : draft-ietf-mpls-crldp-unnum-01.txt Pages : 7 Date : 06-Mar-01 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to CR-LDP, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-unnum-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-crldp-unnum-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-crldp-unnum-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: <20010306125747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crldp-unnum-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125747.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Mar 7 07:49:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01748 for ; Wed, 7 Mar 2001 07:49:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfhz08951; Wed, 7 Mar 2001 12:48:48 GMT Received: by mail-control.mail.uu.net id QQkfhz18937 for mpls-outgoing; Wed, 7 Mar 2001 12:48:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfhz18930 for ; Wed, 7 Mar 2001 12:48:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfhz16107 for ; Wed, 7 Mar 2001 12:47:21 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfhz01708 for ; Wed, 7 Mar 2001 12:47:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA23611 for mpls@uu.net; Wed, 7 Mar 2001 07:47:20 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfhz18882 for ; Wed, 7 Mar 2001 12:46:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfhz04231 for ; Wed, 7 Mar 2001 12:46:02 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfhz04967 for ; Wed, 7 Mar 2001 12:46:01 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01343; Wed, 7 Mar 2001 07:46:01 -0500 (EST) Message-Id: <200103071246.HAA01343@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-rsvp-unnum-01.txt Date: Wed, 07 Mar 2001 07:46:01 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Signalling Unnumbered Links in RSVP-TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-rsvp-unnum-01.txt Pages : 8 Date : 06-Mar-01 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to RSVP-TE, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-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-rsvp-unnum-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-rsvp-unnum-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: <20010306125757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-unnum-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125757.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Mar 7 07:52:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01898 for ; Wed, 7 Mar 2001 07:52:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfhz12842; Wed, 7 Mar 2001 12:51:22 GMT Received: by mail-control.mail.uu.net id QQkfhz19139 for mpls-outgoing; Wed, 7 Mar 2001 12:50:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfhz19077 for ; Wed, 7 Mar 2001 12:50:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfhz23471 for ; Wed, 7 Mar 2001 12:50:26 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfhz06245 for ; Wed, 7 Mar 2001 12:50:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA24030 for mpls@uu.net; Wed, 7 Mar 2001 07:50:25 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfhz18796 for ; Wed, 7 Mar 2001 12:46:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfhz12540 for ; Wed, 7 Mar 2001 12:45:53 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfhz04751 for ; Wed, 7 Mar 2001 12:45:53 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01318; Wed, 7 Mar 2001 07:45:52 -0500 (EST) Message-Id: <200103071245.HAA01318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lmp-02.txt Date: Wed, 07 Mar 2001 07:45:52 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Link Management Protocol (LMP) Author(s) : J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter, L. Berger, B. Rajagopalan, D. Basak, H. Sandick, A. Zinin, A. Banerjee Filename : draft-ietf-mpls-lmp-02.txt Pages : 58 Date : 06-Mar-01 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels, links, and bundled links. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage traffic engineering (TE) links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lmp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lmp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lmp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lmp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125738.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Mar 7 07:53:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01925 for ; Wed, 7 Mar 2001 07:53:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfhz14657; Wed, 7 Mar 2001 12:52:18 GMT Received: by mail-control.mail.uu.net id QQkfhz19327 for mpls-outgoing; Wed, 7 Mar 2001 12:51:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfhz19307 for ; Wed, 7 Mar 2001 12:51:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfhz11551 for ; Wed, 7 Mar 2001 12:51:06 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfhz07178 for ; Wed, 7 Mar 2001 12:51:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA24297 for mpls@uu.net; Wed, 7 Mar 2001 07:51:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfhz18884 for ; Wed, 7 Mar 2001 12:46:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfhz03727 for ; Wed, 7 Mar 2001 12:45:52 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfhz04677 for ; Wed, 7 Mar 2001 12:45:48 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01306; Wed, 7 Mar 2001 07:45:48 -0500 (EST) Message-Id: <200103071245.HAA01306@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-hierarchy-02.txt Date: Wed, 07 Mar 2001 07:45:48 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LSP Hierarchy with MPLS TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-lsp-hierarchy-02.txt Pages : 12 Date : 06-Mar-01 To improve scalability of MPLS TE it may be useful to aggregate TE LSPs. The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (advertising this LSP as a link into ISIS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-02.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-lsp-hierarchy-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-hierarchy-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125729.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Mar 7 08:31:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03376 for ; Wed, 7 Mar 2001 08:31:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfib08223; Wed, 7 Mar 2001 13:28:42 GMT Received: by mail-control.mail.uu.net id QQkfib06924 for mpls-outgoing; Wed, 7 Mar 2001 13:28:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfib06916 for ; Wed, 7 Mar 2001 13:28:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfib10667 for ; Wed, 7 Mar 2001 13:27:43 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkfib01039 for ; Wed, 7 Mar 2001 13:27: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 FAA09740 for ; Wed, 7 Mar 2001 05:27:46 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA03352 for mpls@uu.net; Wed, 7 Mar 2001 08:27:41 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfgr16047 for ; Wed, 7 Mar 2001 04:28:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfgr20064 for ; Wed, 7 Mar 2001 04:27:19 GMT Received: from smtp.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQkfgr11189 for ; Wed, 7 Mar 2001 04:27:17 GMT Received: from tom ([10.110.9.163]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G9T87E03.N14 for ; Wed, 7 Mar 2001 12:23:38 +0800 Message-ID: <001001c0a6be$f91565a0$a3096e0a@tom.huawei.com> From: "zhang" To: Subject: help for CR-LDP Date: Wed, 7 Mar 2001 12:27:50 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C0A702.06800400" 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_000D_01C0A702.06800400 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Dear Mr.(Mrs), Please help me for a question about algorithem of=20 selection of the next hop. In 4.8.1 selection of the next hop 2. If there is no second ER-HOP, this indicates the end of=20 the explicit route. The explicit route TLV should be removed=20 from the Label Request Message. This node may or may not=20 be the end of the LSP. Processing continues with section=20 4.8.2, where a new explicit route TLV may be added to the=20 Label Request Message. But why "This node may or may not be the end of the LSP."? Regards Zhang. =20 ------=_NextPart_000_000D_01C0A702.06800400 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Dear = Mr.(Mrs),
  = Please help me for a question=20 about algorithem of
selection of = the next hop.
  In = 4.8.1 selection of the next=20 hop
       2.=20 If there is no second ER-HOP, this indicates the end = of 
   = the explicit route. The=20 explicit route TLV should be removed 
   = from the Label Request=20 Message. This node may or may not 
   = be the end of the LSP.=20 Processing continues with section 
   = 4.8.2, where a new explicit=20 route TLV may be added to the 
   = Label Request=20 Message.
 
But why = "This node may or may not=20 be the end of the = LSP."?
 
Regards
Zhang.  
------=_NextPart_000_000D_01C0A702.06800400-- From owner-mpls@UU.NET Wed Mar 7 09:40:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05784 for ; Wed, 7 Mar 2001 09:40:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfig27186; Wed, 7 Mar 2001 14:37:14 GMT Received: by mail-control.mail.uu.net id QQkfig00855 for mpls-outgoing; Wed, 7 Mar 2001 14:36:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfig00847 for ; Wed, 7 Mar 2001 14:36:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfig05467 for ; Wed, 7 Mar 2001 14:36:43 GMT Received: from winstar.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-mail.winstar.com [207.86.108.156]) id QQkfig08878 for ; Wed, 7 Mar 2001 14:36:38 GMT Received: from vaaws032382 (VAAWS032382.winstar.com [10.1.183.46]) by winstar.com (8.9.3/8.9.1) with SMTP id JAA02243; Wed, 7 Mar 2001 09:36:31 -0500 (EST) Reply-To: From: "Yi Chu" To: Cc: Subject: questions on draft-martini-l2circuit-encap-mpls-01.txt Date: Wed, 7 Mar 2001 09:39:07 -0500 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.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Luca: I have some comments/questions regarding ATM in the draft. 1. Why AAL5 CPCS-PDU which contains padding? Why not CPCS-SDU with UU octet or with 4 bytes AAL5 trailer? It seems that the cell tax is what people do not like about ATM, and AAL5 padding is a major portion of the tax. 2. For the sake of consistency of the use of control word, in the cell mode when control word is used, is it better to specify T field of the flag to be set, and E,L and C field are not used and should be ignored? That way, an interface operating in cell mode receiving a packet with T not set should infer that it is encapsulated in frame mode and should discard the packet. 3. Can I infer that the mode (AAL5 vs. cell) is configured? Is it allowed to have frame mode in one direction and cell mode in the other? (purely academic and out of curiosity) Thanks. Yi Chu ychu@winstar.com From owner-mpls@UU.NET Wed Mar 7 12:13:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12456 for ; Wed, 7 Mar 2001 12:13:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfiq02919; Wed, 7 Mar 2001 17:09:31 GMT Received: by mail-control.mail.uu.net id QQkfiq12285 for mpls-outgoing; Wed, 7 Mar 2001 17:09:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfiq12183 for ; Wed, 7 Mar 2001 17:08:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfiq15253 for ; Wed, 7 Mar 2001 17:08:38 GMT From: djiang1@lucent.com Received: from auemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkfiq02440 for ; Wed, 7 Mar 2001 17:08:38 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA03575 for ; Wed, 7 Mar 2001 12:08:37 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA03556 for ; Wed, 7 Mar 2001 12:08:37 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA24691; Wed, 7 Mar 2001 12:08:25 -0500 (EST) Subject: MPLS over Ethernet To: mpls@UU.NET Date: Wed, 7 Mar 2001 12:04:28 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 03/07/2001 12:04:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Everyone, Would anyone please know whether there is any paper on MPLS over Ethernet? MPLS over PPPoE? Thanks in advance. Regards, Jane D. Jiang From owner-mpls@UU.NET Wed Mar 7 15:16:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21147 for ; Wed, 7 Mar 2001 15:16:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfjc19042; Wed, 7 Mar 2001 20:14:17 GMT Received: by mail-control.mail.uu.net id QQkfjc27054 for mpls-outgoing; Wed, 7 Mar 2001 20:13:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfjc27045 for ; Wed, 7 Mar 2001 20:13:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfjc10409 for ; Wed, 7 Mar 2001 20:12:43 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfjc08721 for ; Wed, 7 Mar 2001 20:12:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA04010 for mpls@uu.net; Wed, 7 Mar 2001 15:12:42 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfjc26827 for ; Wed, 7 Mar 2001 20:12:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfjc15691 for ; Wed, 7 Mar 2001 20:11:44 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkfjc11764 for ; Wed, 7 Mar 2001 20:11:43 GMT Received: (qmail 27142 invoked by uid 104); 7 Mar 2001 20:11:42 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.42131 secs); 07/03/2001 12:11:42 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 7 Mar 2001 20:11:41 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f27KBXZ19833; Wed, 7 Mar 2001 12:11:33 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <1R8BP69Q>; Wed, 7 Mar 2001 12:15:13 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AFC@BBY1EXM01> From: Shahram Davari To: "'Kireeti Kompella'" , mpls@UU.NET, vkompella@JasmineNetworks.com Subject: Unnumbered Interface I-D Date: Wed, 7 Mar 2001 12:15:12 -0800 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 Kireeti, > 2) Why have ingress and egress ids *all* the time? For the one > case of multiple multiaccess interfaces on a common subnet, > use two ERO subobjects. > How can you specify this case with two ERO subobjects? It seems that in your draft the unnumbered interface ID subobject that includes tuple [R, I], refers to interface "I" as an outgoing Interface on router "R". Yours, -Shahram From owner-mpls@UU.NET Wed Mar 7 18:16:38 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26364 for ; Wed, 7 Mar 2001 18:16:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfjo20165; Wed, 7 Mar 2001 23:14:00 GMT Received: by mail-control.mail.uu.net id QQkfjo04007 for mpls-outgoing; Wed, 7 Mar 2001 23:13:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfjo03996 for ; Wed, 7 Mar 2001 23:13:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfjo22340 for ; Wed, 7 Mar 2001 23:12:55 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfjo18714 for ; Wed, 7 Mar 2001 23:12:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA18847 for mpls@uu.net; Wed, 7 Mar 2001 18:12:54 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfjo03845 for ; Wed, 7 Mar 2001 23:12:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfjo28249 for ; Wed, 7 Mar 2001 23:11:37 GMT Received: from netmail2.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkfjo17077 for ; Wed, 7 Mar 2001 23:11:37 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA24598 for ; Wed, 7 Mar 2001 17:11:37 -0600 (CST) Received: from adn.alcatel.com ([198.205.41.68]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA1AC6; Wed, 7 Mar 2001 18:23:55 -0500 Message-ID: <3AA6C078.E74DB7A0@adn.alcatel.com> Date: Wed, 07 Mar 2001 18:12:56 -0500 From: "Rao Vadlamani" Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "mpls-ops@mplsrc.com" , "mpls@UU.NET" Subject: Questions on LSR-MIB Content-Type: multipart/mixed; boundary="------------97D4243D781B63A972689E46" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------97D4243D781B63A972689E46 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have a few questions on the latest draft 1) I did not understand the significance of the textual convention StorageType and usage of it for objects like mplsInterfaceConfStorageType etc., The description just says the the storage type for the entry. Could this be elaborated further ? 2) mplsIntefaceLabelParticipationType - The description is not clear esp., the last sentence, which says "If only the perPlatform(0) bit is set, then the value of mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for this entry must be identical to the instance of these objects with index 0." It is not clear. Could this be explained further ? Thanks Rao --------------97D4243D781B63A972689E46 Content-Type: text/x-vcard; charset=us-ascii; name="Rao.Vadlamani.vcf" Content-Description: Card for Rao Vadlamani Content-Disposition: attachment; filename="Rao.Vadlamani.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vadlamani;Rao tel;cell:(703)-282-7399 tel;fax:(703)-679-6450 tel;home:(703)-390-1174 tel;work:(703)-679-6430 x-mozilla-html:FALSE url:www.alcatel.com org:Alcatel USA version:2.1 email;internet:rao.vadlamani@adn.alcatel.com adr;quoted-printable:;;15036 Conference Center Drive=0D=0A=0D=0A=0D=0A;Chantilly;VA;20151;USA fn:Rao Vadlamani end:vcard --------------97D4243D781B63A972689E46-- From owner-mpls@UU.NET Wed Mar 7 18:43:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27569 for ; Wed, 7 Mar 2001 18:43:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfjq10823; Wed, 7 Mar 2001 23:41:58 GMT Received: by mail-control.mail.uu.net id QQkfjq07043 for mpls-outgoing; Wed, 7 Mar 2001 23:41:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfjq07010 for ; Wed, 7 Mar 2001 23:41:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfjq17987 for ; Wed, 7 Mar 2001 23:40:54 GMT Received: from china.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: TCE-E-7-182-15.bta.net.cn [202.106.182.15]) id QQkfjq06537 for ; Wed, 7 Mar 2001 23:40:51 GMT Received: from china.com([10.1.7.103]) by china.com(JetMail 2.5.3.0) with SMTP id jm93aa71e8c; Wed, 7 Mar 2001 23:40:34 -0000 Received: from cmr1.ash.ops.us.uu.net([198.5.241.39]) by china.com(JetMail 2.5.3.0) with SMTP id jma3aa1e8d0; Sun, 4 Mar 2001 05:39:51 -0000 Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkevu11907; Sun, 4 Mar 2001 05:39:39 GMT Received: by mail-control.mail.uu.net id QQkevu11184 for mpls-outgoing; Sun, 4 Mar 2001 05:38:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkevu11177 for ; Sun, 4 Mar 2001 05:38:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkevu11689 for ; Sun, 4 Mar 2001 05:37:08 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQkevu02123 for ; Sun, 4 Mar 2001 05:37:07 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id VAA14507; Sat, 3 Mar 2001 21:36:39 -0800 (PST) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id VAA29883; Sat, 3 Mar 2001 21:36:39 -0800 (PST) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs Date: Sat, 3 Mar 2001 21:36:38 -0800 (PST) From: Bora Akyol To: Francis Arts cc: akyol@pluris.com, puneet@pluris.com, mpls@UU.NET, Francois Le Faucheur , liwwu@cisco.com, Shahram Davari , Bruce Davie , pierre.debuysscher@alcatel.be, Marijke Coenen , finizoll@sh.bel.alcatel.be Subject: Re: Comments on draft-agarwal-mpls-ttl-00 In-Reply-To: <3AA0F214.D2A9CA47@alcatel.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Sat, 3 Mar 2001, Francis Arts wrote: > > Puneet, > > Please find included some comments to your draft > draft-agarwal-mpls-ttl-00. > > Kind regards, > > Francis. > > -------------- > > 1) Section 2.2. > > The text states that oTTL = iTTL -1 and that it is checked whether oTTL > is greater than 0. > > However, this does not cover the receipt of an (erroneous) MPLS packet > with a TTL of 0. In this case setting oTTL = iTTL - 1, would result in a > oTTL value different from 0. So the MPLS packet would still pass the > oTTL check while it should not have. > > Therefore, I propose to check the iTTL, rather than the oTTL: > * A check is done whether or not the iTTL value is strictly larger than > 1. This check on the iTTL value should only be done once it has been > determined that the packet is routed (as an IP or MPLS packet) to a next > node. Francis, I believe the text says to check for oTTL > 0/ > > > 2) Section 2.2. > > The text states that 'the oTTL check is performed only if an outgoing > TTL is set to oTTL'. > > However, this is inconsistent with the statement in section 2.4 - 3rd > bullet: "PHP case - The oTTL check should be performed irrespective of > whether the oTTL is used in any outgoing label / IP header". This will be fixed in the next version of the draft. > > > 3) Section 2.3. > > The text states that '... we are performing a push / swap / PHP, then > the iTTL is the TTL ...'. We put the word "push" there to clearly differentiate against the "POP" case. Even when you are pushing, you still need to determine the iTTL so that you can determine the TTL for the label that is being pushed. > > I propose to remove the 'push' since this is irrelevant for the incoming > TTL determination; the push is handled in section 2.4 (outgoing TTL > determination). > From owner-mpls@UU.NET Wed Mar 7 18:50:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27734 for ; Wed, 7 Mar 2001 18:50:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfjr19339; Wed, 7 Mar 2001 23:47:48 GMT Received: by mail-control.mail.uu.net id QQkfjr07963 for mpls-outgoing; Wed, 7 Mar 2001 23:47:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfjr07949 for ; Wed, 7 Mar 2001 23:46:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfjr14849 for ; Wed, 7 Mar 2001 23:46:34 GMT From: djiang1@lucent.com Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQkfjr03601 for ; Wed, 7 Mar 2001 23:46:34 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 SAA20386 for ; Wed, 7 Mar 2001 18:46:33 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA20380 for ; Wed, 7 Mar 2001 18:46:33 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA01867; Wed, 7 Mar 2001 18:46:32 -0500 (EST) Subject: MPLS over PPPoE, MPLS over Ethernet To: mpls@UU.NET Date: Wed, 7 Mar 2001 18:42:35 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 03/07/2001 18:42:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Everyone, Would anyone please know whether there is any paper on MPLS over Ethernet? MPLS over PPPoE? Thanks in advance. Regards, Jane D. Jiang From owner-mpls@UU.NET Wed Mar 7 21:13:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00007 for ; Wed, 7 Mar 2001 21:13:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfka19170; Thu, 8 Mar 2001 02:12:07 GMT Received: by mail-control.mail.uu.net id QQkfka05444 for mpls-outgoing; Thu, 8 Mar 2001 02:11:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfka05438 for ; Thu, 8 Mar 2001 02:11:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfka12879 for ; Thu, 8 Mar 2001 02:11:38 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkfka09800 for ; Thu, 8 Mar 2001 02:11:38 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id SAA13613; Wed, 7 Mar 2001 18:11:36 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id SAA14321; Wed, 7 Mar 2001 18:11:36 -0800 (PST) Date: Wed, 7 Mar 2001 18:11:36 -0800 (PST) From: Kireeti Kompella Message-Id: <200103080211.SAA14321@kummer.juniper.net> To: kireeti@juniper.net, mpls@UU.NET, Shahram_Davari@pmc-sierra.com, vkompella@JasmineNetworks.com Subject: Re: Unnumbered Interface I-D In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6AFC@BBY1EXM01> Sender: owner-mpls@UU.NET Precedence: bulk Unnumbered interfaces are by definition point-to-point. Bora's example doesn't apply. Kireeti. From owner-mpls@UU.NET Wed Mar 7 22:39:06 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02681 for ; Wed, 7 Mar 2001 22:39:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfkg20963; Thu, 8 Mar 2001 03:38:11 GMT Received: by mail-control.mail.uu.net id QQkfkg26878 for mpls-outgoing; Thu, 8 Mar 2001 03:37:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfkg26870 for ; Thu, 8 Mar 2001 03:37:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfkg28707 for ; Thu, 8 Mar 2001 03:36:33 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfkg17663 for ; Thu, 8 Mar 2001 03:36:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA05481 for mpls@uu.net; Wed, 7 Mar 2001 22:36:31 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfkg26706 for ; Thu, 8 Mar 2001 03:36:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfkg00419 for ; Thu, 8 Mar 2001 03:35:58 GMT Received: from baynet.baynetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQkfkg16495 for ; Thu, 8 Mar 2001 03:35:56 GMT Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id TAA07468; Wed, 7 Mar 2001 19:34:02 -0800 (PST) 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 WAA12188; Wed, 7 Mar 2001 22:35:46 -0500 (EST) Received: from nortelnetworks.com (asc4t23q.us.nortel.com [47.81.7.215]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id WAA08637; Wed, 7 Mar 2001 22:35:44 -0500 for Message-ID: <3AA6FF87.6645F490@nortelnetworks.com> Date: Wed, 07 Mar 2001 22:41:59 -0500 From: Shobhan Lakkapragada X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: djiang1@lucent.com CC: mpls@UU.NET Subject: Re: MPLS over PPPoE, MPLS over Ethernet References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Please see RFC 3032, "MPLS Label Stack Encoding". It contains procedures for MPLS over LAN media and MPLS over PPP. - shobhan djiang1@lucent.com wrote: > Hi Everyone, > > Would anyone please know whether there is any paper on MPLS over Ethernet? > MPLS over PPPoE? > > Thanks in advance. > > Regards, > Jane D. Jiang From owner-mpls@UU.NET Wed Mar 7 23:37:32 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03712 for ; Wed, 7 Mar 2001 23:37:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfkk12379; Thu, 8 Mar 2001 04:36:53 GMT Received: by mail-control.mail.uu.net id QQkfkk02414 for mpls-outgoing; Thu, 8 Mar 2001 04:36:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfkk02405 for ; Thu, 8 Mar 2001 04:36:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfkk20571 for ; Thu, 8 Mar 2001 04:34:51 GMT From: ytr@123india.com Received: from c001.zsm.cp.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: c001-h000.c001.zsm.cp.net [209.228.56.114]) id QQkfkk07481 for ; Thu, 8 Mar 2001 04:34:50 GMT Received: (cpmta 1845 invoked from network); 7 Mar 2001 20:34:50 -0800 Date: 7 Mar 2001 20:34:49 -0800 Message-ID: <20010308043449.1844.cpmta@c001.zsm.cp.net> X-Sent: 8 Mar 2001 04:34:49 GMT Received: from [132.233.247.7] by mail.123india.com with HTTP; 07 Mar 2001 20:34:49 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: djiang1@lucent.com Cc: mpls@UU.NET X-Mailer: Web Mail 3.9.0.19 Subject: Re: MPLS over PPPoE, MPLS over Ethernet Sender: owner-mpls@UU.NET Precedence: bulk Hi, pls refer RFC3032 for more details about MPLS over etherner and rest of the stuff. Regards, YTR On Wed, 07 March 2001, djiang1@lucent.com wrote: > > Hi Everyone, > > Would anyone please know whether there is any paper on MPLS over Ethernet? > MPLS over PPPoE? > > Thanks in advance. > > Regards, > Jane D. Jiang ______________________________________________________ 123India.com - India's Premier Portal Get your Free Email Account at http://www.123india.com From owner-mpls@UU.NET Thu Mar 8 06:59:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22743 for ; Thu, 8 Mar 2001 06:59:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfln04682; Thu, 8 Mar 2001 11:59:04 GMT Received: by mail-control.mail.uu.net id QQkfln19551 for mpls-outgoing; Thu, 8 Mar 2001 11:58:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfln19546 for ; Thu, 8 Mar 2001 11:58:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfln28872 for ; Thu, 8 Mar 2001 11:58:09 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfln03792 for ; Thu, 8 Mar 2001 11:58:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA26764 for mpls@uu.net; Thu, 8 Mar 2001 06:58:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfln19504 for ; Thu, 8 Mar 2001 11:57:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfln02364 for ; Thu, 8 Mar 2001 11:57:13 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfln02694 for ; Thu, 8 Mar 2001 11:57:13 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22358; Thu, 8 Mar 2001 06:57:12 -0500 (EST) Message-Id: <200103081157.GAA22358@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-generalized-signaling-02.txt Date: Thu, 08 Mar 2001 06:57:12 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS - Signaling Functional Description Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-signaling-02.txt Pages : 32 Date : 07-Mar-01 This document describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-02.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-generalized-signaling-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010307142730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-signaling-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307142730.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Mar 8 07:01:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22791 for ; Thu, 8 Mar 2001 07:01:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkflo07967; Thu, 8 Mar 2001 12:00:01 GMT Received: by mail-control.mail.uu.net id QQkfln19567 for mpls-outgoing; Thu, 8 Mar 2001 11:59:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfln19557 for ; Thu, 8 Mar 2001 11:59:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfln00271 for ; Thu, 8 Mar 2001 11:58:36 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfln10826 for ; Thu, 8 Mar 2001 11:58:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA26790 for mpls@uu.net; Thu, 8 Mar 2001 06:58:35 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfln19522 for ; Thu, 8 Mar 2001 11:58:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfln26464 for ; Thu, 8 Mar 2001 11:57:22 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfln02880 for ; Thu, 8 Mar 2001 11:57:22 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22382; Thu, 8 Mar 2001 06:57:21 -0500 (EST) Message-Id: <200103081157.GAA22382@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-generalized-rsvp-te-01.txt Date: Thu, 08 Mar 2001 06:57:21 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS Signaling - RSVP-TE Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-rsvp-te-01.txt Pages : 22 Date : 07-Mar-01 This document describes extensions to RSVP-TE signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents an RSVP-TE specific description of the extensions. A CR-LDP specific description can be found in [GMPLS-LDP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-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-generalized-rsvp-te-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-generalized-rsvp-te-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: <20010307142749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-rsvp-te-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307142749.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Mar 8 07:01:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22802 for ; Thu, 8 Mar 2001 07:01:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfln12268; Thu, 8 Mar 2001 11:59:37 GMT Received: by mail-control.mail.uu.net id QQkfln19562 for mpls-outgoing; Thu, 8 Mar 2001 11:59:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfln19555 for ; Thu, 8 Mar 2001 11:59:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfln01241 for ; Thu, 8 Mar 2001 11:58:54 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfln11236 for ; Thu, 8 Mar 2001 11:58:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA26763 for mpls@uu.net; Thu, 8 Mar 2001 06:58:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfln19511 for ; Thu, 8 Mar 2001 11:57:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfln02607 for ; Thu, 8 Mar 2001 11:57:18 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfln02784 for ; Thu, 8 Mar 2001 11:57:18 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22370; Thu, 8 Mar 2001 06:57:17 -0500 (EST) Message-Id: <200103081157.GAA22370@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-generalized-cr-ldp-01.txt Date: Thu, 08 Mar 2001 06:57:17 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS Signaling - CR-LDP Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-cr-ldp-01.txt Pages : 16 Date : 07-Mar-01 This document describes extensions to CR-LDP signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. An RSVP-TE specific description can be found in [GMPLS- RSVP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-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-generalized-cr-ldp-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-generalized-cr-ldp-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: <20010307142739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-cr-ldp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307142739.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Mar 8 07:06:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22938 for ; Thu, 8 Mar 2001 07:06:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkflo23188; Thu, 8 Mar 2001 12:05:31 GMT Received: by mail-control.mail.uu.net id QQkflo05436 for mpls-outgoing; Thu, 8 Mar 2001 12:05:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkflo05420 for ; Thu, 8 Mar 2001 12:05:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkflo19324 for ; Thu, 8 Mar 2001 12:04:43 GMT Received: from penguin-ext.wise.edt.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: penguin-ext.wise.edt.ericsson.se [194.237.142.110]) id QQkflo20805 for ; Thu, 8 Mar 2001 12:04:42 GMT Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f28C4ed08424 for ; Thu, 8 Mar 2001 13:04:40 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Mar 08 13:04:40 2001 +0100 Received: by esealnt747.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Mar 2001 13:04:41 +0100 Message-ID: <7BA41B5547CCD411833B0002A52CD457024EBDF1@enlrynt306.etm.ericsson.se> From: "Christophe Bouhier (ETM)" To: nbvpn@bbo.com, "'mpls@uu.net'" Subject: CE or PE initiated VPN connectivity Date: Thu, 8 Mar 2001 13:04:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A7C7.F2373A10" 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_01C0A7C7.F2373A10 Content-Type: text/plain; charset="iso-8859-1" Hi All, Is there any work being done on CE or PE initiated VPN connectivity? Currently connections are solved using network provisioning tools (running the CLI or XML) to provision a PE-CE link in a VRF. I can imagine, that the VPN connection can be signalled by the CE using e.g. RSVP/or CR-LDP. This could be used to setup LSP's between the CE and PE for multiple VPN subscriptions. This would also solve e.g. simulteanous use of a VPN service and internet access (without NAT) on the PE. LSP end-point on the CE would have different IP addresses (private & public) solving multiple connections on the CE and not on the PE. Thanks , Christophe Bouhier ------_=_NextPart_000_01C0A7C7.F2373A10 Content-Type: application/octet-stream; name="Christophe Bouhier (ETM).vcf" Content-Disposition: attachment; filename="Christophe Bouhier (ETM).vcf" BEGIN:VCARD VERSION:2.1 N:Bouhier;Christophe FN:Christophe Bouhier (ETM) ORG:ETM;ETM/BL/YD TITLE:Product Manager IP NOTE:Datacom / IP program TEL;WORK;VOICE:+31 161 246271 TEL;WORK;VOICE:834 6271 TEL;CELL;VOICE:+31 6 53264027 ADR;WORK:;RY/ETM;Ericssonstraat 2;Rijen;;5121 ML;Netherlands LABEL;WORK;ENCODING=QUOTED-PRINTABLE:RY/ETM=0D=0AEricssonstraat 2=0D=0ARijen 5121 ML=0D=0ANetherlands EMAIL;PREF;INTERNET:Christophe.Bouhier@etm.ericsson.se REV:20001103T081750Z END:VCARD ------_=_NextPart_000_01C0A7C7.F2373A10-- From owner-mpls@UU.NET Thu Mar 8 08:21:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25243 for ; Thu, 8 Mar 2001 08:21:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkflt10921; Thu, 8 Mar 2001 13:20:10 GMT Received: by mail-control.mail.uu.net id QQkflt26564 for mpls-outgoing; Thu, 8 Mar 2001 13:19:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkflt26557 for ; Thu, 8 Mar 2001 13:19:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkflt24585 for ; Thu, 8 Mar 2001 13:19:04 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkflt07859 for ; Thu, 8 Mar 2001 13:19:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA03760 for mpls@uu.net; Thu, 8 Mar 2001 08:19:03 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkflt26528 for ; Thu, 8 Mar 2001 13:18:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkflt22727 for ; Thu, 8 Mar 2001 13:18:17 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkflt05364 for ; Thu, 8 Mar 2001 13:18:10 GMT Received: from flefauch-8kcdt.cisco.com (dhcp-nic-val-26-100.cisco.com [64.103.26.100]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA01888; Thu, 8 Mar 2001 14:18:06 +0100 (MET) Message-Id: <4.0.2.20010308133706.021b33c0@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 08 Mar 2001 14:07:16 +0100 To: mpls@UU.NET From: Francois Le Faucheur Subject: Re: WG Last call Cc: swallow@cisco.com, flefauch@europe.cisco.com In-Reply-To: <200103022226.RAA24233@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 17:26 02/03/2001 -0500, George Swallow wrote: >This message begins a last call on > > draft-ietf-mpls-diff-ext-08.txt > >The last call closes March 16, midnite GMT. > Hello, Below is the list of changes over version 07 to facilitate review. Please remember that this Last Call is not for the whole specification. It is focused on the resolution of the comments from the "special Diff-Serv WG Last Call" that was issued on at the request of the Area Directors. Cheers Francois * L-LSPs EXP<-->PHB mapping ========================= >We plan to incorporate Jim Murphy's suggestion to modify the EXP value >corresponding to AFn3 L-LSPs. AFn3 would be mapped to EXP=011 (instead of >010). >For memory, the rationale is that implementations which support only two >drop priorities per AF class could determine the drop priority to be >applied by looking at a single bit. Same idea was used for the DSCP >encodings for AF. > >The EXP value will be changed accordingly in sections 4.2.1 (in the >example), 4.2.1.1 (in the mapping table), 4.4.1 (in the example), 4.4.1.1 >(in the mapping table). done as described above * Incoming PHB Determination with Pipe Model =========================================== >We received pretty much the same comment from several people (Service >Providers as well as vendors) on one detailed aspect of the Pipe model: >output scheduling at egress of a Pipe LSP. >"xx-07.txt" specifies that, in the Pipe model, the egress LSR does incoming >PHB determination based on the "inner header" (ie after the POP). We plan to: > - keep such a behavior, but make it an optional variation of the Pipe model > - define an alternative behavior where the egress LSR does incoming PHB >determination based on the "outer header" (ie before the POP). This will be >the normal egress behavior for the Pipe Model. >All the other aspects of the Pipe model are unchanged. > >The rationale for using "outer header" by default on egress of Pipe is the >following: > - the typical application of the Pipe model is where a Service Provider >(SP) transports traffic from a customer who uses a different Diff-Serv >policy to the SP's Diff-Serv policy. Doing scheduling on LSP Egress based >on the outer header (and assuming no PHP) allows the Service Provider to >configure scheduling based on its own Diff-Serv policy. Doing scheduling >based on the inner header forces the Service Provider to be aware of each >and every customer Diff-Serv policy and forces the SP to configure >scheduling differently for each customer Diff-Serv policy. The most common >situation will be that the SP does not want to be even aware of the >Customer Diff-Serv policy and thus need to use the outer header. >(There will be cases where the SP may accept the operational overhead of >being aware of the customer's Diff-Serv policy and sell "egress scheduling >based on customer's policy" as a value add; this is why we keep the use of >inner header as an option. But this will be less common.) > - again, use of inner header means that scheduling is based on customer >Diff-SErv policy, which can be different for each egress port. For router >platforms using some form of input queueing, this translates in additional >sophistication since the input queueing must then be made aware of the >Diff-Serv policy of every customer connected to an egress port (unless >input queueing is performed on outer header even if egress scheduling is >based on inner header, but that means performing classification twice: once >on input and once on output). While this is implementable, it is >undesirable to mandate such sophistication/cost as part of the mandatory >Pipe mode. > - use of outer header and use of inner header are both allowed in RFC2983 >(from which the Uniform and Pipe models are inherited). > >This will result in corresponding text changes in section 2.6.2. > done as described above: text changes in 2.6.2 and addition of section 2.6.2.1 added mention of "Short Pipe" when listing all tunneling modes in last paragraph of 2.6.3 added mention of "Short Pipe" when listing all tunneling modes in first paragraph of 2.6.4 collapsing of the last paragraphs of 2.6.4 into a single paragraph applicable to all modes. * Miscellaneaous ================ Updates of references. Consistent use of "Label Forwarding" instead of "Label Swapping" in section 2 . ... From owner-mpls@UU.NET Thu Mar 8 08:22:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25312 for ; Thu, 8 Mar 2001 08:22:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkflt13063; Thu, 8 Mar 2001 13:21:27 GMT Received: by mail-control.mail.uu.net id QQkflt26693 for mpls-outgoing; Thu, 8 Mar 2001 13:21:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkflt26667 for ; Thu, 8 Mar 2001 13:21:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkflt20123 for ; Thu, 8 Mar 2001 13:21:02 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkflt13494 for ; Thu, 8 Mar 2001 13:21:01 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA03930 for mpls@uu.net; Thu, 8 Mar 2001 08:21:00 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkflt26597 for ; Thu, 8 Mar 2001 13:20:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkflt08610 for ; Thu, 8 Mar 2001 13:18:53 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkflt07161 for ; Thu, 8 Mar 2001 13:18:49 GMT Received: from flefauch-8kcdt.cisco.com (dhcp-nic-val-26-100.cisco.com [64.103.26.100]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA01866; Thu, 8 Mar 2001 14:18:02 +0100 (MET) Message-Id: <4.0.2.20010308132046.021be450@europe.cisco.com> Message-Id: <4.0.2.20010308132046.021be450@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 08 Mar 2001 13:36:39 +0100 To: David Charlap , lberger@movaz.com, swallow@cisco.com From: Francois Le Faucheur Subject: Re: WG Last call : Comment on COS service and TSPEC Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk David , George, Lou, At 19:00 02/03/2001 -0500, David Charlap wrote: >------------ > >The second problem involves the use of this draft in conjunction with >the latest changes to RSVP-TE (version -08). Version -08 eleimates the >COS service type from the TSPEC and FLOWSPEC objects. > >The DS draft requires that COS-type objects be used in order to signal >an L-LSP without bandwidth reservations. With the current revisions of >these two drafts, this type of LSP can not be signalled at all. It >effectively makes it impossible to use RSVP-TE to signal a best-effort >LSP (either E-LSP or L-LSP) > >Either the COS-type TSpec must be put back in RSVP-TE, or the DS draft >must be updated to provide a means for singalling a best-effort LSP. > >------------- > >A third problem involves the fact that the SENDER_TSPEC is now optional >in a Path message. This means that routers conforming to this spec will >be generating messages that non-DS-capable routers will be forced to >reject. The RSVP-TE draft still states that SENDER_TSPEC is a mandatory >object. > >There is no mention of whether a FLOWSPEC is optional in Resv messages. >If the COS C-Type is eliminated, then FLOWSPEC must become optional, if >a best-effort LSP is possible, since presence of an IntServ FLOWSPEC >will indicate a bandwidth reservation. > >This will create a similar incompatibility as with the absence of >SENDER_TSPEC in Path messages. > >It seems to me that routers implementing this draft will be unable to >interoperate with routers that do not implement it. IMO, this is >unacceptible. > >-- David > Based on the clarifications from George and Lou, I propose the following resolution for David's two comments above: * generally, "diff-ext" will be updated to simply align to the RSVP-TE draft with respect to signaling LSPs without bandwidth reservation. "diff-ext" will refer to RSVP-TE for details of how Null-Service/TSSPEC are used to signal LSP without bandwidth reservation. * section 5.6 will be updated to reflect use of "Null-service" instead of "COS service". * section 5.6 can probably be shortened (because parts of it came about simply because of the confusion that stemmed from the "COS service" and its associated COS field. I believe some of that confusion naturally goes away with the use of Null-Service). * TSPEC will be made mandatory (in line with RSVP-TE-08) Any comments/issues with this resolution? cheers Francois PS: David, thanks a lot for catching this. From owner-mpls@UU.NET Thu Mar 8 08:48:01 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26186 for ; Thu, 8 Mar 2001 08:48:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkflv02737; Thu, 8 Mar 2001 13:46:59 GMT Received: by mail-control.mail.uu.net id QQkflv29284 for mpls-outgoing; Thu, 8 Mar 2001 13:46:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkflv29208 for ; Thu, 8 Mar 2001 13:45:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkflv08276 for ; Thu, 8 Mar 2001 13:45:15 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQkflv22735 for ; Thu, 8 Mar 2001 13:45:14 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 OAA10174; Thu, 8 Mar 2001 14:45:09 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA14823; Thu, 8 Mar 2001 14:44:34 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Mar 2001 14:44:33 +0100 Message-ID: From: Hummel Heinrich To: "'Christophe Bouhier (ETM)'" , nbvpn@bbo.com, "'mpls@uu.net'" Subject: AW: CE or PE initiated VPN connectivity Date: Thu, 8 Mar 2001 14:44:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA26186 VPNs: provider provisioned versus customer-based, PE-to-PE LSPs established by the SP, CE-to-CE LSPs established by the customer without informing the SP about its purpose, CE-to-CE LSPs initiated/ordered by the customer but done by involving the SP (i.e. its PEs) There are all kind of flavors and there should be a market for all of them and even for mixes of them: E.g. some CEs are capable to install an LSP towards the right remote CE all by themselves, while others are not but need the help of the PE (as a proxy ?). Some tunnels are MPLS while others are not. Some are ordered at this SP, while others are ordered at another SP, but altogether should form a contiguous tunnel system. Furthermore: IPSEC tunnel over MPLS tunnel. There are certainly even more aspects and combinations. I like this discussion. It unveils the wide range of issues. IMHO, so far we all have been focussed too much on whether there should be a "VRF" or a"VR". Heinrich > -----Urspr> üngliche Nachricht----- > Von: Christophe Bouhier (ETM) [SMTP:Christophe.Bouhier@etm.ericsson.se] > Gesendet am: Donnerstag, 8. März 2001 13:05 > An: nbvpn@bbo.com; 'mpls@uu.net' > Betreff: CE or PE initiated VPN connectivity > > Hi All, > > Is there any work being done on CE or PE initiated VPN connectivity? > > Currently connections are solved using network provisioning tools (running the CLI > or XML) to provision a PE-CE link in a VRF. I can imagine, that the VPN connection can be signalled > by the CE using e.g. RSVP/or CR-LDP. This could be used to setup LSP's between the CE and PE for > multiple VPN subscriptions. This would also solve e.g. simulteanous use of a VPN service and > internet access (without NAT) on the PE. LSP end-point on the CE would have different IP addresses > (private & public) solving multiple connections on the CE and not on the PE. > > Thanks , Christophe Bouhier > > << Datei: Christophe Bouhier (ETM).vcf >> From owner-mpls@UU.NET Thu Mar 8 09:39:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27787 for ; Thu, 8 Mar 2001 09:39:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfly29102; Thu, 8 Mar 2001 14:37:22 GMT Received: by mail-control.mail.uu.net id QQkfly19178 for mpls-outgoing; Thu, 8 Mar 2001 14:37:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfly19164 for ; Thu, 8 Mar 2001 14:36:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfly10528 for ; Thu, 8 Mar 2001 14:36:25 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkfly27734 for ; Thu, 8 Mar 2001 14:36:25 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 122D494009; Thu, 8 Mar 2001 09:36:20 -0500 (EST) Message-ID: <3AA798E4.A5D67E86@sandburst.com> Date: Thu, 08 Mar 2001 09:36:20 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: zhang Cc: mpls@UU.NET Subject: Re: help for CR-LDP References: <001001c0a6be$f91565a0$a3096e0a@tom.huawei.com> Content-Type: multipart/alternative; boundary="------------B2947F683CE3CDC940D9A187" Sender: owner-mpls@UU.NET Precedence: bulk --------------B2947F683CE3CDC940D9A187 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhang, You use an Explicit Route to designate nodes you want included in an LSP. That's all. Practical uses of the ERO currently tend to include the egress from an MPLS domain, but there may be TE applications (for example) that benefit from the increased dynamism of having an ERO that only specifies some hop toward the middle of the MPLS cloud. -- Eric Gray You wrote: > Dear Mr.(Mrs), Please help me for a question about algorithem > ofselection of the next hop. In 4.8.1 selection of the next hop > 2. If there is no second ER-HOP, this indicates the end of the > explicit route. The explicit route TLV should be removed from the > Label Request Message. This node may or may not be the end of the > LSP. Processing continues with section 4.8.2, where a new explicit > route TLV may be added to the Label Request Message. But why "This > node may or may not be the end of the LSP."? RegardsZhang. --------------B2947F683CE3CDC940D9A187 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Zhang,

    You use an Explicit Route to designate nodes you want
included in an LSP.  That's all.  Practical uses of the ERO
currently tend to include the egress from an MPLS domain,
but there may be TE applications (for example) that benefit
from the increased dynamism of having an ERO that only
specifies some hop toward the middle of the MPLS cloud.

--
Eric Gray

You wrote:

 Dear Mr.(Mrs),  Please help me for a question about algorithem ofselection of the next hop.  In 4.8.1 selection of the next hop       2. If there is no second ER-HOP, this indicates the end of   the explicit route. The explicit route TLV should be removed   from the Label Request Message. This node may or may not   be the end of the LSP. Processing continues with section   4.8.2, where a new explicit route TLV may be added to the   Label Request Message. But why "This node may or may not be the end of the LSP."? RegardsZhang.
--------------B2947F683CE3CDC940D9A187-- From owner-mpls@UU.NET Thu Mar 8 10:00:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28413 for ; Thu, 8 Mar 2001 10:00:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkflz17334; Thu, 8 Mar 2001 14:57:57 GMT Received: by mail-control.mail.uu.net id QQkflz22565 for mpls-outgoing; Thu, 8 Mar 2001 14:57:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkflz22530 for ; Thu, 8 Mar 2001 14:57:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkflz09368 for ; Thu, 8 Mar 2001 14:56:07 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQkflz11981 for ; Thu, 8 Mar 2001 14:56:07 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 7E1C394009; Thu, 8 Mar 2001 09:56:03 -0500 (EST) Message-ID: <3AA79D83.188E9F3C@sandburst.com> Date: Thu, 08 Mar 2001 09:56:03 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Hummel Heinrich Cc: "'Dirk Ooms'" , davidm@galileo.co.il, "'mpls'" Subject: Re: AW: MPLS Multicast - Forwarding Plane References: 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 KAA28413 Heinrich, I'm joining this discussion a bit late, I'm afraid, but I do not understand why a 'multicast bit' would be useful. I would assume that an LSP used for multicast would be bound to a FEC for a corresponding multicast address (or other addressing related approach). Are there situations in which this is not the case? If so, how would a multicast capable router know what output interfaces to include - even when routing packets not using MPLS labels and LSPs? -- Eric Gray You wrote: > Because not every NHLFE, i.e. not every LSR, can support Multicast, I expressed my regrets some time ago not to have a "Multicast-Bit" in the label > (nor in G-MPLS labels). > > Heinrich Hummel > > > -----Urspr> üngliche Nachricht----- > > Von: Dirk Ooms [SMTP:Dirk.Ooms@alcatel.be] > > Gesendet am: Montag, 12. Februar 2001 12:42 > > An: davidm@galileo.co.il > > Cc: 'mpls' > > Betreff: Re: MPLS Multicast - Forwarding Plane > > > > David, > > > > Can you be more specific on the detail you are looking for? > > > > dirk > > > > David Melman wrote: > > > > > > RFC 3031 MPLS Architecture briefly mentions the forwarding plane processing in section 4.8. "MPLS and Multicast": > > > > > > "When a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label. If the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children." > > > > > > Is this addressed in any more detail in any other draft? > > > > > > Thanks, > > > > > > David > > > > -- From owner-mpls@UU.NET Thu Mar 8 11:13:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01633 for ; Thu, 8 Mar 2001 11:13:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfme24372; Thu, 8 Mar 2001 16:10:56 GMT Received: by mail-control.mail.uu.net id QQkfme06497 for mpls-outgoing; Thu, 8 Mar 2001 16:10:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfme06471 for ; Thu, 8 Mar 2001 16:10:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfme15763 for ; Thu, 8 Mar 2001 16:09:38 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfme27441 for ; Thu, 8 Mar 2001 16:09: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 IAA27718 for ; Thu, 8 Mar 2001 08:09:55 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA05586 for mpls@uu.net; Thu, 8 Mar 2001 11:09:36 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfji24554 for ; Wed, 7 Mar 2001 21:33:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfji16591 for ; Wed, 7 Mar 2001 21:33:14 GMT From: Dkruc@netscape.net Received: from imo-m05.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imo-m05.mx.aol.com [64.12.136.8]) id QQkfji27349 for ; Wed, 7 Mar 2001 21:33:13 GMT Received: from Dkruc@netscape.net by imo-m05.mx.aol.com (mail_out_v29.5.) id 1.1f.f79d8f (16246) for ; Wed, 7 Mar 2001 16:33:06 -0500 (EST) Received: from netscape.com (aimmail10.aim.aol.com [205.188.144.202]) by air-in03.mx.aol.com (v77_r1.21) with ESMTP; Wed, 07 Mar 2001 16:33:06 -0500 Date: Wed, 07 Mar 2001 16:33:32 -0500 To: mpls@UU.NET Subject: LDP over RSVP TE Mime-Version: 1.0 Message-ID: <7E9F794C.58B85746.0000E811@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk If the core of the network is running RSVP TE, and the edge is running LDP for VPNs, do the core MPLS switches (that have created the RSVP TE tunnels) also have to run LDP, or can the LDP messages just be piped transparently over the RSVP TE tunnels to other LDP peers. thanks! -dan.k. __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From owner-mpls@UU.NET Thu Mar 8 11:13:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01646 for ; Thu, 8 Mar 2001 11:13:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfme25037; Thu, 8 Mar 2001 16:11:41 GMT Received: by mail-control.mail.uu.net id QQkfme06578 for mpls-outgoing; Thu, 8 Mar 2001 16:11:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfme06566 for ; Thu, 8 Mar 2001 16:11:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfme03605 for ; Thu, 8 Mar 2001 16:10:41 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkfme23925 for ; Thu, 8 Mar 2001 16:10:41 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 IAA15661 for ; Thu, 8 Mar 2001 08:10:40 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA05637 for mpls@uu.net; Thu, 8 Mar 2001 11:10:39 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfke24599 for ; Thu, 8 Mar 2001 03:07:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfke18681 for ; Thu, 8 Mar 2001 03:05:50 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f70.law14.hotmail.com [64.4.21.70]) id QQkfke24651 for ; Thu, 8 Mar 2001 03:05:50 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Mar 2001 19:05:49 -0800 Received: from 38.204.3.195 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 08 Mar 2001 03:05:49 GMT X-Originating-IP: [38.204.3.195] From: "!! !!" To: mpls@UU.NET Subject: GMPLS question Date: Thu, 08 Mar 2001 03:05:49 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Mar 2001 03:05:49.0547 (UTC) FILETIME=[AD871BB0:01C0A77C] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have one doubt on GMPLS: Can there any scenario in which GMPLS enabled OXC extracts a wavelength (for wavelength switching) and extract the SDH/SONET framing (for VC-x switching) on another wavelength in the same incoming fiber? Pls. help. Thanks in advance. Raju _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Thu Mar 8 11:22:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02092 for ; Thu, 8 Mar 2001 11:22:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfmf16790; Thu, 8 Mar 2001 16:20:03 GMT Received: by mail-control.mail.uu.net id QQkfmf08107 for mpls-outgoing; Thu, 8 Mar 2001 16:19:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfmf08100 for ; Thu, 8 Mar 2001 16:19:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfmf01192 for ; Thu, 8 Mar 2001 16:19:32 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfmf16640 for ; Thu, 8 Mar 2001 16:19: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 IAA04279 for ; Thu, 8 Mar 2001 08:19:48 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA05721 for mpls@uu.net; Thu, 8 Mar 2001 11:19:29 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfme07027 for ; Thu, 8 Mar 2001 16:13:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfme07781 for ; Thu, 8 Mar 2001 16:12:44 GMT Received: from smtp1.gtsgroup.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp1.gtsgroup.com [195.158.230.16]) id QQkfme27403 for ; Thu, 8 Mar 2001 16:12:44 GMT Received: from 207.77.231.73 by smtp1.gtsgroup.com (InterScan E-Mail VirusWall NT); Thu, 08 Mar 2001 17:07:29 +0100 (W. Europe Standard Time) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Mar 2001 17:12:43 +0100 Message-ID: From: "Mannie, Eric" To: mpls@UU.NET, "'ccamp@ops.ietf.org'" Subject: FW: I-D ACTION:draft-many-gmpls-architecture-00.txt Date: Thu, 8 Mar 2001 17:12:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A7EA.96813590" 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_01C0A7EA.96813590 Content-Type: text/plain; charset="iso-8859-1" FYI -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 01, 2001 1:28 PM Subject: I-D ACTION:draft-many-gmpls-architecture-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalized Multi-Protocol Label Switching (GMPLS) Architecture Author(s) : P. Ashwood-Smith et al. Filename : draft-many-gmpls-architecture-00.txt Pages : 37 Date : 27-Feb-01 Future data and transmission networks will consist of elements such as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs) or optical cross- connects (OXCs), etc that will use Generalized MPLS (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-many-gmpls-architecture-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-many-gmpls-architecture-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-many-gmpls-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C0A7EA.96813590 Content-Type: message/rfc822 To: Subject: Date: Thu, 8 Mar 2001 17:12:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0A7EA.96813590" ------_=_NextPart_002_01C0A7EA.96813590 Content-Type: text/plain ------_=_NextPart_002_01C0A7EA.96813590 Content-Type: application/octet-stream; name="ATT69309.txt" Content-Disposition: attachment; filename="ATT69309.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227123550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-many-gmpls-architecture-00.txt ------_=_NextPart_002_01C0A7EA.96813590 Content-Type: message/external-body; site="internet-drafts"; dir="draft-many-gmpls-architecture-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0A7EA.96813590-- ------_=_NextPart_000_01C0A7EA.96813590-- From owner-mpls@UU.NET Thu Mar 8 12:21:47 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04733 for ; Thu, 8 Mar 2001 12:21:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfmj00843; Thu, 8 Mar 2001 17:19:09 GMT Received: by mail-control.mail.uu.net id QQkfmj03433 for mpls-outgoing; Thu, 8 Mar 2001 17:18:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfmj03417 for ; Thu, 8 Mar 2001 17:18:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfmj24266 for ; Thu, 8 Mar 2001 17:17:50 GMT Received: from IRISNT1.iris.irislabs.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.irislabs.com [64.123.160.251]) id QQkfmj08749 for ; Thu, 8 Mar 2001 17:17:50 GMT Received: by IRISNT1.iris.irislabs.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Mar 2001 11:17:49 -0600 Message-ID: <00D96DBEF03E924087EC1D1C0C719F5002804B@IRISNT1.iris.irislabs.com> From: Sandeep Sharma To: "'Francois Le Faucheur'" , David Charlap , lberger@movaz.com, swallow@cisco.com Cc: mpls@UU.NET Subject: RE: WG Last call : Comment on COS service and TSPEC Date: Thu, 8 Mar 2001 11:17:42 -0600 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 Francois, Your suggested changes are good! One comment: I think, in the context of E-LSP and L-LSP, there is a need to clarify use of the RSVP DCLASS object (RFC 2996) as referenced in the NULL service. Thanks, - Sandeep Sandeep Sharma Iris Labs > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Thursday, March 08, 2001 6:37 AM > To: David Charlap; lberger@movaz.com; swallow@cisco.com > Cc: mpls@UU.NET > Subject: Re: WG Last call : Comment on COS service and TSPEC > Based on the clarifications from George and Lou, I propose the > following resolution for David's two comments above: > > * generally, "diff-ext" will be updated to simply align > to the RSVP-TE > draft with respect to signaling LSPs without bandwidth reservation. > "diff-ext" will refer to RSVP-TE for details of how > Null-Service/TSSPEC > are used to signal LSP without bandwidth reservation. > > * section 5.6 will be updated to reflect use of "Null-service" > instead of "COS service". > > * section 5.6 can probably be shortened (because parts > of it came about > simply because of the confusion that stemmed from the "COS > service" and > its associated COS field. I believe some of that confusion naturally > goes away with the use of Null-Service). > > * TSPEC will be made mandatory (in line with RSVP-TE-08) > > > Any comments/issues with this resolution? > > cheers > > Francois > > PS: David, thanks a lot for catching this. > From owner-mpls@UU.NET Thu Mar 8 12:28:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04971 for ; Thu, 8 Mar 2001 12:28:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfmj10815; Thu, 8 Mar 2001 17:26:12 GMT Received: by mail-control.mail.uu.net id QQkfmj04158 for mpls-outgoing; Thu, 8 Mar 2001 17:25:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfmj04148 for ; Thu, 8 Mar 2001 17:25:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfmj11486 for ; Thu, 8 Mar 2001 17:25:17 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfmj09495 for ; Thu, 8 Mar 2001 17:25:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA28917 for mpls@uu.net; Thu, 8 Mar 2001 12:25:16 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfmj04047 for ; Thu, 8 Mar 2001 17:24:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfmj17664 for ; Thu, 8 Mar 2001 17:24:39 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkfmj21975 for ; Thu, 8 Mar 2001 17:24:39 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA01120; Thu, 8 Mar 2001 12:23:58 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-193.cisco.com [161.44.134.193]) by bucket.cisco.com (Mirapoint) with ESMTP id AAW19949; Thu, 8 Mar 2001 12:24:36 -0500 (EST) Message-Id: <4.3.2.7.2.20010308122352.01d9b5d8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Mar 2001 12:28:46 -0500 To: "Rao Vadlamani" , "mpls-ops@mplsrc.com" , "mpls@UU.NET" From: "Thomas D. Nadeau" Subject: Re: Questions on LSR-MIB In-Reply-To: <3AA6C078.E74DB7A0@adn.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 06:12 PM 3/7/2001 -0500, Rao Vadlamani wrote: >Hello, > >I have a few questions on the latest draft > > >1) I did not understand the significance of the textual convention >StorageType and usage of it for objects like >mplsInterfaceConfStorageType etc., The description just says the the >storage type for the entry. Could this be elaborated further ? They are now required on all writable objects in standard MIBs. They are intended to be used to indicate how the agent will treat the particular object (i.e.: will it automatically restore the saved value upon reboot from NVRAM, etc...) >2) mplsIntefaceLabelParticipationType - The description is not clear >esp., the last sentence, which says "If only the perPlatform(0) bit is >set, then the value of mplsInterfaceLabelMinIn, >mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, and >mplsInterfaceLabelMaxOut for this entry must be >identical to the instance of these objects with index 0." > >It is not clear. Could this be explained further ? What this is saying is that if interface index = 0 is configured, then this interface should be used to configure/indicate the per-platform label ranges. However, some implementations wanted to put this information on each interface instead of using a single interface to configure everything. The text is explaining that if you use interface index = 0, that the corresponding label ranges on those interfaces which are using labels from the per platform label space should have consistent (i.e.: the same) ranges as interface index = 0. --Tom >Thanks >Rao > > From owner-mpls@UU.NET Thu Mar 8 12:52:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05939 for ; Thu, 8 Mar 2001 12:52:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfml13781; Thu, 8 Mar 2001 17:49:58 GMT Received: by mail-control.mail.uu.net id QQkfml07805 for mpls-outgoing; Thu, 8 Mar 2001 17:49:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfml07779 for ; Thu, 8 Mar 2001 17:49:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfml05807 for ; Thu, 8 Mar 2001 17:48:17 GMT Received: from infres.enst.fr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: infres-192.enst.fr [137.194.192.1]) id QQkfml11277 for ; Thu, 8 Mar 2001 17:48:17 GMT Received: from cinna.enst.fr (cinna.enst.fr [137.194.192.5]) by infres.enst.fr (Postfix) with ESMTP id 1EAD045540; Thu, 8 Mar 2001 18:48:16 +0100 (MET) Received: from localhost (kuri@localhost) by cinna.enst.fr (8.9.3+Sun/8.9.1) with SMTP id SAA18727; Thu, 8 Mar 2001 18:48:14 +0100 (MET) Date: Thu, 8 Mar 2001 18:48:14 +0100 (MET) From: Josue Kuri To: !!!! Cc: mpls@UU.NET Subject: Re: GMPLS question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > Can there any scenario in which GMPLS enabled OXC extracts > a wavelength (for wavelength switching) and extract the SDH/SONET > framing (for VC-x switching) on another wavelength in the > same incoming fiber? Note that GMPLS is (or, more precisely, is intended to be) a control plane technology. In this sense, a 'GMPLS enabled OXC' would be an OXC that implements GMPLS-based control plane functions. The pertinence of an hybrid wavelength/SDH switch depends on the architectural requirements (e.g., granularity, flexibility) of the network that you are considering. Regards, -- Josue Kuri Department of Computer Science and Networks ENST Paris FRANCE E-mail: kuri@enst.fr Tel: (+33) 1.45.81.75.70 Fax: (+33) 1.45.81.31.19 From owner-mpls@UU.NET Thu Mar 8 17:19:32 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15191 for ; Thu, 8 Mar 2001 17:19:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfnd24705; Thu, 8 Mar 2001 22:17:43 GMT Received: by mail-control.mail.uu.net id QQkfnd10530 for mpls-outgoing; Thu, 8 Mar 2001 22:17:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfnd10513 for ; Thu, 8 Mar 2001 22:17:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfnd28184 for ; Thu, 8 Mar 2001 22:15:51 GMT Received: from apollo.mctr.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQkfnd24167 for ; Thu, 8 Mar 2001 22:15:51 GMT Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id QAA09853; Thu, 8 Mar 2001 16:56:21 -0500 (EST) Received: from localhost (ayyangar@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id RAA11931; Thu, 8 Mar 2001 17:03:01 -0500 (EST) X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs Date: Thu, 8 Mar 2001 17:03:01 -0500 (EST) From: Arthi Ayyangar X-Sender: ayyangar@mercury.mctr.umbc.edu To: George Swallow cc: Francois Le Faucheur , awduche@movaz.com, lberger@movaz.com, dhg@juniper.net, tonyl@home.net, vsriniva@cosine.com, mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, "'Ram Krishnan'" , Shahram Davari , Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi, david.charlap@marconi.com Subject: Re: Status of COS Service in rsvp-lsp-tunnel-08.txt In-Reply-To: <200103051639.LAA24962@lir.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk To add a small point, it would be helpful to add a section at the beginning stating what changed since the last version of the draft. That way everyone is aware of the changes right away. Thanks, -arthi > Francois - > > My error on the dangling references. I'll issue an updated draft with > pointers to the "Null Service Type", RFC 2997. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Thu Mar 8 17:44:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15954 for ; Thu, 8 Mar 2001 17:44:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfne18467; Thu, 8 Mar 2001 22:42:11 GMT Received: by mail-control.mail.uu.net id QQkfne12757 for mpls-outgoing; Thu, 8 Mar 2001 22:41:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfne12746 for ; Thu, 8 Mar 2001 22:41:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfne07024 for ; Thu, 8 Mar 2001 22:41:13 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkfne28536 for ; Thu, 8 Mar 2001 22:41:13 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 RAA08275 for ; Thu, 8 Mar 2001 17:41:10 -0500 (EST) 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 RAA04540 for ; Thu, 8 Mar 2001 17:41:12 -0500 (EST) Message-ID: <3AA80A9A.76F0F75A@marconi.com> Date: Thu, 08 Mar 2001 17:41:30 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: LDP over RSVP TE References: <7E9F794C.58B85746.0000E811@netscape.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dkruc@netscape.net wrote: > > If the core of the network is running RSVP TE, and the edge is > running LDP for VPNs, do the core MPLS switches (that have created > the RSVP TE tunnels) also have to run LDP, or can the LDP messages > just be piped transparently over the RSVP TE tunnels to other LDP > peers. Or the LDP peers at the edge of the RSVP core can talk to each other via unlabeled traffic as extended-discovery peers. I think all three solutions can be made to work. I am not sure which would work best. -- David From owner-mpls@UU.NET Thu Mar 8 19:15:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18349 for ; Thu, 8 Mar 2001 19:15:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfnk29392; Fri, 9 Mar 2001 00:14:26 GMT Received: by mail-control.mail.uu.net id QQkfnk19290 for mpls-outgoing; Fri, 9 Mar 2001 00:13:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfnk19279 for ; Fri, 9 Mar 2001 00:13:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfnk02251 for ; Fri, 9 Mar 2001 00:13:19 GMT Received: from femail14.sdc1.sfba.home.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail14.sdc1.sfba.home.com [24.0.95.141]) id QQkfnk05700 for ; Fri, 9 Mar 2001 00:13:19 GMT Received: from mci.net ([24.15.191.62]) by femail14.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010309001318.VXPA1870.femail14.sdc1.sfba.home.com@mci.net>; Thu, 8 Mar 2001 16:13:18 -0800 Message-ID: <3AA820EE.DFE6816B@mci.net> Date: Thu, 08 Mar 2001 19:16:46 -0500 From: Ashley Shi X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: Francis Arts , puneet@pluris.com, mpls@UU.NET, Francois Le Faucheur , liwwu@cisco.com, Shahram Davari , Bruce Davie , pierre.debuysscher@alcatel.be, Marijke Coenen , finizoll@sh.bel.alcatel.be Subject: Re: Comments on draft-agarwal-mpls-ttl-00 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > On Sat, 3 Mar 2001, Francis Arts wrote: > > > > > Puneet, > > > > Please find included some comments to your draft > > draft-agarwal-mpls-ttl-00. > > > > Kind regards, > > > > Francis. > > > > -------------- > > > > 1) Section 2.2. > > > > The text states that oTTL = iTTL -1 and that it is checked whether oTTL > > is greater than 0. > > > > However, this does not cover the receipt of an (erroneous) MPLS packet > > with a TTL of 0. In this case setting oTTL = iTTL - 1, would result in a > > oTTL value different from 0. So the MPLS packet would still pass the > > oTTL check while it should not have. > > > > Therefore, I propose to check the iTTL, rather than the oTTL: > > * A check is done whether or not the iTTL value is strictly larger than > > 1. This check on the iTTL value should only be done once it has been > > determined that the packet is routed (as an IP or MPLS packet) to a next > > node. > > Francis, > > I believe the text says to check for oTTL > 0/ > > > > > > > 2) Section 2.2. > > > > The text states that 'the oTTL check is performed only if an outgoing > > TTL is set to oTTL'. > > > > However, this is inconsistent with the statement in section 2.4 - 3rd > > bullet: "PHP case - The oTTL check should be performed irrespective of > > whether the oTTL is used in any outgoing label / IP header". > > This will be fixed in the next version of the draft. > > > > > > > 3) Section 2.3. > > > > The text states that '... we are performing a push / swap / PHP, then > > the iTTL is the TTL ...'. > > We put the word "push" there to clearly differentiate against the "POP" > case. Even when you are pushing, you still need to determine the iTTL so > that you can determine the TTL for the label that is being pushed. > > > > > I propose to remove the 'push' since this is irrelevant for the incoming > > TTL determination; the push is handled in section 2.4 (outgoing TTL > > determination). > > About the ospf configuration on CE, is there anything special you need to do, or just the regular ospf configuration as we have discussed today. Ashley From owner-mpls@UU.NET Thu Mar 8 19:56:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18912 for ; Thu, 8 Mar 2001 19:56:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfnn07165; Fri, 9 Mar 2001 00:56:06 GMT Received: by mail-control.mail.uu.net id QQkfnn22003 for mpls-outgoing; Fri, 9 Mar 2001 00:55:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfnn21996 for ; Fri, 9 Mar 2001 00:55:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfnn09734 for ; Fri, 9 Mar 2001 00:54:25 GMT Received: from femail14.sdc1.sfba.home.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail14.sdc1.sfba.home.com [24.0.95.141]) id QQkfnn03396 for ; Fri, 9 Mar 2001 00:54:24 GMT Received: from mci.net ([24.15.191.62]) by femail14.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010309005420.XEXB1870.femail14.sdc1.sfba.home.com@mci.net>; Thu, 8 Mar 2001 16:54:20 -0800 Message-ID: <3AA82A1B.DEA6F411@mci.net> Date: Thu, 08 Mar 2001 19:55:55 -0500 From: Ashley Shi X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol , Francis Arts , puneet@pluris.com, mpls@UU.NET, Francois Le Faucheur , liwwu@cisco.com, Shahram Davari , Bruce Davie , pierre.debuysscher@alcatel.be, Marijke Coenen , finizoll@sh.bel.alcatel.be Subject: Re: Comments on draft-agarwal-mpls-ttl-00 References: <3AA820EE.DFE6816B@mci.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Oops, I replied to the wrong message, please discard my previous message and this one too. -Ashley Ashley Shi wrote: > Bora Akyol wrote: > > > On Sat, 3 Mar 2001, Francis Arts wrote: > > > > > > > > Puneet, > > > > > > Please find included some comments to your draft > > > draft-agarwal-mpls-ttl-00. > > > > > > Kind regards, > > > > > > Francis. > > > > > > -------------- > > > > > > 1) Section 2.2. > > > > > > The text states that oTTL = iTTL -1 and that it is checked whether oTTL > > > is greater than 0. > > > > > > However, this does not cover the receipt of an (erroneous) MPLS packet > > > with a TTL of 0. In this case setting oTTL = iTTL - 1, would result in a > > > oTTL value different from 0. So the MPLS packet would still pass the > > > oTTL check while it should not have. > > > > > > Therefore, I propose to check the iTTL, rather than the oTTL: > > > * A check is done whether or not the iTTL value is strictly larger than > > > 1. This check on the iTTL value should only be done once it has been > > > determined that the packet is routed (as an IP or MPLS packet) to a next > > > node. > > > > Francis, > > > > I believe the text says to check for oTTL > 0/ > > > > > > > > > > > 2) Section 2.2. > > > > > > The text states that 'the oTTL check is performed only if an outgoing > > > TTL is set to oTTL'. > > > > > > However, this is inconsistent with the statement in section 2.4 - 3rd > > > bullet: "PHP case - The oTTL check should be performed irrespective of > > > whether the oTTL is used in any outgoing label / IP header". > > > > This will be fixed in the next version of the draft. > > > > > > > > > > > 3) Section 2.3. > > > > > > The text states that '... we are performing a push / swap / PHP, then > > > the iTTL is the TTL ...'. > > > > We put the word "push" there to clearly differentiate against the "POP" > > case. Even when you are pushing, you still need to determine the iTTL so > > that you can determine the TTL for the label that is being pushed. > > > > > > > > I propose to remove the 'push' since this is irrelevant for the incoming > > > TTL determination; the push is handled in section 2.4 (outgoing TTL > > > determination). > > > > > About the ospf configuration on CE, is there anything special you need to do, > or just the regular ospf configuration as we have discussed today. > > Ashley From owner-mpls@UU.NET Fri Mar 9 07:40:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11937 for ; Fri, 9 Mar 2001 07:40:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfpi19440; Fri, 9 Mar 2001 12:39:03 GMT Received: by mail-control.mail.uu.net id QQkfpi02420 for mpls-outgoing; Fri, 9 Mar 2001 12:38:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfpi02409 for ; Fri, 9 Mar 2001 12:38:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfpi19260 for ; Fri, 9 Mar 2001 12:38:03 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfpi08014 for ; Fri, 9 Mar 2001 12:38:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA03185 for mpls@uu.net; Fri, 9 Mar 2001 07:38:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfpi02369 for ; Fri, 9 Mar 2001 12:37:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfpi16300 for ; Fri, 9 Mar 2001 12:37:06 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkfpi06219 for ; Fri, 9 Mar 2001 12:37: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 HAA11787; Fri, 9 Mar 2001 07:37:04 -0500 (EST) Message-Id: <200103091237.HAA11787@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-te-mib-06.txt Date: Fri, 09 Mar 2001 07:37:04 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Traffic Engineering Management Information Base Using SMIv2 Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-te-mib-06.txt Pages : 65 Date : 08-Mar-01 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 Multi-Protocol Label Switching (MPLS) [MPLSArch] based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.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-te-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-te-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308111108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308111108.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 9 09:43:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15233 for ; Fri, 9 Mar 2001 09:43:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfpq27222; Fri, 9 Mar 2001 14:41:03 GMT Received: by mail-control.mail.uu.net id QQkfpq16671 for mpls-outgoing; Fri, 9 Mar 2001 14:40:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfpq16666 for ; Fri, 9 Mar 2001 14:40:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfpq29822 for ; Fri, 9 Mar 2001 14:39:31 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfpq24968 for ; Fri, 9 Mar 2001 14:39:30 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 GAA09179 for ; Fri, 9 Mar 2001 06:39:49 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09326 for mpls@uu.net; Fri, 9 Mar 2001 09:39:28 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfni01954 for ; Thu, 8 Mar 2001 23:39:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfni05697 for ; Thu, 8 Mar 2001 23:39:18 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f152.law14.hotmail.com [64.4.21.152]) id QQkfni14612 for ; Thu, 8 Mar 2001 23:39:18 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Mar 2001 15:39:17 -0800 Received: from 38.204.3.195 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 08 Mar 2001 23:39:17 GMT X-Originating-IP: [38.204.3.195] From: "Raju Venkatraman" To: mpls@UU.NET Subject: GMPLS, SDH/SONET Question Date: Thu, 08 Mar 2001 23:39:17 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Mar 2001 23:39:17.0772 (UTC) FILETIME=[FDDE0CC0:01C0A828] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have one doubt on GMPLS: Can there any scenario in which GMPLS enabled OXC/optical switch extracts a wavelength (for wavelength switching) and extract the SDH/SONET framing (for VC-x switching) on another wavelength in the same incoming fiber? Should a generic (encompassing as many requirements as possible) GMPLS control plane implementation take care of such scenario? Pls. help. Thanks in advance. Raju _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Fri Mar 9 09:43:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15244 for ; Fri, 9 Mar 2001 09:43:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfpq28429; Fri, 9 Mar 2001 14:41:11 GMT Received: by mail-control.mail.uu.net id QQkfpq16683 for mpls-outgoing; Fri, 9 Mar 2001 14:40:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfpq16672 for ; Fri, 9 Mar 2001 14:40:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfpq01276 for ; Fri, 9 Mar 2001 14:39:59 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfpq25615 for ; Fri, 9 Mar 2001 14:39:58 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 GAA09417 for ; Fri, 9 Mar 2001 06:40:17 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09332 for mpls@uu.net; Fri, 9 Mar 2001 09:39:57 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfnj02449 for ; Thu, 8 Mar 2001 23:45:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfnj02007 for ; Thu, 8 Mar 2001 23:45:11 GMT Received: from shared1-mail.whowhere.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: shared1-qin.whowhere.com [209.185.123.111]) id QQkfnj27220 for ; Thu, 8 Mar 2001 23:45:11 GMT Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Thu Mar 8 15:44:59 2001 To: mpls@UU.NET Date: Fri, 09 Mar 2001 00:14:59 +0030 From: "Manoj Kumar Juneja" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: manoj.juneja@eudoramail.com X-Mailer: MailCity Service Subject: Doubts regarding LSP encoding type X-Sender-Ip: 38.204.3.195 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, The draft "draft-ietf-mpls-generalized-signalling-02.txt" defines different values for LSP encoding type. How does the implementatin of a control plane differ if it receives the LSP encoding type packet/SDH/Digital Wrapper/Lamda/Fiber etc. My understanding is that if the LSP encoding type is either packet/ethernet, then label is just a 32 bit integer (as we already have in traditional MPLS). But if LSP encoding type is SDH, SONET then the label has to be in the form of {S, U, K, L, M} format. If the LSP encoding type is Lamda then the label represents the lamda (specific frequency). If LSP encoding type is fiber, then label is the fiberId itself. Can u please describe a scenario in which the LSP encoding type will be used as a "digital wrapper" ? Please clarify. Regards, manoj. Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-mpls@UU.NET Fri Mar 9 09:44:43 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15311 for ; Fri, 9 Mar 2001 09:44:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfpq29581; Fri, 9 Mar 2001 14:42:28 GMT Received: by mail-control.mail.uu.net id QQkfpq16778 for mpls-outgoing; Fri, 9 Mar 2001 14:42:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfpq16723 for ; Fri, 9 Mar 2001 14:41:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfpq28723 for ; Fri, 9 Mar 2001 14:39:02 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkfpq24313 for ; Fri, 9 Mar 2001 14:39:02 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 GAA08939 for ; Fri, 9 Mar 2001 06:39:20 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09318 for mpls@uu.net; Fri, 9 Mar 2001 09:39:00 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfnf13850 for ; Thu, 8 Mar 2001 22:54:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfnf27030 for ; Thu, 8 Mar 2001 22:54:19 GMT Received: from shared1-mail.whowhere.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: shared1-qin.whowhere.com [209.185.123.111]) id QQkfnf21599 for ; Thu, 8 Mar 2001 22:54:18 GMT Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Thu Mar 8 14:54:08 2001 To: mpls@UU.NET Date: Thu, 08 Mar 2001 23:24:08 +0030 From: "Manoj Kumar Juneja" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: manoj.juneja@eudoramail.com X-Mailer: MailCity Service Subject: Doubts in latest GMPLS drafts (GMPLS Functional Specs and GMPLS-CR-LDP) X-Sender-Ip: 38.204.3.195 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I have following doubts in draft "draft-ietf-mpls-generalized-signalling-02.txt : In section 3.3.1, it is written that wavebandId is 32 bits and this value is selected by the sender and reused in all subsequent messages. I want to know what are all those subsequent messages ? Can waveband Label (format : wavebandId, start label, end label) be present in Label Request message ? It is fine that waveband Label to be present in Label Mapping message. I could not find this information even in draft "draft-ietf-mpls-generalized-cr-ldp-01.txt". Also, How does label request will indicate that a label of type waveband Label is requested in Label request ? Is it based on siganl type ? One more thing, draft "draft-ietf-mpls-generalized-signalling-02.txt" describes different values for signal types. The values 1-7 are derived from the STM hierarchy. But how the remaining values are interpretted (i.e. STM-1 MS, STM-1 RS etc) ? How is STM-4 different from STM-1 MS and STM-1 RS ? Is STM-1 MS or STM-1 RS a different signal type in SDH ? How does implementation of a control plane for GMPLS differ if it receives the signal type as STM-1/STM-1 MS/STM-1 RS ? The draft "draft-ietf-mpls-generalized-cr-ldp-01.txt" gives reference to only two messages of LDP viz. Label Request, Label Mapping. What about the other messages like label withdraw and label release. I believe that the generalized label TLV need to be included in these messages too instead of the label TLV. Please help me in understanding these drafts. Regards, manoj. Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-mpls@UU.NET Fri Mar 9 09:44:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15324 for ; Fri, 9 Mar 2001 09:44:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfpq27598; Fri, 9 Mar 2001 14:42:19 GMT Received: by mail-control.mail.uu.net id QQkfpq16757 for mpls-outgoing; Fri, 9 Mar 2001 14:41:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfpq16721 for ; Fri, 9 Mar 2001 14:41:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfpq29196 for ; Fri, 9 Mar 2001 14:39:13 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkfpq24585 for ; Fri, 9 Mar 2001 14:39: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 GAA29541 for ; Fri, 9 Mar 2001 06:39:12 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09322 for mpls@uu.net; Fri, 9 Mar 2001 09:39:11 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfni01731 for ; Thu, 8 Mar 2001 23:35:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfni03804 for ; Thu, 8 Mar 2001 23:35:11 GMT Received: from shared1-mail.whowhere.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: shared1-qin.whowhere.com [209.185.123.111]) id QQkfni10281 for ; Thu, 8 Mar 2001 23:35:11 GMT Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Thu Mar 8 15:34:57 2001 To: mpls@UU.NET Date: Fri, 09 Mar 2001 00:04:57 +0030 From: "Manoj Kumar Juneja" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: manoj.juneja@eudoramail.com X-Mailer: MailCity Service Subject: GMPLS & LMP X-Sender-Ip: 38.204.3.195 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, Can someone help me in clearing the following doubt : Is implementation of LMP a pre-requisite for supporting LDP-ONUI and GMPLS ? Thanks, manoj. Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-mpls@UU.NET Fri Mar 9 12:00:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22614 for ; Fri, 9 Mar 2001 12:00:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfpz23464; Fri, 9 Mar 2001 16:58:56 GMT Received: by mail-control.mail.uu.net id QQkfpz29125 for mpls-outgoing; Fri, 9 Mar 2001 16:58:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkfpz29119 for ; Fri, 9 Mar 2001 16:58:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfpz28833 for ; Fri, 9 Mar 2001 16:56:58 GMT Received: from malmo.trab.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkfpz15532 for ; Fri, 9 Mar 2001 16:56:57 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f29GusI17451; Fri, 9 Mar 2001 17:56:54 +0100 (MET) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id <1GW4QGCH>; Fri, 9 Mar 2001 17:56:52 +0100 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D01E7DFE7@trab-hermes.haninge.trab.se> From: Olle Pers To: "'Raju Venkatraman'" Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: GMPLS, SDH/SONET Question Date: Fri, 9 Mar 2001 17:56:25 +0100 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 * -----Original Message----- * From: Raju Venkatraman [mailto:raju_vvs@hotmail.com] * Sent: 9 mars 2001 00:39 * To: mpls@UU.NET * Subject: GMPLS, SDH/SONET Question * * * Hi, * * I have one doubt on GMPLS: * * Can there any scenario in which GMPLS enabled OXC/optical switch * extracts a wavelength (for wavelength switching) and extract the * SDH/SONET framing (for VC-x switching) on another wavelength in * the same incoming fiber? Should a generic (encompassing as many * requirements as possible) GMPLS control plane implementation * take care of such scenario? * * Pls. help. * * Thanks in advance. * Raju * Hi, Such an hybrid lambda-SDH crossconnect could fit well in some network designs, replacing a co-located DXC + OXC pair. Similar products have been announced. A "generic control plane" should be able to handle a network that includes such hybrids, among pure OXCs, pure DXCs, and packet switches. So, if GMPLS wants to be (the signaling part of) that control plane, it should support such a scenario. Do you have doubts that current GMPLS can handle this? Olle Pers Telia Sweden From owner-mpls@UU.NET Fri Mar 9 14:08:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00142 for ; Fri, 9 Mar 2001 14:08:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfqi19572; Fri, 9 Mar 2001 19:05:56 GMT Received: by mail-control.mail.uu.net id QQkfqi27114 for mpls-outgoing; Fri, 9 Mar 2001 19:05:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfqi26554 for ; Fri, 9 Mar 2001 19:05:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkfqi16294 for ; Fri, 9 Mar 2001 19:04:43 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfqi21382 for ; Fri, 9 Mar 2001 19:04:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA06247 for mpls@uu.net; Fri, 9 Mar 2001 14:04:42 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfqi14750 for ; Fri, 9 Mar 2001 19:00:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfqi15158 for ; Fri, 9 Mar 2001 19:00:22 GMT Received: from xover.mindspeed.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQkfqi20193 for ; Fri, 9 Mar 2001 19:00:22 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Mar 2001 13:56:21 -0500 Message-ID: <87009604743AD411B1F600508BA0F9597B5EAF@XOVER.dedham.mindspeed.com> From: "Friedeborn, William" To: "'mpls@uu.net'" Subject: re: draft-ietf-mpls-te-mib-06.txt Date: Fri, 9 Mar 2001 13:56:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I'm a little confused by the mplsTunnelCRLDPResTable description: "The mplsTunnelCRLDPResTable allows a manager to specify which CR-LDP-specific resources are desired for an MPLS tunnel if that tunnel is signaled using CR-LDP. Note that these attributes are in addition to those specified in mplsTunnelResourceTable. This table also allows several tunnels to point to a single entry in this table, implying that these tunnels should share resources." If these are in addition to the mplsTunnelResourceTable I would expect this to be an AUGMENT to the resource table or I would expect an additional row pointer in the tunnel table so that the ResourceTable and the CRLDPResTable can be used by the Tunnel? Actually, on closer inspection, there is quite a bit of overlap between the two tables. This doesn't look right to me? It seems to me that the overlapping parameters should be removed and either make the CRLDPResTable an AUGMENT to ResourceTable or add a new ROW POINTER to the TunnelTable. Bill Friedeborn From owner-mpls@UU.NET Fri Mar 9 14:43:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01672 for ; Fri, 9 Mar 2001 14:43:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfqk11229; Fri, 9 Mar 2001 19:41:26 GMT Received: by mail-control.mail.uu.net id QQkfqk01576 for mpls-outgoing; Fri, 9 Mar 2001 19:40:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfqk01571 for ; Fri, 9 Mar 2001 19:40:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfqk11851 for ; Fri, 9 Mar 2001 19:40:44 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfqk07213 for ; Fri, 9 Mar 2001 19:40:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA09790 for mpls@uu.net; Fri, 9 Mar 2001 14:40:42 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfqk01546 for ; Fri, 9 Mar 2001 19:40:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfqk25956 for ; Fri, 9 Mar 2001 19:40:08 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkfqk08865 for ; Fri, 9 Mar 2001 19:40:08 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA07260; Fri, 9 Mar 2001 14:39:19 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAW38607; Fri, 9 Mar 2001 14:39:57 -0500 (EST) Message-Id: <4.3.2.7.2.20010309143504.05317ca8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Mar 2001 14:44:13 -0500 To: "Friedeborn, William" , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: re: draft-ietf-mpls-te-mib-06.txt Cc: cheenu Srinivasan , arun Viswanathan In-Reply-To: <87009604743AD411B1F600508BA0F9597B5EAF@XOVER.dedham.mindsp eed.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >I'm a little confused by the mplsTunnelCRLDPResTable description: > >"The mplsTunnelCRLDPResTable allows a manager to > specify which CR-LDP-specific resources are desired > for an MPLS tunnel if that tunnel is signaled using > CR-LDP. Note that these attributes are in addition > to those specified in mplsTunnelResourceTable. This > table also allows several tunnels to point to a > single entry in this table, implying that these > tunnels should share resources." > >If these are in addition to the mplsTunnelResourceTable I would expect >this to be an AUGMENT to the resource table or I would expect an >additional row pointer in the tunnel table so that the ResourceTable >and the CRLDPResTable can be used by the Tunnel? We went with a separate table that is required ONLY if CRLDP is used for signaling. The AUGMENTS does not apply here due to the fact that the parent table could be sparsely populated with regard to CR-LDP (i.e.: RSVP and CR-LDP resources in the tunnel resource table). From RFC1902: 7.8.1. Relation between INDEX and AUGMENTS clauses When defining instance identification information for a conceptual table: (1) If there is a one-to-one correspondence between the conceptual rows of this table and an existing table, then the AUGMENTS clause should be used. (2) Otherwise, if there is a sparse relationship between the conceptual rows of this table and an existing table, then an INDEX clause should be used which is identical to that in the existing table. For example, the relationship between RFC 1573's ifTable and a media-specific MIB which extends the ifTable for a specific media (e.g., the dot3Table in RFC 1650), is a sparse relationship. --Tom From owner-mpls@UU.NET Fri Mar 9 14:50:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02083 for ; Fri, 9 Mar 2001 14:50:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfql22945; Fri, 9 Mar 2001 19:48:32 GMT Received: by mail-control.mail.uu.net id QQkfql02592 for mpls-outgoing; Fri, 9 Mar 2001 19:47:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfql02579 for ; Fri, 9 Mar 2001 19:47:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfql16014 for ; Fri, 9 Mar 2001 19:46:26 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkfql19710 for ; Fri, 9 Mar 2001 19:46:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA10726 for mpls@uu.net; Fri, 9 Mar 2001 14:46:24 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkfqk01756 for ; Fri, 9 Mar 2001 19:42:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkfqk01565 for ; Fri, 9 Mar 2001 19:41:53 GMT Received: from lobster.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns3.BayNetworks.COM [192.32.253.3]) id QQkfqk08696 for ; Fri, 9 Mar 2001 19:41:53 GMT Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA05670; Fri, 9 Mar 2001 14:46:47 -0500 (EST) 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 OAA26691; Fri, 9 Mar 2001 14:41:02 -0500 (EST) Received: from nortelnetworks.com (dhcp235-150 [192.32.235.150]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id OAA11788; Fri, 9 Mar 2001 14:41:02 -0500 for Message-ID: <3AA9313D.C2450E02@nortelnetworks.com> Date: Fri, 09 Mar 2001 14:38:37 -0500 From: Shobhan Lakkapragada Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Friedeborn, William" CC: "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-te-mib-06.txt References: <87009604743AD411B1F600508BA0F9597B5EAF@XOVER.dedham.mindspeed.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit If I remember correctly, I think the consensus on this mailing list was to add these new CR-LSP objects in a separate table. So my guess is the authors didn't intend to add these in both the mplsTunnelCRLDPResTable and in mplsTunnelResourceTable. Could the authors please clarify. Thanks. - shobhan "Friedeborn, William" wrote: > I'm a little confused by the mplsTunnelCRLDPResTable description: > > "The mplsTunnelCRLDPResTable allows a manager to > specify which CR-LDP-specific resources are desired > for an MPLS tunnel if that tunnel is signaled using > CR-LDP. Note that these attributes are in addition > to those specified in mplsTunnelResourceTable. This > table also allows several tunnels to point to a > single entry in this table, implying that these > tunnels should share resources." > > If these are in addition to the mplsTunnelResourceTable I would expect > this to be an AUGMENT to the resource table or I would expect an > additional row pointer in the tunnel table so that the ResourceTable > and the CRLDPResTable can be used by the Tunnel? > > Actually, on closer inspection, there is quite a bit of overlap between the > two tables. This doesn't look right to me? It seems to me that the > overlapping > parameters should be removed and either make the CRLDPResTable an > AUGMENT to ResourceTable or add a new ROW POINTER to the TunnelTable. > > Bill Friedeborn From owner-mpls@UU.NET Sat Mar 10 09:03:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13856 for ; Sat, 10 Mar 2001 09:03:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkftg22244; Sat, 10 Mar 2001 14:02:34 GMT Received: by mail-control.mail.uu.net id QQkftg21776 for mpls-outgoing; Sat, 10 Mar 2001 14:02:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkftg21740 for ; Sat, 10 Mar 2001 14:01:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkftg18123 for ; Sat, 10 Mar 2001 14:00:58 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkftg22008 for ; Sat, 10 Mar 2001 14:00:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA25622 for mpls@uu.net; Sat, 10 Mar 2001 09:00:48 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkftg15441 for ; Sat, 10 Mar 2001 14:00:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkftg23368 for ; Sat, 10 Mar 2001 14:00:11 GMT Received: from china.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: TCE-E-7-182-16.bta.net.cn [202.106.182.16]) id QQkftg20968 for ; Sat, 10 Mar 2001 14:00:04 GMT Received: from china.com([10.1.7.104]) by china.com(JetMail 2.5.3.0) with SMTP id jm93aaa835c; Sat, 10 Mar 2001 13:58:13 -0000 Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by china.com(JetMail 2.5.3.0) with SMTP id jm143aa59cad; Tue, 6 Mar 2001 19:57:49 -0000 Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkffj12371; Tue, 6 Mar 2001 19:57:38 GMT Received: by mail-control.mail.uu.net id QQkffj13396 for mpls-outgoing; Tue, 6 Mar 2001 19:56:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkffj13387 for ; Tue, 6 Mar 2001 19:56:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkffj03816 for ; Tue, 6 Mar 2001 19:55:38 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkffj20931 for ; Tue, 6 Mar 2001 19:55:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA11994 for mpls@uu.net; Tue, 6 Mar 2001 14:55:32 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkffj13293 for ; Tue, 6 Mar 2001 19:54:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkffj24506 for ; Tue, 6 Mar 2001 19:54:22 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkffj17821 for ; Tue, 6 Mar 2001 19:54:21 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Mar 2001 11:53:52 -0800 Message-ID: From: Vishal Mishra To: "'eric.gray@sandburst.com'" , "'Francis Arts'" Cc: "'mpls@UU.NET'" , Vishal Sharma , Vach Kompella Subject: Re: New TTL Draft. Date: Tue, 6 Mar 2001 11:53:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello All, Besides the reasons specified below, there are several other situations in which it is desirable to decrement TTL by N. According to the MPLS architecture, any label distribution protocol can be used for LSP setup. Therefore, assume an MPLS cloud, which is built over IP (no ATM/Frame Relay for now). Let us also assume that this MPLS cloud is composed of LSRs that use RSVP and/or LDP as their Label Distribution (and therefore LSP setup) Protocols. Now an administrator wants to setup an LSP using RSVP, but realizes that the path is passing through a non-RSVP (say LDP) cloud. Since IP-TTL counts the number of IP hops, and RSVP-TTL counts the number of RSVP hops, therefore the presence of a Non-RSVP cloud is detected by the next RSVP hop, and LSP setup fails, with Path Tear messages being replied back to the sender(s). Therefore, now the administrator would like to connect the RSVP clouds with a 'Single IP Hop' LSP so that, To RSVP, the Multi-MPLS-Hop LSP 'looks' like a Single-IP-Hop. To achieve this, the Ingress LER should be able to setup the LSP, and 'tell' the Egress, not to copy MPLS-TTL into IP-TTL. Instead, it (Ingress LER) would be decrementing the TTL by N (In this example: N=1, by configuration). Do we have any mechanism in RSVP and/or LDP to configure/negotiate the 'IP-Hop length' (say N) of an LSP, so that Ingress LER decrements the IP TTL (by N), and Egress LER does not copy MPLS-TTL into IP-TTL ? I don't think so, although it can be done at the time of LSP setup. If this needs to be supported in RSVP and LDP, then for RSVP, we would need a new 'OPTIONAL' RSVP object (say IP_HOP_LENGTH), and for LDP, we would need a new 'OPTIONAL' TLV (say IP_HOP_LENGTH). I feel that the potential of MPLS TTL field is not being fully utilized by the existing MPLS mechanisms. e.g. We can control the 'perceived' length of an LSP using the above proposed mechanism. There lies the power of MPLS ;-), and the value addition of the presence of multiple TTL fields in the MPLS-IP-Packet !! Awaiting Comments ... Vishal. --- Francis Arts wrote: > > Hello Eric, > > In the discussion below you propose the possibility to decrement the TTL > with N units. You indicate that the reason for doing this, is the following: >> There are practical reasons for decrementing TTL by more than one >> (a high-cost or low-bandwidth link, for example) when it is desirable to >> accelerate the aging of possibly looping packets. A higher TTL >> decrement punishes all packets that use the link, but it punishes looping >> packets much more. http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt From owner-mpls@UU.NET Sun Mar 11 07:09:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09349 for ; Sun, 11 Mar 2001 07:09:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfwq29757; Sun, 11 Mar 2001 12:08:43 GMT Received: by mail-control.mail.uu.net id QQkfwq06637 for mpls-outgoing; Sun, 11 Mar 2001 12:08:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkfwq06632 for ; Sun, 11 Mar 2001 12:08:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfwq22156 for ; Sun, 11 Mar 2001 12:08:02 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkfwq28770 for ; Sun, 11 Mar 2001 12:08:00 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f2BC7wc05879; Sun, 11 Mar 2001 13:07:58 +0100 (MET) Received: from alcatel.be ([138.203.253.227]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A0C.00429D0B; Sun, 11 Mar 2001 13:07:36 +0100 Message-ID: <3AAB6917.8BDB9ADA@alcatel.be> Date: Sun, 11 Mar 2001 13:01:27 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: "'mpls@UU.NET'\"" CC: Vishal Sharma , "Vach Kompella\"@alcatel.be"@relay1.alcatel.be Subject: New TTL Draft. Content-Type: multipart/mixed; boundary="------------4EB3F74D0E8D382F847B1B04" Sender: owner-mpls@UU.NET Precedence: bulk Dit is een multi-gedeelten-bericht in MIME-formaat. --------------4EB3F74D0E8D382F847B1B04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vishal, Please find included some comments to the ideas in your mail: * Decrement of IP-TTL with N. Your mail gives an example that states N = 1 by configuration. Do you see another example / case in which N < > 1? Or stated differently: If we would give the operator the possibility to decrement the IP-TTL with N units, would he ever see the need to put N < > 1? * Signalling procedures. The draft indicates that the LSP through the LDP cloud can be considered as 1 hop (IP TTL decremented with 1 unit). However, this draft does not handle the signalling procedures (refer also to the discussion on the mpls mailing list earlier). Note that the draft proposes to tie the QoS and TTL aspects of the tunnel and pipe model respectively. Kind regards, Francis. --------------- http://cell.onecall.net/mhonarc/mpls/current/msg00114.html --------------4EB3F74D0E8D382F847B1B04 Content-Type: text/html; charset=us-ascii; name="msg00114.html" Content-Disposition: inline; filename="msg00114.html" Content-Base: "http://cell.onecall.net/mhonarc/mpls/c urrent/msg00114.html" Content-Location: "http://cell.onecall.net/mhonarc/mpls/c urrent/msg00114.html" Content-Transfer-Encoding: 7bit New TTL Draft.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New TTL Draft.


Hello All,

    Besides the reasons specified below, there are several other situations
in which it is desirable to decrement TTL by N.

    According to the MPLS architecture, any label distribution protocol can
be used for LSP setup. Therefore, assume an 
MPLS cloud, which is built over IP (no ATM/Frame Relay for now). Let us also
assume that this MPLS cloud is composed
of LSRs that use RSVP and/or LDP as their Label Distribution (and therefore
LSP setup) Protocols.

    Now an administrator wants to setup an LSP using RSVP, but realizes that
the path is passing through a non-RSVP 
(say LDP) cloud.

    Since IP-TTL counts the number of IP hops, and RSVP-TTL counts the
number of RSVP hops, therefore the presence of a 
Non-RSVP cloud is detected by the next RSVP hop, and LSP setup fails, with
Path Tear messages being replied back to the 
sender(s).

     Therefore, now the administrator would like to connect the RSVP clouds
with a 'Single IP Hop' LSP so that, To RSVP, the
Multi-MPLS-Hop LSP 'looks' like a Single-IP-Hop. To achieve this, the
Ingress LER should be able to setup the LSP, and 'tell'
the Egress, not to copy MPLS-TTL into IP-TTL. Instead, it (Ingress LER)
would be decrementing the TTL by N  (In this 
example: N=1, by configuration).

     Do we have any mechanism in RSVP and/or LDP to configure/negotiate the
'IP-Hop length' (say N) of an LSP, so that 
Ingress LER decrements the IP TTL (by N), and Egress LER does not copy
MPLS-TTL into IP-TTL ? I don't think so,
although it can be done at the time of LSP setup.

     If this needs to be supported in RSVP and LDP, then for RSVP, we would
need a new 'OPTIONAL' RSVP object 
(say IP_HOP_LENGTH), and for LDP, we would need a new 'OPTIONAL' TLV (say
IP_HOP_LENGTH).

    I feel that the potential of MPLS TTL field is not being fully utilized
by the existing MPLS mechanisms. e.g. We can
control the 'perceived' length of an LSP using the above proposed mechanism.
There lies the power of MPLS ;-), and
the value addition of the presence of multiple TTL fields in the
MPLS-IP-Packet !!

    Awaiting Comments ...

Vishal.



--- Francis Arts <francis.arts@alcatel.be> wrote:
> 
> Hello Eric,
> 
> In the discussion below you propose the possibility to decrement the TTL
> with N units. You indicate that the reason for doing this, is the
following:
>> There are practical reasons for decrementing TTL by more than one 
>> (a high-cost or low-bandwidth link, for example) when it is desirable to
>>  accelerate the aging of possibly looping packets. A higher TTL 
>> decrement punishes all packets that use the link, but it punishes looping

>> packets much more.

http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt

--------------4EB3F74D0E8D382F847B1B04-- From owner-mpls@UU.NET Sun Mar 11 07:48:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09662 for ; Sun, 11 Mar 2001 07:48:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfwt17830; Sun, 11 Mar 2001 12:47:32 GMT Received: by mail-control.mail.uu.net id QQkfwt09376 for mpls-outgoing; Sun, 11 Mar 2001 12:47:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfwt09371 for ; Sun, 11 Mar 2001 12:46:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfwt16330 for ; Sun, 11 Mar 2001 12:46:36 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkfwt16426 for ; Sun, 11 Mar 2001 12:46:34 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f2BCjTN06709; Sun, 11 Mar 2001 13:45:45 +0100 (MET) Received: from alcatel.be ([138.203.253.227]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A0C.00460C01; Sun, 11 Mar 2001 13:45:07 +0100 Message-ID: <3AAB71E1.843C5243@alcatel.be> Date: Sun, 11 Mar 2001 13:38:57 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: akyol@pluris.com CC: akyol@pluris.com, puneet@pluris.com, mpls@UU.NET, Francois Le Faucheur , liwwu@cisco.com, Shahram@alcatel.be, Davari@alcatel.be, brockmas@se.bel.alcatel.be Subject: Comments on draft-agarwal-mpls-ttl-00 Content-Type: multipart/mixed; boundary="------------652785AC5C8DDFF5C412AA2D" Sender: owner-mpls@UU.NET Precedence: bulk Dit is een multi-gedeelten-bericht in MIME-formaat. --------------652785AC5C8DDFF5C412AA2D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Bora, Please find included some replies: 1) Section 2.2. Bora> I believe the text says to check for oTTL > 0/ Francis >> I agree that indeed the text states 'oTTL > 0'. However, the following Francis >> problem situation can occur: Francis >> *) iTTL == 0 (that is, the TTL of incoming MPLS packet == 0). Francis >> The oTTL calculated as proposed in the draft results in Francis >> oTTL = iTTL - 1 = value greater than 0 (unless one would Francis >> assume that the oTTL is a signed 9 bit quantity (most significant bit = sign Francis >> bit) but I do not think that this is the intention). Francis >> Francis >> Doing in this case a check on oTTL < > 0, will allow the Francis >> packet go through while it should not have. Francis >> According to me this situation can be handled correctly by checking Francis >> whether iTTL > 1. This check on the iTTL value should only be done Francis >> once it has been determined that the packet is routed (as an IP or Francis >> MPLS packet) to a next node. 3) Section 2.3. Bora> We put the word "push" there to clearly differentiate against the "POP" Bora> case. Even when you are pushing, you still need to determine the iTTL so Bora> that you can determine the TTL for the label that is being pushed. Francis >> I agree that even when you are pushing, you still need to calculate the Francis >> iTTL for the label being pushed. Francis >> However, I would propose not to put "push" to differentiate against Francis >> the "pop" case since the same node can perform a "pop" and "push" Francis >> operation at the same time. Kind regards, Francis. ------------- http://cell.onecall.net/mhonarc/mpls/current/msg00079.html --------------652785AC5C8DDFF5C412AA2D Content-Type: text/html; charset=us-ascii; name="msg00079.html" Content-Disposition: inline; filename="msg00079.html" Content-Base: "http://cell.onecall.net/mhonarc/mpls/c urrent/msg00079.html" Content-Location: "http://cell.onecall.net/mhonarc/mpls/c urrent/msg00079.html" Content-Transfer-Encoding: 7bit Comments on draft-agarwal-mpls-ttl-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on draft-agarwal-mpls-ttl-00




On Sat, 3 Mar 2001, Francis Arts wrote:

> 
> Puneet,
> 
> Please find included some comments to your draft
> draft-agarwal-mpls-ttl-00.
> 
> Kind regards,
> 
>     Francis.
> 
> --------------
> 
> 1) Section 2.2.
> 
> The text states that oTTL = iTTL -1 and that it is checked whether oTTL
> is greater than 0.
> 
> However, this does not cover the receipt of an (erroneous) MPLS packet
> with a TTL of 0. In this case setting oTTL = iTTL - 1, would result in a
> oTTL value different from 0. So the MPLS packet would still pass the
> oTTL check while it should not have.
> 
> Therefore, I propose to check the iTTL, rather than the oTTL:
> * A check is done whether or not the iTTL value is strictly larger than
> 1. This check on the iTTL value should only be done once it has been
> determined that the packet is routed (as an IP or MPLS packet) to a next
> node.

Francis,

I believe the text says to check for oTTL > 0/

> 
> 
> 2) Section 2.2.
> 
> The text states that 'the oTTL check is performed only if an outgoing
> TTL is set to oTTL'.
> 
> However, this is inconsistent with the statement in section 2.4 - 3rd
> bullet: "PHP case - The oTTL check should be performed irrespective of
> whether the oTTL is used in any outgoing label / IP header".

This will be fixed in the next version of the draft.

> 
> 
> 3) Section 2.3.
> 
> The text states that '... we are performing a push / swap /  PHP, then
> the iTTL is the TTL ...'.

We put the word "push" there to clearly differentiate against the "POP"
case. Even when you are pushing, you still need to determine the iTTL so
that you can determine the TTL for the label that is being pushed.


 > 
> I propose to remove the 'push' since this is irrelevant for the incoming
> TTL determination; the push is handled in section 2.4 (outgoing TTL
> determination).
>

--------------652785AC5C8DDFF5C412AA2D-- From owner-mpls@UU.NET Mon Mar 12 04:07:23 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05946 for ; Mon, 12 Mar 2001 04:07:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkfzw26029; Mon, 12 Mar 2001 09:05:21 GMT Received: by mail-control.mail.uu.net id QQkfzw23046 for mpls-outgoing; Mon, 12 Mar 2001 09:04:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkfzw22929 for ; Mon, 12 Mar 2001 09:04:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkfzw06736 for ; Mon, 12 Mar 2001 09:04:04 GMT Received: from ss3000e.cselt.it by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ss3000e.cselt.it [163.162.41.5]) id QQkfzw23592 for ; Mon, 12 Mar 2001 09:03:20 GMT Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0GA200E13UE1CD@ss3000e.cselt.it> for mpls@uu.net; Mon, 12 Mar 2001 10:01:16 +0100 (MET) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Mar 2001 09:45:10 +0100 Content-return: allowed Date: Mon, 12 Mar 2001 09:44:15 +0100 From: "D'Albenzio Raffaele" Subject: Question about draft-kats-yeung-ospf-traffic-03 To: "'mpls@uu.net'" , "'dkatz@juniper.net'" Message-id: <7C29E4DE54DA024C82B509BD318C24EA048C061B@clu2k01a.cselt.it> 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 Dave and all, in Section 2.4 of draft about ospf traffic engineering extensions you wrote: "An LSA contains one top-level TLV". What do you mean about it? do you mean that an LSA contain ONLY one top level TLV or one or MORE top level TLV? Could an LSA contain router address TLV and one (or more) Link TLV? Thank you, Raffaele. ____________________________ Raffaele D'Albenzio Telecom Italia Lab Networking - Corporate Networks. Networks and System integrations. Via Reiss Romoli, 274 10148 Turin, Italy Ph. +39 011 228 5798 Fax +39 011 228 5096 email raffaele.dalbenzio@tilab.com From owner-mpls@UU.NET Mon Mar 12 05:10:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06477 for ; Mon, 12 Mar 2001 05:10:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgaa15905; Mon, 12 Mar 2001 10:08:40 GMT Received: by mail-control.mail.uu.net id QQkgaa13074 for mpls-outgoing; Mon, 12 Mar 2001 10:08:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgaa13044 for ; Mon, 12 Mar 2001 10:07:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgaa01585 for ; Mon, 12 Mar 2001 10:06:42 GMT Received: from acc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkgaa13230 for ; Mon, 12 Mar 2001 10:06:42 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f2CA5MT15359 for ; Mon, 12 Mar 2001 02:05:22 -0800 (PST) Reply-To: From: "Anil Gunturu" To: Subject: mplsLdpEntityIndex Date: Mon, 12 Mar 2001 02:04:54 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I know that this issue has a been addressed before. But, I am still unclear on the concept of mplsLdpEntityIndex. 1. If I have an LSR (A) communicating with two peers (P1 & P2) on the same ethernet and A is using platform-wide adressing, will I have two entries in the mplsLdpEntityTable? |------- P1 A:0--------| |------- P2 Section 3.1 in the draft-mib seem to indicate that there will be two entries. Also, is it possible for A to use different label spaces for p1 and P2? 2. What about in the case where A and B are connected over an Ethernet link and a PPP link. B is using interface specific space and A is using platform wide space? Ether ------------- ------------- PPP My guess is there are two entries in the mplsLdpEntityTable. 3. A abd B are connected over Ethernet and PPP links, but both of them are using platform-wide label space. Ether ------------- ------------- PPP Is there only one entry in this case? Thanks, -Anil Anil Gunturu, Software Engineer Ericsson, Inc phone: (805) 562 6431 Datacom & IP Services email: anilg@acc.am.ericsson.se 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Mon Mar 12 13:02:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15638 for ; Mon, 12 Mar 2001 13:02:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgbg05527; Mon, 12 Mar 2001 18:00:04 GMT Received: by mail-control.mail.uu.net id QQkgbf24377 for mpls-outgoing; Mon, 12 Mar 2001 17:59:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgbf24368 for ; Mon, 12 Mar 2001 17:59:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgbf06465 for ; Mon, 12 Mar 2001 17:57:26 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgbf01570 for ; Mon, 12 Mar 2001 17:57:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA23629 for mpls@uu.net; Mon, 12 Mar 2001 12:57:24 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgbf23762 for ; Mon, 12 Mar 2001 17:53:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgbf21073 for ; Mon, 12 Mar 2001 17:51:51 GMT Received: from brixcorp2.brixnet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.122.27.34]) id QQkgbf23914 for ; Mon, 12 Mar 2001 17:51:51 GMT Received: by BRIXCORP2 with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Mar 2001 12:51:51 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B804B@BRIXCORP2> From: "Cucchiara, Joan" To: "'anilg@acc.am.ericsson.se'" , mpls@UU.NET Subject: RE: mplsLdpEntityIndex Date: Mon, 12 Mar 2001 12:51:50 -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 > -----Original Message----- > From: Anil Gunturu [mailto:anilg@acc.com] > Sent: Monday, March 12, 2001 5:05 AM > To: mpls@UU.NET > Subject: mplsLdpEntityIndex > Hi Anil, > > I know that this issue has a been addressed before. But, I am > still unclear > on the concept of mplsLdpEntityIndex. This is a secondary index which is needed for ppp. It may not be needed for your specific implementation,but would have to be supported (e.g. it would have to have a valid value as specified in the MIB). > > 1. If I have an LSR (A) communicating with two peers (P1 & > P2) on the same > ethernet and A is using platform-wide adressing, will I have > two entries in > the mplsLdpEntityTable? > > |------- P1 > A:0--------| > |------- P2 > > Section 3.1 in the draft-mib seem to indicate that there will be two > entries. > I don't quite understand the picture above, but there would be two entries in the mplsLdpEntity Table based on your description. An entry in the mplsLdpEntityTable represents a potential session (prior to session initialization). The mplsLdpSessionTable represents sesssions which are setup or are in the process of being setup. So if you expect 2 sessions then you would have two entries in the mpldLdpEntityTable. If the LSR A is communicating to two peers then this would imply two sessions. > Also, is it possible for A to use different label spaces for > p1 and P2? yes. > > 2. What about in the case where A and B are connected over an > Ethernet link > and a PPP link. B is using interface specific space and A is > using platform > wide space? > Ether > ------------- > ------------- > PPP > My guess is there are two entries in the mplsLdpEntityTable. yes, again, if you anticipate two sessions, then there would be two entries in the EntityTable. > > 3. A abd B are connected over Ethernet and PPP links, but > both of them are > using platform-wide label space. > Ether > ------------- > ------------- > PPP > > Is there only one entry in this case? This is 2 sessions, so would be two Entities. Each would have some labels (non-overlapping from the platform-wide label space) and this would be indicated in the mplsLdpEntityConfGenericLabelRangeTable. Please note, the mplsLdpEntityConfGenericLabelRangeTable allows any number of label ranges per Entity, as long as these ranges don't overlap. -Joan > > Thanks, > -Anil > > > > > > Anil Gunturu, Software Engineer > Ericsson, Inc phone: (805) 562 6431 > Datacom & IP Services email: > anilg@acc.am.ericsson.se > 70 Castilian Dr, Santa Barbara, CA-93117 > From owner-mpls@UU.NET Mon Mar 12 14:20:56 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17601 for ; Mon, 12 Mar 2001 14:20:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgbl05730; Mon, 12 Mar 2001 19:19:04 GMT Received: by mail-control.mail.uu.net id QQkgbl06247 for mpls-outgoing; Mon, 12 Mar 2001 19:18:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgbl06237 for ; Mon, 12 Mar 2001 19:18:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgbl15277 for ; Mon, 12 Mar 2001 19:18:19 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkgbl04450 for ; Mon, 12 Mar 2001 19:18:16 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f2CJGJB14921; Mon, 12 Mar 2001 11:16:19 -0800 (PST) Reply-To: From: "Anil Gunturu" To: "Cucchiara, Joan" , , Subject: RE: mplsLdpEntityIndex Date: Mon, 12 Mar 2001 11:15:45 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-reply-to: <07B0D4912B83D31188F300A0C9F62EBB9B804B@BRIXCORP2> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Joan, Thanks for your response. It clears a lot of mud. But, can you explain why mplsLdpEntityIndex is needed for PPP? Draft-mib also mentions this, but I am not clear on why this is the case. Thanks for your help, -Anil -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Cucchiara, Joan Sent: Monday, March 12, 2001 9:52 AM To: 'anilg@acc.am.ericsson.se'; mpls@UU.NET Subject: RE: mplsLdpEntityIndex > -----Original Message----- > From: Anil Gunturu [mailto:anilg@acc.com] > Sent: Monday, March 12, 2001 5:05 AM > To: mpls@UU.NET > Subject: mplsLdpEntityIndex > Hi Anil, > > I know that this issue has a been addressed before. But, I am > still unclear > on the concept of mplsLdpEntityIndex. This is a secondary index which is needed for ppp. It may not be needed for your specific implementation,but would have to be supported (e.g. it would have to have a valid value as specified in the MIB). > > 1. If I have an LSR (A) communicating with two peers (P1 & > P2) on the same > ethernet and A is using platform-wide adressing, will I have > two entries in > the mplsLdpEntityTable? > > |------- P1 > A:0--------| > |------- P2 > > Section 3.1 in the draft-mib seem to indicate that there will be two > entries. > I don't quite understand the picture above, but there would be two entries in the mplsLdpEntity Table based on your description. An entry in the mplsLdpEntityTable represents a potential session (prior to session initialization). The mplsLdpSessionTable represents sesssions which are setup or are in the process of being setup. So if you expect 2 sessions then you would have two entries in the mpldLdpEntityTable. If the LSR A is communicating to two peers then this would imply two sessions. > Also, is it possible for A to use different label spaces for > p1 and P2? yes. > > 2. What about in the case where A and B are connected over an > Ethernet link > and a PPP link. B is using interface specific space and A is > using platform > wide space? > Ether > ------------- > ------------- > PPP > My guess is there are two entries in the mplsLdpEntityTable. yes, again, if you anticipate two sessions, then there would be two entries in the EntityTable. > > 3. A abd B are connected over Ethernet and PPP links, but > both of them are > using platform-wide label space. > Ether > ------------- > ------------- > PPP > > Is there only one entry in this case? This is 2 sessions, so would be two Entities. Each would have some labels (non-overlapping from the platform-wide label space) and this would be indicated in the mplsLdpEntityConfGenericLabelRangeTable. Please note, the mplsLdpEntityConfGenericLabelRangeTable allows any number of label ranges per Entity, as long as these ranges don't overlap. -Joan > > Thanks, > -Anil > > > > > > Anil Gunturu, Software Engineer > Ericsson, Inc phone: (805) 562 6431 > Datacom & IP Services email: > anilg@acc.am.ericsson.se > 70 Castilian Dr, Santa Barbara, CA-93117 > From owner-mpls@UU.NET Mon Mar 12 16:58:54 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21731 for ; Mon, 12 Mar 2001 16:58:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgbv21211; Mon, 12 Mar 2001 21:56:32 GMT Received: by mail-control.mail.uu.net id QQkgbv24576 for mpls-outgoing; Mon, 12 Mar 2001 21:55:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgbv24552 for ; Mon, 12 Mar 2001 21:55:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgbv21827 for ; Mon, 12 Mar 2001 21:54:58 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgbv24944 for ; Mon, 12 Mar 2001 21:54:58 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA15276 for mpls@uu.net; Mon, 12 Mar 2001 16:54:57 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgbv24011 for ; Mon, 12 Mar 2001 21:49:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgbv00514 for ; Mon, 12 Mar 2001 21:48:19 GMT Received: from hoemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkgbv05928 for ; Mon, 12 Mar 2001 21:48:19 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA26198 for ; Mon, 12 Mar 2001 16:48:18 -0500 (EST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA26176 for ; Mon, 12 Mar 2001 16:48:18 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Mar 2001 16:48:17 -0500 Message-ID: <2E12619580C0D1118C6400805F9F4C9509216259@nj7460exch001u.ho.lucent.com> From: "Griffeth, Nancy D (Nancy)" To: "'mpls@uu.net'" Cc: "Bounimova, Eleonora (Ella)" Subject: formal specifications of MPLS Date: Mon, 12 Mar 2001 16:48:06 -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 Is anyone aware of a formal specification of MPLS. I would be particularly interested in an SDL specification. Thanks, Nancy Griffeth Bell Labs From owner-mpls@UU.NET Mon Mar 12 17:35:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23217 for ; Mon, 12 Mar 2001 17:35:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgby03447; Mon, 12 Mar 2001 22:32:57 GMT Received: by mail-control.mail.uu.net id QQkgby28953 for mpls-outgoing; Mon, 12 Mar 2001 22:32:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgby28947 for ; Mon, 12 Mar 2001 22:32:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgby14369 for ; Mon, 12 Mar 2001 22:31:47 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkgby10376 for ; Mon, 12 Mar 2001 22:31:46 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f2CMViA23134; Mon, 12 Mar 2001 17:31:44 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; MON, 12 Mar 2001 17:29:02 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Mar 2001 17:29:02 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E56993D42@newman.tenornet.com> From: "Shah, Himanshu" To: "'mpls@uu.net'" , "'nbvpn@bbo.com'" Subject: FW: New ID: draft-shah-mpls-l2vpn-ext-00.txt Date: Mon, 12 Mar 2001 17:28:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0AB43.D671C474" 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_01C0AB43.D671C474 Content-Type: text/plain; charset="iso-8859-1" Hello, I know I am late for draft submission for upcoming meeting, so I will re-post after March 19. However, for those interested following is the draft on extensions for MPLS based L2VPN. > From the abstract: > > > This document proposes extension to draft-kompella-mpls-l2vpn-02.txt > such that range on provider's edge router can be increased for the > MPLS labels without requiring to being contiguous for all the > customer edge devices. Also, when the range is increased to > accommodate more customer edge devices into the existing VPN, the > processing of increased range advertisement does not disturb the > ongoing data traffic on existing layer 2 circuits. > > > <> > > > > > Himanshu Shah > Tenor Networks > Acton, MA > ------_=_NextPart_000_01C0AB43.D671C474 Content-Type: text/plain; name="draft-shah-mpls-l2vpn-ext-00.txt" Content-Disposition: attachment; filename="draft-shah-mpls-l2vpn-ext-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group Himanshu Shah Internet Draft Xavier Briard Expiration Date: September 2001 Jim Tsillas =20 Tenor Networks Extensions to MPLS-based Layer 2 VPNs draft-shah-mpls-l2vpn-ext-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other = documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 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=20 http://www.ietf.org/shadow.html. 2. Abstract =09 The Provisioning of VPN based on Layer 2 circuits across MPLS-base=20 network has been described in draft-kompella-mpls-l2vpn-02.txt. The = draft describes how provider's edge routers distribute configured=20 VPN information amongst themselves. This information is then=20 processed to map layer 2 circuits of customer's edge devices to=20 remote customer devices of the same VPN through MPLS cloud via=20 adjoining provider's edge devices. The proposal requires a priori=20 guestimating of customer's growth needs for the VPN and accordingly = over provisioning of a contiguous set of (preferably per platform)=20 MPLS labels.=20 Unfortunately, when the actual needs exceed the already provisioned = and advertised labels, incrementing to higher range causes=20 disruptions in ongoing data traffic. This document proposes extension to = draft-kompella-mpls-l2vpn-02.txt=20 such that range on provider's edge router can be increased for the=20 MPLS labels without requiring to being contiguous for all the=20 customer edge devices. Also, when the range is increased to=20 accommodate more customer edge devices into the existing VPN, the=20 processing of increased range advertisement does not disturb the=20 ongoing data traffic on existing layer 2 circuits. shah et al. page 1 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 =20 3. Introduction The service provider's edge (PE) router, which offers layer 2 VPN=20 services are required to configure VPN specific information which=20 includes VPN ID, Customer's Edge ID and a range that denotes the=20 number of customer's edge devices that can be accommodated for this = VPN. The range parameter is recommended to be over-provisioned to=20 accommodate future additions of customer sites to the VPN with=20 minimal configuration impact. In addition, if data link is of = multi- access in nature for instance frame relay, "range" number of DLCIs=20 must be configured where each DLCI denote a direct connection to=20 remote customer edge device. It is not required that these DLCIs be = contiguous within the range. The provider's edge router then allocates a contiguous range of = MPLS=20 labels and advertises to its peers; VPN ID, CE ID, CE range and = MPLS=20 label base. The remote peer validates the received information and=20 proceeds to update cross-connect forwarding table based on which = CE- ID sent the information and what CE-ID is locally configured for = the=20 VPN.=20 The receiver calculates "inner label" by offsetting the local CE-ID = into the received label base. This "inner label" is then used to=20 send data traffic to the CE through advertising PE router via MPLS=20 tunnels. This process of deriving the label by offsetting CE-ID = from=20 base mandates labels to be contiguous. On one hand, this requirement of contiguousness offers reduction in = amount of information that needs to be exchanged amongst PE = routers.=20 However, on the other hand disadvantages are two fold. First,=20 because the manner in which these labels are used (LSP hierarchical = fashion), the labels are required to be (per platform) global and = to=20 obtain a contiguous set of global labels may not always be = possible.=20 Secondly, when need exceeds already provisioned range, a new range=20 with yet another whole set of contiguous labels are required. And=20 re-advertising of this new range causes previously programmed = cross- connects be removed from forwarding table and re-added with new=20 label information. This document proposes a simple extension to the base document (of=20 Kompella [Mpls]) where an information element is added to the=20 distributed VPN information and an additional processing step to=20 handle this information. =20 4. Extension to signalling MPLS-Based Layer 2 VPNs In Kompella [Mpls] draft, L2VPN information block is defined which=20 constitute the VPN information. This information is then = distributed=20 using either LDP or BGP.=20 shah et al. page 2 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 =20 A new information element, CE-Base is introduced to allow for=20 advertisement of multiple ranges. A given range is then said to=20 begin and end with associated CE-base and CE-range that is present=20 in the advertisement. The L2VPN FEC element (for LDP) or L2VPN NLRI = (for BGP) is then referred to as a set. One or more set of the VPN=20 information elements would then constitute the configured range on=20 the PE router. 4.1 CE-Base CE-base is Customer Edge base information. The base information=20 identifies a VPN for a set of CE identifiers that fall within the=20 CE-base and CE-range. In some sense, the associated MPLS base is=20 bounded by CE-base and CE-range. The labels are required to be=20 sequential within CE-base to CE-range. User is not required to configure CE-base. Instead, L2VPN software=20 module obtains fragments of label sets, which are contiguous within = the fragment. One or more fragments can be obtained to support the=20 configured range. Each fragment is then delineated by CE-base and=20 CE-range that is distributed to PE peers. The L2VPN FEC element for LDP as described in Kompella [Mpls] draft = is shown below with added information of CE-base. "In LDP, VPN CE information and its associated label base are=20 carried in a Label Mapping message, distributed in the downstream=20 unsolicited mode described in [LDP]. A new FEC element is defined=20 below to carry all the information corresponding to a VPN CE, = except=20 from the label base. The label base is carried in the Label TLV=20 following the FEC TLV. If a FEC element in a FEC TLV encodes Layer = 2 VPN information, it MUST be the only FEC element in the FEC TLV." When advertising more than one range that constitutes the = configured=20 range, user must generate advertisement for each FEC element with=20 different CE-base information in the FEC TLV. =20 shah et al. page 3 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 The extended Layer 2 VPN FEC element is depicted in Figure 1 below. =20 Figure 1: L2 VPN FEC Element 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Encaps. Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Flags | Reserved (Must Be Zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE ID | CE Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE-base | reserved (must be zero) |new=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Connectivity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | . ... . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Again, following text from the Kompella [Mpls] draft for BGP=20 signaling. "In BGP, the Multiprotocol Extensions [BGP-MP] are used to carry L2-VPN signalling information. [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability=20 information.=20 We introduce a new address family identifier (AFI) for L2-VPN [to = be=20 assigned by IANA], a new subsequent address family identifier = (SAFI)=20 [to be assigned by IANA], and also a new NLRI format for carrying=20 the individual L2-VPN CE information. This NLRI will be carried in = the above-mentioned BGP attributes. This NLRI MUST be accompanied=20 by one or more extended communities. The extended community type = is=20 "Layer 2 VPN" (to be assigned by IANA); and the format is :, where is 4 octets in length, and=20 is two octets. All extended communities = accompanying=20 one or more Layer 2 VPN NLRIs MUST have the same ." When advertising more than one range that constitutes a configured=20 range, more than one NLRIs are included in a single MP_REACH_NLRI = or=20 MP_UNREACH_NLRI BGP attributes. The format of the extended Layer 2 VPN NLRI is as shown in Figure 2 = below. shah et al. page 4 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 Figure 2: BGP NLRI for L2 VPN Information +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Encaps Type (1 octet) | +------------------------------------+ | Control Flags (1 octet) | +------------------------------------+ | Label base (3 octets) | +------------------------------------+ | Reserved (Must Be Zero) (1 octet) | +------------------------------------+ | CE ID (2 octets) | +------------------------------------+ | CE Base (2 octets) | <- new=20 +------------------------------------+ | CE Range (2 octets) | +------------------------------------+ | Variable TLVs (0 to n octets) | | ... | +------------------------------------+ =20 =20 4.2. Signalled Information =20 The Kompella [Mpls] draft describes the individual information=20 elements that is distributed as part of VPN information.=20 Following sections describes those elements from the base draft=20 with changes where necessary. =09 4.2.1. Type (LDP only) The Type is L2-VPN (to be decided by IETF Consensus Action). 4.2.2. Length In LDP, the Length is the entire length of the L2 VPN FEC element,=20 including the fixed header and all the sub-TLVs. In BGP, the Length field indicates the length in octets of the L2- VPN address prefix. =20 4.2.3. Encapsulation Type Identifies the layer 2 encapsulation, e.g., ATM, Frame Relay etc. The following encapsulation types are defined: shah et al. page 5 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 =09 Value Encapsulation 0 Reserved 1 ATM PDUs (AAL/5) 2 ATM Cells 3 Frame Relay 4 PPP 5 Cisco-HDLC 6 Ethernet VLAN (unswitched) 7 MPLS 4.2.4. Control Flags This is a bit vector, defined as in the following Figure. Figure 3: Control Flags Bit Vector 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |S| +-+-+-+-+-+-+-+-+ The following bit is defined; the rest MUST be set to zero. Name Bit Meaning S 0 Sequenced delivery of frames is required =20 4.2.5. Label base (BGP only) The label-base which is to be used for determining the inner label=20 for forwarding packets to the CE identified by CE ID. (Note: LDP carries the label-base in the Label TLV following the FEC TLV.) Note that label base is bounded by CE-base and CE-range parameters. 4.2.6. VPN ID (LDP only) A 32 bit number which uniquely identifies a VPN in a provider's domain. 4.2.7. CE ID A 16 bit number which uniquely identifies a CE in a VPN. 4.2.8 CE Base A 16 bit number which identifies the base of CE ID. shah et al. page 6 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 4.2.9 CE Range A 16 bit number which describes the range of CE IDs starting from=20 CE-base to which the advertised CE is willing to connect. In=20 particular, a PE receiving an L2 VPN TLV MUST NOT use a label less=20 than or greater than or equal to + when sending traffic for this VPN to the advertising PE. The CE- Range present in the VPN information does not necessarily represent = the total number of CE-Ids that advertising CE is willing to=20 connect. In the case, where multiple number of VPN FEC elements=20 (LDP) or NLRIs (BGP) exist for a VPN, total number of CE-Ids the=20 advertising CE is willing to connect for the VPN is the sum of CE- range present in each advertised set. These CE-ranges between the sets does not have to be contiguous either. For example, a given VPN contains 50 sites with CE-Ids starting from 0 to 49. However, a particular PE router could be configured with total CE-IDs of 20 with ranges of 0 to 9 and 30 to 39. Such level of flexibility, albeit with additional configuration, is possible. 4.2.10 CE Connectivity (LDP only) A 32-bit number encoding connectivity. If the leftmost bit is 1,=20 the CE is a spoke. The remaining 31 bits encode the CE colors (bit i =3D 1 means the CE has color i). 4.2.11 Sub-TLVs New sub-TLVs can be introduced as needed. In LDP, the TLV encoding mechanism described in [LDP] must be used. In BGP, TLVs (type takes 1 octet) can be added to extend the=20 information carried in the L2 VPN address prefix. A TLV (type =3D 1) will be used for carrying VLAN IDs if the=20 encapsulation is VLAN. =20 4.3 Advantages of using BGP=09 =09 The Kompella [Mpls] draft discusses various advantages of using BGP as the signaling protocol for VPN information distribution as=20 compared to LDP.=20 The new mechanism proposed in this document where VPN information=20 can be distributed in multiple sets bodes well in BGP parlance = where each set is an L2VPN NLRI and multiple NLRIs can accompany in a=20 single MP_REACH_NLRI or MP_UNREACH_NLRI attribute. Thus, the number = of advertisements can be reduced if all the sets are known at the=20 time of advertisement. shah et al. page 7 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 =20 5.0. Adding a New Site The first step in adding a new site to a VPN is to pick a new CE = ID. =20 If all current members of the VPN are over-provisioned, i.e., their = range includes the new CE ID, adding the new site is a purely local = task. Otherwise, the sites whose range doesn't include the new CE = ID and wish to communicate directly with the new CE must have their=20 ranges increased to incorporate the new CE ID. In the circumstances when the range is increased, PE router does = not=20 have to obtain a whole new set of labels that are contiguous from 0 = to increased range. Instead, it obtains a small set of labels that=20 covers the difference between the old range and new range and some=20 increment to cover for future growth. This could be obtained in one = or more sets. For example, original range configured in the PE router was 50. The = service provider now wants to add 4 more sites to this VPN. It = would=20 increase the range to 60 with over-provision of 6 more sites. Now=20 lets suppose that PE router could only obtain 2 sets of 5 each=20 contiguous labels. PE router would then generate two L2VPN FEC=20 element, one for each set, with CE-base and CE-range in one set to=20 be 50 and 54 respectively and 55 and 59 in the second set.=20 The next step is ensuring that the new site has the required=20 connectivity (see below). This may require tweaking the=20 connectivity mechanism; however, in several common cases, the only=20 configuration needed is local to the PE to which the CE is = attached. The rest of the configuration is a local matter between the new CE=20 and the PE to which it is attached. It bears repeating that the key to making additions easy is over- provisioning. However, what is being over-provisioned is the = number=20 of DLCIs/VCIs that connect the CE to the PE. This is a local=20 matter, and generally is not an issue. 5.1. PE Information Exchange When a PE is configured with all the needed information for a CE, = it first of all chooses a contiguous set of labels with n labels, = where n may or may not be the whole CE's range. In the event that a=20 contiguous set of labels for the entire range could not be = obtained,=20 PE may obtain more than one smaller sets where individual set has=20 contiguous labels and the combined sets represent the total range.=20 Call the smallest label in each set the label-base. The PE then=20 advertises each set(for this CE): its Router ID, the VPN ID, the CE = ID, CE-base, CE-Range, and the label-base. When one set does not=20 equal to CE's configured range, more than one set are advertised.=20 shah et al. page 8 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 =20 This is the basic Layer 2 VPN advertisement. This same=20 advertisement is sent to all other PEs. Note that PEs that may not = be part of the VPN can receive and keep this information, in case = at=20 some future point, a CE connected to the PE joins the VPN. Also,=20 note that PE participating in the VPN must save all the VPN=20 information which may be spread in multiple sets. If the PE-CE connection goes down, or the CE configuration is=20 removed, the above advertisement is withdrawn. 5.1.1 PE Advertisement Processing When a PE receives a Layer 2 VPN advertisement of a given set, it=20 checks if the VPN ID matches any VPN that it is a member of. If=20 not, the PE just stores the advertisement for future use. If VPN=20 membership is verified but the received information set does not=20 include the configured CE-ID, PE must save this information for=20 later use. The simple rule of thumb when processing VPN information in = multiple=20 sets, is to match the local CE-ID through each set to find a set=20 where the CE-ID falls within the CE-base and CE-range of the set.=20 The CE-base is than subtracted from CE-ID and used as an offset = into=20 the associated label base to derive the "inner label" for send data = traffic. Same logic is used with received CE-ID and the local VPN=20 information in the multiple sets to derive the "inner label" to=20 expect on receive data traffic. Lets suppose the advertisement is from PE A for VPN X, CE m with=20 set range S-Rm, set base S-Bm and label base Lm. For each CE that the receiving PE B is connected to that is member of VPN X, PE B does the following. =20 0) Look up the configuration information associated with the CE.=20 If the encapsulation type for VPN X in the advertisement does=20 not match the configured encapsulation type for VPN X, stop. shah et al. page 9 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 1) Say the configured CE-ID is k, the configured range is Rk, and=20 the DLCI list is Dk[]. Also, the label base PE B allocated for=20 this CE is in n sets, then set bases are S-B(1-n)k, set ranges=20 are S-R(1-n_k and label bases are L(1-n)k where n is the=20 number of sets. 2) Check if k =3D m. If so, issue an error: "CE-ID k has been=20 allocated to two CE in VPN X (check CE at PE A)". Stop. 3) Check if S-Bm <=3D k < S-Rm. The received VPN information for a=20 set does not include the configured CE-ID. Save this=20 information. 4) Look through local 1 to n sets to find the set which contains=20 the CE ID m. Let this set be S-Rjk (Set range j of CE-ID k).=20 If none of the set contains this CE ID m, stop and issue a=20 warning: "Cannot communicate with CE m (PE A) of VPN X:=20 outside range". 5) Look in the appropriate table to see which label will get to=20 PE A. This is the "outer" label, Z. 6) The DLCI that CE-k will use to talk to CE-m is Dk[m]. The=20 "inner" label for sending packets to CE-m is (Lm + (k - S-Bm)). =20 The "inner" label on which to expect packets from CE-m=20 is (Ljk + (m - S-Bjk)).=20 7) Install a "route" such that packets from CE-k with DLCI Dk[m]=20 will be sent with outer label Z, inner label (Lm + (k - S-Bm)). Also, install a route such that packets received with=20 label (Lnk + (m - S-Bjk)) will be mapped to DLCI Dk[m] and be=20 sent to CE-k. 8) Activate DLCI Dk[m] to the CE. This can be done using LMI. If an advertisement is withdrawn, the appropriate DLCI must be de- activated, and the corresponding routes must be removed from the forwarding table. 5.1.2. Example of PE Advertisment Processing shah et al. page 10 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 Figure 3: Example Network Topology S0 S3 .............. .............. . . . . . +-----+ . . . . | CE0 |-----------+ . +-----+ . . +-----+ . | . | CE5 | . . . | . +--+--+ . . +-----+ . | . | . . | CE1 |-------+ | .......|...... . +-----+ . | | / . . | | / .............. | | / | | SP Network / .....|...|.............................../..... . | | / . . +-+---+-+ +-------+ / . . | PE0 |-------| P |-- | . . +-+---+-+ +-------+ \ | . . / \ \ +---+---+ . . | -----+ --| PE2 | . . | | +---+---+ . . | +---+---+ / . . | | PE1 | / . . | +---+---+ / . . | \ / . ...|.............|.............../............. | | / | | / | | / S1 | | S2 / .............. | ........|........../...... . . | . | | . . +-----+ . | . +--+--+ +--+--+ . . | CE2 |-----+ . | CE3 | | CE4 | . . +-----+ . . +-----+ +-----+ . . . . . .............. .......................... Consider the example network of Figure 3. Let the VPN connecting = S0, S1, S2 and S3 have a VPN id of 1. Suppose PE2 receives an=20 advertisement from PE0 for VPN 1, CE ID 0, CE-base =3D 4 with CE = range=20 R0 =3D 10 and label base L0 =3D 1000. Since PE2 is connected to = CE4=20 which is also in VPN 1, PE2 does the following: 0) Look up the configuration information associated with CE4. The=20 advertised encapsulation type matches the configured=20 encapsulation type (both are Frame Relay), so proceed.=20 shah et al. page 11 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 1) Let's suppose that CE4 has 2 sets. Set 1 with set base (S-B4(1)) = =3D 0, set range (S-R4(1)=3D 2, label base (L4(1)) =3D 2000 and set = 2=20 has set base (S-B4(2)) =3D 2, set range (S-R4(2)) =3D 10 and label=20 base (L4(2)) =3D 4000. The configured range R4 is 9, its DLCI list=20 D4[] is [ 107, 209, 265, 301, 414, 555, 654, 777, 888]. 2) CE0 and CE4 have ids 0 and 4 respectively, so step 2 of 5.1.1 is = skipped. 3) Since CE4's id is less than received range R0 (=3D 10) and = greater=20 than equal to CE-base =3D 4, step 3 of 5.1.1 is passed. CE0's id is = then matched in local set 1. As it turns out CE 0 is equal to=20 S-B4{1) (=3D 0) of set 1. Step 4 of 5.1.1 is passed. 4) Look in the appropriate table on PE2 to see which label will get = to PE0. Let the label be 10001. 5) The DLCI that CE4 will use to talk to CE0 is D4[0], i.e., 107.=20 The inner label for sending packets to CE0 is (4 - CE-base) equal=20 0, i.e. 1000. The inner label on which to expect packets from=20 CE0 is (0 - S-B4(1)) equal 0 which is (L4(1) + 0), i.e., 2000. 6) Install a "route" such that packets from CE4 with DLCI 107 will=20 be sent with outer label 10001, inner label 1000. Also, install a route such that packets received with label 2000 will=20 be mapped to DLCI 107 and be sent to CE4. 7) Activate DLCI 107 to CE4. Since CE5 is also attached to PE2, PE2 needs to do processing=20 similar to the above for CE5. Similarly, when PE0 receives an advertis ment from PE2 for VPN1,=20 CE4, with two sets, S-B4(1) =3D 0, S-R4(1) =3D 2, L4(1) =3D 2000 = and S- B4(2) =3D 2, S-R4(2) =3D 10, L4(2) =3D 4000. PE0 processes the=20 advertis0ment for CE0 (and CE1, which is also in VPN 1).=20 0) Look up the configuration information associated with CE0. The=20 advertised encapsulation type matches the configured=20 encapsulation type (both are Frame Relay), so proceed. 1) CE0 has two range sets. S-B0(1) =3D 0, S-R0(1) =3D 4 and label = base=20 L0(1) =3D 577. S-B0(2) =3D 4, S-R0(2) =3D 10 and label base L0(2) = =3D=20 1000. Its DLCI list D0[] is [100 - 109]. 2) CE0 and CE4 have ids 0 and 4 respectively, so step 2 of 5.1.1=20 is skipped. shah et al. page 12 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 3) CE0's ID is first checked in received set 1. Since CE-ID 0 is=20 greater than equal to S-B4(1) (=3D0) and is less than S-R4(1)(=3D = 2),=20 label base L4(1) of set 1 is selected. Similarly, received CE-ID=20 4 is checked against the local set 1. CE-ID 4 is greater than=20 equal to set base S-B0(1) (=3D 0) but not less than set range S- R0(1) (=3D 4), set 1 is not selected. Now, CE-ID 4 is checked=20 against local set 2. Since CE-ID 4 is greater than equal to set=20 base S-B0(2) (=3D 4) and less than set range S-R0(2) (=3D 10), = label=20 base L0(2) of set 2 is selected. 4) Let the outer label to reach PE2 be 9999. =20 5) The DLCI which CE0 will use to talk to CE4 is D0[4], i.e., 103.=20 The inner label for send packets to CE4 is L4(1) =3D 2000 + (CE-ID=20 ( =3D 0) - CE-Base ( =3D 0) 0), i.e., 2000 + (0 - 0) =3D 2000. The=20 inner label on which to expect the packets from CE4 is L0(2) =3D=20 1000 + CE-ID ( =3D 4) - CE-Base (=3D 4), i.e., 1000 + (4 - 4) =3D = 1000. 6) Install a "route" such that packets from CE0 with DLCI 104 will=20 be sent with outer label 9999, inner label 2000. Also, install a=20 route that packets received with label 1000 will be mapped to=20 DLCI 104 and be set to CE0. 7) Activate DLCI 103 to CE0. Note that the inner label of 2000, computed by PE0, for sending=20 packets from CE0 to CE4 is the same as what PE2 computed as the=20 incoming label for receiving packets originated at CE0 and destined = to CE4. Similarly, the inner label of 1000, computed by PE0, for=20 receiving packets from CE4 to CE0 is same what PE2 computed as the=20 outgoing label for sending packets originated at CE4 and destined = to=20 CE0. =20 6.0 Generalizing the VPN Topology In the Kompella [Mpls] draft, full mesh and hub and spoke type of=20 VPN topologies is described using the color value and spoke bit in=20 the connectivity field of the distributed VPN information. However, the spoke bit is available only when using the LDP signaling. Same type of VPN topologies can be created when using BGP as=20 signaling mechanism by creative ways of using the CE-Ids. For=20 example, in order to create a hub and spoke type of VPN topologies, = "hub" PE routers could be configured with CE-ID of the lowest = values and highest range and the "spoke" PE routers with higher CE-IDs and = the range of 1 or sum of the "hub" sites. The processing algorithm=20 described above will then have "spoke" PE routers not creating = layer=20 2 circuits among themseleves as the "spoke" CE-Ids would not fall=20 under the received range. shah et al. page 13 =0C Internet Draft draft-shah-mpls-l2vpn-ext-00.txt March 2001 It is also possible to create sub-VPN clusters by using CE-ID sub ranges. This would require additional configuration on a=20 per set basis where for each set, set-base and set-range is configured. With such configuration, all those CE-IDs that=20 fall within the configured sets would form connectivity with other. These type of methodologies does not incur any=20 further extensions to the protocol and in fact is the added=20 advantage of the extension proposed in this document. =20 7. Acknowledgements Some of the text in this document is "borrowed" from the base Kompella draft for completeness. We would like to thank Bill Townsend for reviewing the draft. 8. References [MPLS] Kompella et al., "MPLS based Layer 2 VPNs", draft-kompella- mpls-l2vpn-02.txt, November 2000. 9. Authors Information Himanshu Shah Tenor Networks 100 Nanog Park Acton, MA 01720 hshah@tenornetworks.com Xavier Briard Tenor Networks 100 Nanog Park Acton, MA 01720 xbriard@tenornetworks.com Jim Tsillas Tenor Networks 100 Nanog Park Acton, MA 01720 jtsillas@tenornetworks.com shah et al. page 14 ------_=_NextPart_000_01C0AB43.D671C474-- From owner-mpls@UU.NET Mon Mar 12 17:36:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23255 for ; Mon, 12 Mar 2001 17:36:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgby06073; Mon, 12 Mar 2001 22:34:10 GMT Received: by mail-control.mail.uu.net id QQkgby29013 for mpls-outgoing; Mon, 12 Mar 2001 22:33:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgby28998 for ; Mon, 12 Mar 2001 22:33:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgby18100 for ; Mon, 12 Mar 2001 22:32:44 GMT Received: from bru5-smtp-out2.be.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bru5-smtp-out2.be.uu.net [194.7.1.6]) id QQkgby11680 for ; Mon, 12 Mar 2001 22:32:44 GMT Received: from pentium (uu212-190-18-244.unknown.uunet.be [212.190.18.244]) by bru5-smtp-out2.be.uu.net (8.11.2/8.11.2) with SMTP id f2CMWbi18921; Mon, 12 Mar 2001 23:32:37 +0100 (MET) Message-ID: <000701c0ab43$7be46ca0$f412bed4@pentium> From: "Francis Arts" To: "Bora Akyol" Cc: , Subject: Expanded ERO draft (http://cell.onecall.net/mhonarc/mpls/current/msg00062.html) Date: Mon, 12 Mar 2001 23:26:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C0AB4B.DC2FF040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 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_0004_01C0AB4B.DC2FF040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Bora, I have a question concerning the use of the ingress IDs and how these = can be replaced using 2 ERO subobjects. The example I have in mind, is the one you mentioned: * 2 routers connected with 2 ethernet switches in the middle. * Each router has 2 interfaces - 1 to each ethenet switch. This case was one of the arguments for the addition of the egress ID to = the EERO subobject: The ingress LSR can then choose either of the 2 = egress interfaces for routing the LSP. Can the same argument be applied when traffic is flowing in the reverse = direction? That is, can the ingress ID just as well be useful here to = choose the proper ingress ID on which the explicitly routed LSP should = enter the node? [I do not see how this behavior can be achieved by using = 2 ERO subobjects.] Kind regards, Francis. ------------------ -------------------------------------------------------------------------= ------- [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread = Index]=20 Expanded ERO draft a.. From: Bora Akyol =20 b.. Date: Fri, 2 Mar 2001 13:03:10 -0800=20 c.. Cc: mpls@UU.NET, vkompella@JasmineNetworks.com=20 d.. In-Reply-To: <200103021926.LAA16080@kummer.juniper.net>=20 e.. References: <200103021926.LAA16080@kummer.juniper.net>=20 f.. X-Sender: akyol@avalon=20 Kireeti There are two reasons why it would be a good idea to add the router=20 ID to the ERO for numbered interfaces as well: 1) It makes the ERO consistent between numbered and unnumbered=20 objects. (Ok, this is a consistency issue) 2) It makes Abstract node lookup as described in RSVP-TE simpler for=20 the most common type objects (/32) as in you don't need to do it at=20 all. 3) By using the router ID in the numbered subobjects one can easily=20 catch errors in TE database, helps troubleshooting also in this case. It makes the common path processing faster. Regarding having both ingress and egress IDs. I still think that this=20 makes the ERO very precise and removes any ambiguity in creation of=20 these objects. For example, we currently create the egress interfaces=20 out of each node as the ERO, but we don't have any problem creating=20 an object that leaves nothing to guess-work. Regardless, you can=20 achieve the same thing by adding two ERO subobjects which wastes even=20 more bytes than our proposal. Instead, we can make the (I/E) bits on=20 our draft to signal three possibilities: - Both exist and are unnumbered - I exists and is unnumbered - I exists and is numbered (I may be missing a case here). So one can easily omit the ingress interface ID. To summarize, here is what I am proposing: I) Add router ID to both numbered and unnumbered subobjects. II) Improve the word alignments of the ERO subobjects as described in = EERO. I will be happy with (I). Bora At 11:26 AM -0800 3/2/01, Kireeti Kompella wrote: >Hi Vach, > >> I >> think it's great for debugging, too. You can look at an inflight = ERO and >> know exactly what it is supposed to do, without reference to a TED = or an >> LSDB. > >Okay, I buy this argument -- it makes trouble shooting easier. > >We've added Router ID to the unnumbered ERO subobject (see version 01, >just shipped to the IETF). Does this cover it? > >So, about EERO, the remaining questions are: >1) Why have router IDs for numbered subobjects? >2) Why have ingress and egress ids *all* the time? For the one > case of multiple multiaccess interfaces on a common subnet, > use two ERO subobjects. > >If you agree that the above two are not needed, we don't need a new >EERO object. > >Kireeti. a.. Follow-Ups:=20 a.. Expanded ERO draft=20 a.. From: Ben Black a.. References:=20 a.. Expanded ERO draft=20 a.. From: Kireeti Kompella b.. Expanded ERO draft=20 a.. From: Kireeti Kompella a.. Prev by Date: Standards for IP stats collection? (corrected)=20 b.. Next by Date: RSVP-TE draft-08=20 c.. Prev by thread: Expanded ERO draft=20 d.. Next by thread: Expanded ERO draft=20 e.. Index(es):=20 a.. Date=20 b.. Thread=20 ------=_NextPart_000_0004_01C0AB4B.DC2FF040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Expanded ERO draft
 
Hello Bora,
 
I have a question concerning the use = of the=20 ingress IDs and how these can be replaced using 2 ERO = subobjects.
 
The example I have in mind, is the = one you=20 mentioned:
* 2 routers connected with 2 = ethernet switches=20 in the middle.
* Each router = has 2=20 interfaces - 1 to each ethenet switch.
 
This case was one of the arguments = for the=20 addition of the egress ID to the EERO subobject: The ingress LSR can = then choose=20 either of the 2 egress interfaces for routing the LSP.
 
Can the same argument be applied when traffic is = flowing in=20 the reverse direction? That is, can the ingress ID just as well be = useful here=20 to choose the proper ingress ID on which the explicitly routed LSP = should enter=20 the node? [I do not see how this behavior can be achieved by using 2 ERO = subobjects.]
 
Kind regards,
 
    = Francis.
 
------------------
 
[Date Prev][Date = Next][Thread Prev][Thread Next][Date=20 Index][Thread = Index]
  • From: Bora Akyol <akyol@pluris.com>=20
  • Date: Fri, 2 Mar 2001 13:03:10 -0800=20
  • Cc: mpls@UU.NET, = vkompella@JasmineNetworks.c= om=20 =20
  • In-Reply-To: <200103021926.LAA16080@kummer.juniper.net>=20
  • References: <200103021926.LAA16080@kummer.juniper.net>=20
  • X-Sender: akyol@avalon = 

Kireeti

There are two reasons why it would be a good idea to add the router=20
ID to the ERO for numbered interfaces as well:

1) It makes the ERO consistent between numbered and unnumbered=20
objects. (Ok, this is a consistency issue)
2) It makes Abstract node lookup as described in RSVP-TE simpler for=20
the most common type objects (/32) as in you don't need to do it at=20
all.
3) By using the router ID in the numbered subobjects one can easily=20
catch errors in TE database, helps troubleshooting also in this case.

It makes the common path processing faster.


Regarding having both ingress and egress IDs. I still think that this=20
makes the ERO very precise and removes any ambiguity in creation of=20
these objects. For example, we currently create the egress interfaces=20
out of each node as the ERO, but we don't have any problem creating=20
an object that leaves nothing to guess-work. Regardless, you can=20
achieve the same thing by adding two ERO subobjects which wastes even=20
more bytes than our proposal. Instead, we can make the (I/E) bits on=20
our draft to signal three possibilities:

	- Both exist and are unnumbered
	- I exists and is unnumbered
	- I exists and is numbered
(I may be missing a case here).
So one can easily omit the ingress interface ID.

To summarize, here is what I am proposing:

I) Add router ID to both numbered and unnumbered subobjects.
II) Improve the word alignments of the ERO subobjects as described in =
EERO.

I will be happy with (I).

Bora

At 11:26 AM -0800 3/2/01, Kireeti Kompella wrote:
>Hi Vach,
>
>>  I
>>  think it's great for debugging, too.  You can look at an =
inflight ERO and
>>  know exactly what it is supposed to do, without reference to a =
TED or an
>>  LSDB.
>
>Okay, I buy this argument -- it makes trouble shooting easier.
>
>We've added Router ID to the unnumbered ERO subobject (see version =
01,
>just shipped to the IETF).  Does this cover it?
>
>So, about EERO, the remaining questions are:
>1) Why have router IDs for numbered subobjects?
>2) Why have ingress and egress ids *all* the time?  For the one
>    case of multiple multiaccess interfaces on a common subnet,
>    use two ERO subobjects.
>
>If you agree that the above two are not needed, we don't need a new
>EERO object.
>
>Kireeti.
=
------=_NextPart_000_0004_01C0AB4B.DC2FF040-- From owner-mpls@UU.NET Mon Mar 12 17:59:52 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23569 for ; Mon, 12 Mar 2001 17:59:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgbz14622; Mon, 12 Mar 2001 22:57:03 GMT Received: by mail-control.mail.uu.net id QQkgbz11037 for mpls-outgoing; Mon, 12 Mar 2001 22:56:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgbz11025 for ; Mon, 12 Mar 2001 22:56:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgbz05846 for ; Mon, 12 Mar 2001 22:55:03 GMT Received: from bru5-smtp-out1.be.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bru5-smtp-out1.be.uu.net [194.7.1.5]) id QQkgbz11914 for ; Mon, 12 Mar 2001 22:55:03 GMT Received: from pentium (uu212-190-18-244.unknown.uunet.be [212.190.18.244]) by bru5-smtp-out1.be.uu.net (8.11.2/8.11.2) with SMTP id f2CMstH03119; Mon, 12 Mar 2001 23:54:56 +0100 (MET) Message-ID: <002201c0ab46$99b7e4c0$f412bed4@pentium> From: "Francis Arts" To: "Bora Akyol" , , Cc: Subject: ERO draft Date: Mon, 12 Mar 2001 23:48:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C0AB4E.FA4FB3A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 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_001F_01C0AB4E.FA4FB3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Bora, Vach, Vishal, Please find included some comments to your = draft: 1) Section 2.1.3 - Abstract node. There is no L bit in the , as was the case in the = draft. Therefore, are the abstract = nodes always to be considered strict or loose in your draft? 2) Section 3.1 - explicitly routed LSPs w/o abstract nodes and w/o loose = routes. The text states that "the only check that needs to be performed during = EERO processing at each hop is for the node to see if the top of the = EERO stack points to itself and send the packet out of the interface = pointed to by ". However, should in this case each node also not check whether = or not the PATH message was received on the proper interface (identified = by the ingress ID in the subobject)? [I think this check would be needed = in each of the cases discussed in section 3 where an shows = up?] 3) Section 3.2 - explicitly routed LSPs with abstract nodes and w/o = loose routes. The text states that "an EERO object may begin and end with an abstract = node". When would an abstract node be used as the end of an EERO object? 4) Section 3. Are the manipulations (addition / removal) of subobjects in the EERO = object meant to be the same as those mentioned in the = draft? Or do you see deviations? 4) Contents of PHOP. =20 What is the contents of the PHOP object when sending a PATH message on = an unnumbered interface? Kind regards, Francis. ------=_NextPart_000_001F_01C0AB4E.FA4FB3A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello Bora, Vach, = Vishal,
 
Please find included some comments = to your=20 <draft-akyol-mpls-exp-ero> draft:
 
1) Section 2.1.3 - Abstract = node.
 
There is no L bit in the = <AN-HOP>, as was=20 the case in the <draft-ietf-mpls-rsvp-lsp-tunnel-08> draft. = Therefore, are=20 the abstract nodes always to be considered strict or loose in your=20 draft?
 
 
2) Section 3.1 - explicitly routed = LSPs w/o=20 abstract nodes and w/o loose routes.
 
The text states that "the only = check that=20 needs to be performed during EERO processing at each hop is for the node = to see=20 if the top of the EERO stack points to itself and send the packet out of = the=20 interface pointed to by <EERO-HOP>".
 
However, should in this case each <EERO-HOP> = node also=20 not check whether or not the PATH message was received on the proper = interface=20 (identified by the ingress ID in the subobject)? [I think this check = would be=20 needed in each of the cases discussed in section 3 where an = <EERO-HOP>=20 shows up?]
 
 
3) Section 3.2 - explicitly routed = LSPs with=20 abstract nodes and w/o loose routes.
 
The text states that "an EERO = object may=20 begin and end with an abstract node".
 
When would an abstract node be used as the end of an = EERO=20 object?
 
 
4) Section 3.
 
Are the manipulations (addition / = removal) of=20 subobjects in the EERO object meant to be the same as those mentioned in = the=20 <draft-ietf-mpls-rsvp-lsp-tunnel-08> draft? Or do you see=20 deviations?
 
 
4) Contents of PHOP.
 
What is the contents of the PHOP object when sending = a PATH=20 message on an unnumbered interface?
 
 
Kind regards,
 
   =20 Francis.
------=_NextPart_000_001F_01C0AB4E.FA4FB3A0-- From owner-mpls@UU.NET Mon Mar 12 18:05:57 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24049 for ; Mon, 12 Mar 2001 18:05:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgca22818; Mon, 12 Mar 2001 23:02:53 GMT Received: by mail-control.mail.uu.net id QQkgca21537 for mpls-outgoing; Mon, 12 Mar 2001 23:02:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgca21070 for ; Mon, 12 Mar 2001 23:02:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgca14849 for ; Mon, 12 Mar 2001 23:01:11 GMT Received: from bru5-smtp-out1.be.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bru5-smtp-out1.be.uu.net [194.7.1.5]) id QQkgca28436 for ; Mon, 12 Mar 2001 23:01:10 GMT Received: from pentium (uu212-190-18-244.unknown.uunet.be [212.190.18.244]) by bru5-smtp-out1.be.uu.net (8.11.2/8.11.2) with SMTP id f2CN16H03377; Tue, 13 Mar 2001 00:01:06 +0100 (MET) Message-ID: <002a01c0ab47$76a311c0$f412bed4@pentium> From: "Francis Arts" To: , Cc: Subject: draft-ietf-mpls-rsvp-unnum-01 Date: Mon, 12 Mar 2001 23:54:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C0AB4F.D75AEBC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 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_0027_01C0AB4F.D75AEBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Kireeti, Yakov, In the latest version of your draft you have added the router id to the = 'unnumbered Interface ID' subobject. This identifies an unnumbered = interface unambiguously in the network. The text of section 6 states that "the unnumbered interface ID subobject = MUST be strict". I have the following question: Is the restriction still needed for the = unnumbered interface ID objects to be strict? Or could they also be made = into loose nodes of the explicit route? Kind regards, Francis. ------=_NextPart_000_0027_01C0AB4F.D75AEBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello Kireeti, Yakov,
 
In the latest version of your draft you have added = the router=20 id to the 'unnumbered Interface ID' subobject. This identifies an = unnumbered=20 interface unambiguously in the network.
 
The text of section 6 states that "the = unnumbered=20 interface ID subobject MUST be strict".
 
I have the following question: Is the restriction = still needed=20 for the unnumbered interface ID objects to be strict? Or could they also = be made=20 into loose nodes of the explicit route?
 
Kind regards,
 
    = Francis.
------=_NextPart_000_0027_01C0AB4F.D75AEBC0-- From owner-mpls@UU.NET Mon Mar 12 20:32:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26925 for ; Mon, 12 Mar 2001 20:32:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgck26719; Tue, 13 Mar 2001 01:32:08 GMT Received: by mail-control.mail.uu.net id QQkgck16117 for mpls-outgoing; Tue, 13 Mar 2001 01:31:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgck16111 for ; Tue, 13 Mar 2001 01:31:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgck27133 for ; Tue, 13 Mar 2001 01:31:21 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgck16973 for ; Tue, 13 Mar 2001 01:31:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA01163 for mpls@uu.net; Mon, 12 Mar 2001 20:31:19 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgck16037 for ; Tue, 13 Mar 2001 01:30:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgck19929 for ; Tue, 13 Mar 2001 01:30:14 GMT Received: from smtprch1.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQkgck15583 for ; Tue, 13 Mar 2001 01:30:14 GMT Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 12 Mar 2001 19:29:46 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Mar 2001 19:27:39 -0600 Message-ID: From: "Laura Robertson" To: "'mpls@uu.net'" Date: Mon, 12 Mar 2001 19:27:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AB5C.C901C050" 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_01C0AB5C.C901C050 Content-Type: text/plain; charset="iso-8859-1" auth b9f40e15 subscribe mpls laurarob@nortelnetworks.com > Laura Robertson > Nortel Networks > National Account Engineer - Team Verizon * 972-362-3877 (ESN 442) > * 972-684-3735 > * laurarob@nortelnetworks.com > > > ------_=_NextPart_001_01C0AB5C.C901C050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

auth b9f40e15 subscribe mpls = laurarob@nortelnetworks.com


Laura = Robertson
Nortel = Networks
National = Account Engineer - Team Verizon
( 972-362-3877 (ESN 442)
2   = 972-684-3735
7  laurarob@nortelnetworks.com



------_=_NextPart_001_01C0AB5C.C901C050-- From owner-mpls@UU.NET Mon Mar 12 23:01:23 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00278 for ; Mon, 12 Mar 2001 23:01:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgcu28562; Tue, 13 Mar 2001 04:00:26 GMT Received: by mail-control.mail.uu.net id QQkgct28065 for mpls-outgoing; Tue, 13 Mar 2001 03:59:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgct28060 for ; Tue, 13 Mar 2001 03:59:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgct21563 for ; Tue, 13 Mar 2001 03:59:24 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkgct29338 for ; Tue, 13 Mar 2001 03:59:23 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA14911; Mon, 12 Mar 2001 19:59:21 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id TAA05403; Mon, 12 Mar 2001 19:59:21 -0800 (PST) Date: Mon, 12 Mar 2001 19:59:21 -0800 (PST) From: Kireeti Kompella Message-Id: <200103130359.TAA05403@kummer.juniper.net> To: hshah@tenornetworks.com, mpls@UU.NET, nbvpn@bbo.com Subject: Re: FW: New ID: draft-shah-mpls-l2vpn-ext-00.txt In-Reply-To: <6B190B34070BD411ACA000B0D0214E56993D42@newman.tenornet.com> Sender: owner-mpls@UU.NET Precedence: bulk Hi Himanshu, > I know I am late for draft submission for upcoming meeting, so I will > re-post after March 19. However, for those interested following is > the draft on extensions for MPLS based L2VPN. This idea was suggested to me by Juha Heinanen at the last IETF. Several of the authors have already discussed it, and will incorporate it in the next revision of the draft, along with several other changes. Kireeti. From owner-mpls@UU.NET Mon Mar 12 23:33:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00751 for ; Mon, 12 Mar 2001 23:33:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgcw10167; Tue, 13 Mar 2001 04:32:02 GMT Received: by mail-control.mail.uu.net id QQkgcw16325 for mpls-outgoing; Tue, 13 Mar 2001 04:31:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgcw16318 for ; Tue, 13 Mar 2001 04:31:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgcw04055 for ; Tue, 13 Mar 2001 04:31:14 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkgcw09987 for ; Tue, 13 Mar 2001 04:31:13 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id UAA16381; Mon, 12 Mar 2001 20:31:09 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id UAA05565; Mon, 12 Mar 2001 20:31:01 -0800 (PST) Date: Mon, 12 Mar 2001 20:31:01 -0800 (PST) From: Kireeti Kompella Message-Id: <200103130431.UAA05565@kummer.juniper.net> To: francis.arts@alcatel.be, mpls@UU.NET Subject: Re: draft-ietf-mpls-rsvp-unnum-01 In-Reply-To: <002a01c0ab47$76a311c0$f412bed4@pentium> Sender: owner-mpls@UU.NET Precedence: bulk Hi Francis, > The text of section 6 states that "the unnumbered interface ID subobject > MUST be strict". > > I have the following question: Is the restriction still needed for the > unnumbered interface ID objects to be strict? Or could they also be made > into loose nodes of the explicit route? What would it mean for an unnum object to be loose? R is the router ID, and I the interface index. Kireeti. From owner-mpls@UU.NET Tue Mar 13 08:04:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19079 for ; Tue, 13 Mar 2001 08:04:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgee13777; Tue, 13 Mar 2001 13:02:50 GMT Received: by mail-control.mail.uu.net id QQkgee05985 for mpls-outgoing; Tue, 13 Mar 2001 13:02:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgee05964 for ; Tue, 13 Mar 2001 13:02:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgee23347 for ; Tue, 13 Mar 2001 13:01:19 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkgee26783 for ; Tue, 13 Mar 2001 13:01:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA01879 for ; Tue, 13 Mar 2001 05:01:18 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA03236 for mpls@uu.net; Tue, 13 Mar 2001 08:01:16 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgbj02055 for ; Mon, 12 Mar 2001 18:54:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgbj18266 for ; Mon, 12 Mar 2001 18:53:57 GMT Received: from shared1-mail.whowhere.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: shared1-qin.whowhere.com [209.185.123.111]) id QQkgbj24941 for ; Mon, 12 Mar 2001 18:53:57 GMT Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Mon Mar 12 10:53:39 2001 To: mpls@UU.NET Date: Mon, 12 Mar 2001 19:23:39 +0030 From: "Manoj Kumar Juneja" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: manoj.juneja@eudoramail.com X-Expiredinmiddle: true X-Mailer: MailCity Service Subject: Doubts regarding LSP encoding type X-Sender-Ip: 38.204.3.195 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, The draft "draft-ietf-mpls-generalized-signalling-02.txt" defines different values for LSP encoding type. How does the implementation of a control plane differ if it receives the LSP encoding type as packet/SDH/Digital Wrapper/Lamda/Fiber etc. My understanding is that if the LSP encoding type is either of packet/ethernet, then label is just a 32 bit integer (as we already have in traditional MPLS). But if LSP encoding type is SDH, SONET then the label has to be in the form of {S, U, K, L, M} format. If the LSP encoding type is Lamda then the label represents the lamda (specific frequency). If LSP encoding type is fiber, then label is the fiberId itself. Can u please describe a scenario in which the LSP encoding type will be used as a "digital wrapper" ? Please clarify. Regards, manoj. Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-mpls@UU.NET Tue Mar 13 08:05:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19090 for ; Tue, 13 Mar 2001 08:05:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgee15125; Tue, 13 Mar 2001 13:03:36 GMT Received: by mail-control.mail.uu.net id QQkgee06387 for mpls-outgoing; Tue, 13 Mar 2001 13:03:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgee06133 for ; Tue, 13 Mar 2001 13:03:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgee26722 for ; Tue, 13 Mar 2001 13:02:49 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkgee29559 for ; Tue, 13 Mar 2001 13:02:48 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 FAA16922 for ; Tue, 13 Mar 2001 05:03:07 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA03287 for mpls@uu.net; Tue, 13 Mar 2001 08:02:47 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgdl04754 for ; Tue, 13 Mar 2001 08:16:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgdl09023 for ; Tue, 13 Mar 2001 08:15:36 GMT Received: from seralph10.essex.ac.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: seralph10.essex.ac.uk [155.245.240.160]) id QQkgdl29197 for ; Tue, 13 Mar 2001 08:15:35 GMT Received: from so-15354-x0.essex.ac.uk ([155.245.127.138] helo=so-18688-xo.china.com) by seralph10.essex.ac.uk with esmtp (Exim 3.13 #1) id 14cjxp-0003r0-00 for mpls@UU.NET; Tue, 13 Mar 2001 08:15:29 +0000 Message-Id: <5.0.2.1.2.20010313081735.00a1cdf0@pop.china.com> Date: Tue, 13 Mar 2001 08:17:39 +0000 To: mpls@UU.NET From: Norman Ng Subject: Network Restoration Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi to all, I am new mpls technology and I would like to know more about the network restoration and protection in MPLS. Could anyone let me know more information or references in this area. Also I have some queries, what happens if a MPLS network has a span failure or node failure in say a mesh network? Does it performs convergence like in OSPF?? If restoration is performed, how fast does it takes? Can this area be improved upon as I am looking into for an area to work on for my thesis. Thanks in advance for helping. Warmest Regards, Norman From owner-mpls@UU.NET Tue Mar 13 08:35:56 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19530 for ; Tue, 13 Mar 2001 08:35:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgeg27987; Tue, 13 Mar 2001 13:34:32 GMT Received: by mail-control.mail.uu.net id QQkgeg16065 for mpls-outgoing; Tue, 13 Mar 2001 13:34:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgeg16059 for ; Tue, 13 Mar 2001 13:34:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgeg07169 for ; Tue, 13 Mar 2001 13:34:05 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f151.law8.hotmail.com [216.33.241.151]) id QQkgeg26491 for ; Tue, 13 Mar 2001 13:34:05 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Mar 2001 05:34:04 -0800 Received: from 192.11.189.113 by lw8fd.law8.hotmail.msn.com with HTTP; Tue, 13 Mar 2001 13:34:04 GMT X-Originating-IP: [192.11.189.113] From: "Ashish Vyas" To: mpls@UU.NET Subject: doubt regarding transport address advertisement (LDP/RFC-3036) Date: Tue, 13 Mar 2001 13:34:04 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 13 Mar 2001 13:34:04.0980 (UTC) FILETIME=[45D27740:01C0ABC2] Sender: owner-mpls@UU.NET Precedence: bulk

The following sections are picked up from RFC 3036.

------------section 1-------------------

"An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency."

 ----------section 2--------------------------

LSR1 determines the transport addresses to be used at its end (A1) and LSR2's end (A2) of the LDP TCP connection. Address A1 is determined as follows:

a. If LSR1 uses the Transport Address optional object (TLV) in Hello's it sends to LSR2 to advertise an address, A1 is the address LSR1 advertises via the optional object;

b. If LSR1 does not use the Transport Address optional object, A1 is the source address used in Hellos it sends to LSR2.

---------------------end-of-section2-------

Suppose there are multiple links between LSR1 and LSR2. IF LSR1 does not use the Transport Address optional object, the Transport address will be the source address used in HELLOs it sends to LSR2 (as specified in section-2) and HELLOs sent on multiple links will be having different source addresses.

BUT RFC-3036 clearly says: "An LSR MUST advertise the same transport address in all Hellos that advertise the same label space". (Refer section-1 given above). How can it be done?

I hope my interpretation of given sctions are correct.

Regards

-Ashish


 

Get your FREE download of MSN Explorer at http://explorer.msn.com

From owner-mpls@UU.NET Tue Mar 13 08:52:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19950 for ; Tue, 13 Mar 2001 08:52:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgeh13961; Tue, 13 Mar 2001 13:50:00 GMT Received: by mail-control.mail.uu.net id QQkgeh17556 for mpls-outgoing; Tue, 13 Mar 2001 13:49:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgeh17541 for ; Tue, 13 Mar 2001 13:49:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgeh10792 for ; Tue, 13 Mar 2001 13:48:44 GMT Received: from nexen.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maelstrom.nexen.com [204.249.97.5]) id QQkgeh16780 for ; Tue, 13 Mar 2001 13:48:44 GMT Received: from phish.nexen.com (phish-99 [204.249.99.14]) by nexen.com (8.11.0/8.11.0) with ESMTP id f2DDmgj25793; Tue, 13 Mar 2001 08:48:42 -0500 (EST) Received: from nexen.com (caldara [204.249.97.50]) by phish.nexen.com (8.8.5/8.8.5) with ESMTP id IAA10962; Tue, 13 Mar 2001 08:48:36 -0500 (EST) Message-ID: <3AAD57EE.B46779FD@nexen.com> Date: Mon, 12 Mar 2001 18:12:46 -0500 From: Mark Stewart X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Gray CC: Hummel Heinrich , "'Dirk Ooms'" , davidm@galileo.co.il, "'mpls'" Subject: Re: AW: MPLS Multicast - Forwarding Plane References: <3AA79D83.188E9F3C@sandburst.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkgeh13961 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19950 Hi Eric I believe the historic reason for the multicast bit is that people thought it might be useful, and put it in just in case. At present it allows a canonical segregation of the label spaces for unicast and multicast, as there is a natural preference for upstream label assignment in the multicast case, and downstream label assignment in the unicast case it does have some advantages. ciao mark Eric Gray wrote: > Heinrich, > > I'm joining this discussion a bit late, I'm afraid, but I > do not understand why a 'multicast bit' would be useful. > I would assume that an LSP used for multicast would be > bound to a FEC for a corresponding multicast address > (or other addressing related approach). > > Are there situations in which this is not the case? > > If so, how would a multicast capable router know what > output interfaces to include - even when routing packets > not using MPLS labels and LSPs? > > -- > Eric Gray > > You wrote: > > > Because not every NHLFE, i.e. not every LSR, can support Multicast, I expressed my regrets some time ago not to have a "Multicast-Bit" in the label > > (nor in G-MPLS labels). > > > > Heinrich Hummel > > > > > -----Urspr> üngliche Nachricht----- > > > Von: Dirk Ooms [SMTP:Dirk.Ooms@alcatel.be] > > > Gesendet am: Montag, 12. Februar 2001 12:42 > > > An: davidm@galileo.co.il > > > Cc: 'mpls' > > > Betreff: Re: MPLS Multicast - Forwarding Plane > > > > > > David, > > > > > > Can you be more specific on the detail you are looking for? > > > > > > dirk > > > > > > David Melman wrote: > > > > > > > > RFC 3031 MPLS Architecture briefly mentions the forwarding plane processing in section 4.8. "MPLS and Multicast": > > > > > > > > "When a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label. If the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children." > > > > > > > > Is this addressed in any more detail in any other draft? > > > > > > > > Thanks, > > > > > > > > David > > > > > > -- From owner-mpls@UU.NET Tue Mar 13 09:01:15 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20136 for ; Tue, 13 Mar 2001 09:01:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgeh27864; Tue, 13 Mar 2001 13:59:43 GMT Received: by mail-control.mail.uu.net id QQkgeh18212 for mpls-outgoing; Tue, 13 Mar 2001 13:59:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgeh18207 for ; Tue, 13 Mar 2001 13:59:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgeh03628 for ; Tue, 13 Mar 2001 13:58:46 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgeh13825 for ; Tue, 13 Mar 2001 13:58:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA06358 for mpls@uu.net; Tue, 13 Mar 2001 08:58:45 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgeh17883 for ; Tue, 13 Mar 2001 13:54:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgeh11753 for ; Tue, 13 Mar 2001 13:53:42 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkgeh23663 for ; Tue, 13 Mar 2001 13:53:42 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA06105; Tue, 13 Mar 2001 05:54:00 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id IAA24076; Tue, 13 Mar 2001 08:53:40 -0500 (EST) Message-Id: <200103131353.IAA24076@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "Ashish Vyas" cc: mpls@UU.NET Subject: Re: doubt regarding transport address advertisement (LDP/RFC-3036) In-reply-to: Your message of "Tue, 13 Mar 2001 13:34:04." Date: Tue, 13 Mar 2001 08:53:40 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Ashish, >
>

The following sections are picked up from RFC 3036.

>

------------section 1-------------------

>

"An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency."

>

 ----------section 2--------------------------

>

LSR1 determines the transport addresses to be used at its end (A1) and LSR2's end (A2) of the LDP TCP connection. Address A1 is determined as follows:

>

a. If LSR1 uses the Transport Address optional object (TLV) in Hello's it sends to LSR2 to advertise an address, A1 is the address LSR1 advertises via the optional object;

>

b. If LSR1 does not use the Transport Address optional object, A1 is the source address used in Hellos it sends to LSR2.

>

---------------------end-of-section2-------

>

Suppose there are multiple links between LSR1 and LSR2. IF LSR1 does not use the Transport Address optional object, the Transport address will be the source address used in HELLOs it sends to LSR2 (as specified in section-2) and HELLOs sent on multiple links will be having different source addresses.

>

BUT RFC-3036 clearly says: "An LSR MUST advertise the same transport address in all Hellos that advertise the same label space". (Refer section-1 given above). How can it be done?

In this case, LSR1 is violating the protocol. Suppose links 1, 2, and 3 connect LSR1 and LSR2, and suppose LSR1 wants to advertise the same label space in the Hellos it sends on these links. If LSR1 omits the Transport Address TLV for Hellos on link 1, then it must use the Transport Address TLV for Hellos on links 2 and 3 to specify the source address used in its link 1 Hellos. Bob >

I hope my interpretation of given sctions are correct.

>

Regards

>

-Ashish

>


>
>
>
 

Get your FREE download of MSN Explorer at http://explorer.msn.com

From owner-mpls@UU.NET Tue Mar 13 10:32:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21934 for ; Tue, 13 Mar 2001 10:32:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgen07917; Tue, 13 Mar 2001 15:29:53 GMT Received: by mail-control.mail.uu.net id QQkgen27543 for mpls-outgoing; Tue, 13 Mar 2001 15:29:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgen27515 for ; Tue, 13 Mar 2001 15:29:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgen08139 for ; Tue, 13 Mar 2001 15:27:56 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f81.law11.hotmail.com [64.4.17.81]) id QQkgen05661 for ; Tue, 13 Mar 2001 15:27:56 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Mar 2001 07:27:55 -0800 Received: from 63.108.78.2 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 13 Mar 2001 15:27:55 GMT X-Originating-IP: [63.108.78.2] From: "Charles Smith" To: mpls@UU.NET Subject: RSVP Hello Protocol extension Date: Tue, 13 Mar 2001 15:27:55 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2001 15:27:55.0857 (UTC) FILETIME=[2D579410:01C0ABD2] Sender: owner-mpls@UU.NET Precedence: bulk MPLS community - I would like to obtain a clarification regarding the functionality of the RSVP Hello Protocol extension. The Hello Protocol is intended for use between adjacent neighbors. Let's assume we have the following simple topology: ingress ------------hello------------- egress Now let's assume LSR C fails. Obviously LSR B would realize the failure. Very straightforward I know. What does LSR B do next? Does this node initiate a PathErr message toward LER X? Any clarification would be appreciated. chas _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Mar 13 11:17:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22663 for ; Tue, 13 Mar 2001 11:17:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkger15226; Tue, 13 Mar 2001 16:15:33 GMT Received: by mail-control.mail.uu.net id QQkger17668 for mpls-outgoing; Tue, 13 Mar 2001 16:15:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgeq17483 for ; Tue, 13 Mar 2001 16:14:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgeq29288 for ; Tue, 13 Mar 2001 16:12:25 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkgeq13863 for ; Tue, 13 Mar 2001 16:12:25 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 LAA18760 for ; Tue, 13 Mar 2001 11:12:21 -0500 (EST) 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 LAA09807 for ; Tue, 13 Mar 2001 11:12:21 -0500 (EST) Message-ID: <3AAE46E0.B8000D59@marconi.com> Date: Tue, 13 Mar 2001 11:12:16 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP Hello Protocol extension References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Charles Smith wrote: > > I would like to obtain a clarification regarding the functionality of > the RSVP Hello Protocol extension. > > The Hello Protocol is intended for use between adjacent neighbors. > Let's assume we have the following simple topology: > > ingress ------------hello------------- egress > > Now let's assume LSR C fails. Obviously LSR B would realize the > failure. Very straightforward I know. > > What does LSR B do next? Does this node initiate a PathErr message > toward LER X? One valid way is to handle this in the exact same way it would detect other kinds of failures - like loss of carrier on the fiber or loss of state refreshes. This would involve purging all RSVP state from the B-C interface and sending out appropriate messages. This would probably involve some combination of PathTear (for any paths going from Y to X), ResvTear (for any reservations going from Y to X), and PathErr (for any paths going from X to Y). This is a draconian approach which will definitely work under all circumstances. But under some circumstances, it may be possible to use an approach with less overhead. For instance, suppose the instance ID sent by C changes. B knows that C has rebooted (or otherwise reset RSVP state), and has not failed. B knows that C no longer has any state, but may still be capable of supporting all of the LSPs that were previously signalled. In this case, B doesn't have to tear down everything. It can instead send out ResvTear messages (since its upstream no longer has a reservation) and immediately refresh all Path state - to re-establish this state on C. If B and C are using refresh reduction, B must also purge all shared message IDs and re-generate them during the next refresh, of course. Of course, this kind of handling would not be appropriate if Hello messages are timing out. In that case, we don't know that C is still operational, and we must act as if it has failed - and tear down all state involving LSR C. -- David From owner-mpls@UU.NET Tue Mar 13 11:23:23 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22774 for ; Tue, 13 Mar 2001 11:23:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkger15107; Tue, 13 Mar 2001 16:21:19 GMT Received: by mail-control.mail.uu.net id QQkger18383 for mpls-outgoing; Tue, 13 Mar 2001 16:20:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkger18348 for ; Tue, 13 Mar 2001 16:20:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkger00787 for ; Tue, 13 Mar 2001 16:18:22 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkger09166 for ; Tue, 13 Mar 2001 16:18:22 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id B8C7A94006; Tue, 13 Mar 2001 11:18:21 -0500 (EST) Message-ID: <3AAE484D.D489F28E@sandburst.com> Date: Tue, 13 Mar 2001 11:18:21 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Norman Ng Cc: mpls@UU.NET Subject: Re: Network Restoration References: <5.0.2.1.2.20010313081735.00a1cdf0@pop.china.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Norman, The MPLS working group charter web site has a lot of information that might be useful to a newbie. The URL is: http://www.ietf.cnri.reston.va.us/html.charters/mpls-charter.html One of the most useful things listed there is the mail archive location: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html You might also want to check out the Internet Drafts site: http://www.ietf.cnri.reston.va.us/ids.by.wg/mpls.html -- Eric Gray You wrote in part: > Hi to all, I am new mpls technology and I would like to know more about the > network restoration and protection in MPLS. Could anyone let me know more > information or references in this area. > > > ... > > Norman From owner-mpls@UU.NET Tue Mar 13 11:50:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23364 for ; Tue, 13 Mar 2001 11:50:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkget17625; Tue, 13 Mar 2001 16:48:37 GMT Received: by mail-control.mail.uu.net id QQkget20638 for mpls-outgoing; Tue, 13 Mar 2001 16:48:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkget20614 for ; Tue, 13 Mar 2001 16:47:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkget10897 for ; Tue, 13 Mar 2001 16:45:48 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkget02627 for ; Tue, 13 Mar 2001 16:45:48 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id C15C79400A; Tue, 13 Mar 2001 11:45:47 -0500 (EST) Message-ID: <3AAE4EBB.2A5C7EA7@sandburst.com> Date: Tue, 13 Mar 2001 11:45:47 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Bob Thomas Cc: Ashish Vyas , mpls@UU.NET Subject: Re: doubt regarding transport address advertisement (LDP/RFC-3036) References: <200103131353.IAA24076@rhthomas-sun2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alternatively, for implementations that can do so, the implementer can set the IP address which will be used in sending the hello messages on a set of interfaces such that the resulting transport address is the same. There are more difficulties to overcome in using this approach, however, than there are in Bob's suggested approach. -- Eric Gray Bob Thomas wrote: > Ashish, > > >
> >

The following sections are picked up from RFC 3036.

> >

------------section 1-------------------

> >

"An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency."

> >

 ----------section 2--------------------------

> >

LSR1 determines the transport addresses to be used at its end (A1) and LSR2's end (A2) of the LDP TCP connection. Address A1 is determined as follows:

> >

a. If LSR1 uses the Transport Address optional object (TLV) in Hello's it sends to LSR2 to advertise an address, A1 is the address LSR1 advertises via the optional object;

> >

b. If LSR1 does not use the Transport Address optional object, A1 is the source address used in Hellos it sends to LSR2.

> >

---------------------end-of-section2-------

> >

Suppose there are multiple links between LSR1 and LSR2. IF LSR1 does not use the Transport Address optional object, the Transport address will be the source address used in HELLOs it sends to LSR2 (as specified in section-2) and HELLOs sent on multiple links will be having different source addresses.

> >

BUT RFC-3036 clearly says: "An LSR MUST advertise the same transport address in all Hellos that advertise the same label space". (Refer section-1 given above). How can it be done?

> > In this case, LSR1 is violating the protocol. > > Suppose links 1, 2, and 3 connect LSR1 and LSR2, and suppose LSR1 wants to > advertise the same label space in the Hellos it sends on these links. > > If LSR1 omits the Transport Address TLV for Hellos on link 1, then it > must use the Transport Address TLV for Hellos on links 2 and 3 to > specify the source address used in its link 1 Hellos. > > Bob > > >

I hope my interpretation of given sctions are correct.

> >

Regards

> >

-Ashish

> >


> >
> >
> >
 

Get your FREE download of MSN Explorer at http://explorer.msn.com

From owner-mpls@UU.NET Tue Mar 13 12:33:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24576 for ; Tue, 13 Mar 2001 12:33:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgew23649; Tue, 13 Mar 2001 17:30:54 GMT Received: by mail-control.mail.uu.net id QQkgew09946 for mpls-outgoing; Tue, 13 Mar 2001 17:30:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgew09941 for ; Tue, 13 Mar 2001 17:30:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgev18541 for ; Tue, 13 Mar 2001 17:28:13 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgev20228 for ; Tue, 13 Mar 2001 17:28:12 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA28237 for mpls@uu.net; Tue, 13 Mar 2001 12:28:11 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkgev09574 for ; Tue, 13 Mar 2001 17:23:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgev27890 for ; Tue, 13 Mar 2001 17:23:19 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkgev08784 for ; Tue, 13 Mar 2001 17:23:19 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29666; Tue, 13 Mar 2001 09:23:22 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA25249; Tue, 13 Mar 2001 12:23:17 -0500 (EST) Message-Id: <200103131723.MAA25249@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: Eric Gray cc: Ashish Vyas , mpls@UU.NET Subject: Re: doubt regarding transport address advertisement (LDP/RFC-3036) In-reply-to: Your message of "Tue, 13 Mar 2001 11:45:47 EST." <3AAE4EBB.2A5C7EA7@sandburst.com> Date: Tue, 13 Mar 2001 12:23:17 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk > Alternatively, for implementations that can do so, the > implementer can set the IP address which will be used > in sending the hello messages on a set of interfaces > such that the resulting transport address is the same. Agreed. > There are more difficulties to overcome in using this > approach, however, than there are in Bob's suggested > approach. Bob From owner-mpls@UU.NET Tue Mar 13 17:03:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29105 for ; Tue, 13 Mar 2001 17:03:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgfo28722; Tue, 13 Mar 2001 22:02:06 GMT Received: by mail-control.mail.uu.net id QQkgfo14043 for mpls-outgoing; Tue, 13 Mar 2001 22:01:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgfo13717 for ; Tue, 13 Mar 2001 22:01:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgfo08945 for ; Tue, 13 Mar 2001 22:01:13 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgfo26545 for ; Tue, 13 Mar 2001 22:01:12 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA20976 for mpls@uu.net; Tue, 13 Mar 2001 17:01:11 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgfo12126 for ; Tue, 13 Mar 2001 22:00:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgfn20049 for ; Tue, 13 Mar 2001 21:59:20 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkgfn20941 for ; Tue, 13 Mar 2001 21:59:19 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA10715; Tue, 13 Mar 2001 16:59:18 -0500 (EST) Message-Id: <200103132159.QAA10715@pilgrim.cisco.com> To: mpls@UU.NET Cc: agenda@ietf.org Subject: Draft MPLS Agenda Date: Tue, 13 Mar 2001 16:59:18 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk ====================================================================== MPLS Agenda Thursday, March 22, 2001 ====================================================================== Agenda Bash and Document Status Chairs 10 Report from CCAMP on GMPLS Lou Berger 5 MPLS Recovery Framework Fifi Hellstrand 15 RSVP Label Allocation for Backup Tunnels George Swallow 10 LDP Fault Tollerance Philip Mathews 10 An Expanded ERO for RSVP-TE Bora Akyol 10 TTL Processing in MPLS networks Bora Akyol 10 TTLProcessing expansion for 1-hop LSP Satoru Matsushima 5 LDP End-to-end Authorization Olivier Paridaens 10 Secure MPLS Tissa Senevirath 10 Multicast Traffic Engineering Dirk Ooms 10 MPLS OAM Shahram Davari 10 Note: The last three presentations are beyond the scope of the current MPLS charter. The presentations are being entertained to help assess the IETF community's intrest in them. ====================================================================== From owner-mpls@UU.NET Wed Mar 14 01:12:47 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06226 for ; Wed, 14 Mar 2001 01:12:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkggu04846; Wed, 14 Mar 2001 06:12:05 GMT Received: by mail-control.mail.uu.net id QQkggu18974 for mpls-outgoing; Wed, 14 Mar 2001 06:11:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkggu18966 for ; Wed, 14 Mar 2001 06:11:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkggu27740 for ; Wed, 14 Mar 2001 06:11:22 GMT Received: from bru5-smtp-out2.be.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bru5-smtp-out2.be.uu.net [194.7.1.6]) id QQkggu04537 for ; Wed, 14 Mar 2001 06:11:21 GMT Received: from pentium (uu212-190-0-9.unknown.uunet.be [212.190.0.9]) by bru5-smtp-out2.be.uu.net (8.11.2/8.11.2) with SMTP id f2E6BBi12229; Wed, 14 Mar 2001 07:11:12 +0100 (MET) Message-ID: <001201c0ac4c$b50a0a80$0900bed4@pentium> From: "Francis Arts" To: Cc: Subject: Re: draft-ietf-mpls-rsvp-unnum-01 Date: Wed, 14 Mar 2001 07:05:00 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C0AC55.15A052C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 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_000F_01C0AC55.15A052C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kireeti, > What would it mean for an unnum object to be loose? R is the = router=20 > ID, and I the interface index. Please find included my reply. Kind regards, Francis. ---------------------- Next the following reference figure is used: * Rprior -- (R, L) -- Rnext is part of the explicit route specified in = the ERO object. * (R, L) is a subobject of the ERO with L an unnumbered interface. * Rprior is the abstract node preceding (R, L) in the ERO object. * Rnext is the abstract node succeeding (R, L) in the ERO object. 1) Meaning of unnum object to be loose. =20 A 'loose unnum object ' would mean that the LSP can pass = intermediate nodes between Rprior and R. This would be in line with the = meaning of the L bit as defined in the = draft: * Section 4.3.3.1 of states that there = can be additional nodes between a loose node and the prior abstract in = the EROnode (no reference is made to the succeeding abstract node in the = ERO). 2)=20 If my understanding is correct, you propose not to allow intermediate = nodes between R and Rnext in the ERO. If this is indeed the case, I = propose to add an explicit statement: "In an ERO an 'unnumbered interface id' subobject cannot be followed by = a loose abstract node." Questions =3D=3D=3D=3D=3D=3D=3D=3D 1) Check in downstream node. =20 Section 6.2 of your draft proposes to do a = check on the 'unnumbered interface id' subobject in the receiving node. =20 Is this check done to ensure that the receiving node is 'part' of the = first subobject in the ERO as described in , = so that the receiving node accepts the ERO? =20 2) Contents of 'unnumbered interface id' subobject. I have the following consideration: * Consider an ERO consisting of a series of strict and loose subobjects = identified by a full 32 bit IP address (no shorter prefixes). This = series of IP addresses identifies a set of interfaces via which the LSP = has to pass. According to my understanding an IP address in this series = identifies not only the node to pass but also the interface via which = the LSP should enter the node (not leave the node). Following this approach, should we then use in the 'unnumbered interface = id' subobject a reference to the incoming interface, rather than a = reference to the outgoing interface? --------------------- Kireeti Kompella wrote: Hi Francis, > The text of section 6 states that "the unnumbered interface ID = subobject > MUST be strict". >=20 > I have the following question: Is the restriction still needed for the > unnumbered interface ID objects to be strict? Or could they also be = made > into loose nodes of the explicit route? What would it mean for an unnum object to be loose? R is the router ID, and I the interface index. Kireeti. ------=_NextPart_000_000F_01C0AC55.15A052C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi Kireeti,
 
> What would it mean for an unnum object <R, I> to be = loose? =20 R is the router
> ID, and I the interface index.
 
Please find included my reply.
 
Kind regards,
 
    = Francis.
 
----------------------
 
Next the following reference figure = is=20 used:
 
* Rprior -- (R, L) -- Rnext is part of the explicit = route=20 specified in the ERO object.
* (R, L) is a subobject of the ERO with L an = unnumbered=20 interface.
* Rprior is the abstract node preceding (R, L) in = the ERO=20 object.
* Rnext is the abstract node succeeding (R, L) in = the ERO=20 object.
 
 
1) Meaning of unnum object <R, = L> to be=20 loose.
 
A 'loose unnum object <R, L>' would mean that = the LSP=20 can pass intermediate nodes between Rprior and R. This would be in line = with the=20 meaning of the L bit as defined in the = <draft-ietf-mpls-rsvp-lsp-tunnel>=20 draft:
* Section=20 4.3.3.1 of <draft-ietf-mpls-rsvp-lsp-tunnel> states that there can = be=20 additional nodes between a loose node and the prior abstract  in = the=20 EROnode (no reference is made to the succeeding abstract node in the=20 ERO).
 
 
2)
 
If my understanding is correct, you = propose not=20 to allow intermediate nodes between R and Rnext in the ERO. If this is = indeed=20 the case, I propose to add an explicit statement:
"In an = ERO an=20 'unnumbered interface id' subobject cannot be followed by a loose = abstract=20 node."
 
 
 
Questions
=3D=3D=3D=3D=3D=3D=3D=3D
 
1) Check in downstream = node.
 
Section 6.2 of your draft=20 <draft-ietf-mpls-rsvp-unnum> proposes to do a check on the = 'unnumbered=20 interface id' subobject in the receiving node.
 
Is this check done to ensure that the receiving node = is 'part'=20 of the first subobject in the ERO as described in=20 <draft-ietf-mpls-rsvp-unnum>, so that the receiving node accepts = the=20 ERO?
 
 
2) Contents of 'unnumbered interface id'=20 subobject.
 
I have the following consideration:
* Consider an ERO consisting of a series of strict = and loose=20 subobjects identified by a full 32 bit IP address (no shorter prefixes). = This=20 series of  IP addresses identifies a set of interfaces via which = the LSP=20 has to pass. According to my understanding an IP address in this series=20 identifies not only the node to pass but also the interface via which = the LSP=20 should enter the node (not leave the node).
 
Following this approach, should we then use in the = 'unnumbered=20 interface id' subobject a reference to the incoming interface, rather = than a=20 reference to the outgoing interface?
 
 
---------------------
 
Kireeti Kompella wrote:
Hi Francis,

> The text of section 6 states that "the unnumbered interface ID =
subobject
> MUST be strict".
>=20
> I have the following question: Is the restriction still needed for =
the
> unnumbered interface ID objects to be strict? Or could they also be =
made
> into loose nodes of the explicit route?

What would it mean for an unnum object <R, I> to be loose?  R is =
the
router ID, and I the interface index.

Kireeti.

------=_NextPart_000_000F_01C0AC55.15A052C0-- From owner-mpls@UU.NET Wed Mar 14 02:54:55 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20672 for ; Wed, 14 Mar 2001 02:54:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkghb02983; Wed, 14 Mar 2001 07:53:58 GMT Received: by mail-control.mail.uu.net id QQkghb15153 for mpls-outgoing; Wed, 14 Mar 2001 07:53:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkghb15140 for ; Wed, 14 Mar 2001 07:53:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkghb23503 for ; Wed, 14 Mar 2001 07:53:25 GMT From: richard.crouch@vf.vodafone.co.uk Received: from igate1.vodafone.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: igate.vodafone.co.uk [194.62.232.65]) id QQkghb01588 for ; Wed, 14 Mar 2001 07:53:25 GMT Received: by igate1.vodafone.co.uk; (8.8.8/1.3/10May95) id HAA27888; Wed, 14 Mar 2001 07:53:24 GMT Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 14 Mar 2001 07:53:28 +0000 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Mar 2001 07:50:51 -0000 Message-Id: <1763F57BB8BAD211B06500A0C9E5D9200366C710@barking.vfl.vodafone> To: mpls@UU.NET Subject: Can RSVP distribution of labels be driven by the IGP ? Date: Wed, 14 Mar 2001 07:50:49 -0000 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 LDP is 'classically' the method for distribution of labels for an MPLS network where the LSPs are created to reflect the IGP running in the network, for hop-by-hop, unicast routing. I understand that there are (a number of) extensions to RSVP signalling protocol to allow it to also distribute labels, most notably when trying to overide the LSP path creation driven by the IGP, e.g. to realise constraint based routing. Q1: Can RSVP be operated in a mode whereby it acts just like LDP (with the same scalability i.e. no hand-crafting of LSPs) in that it is used purely for the distribution of labels that reflect the IGP (i.e. needs to match the basic functionality of LDP) ? Q2: If the answer to Q1 above is "yes", then would this permit a architecture to support 2547bis IP VPNs where MP-iBGP is used to propagate the inner label and RSVP extensions are used to propagate the outer (PE to PE) label, (again with the same order of magnitude of scalability) as a MP-iBGP+LDP architecture ? [I am not so concerned about whether 2547bis mandates or not the use of LDP towards the PE]. The thinking here is that if LSP 'protection' is required from PE to PE (i.e. certain VPNs contained mission-critical traffic), then RSVP extensions plus could provide this mechanism, however I have heard of some architectures where "LDP is tunnelled across an RSVP TE core" and this would imply to me that such an architecture could not provide LSP protection from PE to PE. Any clarifications on the above welcome. Richard Crouch, Core Network Development (Technology), Vodafone Limited, United Kingdom. tel +44(0)1635 676478 fax +44(0)1635 231792 vodafone +44(0)7899 728963 richard.crouch@vf.vodafone.co.uk From owner-mpls@UU.NET Wed Mar 14 09:31:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23997 for ; Wed, 14 Mar 2001 09:31:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgib18743; Wed, 14 Mar 2001 14:29:52 GMT Received: by mail-control.mail.uu.net id QQkgib14270 for mpls-outgoing; Wed, 14 Mar 2001 14:29:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgib14262 for ; Wed, 14 Mar 2001 14:29:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgib01247 for ; Wed, 14 Mar 2001 14:27:44 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQkgib07156 for ; Wed, 14 Mar 2001 14:27:43 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Wed, 14 Mar 2001 13:29:13 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 14 Mar 2001 13:29:03 -0000 Message-ID: To: xuyg@lucent.com, mpls@UU.NET, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com Cc: evarma@lucent.com Subject: RE: Three GMPLS related IDs Date: Wed, 14 Mar 2001 13:29:06 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Yangguang, you wrote 05 March 2001 14:29: > FYI, three GMPLS related IDs have been submitted. > > Architecture: > http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0 0.txt > >Signaling: >http://www.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-reques t-01.txt >http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-reorg-00.txt > >Comments are welcomed. Here are my observations on the sig-reorg and arch-intra-domain IDs (I could not open the label-request one): sig-reorg ID: 1 I noticed that NSAPs are mentioned in 6.2. Yes, I think this form of global addressing will be of considerable interest and importance to several carriers and should be included. It is something we are currently looking closely at and almost certainly will require to be supported. 2 The 'connection ID' noted in para 7.2.2 seems to be the same (similar?) to a trail termination identifier and, as noted, requires global uniqueness. I noted that you have this 'TBD' wrt size/format.....this seems a sensible decision since something larger that 32 bits will surely be required here. 3 I was a little unclear regarding the requirement given in the 1st bullet in para 9.1. Agree that user and control plane *networks* can (and will usually) be disjoint....indeed the control-plane network *must* only take its survivability design cues from the duct network, since only that layer can define the inherited real disjoint connectivity. Further, both the control plane and user plane network need their own OAM....and in the control plane not only is this for the 'physical transport' aspects, but also on a per protocol-type, ie the signalling protocol will have different failure modes to the routing protocol. One feature that is required however, is that user-plane failures can map to control-plane actions for invoking restoration (the reverse of this is clearly not true)...for example to restore S-PVC-like user-plane trails (see also point 5 below). So I would like to see these types of relationship made more clear. 4 A further observation wrt the above is that it seems you are advocating that all failures be conveyed by control-plane message 'events'. Are you suggesting that (at least) the 3 distinct areas of (i) user-plane failures, (ii) signalling protocol failures and (iii) routing protocol failures all get 'merged' into some generic form of event notification? I would have thought that one would need notification (and general defect handling) per protocol type, and that this would be a function of that protocol only since the failure modes of each would be different (and if one changes one protocol one would not want to create backwards compatibility issues with another). Further, if some aspects of the control-plane fail I would still expect the user-plane defect handling to carry on as an autonomous function....for example, the sending of a FDI into client layers to suppress alarm storms and protect user-plane traffic, eg squelch traffic on misrouting if trail ID mismatch. I am not sure we would want to make this low-level action dependent on a 'healthy control-plane'....and this seems quite important when one has a server->client adaptation function between 2 different technologies, eg OTN layer->SDH layer, and where a 'common control-plane' might not be appropriate across such a (different operator domain) boundary....a point you indeed make in para 4 in the Arch-intra-domain ID. Can you please explain the intent of this section more clearly and comment on the above points, including the network management of the control-plane ....maybe you have some new ideas here that are worth exploring further? Arch-intra-domain ID: Note - I like this paper in general, and I guess the reason for this is that several operators have input (requirements) to it and it is not just sourced from vendors. 5 A control-plane for CO transport networks is not a new idea. Indeed, the original designers of SDH (and esp my BT colleague Andy Reid and Mike Sexton now of Alcatel) tried to do this for SDH about 12 years ago....maybe a bit ahead of its time then. However, the key point I wanted to make here is that simply automating the control-plane is not necessarily the key issue for improving the speed of provision (this is certainly true for us).....it is all the associated OSS/service-suround processes (eg order handling, testing (which is more than a quick LMP-like connectivity verification), billing, etc) that go along with this to create a service. These points are also very well made in section 3 of draft-bms-optical-sdhsonet-mpls-control-frmwrk-00.txt I have noted. BTW - we have far more interest in S-PVC equivalent services than SVC equivalent services, at least initially. I can't speak for other carriers but I would be surprised if they thought otherwise. The advantages of S-PVCs come from the fact that there is no need: - to develop new billing systems - no new interfaces to billing systems - no need to solve all the naming issues - low risk security issues - solve all the call admission control mechanisms - etc Yet S-PVCs immediately open up the possibility of much faster provisioning; though in BT's case what we have in our network management systems already is pretty fast in itself. And as a subset of the functions that are needed to implement a switched service it will obviously be easier to implement. Thinking about the further concerns a carrier would have to address in a connection oriented switched-network, there needs to be a consideration of blocking probability and users having connection requests refused, ie a GoS metric. The result is that transport networks currently designed around high utilisation with long-holding connections need to be redesigned around ensuring a large enough pool of free capacity. So, in addition to having to address the above issues up-front with SVC-like services, carriers would also be forced to define a 'erlang/pricing model' for something akin to a Gbit PSTN! Depending upon the number of circuits and the distribution of traffic holding times it may not be possible to apply simply erlang theory as is, but rather some modifications will be required.....and the demand model will obviously be an interdependent function of the pricing model. 6 Noted the point in para 4.2 regarding ENE 'having to maintain source/sink LSP inventory', but the SNE also needs to maintain its server->client layer adaptation mappings....so that on failure the correct FDI information can be sent forward into all affected clients (and this process should recurse for clients of those clients, etc). 7 In section 5.3 on path selection source (ERO) and hop-hop routing are compared. However, the biggest advantage of source routing is not noted strongly enough.....and that is the fact that one does not need to wait until a failure to calculate an alternative route from the link-state database. For very important routes one can pre-calculate an alternative path and reserve resources, so restoration is very fast. This leads me to the next point here. 8 Although not covered explicitly in this paper, I think something needs to be said about pre-emtion/bumping. We have extensive experience of priority selected pre-emption/bumping schemes. And this experience leads us to have a requirement that we must be able to turn-off any such schemes. Why? Well, it only comes into any significant effect at high utilisations. But, because even small changes of loading around the 'congestion knee' can cause large swings in behaviour, it is at this time that predicting its effects can be most difficult, and a single failure event can cause multiple consequential failures as the bumping scheme ripples out. We don't mind dumping 'extra' traffic, but once dumped there is no way we would want this to then dump some even lower priority traffic. However, I clearly would not wish to stop anyone wanting such a scheme to try it out and discover its usefulness for themselves. Our requirement therefore is (i) an ability to turn-off any bumping based on priority, but (ii) an ability to select the priority of restoration post failure between different trails. BTW - Although the largest BW trails seem like they should be restored 1st (if the most efficient packing density is the sole criterion), this may not be the case and we would want to identify trail restoration priority irrespective of BW. 9 In section 5.3.3 you are hinting at quite an important point regarding routing protocols. That is, the attributes of a routing protocol for an OTN will be quite different to that needed for SDH....or indeed IP. This leads to the question - do we create one all-embracing routing protocol for all technologies (and have lots of extensions and redundancies) or do we have different (specifically tailored) routing protocols for different technologies? We can also say the same, and perhaps more strongly, about signalling protocols. And indeed also addressing.....this facet definitely requires independent address spaces per distinct layer network even if based on the same generic structure. The key point is here is that not only are these control-plane facets 'different' for different layer networks, but they are also orthogonal *within* a layer network.....a point which seems to get glossed over quite regularly. This is not to decry any particular choice of addressing/signalling/routing protocol combination, just to point out that it is not a logical way of reasoning to say that either (i) all layers get treated the same or (ii) *if* you choose addressing schema X you *must* have signalling protocol Y and you *must* have routing protocol Z. Indeed for true CO fabrics like an OTN or SDH, it is very hard to agree to arguments that say it must be v4 (or v6) addressing and it must be RSVP (indeed it isn't since we also have CR_LDP) and it must be OSPF (and again indeed it isn't since we also have IS-IS).....but for the NNI BGP seems the only choice. I have yet to hear what is technically wrong with a combination of NSAPs, PNNI signalling and IS-IS/BGP...and on the face of it, these would appear far more logical choices given the nature of the beast they are controlling; noting that for S-PVC-like services this would also seem like a more 'off-the-shelf' solution. 10 In section 5.4.1.5 'actions' on trails are defined. For a CO network with fixed BW selection at trail creation time it is very hard to see what a 'modify' action could be....other than perhaps a change of restoration priority and/or change of dedicated back-up trail/resource. If there is any notion of (working) BW change here (be it a scalar magnitude change, ie same route, or a vector change, ie new route (with or without a scalar magnitude change)), it would seem to me that this is really a new pair of 'create_new->switch_to_new->delete_old' actions. I note however that this has been marked as TBD, but I think it would help if it was made clear that BW changes cannot (IMO) be a single 'modify' action. 11 In section 5.4.3.1 you describe the 4 main stages of prot-sw/restoration. I agree. But please don't overlook these facts that are relevant to the first item of failure detection: - 1st, we must identify all failure modes - 2nd, we must describe their entry/exit criteria - 3rd, we must take correct consequent actions, eg FDI upwards to stop alarm storms, BDI backward (if single ended visibility of both directions needed), squelch traffic if trail ID mismatch (important to protect customer traffic...so this is a sort of security consideration, but it also impacts billing etc) - 4th, we need to know/define what constitutes up and down states of the trail.....this defines the 2 aspects of availability SLA and the QoS SLA, where the latter only has meaning once the former is defined (ie only valid in up-state) and will generally be based on the defect handling covered by points 1st-3rd above. See our draft on MPLS OAM (packet level) where we cover the above for an example of what is required in the user-plane: http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt We need a similar approach for the lower transport layers....and note that there should be some attempt at metric/objective harmonisation across the layers in order for any measurements/SLAs taken/applied at each layer to have some cross-layer relative significance. neil From owner-mpls@UU.NET Wed Mar 14 09:33:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24020 for ; Wed, 14 Mar 2001 09:33:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgic13715; Wed, 14 Mar 2001 14:30:45 GMT Received: by mail-control.mail.uu.net id QQkgic14341 for mpls-outgoing; Wed, 14 Mar 2001 14:30:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgic14325 for ; Wed, 14 Mar 2001 14:30:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgib04674 for ; Wed, 14 Mar 2001 14:29:14 GMT Received: from winstar.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-vau.winstar.com [63.142.215.140]) id QQkgib11384 for ; Wed, 14 Mar 2001 14:29:14 GMT Received: from vaaws032382 ([10.1.183.46]) by winstar.com (8.9.3/8.9.1) with SMTP id JAA06420; Wed, 14 Mar 2001 09:29:04 -0500 (EST) Reply-To: From: "Yi Chu" To: , , , Subject: draft-martini-l2circuit-encap-mpls Date: Wed, 14 Mar 2001 09:31:34 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Martini gangs: What is your take on getting rid of padding with AAL5 PDU? In frame mode encap for AAL5, we can get rid of padding bytes to the extent that the resulted packet aligns with 32-bit word, and keep the AAL5 trailer at the end. There is no need to pad to multiple of 48 bytes. Is this an option in the consideration? yi From owner-mpls@UU.NET Wed Mar 14 10:30:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25925 for ; Wed, 14 Mar 2001 10:30:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgif11120; Wed, 14 Mar 2001 15:28:00 GMT Received: by mail-control.mail.uu.net id QQkgif07193 for mpls-outgoing; Wed, 14 Mar 2001 15:27:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkgif07185 for ; Wed, 14 Mar 2001 15:27:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgif25316 for ; Wed, 14 Mar 2001 15:26:56 GMT Received: from winstar.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-vau.winstar.com [63.142.215.140]) id QQkgif07582 for ; Wed, 14 Mar 2001 15:26:56 GMT Received: from vaaws032382 ([10.1.183.46]) by winstar.com (8.9.3/8.9.1) with SMTP id KAA11859; Wed, 14 Mar 2001 10:26:36 -0500 (EST) Reply-To: From: "Yi Chu" To: "Dan Tappan" Cc: , , , Subject: RE: draft-martini-l2circuit-encap-mpls Date: Wed, 14 Mar 2001 10:29:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20010314093531.035f8200@pilgrim.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I interpret AAL5 CPCS-PDU to be CPCS-SDU plus padding according to I.363.5. The term CPCS-PDU payload is what probably should be used instead of CPCS-PDU, to mean user data without padding. Here is a quote from I.363.5 (5/96) section 9.2.1.2 'The CPCS-PDU trailer together with the padding field and the CPCS-PDU payload comprise the CPCS-PDU.' AAL5 trailer is needed IMO mainly to transport CPCS-UU octet. yi -----Original Message----- From: Dan Tappan [mailto:tappan@cisco.com] Sent: Wednesday, March 14, 2001 9:42 AM To: ychu@winstar.com Cc: luca@level3.net; dvlachos@cisco.com; erosen@cisco.com; mpls@UU.NET Subject: Re: draft-martini-l2circuit-encap-mpls At 09:31 AM 3/14/2001 -0500, Yi Chu wrote: >Hi, Martini gangs: >What is your take on getting rid of padding with AAL5 PDU? In frame mode >encap for AAL5, we can get rid of padding bytes to the extent that the >resulted packet aligns with 32-bit word, and keep the AAL5 trailer at the >end. There is no need to pad to multiple of 48 bytes. Is this an option in >the consideration? To tell you the truth, my interpretation of the draft was that the padding should _not_ be transported. section 4.2.1 says "No AAL5 trailer is transported.", which means that you lose the AAL5 length word, and so should probably remove the AAL5 padding. I certainly don't see the draft as requiring carrying the AAL5 padding.. I'm pretty sure our implementation removes it. But, I don't have a problem with changing the draft to either say that AAL5 padding MUST be removed, or that it MAY/SHOULD be removed. I don't see any benefit to carrying the AAL5 trailer. From owner-mpls@UU.NET Wed Mar 14 11:01:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26574 for ; Wed, 14 Mar 2001 11:01:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgih23565; Wed, 14 Mar 2001 15:59:05 GMT Received: by mail-control.mail.uu.net id QQkgih10036 for mpls-outgoing; Wed, 14 Mar 2001 15:58:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgih10031 for ; Wed, 14 Mar 2001 15:58:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgih26651 for ; Wed, 14 Mar 2001 15:58:11 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkgih06873 for ; Wed, 14 Mar 2001 15:58:11 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 HAA15121 for ; Wed, 14 Mar 2001 07:58:29 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA08277 for mpls@uu.net; Wed, 14 Mar 2001 10:58:09 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkggk15150 for ; Wed, 14 Mar 2001 03:30:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkggj15652 for ; Wed, 14 Mar 2001 03:29:48 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f127.law14.hotmail.com [64.4.21.127]) id QQkggj07388 for ; Wed, 14 Mar 2001 03:29:48 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Mar 2001 19:29:47 -0800 Received: from 152.148.171.23 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 14 Mar 2001 03:29:47 GMT X-Originating-IP: [152.148.171.23] From: "hadya nagraj" To: mpls@UU.NET Date: Wed, 14 Mar 2001 08:59:47 +0530 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 14 Mar 2001 03:29:47.0948 (UTC) FILETIME=[055C2EC0:01C0AC37] Sender: owner-mpls@UU.NET Precedence: bulk
Hello There,

I am a graduate student and am working on a research paper involving QoS
in MPLS networks.
I really appreciate if someone could provide pointers/drafts/rfcs
pertaining to this.

thanks in advance,
Pratibha


Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

From owner-mpls@UU.NET Wed Mar 14 11:21:11 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26980 for ; Wed, 14 Mar 2001 11:21:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgid27414; Wed, 14 Mar 2001 14:48:17 GMT Received: by mail-control.mail.uu.net id QQkgid16391 for mpls-outgoing; Wed, 14 Mar 2001 14:47:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgid16374 for ; Wed, 14 Mar 2001 14:47:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgid11112 for ; Wed, 14 Mar 2001 14:47:31 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgid13831 for ; Wed, 14 Mar 2001 14:47:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA09660 for mpls@uu.net; Wed, 14 Mar 2001 09:47:29 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgic15815 for ; Wed, 14 Mar 2001 14:43:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgic20818 for ; Wed, 14 Mar 2001 14:42:50 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkgic01035 for ; Wed, 14 Mar 2001 14:42:50 GMT Received: from tappan-w2k.cisco.com (tappan-frame1.cisco.com [10.83.99.42]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA08685; Wed, 14 Mar 2001 09:42:08 -0500 (EST) Message-Id: <4.3.2.7.2.20010314093531.035f8200@pilgrim.cisco.com> X-Sender: tappan@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Mar 2001 09:41:59 -0500 To: From: Dan Tappan Subject: Re: draft-martini-l2circuit-encap-mpls Cc: , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:31 AM 3/14/2001 -0500, Yi Chu wrote: >Hi, Martini gangs: >What is your take on getting rid of padding with AAL5 PDU? In frame mode >encap for AAL5, we can get rid of padding bytes to the extent that the >resulted packet aligns with 32-bit word, and keep the AAL5 trailer at the >end. There is no need to pad to multiple of 48 bytes. Is this an option in >the consideration? To tell you the truth, my interpretation of the draft was that the padding should _not_ be transported. section 4.2.1 says "No AAL5 trailer is transported.", which means that you lose the AAL5 length word, and so should probably remove the AAL5 padding. I certainly don't see the draft as requiring carrying the AAL5 padding.. I'm pretty sure our implementation removes it. But, I don't have a problem with changing the draft to either say that AAL5 padding MUST be removed, or that it MAY/SHOULD be removed. I don't see any benefit to carrying the AAL5 trailer. From owner-mpls@UU.NET Wed Mar 14 11:32:55 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27243 for ; Wed, 14 Mar 2001 11:32:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgik29734; Wed, 14 Mar 2001 16:30:38 GMT Received: by mail-control.mail.uu.net id QQkgik28910 for mpls-outgoing; Wed, 14 Mar 2001 16:30:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkgik28895 for ; Wed, 14 Mar 2001 16:30:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgij03743 for ; Wed, 14 Mar 2001 16:28:49 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkgij27003 for ; Wed, 14 Mar 2001 16:28:49 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 LAA23259 for ; Wed, 14 Mar 2001 11:28:46 -0500 (EST) 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 LAA06223 for ; Wed, 14 Mar 2001 11:28:47 -0500 (EST) Message-ID: <3AAF9C3E.A50C7887@marconi.com> Date: Wed, 14 Mar 2001 11:28:46 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Can RSVP distribution of labels be driven by the IGP ? References: <1763F57BB8BAD211B06500A0C9E5D9200366C710@barking.vfl.vodafone> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit richard.crouch@vf.vodafone.co.uk wrote: > > I understand that there are (a number of) extensions to RSVP > signalling protocol to allow it to also distribute labels, most > notably when trying to overide the LSP path creation driven by the > IGP, e.g. to realise constraint based routing. draft-ietf-mpls-rsvp-lsp-tunnel-08.txt > Q1: Can RSVP be operated in a mode whereby it acts just like LDP > (with the same scalability i.e. no hand-crafting of LSPs) in that it > is used purely for the distribution of labels that reflect the IGP > (i.e. needs to match the basic functionality of LDP) ? Not without some major redesign of RSVP. And IMO, I think it would be far better to just use LDP rather than to reinvent the wheel with yet another set of RSVP extensions. RSVP, like CR-LDP, is a tunnel-setup protocol, not a label distribution protocol. It's not possible for it to just derive labels from the IGP and advertise them. Instead, an ingress node must request an LSP from itself to an egress node. An explicit route object is optional. If not present, each router will consult the local routing table to determine the next-hop to the egress node. Determination of what routers should be ingress and egress nodes, and computation of explicit paths is beyond the scope of RSVP. It may be done through manual configuration, as you have described. It may also be done by off-line traffic engineering software or by some software component of the router. But it is not a part of RSVP. -- David From owner-mpls@UU.NET Wed Mar 14 13:33:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00602 for ; Wed, 14 Mar 2001 13:33:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgis20592; Wed, 14 Mar 2001 18:31:04 GMT Received: by mail-control.mail.uu.net id QQkgis14643 for mpls-outgoing; Wed, 14 Mar 2001 18:30:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkgis14629 for ; Wed, 14 Mar 2001 18:30:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgir06167 for ; Wed, 14 Mar 2001 18:28:57 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgir17571 for ; Wed, 14 Mar 2001 18:28:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA03139 for mpls@uu.net; Wed, 14 Mar 2001 13:28:56 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgir14023 for ; Wed, 14 Mar 2001 18:24:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgir20541 for ; Wed, 14 Mar 2001 18:23:38 GMT Received: from lobster.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns3.BayNetworks.COM [192.32.253.3]) id QQkgir10429 for ; Wed, 14 Mar 2001 18:23:38 GMT Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id NAA03700; Wed, 14 Mar 2001 13:29:22 -0500 (EST) 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 NAA25915; Wed, 14 Mar 2001 13:23:35 -0500 (EST) Received: from nortelnetworks.com (dhcp235-150 [192.32.235.150]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id NAA29220; Wed, 14 Mar 2001 13:23:34 -0500 for Message-ID: <3AAFB689.ECD572D@nortelnetworks.com> Date: Wed, 14 Mar 2001 13:20:57 -0500 From: Shobhan Lakkapragada Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jianli Wang CC: mpls@UU.NET Subject: Re: CR-LDP MIBs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jianli, We investigated whether a separate CR-LDP MIB is needed but found that most of the MIB objects needed for CR-LDP are supported by the LDP MIB and the MPLS TE-MIB. Only some objects for CR-LSP traffic parameters were missing, which were then added to the latest MPLS TE-MIB. Do you know of any other objects missing for a CR-LDP implementation? - shobhan Jianli Wang wrote: > Does the WG have any plan for CR-LDP MIBs or is anybody (individual) > working on it? > > Thanks. > > Jianli > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mark > Lewis > Sent: Monday, February 19, 2001 2:10 PM > To: jorge.rodriguez@telefonica-data.com > Cc: mpls@UU.NET > Subject: Re: Interoperability Cisco-Juniper > > Try this link: > > http://www.juniper.net/products/interoperability/250004.html > > Mark Lewis > Frontrunner Solutions > > On Mon, 19 Feb 2001 13:56:27 +0100, jorge.rodriguez@telefonica-data.com > wrote: > > > > > > > > > Can somebody give me any interoperability test information with Cisco > 12000 and > > Juniper? > > > > Sorry if this is not the proper forum... Is there another forum for this > issues? > > > > _____________________________ > > Jorge Rodriguez Gabilondo > > Telefonica > > Network Planning and Design > > > > > > _________________________________________________________________ > > Hemos renovado nuestra web. Esperamos su visita en > > http://www.telefonica-data.com > > > > > > _______________________________________________________ > Get 100% private, FREE email for life from Excite UK > Visit http://inbox.excite.co.uk/ From owner-mpls@UU.NET Wed Mar 14 14:27:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01926 for ; Wed, 14 Mar 2001 14:27:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgiv02148; Wed, 14 Mar 2001 19:25:50 GMT Received: by mail-control.mail.uu.net id QQkgiv07431 for mpls-outgoing; Wed, 14 Mar 2001 19:25:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkgiv07395 for ; Wed, 14 Mar 2001 19:24:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgiv02306 for ; Wed, 14 Mar 2001 19:24:54 GMT Received: from mason2.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkgiv01282 for ; Wed, 14 Mar 2001 19:24:54 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id OAA13286 for ; Wed, 14 Mar 2001 14:24:54 -0500 (EST) Date: Wed, 14 Mar 2001 14:24:54 -0500 (EST) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: mpls@UU.NET Subject: MPLS 2001 Conference, October 7-9 Washington, DC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Dear friends, We are delighted to inform you that the 4th Annual International Conference on MPLS, co-hosted by UUNET Technologies and Advanced Internet Lab of GMU, will be held at Omni Shoreham Hotel in Washington, DC, October 7-9, 2001. The conference begins with parallel tutorial sessions on Sunday October 7 and continues with full-day technical sessions on Monday and Tuesday, October 8 and 9. A series of public Interoperability demonstrations will follow on October 10-12 at Advanced Internet Lab, GMU. Conference information, technical program, and other details, including the testing and public interoperability events will be made available soon. The technical program for MPLS 2001 will be unique, as were the programs for previous events in this series. MPLS 98 was the first conference on the topic of Multiprotocol Label Switching. The attendance has continued to grow each year. Last year, at MPLS 2000, 17 sponsors exhibited their products and services throughout the conference. This year, we have reserved a larger space to accommodate additional sponsors. If you wish to receive further information regarding this event, please send email to: mplsadmn@gmu.edu. Please include your name, email address, company name, mailing address, and telephone number. Thanks. Regards, - Rajiv ******************************** Rajiv Papneja 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 Mar 14 14:31:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02139 for ; Wed, 14 Mar 2001 14:31:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgiv12033; Wed, 14 Mar 2001 19:29:57 GMT Received: by mail-control.mail.uu.net id QQkgiv07907 for mpls-outgoing; Wed, 14 Mar 2001 19:29:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkgiv07884 for ; Wed, 14 Mar 2001 19:29:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgiv23704 for ; Wed, 14 Mar 2001 19:29:07 GMT Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQkgiv11312 for ; Wed, 14 Mar 2001 19:29:07 GMT Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id OAA15284 for ; Wed, 14 Mar 2001 14:24:28 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256A0F.006A9A14 ; Wed, 14 Mar 2001 14:24:22 -0500 X-Lotus-FromDomain: TELCORDIA From: "Anuj Bhatnagar" To: mpls@UU.NET Message-ID: <85256A0F.006A9861.00@notes950.cc.telcordia.com> Date: Wed, 14 Mar 2001 14:24:13 -0500 Subject: Cross Connect traps from mplsXC entry in a router Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Can anybody tell me that if LSR generate any other traps besides being "up" or "down" for mplsXCentry in its mplsXCTable ? What are the conditions that LSR will generate a trap when mplsXC is in "down" status? In other words... if a lower layer link fails (for example SONET link connecting two LSR) and LSPs passing through that link are rerouted then will LSR still generate traps about mplsXCs being "down"? Source for mplsXC and mplsXCtable is "draft-ietf-mpls-lsr-mib-07.txt" Thanks and best regards, Anuj From owner-mpls@UU.NET Wed Mar 14 14:54:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02891 for ; Wed, 14 Mar 2001 14:54:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgix15665; Wed, 14 Mar 2001 19:53:15 GMT Received: by mail-control.mail.uu.net id QQkgix10714 for mpls-outgoing; Wed, 14 Mar 2001 19:52:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgix10692 for ; Wed, 14 Mar 2001 19:52:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgix05135 for ; Wed, 14 Mar 2001 19:50:43 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkgix08291 for ; Wed, 14 Mar 2001 19:50:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA12229 for mpls@uu.net; Wed, 14 Mar 2001 14:50:42 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkgix10044 for ; Wed, 14 Mar 2001 19:46:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgix08543 for ; Wed, 14 Mar 2001 19:46:15 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkgix05387 for ; Wed, 14 Mar 2001 19:46:14 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA17180; Wed, 14 Mar 2001 14:45:30 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABB09620; Wed, 14 Mar 2001 14:46:12 -0500 (EST) Message-Id: <4.3.2.7.2.20010314144327.01be65a0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Mar 2001 14:50:52 -0500 To: "Anuj Bhatnagar" , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Cross Connect traps from mplsXC entry in a router In-Reply-To: <85256A0F.006A9861.00@notes950.cc.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >Can anybody tell me that if LSR generate any other traps besides being "up" or >"down" for mplsXCentry in its mplsXCTable ? Not that we could tell. >What are the conditions that LSR will generate a trap when mplsXC is in "down" >status? In other words... if a lower layer link fails (for example SONET link >connecting two LSR) and LSPs passing through that link are rerouted then will >LSR still generate traps about mplsXCs being "down"? There are several cases where this trap is useful. First, if you are implementing hand-routed LSPs, then one can literally disable the label switching for that set of labels (and then re-enable them if they so choose). In the case of auto-routed label switching, if the label set is removed from the TFIB, then the XC is "down" -- and then disappears. The XC is "up" when it is installed. It can also happen in the case of TE tunnels where the tunnel is using a set of labels and might be re-routed to another set of labels, although it is arguably easier to just monitor the tunnelEntry in the MPLS-TE-MIB. One important use of this trap is in the case of MPLS/BGP VPN. This is a good way of doing fault detection in the core of the network. Using the MPLS-VPN-MIB, one can tell which LSP(s) the VPN is using across the core. If there is a failure, one can find which VPN(s) is/are affected because one can follow down from the VPN MIB to the LSR MIB's XCs and go hop-by-hop along the path. --Tom From owner-mpls@UU.NET Mon Mar 19 18:36:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25903 for ; Mon, 19 Mar 2001 18:36:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhby14324; Mon, 19 Mar 2001 23:34:41 GMT Received: by mail-control.mail.uu.net id QQkhbw17502 for mpls-outgoing; Mon, 19 Mar 2001 23:01:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhbu11650 for ; Mon, 19 Mar 2001 22:40:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgtn24292 for ; Sat, 17 Mar 2001 16:59:57 GMT Received: from pooh.watersprings.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pooh.watersprings.org [211.130.20.222]) id QQkgtn10441 for ; Sat, 17 Mar 2001 16:59:56 GMT Received: from localhost by pooh.watersprings.org (8.8.7/2.8Wb) id RAA18653; Sat, 17 Mar 2001 17:03:11 GMT From: Noritoshi Demizu To: mpls@UU.NET Subject: Re: Draft MPLS Agenda In-Reply-To: Your message of "Tue, 13 Mar 2001 16:59:18 -0500" References: <200103132159.QAA10715@pilgrim.cisco.com> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://www.dd.iij4u.or.jp/~demizu/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010318020307Y.demizu@dd.iij4u.or.jp> Date: Sun, 18 Mar 2001 02:03:07 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 16 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear mpls experts, I have converted the MPLS WG agenda to HTML format. It is located at http://www.watersprings.org/links/mlr/article/MPLS-agenda-0103.html It includes titles and links to all I-Ds on the agenda. Please let me know when you find errors. Thank you. Best Regards, Noritoshi Demizu ps. There is the CCAMP WG agenda in HTML format, too. http://www.watersprings.org/links/mlr/article/CCAMP-agenda-0103.html From owner-mpls@UU.NET Mon Mar 19 18:38:01 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25969 for ; Mon, 19 Mar 2001 18:38:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhby15992; Mon, 19 Mar 2001 23:35:43 GMT Received: by mail-control.mail.uu.net id QQkhbw17825 for mpls-outgoing; Mon, 19 Mar 2001 23:01:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhbu12409 for ; Mon, 19 Mar 2001 22:41:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgqg22579 for ; Fri, 16 Mar 2001 19:40:11 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkgqg28997 for ; Fri, 16 Mar 2001 19:40:10 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f2GJcgB01337 for ; Fri, 16 Mar 2001 11:38:42 -0800 (PST) Reply-To: From: "Anil Gunturu" To: Subject: ldp MIB Date: Fri, 16 Mar 2001 11:37:04 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I was wondering, if it is possible for an entry in the MplsLdpEntity table there are multiple entries in the MplsPeerEntryTable? Looks like the MIB allows it because the MplsLdpPeerEntry table is indexed by mplsLdpEntityLdpId, mplsLdpEntityIndex and mplsLdpPeerLdpId. If it is possible can some one give a practical scenario. Thanks in advance for help, -Anil Anil Gunturu, Software Engineer Ericsson, Inc phone: (805) 562 6431 Datacom & IP Services email: anilg@acc.am.ericsson.se 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Mon Mar 19 18:39:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26003 for ; Mon, 19 Mar 2001 18:39:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhby17847; Mon, 19 Mar 2001 23:36:45 GMT Received: by mail-control.mail.uu.net id QQkhbw17983 for mpls-outgoing; Mon, 19 Mar 2001 23:01:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhbu11188 for ; Mon, 19 Mar 2001 22:39:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgpw07879 for ; Fri, 16 Mar 2001 17:11:39 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkgpw01627 for ; Fri, 16 Mar 2001 17:11:38 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f2GHBXi25515 for ; Fri, 16 Mar 2001 18:11:33 +0100 (MET) Received: from alcatel.be ([138.203.197.202]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A11.005E6C2B; Fri, 16 Mar 2001 18:11:20 +0100 Message-ID: <3AB24936.E96E5D9F@alcatel.be> Date: Fri, 16 Mar 2001 18:11:18 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Diff serv over MPLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Francois, Liwen, ..., I have a question concerning the latest version of the 'diff serv over MPLS' draft. For L-LSPs the drop precedence is encoded in the exp bits. Compared to version 7 of the draft the encoding of the color 'red' has changed from 01 to 11. Why was this encoding changed? [If changing the encoding of the drop precedence would be done, I would have expected that the encoding of ALL (...) drop precedence values would have changed to align with the recommended DSCPs for the AF PHB: * 01 = green. * 10 = yellow. * 11 = red.] Kind regards, Francis. From owner-mpls@UU.NET Mon Mar 19 18:40:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26040 for ; Mon, 19 Mar 2001 18:39:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhby19633; Mon, 19 Mar 2001 23:37:45 GMT Received: by mail-control.mail.uu.net id QQkhbw18597 for mpls-outgoing; Mon, 19 Mar 2001 23:02:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhbu11575 for ; Mon, 19 Mar 2001 22:40:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgqo18161 for ; Fri, 16 Mar 2001 21:37:40 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkgqo02602 for ; Fri, 16 Mar 2001 21:37:40 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f2GLbcR04773 for ; Fri, 16 Mar 2001 16:37:38 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; FRI, 16 Mar 2001 16:34:44 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Mar 2001 16:34:43 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E56993D58@newman.tenornet.com> From: "Shah, Himanshu" To: "'mpls@uu.net'" Subject: comment on latest draft-martini-l2circuit-encap-mpls-01.txt Date: Fri, 16 Mar 2001 16:34:37 -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 Hello Luca, Sorry for the late comment, I didn't know of this draft until recently. I see the addition of the control word and algorithm for handling sequence numbers on send and receive side. It seems that sequence check on receive side does not handle the wrap around correctly, i.e. finds the out-of-sequence little too late. For example if the max was 64, sender receiver's expected Seq 62 -> 62, next: 62+1=63 64 -> 63, 64>=63 packet in order. Next: 64+1=1, wrapped 63 -> 1, 63>=1 packet in order. Next: 63+1=64 1 -> 64, 1 !>=64. packet out-of-order, drop, next:1+1=2 As shown above, out-of-order packet already forwarded! More later... Himanshu Shah Tenor Networks Acton, MA From owner-mpls@UU.NET Mon Mar 19 18:40:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26059 for ; Mon, 19 Mar 2001 18:40:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhby22022; Mon, 19 Mar 2001 23:39:13 GMT Received: by mail-control.mail.uu.net id QQkhbw19229 for mpls-outgoing; Mon, 19 Mar 2001 23:02:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhbu11412 for ; Mon, 19 Mar 2001 22:40:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkglw10543 for ; Thu, 15 Mar 2001 15:06:59 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkglw16086 for ; Thu, 15 Mar 2001 15:06:58 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA26595 for ; Thu, 15 Mar 2001 10:06:58 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA26528; Thu, 15 Mar 2001 10:06:56 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA29776; Thu, 15 Mar 2001 10:06:55 -0500 (EST) Message-ID: <3AB0DA8F.B364BEB0@lucent.com> Date: Thu, 15 Mar 2001 10:06:55 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Fong Liaw CC: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question regarding bi-directional connection set up - And Port-ID in Label object References: <4611AD058694D4118FD5009027B0A6622B8C30@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Fong, > > Regarding how to encode the bi-directionality request, > Removal of upstream label prevents pre-program the > cross-connect, not desirable in some situation. So I would > be in favor of keeping the upstream label object. > I wasn't suggesting to get rid of upstream label (the concept). I proposed to merge it with suggested label, label set into a single suggested label set object. I gave reasons in my ID (draft-xu-ccamp-gmpls-sig-reorg-00.txt). A NE should be able to specify labels of both directions for bi-directional LSP in optical network. Thanks, Yangguang From owner-mpls@UU.NET Mon Mar 19 18:43:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26164 for ; Mon, 19 Mar 2001 18:43:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhby24686; Mon, 19 Mar 2001 23:40:59 GMT Received: by mail-control.mail.uu.net id QQkhbw19990 for mpls-outgoing; Mon, 19 Mar 2001 23:03:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhbu12009 for ; Mon, 19 Mar 2001 22:40:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkglu15367 for ; Thu, 15 Mar 2001 14:41:39 GMT From: wesam.alanqar@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQkglu21960 for ; Thu, 15 Mar 2001 14:41:38 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f2FEonF09398; Thu, 15 Mar 2001 08:50:49 -0600 (CST) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f2FEfai24490; Thu, 15 Mar 2001 08:41:36 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id IAA07547; Thu, 15 Mar 2001 08:41:35 -0600 (CST) X-OpenMail-Hops: 1 Date: Thu, 15 Mar 2001 08:41:34 -0600 Message-Id: Subject: PWOT agenda MIME-Version: 1.0 TO: pwot@ietf.org CC: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-1dcaac31-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-1dcaac31-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Thu, 15 Mar 2001 08:41:34 -0600" Content-Transfer-Encoding: 8bit All, Any info about PWOT agenda for the coming IETF? Thanks. ------------------------------------------------------------------------ ----------- Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations & Evaluation Group Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------------------------ ----------- --openmail-part-1dcaac31-00000001 Content-Type: application/octet-stream Content-Disposition: attachment; filename="Wesam Alanqar (E-mail).vcf" ;Creation-Date="Thu, 15 Mar 2001 08:41:34 -0600" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkFsYW5xYXI7V2VzYW0NCkZOOldlc2FtIEFs YW5xYXIgKEUtbWFpbCkNCk9SRzpUZWNobm9sb2d5IFBsYW5uaW5nICYgSW50ZWdyYXRpb24t U3ByaW50O1RlY2hub2xvZ3kgUGxhbm5pbmcgJiBJbnRlZ3JhdGlvbg0KVElUTEU6TWVtYmVy IG9mIFRlY2huaWNhbCBTdGFmZg0KVEVMO1dPUks7Vk9JQ0U6KDkxMykgNTM0LTU2MjMNClRF TDtXT1JLO0ZBWDooOTEzKSA1MzQtMzQ4NQ0KQURSO1dPUks6Ozg1MTs5MzAwIE1ldGNhbGYg QXZlbnVlO092ZXJsYW5kIFBhcms7S1M7NjYyMTItMTQ2MztVbml0ZWQgU3RhdGVzIG9mIEFt ZXJpY2ENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo4NTE9MEQ9MEE5 MzAwIE1ldGNhbGYgQXZlbnVlPTBEPTBBT3ZlcmxhbmQgUGFyaywgS1MgNjYyMTItMTQ2Mz0w RD0wQVVuaXRlZCBTPQ0KdGF0ZXMgb2YgQW1lcmljYQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDp3 ZXNhbS5hbGFucWFyQG1haWwuc3ByaW50LmNvbQ0KUkVWOjIwMDEwMTI5VDE4MjEyN1oNCkVO RDpWQ0FSRA0K --openmail-part-1dcaac31-00000001-- From owner-mpls@UU.NET Mon Mar 19 18:44:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26216 for ; Mon, 19 Mar 2001 18:44:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhby27256; Mon, 19 Mar 2001 23:42:41 GMT Received: by mail-control.mail.uu.net id QQkhbw23300 for mpls-outgoing; Mon, 19 Mar 2001 23:04:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhbu12006 for ; Mon, 19 Mar 2001 22:40:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgsv16018 for ; Sat, 17 Mar 2001 12:18:41 GMT Received: from smtp.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQkgsv07842 for ; Sat, 17 Mar 2001 12:18:09 GMT Received: from z97716 ([10.110.10.147]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GACCNJ03.A1X for ; Sat, 17 Mar 2001 20:14:07 +0800 Message-ID: <001f01c0aedc$592e0440$930a6e0a@huawei.com> From: "Heqing Zhu" To: Subject: Question of TE MIB Date: Sat, 17 Mar 2001 20:18:16 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C0AF1F.66A96B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C0AF1F.66A96B80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEFsbDoNCg0KSSBhbSBjb25mdXNlZCBhYm91dCB0aGUgaW5kZXggb2YgbXBsc1R1bm5lbFRh YmxlLg0KQW5kIEkgYW0gbm90IGZhbWlsaWFyIHdpdGggUlNWUCBhY3R1YWxseS4NCkluZGV4IHsg bXBsc1R1bm5lbEluZGV4LG1wbHNUdW5uZWxJbnN0YW5jZUluZGV4LCANCm1wbHNUdW5uZWxJbmdy ZXNzTFNSSWQsbXBsc1R1bm5lbEVncmVzc0xTUklkfQ0KDQpXaGF0J3MgdGhlIG1lYW5pbmcgb2Yg aW5zdGFuY2UgZm9yIENSTERQIGFuZCBSU1ZQPw0KDQogICAgLy0tLS0tLSotLS0tLS1cIA0KICAg KiAgICAgICAgICAgICAgICAgICoNCiAgICBcLS0tLS0tKi0tLS0tLS8gDQpBbnlvbmUgY2FuIGV4 cGxhaW4gdG8gbWUgaG93IHRvIHVzZSBUdW5uZWxJbmRleCANCmFuZCBJbnN0YW5jZUluZGV4IGFj Y29yZGluZyB0byB0aGUgYWJvdmUgZmlndXJlLg0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioN ClpodSBIZXFpbmcNClVuaXZlcnNpdHkgb2YgRS5TLiZULiBvZiBDaGluYQ0KKioqKioqKioqKioq KioqKioqKioNCg== ------=_NextPart_000_001C_01C0AF1F.66A96B80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGksIEFsbDo8L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkkgYW0g Y29uZnVzZWQgYWJvdXQgdGhlIGluZGV4IG9mIA0KbXBsc1R1bm5lbFRhYmxlLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5BbmQgSSBhbSBub3QgZmFtaWxpYXIgd2l0aCBSU1ZQ IGFjdHVhbGx5LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5JbmRleCB7IG1w bHNUdW5uZWxJbmRleCxtcGxzVHVubmVsSW5zdGFuY2VJbmRleCwgDQo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWw+bXBsc1R1bm5lbEluZ3Jlc3NMU1JJZCxtcGxzVHVubmVsRWdy ZXNzTFNSSWR9PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5XaGF0J3MgdGhlIG1lYW5pbmcgb2YgaW5z dGFuY2UgZm9yIENSTERQIGFuZCANClJTVlA/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvLS0tLS0t Ki0tLS0tLVwgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOyZuYnNw OyANCiombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoqPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOyZuYnNwOyZuYnNwOyBcLS0t LS0tKi0tLS0tLS8gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkFueW9uZSBj YW4gZXhwbGFpbiB0byBtZSBob3cgdG8gdXNlIFR1bm5lbEluZGV4IA0KPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsPmFuZCBJbnN0YW5jZUluZGV4IGFjY29yZGluZyB0byB0aGUg YWJvdmUgDQpmaWd1cmUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPioqKioq KioqKioqKioqKioqKioqPEJSPlpodSBIZXFpbmc8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWw+VW5pdmVyc2l0eSBvZiBFLlMuJmFtcDtULiBvZiANCkNoaW5hPEJSPioqKioqKioq KioqKioqKioqKioqPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_001C_01C0AF1F.66A96B80-- From owner-mpls@UU.NET Mon Mar 19 18:46:01 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26252 for ; Mon, 19 Mar 2001 18:46:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhby00286; Mon, 19 Mar 2001 23:44:42 GMT Received: by mail-control.mail.uu.net id QQkhbw23627 for mpls-outgoing; Mon, 19 Mar 2001 23:05:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhbu12116 for ; Mon, 19 Mar 2001 22:40:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgqf27257 for ; Fri, 16 Mar 2001 19:17:34 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQkgqf07224 for ; Fri, 16 Mar 2001 19:17:33 GMT Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP; Fri, 16 Mar 2001 19:14:51 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 16 Mar 2001 19:14:48 -0000 Message-ID: To: ssnarayanan@lucent.com Cc: xuyg@lucent.com, mpls@UU.NET, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, evarma@lucent.com Subject: RE: [IP-Optical] RE: Three GMPLS related IDs Date: Fri, 16 Mar 2001 19:14:47 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Sivakumar Sankaranarayanan [mailto:ssnarayanan@lucent.com] wrote 15 March 2001 20:37 > > 4 A further observation wrt the above is that it seems you are > > advocating that all failures be conveyed by control-plane > message 'events'. > > Are you suggesting that (at least) the 3 distinct areas of > (i) user-plane > > failures, (ii) signalling protocol failures and (iii) > routing protocol > > failures all get 'merged' into some generic form of event > notification? I > > would have thought that one would need notification (and > general defect > > handling) per protocol type, and that this would be a > function of that > > protocol only since the failure modes of each would be > different (and if one > > changes one protocol one would not want to create backwards > compatibility > > issues with another). > > > > [Siva] Yes, currently there is no clear separation of the > events generated from > > different sources. Maybe we need to discuss further on the rationales > for this separation. For example, a user plane failure that impacts > traffic would definitely need to be signaled to the control > plane. However, > when you say signaling "protocol" failures and routing "protocol" > failures, what are you referring to, is it the failure of the > "box" that is > implementing the signaling and routing software? Is it the > failure of the link > in > the SCN? Is it a wrong routing decision? If it is failure > of the DCN/SCN, then > it should be protected by theDCN/SCN failure recovery > methods, e.g., protected > signaling channels. If it is a > box failure, then it is a bigger problem and not only is > restoration mechanisms > supposed to kick in, but some maintenance action is needed > and so the management > > system would have to be informed as well. NH=> What I meant by this was very simple. If we consider the user-plane this has defects which are either (i) inherited from lower layers or (ii) caused within the layer. The former generally manifests itself as a 'break' to clients (where a client can be a higher user-plane layer network or the peer control-plane or management-plane protocols). 'Within layer' defects are technology dependent in terms of specification, and can be either simple breaks, swapped trails or mismerged trails (latter only applies to pkt case). For example the definition of simple breaks is different for OTN, SDH, ATM, MPLS, etc and can be, for example, LoS, LoF (loss of framing) or loss of some keepalive/hello say. For the swapped/mismerging cases one needs some form of trail termination network-wide unique ID. For the routing, signalling and management protocols, these could also have failure modes associated with the specific protocol, eg bad PATH message in RSVP, bad LSA in the case of OSPF, etc. There is also the case of internal 'box failures', which are proprietary, and which could affect user and/or control and/or management planes. So all I was really saying here is that some level of defect handling is required at a per transport, per protocol and per box level. From owner-mpls@UU.NET Mon Mar 19 18:49:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26335 for ; Mon, 19 Mar 2001 18:49:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhbz03160; Mon, 19 Mar 2001 23:46:43 GMT Received: by mail-control.mail.uu.net id QQkhbw26072 for mpls-outgoing; Mon, 19 Mar 2001 23:05:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhbu11837 for ; Mon, 19 Mar 2001 22:40:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgtq11676 for ; Sat, 17 Mar 2001 17:39:51 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQkgtq04179 for ; Sat, 17 Mar 2001 17:39:50 GMT Received: from zcard00n.ca.nortel.com by zcars04e.nortelnetworks.com; Sat, 17 Mar 2001 12:24:54 -0500 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HADDWZ8S; Sat, 17 Mar 2001 12:24:58 -0500 Received: from americasm01.nt.com (acart13j.ca.nortel.com [47.129.8.161]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRVX915; Sat, 17 Mar 2001 12:25:05 -0500 Message-ID: <3AB2F50B.96D0DDCF@americasm01.nt.com> Date: Sat, 17 Mar 2001 00:24:27 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Le Faucheur CC: mpls@UU.NET Subject: Re: on its way ... References: <200102091708.SAA29074@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Francois: Sorry, but I am a bit behind in my MPLS WG mailing list reading. Back in February, you posted the following comment to the MPLS WG mailing list. Francois Le Faucheur wrote: > Subsequent to the MPLS WG Last Call, a special Diff-Serv WG Last Call was > issued on at the request of the Area > Directors. > > We received comments relating to two items. Below are the details of the > planned resolution for both items. ..snip ... > Incoming PHB Determination with Pipe Model > =========================================== > We received pretty much the same comment from several people (Service > Providers as well as vendors) on one detailed aspect of the Pipe model: > output scheduling at egress of a Pipe LSP. > "xx-07.txt" specifies that, in the Pipe model, the egress LSR does incoming > PHB determination based on the "inner header" (ie after the POP). We plan to: > - keep such a behavior, but make it an optional variation of the Pipe model > - define an alternative behavior where the egress LSR does incoming PHB > determination based on the "outer header" (ie before the POP). This will be > the normal egress behavior for the Pipe Model. > All the other aspects of the Pipe model are unchanged. > > The rationale for using "outer header" by default on egress of Pipe is the > following: > - the typical application of the Pipe model is where a Service Provider > (SP) transports traffic from a customer who uses a different Diff-Serv > policy to the SP's Diff-Serv policy. Doing scheduling on LSP Egress based > on the outer header (and assuming no PHP) allows the Service Provider to > configure scheduling based on its own Diff-Serv policy. Doing scheduling > based on the inner header forces the Service Provider to be aware of each > and every customer Diff-Serv policy and forces the SP to configure > scheduling differently for each customer Diff-Serv policy. The most common > situation will be that the SP does not want to be even aware of the > Customer Diff-Serv policy and thus need to use the outer header. > (There will be cases where the SP may accept the operational overhead of > being aware of the customer's Diff-Serv policy and sell "egress scheduling > based on customer's policy" as a value add; this is why we keep the use of > inner header as an option. But this will be less common.) It seems very strange to me to schedule the packet based on the outer header, but forward the packet based on the inner header. This solution seems particularly strange to me when the router is popping two or more labels; that is, terminating two or more pipe-model LSPs at once. In this case, using the outermost header seems particularly arbitrary. I make these comments while in the middle of implementing this draft. The way it was before makes for a very logical implementation, while this new proposal will add some weirdness. It seems to me that what the service providers really want is a form of PHP: that is, they want to both schedule and forward the packet based on the outer header, but pop the header just before forwarding the packet. Comments? - Philip Matthews Nortel Networks From owner-mpls@UU.NET Mon Mar 19 18:55:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26525 for ; Mon, 19 Mar 2001 18:55:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhbz08835; Mon, 19 Mar 2001 23:51:59 GMT Received: by mail-control.mail.uu.net id QQkhbw26747 for mpls-outgoing; Mon, 19 Mar 2001 23:06:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhbu11715 for ; Mon, 19 Mar 2001 22:40:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgkl01104 for ; Thu, 15 Mar 2001 05:54:26 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f21.law8.hotmail.com [216.33.241.21]) id QQkgkl12917 for ; Thu, 15 Mar 2001 05:54:26 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Mar 2001 21:54:25 -0800 Received: from 192.11.189.113 by lw8fd.law8.hotmail.msn.com with HTTP; Thu, 15 Mar 2001 05:54:25 GMT X-Originating-IP: [192.11.189.113] From: "Ashish Vyas" To: pratic228@hotmail.com, mpls@UU.NET Subject: Re: Date: Thu, 15 Mar 2001 11:24:25 +0530 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1c15_1bf3_bc2" Message-ID: X-OriginalArrivalTime: 15 Mar 2001 05:54:25.0968 (UTC) FILETIME=[6446B300:01C0AD14] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_1c15_1bf3_bc2 Content-Type: text/html

hi pratibha,

You can refer following links
http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-08.txt  (FOR Diff-serv)
http://www.iec.org/tutorials/mpls/   (tutorial on mpls-qos)                              http://www.cis.ohio-state.edu/~jain/

Using any search engine you can find lot more :)

there is some good stuff in the following book also                                                        "MPLS Technology and Applications" By Davie Bruce and Rekhter

-ashish

 

 

>From: "hadya nagraj"
>To: mpls@UU.NET
>Date: Wed, 14 Mar 2001 08:59:47 +0530
>

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

------=_NextPart_000_1c15_1bf3_bc2 Content-Type: message/rfc822 Received: from [198.5.241.39] by hotmail.com (3.2) with ESMTP id MHotMailBC78E1030064D820F3DAC605F127C1680; Wed Mar 14 08:02:12 2001 Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkgih25075; Wed, 14 Mar 2001 15:59:55 GMT Received: by mail-control.mail.uu.net id QQkgih10036 for mpls-outgoing; Wed, 14 Mar 2001 15:58:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkgih10031 for ; Wed, 14 Mar 2001 15:58:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgih26651 for ; Wed, 14 Mar 2001 15:58:11 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkgih06873 for ; Wed, 14 Mar 2001 15:58:11 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 HAA15121 for ; Wed, 14 Mar 2001 07:58:29 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA08277 for mpls@uu.net; Wed, 14 Mar 2001 10:58:09 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkggk15150 for ; Wed, 14 Mar 2001 03:30:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkggj15652 for ; Wed, 14 Mar 2001 03:29:48 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f127.law14.hotmail.com [64.4.21.127]) id QQkggj07388 for ; Wed, 14 Mar 2001 03:29:48 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Mar 2001 19:29:47 -0800 Received: from 152.148.171.23 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 14 Mar 2001 03:29:47 GMT X-Originating-IP: [152.148.171.23] From: "hadya nagraj" To: mpls@UU.NET Date: Wed, 14 Mar 2001 08:59:47 +0530 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 14 Mar 2001 03:29:47.0948 (UTC) FILETIME=[055C2EC0:01C0AC37] Sender: owner-mpls@UU.NET Precedence: bulk
Hello There,

I am a graduate student and am working on a research paper involving QoS
in MPLS networks.
I really appreciate if someone could provide pointers/drafts/rfcs
pertaining to this.

thanks in advance,
Pratibha


Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

------=_NextPart_000_1c15_1bf3_bc2-- From owner-mpls@UU.NET Mon Mar 19 18:59:47 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26629 for ; Mon, 19 Mar 2001 18:59:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhbz15115; Mon, 19 Mar 2001 23:57:58 GMT Received: by mail-control.mail.uu.net id QQkhbw26996 for mpls-outgoing; Mon, 19 Mar 2001 23:06:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhbu11458 for ; Mon, 19 Mar 2001 22:40:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgms11178 for ; Thu, 15 Mar 2001 20:36:37 GMT Received: from auemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkgms08642 for ; Thu, 15 Mar 2001 20:36:36 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA02517 for ; Thu, 15 Mar 2001 15:36:36 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id PAA02490; Thu, 15 Mar 2001 15:36:35 -0500 (EST) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA02095; Thu, 15 Mar 2001 15:36:34 -0500 Message-ID: <3AB127D7.DF3DB70C@lucent.com> Date: Thu, 15 Mar 2001 15:36:39 -0500 From: Sivakumar Sankaranarayanan X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: xuyg@lucent.com, mpls@UU.NET, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, evarma@lucent.com Subject: Re: [IP-Optical] RE: Three GMPLS related IDs References: Content-Type: multipart/mixed; boundary="------------BB3D6A936307378EFAA05226" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------BB3D6A936307378EFAA05226 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Neil, I generally agree with your observations, please see below for some specific comments... Regards, Shiva. neil.2.harrison@bt.com wrote: > Hi Yangguang, you wrote 05 March 2001 14:29: > > FYI, three GMPLS related IDs have been submitted. > > > > Architecture: > > > http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0 > 0.txt > > > >Signaling: > >http://www.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-reques > t-01.txt > >http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-reorg-00.txt > > > >Comments are welcomed. > > Here are my observations on the sig-reorg and arch-intra-domain IDs (I could > not open the label-request one): > > sig-reorg ID: > > 1 I noticed that NSAPs are mentioned in 6.2. Yes, I think this form > of global addressing will be of considerable interest and importance to > several carriers and should be included. It is something we are currently > looking closely at and almost certainly will require to be supported. > > 2 The 'connection ID' noted in para 7.2.2 seems to be the same > (similar?) to a trail termination identifier and, as noted, requires global > uniqueness. I noted that you have this 'TBD' wrt size/format.....this seems > a sensible decision since something larger that 32 bits will surely be > required here. > [Siva] Agreed. I think there are some issues with respect to whether the connetion ID is global or locally unique that needs to be addressed. For global uniqueness, there must be coordination amongst the providers and vendor on the format and range of values for the ID. For local uniqueness, there must be some translation function that maps the locally unique connection IDs to provide an end-to-end view of the ID. > > 3 I was a little unclear regarding the requirement given in the 1st > bullet in para 9.1. Agree that user and control plane *networks* can (and > will usually) be disjoint....indeed the control-plane network *must* only > take its survivability design cues from the duct network, since only that > layer can define the inherited real disjoint connectivity. Further, both > the control plane and user plane network need their own OAM....and in the > control plane not only is this for the 'physical transport' aspects, but > also on a per protocol-type, ie the signalling protocol will have different > failure modes to the routing protocol. One feature that is required > however, is that user-plane failures can map to control-plane actions for > invoking restoration (the reverse of this is clearly not true)...for example > to restore S-PVC-like user-plane trails (see also point 5 below). So I > would like to see these types of relationship made more clear. > [Siva] I think the document needs to have an expanded discussion on the implications of the user plane and control plane. > > 4 A further observation wrt the above is that it seems you are > advocating that all failures be conveyed by control-plane message 'events'. > Are you suggesting that (at least) the 3 distinct areas of (i) user-plane > failures, (ii) signalling protocol failures and (iii) routing protocol > failures all get 'merged' into some generic form of event notification? I > would have thought that one would need notification (and general defect > handling) per protocol type, and that this would be a function of that > protocol only since the failure modes of each would be different (and if one > changes one protocol one would not want to create backwards compatibility > issues with another). > [Siva] Yes, currently there is no clear separation of the events generated from different sources. Maybe we need to discuss further on the rationales for this separation. For example, a user plane failure that impacts traffic would definitely need to be signaled to the control plane. However, when you say signaling "protocol" failures and routing "protocol" failures, what are you referring to, is it the failure of the "box" that is implementing the signaling and routing software? Is it the failure of the link in the SCN? Is it a wrong routing decision? If it is failure of the DCN/SCN, then it should be protected by theDCN/SCN failure recovery methods, e.g., protected signaling channels. If it is a box failure, then it is a bigger problem and not only is restoration mechanisms supposed to kick in, but some maintenance action is needed and so the management system would have to be informed as well. > > Further, if some aspects of the control-plane fail I would still expect the > user-plane defect handling to carry on as an autonomous function....for > example, the sending of a FDI into client layers to suppress alarm storms > and protect user-plane traffic, eg squelch traffic on misrouting if trail ID > mismatch. I am not sure we would want to make this low-level action > dependent on a 'healthy control-plane'....and this seems quite important > when one has a server->client adaptation function between 2 different > technologies, eg OTN layer->SDH layer, and where a 'common control-plane' > might not be appropriate across such a (different operator domain) > boundary....a point you indeed make in para 4 in the Arch-intra-domain ID. > Can you please explain the intent of this section more clearly and comment > on the above points, including the network management of the control-plane > ....maybe you have some new ideas here that are worth exploring further? > [Siva] Yes, I completely agree with your statements. I dont think we should reinvent what is already a global standard, i.e., existing transport network defect handling capabilities. For example, the equipment functional blocks described in G.783 (for SDH) and G.798 (for OTN) and the various defects and consequent actions described are still valid. Regards Siva. --------------BB3D6A936307378EFAA05226 Content-Type: text/x-vcard; charset=us-ascii; name="ssnarayanan.vcf" Content-Description: Card for Sivakumar Sankaranarayanan Content-Disposition: attachment; filename="ssnarayanan.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sankaranarayanan;Siva tel;fax:+1 732 332 7044 tel;home:+1 732 935 0210 tel;work:+1 732 949 5762 x-mozilla-html:FALSE org:Lucent Technologies;Transport and Network Architectures Department version:2.1 email;internet:ssnarayanan@lucent.com title:Member of Technical Staff adr;quoted-printable:;;HO 3C-508A=0D=0A101 Crawfords Corner Road;Holmdel;NJ;07733;USA fn:Siva Sankaranarayanan end:vcard --------------BB3D6A936307378EFAA05226-- From owner-mpls@UU.NET Mon Mar 19 19:14:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26984 for ; Mon, 19 Mar 2001 19:14:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhca01993; Tue, 20 Mar 2001 00:12:13 GMT Received: by mail-control.mail.uu.net id QQkhbw27095 for mpls-outgoing; Mon, 19 Mar 2001 23:06:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhbu12219 for ; Mon, 19 Mar 2001 22:41:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgqf23054 for ; Fri, 16 Mar 2001 19:15:26 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkgqf23969 for ; Fri, 16 Mar 2001 19:15:26 GMT Received: from chqlubnt02.lon.bt.com by gollum (local) with ESMTP; Fri, 16 Mar 2001 19:16:34 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <1TT22PJQ>; Fri, 16 Mar 2001 19:14:56 -0000 Message-ID: To: zwlin@lucent.com Cc: xuyg@lucent.com, mpls@UU.NET, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, evarma@lucent.com Subject: RE: [IP-Optical] RE: Three GMPLS related IDs Date: Fri, 16 Mar 2001 19:14:46 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Zhi, you noted 15 March 2001 20:14 > If we extend Kireeti's voting weight, I would think an > operator's input > would have more weight than other's inputs. NH=> I think this depends on the issue. For *networking aspects* (eg addressing, OAM, performance metrics/objectives/apportionments, etc), and certainly wrt to determining requirements, then operators should take a strong interest. However, I suspect the effects of cost-cutting might be preventing as much carrier involvement as one would like/expect. If the issue is largely *implementational* then I think the vendor's views should carry more weight. > > > Thinking about the further concerns a carrier would have to > address in a > > connection oriented switched-network, there needs to be a > consideration of > > blocking probability and users having connection requests > refused, ie a GoS > > metric. The result is that transport networks currently > designed around high > > utilisation with long-holding connections need to be > redesigned around > > ensuring a large enough pool of free capacity. So, in > addition to having to > > address the above issues up-front with SVC-like services, > carriers would > > also be forced to define a 'erlang/pricing model' for > something akin to a > > Gbit PSTN! Depending upon the number of circuits and the > distribution of > > traffic holding times it may not be possible to apply > simply erlang theory > > as is, but rather some modifications will be > required.....and the demand > > model will obviously be an interdependent function of the > pricing model. > > > > Yes. Simple availability metric does not fit the switched model very > well. NH=> True if holding time is not long compared to failure frequency. However, one would expect the holding times to increase as one approaches the duct layer.....but if this is not the case, then the operators had better make sure they have paid enough attention to the demand/pricing models and that these make ecomonic sense. > Since availability measurements are obtained through time > integration of errors, with short connection duration, this metric may > not be appropriate in its current form. For example, if a connection > lasts for one day, and during that time 1 or 2 bit error occur. > Depending on the level of availability offered, this may result in > non-compliance. NH=> I see a distinction between availability and QoS. I would not consider a few bit errors (for example) to impact an availability metric/objective. Further, I would strongly recommend *not* to incorporate normal up-state QoS metrics (eg errors/delay) into some OR'd availability criteria.....it can get very complex (and costly) to measure....and it is probably not worth it. It is better IMO (for a well-engineered/designed network) to rely primarily on defect indications to determine availability entry/exit criteria. Have read of our recent draft on MPLS OAM.....some rationale is given in there. > > Parameters that have been used in traditional PSTN networks need to be > re-examined and modified to fit the new switched network. > These include > those you've mentioned, such as connect attempts, hold times, blocking > probability, erlang traffic model (which already takes hold > times into > consideration) NH=> I wonder how many other operators have actually given much thought to this yet? It certainly concerns many of us in BT at least. > > > 6 Noted the point in para 4.2 regarding ENE 'having > to maintain > > source/sink LSP inventory', but the SNE also needs to maintain its > > server->client layer adaptation mappings....so that on > failure the correct > > FDI information can be sent forward into all affected > clients (and this > > process should recurse for clients of those clients, etc). > > > > Yes. Each NE would still provide the capabilities inherent in an NE, > i.e., adaptation mappings, detection/generation/suppression of various > defects/alarms. Because these are user plane functions, we did not > include discussion of this. > > Do you think it would be worthwhile to have a sentence to describe the > user plane functions? NH=> You could do...but how much would one write? Maybe some references to where such material is specified might suffice. > > I agree with the observation that highest bandwidth does not > necessarily > mean highest priority. Highest bandwidth might be the least critical > application, e.g., file transfer (low priority) vs. voice (high > priority), the bandwidth needs might be reversed. NH=> 2 things: - 1st, an application's forwarding QoS requirements have no relationship to its survivability needs. So whilst voice might be mission critical and data transfer not mission critical in one case, in another case their requirements could be reversed......but in *both* cases they need the same up-state forwarding treatment. So, like-DS-class merging in an LSP raises some availability issues at a per 'application level'. - 2nd, how can we can rank restoration priority amongst LSPs? For the L-LSP case we potentially have the situation referred to above, ie merged same DS class applications may not have the same survivability requirements. In the E-LSP case the situation is even less clear for similar considerations. I also think there is a distinction in how one views the survivability needs of a VPN and general public services, ie voice in a VPN might require different survivability treatment to a general 'public voice' service. I therefore have a concern that some issues relating to availability/QoS have currently not be thought through.......possibly because the emphasis to date has been largely on QoS. > > We will add this discussion in the next revision. BTW, when you state > "an ability to select the priority of restoration post failure between > different trails", do you mean that for all protected connections, the > highest priority protected connection get protected first, second > highest priority get protected second, etc. and that you want the > flexibility to decide what criteria is used to rank the restoration? NH=> In essence yes. What we don't want is compounded bumping....or at least the ability to turn it off. > > Yes, I agree. theses issues should be viewed independently. As you > mention, even within routing protocol, there would be differences in > term of the relevant aspects/constraints for route determination. > Whether these differences could be handled via different protocol or > simply as different extensions need to be further discussed. For > example, would the same algorithm be applicable to both SDH and OTN > networks (most likely?) > > Do you suggest we expand this section to include discussions of these > points? We would be very happy to work with you on extending the > concepts that you've described. NH=> I think there needs to be further discussion. And, perhaps more importantly, I think operators need help to get a better grasp of what the various extensions and redundancies will actually mean for routing/signalling protocols. For example, is building 1 parent protocol with extensions/redundancies better (or worse) than tailoring the protocol for a particular technology? Noting that in the former case, then the whole parent protocol seems as though it would need some re-work each time a new technology/layer was introduced. > > > 11 In section 5.4.3.1 you describe the 4 main stages of > > prot-sw/restoration. I agree. But please don't overlook > these facts that > > are relevant to the first item of failure detection: > > - 1st, we must identify all failure modes > > - 2nd, we must describe their entry/exit criteria > > - 3rd, we must take correct consequent actions, eg > FDI upwards to stop > > alarm storms, BDI backward (if single ended visibility of > both directions > > needed), squelch traffic if trail ID mismatch (important to > protect customer > > traffic...so this is a sort of security consideration, but > it also impacts > > billing etc) > > - 4th, we need to know/define what constitutes up and > down states of > > the trail.....this defines the 2 aspects of availability > SLA and the QoS > > SLA, where the latter only has meaning once the former is > defined (ie only > > valid in up-state) and will generally be based on the > defect handling > > covered by points 1st-3rd above. > > See our draft on MPLS OAM (packet level) where we cover the > above for an > > example of what is required in the user-plane: > > http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt We need a > similar approach for the lower transport layers....and note that there > should be some attempt at metric/objective harmonisation across the layers > in order for any measurements/SLAs taken/applied at each layer to have some > cross-layer relative significance. > Yes, these are very valid points. I believe for points 1-3 above, we can provide a brief description and then refer to existing standards. For point 4, we will need to extend the document. Would you happen to have some text available for us to include in the next revision? NH=> Not currently. From owner-mpls@UU.NET Mon Mar 19 19:18:23 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27072 for ; Mon, 19 Mar 2001 19:18:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcb20925; Tue, 20 Mar 2001 00:16:18 GMT Received: by mail-control.mail.uu.net id QQkhbw27202 for mpls-outgoing; Mon, 19 Mar 2001 23:06:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhbu12112 for ; Mon, 19 Mar 2001 22:40:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgmr24593 for ; Thu, 15 Mar 2001 20:16:29 GMT Received: from auemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkgmr07226 for ; Thu, 15 Mar 2001 20:16:29 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA14550 for ; Thu, 15 Mar 2001 15:16:28 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id PAA14434; Thu, 15 Mar 2001 15:16:22 -0500 (EST) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA00042; Thu, 15 Mar 2001 15:16:21 -0500 Message-ID: <3AB1228E.226FA5EF@lucent.com> Date: Thu, 15 Mar 2001 15:14:06 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: xuyg@lucent.com, mpls@UU.NET, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, evarma@lucent.com Subject: Re: [IP-Optical] RE: Three GMPLS related IDs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Neil, I saw your comments for the set of GMPLS related I-Ds. My comments are in-line (related to the arch-intra-domain ID). > Arch-intra-domain ID: > Note - I like this paper in general, and I guess the reason for this is that > several operators have input (requirements) to it and it is not just sourced > from vendors. > Yes. I think this is a very critical aspect of working on any specification, that operators have input into the process. After all, it is the operators (however large or small) who will be deploying these networks and will have to live with the consequences of a well-specified (or not) standards. If we extend Kireeti's voting weight, I would think an operator's input would have more weight than other's inputs. > Thinking about the further concerns a carrier would have to address in a > connection oriented switched-network, there needs to be a consideration of > blocking probability and users having connection requests refused, ie a GoS > metric. The result is that transport networks currently designed around high > utilisation with long-holding connections need to be redesigned around > ensuring a large enough pool of free capacity. So, in addition to having to > address the above issues up-front with SVC-like services, carriers would > also be forced to define a 'erlang/pricing model' for something akin to a > Gbit PSTN! Depending upon the number of circuits and the distribution of > traffic holding times it may not be possible to apply simply erlang theory > as is, but rather some modifications will be required.....and the demand > model will obviously be an interdependent function of the pricing model. > Yes. Simple availability metric does not fit the switched model very well. Since availability measurements are obtained through time integration of errors, with short connection duration, this metric may not be appropriate in its current form. For example, if a connection lasts for one day, and during that time 1 or 2 bit error occur. Depending on the level of availability offered, this may result in non-compliance. Parameters that have been used in traditional PSTN networks need to be re-examined and modified to fit the new switched network. These include those you've mentioned, such as connect attempts, hold times, blocking probability, erlang traffic model (which already takes hold times into consideration) > 6 Noted the point in para 4.2 regarding ENE 'having to maintain > source/sink LSP inventory', but the SNE also needs to maintain its > server->client layer adaptation mappings....so that on failure the correct > FDI information can be sent forward into all affected clients (and this > process should recurse for clients of those clients, etc). > Yes. Each NE would still provide the capabilities inherent in an NE, i.e., adaptation mappings, detection/generation/suppression of various defects/alarms. Because these are user plane functions, we did not include discussion of this. Do you think it would be worthwhile to have a sentence to describe the user plane functions? > 7 In section 5.3 on path selection source (ERO) and hop-hop routing > are compared. However, the biggest advantage of source routing is not noted > strongly enough.....and that is the fact that one does not need to wait > until a failure to calculate an alternative route from the link-state > database. For very important routes one can pre-calculate an alternative > path and reserve resources, so restoration is very fast. This leads me to > the next point here. > Yes, that is certainly an advantage for fast restoration. We will add text to convey this more clearly. do you happen to have some suggested text handy for us to add? > 8 Although not covered explicitly in this paper, I think something > needs to be said about pre-emtion/bumping. We have extensive experience of > priority selected pre-emption/bumping schemes. And this experience leads us > to have a requirement that we must be able to turn-off any such schemes. > Why? Well, it only comes into any significant effect at high utilisations. > But, because even small changes of loading around the 'congestion knee' can > cause large swings in behaviour, it is at this time that predicting its > effects can be most difficult, and a single failure event can cause multiple > consequential failures as the bumping scheme ripples out. We don't mind > dumping 'extra' traffic, but once dumped there is no way we would want this > to then dump some even lower priority traffic. However, I clearly would not > wish to stop anyone wanting such a scheme to try it out and discover its > usefulness for themselves. Our requirement therefore is (i) an ability to > turn-off any bumping based on priority, but (ii) an ability to select the > priority of restoration post failure between different trails. > BTW - Although the largest BW trails seem like they should be restored 1st > (if the most efficient packing density is the sole criterion), this may not > be the case and we would want to identify trail restoration priority > irrespective of BW. > I agree with the observation that highest bandwidth does not necessarily mean highest priority. Highest bandwidth might be the least critical application, e.g., file transfer (low priority) vs. voice (high priority), the bandwidth needs might be reversed. We will add this discussion in the next revision. BTW, when you state "an ability to select the priority of restoration post failure between different trails", do you mean that for all protected connections, the highest priority protected connection get protected first, second highest priority get protected second, etc. and that you want the flexibility to decide what criteria is used to rank the restoration? > 9 In section 5.3.3 you are hinting at quite an important point > regarding routing protocols. That is, the attributes of a routing protocol > for an OTN will be quite different to that needed for SDH....or indeed IP. > This leads to the question - do we create one all-embracing routing protocol > for all technologies (and have lots of extensions and redundancies) or do we > have different (specifically tailored) routing protocols for different > technologies? We can also say the same, and perhaps more strongly, about > signalling protocols. And indeed also addressing.....this facet definitely > requires independent address spaces per distinct layer network even if based > on the same generic structure. The key point is here is that not only are > these control-plane facets 'different' for different layer networks, but > they are also orthogonal *within* a layer network.....a point which seems to > get glossed over quite regularly. This is not to decry any particular > choice of addressing/signalling/routing protocol combination, just to point > out that it is not a logical way of reasoning to say that either (i) all > layers get treated the same or (ii) *if* you choose addressing schema X you > *must* have signalling protocol Y and you *must* have routing protocol Z. > Indeed for true CO fabrics like an OTN or SDH, it is very hard to agree to > arguments that say it must be v4 (or v6) addressing and it must be RSVP > (indeed it isn't since we also have CR_LDP) and it must be OSPF (and again > indeed it isn't since we also have IS-IS).....but for the NNI BGP seems the > only choice. I have yet to hear what is technically wrong with a > combination of NSAPs, PNNI signalling and IS-IS/BGP...and on the face of it, > these would appear far more logical choices given the nature of the beast > they are controlling; noting that for S-PVC-like services this would also > seem like a more 'off-the-shelf' solution. > Yes, I agree. theses issues should be viewed independently. As you mention, even within routing protocol, there would be differences in term of the relevant aspects/constraints for route determination. Whether these differences could be handled via different protocol or simply as different extensions need to be further discussed. For example, would the same algorithm be applicable to both SDH and OTN networks (most likely?) Do you suggest we expand this section to include discussions of these points? We would be very happy to work with you on extending the concepts that you've described. > 10 In section 5.4.1.5 'actions' on trails are defined. For a CO > network with fixed BW selection at trail creation time it is very hard to > see what a 'modify' action could be....other than perhaps a change of > restoration priority and/or change of dedicated back-up trail/resource. If > there is any notion of (working) BW change here (be it a scalar magnitude > change, ie same route, or a vector change, ie new route (with or without a > scalar magnitude change)), it would seem to me that this is really a new > pair of 'create_new->switch_to_new->delete_old' actions. I note however > that this has been marked as TBD, but I think it would help if it was made > clear that BW changes cannot (IMO) be a single 'modify' action. > Modify command can have different implications depending on what attributes you're modifying and what capabilities exist in the network. Two behaviours of modify are: disruptive modification and non-disruptive modification. For example, in certain cases, you might be able to modify the CoS of a connection without disruption (simply by adding a backup path to the original connection, albeit likely not the optimized route), or if you have LCAS capability, you might be able to increase the bandwidth of a connection without impacting the existing traffic. We will revise this to have more discussion regarding use of the modify command. > 11 In section 5.4.3.1 you describe the 4 main stages of > prot-sw/restoration. I agree. But please don't overlook these facts that > are relevant to the first item of failure detection: > - 1st, we must identify all failure modes > - 2nd, we must describe their entry/exit criteria > - 3rd, we must take correct consequent actions, eg FDI upwards to stop > alarm storms, BDI backward (if single ended visibility of both directions > needed), squelch traffic if trail ID mismatch (important to protect customer > traffic...so this is a sort of security consideration, but it also impacts > billing etc) > - 4th, we need to know/define what constitutes up and down states of > the trail.....this defines the 2 aspects of availability SLA and the QoS > SLA, where the latter only has meaning once the former is defined (ie only > valid in up-state) and will generally be based on the defect handling > covered by points 1st-3rd above. > See our draft on MPLS OAM (packet level) where we cover the above for an > example of what is required in the user-plane: > http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt We need a > similar approach for the lower transport layers....and note that there > should be some attempt at metric/objective harmonisation across the layers > in order for any measurements/SLAs taken/applied at each layer to have some > cross-layer relative significance. > Yes, these are very valid points. I believe for points 1-3 above, we can provide a brief description and then refer to existing standards. For point 4, we will need to extend the document. Would you happen to have some text available for us to include in the next revision? Regards, Zhi From owner-mpls@UU.NET Mon Mar 19 19:21:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27141 for ; Mon, 19 Mar 2001 19:21:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcb15172; Tue, 20 Mar 2001 00:20:00 GMT Received: by mail-control.mail.uu.net id QQkhbw27389 for mpls-outgoing; Mon, 19 Mar 2001 23:06:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhbu12513 for ; Mon, 19 Mar 2001 22:43:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgnc08363 for ; Thu, 15 Mar 2001 23:04:32 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkgnc21979 for ; Thu, 15 Mar 2001 23:04:32 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f2FN4UR15455; Thu, 15 Mar 2001 18:04:30 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; THU, 15 Mar 2001 18:01:34 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 18:01:34 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E56993D54@newman.tenornet.com> From: "Shah, Himanshu" To: "'mpls@uu.net'" , "'nbvpn@bbo.com'" Subject: another draft: draft-shah-mpls-l2vpn-reduce-00.txt Date: Thu, 15 Mar 2001 18:01:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0ADA3.E144CE52" 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_01C0ADA3.E144CE52 Content-Type: text/plain; charset="iso-8859-1" Hello, Another draft that uses extensions documented in draft-shah-mpls-l2vpn-ext-00.txt. Both of these drafts will be submitted when the blackout lifts.... From the abstract: This document will describe how provider's edge router can reduce the over-provisioning of resources and in some cases do away with the range configuration so that new sites can be added to an existing VPN topologies without incurring configuration changes to other provider's edge routers in the VPN. <> Himanshu Shah Tenor Networks Acton, MA ------_=_NextPart_000_01C0ADA3.E144CE52 Content-Type: text/plain; name="vpn-reduce.txt" Content-Disposition: attachment; filename="vpn-reduce.txt" Content-Transfer-Encoding: quoted-printable Himanshu Shah = Internet Draft Tenor Networks = Draft-shah-l2vpn-mpls-reduce.txt = Expires: September 2001 March 2001 = =20 =20 Reducing over-provisioning for MPLS based L2VPN=20 =20 =20 1.0 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = =20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents = at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress." = =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 2.0 Abstract=20 =20 This document will describe how provider=92s edge router can reduce=20 the over-provisioning of resources and in some cases do away with=20 the range configuration so that new sites can be added to an=20 existing VPN topologies without incurring configuration changes to=20 other provider=92s edge routers in the VPN.=20 =20 3.0 Overview=20 =20 The draft-kompella-mpls-l2vpn-02.txt [MPLS] describes methodologies=20 by which layer 2 circuits can be mapped through MPLS tunnels to=20 remote sites that belong to the same VPN. It greatly reduces the=20 configuration and improves scalability through the use of LSP=20 hierarchical model. The reduction in configuration is partly based=20 on over-provisioning of the resources.=20 =20 This aspect of over-provisioning of resources on an a priori basis=20 is problematic. This document proposes some models whereby resources = are committed in limited fashion, as and when the newer sites join=20 the existing VPN. These models require in some cases additional=20 configuration and add to distribution of information amongst PE=20 routers. However, the benefits compensate the drawbacks.=20 =20 =20 Shah Informational - Expires September 2001 1 = =0D=0C Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001=20 =20 =20 The service provider starts with some decisions on characteristics=20 of the offered VPN topologies; for instance whether VPN is full-mesh = or hub-and-spoke, how many sites would he consider safe to add=20 without additional configuration, the type of clients (i.e. routers=20 or switches), etc.=20 =20 The proposed models are more beneficial in some topologies and less=20 in others.=20 =20 4.0 Introduction=20 =20 With the advent of extensions proposed in draft-shah-mpls-l2vpn-ext- 00.txt [MPLS-shah] to the base draft-kompella-mpls-l2vpn-02.txt=20 [MPLS], it is possible to articulate a model whereby the PE router=20 does not have to over-provision all the resources required for the=20 MPLS based layer 2 VPN. =20 =20 The extension draft [shah], proposes a mechanism whereby, VPN=20 information can be distributed in fragments. Each fragment includes=20 the range of CE-ID that the advertising PE router is willing to=20 connect to. The total number of CE-ID the PE router would then=20 connect to, stems from the cumulating ranges of the CE-ID present in = each fragment. =20 =20 5.0 Operations=20 =20 The following sections describe how a service provider could offer=20 VPN services with varying configuration on the PE router and how=20 that relates to varying level of over-provisioning and other=20 benefits.=20 =20 First a basic unit of VPN information is defined, followed by=20 actions performed on this unit.=20 =20 5.1 VPN information set=20 =20 A set for a given VPN and CE-ID is defined as a subset of VPN=20 information consisting of CE-Base, CE-Range and a set of PVCs and=20 interface information. CE-Ids that is greater than or equal to CE- Base and less than CE-Range are considered to be the part of the=20 set. Combination of all the sets would then represent the entire=20 VPN information for a given CE-ID of a VPN on a PE router. Each set=20 for a given VPN + CE-ID is disjoint from other sets present for the=20 same VPN + CE-ID. They must never overlap. Also, CE-Range minus CE- Base must be greater than or equal to one but never zero.=20 =20 The VPN information set is either active or inactive. Active state=20 means that label resources have been allocated and the VPN=20 information set has been advertised. Inactive state indicates=20 existence of the set without label allocation and unadvertised=20 status. An active set becomes inactive when VPN information of the=20 set is withdrawn.=20 =20 =20 Shah Informational - Expires September 2001 2 = =0D=0C Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001=20 =20 =20 5.2 Set Activation=20 =20 The VPN information set is considered activated when a range of=20 labels are allocated for the set. These labels do not have to be=20 contiguous for a whole set as shown in draft-shah-mpls-l2vpn-00.txt=20 [MPLS-shah]. However, the total number of labels allocated for the=20 set must match the CE-Range minus the CE-Base of the set. The set is = then advertised to remote PE peers in one or more fragments as=20 described in draft-shah-mpls-l2vpn-00.txt [MPLS-shah]. If the set=20 consists of more than one fragment, all the fragments must be=20 advertised before the set is considered active.=20 =20 Also, note that when a PE router receives an advertisement, it must=20 send active set(s), which contain configured CE-ID and received CE- ID.=20 =20 The set is activated under following circumstances.=20 1. A set matching the local CE-ID=20 2. A received CE-ID matches one of the set (as allowed by the=20 color match), i.e. falls within CE-Base and CE-Range of the=20 local set for the VPN. It is quite possible that the received=20 set information may not contain the local CE-ID. This is OK. It = is expected that those remote PE peers whose sets contain the=20 sent local CE-ID, would respond with active sets that contain=20 the local CE-ID.=20 =20 An activated set may not become active if all the label resources=20 could not be obtained or there were issues with advertisements.=20 =20 5.3 Set Deactivation=20 =20 The VPN information set is considered deactivated when the=20 advertisement of the set is withdrawn and the label resources are=20 freed. The set must be deactivated in its entirety. This means all=20 the fragments advertised for this set, must be withdrawn.=20 =20 The set is deactivated for the reasons described in draft-kompella- mpls-l2vpn-02.txt [MPLS]. The set can also be deactivated on a=20 periodic garbage collection basis when upon inspection found to hold = no received advertisements for the CE-ID present in the set from=20 remote PE peer and no local CE-ID matches the set either. To protect = against possible race conditions or excessive advertisements, one=20 should use least recently used type of algorithm with periodic=20 garbage collection.=20 =20 5.4 Configuration options=20 =20 Following configuration options describe various operational models=20 that offer varying benefits of reduction in over-provisioning=20 coupled with flexibility of adding newer sites with minimal to none=20 reconfiguration. =20 =20 =20 Shah Informational - Expires September 2001 3 = =0D=0C Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001=20 =20 =20 5.4.1 Option-1=20 =20 In this model, service provider configures sets on each PE router=20 for a given VPN and a CE-ID. The PE router then locates the set that = contains the local CE-ID and allocates the resources for this set.=20 Initially, only the set containing the local CE-ID is advertised to=20 remote PE peers. When VPN information is received for a given VPN,=20 the received CE-ID is matched against the configured sets for the=20 VPN + CE-ID. If a set is found and is not active, the set is=20 activated by allocating the resources and sending out the new=20 advertisement.=20 =20 The advantage of this model is that service provider controls the=20 range of CE-Ids that a particular PE router would admit. For=20 example, a given VPN has 50 sites and the customer wishes sub-VPN=20 cluster of CE-IDs 0 to 10 and 30 to 40. The service provider would=20 then configure PE routers connected to those CE that fall in these=20 ranges, with two sets of the VPN information. In this situation,=20 over-provisioning is limited to either one set or two sets (i.e. 20) = but not the full range (i.e. 50).=20 =20 5.4.2 Option-2=20 =20 In this model, service provider configures maximum range and an=20 increment value along with PVC and interface information in a PE=20 router for a given VPN and a CE-ID. The PE router then breaks the=20 range using the increment value into distinct sets with CE-Base, CE- Range and the related PVC and interface information.=20 =20 Initially, the local CE-ID is matched against the sets and the=20 matching set is activated. As and when VPN information from the=20 remote PE peers is received, the CE-ID is matched against the local=20 sets. The matching set is then activated, if not already, and a new=20 advertisement is sent with active sets that contain both the local=20 CE-ID and remote CE-ID. The remote PE reciprocates with same=20 processing yielding a new advertisement, if necessary.=20 =20 This approach reduces the configuration significantly as compared to = option 1 but relies on color matching mechanisms to form sub-VPN=20 clusters or hub-and-spoke type of VPN topologies.=20 =20 5.4.3 Option-3=20 =20 In this model, only VPN, CE-ID and associated interface are=20 configured. A reasonable increment as a default is ascertained and=20 the maximum range is obtained based on the type of interface. For=20 instance, if the interface is frame relay, maximum assumed for 2- byte DLCIs would be 992 (16 to 1008). Using the increment, sets are=20 created. Initially, only the set that contains the local CE-ID is=20 activated. Subsequently, as and when advertisement from remote PE is = received, the matching sets are activated.=20 =20 =20 Shah Informational - Expires September 2001 4 = =0D=0C Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001=20 =20 =20 This model offers maximum flexibility and minimum configuration.=20 However, it is applicable to limited number of customer topologies.=20 For instance, it is more suitable to customer edge devices that are=20 frame relay DTE devices and are capable of handling new DLCIs=20 activating in real time. Its narrow applicability, however, does not = necessarily diminish its advantages since topologies like frame=20 relay might be the most used topologies for MPLS based L2VPN=20 services.=20 =20 By doing away with range configuration, new sites can be added=20 without having to worry about re-adjusting the ranges on existing PE = routers. =20 =20 5.4.4 Option-4=20 =20 In this model, service provider assumes the VPN topology to be in a=20 trusted environment. The PE router is configured for the role it=20 plays in the VPN topology. For instance, if the VPN is hub-and-spoke = and the PE router is a spoke, the range values configured in the=20 router are treated stricter than the PE routers that are hub. The=20 rest of the VPN information is configured as discussed earlier.=20 =20 When a new spoke site is added, the advertisement processed on the=20 hub PE router differs from spoke PE router. If the received CE-ID=20 does not match any of the local sets on the hub site, PE router=20 would increase the range in chunks (as determined by configured=20 increments) until the CE-ID falls under one of the set. This set is=20 then activated. =20 =20 The PE routers at the spoke site on the other hand would discard the = advertisement if the received CE-ID did not match any of the local=20 set.=20 =20 In case of full-mesh VPN topologies, PE router processes the out-of- scope advertisements like a hub PE router.=20 =20 In this model, range is elastic (up to a point) for hub and full=20 mesh PE routers while stricter for spoke PE routers. =20 =20 6.0 Conclusion=20 =20 The various models described in this document allow PE routers to=20 allocate resources on a pay as you go basis. As and when newer sites = are added to the VPN, the existing PE routers may or may not have to = allocate additional resources based on whether the newer site falls=20 under the already allocated resources. When needed, resources are=20 allocated in small chunks rather than one big chunk. =20 =20 However, there is a tradeoff between the over-provisioning and=20 scalability. In worst-case scenario, when the increments are of size = one, a greater number of VPN information sets are exchanged between=20 the PE routers but then over-provisioning is null. There is a=20 =20 Shah Informational - Expires September 2001 5 = =0D=0C Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001=20 =20 =20 balance that a service provider can choose, having given all the=20 options.=20 =20 7.0 Acknowledgements=20 =20 Author would like to thank Xavier Briard and Bill Townsend for=20 reviewing the draft.=20 =20 =20 8.0 References=20 =20 [MPLS] Kompella et al., "MPLS based Layer 2 VPNs", draft-kompella- mpls-l2vpn-02.txt, November 2000.=20 =20 [MPLS-shah] Shah et al., "Extensions to MPLS based Layer 2 VPNs",=20 draft-shah-l2vpn-ext-00.txt, March 2001=20 =20 =20 =20 =20 Author's Address=20 =20 Himanshu Shah=20 Tenor Networks=20 100 Nagog Park=20 Acton, MA 01720=20 hshah@tenornetworks.com=20 =20 =20 =20 =20 Shah Informational - Expires September 2001 6 = =0D=0C ------_=_NextPart_000_01C0ADA3.E144CE52-- From owner-mpls@UU.NET Mon Mar 19 19:26:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27250 for ; Mon, 19 Mar 2001 19:26:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcb29577; Tue, 20 Mar 2001 00:24:13 GMT Received: by mail-control.mail.uu.net id QQkhca15801 for mpls-outgoing; Tue, 20 Mar 2001 00:03:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhby02418 for ; Mon, 19 Mar 2001 23:32:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhby12879 for ; Mon, 19 Mar 2001 23:32:16 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhby22970 for ; Mon, 19 Mar 2001 23:32:07 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA08943 for mpls@uu.net; Mon, 19 Mar 2001 18:32:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhbu11997 for ; Mon, 19 Mar 2001 22:40:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgkb05423 for ; Thu, 15 Mar 2001 03:22:20 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkgkb10985 for ; Thu, 15 Mar 2001 03:22:20 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA07123; Wed, 14 Mar 2001 22:21:32 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABB14481; Wed, 14 Mar 2001 22:22:12 -0500 (EST) Message-Id: <4.3.2.7.2.20010314222525.01b5bbe8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Mar 2001 22:26:52 -0500 To: "Anuj Bhatnagar" , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Cross Connect traps from mplsXC entry in a router In-Reply-To: <85256A0F.00780C44.00@notes950.cc.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Thanks Tom, I really appreciate your inputs on the benefits of various traps. > >However, I have one more question if you don't mind please! > >Can I still retrieve information that which LSP an mplsXC belonged to even >after >a label set is removed from TFIB (how long before the entry in XC table >indicates "down" and disappears)? That depends on the implementation. They disappear immediately on our implementation. Other implementations might choose to let them hang around a bit. --Tom From owner-mpls@UU.NET Mon Mar 19 19:29:10 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27329 for ; Mon, 19 Mar 2001 19:29:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcb26410; Tue, 20 Mar 2001 00:26:47 GMT Received: by mail-control.mail.uu.net id QQkhbw27764 for mpls-outgoing; Mon, 19 Mar 2001 23:06:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhbu11382 for ; Mon, 19 Mar 2001 22:40:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgmt21732 for ; Thu, 15 Mar 2001 20:45:28 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkgmt24901 for ; Thu, 15 Mar 2001 20:45:27 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 PAA06654 for ; Thu, 15 Mar 2001 15:45:27 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id PAA06638; Thu, 15 Mar 2001 15:45:26 -0500 (EST) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA02664; Thu, 15 Mar 2001 15:45:25 -0500 Message-ID: <3AB1293D.1DF8E93D@lucent.com> Date: Thu, 15 Mar 2001 15:42:37 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: xuyg@lucent.com, mpls@UU.NET, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, evarma@lucent.com Subject: Re: [IP-Optical] RE: Three GMPLS related IDs References: Content-Type: multipart/mixed; boundary="------------EFA0801E37B34DECCDA65E0F" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------EFA0801E37B34DECCDA65E0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Neil, The label-request contribution was revised to include a mapping between the EDCBA and SU mapping. Since this was submitted after the IETF deadline, they did not post. Attached is the revised version of that draft. Regards, Zhi neil.2.harrison@bt.com wrote: > Here are my observations on the sig-reorg and arch-intra-domain IDs (I could > not open the label-request one): > --------------EFA0801E37B34DECCDA65E0F Content-Type: text/plain; charset=us-ascii; name="draft-lin-ccamp-ipo-common-label-request-01.txt" Content-Disposition: inline; filename="draft-lin-ccamp-ipo-common-label-request-01.txt" Content-Transfer-Encoding: 7bit Network Working Group Internet Draft Expiration Date: September 2001 Maarten Vissers Zhi-Wei Lin Yangguang Xu Siva Sankaranarayanan Lucent Technologies, Inc. Common Label and Label Request Specification for Automatic Switched Transport Network draft-lin-ccamp-ipo-common-label-request-01.txt 1. 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. 2. Abstract This draft completes the [GMPLS-REORG] draft and details technology specific issues. It proposes different approach and enhancement to [GMPLS-SIG] and [GMPLS-SIGEN]. Changes are: -- New set of Signal Type structures of ETSI-PDH, ANSI-PDH, SONET, SDH and OTN for Generalized Label Request [GMPLS-SIG]. -- G-PIDs associated each signal type for G-Label Request. -- Label Channel ID [GMPLS-REORG] field structure. -- Conversion formula for ITU-T (G.707) EDCBA to SU numbering scheme. Z. Lin et. al. Page [1] Internet Draft G-Label and G-Label Request Specification March 2001 3. G-Label Request Specification 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type | Signal Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type | Dir | Rserved | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LSP Encoding Type and Signal Type together identify the unique signal type of the LSP. 3.1 LSP Encoding LSP Encoding Type: 8 bit Indicates the encoding technology of the LSP being requested. Value Type ----- -------- 3 ANSI PDH 4 ETSI PDH 5 SDH 6 SONET 7 OTN 8 Analog 3.2 Signaling Type and Associated G-PID Signaling Type: 24 bits Indicates the specific signal type of the LSP being requested. This field is interpreted according to the technology specified by LSP Encoding Type. The Signal Type provides transit switches with the information required to determine which link connection can support the LSP. G-PID: 16 bits Indicates the payload carried by an LSP, i.e. an identifier of the client layer of the LSP. It's the same as Payload Types in G.709, Signal Label in G.707 and L3PID in RSVP-TE. Each of signal type may only allow certain types of client signals. The G-PID is mainly used by the adaptation layer function at the LSP terminating points. G-PID is associated with each signal type. Z. Lin et. al. Page [2] Internet Draft G-Label and G-Label Request Specification March 2001 3.2.1 ANSI PDH Signaling Type Permitted values and their meaning for LSP Encoding Type ANSI-PDH: Value Type ----- ---- 1 DS1 SF 2 DS1 ESF 3 DS2 4 DS3 M23 5 DS3 C-bit Parity 6 DS4 When the technology encoding type is ANSI-PDH, GPID can take the following values: Value Client Type ----- ----------- 0 Unknown 3.2.2 ETSI PDH Signaling Type Permitted values and their meaning for LSP Encoding Type ETSI-PDH: Value Type ----- ---- 1 E1 P12x 2 E1 P12s 3 E2 P22x 4 E2 P22e 5 E3 P31x 6 E3 P31e 7 E3 P31s 8 E4 P4x 9 E4 P4e 10 E4 P4s 3.2.3 SDH Signaling Type For SONET/SDH, the 24-bit Signal Type SHALL be encoded in the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type | Type | X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Z. Lin et. al. Page [3] Internet Draft G-Label and G-Label Request Specification March 2001 Type: 8 bits Indicates specific signal type of a LSP encoding type X : 16 bits Indicates concatenation value. Permitted type values and their meaning for LSP Encoding Type SDH are: Value Type ----- -------- 1 VC-11 2 VC-12 3 VC-2 4 VC-2-Xc (1<=x<=7) 5 VC-3 6 VC-4 7 VC-4-Xc (X=4,16,64,256) 8 MS-X (STM-X MS) (X=1,4,16,64,256) 9 STM-X (X=1,4,16,64,256) 10 VC-11-Xv (1<=X<=64) 11 VC-12-Xv (1<=X<=64) 12 VC-2-Xv (1<=X<=64) 13 VC-3-Xv (1<=X<=256) 14 VC-4-Xv (1<=X<=256) 15 VC-11-Xv LCAS 16 VC-12-Xv LCAS 17 VC-2-Xv LCAS 18 VC-3-Xv LCAS 19 VC-4-Xv LCAS 20 VC-11-X ** 21 VC-12-X 22 VC-2-X 23 VC-3-X 24 VC-4-X 128 TUG-2 129 TUG-3 130 AUG-X (X=1,4,16,64,256) 131 VC-4-Xa (1<=X<=256) 132 STM-Xst 133-143 Reserved for vendor specific SDH signal type ** This is used at intermediate nodes to support the LCAS when a subset of the link connections are co-routed. Z. Lin et. al. Page [4] Internet Draft G-Label and G-Label Request Specification March 2001 The "MS-X" and "STM-X" Signal types represent transparent STM Multiplex Section and Regenerator Section LSPs respectively. Note that the "STM-X" signal type represents the complete STM-N signal, including all its SOH. The "VC-n-Xc" Signal Type represents a contiguous standard concatenated VC-n signal (ITU-T Rec. G.707), which is transported via the AU and TU timeslots according to the (E,D,C,B,A) and (K,L,M) structures. The "VC-n-Xv" Signal type represents a virtual concatenated VC-n signal. The "VC-n-Xv LCAS" Signal type represents a VC-n-Xv signal with Link Capacity Adjustment Scheme (LCAS) capability. The "VC-n-X" Signal type represents a group of VC-n signals that are to be co-routed. Besides the set of signal types derived from the SDH standards, a number of additional signal types are defined. These additional signal types are vendor specific extensions of the SDH standards. The "AUG-X" Signal type represents an AUG-X bandwidth, of which the specific AU structure is not predefined. This AUG-X link will autonomously adapt to the incoming AU structure. Idem for TUG-2 and TUG-3. The "VC-4-Xa" Signal type represents a contiguous arbitrary concatenated VC-4 signal. The "STM-Xst" Signal type represents a "semi transparent" STM-X signal. The AUG-X and some of the SOH (vendor specific selection) is transported through the link connection. Interworking between equipment of different vendors is not to be expected. To support other vendor specific SDH signal types a set of 13 code points (133-143) is reserved. Within its subnetwork a vendor may assign these code points to its specific signals. The G-PIDs associated with each Signal Type are (based on G.707): VC-11: (1) async 1.544 Mbps, (2) bit sync 1.544 Mbps, (3) byte sync 1.544 Mbps, (4) byte sync 384 kbps, (5) ATM, (6) HDLC framed, (7) GFP framed VC-12: (1) async 2.048 Mbps - transparent, (2) async 2.048 Mbps - terminated, (3) byte sync 2.048 Mbps - transparent, (4) byte sync 2.048 Mbps - terminated, (3) 31x64 kbps, (4) ATM, (5) HDLC framed, (7) GFP framed VC-2: (1) async 6.312 Mbps, (2) bit sync 6.312 Mbps, (3) ATM, (4) HDLC framed, (5) GFP framed VC-2-Xc: (1) ATM, (2) HDLC framed w/ scrambling VC-3: (1) 44.736 Mbps - transparent, (2) 44.736 Mbps - terminated, (3) 34.368 Mbps - transparent, (4) 34.368 Mbps - terminated G.751 frame, (5) 34.368 Mbps - terminated G.832 frame, (3) TUG (4) ATM, (5) HDLC framed w/ scrambling, (6) GFP framed Z. Lin et. al. Page [5] Internet Draft G-Label and G-Label Request Specification March 2001 TUG-2: (1) one TU-2, (2) three TU-12, (3) four TU-11 TUG-3: (1) one TU-3, (2) seven TUG-2 VC-4: (1) 139.264 Mbps - transparent, (2) 139.264 Mbps - terminated G.751 frame, (3) 139.264 Mbps - terminated G.832 frame, (4) TUG, (5) ATM, (6) HDLC framed w/ scrambling, (7) DQDB, (8) async FDDI, (9) GFP framed VC-4-4c: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-4-16c: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-4-64c: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-4-256c: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed AUG-1: (1) one AU-4, (2) three AU-3 AUG-4: (1) four AUG-1, (2) one AU-4-4c AUG-16: (1) four AUG-4, (2) one AU-4-16c AUG-64: (1) four AUG-16, (2) one AU-4-64c AUG-256: (1) four AUG-64, (2) one AU-4-256c MS-X: (1) AUG-X STM-X: VC-11-Xv: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-12-Xv: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-2-Xv: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-3-Xv: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-4-Xv: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-11-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-12-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-2-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-3-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-4-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed VC-11-X group that is co-routed: (0) unknown VC-12-X group that is co-routed: (0) unknown VC-2-X group that is co-routed: (0) unknown VC-3-X group that is co-routed: (0) unknown VC-4-X group that is co-routed: (0) unknown 3.2.4 SONET Signaling Type Permitted type values and their meaning for LSP Encoding Type SONET are: Value Type ----- -------- 1 VT1.5 2 VT2 3 VT3 4 VT6 5 STS-1 SPE 6 STS-Xc SPE (X=3,12,48,192,768) 7 STS-X SPE (X=1,3,12,48,192,768) 8 STS-X Line (X=1,3,12,48,192,768) Z. Lin et. al. Page [6] Internet Draft G-Label and G-Label Request Specification March 2001 9 STS-X (X=1,3,12,48,192,768) 10 VT1.5-Xv (1<=X<=64) 11 VT2-Xv (1<=X<=64) 12 VT3-Xv (1<=X<=64) 13 VT6-Xv (1<=X<=64) 14 STS-1-Xv (1<=X<=256) 15 STS-3c-Xv (1<=X<=256) 16 VT1.5-Xv LCAS 17 VT2-Xv LCAS 18 VT3-Xv LCAS 19 VT6-Xv LCAS 20 STS-1-Xv LCAS 21 STS-3c-Xv LCAS 22 VT1.5-X ** 23 VT2-X 24 VT3-X 25 VT6-X 26 STS-1-X 27 STS-3c-X 128 VTG 129 STS Group-X (X=3,12,48,192,768) 130 STS-3c-Xa (1<=X<=256) 131 STS-Xst 132-143 Reserved for vendor specific SONET signal type ** This is used at intermediate nodes to support the LCAS when a subset of the link connections are co-routed. The "STS-X Line" and "STS-X" Signal types represent transparent STS Line and STS Section LSPs respectively. Note that the "STS-X" signal type represents the complete STS-N signal, including all its TOH. The "STS-Xc" Signal Type represents a contiguous standard concatenated STS signal (ANSI T1.105), which is transported via the STS timeslots according to the (E,D,C,B,A) structures. The "VTn-Xv" and "STS-n-Xv" Signal types represent virtual concatenated VT and STS signals. The "VTn-Xv LCAS" and "STS-n-Xv LCAS" Signal type represent VTn-Xv and STS-n-Xv signal with Link Capacity Adjustment Scheme (LCAS) capability. The "VTn-X" and "STS-n-X" Signal types represent a group of VTn and STS-n signals that are to be co-routed. Besides the set of signal types derived from the SONET standards, a number of additional signal types are defined. These additional signal types are vendor specific extensions of the SONET standards. The "STS Group-X" Signal type represents an STS Group bandwidth, of which the specific STS structure is not predefined. This STS Group-X link will autonomously adapt to the incoming STS structure. Idem VTG. Z. Lin et. al. Page [7] Internet Draft G-Label and G-Label Request Specification March 2001 The "STS-3c-Xa" Signal type represents a contiguous arbitrary concatenated STS-3c signal. The "STS-Xst" Signal type represents a "semi transparent" STS-X signal. The STS-X SPE and some of the TOH (vendor specific selection) is transported through the link connection. Inter-working between equipment of different vendors is not to be expected. To support other vendor specific SONET signal types a set of 13 code points (132-143) is reserved. Within its subnetwork a vendor may assign these code points to its specific signals. The G-PIDs associated with each Signal Type are (based on T1.105): VT1.5: (1) async DS1 (1.544 Mbps), (2) bit sync DS1, byte sync DS1, (3) GFP framed VT2: (1) async 2.048 Mbps, (2) bit sync 2.048 Mbps, (3) byte sync 2.048 Mbps, (4) GFP framed VT3: (1) async DS1C (3.152 Mbps) VT6: (1) async DS2 (6.312 Mbps), (2) GFP framed STS Group-X: (1) STS-X SPE STS-1 SPE: (1) async DS3 (44.736 Mbps), (2) VTG, (3) GFP framed STS-3c SPE: (1) ATM, (2) HDLC framed, (3) GFP framed, (4) SDL w/ scrambler STS-12c SPE: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler STS-48c SPE: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler STS-192c SPE:(1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler, 10 Gbps Ethernet STS-768c SPE:(1)ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler STS-1 Line: STS-3 Line: STS-12 Line: STS-48 Line: STS-192 Line: STS-768 Line: STS-1: STS-3: STS-12: STS-48: STS-192: STS-768: VT1.5-Xv: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler VT2-Xv: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler VT3-Xv: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler VT6-Xv: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler STS-1-Xv: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler STS-3c-Xv: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler VT1.5-Xv LCAS: VT2-Xv LCAS: VT3-Xv LCAS: Z. Lin et. al. Page [8] Internet Draft G-Label and G-Label Request Specification March 2001 VT6-Xv LCAS: STS-1-Xv LCAS: STS-3c-Xv LCAS: 3.2.5 OTN Signaling Type For OTN, the permitted signal types are Value Type ----- -------- 1 ODU1 2 ODU2 3 ODU3 10 OCh - further typing will be added to OCh G-PIDs for ODU1 include: Value Type ----- -------- 1 CBR2G5a (asynchronous constant bit rate of 2.5 Gbps such as STM-16 or OC-48) 2 CBR2G5b (bit synchronous constant bit rate of 2.5 Gbps such as STM-16 or OC-48) 3 ATM2G5 4 GFP2G5 (used for transporting data, e.g., IP @ 2.5 Gbps) 5 BSOT2G5 (mapping of non-specific client bit stream w/ octet timing) 6 BSNT2G5 (mapping of non-specific client bit stream w/o octet timing) G-PIDs for ODU2 include: Value Type ----- -------- 1 CBR10Ga 2 CBR10Gb 3 ATM10G 4 GFP10G 5 BSOT10G 6 BSNT10G G-PIDs for ODU3 include: Value Type ----- -------- 1 CBR40Ga Z. Lin et. al. Page [9] Internet Draft G-Label and G-Label Request Specification March 2001 2 CBR40Gb 3 ATM40G 4 GFP40G 5 BSOT40G 6 BSNT40G G-PIDs for OCh include: Value Type ----- -------- 1 OTU1 2 OTU1V 3 OTU2 4 OTU2V 5 OTU3 6 OTU3V 7 STM-16/OC-48 8 STM-64/OC-192 9 STM-256/OC-256 10 1 GbE 3.3 Directionality and Service Type are defined in [GMPLS-REORG]. 4. G-label Channel ID Specification 4.1 G-Label Specification [GMPLS-REORG] introduces two type of Label format for automatically switched transport network. Basic Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | G-Label (Port ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D | G-Label (Channel ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hierarchical Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // G-Label (Connection ID) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D | G-Label (Channel ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Z. Lin et. al. Page [10] Internet Draft G-Label and G-Label Request Specification March 2001 4.2 G-Label Channel ID for SONET/SDH For SDH/SONET, the label identifies both a timeslot in the SDH/SONET frame as well as a Connection Termination Point (CTP) in the equipment. The Channel ID of the G-label represents for SDH/SONET either the AU/STS timeslots or the TU/VT timeslots. SDH/SONET are technologies encompassing multiple independent layer networks. Trails and connections in layer networks are set up and torn down independent of trails and connections in their server layer networks. Trails and connections in layer networks are modified independent of trails and connections in their server and client layer networks. Typically, server layer trails must have been set up before client layer connections and trails can be set up. Server layer trails provide the client layer link connections (label switched hops). As such, STM-N/OC-N (i.e. multiplex section/line) trails must have been established before HOVC connections and trails can be set up. Similarly, VC-4/STS-1 trails must have been established before LOVC/VT connections and trails can be set up. There is a multiplicity of ports (physical and logical) in SDH/SONET equipment; STM-N/OC-N physical ports, HOVC/STS logical ports, LOVC/VT logical ports. In future hybrid OTN/SDH/SONET equipment STM-N/OC-N ports might also be logical ports. HOVC/STS signals can be transported over STM-N/OC-N signals. LOVC/VT signals can be transported over either VC-4/VC-3/STS-1 signals, or sub- STM-0/sub-STS-1 signals (e.g. sSTM-1k [k=1,2,4,8,16], sSTM-2n [n=1,2,4]), or 34 376 and 139 264 kbit/s signals with G.832 framing. STM-N/OC-N signals aggregate HOVC/STS signals. The associated multiplex structure may be adapted during the lifetime of the STM-N/OC-N trail to accommodate the requested mix of HOVC/STS signal types. VC-4/VC-3/STS-1 signals aggregate LOVC/VT signals. The associated multiplex structure may be adapted during the lifetime of the VC-4/VC-3/STS-1 trail to accommodate the requested mix of LOVC/VT signal types. At any moment in time, the complete aggregation bandwidth's multiplex structure must be defined to prevent alarms to be raised. SDH/SONET equipment may have either no switch fabric, or a HOVC/STS switch fabric, or a LOVC/VT switch fabric, or a HOVC/STS and a LOVC/VT switch fabric. SDH/SONET interfaces on none-SDH/SONET equipment typically have no switch fabric. Hybrid equipment may have SDH/SONET type switch fabrics in addition to client layer (e.g. ATM VP, ATM, VC, IP, Ethernet) switch fabrics and/or server layer (e.g. OTN OCh, OTN ODUk) switch fabrics. Installing fibers between equipment will establish physical layer trails, Z. Lin et. al. Page [11] Internet Draft G-Label and G-Label Request Specification March 2001 but most likely no HOVC/STS or LOVC/VT trails, despite that there might be some SDH/SONET interfaces without switch fabrics connected at the edge of the (sub)network. Therefore, HOVC/STS labels are independent of LOVC/VT labels. Each one will have a dedicated Channel ID. 4.2.1. HOVC/STS specific Channel ID in STM-N/OC-N The latest version of G.707 (10/00) has defined a naming structure for the AU's, similar to that for the TU's. AUs are now named according the (E,D,C,B,A) structure (TUs are named according the (K,L,M) structure). This (E,D,C,B,A) structure identifies the AU type, the location in the STM-N/OC-N frame and at the same time implies a restriction on the AU-4- Xc/STS-Xc types and the timeslots these signals can be transported over. Vendor specific extensions exist that have fewer restrictions. To accommodate both cases in a single channel ID structure, HOVC/STS channel IDs are represented by means of the "SU" structure. A conversion between (E,D,C,B,A) and SU is included. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S | U | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1. S is the index of a particular AUG-X/STS-X, AU/STS, STM-Xst signal. S=1->N indicates the first timeslot of a specific AUG-X/STS-X, AU/STS, STM-Xst inside an STM-N/STS-N multiplex. For example, S=1 indicates the first AUG-1/STS-3, and S=N indicates the last AUG-1/STS-3 of this multiplex. S=0 is invalid. 2. U indicates if the AUG-1/STS-3 is subdivided. U=1 indicates that the AUG-1/STS-3 is not further subdivided and contains an AU-4/STS-3c. U=2->4 indicates a specific AU-3/STS-1 inside the given AUG-1/STS-3. For the other signals, U is not-applicable and is fixed to 0. 4.2.2. TU/VT specific Channel ID portion in VC-4 and STS-1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | K | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For SDH VC-4 and VC-3, this is an extension of the numbering scheme defined Z. Lin et. al. Page [12] Internet Draft G-Label and G-Label Request Specification March 2001 in G.707 section 7.3, i.e. the (K, L, M) and (L,M) numbering. For SONET and SDH VC-3 the K field is not significant and must be set to zero. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non- significant field. When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. 1. K is only significant for SDH VC-4 and must be ignored for SONET and SDH VC-3. It indicates a specific branch of a VC-4. K=1 indicates that the VC-4 is not further sub-divided and contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-4. 2. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for an unstructured VC-4, and must be 0 in this case. L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further sub-divided and contains a TU-3 in SDH; It is not applicable for SONET. L=2->8 indicates a specific TUG-2/VT Group inside the corresponding higher order signal. L=9 indicates that the TUG3 structure is not predefined; instead it is determined by the incoming signal and autonomously adapts to the TU structure of the incoming signal. This signal is referred to as a TUG-3. 3. M indicates a specific branch of a TUG-2/VT Group. It is not significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE and must be 0 in this case. M=1 indicates that the TUG-2/VT Group is not further sub-divided and contains a TU-2/VT-6. M=2->3 indicates a specific VT-3 inside the corresponding VT Group, these values MUST NOT be used for SDH since there is no equivalent of VT-3 with SDH. M=4->6 indicates a specific TU-12/VT-2 inside the corresponding TUG-2/VT Group. M=7->10 indicates a specific TU-11/VT-1.5 inside the corresponding TUG-2/VT Group. M=11 indicates that the TUG2/VTG structure is not predefined; instead it is determined by the incoming signal and autonomously adapts to the TU/VT structure of the incoming signal. This signal is referred to as a TUG-2/VTG. 4.2.3 TU/VT specific channel portion in sSTM-1k and sSTM-2n 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Z. Lin et. al. Page [13] Internet Draft G-Label and G-Label Request Specification March 2001 For SDH sSTM-2n, this is an extension of the numbering scheme defined in G.708, i.e. the (L,M) numbering. 1. L=1->n indicates a specific TUG-2/VT Group inside the sSTM-2n (n=1,2,4). L=5 indicates that the TUG2 structure is not predefined; instead it is determined by the incoming signal and autonomously adapts to the TU structure of the incoming signal. This signal is referred to as a TUG-2. 2. M indicates a specific branch of a TUG-2/VT Group. M=1 indicates that the TUG-2/VT Group is not further sub-divided and contains a TU-2/VT-6. M=2->4 indicates a specific TU-12/VT-2 inside the corresponding TUG-2/VT Group. M=5->8 indicates a specific TU-11/VT-1.5 inside the corresponding TUG-2/VT Group. M=9 indicates that the TUG2/VTG structure is not predefined; instead it is determined by the incoming signal and autonomously adapts to the TU/VT structure of the incoming signal. This signal is referred to as a TUG-2/VTG. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For SDH sSTM-1k, this is an extension of the numbering scheme defined in G.708, i.e. the (M) numbering. 1. M=1->k indicates a specific TU-12 inside the sSTM-1k (k=1,2,4,8,16). 4.2.4 TU/VT specific channel portion in P31s and P4s 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | K | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the 139 264 kbit/s G.832 framed signal (P4s) option II, this is an extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the (K, L, M) numbering. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non- significant field. Z. Lin et. al. Page [14] Internet Draft G-Label and G-Label Request Specification March 2001 When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. 1. K indicates a specific branch of a P4s. K=1->3 indicates a specific TUG- 3 (A, B, C) inside the P4s. 2. L indicates a specific branch of a TUG-3. L=1 indicates that the TUG-3 is not further sub-divided and contains a TU-3. L=2->8 (for K=3, L is limited to 2->6) indicates a specific TUG-2. 3. M indicates a specific branch of a TUG-2. It is not significant for an unstructured TUG-3 and must be 0 in this case. M=1 indicates that the TUG-2 is not further sub-divided and contains a TU-2. M=2->4 indicates a specific TU-12 inside the corresponding TUG-2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the 139 264 kbit/s G.832 framed signal (P4s) option I, this is an extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the (L, M) numbering. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non- significant field. When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. 1. L indicates a specific branch of a P4s. L=1->20 indicates a specific TUG-2. 2. M indicates a specific branch of a TUG-2. M=1 indicates that the TUG-2 is not further sub-divided and contains a TU-2. M=2->4 indicates a specific TU-12 inside the corresponding TUG-2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the 34 368 kbit/s G.832 framed signal (P4s) option I, this is an extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the (L, M) numbering. For sSTM-1k, this is an extension of the numbering scheme Z. Lin et. al. Page [15] Internet Draft G-Label and G-Label Request Specification March 2001 defined in G.708, i.e. the (M) numbering. 1. M=1->k indicates a specific TU-12 inside the sSTM-1k (k=1,2,4,8,16). 4.3 OTN Label TBD 5. Security Considerations This document raises no new security concerns. 6. References [GMPLS-REORG] Y. Xu, et. al., "GMPLS Signaling Functional Spec. Modification and Reorganization", Work in Progress, March 2001. [GMPLS-SIG] P. Ashwood-Smith, et. al., "Generalized MPLS - Signaling Functional Description", Work in Progress, Nov. 2000. [GMPLS-ARCH] Y. Xu, et. al., "GMPLS Control Plane Architecture for ASTN", Work in Progress, Nov. 2000. [GMPLS-SIGEN] B. Mack-Crane, et. al., "Enhancements to GMPLS Signaling for Optical Technologies", Work in Progress, Nov. 2000. 7. Author Information Yangguang Xu 21-2A41, 1600 Osgood Street North Andover, MA 01845 Email: xuyg@lucent.com Zhi-Wei Lin 101 Crawfords Corner Rd Holmdel, NJ 07733-3030 Email: zwlin@lucent.com Siva Sankaranarayanan 101 Crawfords Corner Rd Holmdel, NJ 07733-3030 Email: siva@hotair.hobl.lucent.com Maarten Vissers Botterstraat 45 Postbus 18 1270 AA Huizen, Netherlands Email: mvissers@lucent.com Z. Lin et. al. Page [16] Annex A: Conversion formula for EDCBA <-> SU For the EDCBA to SU conversion, the following formula can be used: S = max[ (E-1)*64, 0 ] + max[ (D-1)*16, 0 ] + max[ (C-1)*4, 0 ] + max[ B-1, 0 ] + 1 B U = ceiling[ --- , 0 ] + A B+1 For the SU to EDCBA conversion, the following formula can be used: S E = max[ ceiling[ --- ], 0 ] 64 or 0 {for AU-4-256c & STM-64 or lower} S D = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1 16 or 0 {for AU-4-64c or above & STM-16 or lower} S C = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1 4 or 0 {for AU-4-16c or above & STM-4 or lower} B = [ ( S-1 ) modulo 4 ] + 1 or 0 {for AU-4-4c or above & STM-1 or lower} A = U - 1 or 0 (for AU-4 or above) Annex B: Sample conversion table The following table provides the explicit mapping between the SU and the EDCBA numbering scheme: Conversion table (E,D,C,B,A) (ITU-T G.707) to SU: G.707 EDCBA S U Signal Type ========================================= 00000 1 0 AU-4-256c/STS-768c in STM-256/OC-768 10000 1 0 AU-4-64c/STS-192c in STM-256/OC-768 20000 65 0 AU-4-64c/STS-192c in STM-256/OC-768 30000 129 0 AU-4-64c/STS-192c in STM-256/OC-768 40000 193 0 AU-4-64c/STS-192c in STM-256/OC-768 11000 1 0 AU-4-16c/STS-48c in STM-256/OC-768 12000 17 0 AU-4-16c/STS-48c in STM-256/OC-768 13000 33 0 AU-4-16c/STS-48c in STM-256/OC-768 14000 49 0 AU-4-16c/STS-48c in STM-256/OC-768 21000 65 0 AU-4-16c/STS-48c in STM-256/OC-768 22000 81 0 AU-4-16c/STS-48c in STM-256/OC-768 23000 97 0 AU-4-16c/STS-48c in STM-256/OC-768 24000 113 0 AU-4-16c/STS-48c in STM-256/OC-768 31000 129 0 AU-4-16c/STS-48c in STM-256/OC-768 32000 145 0 AU-4-16c/STS-48c in STM-256/OC-768 33000 161 0 AU-4-16c/STS-48c in STM-256/OC-768 34000 177 0 AU-4-16c/STS-48c in STM-256/OC-768 41000 193 0 AU-4-16c/STS-48c in STM-256/OC-768 42000 209 0 AU-4-16c/STS-48c in STM-256/OC-768 43000 225 0 AU-4-16c/STS-48c in STM-256/OC-768 44000 241 0 AU-4-16c/STS-48c in STM-256/OC-768 11100 1 0 AU-4-4c/STS-12c in STM-256/OC-768 11200 5 0 AU-4-4c/STS-12c in STM-256/OC-768 11300 9 0 AU-4-4c/STS-12c in STM-256/OC-768 11400 13 0 AU-4-4c/STS-12c in STM-256/OC-768 12100 17 0 AU-4-4c/STS-12c in STM-256/OC-768 12200 21 0 AU-4-4c/STS-12c in STM-256/OC-768 12300 25 0 AU-4-4c/STS-12c in STM-256/OC-768 12400 29 0 AU-4-4c/STS-12c in STM-256/OC-768 13100 33 0 AU-4-4c/STS-12c in STM-256/OC-768 13200 37 0 AU-4-4c/STS-12c in STM-256/OC-768 13300 41 0 AU-4-4c/STS-12c in STM-256/OC-768 13400 45 0 AU-4-4c/STS-12c in STM-256/OC-768 14100 49 0 AU-4-4c/STS-12c in STM-256/OC-768 14200 53 0 AU-4-4c/STS-12c in STM-256/OC-768 14300 57 0 AU-4-4c/STS-12c in STM-256/OC-768 14400 61 0 AU-4-4c/STS-12c in STM-256/OC-768 21100 65 0 AU-4-4c/STS-12c in STM-256/OC-768 21200 69 0 AU-4-4c/STS-12c in STM-256/OC-768 21300 73 0 AU-4-4c/STS-12c in STM-256/OC-768 21400 77 0 AU-4-4c/STS-12c in STM-256/OC-768 22100 81 0 AU-4-4c/STS-12c in STM-256/OC-768 22200 69 0 AU-4-4c/STS-12c in STM-256/OC-768 22300 73 0 AU-4-4c/STS-12c in STM-256/OC-768 22400 77 0 AU-4-4c/STS-12c in STM-256/OC-768 23100 97 0 AU-4-4c/STS-12c in STM-256/OC-768 23200 69 0 AU-4-4c/STS-12c in STM-256/OC-768 23300 73 0 AU-4-4c/STS-12c in STM-256/OC-768 23400 77 0 AU-4-4c/STS-12c in STM-256/OC-768 24100 113 0 AU-4-4c/STS-12c in STM-256/OC-768 24200 117 0 AU-4-4c/STS-12c in STM-256/OC-768 24300 121 0 AU-4-4c/STS-12c in STM-256/OC-768 24400 125 0 AU-4-4c/STS-12c in STM-256/OC-768 31100 129 0 AU-4-4c/STS-12c in STM-256/OC-768 31200 133 0 AU-4-4c/STS-12c in STM-256/OC-768 31300 137 0 AU-4-4c/STS-12c in STM-256/OC-768 31400 141 0 AU-4-4c/STS-12c in STM-256/OC-768 32100 145 0 AU-4-4c/STS-12c in STM-256/OC-768 32200 149 0 AU-4-4c/STS-12c in STM-256/OC-768 32300 153 0 AU-4-4c/STS-12c in STM-256/OC-768 32400 157 0 AU-4-4c/STS-12c in STM-256/OC-768 33100 161 0 AU-4-4c/STS-12c in STM-256/OC-768 33200 165 0 AU-4-4c/STS-12c in STM-256/OC-768 33300 169 0 AU-4-4c/STS-12c in STM-256/OC-768 33400 173 0 AU-4-4c/STS-12c in STM-256/OC-768 34100 177 0 AU-4-4c/STS-12c in STM-256/OC-768 34200 181 0 AU-4-4c/STS-12c in STM-256/OC-768 34300 185 0 AU-4-4c/STS-12c in STM-256/OC-768 34400 189 0 AU-4-4c/STS-12c in STM-256/OC-768 41100 193 0 AU-4-4c/STS-12c in STM-256/OC-768 41200 197 0 AU-4-4c/STS-12c in STM-256/OC-768 41300 201 0 AU-4-4c/STS-12c in STM-256/OC-768 41400 205 0 AU-4-4c/STS-12c in STM-256/OC-768 42100 209 0 AU-4-4c/STS-12c in STM-256/OC-768 42200 213 0 AU-4-4c/STS-12c in STM-256/OC-768 42300 217 0 AU-4-4c/STS-12c in STM-256/OC-768 42400 221 0 AU-4-4c/STS-12c in STM-256/OC-768 43100 225 0 AU-4-4c/STS-12c in STM-256/OC-768 43200 229 0 AU-4-4c/STS-12c in STM-256/OC-768 43300 233 0 AU-4-4c/STS-12c in STM-256/OC-768 43400 237 0 AU-4-4c/STS-12c in STM-256/OC-768 44100 241 0 AU-4-4c/STS-12c in STM-256/OC-768 44200 245 0 AU-4-4c/STS-12c in STM-256/OC-768 44300 249 0 AU-4-4c/STS-12c in STM-256/OC-768 44400 253 0 AU-4-4c/STS-12c in STM-256/OC-768 11110 1 1 AU-4/STS-3c in STM-256/OC-768 11120 2 1 AU-4/STS-3c in STM-256/OC-768 11130 3 1 AU-4/STS-3c in STM-256/OC-768 11140 4 1 AU-4/STS-3c in STM-256/OC-768 11210 5 1 AU-4/STS-3c in STM-256/OC-768 11220 6 1 AU-4/STS-3c in STM-256/OC-768 11220 7 1 AU-4/STS-3c in STM-256/OC-768 11220 8 1 AU-4/STS-3c in STM-256/OC-768 11310 9 1 AU-4/STS-3c in STM-256/OC-768 : 11410 13 1 AU-4/STS-3c in STM-256/OC-768 : 12110 17 1 AU-4/STS-3c in STM-256/OC-768 : 12210 21 1 AU-4/STS-3c in STM-256/OC-768 : 12310 25 1 AU-4/STS-3c in STM-256/OC-768 : 12410 29 1 AU-4/STS-3c in STM-256/OC-768 : 13110 33 1 AU-4/STS-3c in STM-256/OC-768 : 13210 37 1 AU-4/STS-3c in STM-256/OC-768 : 13310 41 1 AU-4/STS-3c in STM-256/OC-768 : 13410 45 1 AU-4/STS-3c in STM-256/OC-768 : 14110 49 1 AU-4/STS-3c in STM-256/OC-768 : 14210 53 1 AU-4/STS-3c in STM-256/OC-768 : 14310 57 1 AU-4/STS-3c in STM-256/OC-768 : 14410 61 1 AU-4/STS-3c in STM-256/OC-768 : 21110 65 1 AU-4/STS-3c in STM-256/OC-768 : 21210 69 1 AU-4/STS-3c in STM-256/OC-768 : 21310 73 1 AU-4/STS-3c in STM-256/OC-768 : 21410 77 1 AU-4/STS-3c in STM-256/OC-768 : 22110 81 1 AU-4/STS-3c in STM-256/OC-768 : 22210 85 1 AU-4/STS-3c in STM-256/OC-768 : 22310 89 1 AU-4/STS-3c in STM-256/OC-768 : 22410 93 1 AU-4/STS-3c in STM-256/OC-768 : 23110 97 1 AU-4/STS-3c in STM-256/OC-768 : 23210 101 1 AU-4/STS-3c in STM-256/OC-768 : 23310 105 1 AU-4/STS-3c in STM-256/OC-768 : 23410 109 1 AU-4/STS-3c in STM-256/OC-768 : 24110 113 1 AU-4/STS-3c in STM-256/OC-768 : 24210 117 1 AU-4/STS-3c in STM-256/OC-768 : 24310 121 1 AU-4/STS-3c in STM-256/OC-768 : 24410 125 1 AU-4/STS-3c in STM-256/OC-768 : 31110 129 1 AU-4/STS-3c in STM-256/OC-768 : 31210 133 1 AU-4/STS-3c in STM-256/OC-768 : 31310 137 1 AU-4/STS-3c in STM-256/OC-768 : 31410 141 1 AU-4/STS-3c in STM-256/OC-768 : 32110 145 1 AU-4/STS-3c in STM-256/OC-768 : 32210 149 1 AU-4/STS-3c in STM-256/OC-768 : 32310 153 1 AU-4/STS-3c in STM-256/OC-768 : 32410 157 1 AU-4/STS-3c in STM-256/OC-768 : 33110 161 1 AU-4/STS-3c in STM-256/OC-768 : 33210 165 1 AU-4/STS-3c in STM-256/OC-768 : 33310 169 1 AU-4/STS-3c in STM-256/OC-768 : 33410 173 1 AU-4/STS-3c in STM-256/OC-768 : 34110 177 1 AU-4/STS-3c in STM-256/OC-768 : 34210 181 1 AU-4/STS-3c in STM-256/OC-768 : 34310 185 1 AU-4/STS-3c in STM-256/OC-768 : 34410 189 1 AU-4/STS-3c in STM-256/OC-768 : 41110 193 1 AU-4/STS-3c in STM-256/OC-768 : 41210 197 1 AU-4/STS-3c in STM-256/OC-768 : 41310 201 1 AU-4/STS-3c in STM-256/OC-768 : 41410 205 1 AU-4/STS-3c in STM-256/OC-768 : 42110 209 1 AU-4/STS-3c in STM-256/OC-768 : 42210 213 1 AU-4/STS-3c in STM-256/OC-768 : 42310 217 1 AU-4/STS-3c in STM-256/OC-768 : 42410 221 1 AU-4/STS-3c in STM-256/OC-768 : 43110 225 1 AU-4/STS-3c in STM-256/OC-768 : 43210 229 1 AU-4/STS-3c in STM-256/OC-768 : 43310 233 1 AU-4/STS-3c in STM-256/OC-768 : 43410 237 1 AU-4/STS-3c in STM-256/OC-768 : 44110 241 1 AU-4/STS-3c in STM-256/OC-768 : 44210 245 1 AU-4/STS-3c in STM-256/OC-768 : 44310 249 1 AU-4/STS-3c in STM-256/OC-768 : 44410 253 1 AU-4/STS-3c in STM-256/OC-768 44420 254 1 AU-4/STS-3c in STM-256/OC-768 44430 255 1 AU-4/STS-3c in STM-256/OC-768 44440 256 1 AU-4/STS-3c in STM-256/OC-768 11111 1 2 AU-3/STS-1 in STM-256/OC-768 11112 1 3 AU-3/STS-1 in STM-256/OC-768 11113 1 4 AU-3/STS-1 in STM-256/OC-768 11121 2 2 AU-3/STS-1 in STM-256/OC-768 11122 2 3 AU-3/STS-1 in STM-256/OC-768 11123 2 4 AU-3/STS-1 in STM-256/OC-768 : 11131 3 2 AU-3/STS-1 in STM-256/OC-768 : 11141 4 2 AU-3/STS-1 in STM-256/OC-768 : 11211 5 2 AU-3/STS-1 in STM-256/OC-768 : 11311 9 2 AU-3/STS-1 in STM-256/OC-768 : 11411 13 2 AU-3/STS-1 in STM-256/OC-768 : 12111 17 2 AU-3/STS-1 in STM-256/OC-768 : 12211 21 2 AU-3/STS-1 in STM-256/OC-768 : 12311 25 2 AU-3/STS-1 in STM-256/OC-768 : 12411 29 2 AU-3/STS-1 in STM-256/OC-768 : 13111 33 2 AU-3/STS-1 in STM-256/OC-768 : 13211 37 2 AU-3/STS-1 in STM-256/OC-768 : 13311 41 2 AU-3/STS-1 in STM-256/OC-768 : 13411 45 2 AU-3/STS-1 in STM-256/OC-768 : 14111 49 2 AU-3/STS-1 in STM-256/OC-768 : 14211 53 2 AU-3/STS-1 in STM-256/OC-768 : 14311 57 2 AU-3/STS-1 in STM-256/OC-768 : 14411 61 2 AU-3/STS-1 in STM-256/OC-768 : 21111 65 2 AU-3/STS-1 in STM-256/OC-768 : 21211 69 2 AU-3/STS-1 in STM-256/OC-768 : 21311 73 2 AU-3/STS-1 in STM-256/OC-768 : 21411 77 2 AU-3/STS-1 in STM-256/OC-768 : 22111 81 2 AU-3/STS-1 in STM-256/OC-768 : 22211 85 2 AU-3/STS-1 in STM-256/OC-768 : 22311 89 2 AU-3/STS-1 in STM-256/OC-768 : 22411 93 2 AU-3/STS-1 in STM-256/OC-768 : 23111 97 2 AU-3/STS-1 in STM-256/OC-768 : 23211 101 2 AU-3/STS-1 in STM-256/OC-768 : 23311 105 2 AU-3/STS-1 in STM-256/OC-768 : 23411 109 2 AU-3/STS-1 in STM-256/OC-768 : 24111 113 2 AU-3/STS-1 in STM-256/OC-768 : 24211 117 2 AU-3/STS-1 in STM-256/OC-768 : 24311 121 2 AU-3/STS-1 in STM-256/OC-768 : 24411 125 2 AU-3/STS-1 in STM-256/OC-768 : 31111 129 2 AU-3/STS-1 in STM-256/OC-768 : 31211 133 2 AU-3/STS-1 in STM-256/OC-768 : 31311 137 2 AU-3/STS-1 in STM-256/OC-768 : 31411 141 2 AU-3/STS-1 in STM-256/OC-768 : 32111 145 2 AU-3/STS-1 in STM-256/OC-768 : 32211 149 2 AU-3/STS-1 in STM-256/OC-768 : 32311 153 2 AU-3/STS-1 in STM-256/OC-768 : 32411 157 2 AU-3/STS-1 in STM-256/OC-768 : 33111 161 2 AU-3/STS-1 in STM-256/OC-768 : 33211 165 2 AU-3/STS-1 in STM-256/OC-768 : 33311 169 2 AU-3/STS-1 in STM-256/OC-768 : 33411 173 2 AU-3/STS-1 in STM-256/OC-768 : 34111 177 2 AU-3/STS-1 in STM-256/OC-768 : 34211 181 2 AU-3/STS-1 in STM-256/OC-768 : 34311 185 2 AU-3/STS-1 in STM-256/OC-768 : 34411 189 2 AU-3/STS-1 in STM-256/OC-768 : 41111 193 2 AU-3/STS-1 in STM-256/OC-768 : 41211 197 2 AU-3/STS-1 in STM-256/OC-768 : 41311 211 2 AU-3/STS-1 in STM-256/OC-768 : 41411 215 2 AU-3/STS-1 in STM-256/OC-768 : 42111 219 2 AU-3/STS-1 in STM-256/OC-768 : 42211 213 2 AU-3/STS-1 in STM-256/OC-768 : 42311 217 2 AU-3/STS-1 in STM-256/OC-768 : 42411 221 2 AU-3/STS-1 in STM-256/OC-768 : 43111 225 2 AU-3/STS-1 in STM-256/OC-768 : 43211 229 2 AU-3/STS-1 in STM-256/OC-768 : 43311 233 2 AU-3/STS-1 in STM-256/OC-768 : 43411 237 2 AU-3/STS-1 in STM-256/OC-768 : 44111 241 2 AU-3/STS-1 in STM-256/OC-768 : 44211 245 2 AU-3/STS-1 in STM-256/OC-768 : 44311 249 2 AU-3/STS-1 in STM-256/OC-768 : 44411 253 2 AU-3/STS-1 in STM-256/OC-768 : 44421 254 2 AU-3/STS-1 in STM-256/OC-768 : 44431 255 2 AU-3/STS-1 in STM-256/OC-768 : 44441 256 2 AU-3/STS-1 in STM-256/OC-768 44442 256 3 AU-3/STS-1 in STM-256/OC-768 44443 256 4 AU-3/STS-1 in STM-256/OC-768 G.707 DCBA S U Signal Type ========================================= 0000 1 0 AU-4-64c/STS-192c in STM-64/OC-192 1000 1 0 AU-4-16c/STS-48c in STM-64/OC-192 2000 17 0 AU-4-16c/STS-48c in STM-64/OC-192 3000 33 0 AU-4-16c/STS-48c in STM-64/OC-192 4000 49 0 AU-4-16c/STS-48c in STM-64/OC-192 1100 1 0 AU-4-4c/STS-12c in STM-64/OC-192 1200 5 0 AU-4-4c/STS-12c in STM-64/OC-192 1300 9 0 AU-4-4c/STS-12c in STM-64/OC-192 1400 13 0 AU-4-4c/STS-12c in STM-64/OC-192 2100 17 0 AU-4-4c/STS-12c in STM-64/OC-192 2200 21 0 AU-4-4c/STS-12c in STM-64/OC-192 2300 25 0 AU-4-4c/STS-12c in STM-64/OC-192 2400 29 0 AU-4-4c/STS-12c in STM-64/OC-192 3100 33 0 AU-4-4c/STS-12c in STM-64/OC-192 3200 37 0 AU-4-4c/STS-12c in STM-64/OC-192 3300 41 0 AU-4-4c/STS-12c in STM-64/OC-192 3400 45 0 AU-4-4c/STS-12c in STM-64/OC-192 4100 49 0 AU-4-4c/STS-12c in STM-64/OC-192 4200 53 0 AU-4-4c/STS-12c in STM-64/OC-192 4300 57 0 AU-4-4c/STS-12c in STM-64/OC-192 4400 61 0 AU-4-4c/STS-12c in STM-64/OC-192 1110 1 1 AU-4/STS-3c in STM-64/OC-192 1120 2 1 AU-4/STS-3c in STM-64/OC-192 1130 3 1 AU-4/STS-3c in STM-64/OC-192 1140 4 1 AU-4/STS-3c in STM-64/OC-192 1210 5 1 AU-4/STS-3c in STM-64/OC-192 1220 6 1 AU-4/STS-3c in STM-64/OC-192 1220 7 1 AU-4/STS-3c in STM-64/OC-192 1220 8 1 AU-4/STS-3c in STM-64/OC-192 1310 9 1 AU-4/STS-3c in STM-64/OC-192 : 1410 13 1 AU-4/STS-3c in STM-64/OC-192 : 2110 17 1 AU-4/STS-3c in STM-64/OC-192 : 2210 21 1 AU-4/STS-3c in STM-64/OC-192 : 2310 25 1 AU-4/STS-3c in STM-64/OC-192 : 2410 29 1 AU-4/STS-3c in STM-64/OC-192 : 3110 33 1 AU-4/STS-3c in STM-64/OC-192 : 3210 37 1 AU-4/STS-3c in STM-64/OC-192 : 3310 41 1 AU-4/STS-3c in STM-64/OC-192 : 3410 45 1 AU-4/STS-3c in STM-64/OC-192 : 4110 49 1 AU-4/STS-3c in STM-64/OC-192 : 4210 53 1 AU-4/STS-3c in STM-64/OC-192 : 4310 57 1 AU-4/STS-3c in STM-64/OC-192 : 4410 61 1 AU-4/STS-3c in STM-64/OC-192 4420 62 1 AU-4/STS-3c in STM-64/OC-192 4430 63 1 AU-4/STS-3c in STM-64/OC-192 4440 64 1 AU-4/STS-3c in STM-64/OC-192 1111 1 2 AU-3/STS-1 in STM-64/OC-192 1112 1 3 AU-3/STS-1 in STM-64/OC-192 1113 1 4 AU-3/STS-1 in STM-64/OC-192 1121 2 2 AU-3/STS-1 in STM-64/OC-192 1122 2 3 AU-3/STS-1 in STM-64/OC-192 1123 2 4 AU-3/STS-1 in STM-64/OC-192 : 1131 3 2 AU-3/STS-1 in STM-64/OC-192 : 1141 4 2 AU-3/STS-1 in STM-64/OC-192 : 1211 5 2 AU-3/STS-1 in STM-64/OC-192 : 1311 9 2 AU-3/STS-1 in STM-64/OC-192 : 1411 13 2 AU-3/STS-1 in STM-64/OC-192 : 2111 17 2 AU-3/STS-1 in STM-64/OC-192 : 2211 21 2 AU-3/STS-1 in STM-64/OC-192 : 2311 25 2 AU-3/STS-1 in STM-64/OC-192 : 2411 29 2 AU-3/STS-1 in STM-64/OC-192 : 3111 33 2 AU-3/STS-1 in STM-64/OC-192 : 3211 37 2 AU-3/STS-1 in STM-64/OC-192 : 3311 41 2 AU-3/STS-1 in STM-64/OC-192 : 3411 45 2 AU-3/STS-1 in STM-64/OC-192 : 4111 49 2 AU-3/STS-1 in STM-64/OC-192 : 4211 53 2 AU-3/STS-1 in STM-64/OC-192 : 4311 57 2 AU-3/STS-1 in STM-64/OC-192 : 4411 61 2 AU-3/STS-1 in STM-64/OC-192 : 4441 63 2 AU-3/STS-1 in STM-64/OC-192 4442 64 3 AU-3/STS-1 in STM-64/OC-192 4443 65 4 AU-3/STS-1 in STM-64/OC-192 G.707 CBA S U Signal Type ========================================= 000 1 0 AU-4-16c/STS-48c in STM-16/OC-48 100 1 0 AU-4-4c/STS-12c in STM-16/OC-48 200 5 0 AU-4-4c/STS-12c in STM-16/OC-48 300 9 0 AU-4-4c/STS-12c in STM-16/OC-48 400 13 0 AU-4-4c/STS-12c in STM-16/OC-48 110 1 1 AU-4/STS-3c in STM-16/OC-48 120 2 1 AU-4/STS-3c in STM-16/OC-48 130 3 1 AU-4/STS-3c in STM-16/OC-48 140 4 1 AU-4/STS-3c in STM-16/OC-48 210 5 1 AU-4/STS-3c in STM-16/OC-48 220 6 1 AU-4/STS-3c in STM-16/OC-48 220 7 1 AU-4/STS-3c in STM-16/OC-48 220 8 1 AU-4/STS-3c in STM-16/OC-48 310 9 1 AU-4/STS-3c in STM-16/OC-48 320 10 1 AU-4/STS-3c in STM-16/OC-48 330 11 1 AU-4/STS-3c in STM-16/OC-48 340 12 1 AU-4/STS-3c in STM-16/OC-48 410 13 1 AU-4/STS-3c in STM-16/OC-48 420 14 1 AU-4/STS-3c in STM-16/OC-48 430 15 1 AU-4/STS-3c in STM-16/OC-48 440 16 1 AU-4/STS-3c in STM-16/OC-48 111 1 2 AU-3/STS-1 in STM-16/OC-48 112 1 3 AU-3/STS-1 in STM-16/OC-48 113 1 4 AU-3/STS-1 in STM-16/OC-48 121 2 2 AU-3/STS-1 in STM-16/OC-48 122 2 3 AU-3/STS-1 in STM-16/OC-48 123 2 4 AU-3/STS-1 in STM-16/OC-48 131 3 2 AU-3/STS-1 in STM-16/OC-48 132 3 3 AU-3/STS-1 in STM-16/OC-48 133 3 4 AU-3/STS-1 in STM-16/OC-48 141 4 2 AU-3/STS-1 in STM-16/OC-48 : 211 5 2 AU-3/STS-1 in STM-16/OC-48 : 311 9 2 AU-3/STS-1 in STM-16/OC-48 : 411 13 2 AU-3/STS-1 in STM-16/OC-48 : 441 16 2 AU-3/STS-1 in STM-16/OC-48 442 16 3 AU-3/STS-1 in STM-16/OC-48 443 16 4 AU-3/STS-1 in STM-16/OC-48 G.707 BA S U Signal Type ========================================= 00 1 0 AU-4-4c/STS-12c in STM-4/OC-12 10 1 1 AU-4/STS-3c in STM-4/OC-12 20 2 1 AU-4/STS-3c in STM-4/OC-12 30 3 1 AU-4/STS-3c in STM-4/OC-12 40 4 1 AU-4/STS-3c in STM-4/OC-12 11 1 2 AU-3/STS-1 in STM-4/OC-12 12 1 3 AU-3/STS-1 in STM-4/OC-12 13 1 4 AU-3/STS-1 in STM-4/OC-12 21 2 2 AU-3/STS-1 in STM-4/OC-12 22 2 3 AU-3/STS-1 in STM-4/OC-12 23 2 4 AU-3/STS-1 in STM-4/OC-12 31 3 2 AU-3/STS-1 in STM-4/OC-12 32 3 3 AU-3/STS-1 in STM-4/OC-12 33 3 4 AU-3/STS-1 in STM-4/OC-12 41 4 2 AU-3/STS-1 in STM-4/OC-12 42 4 3 AU-3/STS-1 in STM-4/OC-12 43 4 4 AU-3/STS-1 in STM-4/OC-12 G.707 A S U Signal Type ========================================= 0 1 1 AU-4/STS-3c in STM-1/OC-3 1 1 2 AU-3/STS-1 in STM-1/OC-3 2 1 3 AU-3/STS-1 in STM-1/OC-3 3 1 4 AU-3/STS-1 in STM-1/OC-3 --------------EFA0801E37B34DECCDA65E0F-- From owner-mpls@UU.NET Mon Mar 19 19:38:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27558 for ; Mon, 19 Mar 2001 19:38:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcc03605; Tue, 20 Mar 2001 00:36:23 GMT Received: by mail-control.mail.uu.net id QQkhca16062 for mpls-outgoing; Tue, 20 Mar 2001 00:03:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhby02538 for ; Mon, 19 Mar 2001 23:35:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhby23761 for ; Mon, 19 Mar 2001 23:35:49 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhby16139 for ; Mon, 19 Mar 2001 23:35:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA09196 for mpls@uu.net; Mon, 19 Mar 2001 18:35:48 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhbu11359 for ; Mon, 19 Mar 2001 22:40:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgox17303 for ; Fri, 16 Mar 2001 10:46:34 GMT Received: from albatross-ext.wise.edt.ericsson.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116]) id QQkgox17981 for ; Fri, 16 Mar 2001 10:46:34 GMT Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2GAkWC03494 for ; Fri, 16 Mar 2001 11:46:33 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri Mar 16 11:46:32 2001 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 11:46:31 +0100 Message-ID: From: "Berner Vegge (ETO)" To: "'mpls@uu.net'" Date: Fri, 16 Mar 2001 11:38:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello! When looking at the RFCs for MPLS I find quite a lot of information. I also see that there are very many Internet-drafts on MPLS. From all this documentation I find it hard to get the picture on current status for MPLS standardization, and I wonder if someone could help me to explain the current status, like for example: - What are the main remaining topics to standardize within MPLS? - What are the main topics being standardized at the moment? - Any comments to why people say that MPLS is not yet mature? I also wonder what the relation to MPLS forum is. When we have this IETF working group - why do we need MPLS forum? Thanks to anyone who can help me! Best Regards Berner Vegge From owner-mpls@UU.NET Mon Mar 19 19:41:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27672 for ; Mon, 19 Mar 2001 19:41:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcc08994; Tue, 20 Mar 2001 00:40:05 GMT Received: by mail-control.mail.uu.net id QQkhca21442 for mpls-outgoing; Tue, 20 Mar 2001 00:11:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhby02420 for ; Mon, 19 Mar 2001 23:32:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhby25461 for ; Mon, 19 Mar 2001 23:32:09 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhby11015 for ; Mon, 19 Mar 2001 23:32:08 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA08965 for mpls@uu.net; Mon, 19 Mar 2001 18:32:08 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhbu12114 for ; Mon, 19 Mar 2001 22:40:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgly06372 for ; Thu, 15 Mar 2001 15:31:17 GMT Received: from alemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQkgly03131 for ; Thu, 15 Mar 2001 15:31:16 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25851 for ; Thu, 15 Mar 2001 10:31:16 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25797 for ; Thu, 15 Mar 2001 10:31:15 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA08153; Thu, 15 Mar 2001 16:31:14 +0100 (MET) Cc: ccamp@ops.ietf.org, mpls@UU.NET Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA08138; Thu, 15 Mar 2001 16:31:10 +0100 (MET) Message-ID: <3AB0E03D.F76EC79@lucent.com> Date: Thu, 15 Mar 2001 16:31:09 +0100 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Fong Liaw Original-CC: ccamp@ops.ietf.org, mpls@uu.net Subject: Re: Question regarding bi-directional connection set up - And Port-ID in Label object References: <4611AD058694D4118FD5009027B0A6622B8C30@ICARIAN> Content-Type: multipart/mixed; boundary="------------A0B67469376A3D9CECED8179" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------A0B67469376A3D9CECED8179 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fong, > "An example of bundling is inverse > multiplexing, it is useful when a higher order signal needs to be > transported over a number of lower order signals, e.g. when a 10Gbps > signal must be transported over four 2.5Gbps signals. In that case, > the lower order signals must follow exactly the same path, and be > treated in the same way, in order to achieve the same characteristics > (e.g. delay). To support inverse multiplexing, a request is made to > open in parallel and in one single operation several LSPs at the same > time." The above text is not aligned with today's transport layer capabilities in SDH/SONET. VC-n/STS/VT virtual concatenated signals must NOT follow exactly the same path, they may do so. The recent defined VC-n-Xv LCAS (link capacity adjustment scheme) assumes that the group of X VC-n signals is routed over at least two diverse routes. The need to co-route all members of the group depends mainly on the differential delay that the virtual concatenation egress point can accomodate. If it is very low, you better co-route all signals. Otherwise, co-routing is not necessary as long as the differential delay is less than the maximum differential delay that the endpoint can compensate. Regards, Maarten --------------A0B67469376A3D9CECED8179 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------A0B67469376A3D9CECED8179-- From owner-mpls@UU.NET Mon Mar 19 21:02:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29806 for ; Mon, 19 Mar 2001 21:02:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhci16682; Tue, 20 Mar 2001 02:01:13 GMT Received: by mail-control.mail.uu.net id QQkhcb22662 for mpls-outgoing; Tue, 20 Mar 2001 00:22:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhca12918 for ; Tue, 20 Mar 2001 00:01:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhca12823 for ; Tue, 20 Mar 2001 00:01:19 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhca18674 for ; Tue, 20 Mar 2001 00:01:18 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA13697 for mpls@uu.net; Mon, 19 Mar 2001 19:01:18 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhbw01228 for ; Mon, 19 Mar 2001 23:12:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhbw16917 for ; Mon, 19 Mar 2001 23:12:07 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhbw15020 for ; Mon, 19 Mar 2001 23:12:06 GMT Received: from FRED-W2K.ietf.org (sjc-vpn-365.cisco.com [10.21.65.109]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA27786; Mon, 19 Mar 2001 15:12:25 -0800 (PST) Message-Id: <5.0.2.1.2.20010319165835.045c81f8@mira-sjcm-2.cisco.com> X-Sender: fred@flipper.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 19 Mar 2001 17:11:58 -0600 To: mpls@UU.NET From: Fred Baker Subject: Establishment of Temporary Sub-IP Area Cc: scott_Bradner , bert Wijnen , harald Alvestrand Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkhci16682 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA29806 The IESG has decided to incorporate the sub-IP working groups, which are currently chartered in the General Area, into a temporary area. The area directors will be Scott Bradner and Bert Wijnen. With that change, and perhaps some jiggling of IESG Technical Advisers, the current working group charters remain unchanged and represent your work plan. Long term, the IESG expects to review the process of the development of this technology and determine whether the IETF needs to further formalize this area or not. The IESG currently believes that this will not be necessary; once a strong architecture is in place here, remaining work can be re-absorbed into other areas such as Operations or Routing. However, we know all too well that we have been incorrect in the past, and may be incorrect here. Part of that discussion will have to be the meta-question of exactly what the boundaries of the IETF's role are. Clearly, the Internet Engineering Task Force is interested in the Engineering of the Internet, which we define as including any network, private or public, metropolitan, local, or global, which content embedded in an IP packet crosses between two domains. It includes a discussion of any link or intra-network technology IP uses, as in the past it has included discussions of Ethernet and extended Ethernets, occasional and continuous serial links, X.25 networks, Frame Relay, and ATM. But it does not necessarily include all aspects of those technologies, or all of their users. Clearly, we need to be prepared to step in when nobody else is doing a bit of work that the Internet depends on. Equally clearly, we do not presume expertise in every area, and are willing to capitalize on work done by other bodies such as ITU-T and IEEE. This dividing line is fuzzy and needs clarification. The arguments that bring us to accept sub-IP work in the IETF are principally that · The work depends on IP expertise which is here, · That it is critical to the development of the IP infrastructure, and · That it directly or indirectly affects operations or routing at the IP layer. For example, optical networking is clearly a next generation requirement for service providers and for fiber consortia. However, the obvious next hop router in a general network may differ from the obvious next hop router in an optical network. Therefore, the use of optical networking may change the results that we need to get from routing protocols. It would be better for us to determine how the routing protocols should model those networks than for another body to arbitrarily change them or substitute others. I trust that you will find your new area directors supportive and helpful in accomplishing your goals, and expect that you will work with them to accomplish theirs. From owner-mpls@UU.NET Mon Mar 19 22:25:22 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02929 for ; Mon, 19 Mar 2001 22:25:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcn03712; Tue, 20 Mar 2001 03:20:55 GMT Received: by mail-control.mail.uu.net id QQkhcm06979 for mpls-outgoing; Tue, 20 Mar 2001 03:00:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhcl05033 for ; Tue, 20 Mar 2001 02:53:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhcl25546 for ; Tue, 20 Mar 2001 02:52:33 GMT Received: from smtp.263.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.44.20]) id QQkhcl17066 for ; Tue, 20 Mar 2001 02:52:29 GMT Received: from zhou (unknown [211.69.206.240]) by smtp.263.net (Postfix) with ESMTP id 57E40205A2 for ; Tue, 20 Mar 2001 10:55:00 +0800 (CST) Date: Tue, 20 Mar 2001 10:53:10 +0800 From: zhou To: "mpls@uu.net" Subject: layer 3 switch isn't support WAN? X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: <20010320025500.57E40205A2@smtp.263.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi, I have read a comparison between layer 3 switch Vs traditonal router as follow: Characteristic Layer 3 Switch Legacy Router -------------------------------------------------------------- Routes core LAN protocols: IP, IPX, AppleTalk Yes Yes --------------------------------------------------------------- Subnet definition Layer 2 switch domain Port --------------------------------------------------------------- Forwarding architecture Hardware Software --------------------------------------------------------------- Forwarding performance High Low --------------------------------------------------------------- Policy performance High Low --------------------------------------------------------------- WAN support No Yes I am not clear about why layer 3 switch is not support WAN, could you give more explanation ? From owner-mpls@UU.NET Mon Mar 19 22:30:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03104 for ; Mon, 19 Mar 2001 22:30:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcn12996; Tue, 20 Mar 2001 03:29:30 GMT Received: by mail-control.mail.uu.net id QQkhcm07131 for mpls-outgoing; Tue, 20 Mar 2001 03:00:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhck04226 for ; Tue, 20 Mar 2001 02:38:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck08140 for ; Tue, 20 Mar 2001 02:37:55 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhck23069 for ; Tue, 20 Mar 2001 02:37:54 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 SAA14733 for ; Mon, 19 Mar 2001 18:38:13 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27923 for mpls@uu.net; Mon, 19 Mar 2001 21:37:52 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhbu12232 for ; Mon, 19 Mar 2001 22:41:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgqu27277 for ; Fri, 16 Mar 2001 23:09:33 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f147.law10.hotmail.com [64.4.15.147]) id QQkgqu05474 for ; Fri, 16 Mar 2001 23:09:32 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Mar 2001 15:09:32 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 16 Mar 2001 23:09:32 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: manojkumarjuneja@hotmail.com Subject: Doubt about waveband Id Date: Fri, 16 Mar 2001 16:09:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2001 23:09:32.0308 (UTC) FILETIME=[28F3DD40:01C0AE6E] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, In draft "draft-ietf-mpls-generalized-signalling-02.txt", it is mentioned that wavebandId (32 bits) is selected by the sender and reused in all the subsequent messages. What all subsequent messages is it mentioning to ? Thanks, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Mar 19 22:32:36 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04076 for ; Mon, 19 Mar 2001 22:32:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhco16600; Tue, 20 Mar 2001 03:31:39 GMT Received: by mail-control.mail.uu.net id QQkhcm07391 for mpls-outgoing; Tue, 20 Mar 2001 03:00:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhck04214 for ; Tue, 20 Mar 2001 02:38:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck13217 for ; Tue, 20 Mar 2001 02:37:58 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhck23143 for ; Tue, 20 Mar 2001 02:37:58 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA10493 for ; Mon, 19 Mar 2001 18:38:01 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27929 for mpls@uu.net; Mon, 19 Mar 2001 21:37:56 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhbu11624 for ; Mon, 19 Mar 2001 22:40:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgqu26470 for ; Fri, 16 Mar 2001 23:05:27 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f35.law10.hotmail.com [64.4.15.35]) id QQkgqu29473 for ; Fri, 16 Mar 2001 23:05:26 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Mar 2001 15:05:26 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 16 Mar 2001 23:05:25 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: manojkumarjuneja@hotmail.com Subject: Please Clarify the GMPLS Doubts...... Date: Fri, 16 Mar 2001 16:05:25 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2001 23:05:26.0141 (UTC) FILETIME=[9639C2D0:01C0AE6D] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I have gone through the latest GMPLS drafts. But I could not make out clearly the message structure of even the Label Request Message. Can u pleae brief me the TLVs that will be present in generalized Label Request Message (both mandatory and optional) ? The following TLVs are passed on the O-UNI : - Label Set - Suggested Label - Generalized Label TLV - LightPath TLV - Source Id TLV - Destination Id TLV - Service TLV In an interworking scenario i.e. from O-UNI to GMPLS, whether LightPathId TLV, SourceId TLV, Destination Id TLV, Service TLV are passed on GMPLS or not ? I believe that these TLVs are just consumed at the UNI only. Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Mar 19 22:33:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04103 for ; Mon, 19 Mar 2001 22:33:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhco18289; Tue, 20 Mar 2001 03:32:43 GMT Received: by mail-control.mail.uu.net id QQkhcm07486 for mpls-outgoing; Tue, 20 Mar 2001 03:00:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhck04233 for ; Tue, 20 Mar 2001 02:39:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck13752 for ; Tue, 20 Mar 2001 02:38:08 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhck23317 for ; Tue, 20 Mar 2001 02:38:08 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 SAA10541 for ; Mon, 19 Mar 2001 18:38:11 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27953 for mpls@uu.net; Mon, 19 Mar 2001 21:38:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhbu11998 for ; Mon, 19 Mar 2001 22:40:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgqw14487 for ; Fri, 16 Mar 2001 23:30:38 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f120.law10.hotmail.com [64.4.15.120]) id QQkgqw27851 for ; Fri, 16 Mar 2001 23:30:37 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Mar 2001 15:30:36 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 16 Mar 2001 23:30:36 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: manojkumarjuneja@hotmail.com Subject: Doubts regarding LSP encoding type... Date: Fri, 16 Mar 2001 16:30:36 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2001 23:30:36.0918 (UTC) FILETIME=[1AB80960:01C0AE71] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, The draft "draft-ietf-mpls-generalized-signalling-02.txt" defines different values for LSP encoding type. How does the implementation of a control plane differ if it receives the LSP encoding type packet/SDH/Digital Wrapper/Lamda/Fiber etc. My understanding is that if the LSP encoding type is either packet/ethernet, then label is just a 32 bit integer (as we already have in traditional MPLS). But if LSP encoding type is SDH, SONET then the label has to be in the form of {S, U, K, L, M} format. If the LSP encoding type is Lamda then the label represents the lamda (specific frequency). If LSP encoding type is fiber, then label is the fiberId itself. Can u please describe a scenario in which the LSP encoding type will be used as a "digital wrapper" ? Please clarify. Regards, _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Mar 19 22:34:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04156 for ; Mon, 19 Mar 2001 22:34:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhco14753; Tue, 20 Mar 2001 03:30:32 GMT Received: by mail-control.mail.uu.net id QQkhcm07235 for mpls-outgoing; Tue, 20 Mar 2001 03:00:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhck04213 for ; Tue, 20 Mar 2001 02:38:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck13500 for ; Tue, 20 Mar 2001 02:38:04 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhck23221 for ; Tue, 20 Mar 2001 02:38:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA14791 for ; Mon, 19 Mar 2001 18:38:22 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27941 for mpls@uu.net; Mon, 19 Mar 2001 21:38:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhbu11905 for ; Mon, 19 Mar 2001 22:40:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkgqu15248 for ; Fri, 16 Mar 2001 23:11:25 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f203.law10.hotmail.com [64.4.15.203]) id QQkgqu13819 for ; Fri, 16 Mar 2001 23:11:25 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Mar 2001 15:11:24 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 16 Mar 2001 23:11:24 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" Subject: Doubt about waveband Label Date: Fri, 16 Mar 2001 16:11:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2001 23:11:24.0491 (UTC) FILETIME=[6BD1A1B0:01C0AE6E] To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk Hi All, In draft "draft-ietf-mpls-generalized-signalling-02.txt", it is mentioned that for waveband switching, the genralized label has the format (wavebandId - start label - end label). When the label request message is received on incoming interface, how to identify that the waveand label is requested ? Is it the LSP encoding type or some other parameter in label request message ? Please help. Thanks, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Mar 19 22:35:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04174 for ; Mon, 19 Mar 2001 22:35:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhco19991; Tue, 20 Mar 2001 03:33:47 GMT Received: by mail-control.mail.uu.net id QQkhcm07533 for mpls-outgoing; Tue, 20 Mar 2001 03:00:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhck04222 for ; Tue, 20 Mar 2001 02:38:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck01816 for ; Tue, 20 Mar 2001 02:38:06 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhck23286 for ; Tue, 20 Mar 2001 02:38:06 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 SAA10530 for ; Mon, 19 Mar 2001 18:38:09 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27947 for mpls@uu.net; Mon, 19 Mar 2001 21:38:04 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhbu11416 for ; Mon, 19 Mar 2001 22:40:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkgqu28432 for ; Fri, 16 Mar 2001 23:14:26 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f104.law10.hotmail.com [64.4.15.104]) id QQkgqu11901 for ; Fri, 16 Mar 2001 23:14:26 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Mar 2001 15:14:25 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 16 Mar 2001 23:14:25 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: manojkumarjuneja@hotmail.com Subject: Doubts in latest GMPLS drafts (GMPLS Functional Specs and GMPLS-CR-LDP) Date: Fri, 16 Mar 2001 16:14:25 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2001 23:14:25.0668 (UTC) FILETIME=[D7CF0C40:01C0AE6E] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, The draft "draft-ietf-mpls-generalized-signalling-02.txt" describes different values for signal types. The values 1-7 are derived from the STM hierarchy. But how the remaining values are interpretted (i.e. STM-1 MS, STM-1 RS etc) ? How is STM-4 different from STM-1 MS and STM-1 RS ? Is STM-1 MS or STM-1 RS a different signal type in SDH ? How does implementation of a control plane for GMPLS differ if it receives the signal type as STM-1/STM-1 MS/STM-1 RS ? The draft "draft-ietf-mpls-generalized-cr-ldp-01.txt" gives reference to only two messages of LDP viz. Label Request, Label Mapping. What about the other messages like label withdraw and label release. I believe that the generalized label TLV need to be included in these messages too instead of the label TLV. Please help me in understanding these drafts. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Mar 19 22:35:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04216 for ; Mon, 19 Mar 2001 22:35:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhco21712; Tue, 20 Mar 2001 03:34:50 GMT Received: by mail-control.mail.uu.net id QQkhcm07649 for mpls-outgoing; Tue, 20 Mar 2001 03:00:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhck04223 for ; Tue, 20 Mar 2001 02:38:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck01990 for ; Tue, 20 Mar 2001 02:38:11 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhck23372 for ; Tue, 20 Mar 2001 02:38: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 SAA14836 for ; Mon, 19 Mar 2001 18:38:29 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27959 for mpls@uu.net; Mon, 19 Mar 2001 21:38:08 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhbw00641 for ; Mon, 19 Mar 2001 23:09:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhbw07664 for ; Mon, 19 Mar 2001 23:09:03 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f71.law10.hotmail.com [64.4.15.71]) id QQkhbw11190 for ; Mon, 19 Mar 2001 23:09:03 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 Mar 2001 15:09:02 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 19 Mar 2001 23:09:02 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: mpls@UU.NET Subject: Clarification Required regarding LSP Encoding Type Date: Mon, 19 Mar 2001 16:09:02 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Mar 2001 23:09:02.0716 (UTC) FILETIME=[968DBBC0:01C0B0C9] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, The draft "draft-ietf-mpls-generalized-signalling-02.txt" defines different values for LSP encoding type. How does the implementation of a control plane differ if it receives the LSP encoding type packet/SDH/Digital Wrapper/Lamda/Fiber etc. My understanding is that if the LSP encoding type is either packet/ethernet, then label is just a 32 bit integer (as we already have in traditional MPLS). But if LSP encoding type is SDH, SONET then the label has to be in the form of {S, U, K, L, M} format. If the LSP encoding type is Lamda then the label represents the lamda (specific frequency). If LSP encoding type is fiber, then label is the fiberId itself. Please comment on whether my understanding is correct or I am overlooking something. Can u please describe a scenario in which the LSP encoding type will be used as a "digital wrapper" ? Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Mar 19 22:37:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04262 for ; Mon, 19 Mar 2001 22:37:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhco23432; Tue, 20 Mar 2001 03:35:56 GMT Received: by mail-control.mail.uu.net id QQkhcm07809 for mpls-outgoing; Tue, 20 Mar 2001 03:00:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhck04234 for ; Tue, 20 Mar 2001 02:39:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck14025 for ; Tue, 20 Mar 2001 02:38:14 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhck23433 for ; Tue, 20 Mar 2001 02:38:13 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 SAA14850 for ; Mon, 19 Mar 2001 18:38:32 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27965 for mpls@uu.net; Mon, 19 Mar 2001 21:38:11 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhby02508 for ; Mon, 19 Mar 2001 23:35:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhby18370 for ; Mon, 19 Mar 2001 23:34:04 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f169.law10.hotmail.com [64.4.15.169]) id QQkhby26061 for ; Mon, 19 Mar 2001 23:34:03 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 Mar 2001 15:34:03 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 19 Mar 2001 23:34:03 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: mpls@UU.NET Subject: Please Clarify Doubts regarding RGT & RNC Date: Mon, 19 Mar 2001 16:34:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Mar 2001 23:34:03.0153 (UTC) FILETIME=[14E24010:01C0B0CD] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, The GMPLS draft "draft-ietf-mpls-generalized-signalling-02.txt" defines different values for RGT (Requested Grouping Type) viz. Virtual Concatenation, Contiguous standard concatenation, Contiguous arbitrary concatenation, Bundle. How does the implementation of a control plane differ if it receives different RGT values ? Another field RNC (Reuested Number of Components) defines the number of such components requested. My understanding is that if RNC is 2 and signal type is STM-1. Then it means that 2 STM-1 signals are requested and these are concatenated according to the RGT specified. Does this mean, the number of labels requested depend on the RNC field ? This means that is RNC is "X", then "X" number of labels are to be returned in Label Mapping message and the labels returned should be in accrodance with the requested signal type. Please clarify these doubts. Can somebody please brief me on grouping type Bundle ? Is there any additional capability required in the network for supporting different types of grouping types (RGTs) ? Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Mar 19 22:37:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04275 for ; Mon, 19 Mar 2001 22:37:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhco25258; Tue, 20 Mar 2001 03:36:58 GMT Received: by mail-control.mail.uu.net id QQkhcm07984 for mpls-outgoing; Tue, 20 Mar 2001 03:00:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhck04224 for ; Tue, 20 Mar 2001 02:38:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck01623 for ; Tue, 20 Mar 2001 02:38:01 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhck23195 for ; Tue, 20 Mar 2001 02:38: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 SAA14772 for ; Mon, 19 Mar 2001 18:38:20 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27935 for mpls@uu.net; Mon, 19 Mar 2001 21:37:59 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhbu12430 for ; Mon, 19 Mar 2001 22:42:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkgmv06635 for ; Thu, 15 Mar 2001 21:27:03 GMT Received: from hypnos.cps.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hypnos.cps.intel.com [192.198.165.17]) id QQkgmv12144 for ; Thu, 15 Mar 2001 21:27:00 GMT Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id VAA23045 for ; Thu, 15 Mar 2001 21:26:59 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 15 Mar 2001 21:26:59 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 13:26:58 -0800 Message-ID: From: "Sharma, Prem" To: "'mpls@uu.net'" Subject: FW: Questions on GMPLS-02.txt Date: Thu, 15 Mar 2001 13:26:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, The following paragraph is from draft-ietf-mpls-generalized-signaling-02.txt. ... Note that since the nodes sending and receiving the new form of label know what kinds of link they are using, the generalized label does not contain a type field, instead the nodes are expected to know from context what type of label to expect. ... I'm not clear how the label type would be inferred if the link id or label type field is not provided when we have the scenario of two hybrid nodes connected together. By hybrid nodes, I mean the followings: * The nodes have K no. of fibers between them. * Each fiber carries L no. of wavelengths. * Some of the wavelengths are SDH/SONET (TDM) switched and the others are lambda (or wavelength) switched. * The control channel (for GMPLS control signalling) is OOB/OOF (Out of Band/Out of fiber)[Referring to LMP]. Besides this, I have one comment. Though the GMPLS Func. Desc. draft specifies the format of waveband labels, but the companion documents, like architecture document, don't specify in what all scenarios such labels are going to be used/granted. IMO, it leaves a lot to assume. Pls. help and correct me if something has been overlooked. Thanks in advance. Prem From owner-mpls@UU.NET Mon Mar 19 22:38:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04317 for ; Mon, 19 Mar 2001 22:38:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhco27130; Tue, 20 Mar 2001 03:38:03 GMT Received: by mail-control.mail.uu.net id QQkhcm08643 for mpls-outgoing; Tue, 20 Mar 2001 03:01:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhck04220 for ; Tue, 20 Mar 2001 02:38:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhck23491 for ; Tue, 20 Mar 2001 02:38:16 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhck23503 for ; Tue, 20 Mar 2001 02:38:16 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 SAA10583 for ; Mon, 19 Mar 2001 18:38:19 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA27971 for mpls@uu.net; Mon, 19 Mar 2001 21:38:14 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhbz04591 for ; Mon, 19 Mar 2001 23:49:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhbz10753 for ; Mon, 19 Mar 2001 23:49:33 GMT Received: from ss8mail1.ss8ott by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ss8.ca [209.87.228.147]) id QQkhbz22952 for ; Mon, 19 Mar 2001 23:49:33 GMT Received: from jianlipc (JIANLI_PC [192.168.1.78]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HH8Q22ZZ; Mon, 19 Mar 2001 18:50:25 -0500 From: "Jianli Wang" To: "Shobhan Lakkapragada" Cc: Subject: RE: CR-LDP MIBs Date: Mon, 19 Mar 2001 18:49:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3AAFB689.ECD572D@nortelnetworks.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Saobhan, We checked CR-LDP MIB and MPLS TE MIB, seems that everything is there. Thanks. jianli -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shobhan Lakkapragada Sent: Wednesday, March 14, 2001 1:21 PM To: Jianli Wang Cc: mpls@UU.NET Subject: Re: CR-LDP MIBs Jianli, We investigated whether a separate CR-LDP MIB is needed but found that most of the MIB objects needed for CR-LDP are supported by the LDP MIB and the MPLS TE-MIB. Only some objects for CR-LSP traffic parameters were missing, which were then added to the latest MPLS TE-MIB. Do you know of any other objects missing for a CR-LDP implementation? - shobhan Jianli Wang wrote: > Does the WG have any plan for CR-LDP MIBs or is anybody (individual) > working on it? > > Thanks. > > Jianli > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mark > Lewis > Sent: Monday, February 19, 2001 2:10 PM > To: jorge.rodriguez@telefonica-data.com > Cc: mpls@UU.NET > Subject: Re: Interoperability Cisco-Juniper > > Try this link: > > http://www.juniper.net/products/interoperability/250004.html > > Mark Lewis > Frontrunner Solutions > > On Mon, 19 Feb 2001 13:56:27 +0100, jorge.rodriguez@telefonica-data.com > wrote: > > > > > > > > > Can somebody give me any interoperability test information with Cisco > 12000 and > > Juniper? > > > > Sorry if this is not the proper forum... Is there another forum for this > issues? > > > > _____________________________ > > Jorge Rodriguez Gabilondo > > Telefonica > > Network Planning and Design > > > > > > _________________________________________________________________ > > Hemos renovado nuestra web. Esperamos su visita en > > http://www.telefonica-data.com > > > > > > _______________________________________________________ > Get 100% private, FREE email for life from Excite UK > Visit http://inbox.excite.co.uk/ From owner-mpls@UU.NET Mon Mar 19 23:04:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05237 for ; Mon, 19 Mar 2001 23:04:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhcq29724; Tue, 20 Mar 2001 04:03:40 GMT Received: by mail-control.mail.uu.net id QQkhcn22275 for mpls-outgoing; Tue, 20 Mar 2001 03:20:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhcm07007 for ; Tue, 20 Mar 2001 03:00:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhcm21477 for ; Tue, 20 Mar 2001 03:00:10 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhcm17936 for ; Tue, 20 Mar 2001 03:00:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA04719 for mpls@uu.net; Mon, 19 Mar 2001 22:00:08 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhcj03007 for ; Tue, 20 Mar 2001 02:18:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhcj08843 for ; Tue, 20 Mar 2001 02:18:09 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkhcj03527 for ; Tue, 20 Mar 2001 02:18:08 GMT Received: (qmail 8030 invoked by uid 104); 20 Mar 2001 02:18:08 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.392763 secs); 19/03/2001 18:18:07 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 20 Mar 2001 02:18:07 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f2K2I6n08527; Mon, 19 Mar 2001 18:18:06 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Mar 2001 18:18:07 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B3F@BBY1EXM01> From: Shahram Davari To: "'Francis Arts'" , mpls@UU.NET Subject: RE: Diff serv over MPLS Date: Mon, 19 Mar 2001 18:18:06 -0800 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 Francis, The reason was that the AF required a minimum of two drop priority treatment, and that people wanted to be able to find whether a packet is green or yellow/red just by looking at 2nd bit. Please check the archived emails for details. Yours, -Shahram > -----Original Message----- > From: Francis Arts [mailto:francis.arts@alcatel.be] > Sent: Friday, March 16, 2001 12:11 PM > To: mpls@UU.NET > Subject: Diff serv over MPLS > > > > Hello Francois, Liwen, ..., > > I have a question concerning the latest version of the 'diff serv over > MPLS' draft. For L-LSPs the drop precedence is encoded in the > exp bits. > Compared to version 7 of the draft the encoding of the color 'red' has > changed from 01 to 11. > > Why was this encoding changed? > > [If changing the encoding of the drop precedence would be > done, I would > have expected that the encoding of ALL (...) drop precedence values > would have changed to align with the recommended DSCPs for the AF PHB: > * 01 = green. > * 10 = yellow. > * 11 = red.] > > Kind regards, > > Francis. > From owner-mpls@UU.NET Tue Mar 20 02:21:51 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24288 for ; Tue, 20 Mar 2001 02:21:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhdd18060; Tue, 20 Mar 2001 07:20:15 GMT Received: by mail-control.mail.uu.net id QQkhdc22068 for mpls-outgoing; Tue, 20 Mar 2001 07:00:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhcz20340 for ; Tue, 20 Mar 2001 06:26:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhcz05311 for ; Tue, 20 Mar 2001 06:24:37 GMT Received: from smtp.263.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.44.20]) id QQkhcz20687 for ; Tue, 20 Mar 2001 06:24:29 GMT Received: from zhou (unknown [211.69.206.240]) by smtp.263.net (Postfix) with ESMTP id B98C0205BF for ; Tue, 20 Mar 2001 14:26:53 +0800 (CST) Date: Tue, 20 Mar 2001 14:24:28 +0800 From: zhou To: "mpls@uu.net" Subject: Re: RE: layer 3 switch isn't support WAN? X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Message-Id: <20010320062653.B98C0205BF@smtp.263.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA24288 >Could you pls tell me where did you read this >& if possible the same document also > >John http://www.3com.com/technology/tech_net/white_papers/500660.html Table 2 > >-----Original Message----- >From: zhou [mailto:ipswicth_zhou@263.net] >Sent: Monday, March 19, 2001 6:53 PM >To: mpls@uu.net >Subject: layer 3 switch isn't support WAN? > > >hi, > I have read a comparison between layer 3 switch Vs traditonal >router as follow: > Characteristic Layer 3 Switch Legacy Router > >-------------------------------------------------------------- >Routes core LAN protocols: > IP, IPX, AppleTalk Yes Yes >--------------------------------------------------------------- >Subnet definition Layer 2 switch >domain Port >--------------------------------------------------------------- >Forwarding architecture Hardware Software >--------------------------------------------------------------- >Forwarding performance High Low >--------------------------------------------------------------- >Policy performance High Low >--------------------------------------------------------------- >WAN support No Yes > >I am not clear about why layer 3 switch is not support WAN, >could you give more explanation ? Ö Àñ£¡ zhou ipswicth_zhou@263.net From owner-mpls@UU.NET Tue Mar 20 06:03:47 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00744 for ; Tue, 20 Mar 2001 06:03:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhds11317; Tue, 20 Mar 2001 11:00:20 GMT Received: by mail-control.mail.uu.net id QQkhdp05451 for mpls-outgoing; Tue, 20 Mar 2001 10:20:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhdo04150 for ; Tue, 20 Mar 2001 10:05:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhdo23236 for ; Tue, 20 Mar 2001 10:03:51 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhdo13136 for ; Tue, 20 Mar 2001 10:03:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA26181 for mpls@uu.net; Tue, 20 Mar 2001 05:03:49 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhdk15918 for ; Tue, 20 Mar 2001 09:13:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhdk29316 for ; Tue, 20 Mar 2001 09:12:31 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkhdk23514 for ; Tue, 20 Mar 2001 09:12:30 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Mar 2001 01:11:54 -0800 Message-ID: From: Vishal Sharma To: xuyg@lucent.com Cc: "'Zhi-Wei Lin'" , mpls@UU.NET, ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com Subject: RE: Three GMPLS related IDs: draft-xu-ccamp-gmpls-arch-intra-dom ain-00.txt Date: Tue, 20 Mar 2001 01:11:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Folks, I have read quite carefully through the three drafts that you referred to, and have the following comments them (they'll come one by one, in three emails). draft-xu-ccamp-gmpls-arch-intra-domain-00.txt. This is a v. good document, and provides a good overview of the various issues that need to be considered while architecting a control plane for optical networks, using MPLS/IP. Comments: i) On pp. 8, in the sentence "INE maintains LSP ID..." the LSP ID is introduced in this document for the first time. Where did this come from? Is it assumed that the document is suddenly referring to the LSP ID in RSVP-TE? If so, the connection needs to be made clear. If not, some introduction is needed before mentioning it. ii) In the same paragraph the sentences "However, it does not ... disseminate to other nodes," is unclear. What local information needn't exist on other NEs? iii) In Section 5, the phrase "Several physical attributes can be abstracted into one logical attribute," needs more elaboration, with examples. iv) On pp. 10, second last para, "The user traffic _connection service_ performance..." What is "connection service"? Some explanation needed. v) On pp. 13, under "Service Negotiation," ... "A typical example is... assignment order." What is this example saying? Seems quite unclear how it pertains to service negotiation. vi) On pp. 19, in the paragraph just above Section 5.3.2., you say "This implies that a time slot map.... routing decisions." Then, "Alternately, in the logical link ... STS-N signals." This latter phrase is not clear. What is the "logical link" representation? vii)In Section 5.4.1, the analogies to apply MPLS control plane concepts to circuit switched networks are both unclear. The first one is especially unclear, since it's not clear to the reader what exactly you seem to be drawing a parallel between? The second one, though better, is still not well said. viii) Similarly, on pp. 19, you talk again of a logical link (bundle). I think the term "logical link" needs to be explained better throughout the text. It was quite confusing. ix)In Section 5.4.1.2.2, you introduce "Connection ID" for the first time. Please define it first. x) The hierarchical label format, and its use is very _unclear_. I think if the text intends to make a case for that, the explanation just above the hierarchical label format needs to be much much better. xi) In Section 5.4.1.5, pp. 25, first paragraph. The phrase starting with "If the incoming label... NEs in parallel," is again unclear. To whom should the label be given at request time? I think what you mean is that the label should be allocated at request time, and the cross-connect (that allocated that label, to be passed to its upstream neighbor during the confirmation phase) should start configuring itself accordingly. xii) Section 5.4.1.6 on LSP tunneling and label stack, should have more explanation. How is the hierarchical label used exactly? xiii) Again in the "Delete" operation on pp. 25, you talk of LSP ID. Not clear where this comes from. RSVP-TE? xiv) Section 5.4.2, says (at last!) that "LSP ID can be defined as a source NE address + a source NE ingress label." How does a source NE have an ingress label? xv) The phrase immediately following the last one "An LSP has two sets of information ...." is again unclear. Does it mean an LSP has two sets of info. associated with it? xvi) Section 5.4.1.7 "A new LSP can be concatenated through ..." What does "concatenated through" mean?? xvii) At the end of the document, I came away with the feeling that it somehow ended abruptly. I haven't put my finger on it yet, but that is what I felt. I almost felt that more should have been there. xviii) A number of references don't seem to be referred to in the text. [LSP-HIER], [IPO-FRAM], [OSPF-OMPLS], [ISIS-OMPLS]. xix) In addition, a number of documents that probably should be referenced in this one are not referenced. For example, draft-bernstein-gmpls-optical-00.txt, makes many points germane to the subject of this draft. draft-ietf-mpls-recovery-frmwrk-02.txt, and draft-harrison-mpls-oam-00.txt, also make many points relevant to the discussions in Section 5.4.3. There exist drafts on bundling that are not mentioned here. draft-kompella-mpls-bundle-05.txt, for instance. From owner-mpls@UU.NET Tue Mar 20 07:01:47 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02400 for ; Tue, 20 Mar 2001 07:01:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhdw02599; Tue, 20 Mar 2001 12:00:28 GMT Received: by mail-control.mail.uu.net id QQkhdt24227 for mpls-outgoing; Tue, 20 Mar 2001 11:20:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhds22830 for ; Tue, 20 Mar 2001 11:04:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhds16691 for ; Tue, 20 Mar 2001 11:03:51 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhds20521 for ; Tue, 20 Mar 2001 11:03:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA28647 for mpls@uu.net; Tue, 20 Mar 2001 06:03:50 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhdo04905 for ; Tue, 20 Mar 2001 10:12:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhdo06092 for ; Tue, 20 Mar 2001 10:11:05 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkhdo23038 for ; Tue, 20 Mar 2001 10:11:04 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Mar 2001 02:10:34 -0800 Message-ID: From: Vishal Sharma To: "'xuyg@lucent.com'" Cc: "'Zhi-Wei Lin'" , "'mpls@UU.NET'" , "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" Subject: RE: Three GMPLS related IDs: draft-xu-ccamp-gmpls-sig-reorg-00.tx t Date: Tue, 20 Mar 2001 02:10:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Folks, This is the second in a series of three emails. (First, a note to Bert Wijnen. I have cc'd all the three lists, since the original request was sent on all three, and I wanted to make people aware that this subject is under active discussion. The authors may now reply to only CCAMP, if they wish, since people on other lists have at least been made aware of the ongoing discussion, and can always access the CCAMP archives to see what's going on; BTW, talking of CCAMP archives, unlike MPLS or IPO, they appear as one undifferentiated file of emails, which is _very difficult_ to wade through.) -Vishal Now on to comments: i) Section 4. The phrase "GMPLS signaling is .... consists of a set of messages," does not appear to be accurate, since the GMPLS signaling draft draft-ietf-mpls-generalized-signaling-02.txt, does not use this terminology. In particular, saying that they are "Create/response, Restoration/response... ... Notification," is likely to throw people off. ii) The document classified G-label as "optional." Is that correct? Why would that be so? iii) Section 5.1, starts out well, but soon meanders... The first two make sense, even the third and fourth ones (perhaps), but the fifth is problematic. I think some justification should also be given about why it makes sense for GPID to be associated with each signal type. BTW, the current signaling draft (see above) _does not_ associate the GPID with anything. The GPID, as defined, is a flat, undifferentiated space. The code points are neither interpreted in the context of LSP encoding type nor signal type. The draft [GMPLS-SIGEN] was the one that proposed dividing GPID by LSP encoding type, and you are proposing an even finer division. Note that I am not commenting on the appropriateness or otherwise of any of these proposals. I am merely asking that if the draft proposes reasons for modification, then it should provide them so that the reader can appreciate the logic. iv) The example under the sixth point is not clear. The RNC has to be interpreted together with RGT (as you yourself observe in the preceding sentence). If the RGT was standard contiguous or arbitrary contiguous concatenation, the interpretation would be "STS-3c", if RGT was virtual concatenation, the interpretation would be "STS-3v", if it was bundle, the interpretation would be "3 co-routed STS-1s." Where is the problem? (Zhi, don't remind me again about 3 STS-3 or 3 STS-7v, etc. :-), since, as I explained in a separate email on this thread, they cannot be signaled in one shot using the definitions in the current signaling draft [GMPLS-SIG].) v) Section 5.2. The Signal Type now incorporates the RNC and RGT of GMPLS-SIG. Again, it is not clear why this was necessary or desirable? No adequate justification seems to have been provided for this choice. One major problem with doing what you have done is that this leaves no possibility to accomplish reason one in your "Reasons for Modification." Namely, you cannot now have a generalized label that spans packet, TDM, WDM, fiber, etc. (Perhaps you have have one that spans the optical technologies, but is that good enough?) RGT and RNT are general concepts that are probably generalizable in a way that each layer in a layered network can use them, so why throw away that possibility by intertwining everything within "signal type"? **(Note that even GMPLS-SIG does not truly have a generalized label, since it proposes a "generalized label" and then again an "SDH/SONET label"! However, I see no good technical or architectural reason for why that needs to be the case. Indeed, GMPLS-SIGEN states very eloquently why having a single label format makes a lot of sense, and, as Yuanggang calls it, "puts the G in GMPLS".) ** vi) Section 5.2, the "Directionality" bits say "Indicates the direction of the LSP," ... with respect to what? If the intent is to clarify/enhance things, the explanation needs to be much clearer. vii) The "Service Type" bits seem to have absorbed what in GMPLS-SIGEN was the Link Protection Flags, and what in GMPLS-SIG is the Protection TLV. If that is so, this needs to be explicitly stated somewhere. This also is problematic. What if a service provider wants to provide a service that is independent of the underlying protection? Or is protection deemed to be an integral part of every/any service? Again, doesn't appear very clear. viii) The firs sentence in Section 6 should probably be modified to "Current ER Object/TLV ... Logical Link (bundle) granularity, by introducing a logical interface ID object." ix) A confusion with Section 6 is, which ER object are you talking about?? Which draft or drafts are you referring to?? I think it would be much easier on the reader, if at specific points this draft provides references to the particular one of the three drafts ([GMPLS-SIGEN], [GMPLS-SIG], or [GMPLS-ARCH]) that discusses the topic at hand. x) Section 7.1.2. As in the GMPLS-ARCH draft, this section is very unclear. It does not adequately explain what is happening, nor does it provide the reader a view of why a hierarchical label is needed or makes sense? The last sentence says "The hierarchical label ... at the stack bottom." Why not show it with an example? The sentence above that says, "Hierarchical format is a more generic form." Than what?? Than having a single label? Why? How does it work? What is the use? The reader is left wondering ... xii)The last sentence in Section 7.2.1 says "The Channel ID structure is ... and defined in [GMPLS-SIG] and [GMPLS-SIGEN]." Where?? This is very^2 confusing, since these two drafts do not use the same terminology as the current draft. The draft should either clearly point out where these drafts define something akin to the channel ID, or say what these drafts call this beast, so that the reader is not left confused and bewildered!! (BTW, I hate the practice that we seem to have gotten into recently of having a plethora of drafts, with each covering a small morsel of the total picture, and then referring to each other, at crucial junctures in the drafts. This leads the reader/implementer on a wild goose chase, and makes the drafts quite incomprehensible!) xiii)I think it has been already pointed out that Suggested Label and Label Set are not, in fact, mutually exclusive. I may have a label set, and from _within_ that set suggest a specific label to my neighboring node. Thus, both could be simultaneously present. Hence, the assumption in Section 8.1 and the corresponding reason for creating the suggested label set, are incorrect. xiv) Section 8.2, pp. 9, last sentence under "Action: 8 bits" is unclear. If the transmit and receive labels are adjacent, how will they be distinguished. Where and how will their placement have been negotiated? xv) Section 8.2, under G-label, "Specifies a label without an _object wrapper_" What is that?? Some explanation needed. xvi)Finally, the reference to [GLABEL-REQ] at the end is wrong and incomplete. Unless this is a new draft, I think what was meant here was draft-lin-ccamp-ipo-common-label-request-00.txt. Also, it is a good practice to give the complete title of the draft "draft-lin ...." to make it easier for the reader to locate it. (Especially useful considering that the implementer is running on a wild goose chase trying to make sense of the myriad drafts across which useful information tidbits are spread!) From owner-mpls@UU.NET Tue Mar 20 08:01:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04220 for ; Tue, 20 Mar 2001 08:01:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhea23204; Tue, 20 Mar 2001 13:00:34 GMT Received: by mail-control.mail.uu.net id QQkhdx13539 for mpls-outgoing; Tue, 20 Mar 2001 12:20:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhdw12259 for ; Tue, 20 Mar 2001 12:05:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhdw06317 for ; Tue, 20 Mar 2001 12:03:56 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhdw08159 for ; Tue, 20 Mar 2001 12:03:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA01651 for mpls@uu.net; Tue, 20 Mar 2001 07:03:54 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhds13052 for ; Tue, 20 Mar 2001 11:01:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhds26475 for ; Tue, 20 Mar 2001 11:01:11 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQkhds23613 for ; Tue, 20 Mar 2001 11:01:10 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Mar 2001 03:00:40 -0800 Message-ID: From: Vishal Sharma To: "'mvissers@lucent.com'" Cc: "'Zhi-Wei Lin'" , "'xuyg@lucent.com'" , "'mpls@UU.NET'" , "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" Subject: RE: Three GMPLS related IDs: draft-lin-ccamp-ipo-common-label-req uest-00.txt Date: Tue, 20 Mar 2001 03:00:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Folks, This is the last in the sequel. -Vishal Now on to the comments: i) First, a nit. The draft should be named "Common Label Request and Label Specification ...," since that is precisely the order in which it discusses things. ii) Also, (unless the plan was to make the wild goose chase of the implementer interesting!) at various points "Signaling Type" needs to be replaced with "Signal Type." The two don't mean the same thing. :-) iii) Section 2, Abstract. The statement describing the very first change needs to be expanded on somewhere in the rest of the text! It is not just a new _set_ of Signal Type structures, it is a completely new organization of what is there in GMPLS-SIG or in GMPLS-SIGEN, and that needs to be made very clear to the reader. The text should say that RGT, RNT, etc. have been all absorbed into the signal type. (Of course, it is an entirely different matter to say "why" that makes sense, but we'll come to that shortly.) iv) The final "signal type" discussed in Section 3.2.3 again breaks things into a signal type and a concatenation type. So it seems such a break-up is needed. What would be use then of eliminating RNC in GMPLS-SIG? If there is a valid technical reason for doing things this way, it should be clearly, succintly, and unambiguously articulated. I am afraid, in this trilogy of drafts that does not seem to have been done adequately. v) My major problem with this and its companion draft is that it proposes changes (some of which could even be good ones), BUT it does not provide a detailed enough justification for all of its changes. Nor does it provide the reader with any insight about why the encoding proposed in this draft is a good one, a better one, an easier one, or a sensible one. (Note: I am not implying that the remaining GMPLS drafts do a good job of this. I am here merely pointing to the _need_ to do so, in all drafts; in particular, in drafts that propose changing things (pl. see, for example, draft-mack-crane-gmpls-signaling-enhancements-00.txt and draft-bernstein-gmpls-optical-00.txt, which at least make an attempt to do so). This is especially useful to enable the community to appreciate the _technical merits_ of each proposal and is very^2 helpful to pick the right ones.) A lot of the community may not instantly know all of the technicalities of SONET/SDH or optical technologies, so it is all the more important to make a crystal clear _technical case_, that anyone can appreciate. vi) So why does it make sense to combine RGT and RNT and transparency, and signal type all into "signal type"? Why is that more helpful/better/cleaner than a form of encoding that treats these as separate entities? -- If we resort to one big coding space for signal types, it would be difficult to add more as more signal types come in, since all combinations of those signal types with RGT and RNC will have to be added. -- Further, what if an RNC or RGT option changes tomorrow? Now, we'd have to expand all existing signal types! If things were broken up, only the RGT or RNT codepoints would change. vii) The encoding of signal types in Section 3.2.4 allows for two ways to specify an STS-1, using value 5, X=0 or value 7, X=1. Was this intended? viii) Section 3.2.4, in the values for virtual concatenation (10-15), why does the draft stop at STS-3c-Xv? What about STS-12c-Xv, or higher? ix)Similarly, in the values for co-routed groups (23-27), why stop at STS-3c-X? What about STS-12c-X or higher? x) Page 8, para 3, the number of vendor specific codepoints is 12 it seems, not 13. xi) Section 4.2, the document spends many paragraphs trying to make a case apparently for why HOVC and LOVC labels are independent, and should have dedicated channel IDs. However, I cannot see how this follows from any of the preceding explanations. After a lot of words, the reader is suddenly confronted with the blanket statement " Therefore, HOVC.... labels. Each one will have a dedicated channel ID." xii) Again, in Section 4.2, the notation for the sub-STM-0/STM-1 signals is never introduced, even briefly. It is just thrown at the reader. Where does that come from? What is the background? The reader has no clue... xiii) In the same section, para 6, the last sentence says "At any moment, the complete aggregation bandwidth's multiplex structure must be defined to prevent alarms to be raised." Uh?! Say what? xiv) Section 4.2.3, please ... at least give an explanation of the notation used in the title, in plain English, somewhere. (Not everyone is an SDH/SONET expert, for crying out loud!) xv) Again, maybe I am missing something, but how does the current encoding allow to encode a signal like 3 STS-3? or 7 STS-3c-Xv? Or doesn't it? xvi) Also, it would be useful for the document to give references to all the G.707, G.708, etc. documents that it refers to throughout, together with pointers to how they may be obtained. (Let's make people's life a little bit easier, let's at least help them read, understand, and look at our drafts critically, instead of having them put the drafts aside in a huge pile, never to be read.) From owner-mpls@UU.NET Tue Mar 20 12:12:39 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14009 for ; Tue, 20 Mar 2001 12:12:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkheq15008; Tue, 20 Mar 2001 17:10:25 GMT Received: by mail-control.mail.uu.net id QQkheq22573 for mpls-outgoing; Tue, 20 Mar 2001 17:09:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkheq22566 for ; Tue, 20 Mar 2001 17:09:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkheq20726 for ; Tue, 20 Mar 2001 17:09:09 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkheq07320 for ; Tue, 20 Mar 2001 17:09:07 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 JAA21650 for ; Tue, 20 Mar 2001 09:09:06 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA28943 for mpls@uu.net; Tue, 20 Mar 2001 12:09:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkheq11888 for ; Tue, 20 Mar 2001 17:02:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkheq06861 for ; Tue, 20 Mar 2001 17:02:34 GMT Received: from mailgw.local.ipunplugged.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.88.134.217]) id QQkheq15068 for ; Tue, 20 Mar 2001 17:02:33 GMT Received: from HANSPC (sparcis.local.ipunplugged.com [192.168.4.51]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA20942; Tue, 20 Mar 2001 18:02:21 +0100 From: =?iso-8859-1?Q?Hans_Sj=F6strand?= To: , Subject: RE: ldp MIB Date: Tue, 20 Mar 2001 11:02:01 +0100 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit No, the entity and the peer is one-to-one. Just because it's indexed this way, using the ldpId and the peers ldp id in the index it doesn't automatically imply a one to many relationship. On the contrary, the ldp session table is augmenting the ldp peer table and it's specifically a one-to-one relationship between entity and session, e.g. section 3.1 Overview "A table is used to configure potential LDP Sessions, where each row in the table initiates an LDP Session. This is the mplsLdpEntityTable" Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Anil > Gunturu > Sent: den 16 mars 2001 20:37 > To: mpls@UU.NET > Subject: ldp MIB > > > Hi, > I was wondering, if it is possible for an entry in the MplsLdpEntity table > there are multiple entries in the MplsPeerEntryTable? Looks like the MIB > allows it because the MplsLdpPeerEntry table is indexed by > mplsLdpEntityLdpId, mplsLdpEntityIndex and mplsLdpPeerLdpId. If it is > possible can some one give a practical scenario. > Thanks in advance for help, > -Anil > > Anil Gunturu, Software Engineer > Ericsson, Inc phone: (805) 562 6431 > Datacom & IP Services email: anilg@acc.am.ericsson.se > 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Tue Mar 20 15:53:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24563 for ; Tue, 20 Mar 2001 15:53:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhff19474; Tue, 20 Mar 2001 20:50:50 GMT Received: by mail-control.mail.uu.net id QQkhff27412 for mpls-outgoing; Tue, 20 Mar 2001 20:50:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhff27396 for ; Tue, 20 Mar 2001 20:50:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhff20580 for ; Tue, 20 Mar 2001 20:49:22 GMT Received: from usrsrv1.meeting.ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.meeting.ietf.org [135.222.20.40]) id QQkhff14239 for ; Tue, 20 Mar 2001 20:49:22 GMT Received: from mindspring.com (pcp008482pcs.desktop.meeting.ietf.org [135.222.3.41]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with ESMTP id f2KKMww10014; Tue, 20 Mar 2001 14:22:58 -0600 (CST) Message-ID: <3AB7CA17.187DCE1E@mindspring.com> Date: Tue, 20 Mar 2001 14:22:31 -0700 From: ietf Reply-To: egray@sandburst.com X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yangguang Xu CC: Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question regarding bi-directional connection set up - And Port-ID in Label object References: <4611AD058694D4118FD5009027B0A6622B8C30@ICARIAN> <3AB0DA8F.B364BEB0@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang, I'm not sure that merging them is the right thing to do. They do not represent the same thing. I believe the suggested label is the label the upstream would like the downstream to assign/recognize while the upstream label (I believe) is the label that the upstream _has_ assigned for the use of the downstream in a corresponding reverse LSP. There are two problems with trying to force the two to be the same: o one is being assigned and the other is being requested (assignment may not occur as requested), and o it is not always the case that the same label can be assigned, in both directions, and associated with the two halves of the same bi-directional LSP. -- Eric Gray Yangguang Xu wrote: > Fong, > > > > > Regarding how to encode the bi-directionality request, > > Removal of upstream label prevents pre-program the > > cross-connect, not desirable in some situation. So I would > > be in favor of keeping the upstream label object. > > > > I wasn't suggesting to get rid of upstream label (the concept). I proposed to > merge it with suggested label, label set into a single suggested label set > object. I gave reasons in my ID (draft-xu-ccamp-gmpls-sig-reorg-00.txt). A NE > should be able to specify labels of both directions for bi-directional LSP in > optical network. > > Thanks, > > Yangguang From owner-mpls@UU.NET Tue Mar 20 16:08:56 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25213 for ; Tue, 20 Mar 2001 16:08:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhfg24940; Tue, 20 Mar 2001 21:06:36 GMT Received: by mail-control.mail.uu.net id QQkhfg07608 for mpls-outgoing; Tue, 20 Mar 2001 21:06:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhfg07574 for ; Tue, 20 Mar 2001 21:05:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfg26047 for ; Tue, 20 Mar 2001 21:04:07 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhfg11140 for ; Tue, 20 Mar 2001 21:04:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA23199 for mpls@uu.net; Tue, 20 Mar 2001 16:04:06 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhfg04737 for ; Tue, 20 Mar 2001 21:03:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhfg23335 for ; Tue, 20 Mar 2001 21:03:21 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkhfg19661 for ; Tue, 20 Mar 2001 21:03:20 GMT Received: from flefauch-8kcdt.cisco.com (sj-dial-3-52.cisco.com [171.68.180.53]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id WAA06989; Tue, 20 Mar 2001 22:03:07 +0100 (MET) Message-Id: <4.0.2.20010320120117.0220e380@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 20 Mar 2001 12:28:27 +0100 To: Francis Arts From: Francois Le Faucheur Subject: Re: Diff serv over MPLS (L-LSP EXP bits encoding) Cc: mpls@UU.NET In-Reply-To: <3AB24936.E96E5D9F@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Francis, hey, just on time for the end of the Last Call... At 18:11 16/03/2001 +0100, Francis Arts wrote: > >Hello Francois, Liwen, ..., > >I have a question concerning the latest version of the 'diff serv over >MPLS' draft. For L-LSPs the drop precedence is encoded in the exp bits. >Compared to version 7 of the draft the encoding of the color 'red' has >changed from 01 to 11. > >Why was this encoding changed? > encoding was changed for the following reason: * L-LSPs EXP<-->PHB mapping ========================= >We plan to incorporate Jim Murphy's suggestion to modify the EXP value >corresponding to AFn3 L-LSPs. AFn3 would be mapped to EXP=011 (instead of >010). >For memory, the rationale is that implementations which support only two >drop priorities per AF class could determine the drop priority to be >applied by looking at a single bit. Same idea was used for the DSCP >encodings for AF. > so, motivation is to have one single bit that can be checked for yellow_or_red. apart from that, absolute values don't really matter; but I agree that we may as well use the same value as AF DSCP "drop bits". -09 will use EXP= 001, 010, 011. Thanks Francois >[If changing the encoding of the drop precedence would be done, I would >have expected that the encoding of ALL (...) drop precedence values >would have changed to align with the recommended DSCPs for the AF PHB: >* 01 = green. >* 10 = yellow. >* 11 = red.] > >Kind regards, > > Francis. > From owner-mpls@UU.NET Tue Mar 20 18:51:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02177 for ; Tue, 20 Mar 2001 18:51:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhfr23834; Tue, 20 Mar 2001 23:49:13 GMT Received: by mail-control.mail.uu.net id QQkhfr29732 for mpls-outgoing; Tue, 20 Mar 2001 23:48:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhfr29727 for ; Tue, 20 Mar 2001 23:48:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfr12141 for ; Tue, 20 Mar 2001 23:47:46 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhfr13735 for ; Tue, 20 Mar 2001 23:47:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA03391 for mpls@uu.net; Tue, 20 Mar 2001 18:47:44 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhfr29581 for ; Tue, 20 Mar 2001 23:46:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhfr16206 for ; Tue, 20 Mar 2001 23:46:30 GMT Received: from lobster.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns3.BayNetworks.COM [192.32.253.3]) id QQkhfr03110 for ; Tue, 20 Mar 2001 23:46:30 GMT Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id SAA05494; Tue, 20 Mar 2001 18:52:17 -0500 (EST) 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 SAA26051; Tue, 20 Mar 2001 18:43:04 -0500 (EST) Received: from baynetworks.com (dhcp235-150 [192.32.235.150]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id SAA18984; Tue, 20 Mar 2001 18:43:04 -0500 for Message-ID: <3AB7EA60.2599E614@baynetworks.com> Date: Tue, 20 Mar 2001 18:40:17 -0500 From: Shobhan Lakkapragada Reply-To: slakkapr@nortelnetworks.com Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: manoj juneja CC: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: Please Clarify on O-UNI Issues.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Manoj, If you have access to OIF specs, please see the LDP UNI signaling section of oif2000.125.3. It has definitions of LDP messages for Address Resolution, among other things. Although it comes from a different SB, both OIF work and IETF drafts seem to be in sync for O-UNI. - shobhan manoj juneja wrote: > Hi All, > I was going through the draft > "draft-ietf-mpls-ldp-optical-uni-00.txt", but I could not find the complete > picture related to neighbor discovery, Address Resolution issues. Can > someone please give a pointer to some other draft which is pre-requisite for > this one (O-UNI draft). Is there more work going on O-UNI draft ? > I could not find even a single draft which talks from architectural > viewpoint. There is one architecture document (gmpls-arch-00.txt), this > document also lacks lot of information. > > Please help. > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Mar 20 19:15:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03161 for ; Tue, 20 Mar 2001 19:15:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhfs09056; Wed, 21 Mar 2001 00:13:15 GMT Received: by mail-control.mail.uu.net id QQkhfs16510 for mpls-outgoing; Wed, 21 Mar 2001 00:11:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhfs16501 for ; Wed, 21 Mar 2001 00:11:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfs06624 for ; Wed, 21 Mar 2001 00:10:46 GMT Received: from apollo.mctr.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQkhfs03519 for ; Wed, 21 Mar 2001 00:10:45 GMT Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id TAA25686; Tue, 20 Mar 2001 19:10:42 -0500 (EST) Received: from localhost (ayyangar@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id TAA16306; Tue, 20 Mar 2001 19:17:36 -0500 (EST) X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs Date: Tue, 20 Mar 2001 19:17:36 -0500 (EST) From: Arthi Ayyangar X-Sender: ayyangar@mercury.mctr.umbc.edu To: mpls@UU.NET, ccamp@ops.ietf.org Subject: Notify msg Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk What is the RSVP message type for Notify msg. ?? (There is no mention of it in draft-ietf-mpls-generalized-rsvp-te-01.txt.gz) Thanks, -arthi From owner-mpls@UU.NET Tue Mar 20 20:01:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05046 for ; Tue, 20 Mar 2001 20:01:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhfv03082; Wed, 21 Mar 2001 00:58:42 GMT Received: by mail-control.mail.uu.net id QQkhfv19433 for mpls-outgoing; Wed, 21 Mar 2001 00:57:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhfv19426 for ; Wed, 21 Mar 2001 00:57:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfv19939 for ; Wed, 21 Mar 2001 00:56:44 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhfv28168 for ; Wed, 21 Mar 2001 00:56: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 QAA10670 for ; Tue, 20 Mar 2001 16:56:47 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id TAA29916 for mpls@uu.net; Tue, 20 Mar 2001 19:56:41 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhfq28414 for ; Tue, 20 Mar 2001 23:32:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfq05827 for ; Tue, 20 Mar 2001 23:31:42 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f38.law10.hotmail.com [64.4.15.38]) id QQkhfq21996 for ; Tue, 20 Mar 2001 23:31:42 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Mar 2001 15:31:41 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 20 Mar 2001 23:31:40 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, mpls@UU.NET Date: Tue, 20 Mar 2001 16:31:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2001 23:31:41.0221 (UTC) FILETIME=[EAB2E550:01C0B195] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, Please clarify on the following issue : Will IETF's MPLS WG going to adopt OIF UNI 1.0 specification instead of its draft-ietf-mpls-ldp-optical-uni-00.txt? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Mar 20 20:01:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05111 for ; Tue, 20 Mar 2001 20:01:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhfw28878; Wed, 21 Mar 2001 01:00:32 GMT Received: by mail-control.mail.uu.net id QQkhfv19436 for mpls-outgoing; Wed, 21 Mar 2001 00:57:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhfv19427 for ; Wed, 21 Mar 2001 00:57:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfv19311 for ; Wed, 21 Mar 2001 00:56:28 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhfv27336 for ; Wed, 21 Mar 2001 00:56:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA10539 for ; Tue, 20 Mar 2001 16:56:31 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id TAA29910 for mpls@uu.net; Tue, 20 Mar 2001 19:56:26 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhfo26633 for ; Tue, 20 Mar 2001 23:06:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfo07216 for ; Tue, 20 Mar 2001 23:05:47 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f41.law10.hotmail.com [64.4.15.41]) id QQkhfo10352 for ; Tue, 20 Mar 2001 23:05:47 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Mar 2001 15:05:42 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 20 Mar 2001 23:05:42 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Please Clarify on O-UNI Issues.... Date: Tue, 20 Mar 2001 16:05:42 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2001 23:05:42.0809 (UTC) FILETIME=[49D01890:01C0B192] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I was going through the draft "draft-ietf-mpls-ldp-optical-uni-00.txt", but I could not find the complete picture related to neighbor discovery, Address Resolution issues. Can someone please give a pointer to some other draft which is pre-requisite for this one (O-UNI draft). Is there more work going on O-UNI draft ? I could not find even a single draft which talks from architectural viewpoint. There is one architecture document (gmpls-arch-00.txt), this document also lacks lot of information. Please help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Mar 20 20:02:47 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05139 for ; Tue, 20 Mar 2001 20:02:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhfw08041; Wed, 21 Mar 2001 01:00:35 GMT Received: by mail-control.mail.uu.net id QQkhfv19439 for mpls-outgoing; Wed, 21 Mar 2001 00:58:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhfv19428 for ; Wed, 21 Mar 2001 00:57:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfv21216 for ; Wed, 21 Mar 2001 00:57:16 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhfv28968 for ; Wed, 21 Mar 2001 00:57:16 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 QAA11005 for ; Tue, 20 Mar 2001 16:57:19 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id TAA29924 for mpls@uu.net; Tue, 20 Mar 2001 19:57:14 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhfr00368 for ; Tue, 20 Mar 2001 23:59:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfr09390 for ; Tue, 20 Mar 2001 23:59:09 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f130.law10.hotmail.com [64.4.15.130]) id QQkhfr08464 for ; Tue, 20 Mar 2001 23:59:09 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Mar 2001 15:59:08 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 20 Mar 2001 23:59:08 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: slakkapr@nortelnetworks.com Cc: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: Please Clarify on O-UNI Issues.... Date: Tue, 20 Mar 2001 16:59:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2001 23:59:08.0368 (UTC) FILETIME=[C0799500:01C0B199] Sender: owner-mpls@UU.NET Precedence: bulk Hi Shobhan, There is some difference in both oif2000.125.3 and IETF O-UNI drafts. In IETF O-UNI, there are no messages like Address Resolution Query, Address Resolution Response. Also, It is written that FEC TLV has no significance at UNI. If it is present then it should be ignored. Please elaborate more on this. Regards, manoj. >From: Shobhan Lakkapragada >Reply-To: slakkapr@nortelnetworks.com >To: manoj juneja >CC: mpls@uu.net, ip-optical@lists.bell-labs.com >Subject: Re: Please Clarify on O-UNI Issues.... >Date: Tue, 20 Mar 2001 18:40:17 -0500 > > >Manoj, > >If you have access to OIF specs, please see the LDP >UNI signaling section of oif2000.125.3. It has definitions >of LDP messages for Address Resolution, among other >things. Although it comes from a different SB, both >OIF work and IETF drafts seem to be in sync for O-UNI. > >- shobhan > > > >manoj juneja wrote: > > > Hi All, > > I was going through the draft > > "draft-ietf-mpls-ldp-optical-uni-00.txt", but I could not find the >complete > > picture related to neighbor discovery, Address Resolution issues. Can > > someone please give a pointer to some other draft which is pre-requisite >for > > this one (O-UNI draft). Is there more work going on O-UNI draft ? > > I could not find even a single draft which talks from architectural > > viewpoint. There is one architecture document (gmpls-arch-00.txt), this > > document also lacks lot of information. > > > > Please help. > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Mar 20 20:04:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05235 for ; Tue, 20 Mar 2001 20:04:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhfw11141; Wed, 21 Mar 2001 01:02:33 GMT Received: by mail-control.mail.uu.net id QQkhfw19545 for mpls-outgoing; Wed, 21 Mar 2001 01:00:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhfv19456 for ; Wed, 21 Mar 2001 00:58:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhfv21192 for ; Wed, 21 Mar 2001 00:57:07 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhfv13872 for ; Wed, 21 Mar 2001 00:57:07 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 QAA29291 for ; Tue, 20 Mar 2001 16:57:25 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id TAA29920 for mpls@uu.net; Tue, 20 Mar 2001 19:57:04 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhfq29082 for ; Tue, 20 Mar 2001 23:44:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhfq28748 for ; Tue, 20 Mar 2001 23:43:17 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f186.law10.hotmail.com [64.4.15.186]) id QQkhfq24131 for ; Tue, 20 Mar 2001 23:43:17 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Mar 2001 15:43:13 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 20 Mar 2001 23:43:13 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Please Clarify on O-UNI Status Date: Tue, 20 Mar 2001 16:43:13 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2001 23:43:13.0574 (UTC) FILETIME=[875F9460:01C0B197] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, Please clarify on the following issue : Will IETF's MPLS WG going to adopt OIF UNI 1.0 specification instead of its draft-ietf-mpls-ldp-optical-uni-00.txt? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Mar 20 22:09:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10966 for ; Tue, 20 Mar 2001 22:09:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhge21412; Wed, 21 Mar 2001 03:08:49 GMT Received: by mail-control.mail.uu.net id QQkhge14977 for mpls-outgoing; Wed, 21 Mar 2001 03:08:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhge14951 for ; Wed, 21 Mar 2001 03:08:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhge22357 for ; Wed, 21 Mar 2001 03:07:10 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhge27128 for ; Wed, 21 Mar 2001 03:07:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA16361 for mpls@uu.net; Tue, 20 Mar 2001 22:07:08 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhge07626 for ; Wed, 21 Mar 2001 03:02:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhge11628 for ; Wed, 21 Mar 2001 03:02:23 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkhge13543 for ; Wed, 21 Mar 2001 03:02:23 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA22350; Tue, 20 Mar 2001 22:01:27 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (sj-dial-4-7.cisco.com [171.68.181.136]) by bucket.cisco.com (Mirapoint) with ESMTP id ABF12012; Tue, 20 Mar 2001 22:02:07 -0500 (EST) Message-Id: <4.3.2.7.2.20010320183644.01b6b008@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Mar 2001 18:38:54 -0500 To: mpls@UU.NET From: "Thomas D. Nadeau" Cc: arun Viswanathan , Cheenu Srinivasan , "Wijnen, Bert (Bert)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, We are currently going through the edits requested by the IESG for the proposed standard version of the MPLS-LSR-MIB. The issue of whether or not to add a new node under transmission called mplsMIB was brought up. We think that this should be done, but it was pointed out that the WG should comment on this. Please let us know what you all think. --Tom > although... this MIB possibly should go under transmission. > so then import "transmission" instead of "experimental" > and use: > > ::= { transmission xxx } -- to be assigned by IANA, > -- porbably best to use 166 (MPLS) > > And then.. there might be other MPLS related MIBs that need to > be underneath this node, so maybe even define mplsMIB as > transmission xxx and then have various other MPLS (transmission) > related MIBs underneath mplsMIB... Did the WG discuss and > consider this? From owner-mpls@UU.NET Wed Mar 21 00:21:21 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17188 for ; Wed, 21 Mar 2001 00:21:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhgn26984; Wed, 21 Mar 2001 05:20:31 GMT Received: by mail-control.mail.uu.net id QQkhgn24325 for mpls-outgoing; Wed, 21 Mar 2001 05:19:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhgn24318 for ; Wed, 21 Mar 2001 05:19:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhgn19002 for ; Wed, 21 Mar 2001 05:18:37 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkhgn21261 for ; Wed, 21 Mar 2001 05:18:36 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 21 Mar 2001 10:55:56 +0530 Received: from saumyad (saumyad.future.futsoft.com [10.0.6.85]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f2LArJ824531; Wed, 21 Mar 2001 16:23:19 +0530 Received: by localhost with Microsoft MAPI; Wed, 21 Mar 2001 10:30:35 +1100 Message-Id: <01C0B1F1.F72E1140.saumyad@future.futsoft.com> From: Saumya D Reply-To: "saumyad@future.futsoft.com" To: =?us-ascii?Q?=27Hans_Sjostrand=27?= , "anilg@acc.am.ericsson.se" , "mpls@uu.net" Subject: RE: ldp MIB Date: Wed, 21 Mar 2001 10:30:35 +1100 Organization: FSL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, If an entity is configured with three interface indices which is possible in generic scenarios(eg ethernet), that will result in three entries in peer table. Also another possibility is if we have multiple peers connected to a single interface(eg a broadcast lan) that will result in multiple entries of peer table. thanks and regards saumya -----Original Message----- From: Hans Sjostrand [SMTP:hans@ipunplugged.com] Sent: Tuesday, March 20, 2001 9:02 PM To: anilg@acc.am.ericsson.se; mpls@uu.net Subject: RE: ldp MIB No, the entity and the peer is one-to-one. Just because it's indexed this way, using the ldpId and the peers ldp id in the index it doesn't automatically imply a one to many relationship. On the contrary, the ldp session table is augmenting the ldp peer table and it's specifically a one-to-one relationship between entity and session, e.g. section 3.1 Overview "A table is used to configure potential LDP Sessions, where each row in the table initiates an LDP Session. This is the mplsLdpEntityTable" Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Anil > Gunturu > Sent: den 16 mars 2001 20:37 > To: mpls@UU.NET > Subject: ldp MIB > > > Hi, > I was wondering, if it is possible for an entry in the MplsLdpEntity table > there are multiple entries in the MplsPeerEntryTable? Looks like the MIB > allows it because the MplsLdpPeerEntry table is indexed by > mplsLdpEntityLdpId, mplsLdpEntityIndex and mplsLdpPeerLdpId. If it is > possible can some one give a practical scenario. > Thanks in advance for help, > -Anil > > Anil Gunturu, Software Engineer > Ericsson, Inc phone: (805) 562 6431 > Datacom & IP Services email: anilg@acc.am.ericsson.se > 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Wed Mar 21 01:22:00 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21255 for ; Wed, 21 Mar 2001 01:22:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhgr16461; Wed, 21 Mar 2001 06:21:03 GMT Received: by mail-control.mail.uu.net id QQkhgr13785 for mpls-outgoing; Wed, 21 Mar 2001 06:20:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhgr13776 for ; Wed, 21 Mar 2001 06:20:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhgr08751 for ; Wed, 21 Mar 2001 06:19:50 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkhgr05962 for ; Wed, 21 Mar 2001 06:19:48 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 21 Mar 2001 11:57:11 +0530 Received: from jananik (jananik.future.futsoft.com [10.0.6.90]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f2LBsX829958; Wed, 21 Mar 2001 17:24:35 +0530 Message-Id: <010901bd5623$c1666800$5a06000a@future.futsoft.com> From: "janani" To: Cc: Subject: doubts on RSVP-TE resv style Date: Mon, 23 Mar 1998 11:50:18 +0530 MIME-Version: 1.0 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 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01BD5651.D9BE29A0" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0106_01BD5651.D9BE29A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello, i am at present reading the draft "RSVP-TE: Extensions to RSVP for = LSP Tunnels (draft-ietf-mpls-rsvp-lsp-tunnel-07.txt)" i have the following doubts. 1.. in section 2.4.2., while explaining the Wildcard Filter (WF) = Reservation Style it is said that .."This style is useful for = applications in which not all senders send traffic at the same = time.......If,however, all senders send simultaneously, then there is no = means of getting the proper reservations made. Either the reserved = bandwidth on links close to the destination will be less than what is = required or then the reserved bandwidth on links close to some senders = will be greater than what is required. This restricts the applicability = of WF for traffic engineering purposes." =20 ..but what i feel is that the same overhead that is described above = could also apply for Shared Explicit Reservation style also. if i am = missing anything here could anyone point out the difference in the two = reservation styles ? 2. in the same section it is said that ".....because of the = merging rules of WF, EXPLICIT_ROUTE objects cannot be used with WF = reservations. " =20 can anyone point out the reason as to why WF resv style does not use = ERO. pointers to archives could aslo be sufficent. thanks and regards, janani. ------=_NextPart_000_0106_01BD5651.D9BE29A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello,
     i am at = present reading=20 the draft "RSVP-TE: Extensions to RSVP for LSP Tunnels=20 (draft-ietf-mpls-rsvp-lsp-tunnel-07.txt)"
i have the following = doubts.
  1.  in section 2.4.2., while=20 explaining the Wildcard Filter (WF) Reservation Style it is said that = .."This style is useful for applications in which not = all senders=20 send traffic at the same time.......If,however, all = senders send=20 simultaneously, then there is no means of getting the proper = reservations=20 made. Either the reserved bandwidth on links close to the destination = will be=20 less than what is required or then the reserved bandwidth on links = close to=20 some senders will be greater than what is required. This restricts the = applicability of WF for traffic engineering=20 purposes."
  
..but what i feel is that the same = overhead that is=20 described above could also apply for Shared Explicit Reservation = style=20 also. if i am missing anything here could anyone point out the = difference in the=20 two reservation styles ?
 
 
2.        = in the same=20 section it is said that ".....because of the merging = rules of WF,=20 EXPLICIT_ROUTE objects cannot be used with WF reservations.=20 "
 
can anyone point out the reason as to = why WF resv=20 style does not use ERO.
 pointers to archives could aslo = be=20 sufficent.
 
thanks and regards,
janani.
 
------=_NextPart_000_0106_01BD5651.D9BE29A0-- From owner-mpls@UU.NET Wed Mar 21 03:51:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08650 for ; Wed, 21 Mar 2001 03:51:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhhb26347; Wed, 21 Mar 2001 08:50:58 GMT Received: by mail-control.mail.uu.net id QQkhhb23747 for mpls-outgoing; Wed, 21 Mar 2001 08:50:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhhb23741 for ; Wed, 21 Mar 2001 08:50:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhhb17777 for ; Wed, 21 Mar 2001 08:49:07 GMT Received: from hclhprnd.hclt.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkhhb10711 for ; Wed, 21 Mar 2001 08:49:05 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id OAA05076; Wed, 21 Mar 2001 14:46:35 +0530 Received: from VIJAYC ([192.168.232.145]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2M299CZ; Wed, 21 Mar 2001 14:18:24 +0530 From: "Vijayanand Chandrasekar" To: =?iso-8859-1?Q?Hans_Sj=F6strand?= Cc: Subject: RE: ldp MIB Date: Wed, 21 Mar 2001 14:19:01 +0530 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkhhb26347 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA08650 IF there is a one to one correspondence between Entity and Session how will the entity be initialised. Should'nt each entity be configured initially with Label range, Label space, Targetted peer address etc, so that this info will be used for peer discovery and session establishment.The LdpId used in the PDU is that of the entity which should have been configured.If this is so then how can the number of sessions(hence entities) be known apriori, since this is as a result of peer discovery. Also, in the Entity Table the Enity Index is given as optional for implementations, what is the reason for this? Does it mean that we start of with an Enity configuration intially and for each new peer discovered and sesssion established the Entity Table is updated. Thanks in advance, Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Hans Sjöstrand Sent: Tuesday, March 20, 2001 3:32 PM To: anilg@acc.am.ericsson.se; mpls@UU.NET Subject: RE: ldp MIB No, the entity and the peer is one-to-one. Just because it's indexed this way, using the ldpId and the peers ldp id in the index it doesn't automatically imply a one to many relationship. On the contrary, the ldp session table is augmenting the ldp peer table and it's specifically a one-to-one relationship between entity and session, e.g. section 3.1 Overview "A table is used to configure potential LDP Sessions, where each row in the table initiates an LDP Session. This is the mplsLdpEntityTable" Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Anil > Gunturu > Sent: den 16 mars 2001 20:37 > To: mpls@UU.NET > Subject: ldp MIB > > > Hi, > I was wondering, if it is possible for an entry in the MplsLdpEntity table > there are multiple entries in the MplsPeerEntryTable? Looks like the MIB > allows it because the MplsLdpPeerEntry table is indexed by > mplsLdpEntityLdpId, mplsLdpEntityIndex and mplsLdpPeerLdpId. If it is > possible can some one give a practical scenario. > Thanks in advance for help, > -Anil > > Anil Gunturu, Software Engineer > Ericsson, Inc phone: (805) 562 6431 > Datacom & IP Services email: anilg@acc.am.ericsson.se > 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Wed Mar 21 10:07:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24280 for ; Wed, 21 Mar 2001 10:07:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhia22678; Wed, 21 Mar 2001 15:05:56 GMT Received: by mail-control.mail.uu.net id QQkhia06084 for mpls-outgoing; Wed, 21 Mar 2001 15:05:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhia05925 for ; Wed, 21 Mar 2001 15:04:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhia04159 for ; Wed, 21 Mar 2001 15:04:21 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkhia07322 for ; Wed, 21 Mar 2001 15:04:21 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 KAA10896 for ; Wed, 21 Mar 2001 10:04:19 -0500 (EST) 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 KAA02916 for ; Wed, 21 Mar 2001 10:04:21 -0500 (EST) Message-ID: <3AB8C300.62846F82@marconi.com> Date: Wed, 21 Mar 2001 10:04:32 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: doubts on RSVP-TE resv style References: <010901bd5623$c1666800$5a06000a@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 janani wrote: > > i am at present reading the draft "RSVP-TE: Extensions to RSVP > for LSP Tunnels (draft-ietf-mpls-rsvp-lsp-tunnel-07.txt)" > i have the following doubts. > > 1. in section 2.4.2., while explaining the Wildcard Filter (WF) > Reservation Style it is said that .."This style is useful for > applications in which not all senders send traffic at the same > time.......If,however, all senders send simultaneously, then > there is no means of getting the proper reservations made. Either > the reserved bandwidth on links close to the destination will be > less than what is required or then the reserved bandwidth on > links close to some senders will be greater than what is > required. This restricts the applicability of WF for traffic > engineering purposes." > > ..but what i feel is that the same overhead that is described above > could also apply for Shared Explicit Reservation style also. if i am > missing anything here could anyone point out the difference in the two > reservation styles ? WF style has no admission control. All packets that match the session information (IP destination for straight RSVP, tunnel egress for MPLS) must automatically get the reserved resources, regardless of sender information (IP source for straight RSVP, tunnel ingress for MPLS). This is diametrically opposite to the MPLS concept, where an ingress node decides which packets get the reserved resources (by way of the label), and transit routers forward them according to this label, regardless of the packet's content. > 2. in the same section it is said that ".....because of the > merging rules of WF, EXPLICIT_ROUTE objects cannot be used with WF > reservations. " > > can anyone point out the reason as to why WF resv style does not use > ERO. pointers to archives could aslo be sufficent. You can't wildcard-in all packets that match a destination if these packets are following an explicit route. Even conceptually, it is impossible. Once a packet is placed in an LSP, routers must forward them according to the label, and not according to anything else. -- David From owner-mpls@UU.NET Wed Mar 21 10:33:00 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26035 for ; Wed, 21 Mar 2001 10:32:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhic16719; Wed, 21 Mar 2001 15:31:16 GMT Received: by mail-control.mail.uu.net id QQkhic08591 for mpls-outgoing; Wed, 21 Mar 2001 15:30:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhic08584 for ; Wed, 21 Mar 2001 15:30:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhib19557 for ; Wed, 21 Mar 2001 15:29:14 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhib29334 for ; Wed, 21 Mar 2001 15:29:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA20689 for mpls@uu.net; Wed, 21 Mar 2001 10:29:12 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhib07971 for ; Wed, 21 Mar 2001 15:24:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhib10590 for ; Wed, 21 Mar 2001 15:24:28 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkhib23047 for ; Wed, 21 Mar 2001 15:24:27 GMT Received: from flefauch-8kcdt.cisco.com (sj-dial-3-195.cisco.com [171.68.180.196]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA07444; Wed, 21 Mar 2001 16:01:07 +0100 (MET) Message-Id: <200103211501.QAA07444@cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 21 Mar 2001 15:55:27 +0100 To: "Philip Matthews" From: Francois Le Faucheur Subject: Re: on its way ... Cc: Francois Le Faucheur , mpls@UU.NET In-Reply-To: <3AB2F50B.96D0DDCF@americasm01.nt.com> References: <200102091708.SAA29074@europe.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Philip, At 00:24 17/03/2001 -0500, Philip Matthews wrote: >Francois: > >Sorry, but I am a bit behind in my MPLS WG mailing list reading. >Back in February, you posted the following comment to the MPLS WG >mailing list. > > >Francois Le Faucheur wrote: >> Subsequent to the MPLS WG Last Call, a special Diff-Serv WG Last Call was >> issued on at the request of the Area >> Directors. >> >> We received comments relating to two items. Below are the details of the >> planned resolution for both items. > >..snip ... > >> Incoming PHB Determination with Pipe Model >> =========================================== >> We received pretty much the same comment from several people (Service >> Providers as well as vendors) on one detailed aspect of the Pipe model: >> output scheduling at egress of a Pipe LSP. >> "xx-07.txt" specifies that, in the Pipe model, the egress LSR does incoming >> PHB determination based on the "inner header" (ie after the POP). We plan to: >> - keep such a behavior, but make it an optional variation of the Pipe model >> - define an alternative behavior where the egress LSR does incoming PHB >> determination based on the "outer header" (ie before the POP). This will be >> the normal egress behavior for the Pipe Model. >> All the other aspects of the Pipe model are unchanged. >> >> The rationale for using "outer header" by default on egress of Pipe is the >> following: >> - the typical application of the Pipe model is where a Service Provider >> (SP) transports traffic from a customer who uses a different Diff-Serv >> policy to the SP's Diff-Serv policy. Doing scheduling on LSP Egress based >> on the outer header (and assuming no PHP) allows the Service Provider to >> configure scheduling based on its own Diff-Serv policy. Doing scheduling >> based on the inner header forces the Service Provider to be aware of each >> and every customer Diff-Serv policy and forces the SP to configure >> scheduling differently for each customer Diff-Serv policy. The most common >> situation will be that the SP does not want to be even aware of the >> Customer Diff-Serv policy and thus need to use the outer header. >> (There will be cases where the SP may accept the operational overhead of >> being aware of the customer's Diff-Serv policy and sell "egress scheduling >> based on customer's policy" as a value add; this is why we keep the use of >> inner header as an option. But this will be less common.) > >It seems very strange to me to schedule the packet based on the outer header, >but forward the packet based on the inner header. > From a Service Provider's viewpoint this is not strange at all. It simply means that the SP will be doing scheduling on the egress interface based on his Diff-Serv policy rather than on one of many many different end-customer's own Diff-Serv policy. Typically, the "pipe" model is precisely used so that the end-customer's Diff-SErv policy is hidden from SP and vice-versa. So , often, the SP has no idea whatsoever about what EXP=eee means in the inner header. Really, the PIpe Model can be looked at as extending the SP Diff-SErv policy right through to the egress interface of the egress LSR (wheras with the Short PIpe, the egress interface of egress LSR should be looked at as within the end-customer Diff-Serv domain). From my discussions with SPs, by and large, they prefer the model where they run their own Diff-Serv policy on all egress interfaces rather than one differnet Diff-Serv policy on every egress interface. Cheers Francois >This solution seems particularly strange to me when the router is popping >two or more labels; that is, terminating two or more pipe-model LSPs at once. >In this case, using the outermost header seems particularly arbitrary. > >I make these comments while in the middle of implementing this draft. >The way it was before makes for a very logical implementation, while this >new proposal will add some weirdness. > >It seems to me that what the service providers really want is a form of PHP: >that is, they want to both schedule and forward the packet based on the outer >header, but pop the header just before forwarding the packet. > >Comments? > >- Philip Matthews > Nortel Networks > From owner-mpls@UU.NET Wed Mar 21 11:29:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28674 for ; Wed, 21 Mar 2001 11:29:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhif24689; Wed, 21 Mar 2001 16:27:17 GMT Received: by mail-control.mail.uu.net id QQkhif28763 for mpls-outgoing; Wed, 21 Mar 2001 16:26:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhif28755 for ; Wed, 21 Mar 2001 16:26:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhif28921 for ; Wed, 21 Mar 2001 16:26:17 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkhif19783 for ; Wed, 21 Mar 2001 16:26:17 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f2LGQ5R16258; Wed, 21 Mar 2001 11:26:13 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; WED, 21 Mar 2001 11:23:01 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Mar 2001 11:23:01 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E5659A194@newman.tenornet.com> From: "Arvind, K" To: "'lberger@movaz.com'" , "'swallow@cisco.com'" Cc: "'mpls@uu.net'" Subject: Section 5.5 of ietf-mpls-rsvp-lsp-tunnel-08.txt Date: Wed, 21 Mar 2001 11:23:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Lou, George: The following change doesn't seem to have made it into this version of the draft. The clause "or will respond with an 'Unknown Object Class' error" still appears in the second paragraph of this section. It was agreed earlier (http://cell-relay.indiana.edu/mhonarc/mpls/2000-Oct/msg00031.html) that this clause should be dropped. Regards, Arvind. From owner-mpls@UU.NET Wed Mar 21 18:57:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24206 for ; Wed, 21 Mar 2001 18:57:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhjj22905; Wed, 21 Mar 2001 23:55:26 GMT Received: by mail-control.mail.uu.net id QQkhjj20154 for mpls-outgoing; Wed, 21 Mar 2001 23:54:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhjj20147 for ; Wed, 21 Mar 2001 23:54:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhjj13091 for ; Wed, 21 Mar 2001 23:54:15 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host100.pluris.com [208.227.9.100]) id QQkhjj23625 for ; Wed, 21 Mar 2001 23:54:14 GMT Received: from [172.16.55.198] ([172.16.55.198]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id PAA11154; Wed, 21 Mar 2001 15:54:07 -0800 (PST) Mime-Version: 1.0 X-Sender: akyol@avalon Message-Id: Date: Wed, 21 Mar 2001 15:53:22 -0800 To: af@dataconnection.com From: Bora Akyol Subject: LDP-FT Question Cc: mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk Adrian I would like to suggest that the draft use a sequence number in place of the FT_ Reconnect_Flag. A sequence number that is updated every time FT data is changed and agreed upon by both sides (FT-pair) will offer better protection than a single flag especially if both router reboot within a time window. What do you think? Bora From owner-mpls@UU.NET Wed Mar 21 21:46:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03797 for ; Wed, 21 Mar 2001 21:46:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhjv24881; Thu, 22 Mar 2001 02:45:30 GMT Received: by mail-control.mail.uu.net id QQkhju17546 for mpls-outgoing; Thu, 22 Mar 2001 02:44:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhju17540 for ; Thu, 22 Mar 2001 02:44:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhju23454; Thu, 22 Mar 2001 02:44:30 GMT Received: from mason2.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkhju20749; Thu, 22 Mar 2001 02:44:30 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id VAA18588; Wed, 21 Mar 2001 21:44:28 -0500 (EST) Date: Wed, 21 Mar 2001 21:44:28 -0500 (EST) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: sk@southernstar.com cc: mpls@UU.NET, te-wg@UU.NET Subject: RE: Books/Articles on Traffic Engineering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi! I would say that RFC 2702 would be a nice start for you as it talks about various requirements for Traffic Engineering over MPLS. Also you might want to visit Daniel Awduche's website for more articles on Traffic Engineering at http://www.awduche.com. Thanks. -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** Date: 21 Mar 2001 15:54:36 -0800 From: sk@southernstar.com To: mpls@UU.NET, te-wg@UU.NET Subject: Books/Articles on Traffic Engineering Does anyone know any good books/articles on traffic engineering? Thanks -SK From owner-mpls@UU.NET Wed Mar 21 22:10:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04888 for ; Wed, 21 Mar 2001 22:10:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhjw22809; Thu, 22 Mar 2001 03:08:33 GMT Received: by mail-control.mail.uu.net id QQkhjw04707 for mpls-outgoing; Thu, 22 Mar 2001 03:07:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhjw04626 for ; Thu, 22 Mar 2001 03:07:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhjw20334 for ; Thu, 22 Mar 2001 03:06:06 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhjw14925 for ; Thu, 22 Mar 2001 03:06:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA08634 for mpls@uu.net; Wed, 21 Mar 2001 22:06:04 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhjw03958 for ; Thu, 22 Mar 2001 03:05:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhjw20124; Thu, 22 Mar 2001 03:03:38 GMT Received: from mail-blue.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQkhjw18826; Thu, 22 Mar 2001 03:03:37 GMT Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 9D70F4CE1E; Wed, 21 Mar 2001 22:03:37 -0500 (EST) Received: from chips.research.att.com (chips.research.att.com [135.207.27.139]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id WAA10585; Wed, 21 Mar 2001 22:03:33 -0500 (EST) Received: (from jrex@localhost) by chips.research.att.com (SGI-8.9.3/8.8.5) id WAA22783; Wed, 21 Mar 2001 22:03:32 -0500 (EST) Date: Wed, 21 Mar 2001 22:03:32 -0500 (EST) Message-Id: <200103220303.WAA22783@chips.research.att.com> From: Jennifer Rexford To: sk@southernstar.com Cc: mpls@UU.NET, te-wg@UU.NET Subject: Re: Books/Articles on Traffic Engineering Sender: owner-mpls@UU.NET Precedence: bulk > Does anyone know any good books/articles on traffic engineering? See the March 2000 issue of IEEE Network Magazine at http://www.comsoc.org/ni/public/2000/mar/index.html and the working-group charter at http://www.ietf.org/html.charters/tewg-charter.html and the (expired) framework Internet Draft at http://info.broker.isi.edu/0/in-drafts/files/draft-ietf-tewg-framework-02.txt -- Jennifer http://www.research.att.com/~jrex From owner-mpls@UU.NET Wed Mar 21 23:00:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08152 for ; Wed, 21 Mar 2001 23:00:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhjz10908; Thu, 22 Mar 2001 03:59:23 GMT Received: by mail-control.mail.uu.net id QQkhjz08202 for mpls-outgoing; Thu, 22 Mar 2001 03:58:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhjz08194 for ; Thu, 22 Mar 2001 03:58:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhjz24014; Thu, 22 Mar 2001 03:57:55 GMT Received: from bgslc02.TBG.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQkhjz07434; Thu, 22 Mar 2001 03:57:55 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Mar 2001 20:47:00 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE70146D82C@BGSLC02> From: Irwin Lazar To: sk@southernstar.com Cc: mpls@UU.NET, te-wg@UU.NET Subject: RE: Books/Articles on Traffic Engineering Date: Wed, 21 Mar 2001 20:46: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 > Does anyone know any good books/articles on traffic > engineering? > > Thanks > -SK Please see www.mplsrc.com/articles.shtml for links to about half a dozen articles on MPLS-TE. Irwin From owner-mpls@UU.NET Wed Mar 21 23:45:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10880 for ; Wed, 21 Mar 2001 23:45:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkc27845; Thu, 22 Mar 2001 04:44:45 GMT Received: by mail-control.mail.uu.net id QQkhkc26640 for mpls-outgoing; Thu, 22 Mar 2001 04:44:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhkc26630 for ; Thu, 22 Mar 2001 04:44:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhkc18488; Thu, 22 Mar 2001 04:43:44 GMT Received: from mason2.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkhkc05070; Thu, 22 Mar 2001 04:43:43 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id XAA23906; Wed, 21 Mar 2001 23:29:11 -0500 (EST) Date: Wed, 21 Mar 2001 23:29:11 -0500 (EST) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: soohyunc@etri.re.kr cc: sk@southernstar.com, mpls@UU.NET, te-wg@UU.NET Subject: Re: Books/Articles on Traffic Engineering In-Reply-To: <002701c0b27c$be305020$92feffcb@etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I believe the webpage is temporarily down and will be up soon. You might also want to look at the following URL where you will find a couple of good tutorials on MPLS traffic engineering. http://www.ail.gmu.edu/MPLS2000/proceedings/default.htm Happy reading! -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** On Thu, 22 Mar 2001 soohyunc@etri.re.kr wrote: > Hi, all~ > > I've been aware of the Daniel Awduche's website for ages. > But, the server may have been dead for these days. > Anyone happen to meet same problem with me? > or it is just for me? > > Does anyone know the mirror site for that? > or any other recommendation? > > SH-- > ------------------------------ > Soo-Hyun Choi > Dept. of Internet Technology > Network Technology Lab. > ETRI (Elec. & Telecom. Research Inst.) > > Office: +82.42.860.5607 > Mobile: +82.16.712.9571 > Fax: +82.42.860.5440 > E-mail: soohyunc@etri.re.kr > ------------------------------ > > > ----- Original Message ----- > From: "Rajiv Papneja" > To: > Cc: ; > Sent: Thursday, March 22, 2001 11:44 AM > Subject: RE: Books/Articles on Traffic Engineering > > > > Hi! > > > > I would say that RFC 2702 would be a nice start for you as it talks about > > various requirements for Traffic Engineering over MPLS. Also you might > > want to visit Daniel Awduche's website for more articles on Traffic > > Engineering at http://www.awduche.com. Thanks. > > > > -Rajiv > > > > Date: 21 Mar 2001 15:54:36 -0800 > > From: sk@southernstar.com > > To: mpls@UU.NET, te-wg@UU.NET > > Subject: Books/Articles on Traffic Engineering > > > > Does anyone know any good books/articles on traffic > > engineering? > > > > Thanks > > -SK > > > > > > > From owner-mpls@UU.NET Thu Mar 22 03:09:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03347 for ; Thu, 22 Mar 2001 03:09:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkq04658; Thu, 22 Mar 2001 08:08:14 GMT Received: by mail-control.mail.uu.net id QQkhkq11379 for mpls-outgoing; Thu, 22 Mar 2001 08:07:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhkq11353 for ; Thu, 22 Mar 2001 08:07:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhkq29515 for ; Thu, 22 Mar 2001 08:07:07 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhkq01027 for ; Thu, 22 Mar 2001 08:07:06 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 AAA29259 for ; Thu, 22 Mar 2001 00:07:26 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00768 for mpls@uu.net; Thu, 22 Mar 2001 03:07:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhjj20156 for ; Wed, 21 Mar 2001 23:54:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhjj14005 for ; Wed, 21 Mar 2001 23:54:38 GMT From: sk@southernstar.com Received: from c000.snv.cp.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: c000-h011.c000.snv.cp.net [209.228.32.75]) id QQkhjj20557 for ; Wed, 21 Mar 2001 23:54:37 GMT Received: (cpmta 13488 invoked from network); 21 Mar 2001 15:54:36 -0800 Date: 21 Mar 2001 15:54:36 -0800 Message-ID: <20010321235436.13487.cpmta@c000.snv.cp.net> X-Sent: 21 Mar 2001 23:54:36 GMT Received: from [66.1.144.153] by mail.southernstar.com with HTTP; 21 Mar 2001 15:54:36 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: mpls@UU.NET, te-wg@UU.NET X-Mailer: Web Mail 3.7.1.9 Subject: Books/Articles on Traffic Engineering Sender: owner-mpls@UU.NET Precedence: bulk Does anyone know any good books/articles on traffic engineering? Thanks -SK From owner-mpls@UU.NET Thu Mar 22 03:10:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03419 for ; Thu, 22 Mar 2001 03:10:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkq12221; Thu, 22 Mar 2001 08:10:14 GMT Received: by mail-control.mail.uu.net id QQkhkq11489 for mpls-outgoing; Thu, 22 Mar 2001 08:09:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhkq11464 for ; Thu, 22 Mar 2001 08:08:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhkq14154 for ; Thu, 22 Mar 2001 08:07:06 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhkq11233 for ; Thu, 22 Mar 2001 08:07: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 AAA23784 for ; Thu, 22 Mar 2001 00:07:04 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00764 for mpls@uu.net; Thu, 22 Mar 2001 03:07:04 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhjj20156 for ; Wed, 21 Mar 2001 23:54:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhjj14005 for ; Wed, 21 Mar 2001 23:54:38 GMT From: sk@southernstar.com Received: from c000.snv.cp.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: c000-h011.c000.snv.cp.net [209.228.32.75]) id QQkhjj20557 for ; Wed, 21 Mar 2001 23:54:37 GMT Received: (cpmta 13488 invoked from network); 21 Mar 2001 15:54:36 -0800 Date: 21 Mar 2001 15:54:36 -0800 Message-ID: <20010321235436.13487.cpmta@c000.snv.cp.net> X-Sent: 21 Mar 2001 23:54:36 GMT Received: from [66.1.144.153] by mail.southernstar.com with HTTP; 21 Mar 2001 15:54:36 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: mpls@UU.NET, te-wg@UU.NET X-Mailer: Web Mail 3.7.1.9 Subject: Books/Articles on Traffic Engineering Sender: owner-mpls@UU.NET Precedence: bulk Does anyone know any good books/articles on traffic engineering? Thanks -SK From owner-mpls@UU.NET Thu Mar 22 03:13:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03547 for ; Thu, 22 Mar 2001 03:13:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkq14872; Thu, 22 Mar 2001 08:11:36 GMT Received: by mail-control.mail.uu.net id QQkhkq11492 for mpls-outgoing; Thu, 22 Mar 2001 08:09:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhkq11468 for ; Thu, 22 Mar 2001 08:08:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhkq14508 for ; Thu, 22 Mar 2001 08:07:15 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhkq01581 for ; Thu, 22 Mar 2001 08:07:15 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 AAA29289 for ; Thu, 22 Mar 2001 00:07:35 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00776 for mpls@uu.net; Thu, 22 Mar 2001 03:07:13 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhkb25425 for ; Thu, 22 Mar 2001 04:19:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhkb01533 for ; Thu, 22 Mar 2001 04:18:52 GMT Received: from mail10.speakeasy.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail10.speakeasy.net [216.254.0.210]) id QQkhkb26243 for ; Thu, 22 Mar 2001 04:18:52 GMT Received: (qmail 91972 invoked from network); 22 Mar 2001 04:18:51 -0000 Received: from unknown (HELO speakeasy.net) ([64.81.69.143]) (envelope-sender ) by mail10.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Mar 2001 04:18:51 -0000 Message-ID: <3AB97DE2.99672D58@speakeasy.net> Date: Wed, 21 Mar 2001 20:21:54 -0800 From: Zheng Wang Reply-To: zheng@wang.net X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: sk@southernstar.com CC: mpls@UU.NET, te-wg@UU.NET Subject: Re: Books/Articles on Traffic Engineering Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Does anyone know any good books/articles on traffic > engineering? I recently published a book "Internet QoS: Architectures and Mechanisms" which has one chapter on traffic engineering and route optimization mechanisms. You can find the table of content at http://www.bookshelf.org/qos/toc.html Cheers Zheng From owner-mpls@UU.NET Thu Mar 22 03:14:16 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03570 for ; Thu, 22 Mar 2001 03:14:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkq20498; Thu, 22 Mar 2001 08:13:43 GMT Received: by mail-control.mail.uu.net id QQkhkq11504 for mpls-outgoing; Thu, 22 Mar 2001 08:09:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhkq11469 for ; Thu, 22 Mar 2001 08:08:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhkq13953 for ; Thu, 22 Mar 2001 08:07:01 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhkq00593 for ; Thu, 22 Mar 2001 08:07:00 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 AAA29212 for ; Thu, 22 Mar 2001 00:07:20 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00756 for mpls@uu.net; Thu, 22 Mar 2001 03:06:59 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhit01451 for ; Wed, 21 Mar 2001 19:55:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhit21752 for ; Wed, 21 Mar 2001 19:53:54 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f83.law10.hotmail.com [64.4.15.83]) id QQkhit00216 for ; Wed, 21 Mar 2001 19:53:54 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Mar 2001 11:53:53 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 21 Mar 2001 19:53:53 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: mpls@UU.NET Cc: gash@att.com, petera@NortelNetworks.com, jamoussi@NortelNetworks.com, fedyk@NortelNetworks.com, skalecki@NortelNetworks.com, lili@ss8networks.com, ylee@irislabs.com Subject: Feedback regarding draft "draft-ietf-mpls-crlsp-modify-03.txt" Date: Wed, 21 Mar 2001 12:53:53 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2001 19:53:53.0678 (UTC) FILETIME=[A83FD2E0:01C0B240] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I have certain comments regarding draft "draft-ietf-mpls-crlsp-modify-03.txt". LSP modification should be limited to modification in bandwidth and holding priority of already active LSP. I don't foresee any application for re-route capability. If we compare the modification procedures to already exisiting modification procedures in various call control protocols viz. ISDN, ATM and GSM, these protocols allow in bandwidth modification only. Those procedures don't allow for re-routing. For re-routing u have to establish another path which is treated as a complete new request. Is there any specific reason why re-routeing has been thought of as a part of modification. I think we should define messages like LSP modify Request and LSP modify complete/LSP modify reject for modification. These modify messages should take the same signalling path as of original LSP establishment messages. Is not everbody overloading the Label Request/Label Mapping messages for everything (i.e keeping the same set of messages even for O-UNI) ? Please comment on this. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Thu Mar 22 03:14:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03591 for ; Thu, 22 Mar 2001 03:14:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkq17680; Thu, 22 Mar 2001 08:12:38 GMT Received: by mail-control.mail.uu.net id QQkhkq11495 for mpls-outgoing; Thu, 22 Mar 2001 08:09:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhkq11462 for ; Thu, 22 Mar 2001 08:08:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhkq21109 for ; Thu, 22 Mar 2001 08:07:03 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhkq00771 for ; Thu, 22 Mar 2001 08:07:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA29232 for ; Thu, 22 Mar 2001 00:07:23 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00760 for mpls@uu.net; Thu, 22 Mar 2001 03:07:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhjg16951 for ; Wed, 21 Mar 2001 23:06:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhjg14384 for ; Wed, 21 Mar 2001 23:06:13 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f8.law10.hotmail.com [64.4.15.8]) id QQkhjg09417 for ; Wed, 21 Mar 2001 23:06:13 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Mar 2001 15:06:12 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 21 Mar 2001 23:06:12 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: mpls@UU.NET Cc: gash@att.com, petera@NortelNetworks.com, jamoussi@NortelNetworks.com, fedyk@NortelNetworks.com, skalecki@NortelNetworks.com, lili@ss8networks.com, ylee@irislabs.com Subject: Valid Race Condition related to draft "draft-ietf-mpls-crlsp-modify-03.txt" Date: Wed, 21 Mar 2001 16:06:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2001 23:06:12.0170 (UTC) FILETIME=[85B9FAA0:01C0B25B] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, Please comment on the following : If the LSP modification is in progress and in the meantime the next hop for the same LSP changes then should the modification procedure be aborted ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Thu Mar 22 03:15:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03677 for ; Thu, 22 Mar 2001 03:15:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkq24052; Thu, 22 Mar 2001 08:14:51 GMT Received: by mail-control.mail.uu.net id QQkhkq11510 for mpls-outgoing; Thu, 22 Mar 2001 08:09:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhkq11465 for ; Thu, 22 Mar 2001 08:08:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhkq21521 for ; Thu, 22 Mar 2001 08:07:12 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhkq11522 for ; Thu, 22 Mar 2001 08:07:12 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id AAA23809 for ; Thu, 22 Mar 2001 00:07:11 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00772 for mpls@uu.net; Thu, 22 Mar 2001 03:07:10 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhjw03661 for ; Thu, 22 Mar 2001 03:04:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhjw27352; Thu, 22 Mar 2001 03:04:33 GMT From: soohyunc@etri.re.kr Received: from cms1.etri.re.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cms1.etri.re.kr [129.254.16.11]) id QQkhjw09354; Thu, 22 Mar 2001 03:04:32 GMT Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Mar 2001 12:05:22 +0900 Received: from soohyunc (soohyunc.etri.re.kr [129.254.191.33]) by cms3.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H282VKN6; Thu, 22 Mar 2001 12:04:34 +0900 To: rpapneja@osf1.gmu.edu, sk@southernstar.com Cc: mpls@UU.NET, te-wg@UU.NET Message-ID: <002701c0b27c$be305020$92feffcb@etri.re.kr> References: Subject: Re: Books/Articles on Traffic Engineering Date: Thu, 22 Mar 2001 12:04:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, all~ I've been aware of the Daniel Awduche's website for ages. But, the server may have been dead for these days. Anyone happen to meet same problem with me? or it is just for me? Does anyone know the mirror site for that? or any other recommendation? SH-- ------------------------------ Soo-Hyun Choi Dept. of Internet Technology Network Technology Lab. ETRI (Elec. & Telecom. Research Inst.) Office: +82.42.860.5607 Mobile: +82.16.712.9571 Fax: +82.42.860.5440 E-mail: soohyunc@etri.re.kr ------------------------------ ----- Original Message ----- From: "Rajiv Papneja" To: Cc: ; Sent: Thursday, March 22, 2001 11:44 AM Subject: RE: Books/Articles on Traffic Engineering > Hi! > > I would say that RFC 2702 would be a nice start for you as it talks about > various requirements for Traffic Engineering over MPLS. Also you might > want to visit Daniel Awduche's website for more articles on Traffic > Engineering at http://www.awduche.com. Thanks. > > -Rajiv > > ******************************** > Rajiv Papneja (GRA) > Advanced Internet Laboratory > George Mason University, > G10, Johnson Center, > Fairfax, VA 22030-4444 > Tel: 703.993.4703 > email: rpapneja@osf1.gmu.edu > ******************************** > > > Date: 21 Mar 2001 15:54:36 -0800 > From: sk@southernstar.com > To: mpls@UU.NET, te-wg@UU.NET > Subject: Books/Articles on Traffic Engineering > > Does anyone know any good books/articles on traffic > engineering? > > Thanks > -SK > > > From owner-mpls@UU.NET Thu Mar 22 03:16:51 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03755 for ; Thu, 22 Mar 2001 03:16:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkr28660; Thu, 22 Mar 2001 08:16:28 GMT Received: by mail-control.mail.uu.net id QQkhkq11513 for mpls-outgoing; Thu, 22 Mar 2001 08:09:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhkq11445 for ; Thu, 22 Mar 2001 08:08:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhkq25849 for ; Thu, 22 Mar 2001 08:07:19 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkhkq01793 for ; Thu, 22 Mar 2001 08:07:17 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 AAA29302 for ; Thu, 22 Mar 2001 00:07:37 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00780 for mpls@uu.net; Thu, 22 Mar 2001 03:07:16 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhkc26394 for ; Thu, 22 Mar 2001 04:41:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhkc07221; Thu, 22 Mar 2001 04:40:58 GMT Received: from zcamail05.zca.compaq.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcamail05.zca.compaq.com [161.114.32.105]) id QQkhkc26588; Thu, 22 Mar 2001 04:40:58 GMT Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id E6E301E3; Wed, 21 Mar 2001 20:43:17 -0800 (PST) Received: from excsin-gh02.asia.compaq.com (excsin-gh02.asia.compaq.com [16.177.2.8]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 697A82E4; Wed, 21 Mar 2001 20:43:15 -0800 (PST) Received: by excsin-gh02.asia.compaq.com with Internet Mail Service (5.5.2652.78) id ; Thu, 22 Mar 2001 12:40:52 +0800 Message-ID: <9D5A8F73D0FCD211BF710008C72486526ECE91@excind-bgl02.in.cpqcorp.net> From: "Mukherjee, Avijeet" To: "'soohyunc@etri.re.kr'" , rpapneja@osf1.gmu.edu, sk@southernstar.com Cc: mpls@UU.NET, te-wg@UU.NET Subject: RE: Books/Articles on Traffic Engineering Date: Thu, 22 Mar 2001 12:37:32 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Same problem here , Does it exist ? -----Original Message----- From: soohyunc@etri.re.kr [mailto:soohyunc@etri.re.kr] Sent: Thursday, March 22, 2001 8:34 AM To: rpapneja@osf1.gmu.edu; sk@southernstar.com Cc: mpls@UU.NET; te-wg@UU.NET Subject: Re: Books/Articles on Traffic Engineering Hi, all~ I've been aware of the Daniel Awduche's website for ages. But, the server may have been dead for these days. Anyone happen to meet same problem with me? or it is just for me? Does anyone know the mirror site for that? or any other recommendation? SH-- ------------------------------ Soo-Hyun Choi Dept. of Internet Technology Network Technology Lab. ETRI (Elec. & Telecom. Research Inst.) Office: +82.42.860.5607 Mobile: +82.16.712.9571 Fax: +82.42.860.5440 E-mail: soohyunc@etri.re.kr ------------------------------ ----- Original Message ----- From: "Rajiv Papneja" To: Cc: ; Sent: Thursday, March 22, 2001 11:44 AM Subject: RE: Books/Articles on Traffic Engineering > Hi! > > I would say that RFC 2702 would be a nice start for you as it talks about > various requirements for Traffic Engineering over MPLS. Also you might > want to visit Daniel Awduche's website for more articles on Traffic > Engineering at http://www.awduche.com. Thanks. > > -Rajiv > > ******************************** > Rajiv Papneja (GRA) > Advanced Internet Laboratory > George Mason University, > G10, Johnson Center, > Fairfax, VA 22030-4444 > Tel: 703.993.4703 > email: rpapneja@osf1.gmu.edu > ******************************** > > > Date: 21 Mar 2001 15:54:36 -0800 > From: sk@southernstar.com > To: mpls@UU.NET, te-wg@UU.NET > Subject: Books/Articles on Traffic Engineering > > Does anyone know any good books/articles on traffic > engineering? > > Thanks > -SK > > > From owner-mpls@UU.NET Thu Mar 22 03:18:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03828 for ; Thu, 22 Mar 2001 03:18:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkr03167; Thu, 22 Mar 2001 08:17:46 GMT Received: by mail-control.mail.uu.net id QQkhkq11523 for mpls-outgoing; Thu, 22 Mar 2001 08:09:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhkq11451 for ; Thu, 22 Mar 2001 08:08:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhkq24766 for ; Thu, 22 Mar 2001 08:06:55 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhkq10835 for ; Thu, 22 Mar 2001 08:06: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 AAA23719 for ; Thu, 22 Mar 2001 00:06:53 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00747 for mpls@uu.net; Thu, 22 Mar 2001 03:06:53 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhgx04457 for ; Wed, 21 Mar 2001 07:46:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhgx02878 for ; Wed, 21 Mar 2001 07:45:04 GMT Received: from smtp.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQkhgw26117 for ; Wed, 21 Mar 2001 07:44:31 GMT Received: from tom ([10.110.9.163]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GAJEN602.U1T; Wed, 21 Mar 2001 15:40:18 +0800 Message-ID: <001701c0b1da$d644e4c0$a3096e0a@tom.huawei.com> From: "zhang" To: "Eric Gray" Cc: Subject: =?iso-8859-1?B?u9i4tDogaGVscCBmb3IgQ1ItTERQ?= Date: Wed, 21 Mar 2001 15:44:51 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C0B21D.DE7243C0" 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_0012_01C0B21D.DE7243C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric Gray please give me a example"This node is not the end of the LSP.", and = according what the node adds new explicit route? -----Original Message----- =B7=A2=BC=FE=C8=CB: Eric Gray =CA=D5=BC=FE=C8=CB: zhang =B3=AD=CB=CD: mpls@UU.NET =C8=D5=C6=DA: 2001=C4=EA3=D4=C28=C8=D5 22:32 =D6=F7=CC=E2: Re: help for CR-LDP =20 =20 Zhang,=20 You use an Explicit Route to designate nodes you want=20 included in an LSP. That's all. Practical uses of the ERO=20 currently tend to include the egress from an MPLS domain,=20 but there may be TE applications (for example) that benefit=20 from the increased dynamism of having an ERO that only=20 specifies some hop toward the middle of the MPLS cloud.=20 --=20 Eric Gray=20 You wrote:=20 Dear Mr.(Mrs), Please help me for a question about algorithem = ofselection of the next hop. In 4.8.1 selection of the next hop = 2. If there is no second ER-HOP, this indicates the end of the = explicit route. The explicit route TLV should be removed from the = Label Request Message. This node may or may not be the end of the LSP. = Processing continues with section 4.8.2, where a new explicit route = TLV may be added to the Label Request Message. But why "This node may = or may not be the end of the LSP."? RegardsZhang. ------=_NextPart_000_0012_01C0B21D.DE7243C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Eric = Gray
please give = me a example"This node=20 is not the end of the LSP.", and according what
  the=20 node adds new explicit route?
-----Original=20 Message-----
·¢¼þÈË: = Eric=20 Gray <eric.gray@sandburst.com>ÊÕ¼þÈË:=20 zhang <zhanghuachen@huawei.com>³­ËÍ:=20 mpls@UU.NET <mpls@UU.NET>
ÈÕ&AE= lig;Ú:=20 2001Äê3ÔÂ8ÈÕ=20 22:32
Ö÷Ìâ: Re: help for=20 CR-LDP

Zhang,=20

    You use an Explicit Route to designate nodes = you want=20
included in an LSP.  That's all.  Practical uses of = the ERO=20
currently tend to include the egress from an MPLS domain, =
but there=20 may be TE applications (for example) that benefit
from the = increased=20 dynamism of having an ERO that only
specifies some hop toward = the middle=20 of the MPLS cloud.=20

--
Eric Gray=20

You wrote:=20

 Dear Mr.(Mrs),  Please help me for a = question about=20 algorithem ofselection of the next=20 hop.  In 4.8.1 selection of the next=20 hop       2. If there is no = second=20 ER-HOP, this indicates the end of   the = explicit=20 route. The explicit route TLV should be=20 removed   from the Label Request Message. This node = may or=20 may not   be the end of the LSP. Processing = continues with=20 section   4.8.2, where a new explicit route TLV may = be added=20 to the   Label Request=20 Message. But why "This node may or = may not be=20 the end of the LSP."? RegardsZhang.
------=_NextPart_000_0012_01C0B21D.DE7243C0-- From owner-mpls@UU.NET Thu Mar 22 03:19:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03908 for ; Thu, 22 Mar 2001 03:19:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkr06750; Thu, 22 Mar 2001 08:18:57 GMT Received: by mail-control.mail.uu.net id QQkhkq11533 for mpls-outgoing; Thu, 22 Mar 2001 08:09:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhkq11466 for ; Thu, 22 Mar 2001 08:08:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhkq20908 for ; Thu, 22 Mar 2001 08:06:59 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhkq11009 for ; Thu, 22 Mar 2001 08:06:58 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id AAA23743 for ; Thu, 22 Mar 2001 00:06:58 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id DAA00752 for mpls@uu.net; Thu, 22 Mar 2001 03:06:57 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhik20198 for ; Wed, 21 Mar 2001 17:44:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhik08830 for ; Wed, 21 Mar 2001 17:43:08 GMT Received: from usrsrv1.meeting.ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.meeting.ietf.org [135.222.20.40]) id QQkhik24425 for ; Wed, 21 Mar 2001 17:43:08 GMT Received: from sandburst.com (pcp008487pcs.desktop.meeting.ietf.org [135.222.3.46]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with ESMTP id f2LHglw12213; Wed, 21 Mar 2001 11:42:47 -0600 (CST) Message-ID: <3AB8F5AF.70FFFA7F@sandburst.com> Date: Wed, 21 Mar 2001 11:40:47 -0700 From: ietf X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: zhang CC: Eric Gray , mpls@UU.NET Subject: Re: =?iso-8859-1?Q?=BB=D8=B8=B4?=: help for CR-LDP References: <001701c0b1da$d644e4c0$a3096e0a@tom.huawei.com> Content-Type: multipart/alternative; boundary="------------7C6194C6AB00456155A1DB68" Sender: owner-mpls@UU.NET Precedence: bulk --------------7C6194C6AB00456155A1DB68 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkhkr06750 Content-Transfer-Encoding: quoted-printable Zhang, A simple example (like I said, no one may do this in practice). I could simply decide to releave a node that is congested by deliberately routing traffic toward another node that is not. There may be lots of ways to ensure that the redirected traffic does not still end up traversing the congested node without explicitly excluding it (by explicitly listing all included nodes) in any ERO. To do this, I should be able to specify an explicit route that only contains the desired alternate node as a loose hop. In practice, this is not noticeably different from simply terminating the TE LSP at that node. -- Eric Gray zhang wrote: > Eric Grayplease give me a example"This node is not the end of the > LSP.", and according what the node adds new explicit route? > > -----Original Message----- > =B7=A2=BC=FE=C8=CB: Eric Gray > =CA=D5=BC=FE=C8=CB: zhang > =B3=AD=CB=CD: mpls@UU.NET > =C8=D5=C6=DA: 2001=C4=EA3=D4=C28=C8=D5 22:32 > =D6=F7=CC=E2: Re: help for CR-LDP > Zhang, > > You use an Explicit Route to designate nodes you want > included in an LSP. That's all. Practical uses of the ERO > currently tend to include the egress from an MPLS domain, > but there may be TE applications (for example) that benefit > from the increased dynamism of having an ERO that only > specifies some hop toward the middle of the MPLS cloud. > > -- > Eric Gray > > You wrote: > > > Dear Mr.(Mrs), Please help me for a question about > > algorithem ofselection of the next hop. In 4.8.1 > > selection of the next hop 2. If there is no second > > ER-HOP, this indicates the end of the explicit route. > > The explicit route TLV should be removed from the Label > > Request Message. This node may or may not be the end of > > the LSP. Processing continues with section 4.8.2, where > > a new explicit route TLV may be added to the Label > > Request Message. But why "This node may or may not be the > > end of the LSP."? RegardsZhang. > --------------7C6194C6AB00456155A1DB68 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkhkr06750 Content-Transfer-Encoding: quoted-printable Zhang,

    A simple example (like I said, no one may do this
in practice).  I could simply decide to releave a node
that is congested by deliberately routing traffic toward
another node that is not.  There may be lots of ways
to ensure that the redirected traffic does not still end
up traversing the congested node without explicitly
excluding it (by explicitly listing all included nodes) in
any ERO.  To do this, I should be able to specify an
explicit route that only contains the desired alternate
node as a loose hop.  In practice, this is not noticeably
different from simply terminating the TE LSP at that
node.

--
Eric Gray

zhang wrote:

 <= font size=3D-1>Eric Grayplease give me a example"This node is not the end of the LSP.", and according what  the nod= e adds new explicit route? -----Original Message-----
·¢¼= þÈË: Eric Gray <eric.gray@sa= ndburst.com>
ÊÕ¼= ;þÈË: zhang <zhanghuachen@hua= wei.com>
³­Ë&Iacu= te;: mpls@UU.NET <mpls@UU.NET>
ÈÕÆ= ;Ú: 2001Äê3ÔÂ8ÈÕ 22:32
Ö÷Ì= â: Re: help for CR-LDP
 Zhang,

    You use an Explicit Route to designate nodes you want
included in an LSP.  That's all.  Practical uses of the ERO
currently tend to include the egress from an MPLS domain,
but there may be TE applications (for example) that benefit
from the increased dynamism of having an ERO that only
specifies some hop toward the middle of the MPLS cloud.

--
Eric Gray

You wrote:

 Dear Mr.(Mrs),  Please help me for a question about algorithem ofselectio= n of the next hop.  In 4.8.1 selection of the next hop  &nbs= p;    2. If there is no second ER-HOP, this indicates the end of   the explicit route. The explicit route TLV should be removed   from the Label Request Message. This node may or may not   be the end of the LSP. Processing continues with section   4.8.2, where a new explicit route TLV may be added to the   Label Requ= est Message. <= font size=3D-1>But why "This node may or may not be the end of the LSP."? RegardsZhang.
--------------7C6194C6AB00456155A1DB68-- From owner-mpls@UU.NET Thu Mar 22 03:52:14 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05404 for ; Thu, 22 Mar 2001 03:52:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkt21184; Thu, 22 Mar 2001 08:51:59 GMT Received: by mail-control.mail.uu.net id QQkhkt15056 for mpls-outgoing; Thu, 22 Mar 2001 08:51:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhkt14992 for ; Thu, 22 Mar 2001 08:51:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhkt23727; Thu, 22 Mar 2001 08:50:43 GMT Received: from ulysses.routingloop.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dsl-64-195-149-73.telocity.com [64.195.149.73]) id QQkhkt16336; Thu, 22 Mar 2001 08:50:42 GMT Received: (from alan@localhost) by ulysses.routingloop.com (8.10.0/8.10.0) id f2M8fJw75992; Thu, 22 Mar 2001 00:41:19 -0800 (PST) Date: Thu, 22 Mar 2001 00:41:19 -0800 From: Alan Hannan To: sk@southernstar.com Cc: mpls@UU.NET, te-wg@UU.NET Subject: Re: Books/Articles on Traffic Engineering Message-ID: <20010322004119.B75921@routingloop.com> References: <20010321235436.13487.cpmta@c000.snv.cp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010321235436.13487.cpmta@c000.snv.cp.net>; from sk@southernstar.com on Wed, Mar 21, 2001 at 03:54:36PM -0800 Sender: owner-mpls@UU.NET Precedence: bulk some exceedingly good and practical work is available at: http://www.cse.msu.edu/~xiaoxipe/ specifically: http://www.cse.msu.edu/~xiaoxipe/download.mplsTE.html http://www.cse.msu.edu/~xiaoxipe/papers/AmericaNet/americanet.pdf -alan Thus spake sk@southernstar.com (sk@southernstar.com) on or about Wed, Mar 21, 2001 at 03:54:36PM -0800: > Does anyone know any good books/articles on traffic > engineering? > > Thanks > -SK From owner-mpls@UU.NET Thu Mar 22 04:36:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07031 for ; Thu, 22 Mar 2001 04:36:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkw23805; Thu, 22 Mar 2001 09:34:36 GMT Received: by mail-control.mail.uu.net id QQkhkw03246 for mpls-outgoing; Thu, 22 Mar 2001 09:34:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhkw03241 for ; Thu, 22 Mar 2001 09:33:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhkw12315 for ; Thu, 22 Mar 2001 09:32:11 GMT Received: from hclhprnd.hclt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkhkw16122 for ; Thu, 22 Mar 2001 09:32:08 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id PAA15520; Thu, 22 Mar 2001 15:29:06 +0530 Received: from hclt.com (GOPINATHPC [192.168.232.109]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2M20DGP; Thu, 22 Mar 2001 15:01:03 +0530 Message-ID: <3AB9C6E0.9E3804F0@hclt.com> Date: Thu, 22 Mar 2001 15:03:20 +0530 From: gopinathg Organization: HCL Technologies LTD X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf , mpls@UU.NET Subject: Re: help for CR-LDP References: <001701c0b1da$d644e4c0$a3096e0a@tom.huawei.com> <3AB8F5AF.70FFFA7F@sandburst.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkhkw23805 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA07031 Eric Gray In your example I just want to conform & clarify the following from u.. I think CR-LDP packet will have both ER-HOP and FEC (ie similar to FEC in LDP but not CR-LSP FEC element). If its is true ,at the last ER-HOP we need to get the next hop as per the LDP specifications.. Thanks In Advance gopinathg > Zhang, > > A simple example (like I said, no one may do this > in practice). I could simply decide to releave a node > that is congested by deliberately routing traffic toward > another node that is not. There may be lots of ways > to ensure that the redirected traffic does not still end > up traversing the congested node without explicitly > excluding it (by explicitly listing all included nodes) in > any ERO. To do this, I should be able to specify an > explicit route that only contains the desired alternate > node as a loose hop. In practice, this is not noticeably > different from simply terminating the TE LSP at that > node. > > -- > Eric Gray > > zhang wrote: > >> Eric Grayplease give me a example"This node is not the end of the >> LSP.", and according what the node adds new explicit route? >> >> -----Original Message----- >> ·¢¼þÈË: Eric Gray >> ÊÕ¼þÈË: zhang >> ³­ËÍ: mpls@UU.NET >> ÈÕÆÚ: 2001Äê3ÔÂ8ÈÕ 22:32 >> Ö÷Ìâ: Re: help for CR-LDP >> Zhang, >> >> You use an Explicit Route to designate nodes you want >> included in an LSP. That's all. Practical uses of the >> ERO >> currently tend to include the egress from an MPLS domain, >> but there may be TE applications (for example) that >> benefit >> from the increased dynamism of having an ERO that only >> specifies some hop toward the middle of the MPLS cloud. >> >> -- >> Eric Gray >> >> You wrote: >> >> > Dear Mr.(Mrs), Please help me for a question about >> > algorithem ofselection of the next hop. In 4.8.1 >> > selection of the next hop 2. If there is no second >> > ER-HOP, this indicates the end of the explicit route. >> > The explicit route TLV should be removed from the Label >> > Request Message. This node may or may not be the end of >> > the LSP. Processing continues with section 4.8.2, where >> > a new explicit route TLV may be added to the Label >> > Request Message. But why "This node may or may not be the >> > end of the LSP."?RegardsZhang. >> From owner-mpls@UU.NET Thu Mar 22 04:53:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07709 for ; Thu, 22 Mar 2001 04:53:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhkx29445; Thu, 22 Mar 2001 09:52:29 GMT Received: by mail-control.mail.uu.net id QQkhkx04764 for mpls-outgoing; Thu, 22 Mar 2001 09:51:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhkx04759 for ; Thu, 22 Mar 2001 09:51:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhkx18853 for ; Thu, 22 Mar 2001 09:51:41 GMT From: afarrel@movaz.com Received: from ims001.dcat.ops.broadbandoffice.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: external00.dca55.ops.bbo.com [64.47.146.7]) id QQkhkx26331 for ; Thu, 22 Mar 2001 09:51:31 GMT Received: by ims001.dcat.ops.broadbandoffice.net with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Mar 2001 04:51:30 -0500 Message-ID: <4F9E13BCC53ED411A629009027E8D00C0433367D@msg001.dcat.ops.broadbandoffice.net> To: akyol@pluris.com Cc: mpls@UU.NET, eric.gray@sandburst.com, pjb@dataconnection.com, philipma@nortelnetworks.com Subject: RE: LDP-FT Question Date: Thu, 22 Mar 2001 04:51:29 -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 Bora, Thanks for your interest in the draft. Your thinking is, I believe, that on recovery of a TCP connection and re-establishment of the LSP session, the peers are able to establish the instance of the session from which they have preserved state. However, since the session runs between the two peers and no-one else is involved, it will always be the case that both peers have the same understanding of the last successful session instance. Further, maintained state refers to the long-term conceptual session between the peers, not to individual instances. The following race illustrates your concern... A talks to B connection fails connection re-established A announces preserved state B announces lost state, but connection fails before A hears this connection re-established A announces preserved state (*) B announces preserved state (i.e. nothing to preserve since last time) (+) Now A believes that the state is preserved, when it has actually been lost. However, the Initialization messages at (*) and (+) carry the sequence numbers of the most recently received and processed messages. A will receive 0 and will know that no message it sent has been preserved. B will receive some non-zero number and will immediately report a sequence number error since it believes it has issued no messages. The session will be reset. Does this answer your worries? Regards, Adrian -- Adrian Farrel Movaz Networks Inc afarrel@movaz.com > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Wednesday, March 21, 2001 6:53 PM > To: af@dataconnection.com > Cc: mpls@UU.NET > Subject: LDP-FT Question > > > Adrian > > I would like to suggest that the draft use a sequence number in place > of the FT_ Reconnect_Flag. A sequence number that is updated every > time FT data is changed and agreed upon by both sides (FT-pair) will > offer better protection than a single flag especially if both router > reboot within a time window. > > What do you think? > > Bora > From owner-mpls@UU.NET Thu Mar 22 05:50:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09263 for ; Thu, 22 Mar 2001 05:50:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhlb15938; Thu, 22 Mar 2001 10:49:30 GMT Received: by mail-control.mail.uu.net id QQkhlb23826 for mpls-outgoing; Thu, 22 Mar 2001 10:48:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhlb23818 for ; Thu, 22 Mar 2001 10:48:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhlb02854; Thu, 22 Mar 2001 10:47:37 GMT Received: from bbnmg1.net.external.hp.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bbnmg1.net.external.hp.com [192.6.76.73]) id QQkhlb24423; Thu, 22 Mar 2001 10:47:36 GMT Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.136.193.32]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id AF722DB; Thu, 22 Mar 2001 11:47:24 +0100 (MET) Received: from eiach.bbn.hp.com (eiach.bbn.hp.com [15.140.168.10]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id LAA11930; Thu, 22 Mar 2001 11:47:24 +0100 (MET) Received: from 15.140.168.10 by eiach.bbn.hp.com (InterScan E-Mail VirusWall NT); Thu, 22 Mar 2001 11:47:23 +0100 (W. Europe Standard Time) Received: by eiach.bbn.hp.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Mar 2001 11:47:23 +0100 Message-ID: From: "WU,CHENG (HP-Germany,ex1)" To: mpls@UU.NET, te-wg@UU.NET Subject: Books/Articles on optical networks and IP-Optical networks Date: Thu, 22 Mar 2001 11:47:13 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA09263 Does anybody know good books articles about optical networks and IP-Optical networks? All the best Cheng HP Consulting SDC NC Schickardstr. 25, Bldg. 32 Boeblingen Germany Tel. +49 (0) 7031-14 6484 mobile +49 (0) 171 - 8577720 Fax +49 (0) 7031-14 4143 Telnet 777 6484 _________________________ -----Original Message----- From: Irwin Lazar [mailto:ILazar@tbg.com] Sent: Donnerstag, 22. März 2001 04:47 To: sk@southernstar.com Cc: mpls@UU.NET; te-wg@UU.NET Subject: RE: Books/Articles on Traffic Engineering > Does anyone know any good books/articles on traffic > engineering? > > Thanks > -SK Please see www.mplsrc.com/articles.shtml for links to about half a dozen articles on MPLS-TE. Irwin From owner-mpls@UU.NET Thu Mar 22 06:03:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09382 for ; Thu, 22 Mar 2001 06:03:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhlc20956; Thu, 22 Mar 2001 11:02:10 GMT Received: by mail-control.mail.uu.net id QQkhlc00732 for mpls-outgoing; Thu, 22 Mar 2001 11:01:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhlc00173 for ; Thu, 22 Mar 2001 11:01:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhlc00680 for ; Thu, 22 Mar 2001 11:00:02 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhlb04946 for ; Thu, 22 Mar 2001 10:59:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA08915 for mpls@uu.net; Thu, 22 Mar 2001 05:59:56 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhlb24420 for ; Thu, 22 Mar 2001 10:59:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhlb20017; Thu, 22 Mar 2001 10:57:15 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhlb05309; Thu, 22 Mar 2001 10:57:15 GMT Received: from cbin3-mira-01.cisco.com (cbin3-mira-01.cisco.com [64.104.129.145]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA19629; Thu, 22 Mar 2001 02:57:17 -0800 (PST) Received: from cisco.com ([64.104.137.138]) by cbin3-mira-01.cisco.com (Mirapoint) with ESMTP id AAI33726 (AUTH naron); Thu, 22 Mar 2001 16:27:11 +0530 (IST) Message-ID: <3AB9DA99.67912FF3@cisco.com> Date: Thu, 22 Mar 2001 16:27:29 +0530 From: Navneet Aron Organization: cisco X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "WU,CHENG (HP-Germany,ex1)" CC: mpls@UU.NET, te-wg@UU.NET Subject: Re: Books/Articles on optical networks and IP-Optical networks References: Content-Type: multipart/mixed; boundary="------------605A27DD8203E73E2FDCB620" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------605A27DD8203E73E2FDCB620 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkhlc20956 Content-Transfer-Encoding: quoted-printable Hi, I can suggest you a pointer .. visit www.Lightreading.com it's a site dedicated to optical networks...u will find something atleast of interest.. i hope this helps.. regards, Navneet "WU,CHENG (HP-Germany,ex1)" wrote: >=20 > Does anybody know good books articles about optical networks and IP-Opt= ical > networks? >=20 > All the best >=20 > Cheng >=20 > HP Consulting > SDC NC > Schickardstr. 25, Bldg. 32 > Boeblingen > Germany >=20 > Tel. +49 (0) 7031-14 6484 > mobile +49 (0) 171 - 8577720 > Fax +49 (0) 7031-14 4143 > Telnet 777 6484 > _________________________ >=20 > -----Original Message----- > From: Irwin Lazar [mailto:ILazar@tbg.com] > Sent: Donnerstag, 22. M=E4rz 2001 04:47 > To: sk@southernstar.com > Cc: mpls@UU.NET; te-wg@UU.NET > Subject: RE: Books/Articles on Traffic Engineering >=20 > > Does anyone know any good books/articles on traffic > > engineering? > > > > Thanks > > -SK >=20 > Please see www.mplsrc.com/articles.shtml for links to about half a doze= n > articles on MPLS-TE. >=20 > Irwin --------------605A27DD8203E73E2FDCB620 Content-Type: text/x-vcard; charset=us-ascii; name="naron.vcf" Content-Description: Card for Navneet Aron Content-Disposition: attachment; filename="naron.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Aron;Navneet tel;fax:+91-80-2289955 tel;work:+91-80-2289933 extn- 5111 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:naron@cisco.com fn:Navneet Aron end:vcard --------------605A27DD8203E73E2FDCB620-- From owner-mpls@UU.NET Thu Mar 22 06:07:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09406 for ; Thu, 22 Mar 2001 06:07:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhlc03326; Thu, 22 Mar 2001 11:06:41 GMT Received: by mail-control.mail.uu.net id QQkhlc10573 for mpls-outgoing; Thu, 22 Mar 2001 11:06:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhlc10521 for ; Thu, 22 Mar 2001 11:05:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhlc29622 for ; Thu, 22 Mar 2001 11:05:05 GMT Received: from hclhprnd.hclt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkhlc11991 for ; Thu, 22 Mar 2001 11:05:03 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id RAA19731 for ; Thu, 22 Mar 2001 17:02:32 +0530 Received: from VIJAYC ([192.168.232.145]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2M20D76; Thu, 22 Mar 2001 16:34:30 +0530 From: "Vijayanand Chandrasekar" To: Subject: FW: ldp MIB Date: Thu, 22 Feb 2001 16:34:55 +0530 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkhlc03326 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA09406 Can anyone please answer this for me Thanks in advance, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vijayanand Chandrasekar Sent: Wednesday, March 21, 2001 2:19 PM To: Hans Sjöstrand Cc: mpls@UU.NET Subject: RE: ldp MIB IF there is a one to one correspondence between Entity and Session how will the entity be initialised. Should'nt each entity be configured initially with Label range, Label space, Targetted peer address etc, so that this info will be used for peer discovery and session establishment.The LdpId used in the PDU is that of the entity which should have been configured.If this is so then how can the number of sessions(hence entities) be known apriori, since this is as a result of peer discovery. Also, in the Entity Table the Enity Index is given as optional for implementations, what is the reason for this? Does it mean that we start of with an Enity configuration intially and for each new peer discovered and sesssion established the Entity Table is updated. Thanks in advance, Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Hans Sjöstrand Sent: Tuesday, March 20, 2001 3:32 PM To: anilg@acc.am.ericsson.se; mpls@UU.NET Subject: RE: ldp MIB No, the entity and the peer is one-to-one. Just because it's indexed this way, using the ldpId and the peers ldp id in the index it doesn't automatically imply a one to many relationship. On the contrary, the ldp session table is augmenting the ldp peer table and it's specifically a one-to-one relationship between entity and session, e.g. section 3.1 Overview "A table is used to configure potential LDP Sessions, where each row in the table initiates an LDP Session. This is the mplsLdpEntityTable" Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Anil > Gunturu > Sent: den 16 mars 2001 20:37 > To: mpls@UU.NET > Subject: ldp MIB > > > Hi, > I was wondering, if it is possible for an entry in the MplsLdpEntity table > there are multiple entries in the MplsPeerEntryTable? Looks like the MIB > allows it because the MplsLdpPeerEntry table is indexed by > mplsLdpEntityLdpId, mplsLdpEntityIndex and mplsLdpPeerLdpId. If it is > possible can some one give a practical scenario. > Thanks in advance for help, > -Anil > > Anil Gunturu, Software Engineer > Ericsson, Inc phone: (805) 562 6431 > Datacom & IP Services email: anilg@acc.am.ericsson.se > 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Thu Mar 22 09:33:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12068 for ; Thu, 22 Mar 2001 09:33:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhlq05533; Thu, 22 Mar 2001 14:31:16 GMT Received: by mail-control.mail.uu.net id QQkhlq13406 for mpls-outgoing; Thu, 22 Mar 2001 14:30:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhlq13398 for ; Thu, 22 Mar 2001 14:30:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhlp18566 for ; Thu, 22 Mar 2001 14:29:58 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQkhlp01094 for ; Thu, 22 Mar 2001 14:29:57 GMT Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 22 Mar 2001 09:15:53 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Mar 2001 09:15:55 -0500 Message-ID: From: "Bilel Jamoussi" To: "'manoj juneja'" , "'mpls@UU.NET'" Cc: "'gash@att.com'" , "Peter Ashwood-Smith" , fedyk@nortelnetworks.com, skalecki@nortelnetworks.com, "'lili@ss8networks.com'" , "'ylee@irislabs.com'" Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" Date: Thu, 22 Mar 2001 09:15:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B2DA.7FB273B0" 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_01C0B2DA.7FB273B0 Content-Type: text/plain; charset="ISO-8859-1" can you clarify why the next hop changes? is it node failure? loosely routed lsp with no pinning? Bilel. -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Wednesday, March 21, 2001 6:06 PM To: mpls@UU.NET Cc: gash@att.com; Ashwood-Smith, Peter [CAR:CS0I:EXCH]; Jamoussi, Bilel [BL60:2868-M:EXCH]; fedyk@nortelnetworks.com; skalecki@nortelnetworks.com; lili@ss8networks.com; ylee@irislabs.com Subject: Valid Race Condition related to draft "draft-ietf-mpls-crlsp-modify-03.txt" Hi All, Please comment on the following : If the LSP modification is in progress and in the meantime the next hop for the same LSP changes then should the modification procedure be aborted ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com ------_=_NextPart_001_01C0B2DA.7FB273B0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Valid Race Condition related to draft = "draft-ietf-mpls-crlsp-modify-03.txt"

can you clarify why the next hop changes? is it node = failure? loosely routed lsp with no pinning?

Bilel.

-----Original Message-----
From: manoj juneja [mailto:manojkumarjuneja@hot= mail.com]
Sent: Wednesday, March 21, 2001 6:06 PM
To: mpls@UU.NET
Cc: gash@att.com; Ashwood-Smith, Peter = [CAR:CS0I:EXCH]; Jamoussi, Bilel
[BL60:2868-M:EXCH]; fedyk@nortelnetworks.com;
skalecki@nortelnetworks.com; lili@ss8networks.com; = ylee@irislabs.com
Subject: Valid Race Condition related to = draft
"draft-ietf-mpls-crlsp-modify-03.txt"


Hi All,

   Please comment on the following :

        If the LSP = modification is in progress and in the meantime the
next hop for the same LSP changes then should the = modification
procedure be aborted ?

Regards,
manoj.




_______________________________________________________________= __
Get your FREE download of MSN Explorer at http://explorer.msn.com

------_=_NextPart_001_01C0B2DA.7FB273B0-- From owner-mpls@UU.NET Thu Mar 22 09:48:13 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12364 for ; Thu, 22 Mar 2001 09:48:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhlr18834; Thu, 22 Mar 2001 14:45:50 GMT Received: by mail-control.mail.uu.net id QQkhlr14849 for mpls-outgoing; Thu, 22 Mar 2001 14:45:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhlq14617 for ; Thu, 22 Mar 2001 14:44:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhlq05876 for ; Thu, 22 Mar 2001 14:43:23 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhlq08984 for ; Thu, 22 Mar 2001 14:43:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA22636 for mpls@uu.net; Thu, 22 Mar 2001 09:43:22 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhlq14508 for ; Thu, 22 Mar 2001 14:42:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhlq04371 for ; Thu, 22 Mar 2001 14:40:16 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkhlq04797 for ; Thu, 22 Mar 2001 14:40:15 GMT Received: from swallow-pc01.cisco.com (sj-dial-3-163.cisco.com [171.68.180.164]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA24308; Thu, 22 Mar 2001 09:39:56 -0500 (EST) Message-Id: <4.3.2.7.2.20010321162239.00b8a250@pilgrim.cisco.com> X-Sender: swallow@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Mar 2001 16:24:54 -0500 To: "Arvind, K" From: George Swallow Subject: Re: Section 5.5 of ietf-mpls-rsvp-lsp-tunnel-08.txt Cc: "'lberger@movaz.com'" , "'mpls@uu.net'" In-Reply-To: <6B190B34070BD411ACA000B0D0214E5659A194@newman.tenornet.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:23 AM 3/21/2001 -0500, Arvind, K wrote: >Lou, George: > > The following change doesn't seem to have made it into this version of the >draft. The clause "or will respond with an 'Unknown Object Class' error" >still appears in the second paragraph of this section. It was agreed earlier >(http://cell-relay.indiana.edu/mhonarc/mpls/2000-Oct/msg00031.html) that >this clause should be dropped. > >Regards, >Arvind. Yes. The plan is to handle this as part of the final edits before RFC publication. ...George From owner-mpls@UU.NET Thu Mar 22 15:12:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20009 for ; Thu, 22 Mar 2001 15:12:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhmm25675; Thu, 22 Mar 2001 20:11:22 GMT Received: by mail-control.mail.uu.net id QQkhmm22318 for mpls-outgoing; Thu, 22 Mar 2001 20:10:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhmm22283 for ; Thu, 22 Mar 2001 20:10:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhmm05293 for ; Thu, 22 Mar 2001 20:09:45 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkhmm19541 for ; Thu, 22 Mar 2001 20:09:45 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 MAA13026 for ; Thu, 22 Mar 2001 12:09:48 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA01653 for mpls@uu.net; Thu, 22 Mar 2001 15:09:43 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhmh13196 for ; Thu, 22 Mar 2001 18:59:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhmh09193 for ; Thu, 22 Mar 2001 18:59:33 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f165.law10.hotmail.com [64.4.15.165]) id QQkhmh10778 for ; Thu, 22 Mar 2001 18:59:32 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Mar 2001 10:59:28 -0800 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Thu, 22 Mar 2001 18:59:28 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: jamoussi@nortelnetworks.com, mpls@UU.NET Cc: gash@att.com, petera@nortelnetworks.com, fedyk@nortelnetworks.com, skalecki@nortelnetworks.com, lili@ss8networks.com, ylee@irislabs.com Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" Date: Thu, 22 Mar 2001 11:59:28 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Mar 2001 18:59:28.0453 (UTC) FILETIME=[386FC750:01C0B302] Sender: owner-mpls@UU.NET Precedence: bulk Hi bilel, I have couple of points in mind regarding crlsp-modift-03.txt draft. First Point : From the protocol point of view, we have a valid next hop change procedure defined for an already established LSP. So, there has to be proper interworking of various procedures in the protocol. It may happen that when u have sent the label request message for modifying the characteristics of an LSP, the next hop change trigger can come for an already establsihed LSP (for which the modification is in progress). We should provide this valid race condition in the draft and the solution for the same in draft. The next hop of an active LSP can change due to any reason. Also, Can u please comment on the following : Second Point : LSP modification should be limited to modification in bandwidth and holding priority of already active LSP. I don't foresee any application for re-route capability. This capability can be implemented in some other way also. If we compare the modification procedures to already exisiting modification procedures in various call control protocols viz. ISDN, ATM and GSM, these protocols allow in bandwidth modification only. Those procedures don't allow for re-routing. For re-routing u have to establish another path which is treated as a complete new request. Is there any specific reason why re-routeing has been thought of as a part of modification in MPLS ? I think we should define messages like LSP modify Request and LSP modify complete/LSP modify reject for modification. These modify messages should take the same signalling path as of original LSP establishment messages. Is not everbody overloading the Label Request/Label Mapping messages for everything (i.e. keeping the same set of messages even for O-UNI) ? Third Point : As per the draft, after the modification procedure is complete, the ingress node will initiate the LSP release procedures for the old LSP. Is there any guard timer running in the intermediate nodes that these nodes will be receiving the Label Release message from the upstream node ? I think we should have the guard timer, may be network manager dependent. Please comment. Regards, manoj. >From: "Bilel Jamoussi" >To: 'manoj juneja' , "'mpls@UU.NET'" > >CC: "'gash@att.com'" , "Peter Ashwood-Smith" >, fedyk@nortelnetworks.com, >skalecki@nortelnetworks.com, "'lili@ss8networks.com'" >, "'ylee@irislabs.com'" >Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp > -modify-03.txt" >Date: Thu, 22 Mar 2001 09:15:08 -0500 > >can you clarify why the next hop changes? is it node failure? loosely >routed >lsp with no pinning? > >Bilel. > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Wednesday, March 21, 2001 6:06 PM >To: mpls@UU.NET >Cc: gash@att.com; Ashwood-Smith, Peter [CAR:CS0I:EXCH]; Jamoussi, Bilel >[BL60:2868-M:EXCH]; fedyk@nortelnetworks.com; >skalecki@nortelnetworks.com; lili@ss8networks.com; ylee@irislabs.com >Subject: Valid Race Condition related to draft >"draft-ietf-mpls-crlsp-modify-03.txt" > > >Hi All, > > Please comment on the following : > > If the LSP modification is in progress and in the meantime the >next hop for the same LSP changes then should the modification >procedure be aborted ? > >Regards, >manoj. > > > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Thu Mar 22 17:01:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23008 for ; Thu, 22 Mar 2001 17:01:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhmt01608; Thu, 22 Mar 2001 21:58:58 GMT Received: by mail-control.mail.uu.net id QQkhmt17599 for mpls-outgoing; Thu, 22 Mar 2001 21:58:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhmt17565 for ; Thu, 22 Mar 2001 21:57:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhmt21264; Thu, 22 Mar 2001 21:57:34 GMT Received: from bgslc02.TBG.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQkhmt00041; Thu, 22 Mar 2001 21:57:33 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Mar 2001 14:46:35 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE70146D84F@BGSLC02> From: Irwin Lazar To: "'WU,CHENG (HP-Germany,ex1)'" , mpls@UU.NET, te-wg@UU.NET Subject: RE: Books/Articles on optical networks and IP-Optical networks Date: Thu, 22 Mar 2001 14:46: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 >Does anybody know good books articles about optical networks and IP-Optical >networks? Try: Optical Networks: A practical perspective By Rajiv Ramaswami & Kumar Sivarajan Irwin From owner-mpls@UU.NET Thu Mar 22 18:52:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26435 for ; Thu, 22 Mar 2001 18:52:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhnb20563; Thu, 22 Mar 2001 23:50:56 GMT Received: by mail-control.mail.uu.net id QQkhnb28621 for mpls-outgoing; Thu, 22 Mar 2001 23:49:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhnb28614 for ; Thu, 22 Mar 2001 23:49:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhnb08083 for ; Thu, 22 Mar 2001 23:49:14 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhnb18354 for ; Thu, 22 Mar 2001 23:49:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA04456 for mpls@uu.net; Thu, 22 Mar 2001 18:49:13 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhnb28568 for ; Thu, 22 Mar 2001 23:48:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhnb08780 for ; Thu, 22 Mar 2001 23:48:02 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkhnb08738 for ; Thu, 22 Mar 2001 23:48:02 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA29821; Thu, 22 Mar 2001 18:47:14 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (rtp-vpn-186.cisco.com [10.82.192.186]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA00479; Thu, 22 Mar 2001 18:47:57 -0500 (EST) Message-Id: <4.3.2.7.2.20010322184552.01bd5d48@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Mar 2001 18:47:17 -0500 To: mpls@UU.NET, swallow@cisco.com From: "Thomas D. Nadeau" Subject: MPLS WG Meeting Minutes Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_16356369==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_16356369==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable MPLS WG Meeting Thursday, March 22, 2001 Agenda Bashing George provided document status on existing documents which are in last= call. Mpls-bgp4-mpls-05: Not sure what the current state is. Applicability statement for extensions to rsvp for lsp-tunnels: some minor= =20 edits needed. Rsvp-te extensions to rsvp for lsp tunnels LDP =93boxed=94 set: Needs some editorial changes. Eric Gray needs to do= some=20 editing. MPLS-LSR/LDP MIB are currently working on IESG changes. Another round of=20 last call probably not required. MPLS DiffServ Update: Francois L. provided an update. Last call finished in= =20 diffServ WG. Mostly minor comments to fix. Re-issue a final version which=20 gets sent over to the IESG. Who to hand it over to? Rob Coltun: Hand it=20 over to Scott/Bert. Framework for IP Multicast in MPLS: read for IESG last call. Generalized MPLS Signaling drafts: join last call with CCAMP. Updated by=20 Kireeti. There were a few changes in CCAMP. Lou Berger needs to make a few= =20 changes. Some changes to spin Sonet documents off into another document,=20 and will then be ready to go to last call. This is related to the TSPEC for= =20 Sonet. George, should we go to last call? No hands opposed. Consensus to=20 send to last call. Framework for multicast recovery. Authors feel it is ready to go to wg last= =20 call. Unnumbered, Bundle, Hierarchy documents will remain as wg drafts in MPLS. Accept draft-kompella-mpls-undle-05.txt as working group draft. Modify the= =20 draft slightly as draft-mpls-bundle-00.txt. Draft will then go to wg last=20 call. None opposed; consensus. Kellstrand MPLS recovery framework -- draft-ietf-mpls-recovery-framework Gave update on progress of document. This document was presented to TE WG.= =20 Many comments received on this document. Minor changes were required=20 (editorial). Updated WG on current updates to the document. Outlined=20 recovery principles: initiation of the recovery path setup:=20 pre-established, prequalified, established-on-demand. Recovery principles= =20 covered. Asked to send to WG last call and move it to an informational RFC. No questions from crowd. George asked Ads to move this forward to wg last call. Scott wants to wait until TE wg design teams return their results before we= =20 bring this to wg last call, but doesn=92t want to hold the document. Kellstrand noted that this document was on hold for 2 meetings, and wants=20 to move forward with bringing it to last call. Will send out on TE WG mailing list and ask for comments. George: TE WG design teams can use this document for their work. Question A: Are there any performance benchmarks provided for recovery or= =20 should this be somewhere in the requrirements? Kellstrand: No, there are no benchmarking in draft. Question A: Performance benchmarks need to be added. George: This document contains things in a much higher level than this. Curtis: This document is a little too complete. This document is useful=20 regardless and advanced anyway while the TE wg can progress with its own= work. George: This document is really a taxonomy. Scott: There might be a taxonomy, but the te wg might want to use it. Kellstrand: we can include additional minor changes during last call. Curtis: Rename as =93taxonomy=94? Scott: Wants to take a sense of the room, and then get comments from the=20 mailing list for last call, but still wants te design team to make sure=20 that they don=92t want to add to it. Don=92t want to wait for more than a= month. George: Any objections on moving to last call within a month? None were= voiced. Swallow MPLS Resilience Objective is to do FRR in MPLS to allow for temporary routing around a=20 failed link or node while the head-end is reoptimizing the lsp. Rerouting=20 under 50ms. Scalable. Allows for sonnet-speed recovery times. Two=20 mechanisms provided in draft: use rsvp to signal backup paths, or a=20 frame-based switch using the global label space can simply record labels in= =20 the rro. Although linkstate changes may be the primary means of adding need= =20 to notify the head end. Draft available for the past 1.5 years. It is purely informational; doesn=92= t=20 propose anything new. Would like to publish as a wg informational draft. Scott (as chair): Is there support in the room for this. No objections. Question A: Does not see quite how it works if wanting to route around a=20 few hops versus routing around a few links. George: The assumption is that you set up a tunnel to the hop around the=20 one being protected. Q A: No, the outer tunnel needs to use one of the outer tunnels to get= around? George: Lets take it offline and I will explain the details. Q B: If the tunnel follows the green tunnel, then the RSVP object is set to= =20 this object. George: Explains how messages are sent. Q B: Two path messages are sent? George: Yes, two path messages are sent. Q B: More clarification requested=85 George: Lets take it offline. Q C: There are two objectives: 50ms + large numbers of LSPs backed up. How= =20 are these both achieved. George: All information is in each router at the time of failure.=20 Scalability by allowing many tunnels allowed to be backed up by a single=20 tunnel. Scott: Confusion needs to be set up. Support seems to be there. Bert and I= =20 will take a look at the draft. Matthews LDP Fault Tollerance draft-ietf-mpls-ldp-ft-01.txt Summarized draft. Discussed changes between last version and current=20 version. Expect to ask for wg last call soon. Requested comments now or via= =20 mailing list. George: Consensus to put this draft to a wg last call. Luca Martini opposes= =20 wg last call; no other objections. Luca: Since ldp is not a controlling protocol, why bother making it fault=20 tolerant? Matthews: Enhance software upgrades and you don=92t want to disrupt the LSPs= =20 that are running over the network. Luca: But other protocols need to be made redundant too. Matt: OSPF etc=85 are being made fault tolerant. We stole this proposal from= IDR. George: Last call to be issued. Scott: Shouldn=92t we wait until the work on the routing protocols is=20 finished before we finish this up? George: The idea is for this state to be useful, this work needs to be=20 done. The state of this protocol needs to be done, and can be done in= parallel. Scott: Should we serialize them? George: There is no hardm. Curtis: There was some work in OSPF that helped quicken the detection of=20 faults in the database. Prevents premature changes in database. Are those=20 applicable to this draft? Matt: That is true. This is useful by itself because you can use this to=20 upgrade your LDP software. For OSPF it is not clear how this will work. Curtis: A router is loading software takes a long time relative to changes= =20 in the routing protocol. The static tables in hardware should be okay. If=20 there are changes in the network, then there can be problems. Matt: I don=92t see this being used this way. If you use hot standby=20 hardware, then there is no disruption. You need to sift information across= =20 between cards. It is easier to do at the ldp level than at the tcp level. Eric: there is a lot of interaction between ldp and routing protocols. It=20 is orthogonal between what is used to modify the routing protocols. We can= =20 get into a problem if we mix routing protocols in this specification. Lets= =20 not worry about OSPF, ISIS, etc=85 Curtis: The issue is not to do the same as ospf. If there is a small=20 router, should this be in the protocol to handle the overhead of this=20 switchover? Matt: We want to support this ability? Curtis: OSPF/IDR changes were intended to use for switchovers. It might be= =20 better to abort graceful restart and just assume the router is down. Q: There are applications of LDP that do not depend on upgrades to other=20 protocols. Scott: Is there an applicability statement in this document to show where=20 it can be used? M: There are, but there are not which describe where it should not be used. Scott: It might benefit from this. There doesn=92t seem like there is a lot= =20 of support for this. George: Lets continue this discussion on the mailing list. If no resolution= =20 there, we can talk about it later. Curtis: If there is no problem in last call, just move it forward? Small=20 changes may be required to support OSPF/RTP changes. George: that is okay with me. We will do a last call, raise these issues=20 and try to close them. If closed, then document is finished. Sharma Vishal Expanded ERO for RSVP-TE Overview. Lets make this an informational document on how to form EROs and= =20 move it forward that way. George: Questions? Matt: Asked to clarify. Vishal: Yes. George: Turn another draft and will ask later. Qa: Don=92t want to move it forward. G: Isn=92t being moved forward. We will re-spin another version of this=20 document. Come to London for more information. Agarawal TTL Processing in MPLS Networks Draft covers different ways of processing TTL. Overview. Would like to=20 update according to comments from list and move forward to last call. Matt: Document is useful and technical content is good. Figures would be=20 useful. Document is difficult to read. Pipe/Hose model are mixed in=20 document. Put them in a their own places in the document? Q1: I don=92t see how TTLs are specified in NTAPs draft. A: Some models are not described in that document. Q1: There might be some difficulty with your approach. Rosen: There is already a document that specifies how TTL processing works.= =20 Lets just put pipe model in here only, otherwise we duplicate things=20 explained in RFC 3032. I think that we need to organize the discussion around the point of the=20 organization of this document (what is not covered and what is). E: You don=92t need a separate procedure for nested procedure; already=20 covered in 3032. Discussion did not complete on mailing list. There is a=20 lot that needs to be clarified. A: What are you proposing? E: I think that you are proposing changes and additions (specified and=20 unspecified). Need to specified which is which. Need to reach consensus on= =20 whether or not they are necessary. Do we need a document that obsoletes=20 pieces of rfc3033. George: this is an information proposal. We cannot contradict something=20 that is in a standard. Lets continue this discussion on the mailing list. Egray: I was going to say what george just said. Define something in a=20 standard specification and explain something in an informational. George: Cannot contradict what was in the rfc. Take it to the list. Matsushima ttl processing expansion for 1 hop lsp Overview. Next steps: merge with Puneet=92s ttl draft. Would like to become= a=20 wg draft. Need signaling extensions for 1-hop lsp. George: Discussion? Rosen: There are two schools of thought on TTL processing. Don=92t think=20 there is a need to specify TTL on a per-lsp basis. I don=92t think that= there=20 is a problem that we need to solve here. Matt: I agree with eric. The terminology for a 1-hop lsp is different from= =20 what they define. Luca: I agree with Eric=92s comments. I don=92t see the use of specifying= the=20 behavior on a per-lsp basis. Q: I don=92t think that this is what ttl was designed for. George: Continue discussion on mailing list. Paridaens End to End Authentication for ldp Overview. Presented requirements. What we are asking is that this be=20 adopted as a wg draft. This work is part of the charter, so it should be=20 accepted. Scott: What operators have expressed interest in this technology and have=20 the security geeks looked at this? Q: I don=92t see any carriers looking at this. This method is expensive. Parid: The cost is not so heavy. Q: The other routing protocols work fine without authentication. If that is= =20 not a problem there, then why is this necessary here? Paris: There are options as part of other protocols for authentication. It= =20 is necessary in other protocols and applications of them. Q: All vendors are required to implement these drafts, and I don=92t think= =20 that it is necessary. I would like to see the requirements document for=20 this sort of work. George: I would like to see a clear indication from the carriers that this= =20 is necessary. Q: We had this discussion in San Diego. The consensus there was that this=20 is overkill. Similar mechanisms are already available in TCP. George: The charter items must not be worked on, they can be worked on. Q: There is no explicit =93why=94 about doing this from carriers. Qb: I am not comfortable with this solution, but there seemed to be a clear= =20 statement in San Diego for non-hop-by-hop authentication. George: Can some of those people speak up? Qd: I made this proposal. There was some support at this time. Qe: This looks like S-BGP which was roundly rejected because it was=20 overkill/unfeasible. There is precident for this not being what vendors= want. George: We need to figure out what providers want first. We don=92t have=20 consensus. Qf: Providers want security, but this is not really what we are looking for. George: Lets get some carriers to give us some contributions for what they= =20 would like to see in this space. Continue discussion on this mailing list. Black Update on LDP Path MTU black-ldp-mtu-extensions-00.txt Overview. Simple extension to ldp to allow automatic signaling of mtu=20 detection. Allows proper fragmentation of packets within the MPLS domain.=20 Support RFC1191 too. Version 00 has been out for some time. Lots of=20 comments received. Asked that this be accepted as a wg document. George: discussion Curtis: What happens if along the way, one hop is inside a hierarchtical=20 tunnel or if bypass tunnels are used. In both cases, the router negotiating= =20 a hop is not aware that somewhere in the middle that a bypass exists. Black: If hierarchtical, the outermost tunnel=92s mtu is used. There is an= =20 lsr somewhere that can see the bypass which can unsolicited signal the mtu= =20 change. It will pick the lesser of the two=92s path. George: Anything that causes an impulse into signaling during a failure is= bad. Rosen: In practice, a typical situation a packet with dm bit set, packets=20 go through Firewalls that strip the tos bits off the packet. This solution= =20 does not solve the problem. Black: In some cases, path MTU signaling in some cases is not valid to not= =20 solve the problem altogether. Second, there are other reasons for doing=20 this: packets being fragmented in/out of MPLS domain. Rosen: Both packets have df bits set. Curtis: There are places where this is necessary: no NATs and high=20 performance IP. Matt: I haven=92t seen demands from the carriers for this functionality,=20 eventhough I like it. Scott: Process point: is this in the charter? George: Gray area. We should work to get MPLS to work. Scott: WG can change charter if necessary. Charter is description of what=20 we should be doing within a certain time period. Q1: Carriers are interested in this. Black: RSVP has this functionality. George: We now have three presentations that are not in the gray area. They= =20 are outside of the charter. We are going into =93BOF=94 mode to see if there= is=20 interest to expand the charter. Senevirath -- Secure MPLS draft-tsenevir-smpls-01, tsenevir-smpls-doi-00 Overview. Applications: Most metro applications use MPLS. Q1: In your first slide, you stated that most MPLS Metro carriers use MPLS.= =20 Which country are you talking about? Sen: US. Q1: Do you know which vendors are supporting MPLS in the metro area. Q2: Most operators use f/r links. The law prohibits them from monitoring=20 authentications. Can authentications be monitored on MPLS. Even if we have= =20 mpls security on a backbone. MPLS is an end-to-end problem. This does not=20 seem to be useful unless it is end to end. Bilel J: Where are you getting the requirements for this draft. Sen: These requirements are coming from the optical development going on in= =20 the world. George: Take the discussion to the mailing list. Disk Ooms MPLS multicast Traffic Engineering Overview. Questions. George: This work was started a long time ago. There was no interest in=20 this at that time. What has changed? Disk: Now there is SSMulticast. George: I think that you should change the name of your document to=20 =93support for SSM=94. Describe your document in this way. Disk: this is an alternative to SSM, not a tunnel through it. George: I guess the amount of time we have left, we should see if there is= =20 interest on the mailing list. Rosen: As far as SSM, there are other solutions to the problem of passing=20 multicast packets back to the root. Disk: There are other solutions, but they are undocumented as of yet. Q1: I wasn=92t clear why SSM makes this more interesting. Also it isn=92t= clear=20 how you distribute the labels using TE. Where is the definition of TE is=20 not clearly defined in the draft. Disk: Traffic engineering allows you to construct a tree, which deviates=20 from the one created in unicast. George: The interest in SSM is more interesting than general multicast, and= =20 it is an easier problem to solve. Lets continue discussion on the mailing= list. Davari MPLS OAM draft-harrison-mpls-oam-00.txt Overview. Status of this document: ITU SG14-Q3. Requirements are defined.= =20 Availability is defined. OAM Packets are defined. Connectivity verification= =20 is worked out. Future work: LSP performance work. Summary: OAM is=20 necessary for user-plane, independent of control-plane. This draft=20 introduces OAM requirements and simple OAM functions. Determining=20 connectivity/availability. MPLS OAM was previously defined in MPLS charter.= =20 If interested, it should be added to charter and document accepted as a=20 work item. Q: I think this work is very useful. It will increase the performance of=20 the MPLS network. Recovery framework is applicable. Performance=20 benchmarking applies. This is useful for fault-tollerance. Curtis: How does this apply to the Bonica work? We should go to the TE Wg=20 and see what their requirements are for this. Rosen: I think that some of the stuff in the beginning is important. I=20 think this document is not a good piece of work that are not defined in the= =20 IETF. It has a very ATM-flavor. It does not handle a lot of stuff like=20 multi-point-to-point. Even if we were to add measurement to charter, lets=20 not accept this document to the charter. Davari This is optional. Carriers want this. Q2: I don=92t think that this is useful. I think that it is not useful in an= =20 LSR. I can see this to be useful if GSMP is being used. Useful in=20 detecting configuration errors, otherwise lets assume that the LSR works= okay. Q3: I second that. I don=92t buy the argument that software is broken, so we= =20 need to add more software. Scott: My problem with the document is that it mixes light requirements=20 with lots of suggestions. It would be useful to have a clear requirements=20 document (TE WG) that specifies what it is that you are trying to find out= =20 with this approach. That would be helpful for TE WG. Q4: I think that the notion at the MPLS Layer is a useful construct for=20 fault diagnosis. Q5: The ITU is working on this. Can you send a pointer to this information= =20 on the ITU. Davari: The information at the ITU is exactly the same information. ITU=20 study group SG-13 Q6: I am not sure if the finding of errors is to be found in the te wg. Davari: is it in the charter of te? Scott: Thinking is in the charter of te. Management of this kind is not in= =20 the charter. However, if requirements can come forward and hint at which=20 tools they could have would be a good thing. Q6: I am not sure that availability is specified. Davari: What we have done is take this from ATM and reduce most of what was= =20 there, and kept the best %1. George: End of the agenda. See you in London. --=====================_16356369==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS WG Meeting Thursday, March 22, 2001

Agenda Bashing

George provided document status on existing documents which are in last call.

Mpls-bgp4-mpls-05: Not sure what the current state is.

Applicability statement for extensions to rsvp for lsp-tunnels: some minor edits needed.

Rsvp-te extensions to rsvp for lsp tunnels

LDP =93boxed=94 set: Needs some editorial changes. Eric Gray needs to do som= e editing.

MPLS-LSR/LDP MIB are currently working on IESG changes. Another round of last call probably not required.

MPLS DiffServ Update: Francois L. provided an update. Last call finished in diffServ WG. Mostly minor comments to fix. Re-issue a final version which gets sent over to the IESG. Who to hand it over to? Rob Coltun: Hand it over to Scott/Bert.

Framework for IP Multicast in MPLS: read for IESG last call.

Generalized MPLS Signaling drafts: join last call with CCAMP. Updated by Kireeti. There were a few changes in CCAMP. Lou Berger needs to make a few changes. Some changes to spin Sonet documents off into another document, and will then be ready to go to last call. This is related to the TSPEC for Sonet. George, should we go to last call? No hands opposed. Consensus to send to last call.

Framework for multicast recovery. Authors feel it is ready to go to wg last call.

Unnumbered, Bundle, Hierarchy documents will remain as wg drafts in MPLS.

Accept draft-kompella-mpls-undle-05.txt as working group draft. Modify the draft slightly as draft-mpls-bundle-00.txt. Draft will then go to wg last call. None opposed; consensus.

Kellstrand  MPLS recovery framework --  draft-ietf-mpls-recovery-framework

Gave update on progress of document. This document was presented to TE WG. Many comments received on this document. Minor changes were required (editorial). Updated WG on current updates to the document.  Outlined recovery principles: initiation of the recovery path setup: pre-established, prequalified, established-on-demand.  Recovery principles covered.  Asked to send to WG last call and move it to
an informational RFC. No questions from crowd.

George asked Ads to move this forward to wg last call.

Scott wants to wait until TE wg design teams return their results before we bring this to wg last call, but doesn=92t want to hold the document.

Kellstrand noted that this document was on hold for 2 meetings, and wants to move forward with bringing it to last call.

Will send out on TE WG mailing list and ask for comments.

George: TE WG design teams can use this document for their work.

Question A:  Are there any performance benchmarks provided for recovery or should this be somewhere in the requrirements?

Kellstrand: No, there are no benchmarking in draft.

Question A: Performance benchmarks need to be added.

George: This document contains things in a much higher level than this.

Curtis:  This document is a little too complete. This document is useful regardless and advanced anyway while the TE wg can progress with its own work.

George: This document is really a taxonomy.

Scott: There might be a taxonomy, but the te wg might want to use it.

Kellstrand: we can include additional minor changes during last call.

Curtis: Rename as =93taxonomy=94?

Scott: Wants to take a sense of the room, and then get comments from the mailing list for last call, but still wants te design team to make sure that they don=92t want to add to it. Don=92t want to wait for more than a month.

George: Any objections on moving to last call within a month? None were voiced.



Swallow  MPLS Resilience

Objective is to do FRR in MPLS to allow for temporary routing around a failed link or node while the head-end is reoptimizing the lsp. Rerouting under 50ms. Scalable. Allows for sonnet-speed recovery times. Two mechanisms provided in draft: use rsvp to signal backup paths, or a frame-based switch using the global label space can simply record labels in the rro. Although linkstate changes may be the primary means of adding need to notify the head end.

Draft available for the past 1.5 years. It is purely informational; doesn=92t propose anything new. Would like to publish as a wg informational draft.

Scott (as chair): Is there support in the room for this. No objections.

Question A: Does not see quite how it works if wanting to route around a few hops versus routing around a few links.

George: The assumption is that you set up a tunnel to the hop around the one being protected.

Q A: No, the outer tunnel needs to use one of the outer tunnels  to get around?

George: Lets take it offline and I will explain the details.

Q B: If the tunnel follows the green tunnel, then the RSVP object is set to this object. 

George: Explains how messages are sent.

Q B: Two path messages are sent?

George: Yes, two path messages are sent.

Q B: More clarification requested=85

George: Lets take it offline.

Q C: There are two objectives: 50ms + large numbers of LSPs backed up. How are these both achieved.

George: All information is in each router at the time of failure. Scalability by allowing many tunnels allowed to be backed up by a single tunnel.

Scott: Confusion needs to be set up. Support seems to be there. Bert and I will take a look at the draft.

Matthews  LDP Fault Tollerance  draft-ietf-mpls-ldp-ft-01.txt

Summarized draft. Discussed changes between last version and current version. Expect to ask for wg last call soon. Requested comments now or via mailing list.

George: Consensus to put this draft to a wg last call. Luca Martini opposes wg last call; no other objections.

Luca: Since ldp is not a controlling protocol, why bother making it fault tolerant?

Matthews: Enhance software upgrades and you don=92t want to disrupt the LSPs that are running over the network.

Luca: But other protocols need to be made redundant too.

Matt: OSPF etc=85 are being made fault tolerant. We stole this proposal from IDR.

George: Last call to be issued.

Scott: Shouldn=92t we wait until the work on the routing protocols is finished before we finish this up?

George: The idea is for this state to be useful, this work needs to be done. The state of this protocol needs to be done, and can be done in parallel.

Scott: Should we serialize them?

George: There is no hardm.

Curtis: There was some work in OSPF that helped quicken the detection of faults in the database. Prevents premature changes in database. Are those applicable to this draft?

Matt: That is true. This is useful by itself because you can use this to upgrade your LDP software. For OSPF it is not clear how this will work.

Curtis: A router is loading software takes a long time relative to changes in the routing protocol. The static tables in hardware should be okay. If there are changes in the network, then there can be problems.

Matt: I don=92t see this being used this way. If you use hot standby hardware, then there is no disruption. You need to sift information across between cards. It is easier to do at the ldp level than at the tcp level.

Eric: there is a lot of interaction between ldp and routing protocols. It is orthogonal between what is used to modify the routing protocols. We can get into a problem if we mix routing protocols in this specification. Lets not worry about OSPF, ISIS, etc=85

Curtis: The issue is not to do the same as ospf. If there is a small router, should this be in the protocol to handle the overhead of this switchover?

Matt: We want to support this ability?

Curtis: OSPF/IDR changes were intended to use for switchovers. It might be better to abort graceful restart and just assume the router is down.

Q: There are applications of LDP that do not depend on upgrades to other protocols.

Scott: Is there an applicability statement in this document to show where it can be used?

M: There are, but there are not which describe where it should not be used.

Scott: It might benefit from this. There doesn=92t seem like there is a lot of support for this.

George: Lets continue this discussion on the mailing list. If no resolution there, we can talk about it later.

Curtis: If there is no problem in last call, just move it forward? Small changes may be required to support OSPF/RTP changes.

George: that is okay with me. We will do a last call, raise these issues and try to close them. If closed, then document is finished.

Sharma  Vishal  Expanded ERO for RSVP-TE

Overview. Lets make this an informational document on how to form EROs and move it forward that way.

George: Questions?

Matt: Asked to clarify.

Vishal: Yes.

George: Turn another draft and will ask later.

Qa: Don=92t want to move it forward.

G: Isn=92t being moved forward. We will re-spin another version of this document. Come to London for more information.

Agarawal  TTL Processing in MPLS Networks

Draft covers different ways of processing TTL. Overview. Would like to update according to comments from list and move forward to last call.

Matt: Document is useful and technical content is good. Figures would be useful. Document is difficult to read. Pipe/Hose model are mixed in document. Put them in a their own places in the document?

Q1: I don=92t see how TTLs are specified in NTAPs draft.

A: Some models are not described in that document.

Q1: There might be some difficulty with your approach.

Rosen: There is already a document that specifies how TTL processing works. Lets just put pipe model in here only, otherwise we duplicate things explained in RFC 3032.
I think that we need to organize the discussion around the point of the organization of this document (what is not covered and what is).

E: You don=92t need a separate procedure for nested procedure; already covered in 3032. Discussion did not complete on mailing list. There is a lot that needs to be clarified.

A: What are you proposing?

E: I think that you are proposing changes and additions (specified and unspecified). Need to specified which is which. Need to reach consensus on whether or not they are necessary. Do we need a document that obsoletes pieces of rfc3033.

George:  this is an information proposal. We cannot contradict something that is in a standard. Lets continue this discussion on the mailing list.

Egray: I was going to say what george just said. Define something in a standard specification and explain something in an informational.

George: Cannot contradict what was in the rfc. Take it to the list.


Matsushima  ttl processing expansion for 1 hop lsp

Overview. Next steps: merge with Puneet=92s ttl draft. Would like to become a wg draft.  Need signaling extensions for 1-hop lsp.

George: Discussion?

Rosen: There are two schools of thought on TTL processing. Don=92t think there is a need to specify TTL on a per-lsp basis. I don=92t think that there is a problem that we need to solve here.

Matt: I agree with eric. The terminology for a 1-hop lsp is different from what they define. 

Luca: I agree with Eric=92s comments. I don=92t see the use of specifying th= e behavior on a per-lsp basis.

Q: I don=92t think that this is what ttl was designed for.

George: Continue discussion on mailing list.

Paridaens  End to End Authentication for ldp

Overview. Presented requirements. What we are asking is that this be adopted as a wg draft. This work is part of the charter, so it should be accepted.

Scott: What operators have expressed interest in this technology and have the security geeks looked at this?

Q: I don=92t see any carriers looking at this. This method is expensive.

Parid: The cost is not so heavy.

Q: The other routing protocols work fine without authentication. If that is not a problem there, then why is this necessary here?

Paris: There are options as part of other protocols for authentication. It is necessary in other protocols and applications of them.

Q: All vendors are required to implement these drafts, and I don=92t think that it is necessary. I would like to see the requirements document for this sort of work.

George: I would like to see a clear indication from the carriers that this is necessary.

Q: We had this discussion in San Diego. The consensus there was that this is overkill. Similar mechanisms are already available in TCP.

George: The charter items must not be worked on, they can be worked on.

Q: There is no explicit =93why=94 about doing this from carriers.

Qb: I am not comfortable with this solution, but there seemed to be a clear statement in San Diego for non-hop-by-hop authentication.

George: Can some of those people speak up?

Qd: I made this proposal. There was some support at this time.

Qe: This looks like S-BGP which was roundly rejected because it was overkill/unfeasible. There is precident for this not being what vendors want.

George: We need to figure out what providers want first. We don=92t have consensus.

Qf: Providers want security, but this is not really what we are looking for.

George: Lets get some carriers to give us some contributions for what they would like to see in this space. Continue discussion on this mailing list.

Black  Update on LDP Path MTU  black-ldp-mtu-extensions-00.txt

Overview. Simple extension to ldp to allow automatic signaling of mtu detection. Allows proper fragmentation of packets within the MPLS domain. Support RFC1191 too. Version 00 has been out for some time. Lots of comments received. Asked that this be accepted as a wg document.

George: discussion

Curtis: What happens if along the way, one hop is inside a hierarchtical tunnel or if bypass tunnels are used. In both cases, the router negotiating a hop is not aware that somewhere in the middle that a bypass exists.

Black: If hierarchtical, the outermost tunnel=92s mtu is used.  There is an lsr somewhere that can see the bypass which can unsolicited signal the mtu change. It will pick the lesser of the two=92s path.

George: Anything that causes an impulse into signaling during a failure is bad.

Rosen: In practice, a typical situation a packet with dm bit set, packets go through Firewalls that strip the tos bits off the packet. This solution does not solve the problem.

Black: In some cases, path MTU signaling in some cases is not valid to not solve the problem altogether. Second, there are other reasons for doing this: packets being fragmented in/out of MPLS domain.

Rosen: Both packets have df bits set.

Curtis: There are places where this is necessary: no NATs and high performance IP.

Matt: I haven=92t seen demands from the carriers for this functionality, eventhough I like it.

Scott: Process point: is this in the charter?

George: Gray area. We should work to get MPLS to work.

Scott: WG can change charter if necessary. Charter is description of what we should be doing within a certain time period.

Q1: Carriers are interested in this.

Black: RSVP has this functionality.


George: We now have three presentations that are not in the gray area. They are outside of the charter. We are going into =93BOF=94 mode to see if there is interest to expand the charter.


Senevirath -- Secure MPLS  draft-tsenevir-smpls-01, tsenevir-smpls-doi-00
Overview. Applications: Most metro applications use MPLS.

Q1: In your first slide, you stated that most MPLS Metro carriers use MPLS. Which country are you talking about?

Sen: US.

Q1: Do you know which vendors are supporting MPLS in the metro=20 area.

Q2: Most operators use f/r links. The law prohibits them from monitoring authentications. Can authentications be monitored on MPLS. Even if we have mpls security on a backbone. MPLS is an end-to-end problem. This does not seem to be useful unless it is end to end.

Bilel J: Where are you getting the requirements for this draft.

Sen: These requirements are coming from the optical development going on in the world.

George: Take the discussion to the mailing list.



Disk Ooms  MPLS multicast Traffic Engineering

Overview. Questions.

George: This work was started a long time ago. There was no interest in this at that time. What has changed?

Disk: Now there is SSMulticast.

George: I think that you should change the name of your document to =93support for SSM=94. Describe your document in this way.

Disk: this is an alternative to SSM, not a tunnel through it.

George: I guess the amount of time we have left, we should see if there is interest on the mailing list.

Rosen: As far as SSM, there are other solutions to the problem of passing multicast packets back to the root.

Disk: There are other solutions, but they are undocumented as of yet.

Q1: I wasn=92t clear why SSM makes this more interesting. Also it isn=92t clear how you distribute the labels using TE. Where is the definition of TE is not clearly defined in the draft.

Disk: Traffic engineering allows you to construct a tree, which deviates from the one created in unicast.

George: The interest in SSM is more interesting than general multicast, and it is an easier problem to solve. Lets continue discussion on the mailing list.



Davari  MPLS OAM  draft-harrison-mpls-oam-00.txt
Overview.  Status of this document: ITU SG14-Q3. Requirements are defined. Availability is defined. OAM Packets are defined. Connectivity verification is worked out.  Future work: LSP performance work. Summary: OAM is necessary for user-plane, independent of control-plane. This draft introduces OAM requirements and simple OAM functions. Determining connectivity/availability. MPLS OAM was previously defined in MPLS charter. If interested, it should be added to charter and document accepted as a work item.

Q: I think this work is very useful. It will increase the performance of the MPLS network. Recovery framework is applicable. Performance benchmarking applies. This is useful for fault-tollerance.

Curtis: How does this apply to the Bonica work? We should go to the TE Wg and see what their requirements are for this.

Rosen: I think that some of the stuff in the beginning is important. I think this document is not a good piece of work that are not defined in the IETF. It has a very ATM-flavor. It does not handle a lot of stuff like multi-point-to-point. Even if we were to add measurement to charter, lets not accept this document to the charter.

Davari  This is optional. Carriers want this.

Q2: I don=92t think that this is useful. I think that it is not useful in an LSR. I can see this to be useful if GSMP is being used.  Useful in detecting configuration errors, otherwise lets assume that the LSR works okay.

Q3: I second that. I don=92t buy the argument that software is broken, so we need to add more software.

Scott: My problem with the document is that it mixes light requirements with lots of suggestions. It would be useful to have a clear requirements document (TE WG) that specifies what it is that you are trying to find out with this approach. That would be helpful for TE WG.

Q4: I think that the notion at the MPLS Layer is a useful construct for fault diagnosis.

Q5: The ITU is working on this. Can you send a pointer to this information on the ITU.

Davari: The information at the ITU is exactly the same information. ITU study group SG-13

Q6: I am not sure if the finding of errors is to be found in the te wg.

Davari: is it in the charter of te?

Scott: Thinking is in the charter of te. Management of this kind is not in the charter. However, if requirements can come forward and hint at which tools they could have would be a good thing.

Q6: I am not sure that availability is specified.

Davari: What we have done is take this from ATM and reduce most of what was there, and kept the best %1.

George: End of the agenda. See you in London.

















--=====================_16356369==_.ALT-- From owner-mpls@UU.NET Fri Mar 23 03:36:16 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29057 for ; Fri, 23 Mar 2001 03:36:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhok26528; Fri, 23 Mar 2001 08:35:05 GMT Received: by mail-control.mail.uu.net id QQkhok27845 for mpls-outgoing; Fri, 23 Mar 2001 08:34:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhok27840 for ; Fri, 23 Mar 2001 08:34:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhok00373 for ; Fri, 23 Mar 2001 08:34:17 GMT Received: from hclhprnd.hclt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkhok05760 for ; Fri, 23 Mar 2001 08:34:16 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id OAA22690; Fri, 23 Mar 2001 14:31:06 +0530 Received: from VIJAYC ([192.168.232.145]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2M202HK; Fri, 23 Mar 2001 14:03:11 +0530 From: "Vijayanand Chandrasekar" To: Cc: , , Subject: LDP MIB Date: Fri, 23 Feb 2001 14:03:30 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I have asked this question twice before but have'nt been able to get a reply.Can anyone please reply. IF there is a one to one correspondence between Entity and Session how will the entity be initialised. Should'nt each entity be configured initially with Label range, Label space, Targetted peer address etc, so that this info will be used for peer discovery and session establishment.The LdpId used in the PDU is that of the entity which should have been configured.If this is so then how can the number of sessions(hence entities) be known apriori, since this is as a result of peer discovery. Also, in the Entity Table the Enity Index is given as optional for implementations, what is the reason for this? Does it mean that we start of with an Enity configuration intially and for each new peer discovered and sesssion established the Entity Table is updated. Thanks in advance, Regards, Vijay From owner-mpls@UU.NET Fri Mar 23 11:21:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22191 for ; Fri, 23 Mar 2001 11:21:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhpp05816; Fri, 23 Mar 2001 16:19:46 GMT Received: by mail-control.mail.uu.net id QQkhpp13446 for mpls-outgoing; Fri, 23 Mar 2001 16:19:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhpp13439 for ; Fri, 23 Mar 2001 16:19:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhpp21400 for ; Fri, 23 Mar 2001 16:18:29 GMT Received: from iol.unh.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mars.iol.unh.edu [132.177.121.222]) id QQkhpp10023 for ; Fri, 23 Mar 2001 16:18:29 GMT Received: from localhost (mmeara@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA25313 for ; Fri, 23 Mar 2001 11:23:28 -0500 (EST) Date: Fri, 23 Mar 2001 11:23:28 -0500 From: "Michael H. O'Meara" To: mpls@UU.NET Subject: Use of the U-bit for TLV encoding in LDP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello all, Section 3.3 of RFC 3036, the LDP Specification, states the following about the usage of the U-bit in TLV encoding: U bit Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear (=0), a notification must be returned to the message originator and the entire message must be ignored; if U is set (=1), the unknown TLV is silently ignored and the rest of the message is processed as if the unknown TLV did not exist. The sections following that define TLVs specify a value for the U-bit. The RFC goes on to specify the value of the U-bit for most TLVs. However, no value is specified for certain optional TLVs, such as the Configuration Sequence TLV and Transport Address TLVs that are optional in Hello messages. Is it safe to assume, then, that the value for the U-bit in these optional TLVs is left to the discretion of those implementing the RFC? While an expected value for the U-bit is obvious for certain of these TLVs (as silently ignoring a Transport Address TLV, for example, could lead to some difficulty in establishing an LDP session TCP connection), there seems to be some leeway, and thus the potential for occasional interoperability problems, for some of the other optional TLVs. If I am missing something in the RFC, or making problems where there are none, please point me in the right direction. Thanks in advance, Mike *************************** Michael O'Meara Technician MPLS Consortium InterOperability Lab University of New Hampshire *************************** From owner-mpls@UU.NET Fri Mar 23 14:23:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01340 for ; Fri, 23 Mar 2001 14:23:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhqb02427; Fri, 23 Mar 2001 19:20:56 GMT Received: by mail-control.mail.uu.net id QQkhqb21834 for mpls-outgoing; Fri, 23 Mar 2001 19:20:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhqb21813 for ; Fri, 23 Mar 2001 19:20:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhqb11350 for ; Fri, 23 Mar 2001 19:19:42 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhqb22716 for ; Fri, 23 Mar 2001 19:19:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA10293 for mpls@uu.net; Fri, 23 Mar 2001 14:19:41 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhqb21384 for ; Fri, 23 Mar 2001 19:15:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhqa02666; Fri, 23 Mar 2001 19:14:26 GMT Received: from netmail2.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkhqa15184; Fri, 23 Mar 2001 19:14:25 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA17842; Fri, 23 Mar 2001 13:14:24 -0600 (CST) Received: from adn.alcatel.com ([198.205.41.68]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA2A3; Fri, 23 Mar 2001 14:27:02 -0500 Message-ID: <3ABBA0EA.99E22C6D@adn.alcatel.com> Date: Fri, 23 Mar 2001 14:15:54 -0500 From: "Rao Vadlamani" Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "mpls@UU.NET" , "te-wg@UU.NET" Subject: Two TE MIBs Content-Type: multipart/mixed; boundary="------------130EE98550E883B4FE4553A4" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------130EE98550E883B4FE4553A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Could someone clarify as to why there are 2 draft TE MIB's draft-ietf-mpls-te-mib-06.txt of Thomas D. Nadeu etal and draft-ietf-tewg-mib-00.txt of Kireeti ? If I understand, both are going for a IESG approval, too. If my understanding is correct both the MIBs are giving more or less the same information. except in the second MIB of kireeti, all the objects are only read-only and operator can't exercise control over them ? What's the motivation behind this ? Thanks in advance for the clarification and I am sorry to pose this question if this is already raised and discussed. Regards Rao --------------130EE98550E883B4FE4553A4 Content-Type: text/x-vcard; charset=us-ascii; name="Rao.Vadlamani.vcf" Content-Description: Card for Rao Vadlamani Content-Disposition: attachment; filename="Rao.Vadlamani.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vadlamani;Rao tel;cell:(703)-282-7399 tel;fax:(703)-679-6450 tel;home:(703)-390-1174 tel;work:(703)-679-6430 x-mozilla-html:FALSE url:www.alcatel.com org:Alcatel USA version:2.1 email;internet:rao.vadlamani@adn.alcatel.com adr;quoted-printable:;;15036 Conference Center Drive=0D=0A=0D=0A=0D=0A;Chantilly;VA;20151;USA fn:Rao Vadlamani end:vcard --------------130EE98550E883B4FE4553A4-- From owner-mpls@UU.NET Fri Mar 23 14:57:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02561 for ; Fri, 23 Mar 2001 14:57:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhqd15294; Fri, 23 Mar 2001 19:55:06 GMT Received: by mail-control.mail.uu.net id QQkhqd24980 for mpls-outgoing; Fri, 23 Mar 2001 19:54:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhqd24969 for ; Fri, 23 Mar 2001 19:54:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhqd01251 for ; Fri, 23 Mar 2001 19:53:08 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhqd19528 for ; Fri, 23 Mar 2001 19:53:07 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA13494 for mpls@uu.net; Fri, 23 Mar 2001 14:53:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhqd24496 for ; Fri, 23 Mar 2001 19:48:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhqd22243; Fri, 23 Mar 2001 19:47:52 GMT Received: from boyle.eng.level3.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu26-240-223.nc.rr.com [66.26.240.223]) id QQkhqd12378; Fri, 23 Mar 2001 19:47:52 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id NAA02643; Fri, 23 Mar 2001 13:12:07 -0700 Date: Fri, 23 Mar 2001 13:12:06 -0700 (MST) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: Rao Vadlamani cc: "mpls@UU.NET" , "te-wg@UU.NET" Subject: Re: Two TE MIBs In-Reply-To: <3ABBA0EA.99E22C6D@adn.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk please consult the mailing list archives, this has been well discussed. Jim p.s. mailing list archives can be found on WG homepages, which are off of www.ietf.org On Fri, 23 Mar 2001, Rao Vadlamani wrote: > Hello, > > Could someone clarify as to why there are 2 draft TE MIB's > draft-ietf-mpls-te-mib-06.txt of Thomas D. Nadeu etal and > draft-ietf-tewg-mib-00.txt of Kireeti ? If I understand, both are going > for a IESG approval, too. If my understanding is correct both the MIBs > are giving more or less the same information. except in the second MIB > of kireeti, all the objects are only read-only and operator can't > exercise control over them ? What's the motivation behind this ? > > Thanks in advance for the clarification and I am sorry to pose this > question if this is already raised and discussed. > > Regards > Rao > > From owner-mpls@UU.NET Fri Mar 23 15:34:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03136 for ; Fri, 23 Mar 2001 15:34:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhqg03602; Fri, 23 Mar 2001 20:31:51 GMT Received: by mail-control.mail.uu.net id QQkhqg15044 for mpls-outgoing; Fri, 23 Mar 2001 20:31:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhqg14986 for ; Fri, 23 Mar 2001 20:31:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhqg27495 for ; Fri, 23 Mar 2001 20:30:45 GMT Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: int.zaffire.com [63.121.21.2]) id QQkhqg02186 for ; Fri, 23 Mar 2001 20:30:44 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Mar 2001 12:34:51 -0800 Message-ID: <4611AD058694D4118FD5009027B0A6622B8C5A@ICARIAN> From: Fong Liaw To: "'manoj juneja'" , slakkapr@nortelnetworks.com Cc: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: Please Clarify on O-UNI Issues.... Date: Fri, 23 Mar 2001 12:34:45 -0800 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 Manoj Both drafts (2000.125 and ldp) are out of date after the Tempa OIF meeting. In particular, the use of Addres Resolution Qurey, and resolution will/should be removed from the updated 2000.125 UNI version in both RSVP and LDP sections. -Fong > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Tuesday, March 20, 2001 3:59 PM > To: slakkapr@nortelnetworks.com > Cc: mpls@UU.NET; ip-optical@lists.bell-labs.com > Subject: Re: Please Clarify on O-UNI Issues.... > > > Hi Shobhan, > > There is some difference in both oif2000.125.3 and IETF > O-UNI drafts. In IETF O-UNI, there are no messages like Address > Resolution Query, Address Resolution Response. > Also, It is written that FEC TLV has no significance at UNI. > If it is > present then it should be ignored. Please elaborate more on this. > > Regards, > manoj. > > > > >From: Shobhan Lakkapragada > >Reply-To: slakkapr@nortelnetworks.com > >To: manoj juneja > >CC: mpls@uu.net, ip-optical@lists.bell-labs.com > >Subject: Re: Please Clarify on O-UNI Issues.... > >Date: Tue, 20 Mar 2001 18:40:17 -0500 > > > > > >Manoj, > > > >If you have access to OIF specs, please see the LDP > >UNI signaling section of oif2000.125.3. It has definitions > >of LDP messages for Address Resolution, among other > >things. Although it comes from a different SB, both > >OIF work and IETF drafts seem to be in sync for O-UNI. > > > >- shobhan > > > > > > > >manoj juneja wrote: > > > > > Hi All, > > > I was going through the draft > > > "draft-ietf-mpls-ldp-optical-uni-00.txt", but I could > not find the > >complete > > > picture related to neighbor discovery, Address > Resolution issues. Can > > > someone please give a pointer to some other draft which > is pre-requisite > >for > > > this one (O-UNI draft). Is there more work going on O-UNI draft ? > > > I could not find even a single draft which talks from > architectural > > > viewpoint. There is one architecture document > (gmpls-arch-00.txt), this > > > document also lacks lot of information. > > > > > > Please help. > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > From owner-mpls@UU.NET Fri Mar 23 17:23:00 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05193 for ; Fri, 23 Mar 2001 17:23:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhqn01968; Fri, 23 Mar 2001 22:20:32 GMT Received: by mail-control.mail.uu.net id QQkhqn26890 for mpls-outgoing; Fri, 23 Mar 2001 22:19:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhqn26881 for ; Fri, 23 Mar 2001 22:19:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhqn16690 for ; Fri, 23 Mar 2001 22:19:32 GMT Received: from sutton.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.96.170.5]) id QQkhqn00346 for ; Fri, 23 Mar 2001 22:19:31 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by sutton.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-69929U800L2S100V35) with ESMTP id ca for ; Fri, 23 Mar 2001 17:21:19 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Mar 2001 17:19:25 -0500 Message-ID: From: Eyad Saheb To: "'mpls@uu.net'" Subject: Dest IP addr in MPLS Date: Fri, 23 Mar 2001 17:19:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B3E7.51254C30" 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_01C0B3E7.51254C30 Content-Type: text/plain; charset="iso-8859-1" Hello, I am unclear on the proper IP address to use as IP_DEST in RSVP-TE packets, especially when switches are involved. Unfortunately, the "standards" docs aren't too clear on this point (IMHO). I will illustrate my point: 1 - 2 - 3 - 4 \ / 5 -----/ In the above topology, if Router 1 wants to establish a path to Router 4 through 2 & 3 it will create an RSVP-TE packet with IP_DEST = 4 & and ERO = 2,3,4. Correct ? This should override the IGP routing table which would probably indicate router 5 as the 'correct' next-hop from router 1. However, consider the following: +-+ | |- 2 1 -| |- 3 | |- 4 +-+ In this case, all routers are connected via a switch. If the same RSVP-TE packet is sent over this network, it would reach router 4 directly. It would then reject the packet since it'snot the first node in the ERO. Is this expected ? Was RSVP-TE designed to be run over 'switched' networks ? Regards, Eyad ------_=_NextPart_001_01C0B3E7.51254C30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dest IP addr in MPLS

Hello,

        I am = unclear on the proper IP address to use as IP_DEST in RSVP-TE packets, = especially when switches are involved.  Unfortunately, the = "standards" docs aren't too clear on this point (IMHO).  = I will illustrate my point:

1 - 2 - 3 - 4
  \        = / 
   5 -----/

In the above topology, if Router 1 wants to establish = a path to Router 4 through 2 & 3 it will create an RSVP-TE packet = with IP_DEST =3D 4 & and ERO =3D 2,3,4.  Correct ?  This = should override the IGP routing table which would probably indicate = router 5 as the 'correct' next-hop from router 1.

However, consider the following:

     +-+
     | |- 2
  1 -| |- 3
     | |- 4
     +-+

In this case, all routers are connected via a = switch.  If the same RSVP-TE packet is sent over this network, it = would reach router 4 directly.  It would then reject the packet = since it'snot the first node in the ERO.  Is this expected = ?

Was RSVP-TE designed to be run over 'switched' = networks ?

Regards,

        Eyad

------_=_NextPart_001_01C0B3E7.51254C30-- From owner-mpls@UU.NET Fri Mar 23 18:14:56 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05708 for ; Fri, 23 Mar 2001 18:14:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhqq09752; Fri, 23 Mar 2001 23:12:20 GMT Received: by mail-control.mail.uu.net id QQkhqq17252 for mpls-outgoing; Fri, 23 Mar 2001 23:11:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhqq17238 for ; Fri, 23 Mar 2001 23:11:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhqq12679 for ; Fri, 23 Mar 2001 23:10:13 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhqq18511 for ; Fri, 23 Mar 2001 23:10:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA28489 for mpls@uu.net; Fri, 23 Mar 2001 18:10:12 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhqp29805 for ; Fri, 23 Mar 2001 22:57:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhqp03822 for ; Fri, 23 Mar 2001 22:57:16 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkhqp09479 for ; Fri, 23 Mar 2001 22:57:16 GMT Received: from flefauch-8kcdt.cisco.com (sj-dial-4-78.cisco.com [171.68.181.207]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id XAA04417; Fri, 23 Mar 2001 23:57:11 +0100 (MET) Message-Id: <4.0.2.20010323200811.021b9f10@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 23 Mar 2001 20:13:44 +0100 To: "Thomas D. Nadeau" From: Francois Le Faucheur Subject: Re: MPLS WG Meeting Minutes Cc: mpls@UU.NET, swallow@cisco.com In-Reply-To: <4.3.2.7.2.20010322184552.01bd5d48@bucket.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_984962==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_984962==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom , George, > > MPLS DiffServ Update: Francois L. provided an update. Last call finished= in > diffServ WG. A clarification: the last call that just finished was actually an MPLS WG Last Call. This= Last Call was for the resolution of comments sent earlier during the Diff-Serv WG Last Call. > > Mostly minor comments to fix. Re-issue a final version which gets sent= over > to the IESG. Who to hand it over to? Rob Coltun: Hand it over to= Scott/Bert. thanks FRancois PLEASE NOTE NEW CONTACT DETAILS - See below _________________________________________________________________ Francois Le Faucheur =20 Development Engineer, IOS Layer 3 Services=20 Cisco Systems=20 Office Phone: +33 4 97 23 26 19 Mobile : +33 6 89 108 159 Fax: +33 4 97 23 26 26 Email: flefauch@cisco.com _________________________________________________________________ Cisco Systems Europe Domaine Green Side 400, Avenue de Roumanille B=E2timent T3 06 410 BIOT=20 SOPHIA ANTIPOLIS FRANCE _________________________________________________________________ =20 --=====================_984962==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom , George,


MPLS DiffServ Update: Francois L. provided an update. Last call finished in diffServ WG.

A clarification:
the last call that just finished was actually an MPLS WG Last Call. This Last Call was for the resolution of comments sent earlier during the Diff-Serv WG Last Call.

Mostly minor comments to fix. Re-issue a final version which gets sent over to the IESG. Who to hand it over to? Rob Coltun: Hand it over to Scott/Bert.

thanks

FRancois
PLEASE NOTE NEW CONTACT DETAILS - See below

_________________________________________________________= ________
Francois Le Faucheur  
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :            &nb= sp;  +33 6 89 108 159
Fax:            =        +33 4 97 23 26 26
Email:           &nbs= p;      flefauch@cisco.com
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
B=E2timent T3
06 410   BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________ --=====================_984962==_.ALT-- From owner-mpls@UU.NET Fri Mar 23 19:04:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06322 for ; Fri, 23 Mar 2001 19:04:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhqe26381; Fri, 23 Mar 2001 20:03:20 GMT Received: by mail-control.mail.uu.net id QQkhqe04369 for mpls-outgoing; Fri, 23 Mar 2001 20:02:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhqe04045 for ; Fri, 23 Mar 2001 20:02:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhqe21755 for ; Fri, 23 Mar 2001 20:01:57 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhqe24778 for ; Fri, 23 Mar 2001 20:01:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA14728 for mpls@uu.net; Fri, 23 Mar 2001 15:01:55 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkhqd25258 for ; Fri, 23 Mar 2001 19:57:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhqd21152; Fri, 23 Mar 2001 19:57:12 GMT Received: from netmail2.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkhqd18341; Fri, 23 Mar 2001 19:57:07 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA25740; Fri, 23 Mar 2001 13:57:07 -0600 (CST) Received: from adn.alcatel.com ([198.205.41.68]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA9E3; Fri, 23 Mar 2001 15:09:44 -0500 Message-ID: <3ABBAAEC.2CD7236C@adn.alcatel.com> Date: Fri, 23 Mar 2001 14:58:36 -0500 From: "Rao Vadlamani" Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Boyle CC: "mpls@UU.NET" , "te-wg@UU.NET" Subject: Re: Two TE MIBs References: Content-Type: multipart/mixed; boundary="------------6CB2CDDA8899BF058B514FD1" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------6CB2CDDA8899BF058B514FD1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks, Jim. It would be nice if there is a summary of discussions, since the archives takes longer to search. Regards Jim Boyle wrote: > please consult the mailing list archives, this has been well discussed. > > Jim > > p.s. mailing list archives can be found on WG homepages, which are > off of www.ietf.org > > On Fri, 23 Mar 2001, Rao Vadlamani wrote: > > > Hello, > > > > Could someone clarify as to why there are 2 draft TE MIB's > > draft-ietf-mpls-te-mib-06.txt of Thomas D. Nadeu etal and > > draft-ietf-tewg-mib-00.txt of Kireeti ? If I understand, both are going > > for a IESG approval, too. If my understanding is correct both the MIBs > > are giving more or less the same information. except in the second MIB > > of kireeti, all the objects are only read-only and operator can't > > exercise control over them ? What's the motivation behind this ? > > > > Thanks in advance for the clarification and I am sorry to pose this > > question if this is already raised and discussed. > > > > Regards > > Rao > > > > --------------6CB2CDDA8899BF058B514FD1 Content-Type: text/x-vcard; charset=us-ascii; name="Rao.Vadlamani.vcf" Content-Description: Card for Rao Vadlamani Content-Disposition: attachment; filename="Rao.Vadlamani.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vadlamani;Rao tel;cell:(703)-282-7399 tel;fax:(703)-679-6450 tel;home:(703)-390-1174 tel;work:(703)-679-6430 x-mozilla-html:FALSE url:www.alcatel.com org:Alcatel USA version:2.1 email;internet:rao.vadlamani@adn.alcatel.com adr;quoted-printable:;;15036 Conference Center Drive=0D=0A=0D=0A=0D=0A;Chantilly;VA;20151;USA fn:Rao Vadlamani end:vcard --------------6CB2CDDA8899BF058B514FD1-- From owner-mpls@UU.NET Sun Mar 25 08:13:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13683 for ; Sun, 25 Mar 2001 08:13:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhwm12904; Sun, 25 Mar 2001 13:13:25 GMT Received: by mail-control.mail.uu.net id QQkhwm09273 for mpls-outgoing; Sun, 25 Mar 2001 13:12:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhwm09238 for ; Sun, 25 Mar 2001 13:12:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhwm03050 for ; Sun, 25 Mar 2001 13:12:18 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkhwm23421 for ; Sun, 25 Mar 2001 13:12:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA10769 for mpls@uu.net; Sun, 25 Mar 2001 08:12:16 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhwm08642 for ; Sun, 25 Mar 2001 13:07:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhwm25207; Sun, 25 Mar 2001 13:07:49 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkhwm03017; Sun, 25 Mar 2001 13:07:49 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29349; Sun, 25 Mar 2001 08:06:52 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA20172; Sun, 25 Mar 2001 08:07:36 -0500 (EST) Message-Id: <4.3.2.7.2.20010324102105.0171e848@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 25 Mar 2001 08:07:04 -0500 To: "Rao Vadlamani" , "mpls@UU.NET" , "te-wg@UU.NET" From: "Thomas D. Nadeau" Subject: Re: Two TE MIBs Cc: cheenu Srinivasan , Arun Viswanathan In-Reply-To: <3ABBA0EA.99E22C6D@adn.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >Could someone clarify as to why there are 2 draft TE MIB's >draft-ietf-mpls-te-mib-06.txt of Thomas D. Nadeu etal and >draft-ietf-tewg-mib-00.txt of Kireeti ? If I understand, both are going >for a IESG approval, too. If my understanding is correct both the MIBs >are giving more or less the same information. except in the second MIB >of kireeti, all the objects are only read-only and operator can't >exercise control over them ? What's the motivation behind this ? >Thanks in advance for the clarification and I am sorry to pose this >question if this is already raised and discussed. Beats me why there are two, but I am not going to beat a dead horse and argue about it any longer though. This was discussed at length late last summer, and I suggest you go back and re-read the archive so that you can come to your own informed conclusion. The outcome of the discussion at that time was that IESG agreed to have two. --Tom From owner-mpls@UU.NET Sun Mar 25 15:20:43 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08586 for ; Sun, 25 Mar 2001 15:20:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhxp07067; Sun, 25 Mar 2001 20:19:59 GMT Received: by mail-control.mail.uu.net id QQkhxp07957 for mpls-outgoing; Sun, 25 Mar 2001 20:19:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkhxp07943 for ; Sun, 25 Mar 2001 20:19:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhxp28078; Sun, 25 Mar 2001 20:18:14 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkhxp28692; Sun, 25 Mar 2001 20:18:14 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 PAA06809; Sun, 25 Mar 2001 15:18:10 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA06786; Sun, 25 Mar 2001 15:18:09 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 25 Mar 2001 22:18:08 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0BC0B6A4@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Rao Vadlamani , mpls@UU.NET, te-wg@UU.NET, "Thomas D. Nadeau" Cc: cheenu Srinivasan , Arun Viswanathan Subject: RE: Two TE MIBs Date: Sun, 25 Mar 2001 22:18:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Inline > ---------- > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > Sent: Sunday, March 25, 2001 3:07 PM > To: Rao Vadlamani; mpls@UU.NET; te-wg@UU.NET > Cc: cheenu Srinivasan; Arun Viswanathan > Subject: Re: Two TE MIBs > > > Hi, > > >Could someone clarify as to why there are 2 draft TE MIB's > >draft-ietf-mpls-te-mib-06.txt of Thomas D. Nadeu etal and > >draft-ietf-tewg-mib-00.txt of Kireeti ? If I understand, both are going > >for a IESG approval, too. If my understanding is correct both the MIBs > >are giving more or less the same information. except in the second MIB > >of kireeti, all the objects are only read-only and operator can't My understanding is that Kireeti was going to change MAX-ACCESS to read-create or read-write > >exercise control over them ? What's the motivation behind this ? > >Thanks in advance for the clarification and I am sorry to pose this > >question if this is already raised and discussed. > > Beats me why there are two, but I am not going to beat > a dead horse and argue about it any longer though. This was discussed > at length late last summer, and I suggest you go back and re-read > the archive so that you can come to your own informed conclusion. > The outcome of the discussion at that time was that IESG agreed to > have two. > But we prefer to have no (or as few as possible) overlaps. Maybe we need to check how this can be achieved. My understanding at the time of a quick briefing was that they do different things. Specifically the MIB(s) developed in MPLS WG have lots of stuff to be able to "debug" MPLS. Also... the message I got was that the MIB from MPLS WG was to be run at each node, while the TE-WG MIB does not need to run at each node. I will look into these MIBs in more detail over the next weeks. Bert > --Tom > > > From owner-mpls@UU.NET Sun Mar 25 16:30:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15063 for ; Sun, 25 Mar 2001 16:30:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhxt16840; Sun, 25 Mar 2001 21:29:30 GMT Received: by mail-control.mail.uu.net id QQkhxt29664 for mpls-outgoing; Sun, 25 Mar 2001 21:28:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhxt29640 for ; Sun, 25 Mar 2001 21:28:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhxt14922; Sun, 25 Mar 2001 21:26:51 GMT Received: from localhost.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-201-33-109.dsl.snfc21.pacbell.net [63.201.33.109]) id QQkhxt10597; Sun, 25 Mar 2001 21:26:50 GMT Received: from localhost (localhost [127.0.0.1]) by localhost.pluris.com (8.10.2/8.10.2) with ESMTP id f2PLQkp00296; Sun, 25 Mar 2001 13:26:46 -0800 (PST) Message-Id: <200103252126.f2PLQkp00296@localhost.pluris.com> Date: Sun, 25 Mar 2001 13:26:45 -0800 From: Bora Akyol Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: Two TE MIBs Cc: mpls@UU.NET, te-wg@UU.NET To: "Wijnen, Bert (Bert)" X-Mailer: Apple Mail (2.387) In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0BC0B6A4@nl0006exch002u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v387) Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Of course some of the vendors may be implementing a MIB that combines the best parts of both of these. Bora Who thinks having one MIB would have been easier. On Sunday, March 25, 2001, at 12:18 PM, Wijnen, Bert (Bert) wrote: > Inline > >> ---------- >> From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] >> Sent: Sunday, March 25, 2001 3:07 PM >> To: Rao Vadlamani; mpls@UU.NET; te-wg@UU.NET >> Cc: cheenu Srinivasan; Arun Viswanathan >> Subject: Re: Two TE MIBs >> >> >> Hi, >> >>> Could someone clarify as to why there are 2 draft TE MIB's >>> draft-ietf-mpls-te-mib-06.txt of Thomas D. Nadeu etal and >>> draft-ietf-tewg-mib-00.txt of Kireeti ? If I understand, both are >>> going >>> for a IESG approval, too. If my understanding is correct both the MIBs >>> are giving more or less the same information. except in the second MIB >>> of kireeti, all the objects are only read-only and operator can't > My understanding is that Kireeti was going to change MAX-ACCESS to > read-create or read-write >>> exercise control over them ? What's the motivation behind this ? >>> Thanks in advance for the clarification and I am sorry to pose this >>> question if this is already raised and discussed. >> >> Beats me why there are two, but I am not going to beat >> a dead horse and argue about it any longer though. This was discussed >> at length late last summer, and I suggest you go back and re-read >> the archive so that you can come to your own informed conclusion. >> The outcome of the discussion at that time was that IESG agreed to >> have two. >> > But we prefer to have no (or as few as possible) overlaps. > Maybe we need to check how this can be achieved. > > My understanding at the time of a quick briefing was that they do > different > things. Specifically the MIB(s) developed in MPLS WG have lots of stuff > to be able to "debug" MPLS. Also... the message I got was that the MIB > from MPLS WG was to be run at each node, while the TE-WG MIB > does not need to run at each node. > > I will look into these MIBs in more detail over the next weeks. > > Bert > >> --Tom >> >> >> > From owner-mpls@UU.NET Mon Mar 26 00:10:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18091 for ; Mon, 26 Mar 2001 00:10:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhyy01645; Mon, 26 Mar 2001 05:08:51 GMT Received: by mail-control.mail.uu.net id QQkhyy17758 for mpls-outgoing; Mon, 26 Mar 2001 05:08:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhyy17741 for ; Mon, 26 Mar 2001 05:08:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhyy29068 for ; Mon, 26 Mar 2001 05:07:31 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQkhyy25601 for ; Mon, 26 Mar 2001 05:07:29 GMT Received: from LocalHost (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f2Q5B0421886 for ; Mon, 26 Mar 2001 14:11:03 +0900 (KST) Message-ID: <003401c0b5b2$73ad0960$77131796@sktelecom.com> From: "Rae M. Chang" To: Subject: References to MPLS TE routing algorithms? Date: Mon, 26 Mar 2001 14:05:58 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C0B5FD.E1A64EE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C0B5FD.E1A64EE0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpJJ20gc2VhcmNoaW5nIGZvciBhbnkgcmVmZXJlbmNlcyBvciBwb2ludGVy cyB0byByb3V0aW5nIGFsZ29yaXRobXMgZm9yIHRoZSBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcu DQpBbmQgSSdtIHdvbmRlcmluZyBpZiB0aGUgYWxnb3JpdGhtcyBvciBtZXRob2RvbG9naWVzIGhh dmUgYW55IGRpZmZlcmVudCBmZWF0dXJlcyBjb21wYXJlZCB3aXRoIHRoZSBleGlzdGluZyANCnJv dXRpbmcgbWV0aG9kcyBvZiB0aGUgcHJldmlvdXMgbGl0ZXJhdHVyZS4gWW91ciBoZWxwIHdpbGwg YmUgdmVyeSBhcHByZWNpYXRlZC4gVGhhbmsgeW91Lg0KDQpSYWUuDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIE15b25nLVJhZSBDaGFuZywgUGguRC4g Y21yQHNrdGVsZWNvbS5jb20gDQogIDRHIERldmVsb3BtZW50IFRlYW0gDQogIE5ldHdvcmsgUmVz ZWFyY2ggQ2VudGVyLCBTSyBUZWxlY29tDQogIDktMSBTdW5hZS1kb25nIFB1bmRhbmctZ3UgU3Vu Z25hbSBDaXR5IA0KICBLeXVuZ2dpLWRvIDQ2My0wMjAsIFNvdXRoIEtvcmVhDQogIE1vYmlsZTog KzgyLTExLTk4NzQtMzkyNiAgIA0KICBURUwgKzgyLTM0Mi03MTAtNTIwMSBGQVggKzgyLTMxLTcx MC01Mjk5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ------=_NextPart_000_0031_01C0B5FD.E1A64EE0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+DQo8RElWPjxGT05UIHNpemU9Mj5I ZWxsbyBhbGwsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSdtJm5ic3A7c2VhcmNoaW5nIGZvciBhbnkgcmVmZXJl bmNlcyBvciBwb2ludGVycyB0byByb3V0aW5nIA0KYWxnb3JpdGhtcyBmb3IgdGhlIE1QTFMgVHJh ZmZpYyBFbmdpbmVlcmluZy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5BbmQgSSdt IHdvbmRlcmluZyBpZiB0aGUgYWxnb3JpdGhtcyBvciBtZXRob2RvbG9naWVzIGhhdmUgYW55IA0K ZGlmZmVyZW50IGZlYXR1cmVzIGNvbXBhcmVkIHdpdGggdGhlIGV4aXN0aW5nIDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPnJvdXRpbmcgbWV0aG9kcyBvZiB0aGUgcHJldmlvdXMgbGl0 ZXJhdHVyZS4mbmJzcDtZb3VyIGhlbHAgDQp3aWxsIGJlIHZlcnkgYXBwcmVjaWF0ZWQuIFRoYW5r IHlvdTwvRk9OVD48Rk9OVCBzaXplPTI+LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJhZS48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4mbmJzcDsg DQpNeW9uZy1SYWUgQ2hhbmcsIFBoLkQuIDxBIGhyZWY9Im1haWx0bzpjbXJAc2t0ZWxlY29tLmNv bSI+Y21yQHNrdGVsZWNvbS5jb208L0E+IA0KPEJSPiZuYnNwOyA0RyBEZXZlbG9wbWVudCBUZWFt IDxCUj4mbmJzcDsgTmV0d29yayBSZXNlYXJjaCBDZW50ZXIsIFNLIA0KVGVsZWNvbTxCUj4mbmJz cDsgOS0xIFN1bmFlLWRvbmcgUHVuZGFuZy1ndSBTdW5nbmFtIENpdHkgPEJSPiZuYnNwOyBLeXVu Z2dpLWRvIA0KNDYzLTAyMCwgU291dGggS29yZWE8QlI+Jm5ic3A7IE1vYmlsZTogKzgyLTExLTk4 NzQtMzkyNiZuYnNwOyZuYnNwOyA8QlI+Jm5ic3A7IA0KVEVMICs4Mi0zNDItNzEwLTUyMDEgRkFY IA0KKzgyLTMxLTcxMC01Mjk5PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPC9GT05UPjwvRElWPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0031_01C0B5FD.E1A64EE0-- From owner-mpls@UU.NET Mon Mar 26 02:11:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22507 for ; Mon, 26 Mar 2001 02:11:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkhzg14319; Mon, 26 Mar 2001 07:10:34 GMT Received: by mail-control.mail.uu.net id QQkhzg00039 for mpls-outgoing; Mon, 26 Mar 2001 07:10:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhzg29975 for ; Mon, 26 Mar 2001 07:09:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhzg14228 for ; Mon, 26 Mar 2001 07:09:30 GMT Received: from tju.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserver.tju.edu.cn [202.113.15.13]) id QQkhzg08701 for ; Mon, 26 Mar 2001 07:09:27 GMT Received: from rose.tju.edu.cn (rose.tju.edu.cn [202.113.0.9]) by tju.edu.cn (8.9.1b+Sun/8.9.1) with ESMTP id PAA28205 for ; Mon, 26 Mar 2001 15:03:02 +0800 (CST) Received: from rose ([202.113.4.43]) by rose.tju.edu.cn (8.9.3/8.8.7) with SMTP id PAA19504 for ; Mon, 26 Mar 2001 15:02:54 +0800 Message-Id: <200103260702.PAA19504@rose.tju.edu.cn> Date: Mon, 26 Mar 2001 15:4:12 +0800 From: STONE CHEN To: "mpls@uu.net" Subject: routing algorithms for ATM X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hello everyone, I'm looking for some references or pointers to routing algorithms for ATM. And I'm wondering if the algorithms or methodologies have any different features compared with the existing routing methods of the previous literature. Thank you. From owner-mpls@UU.NET Mon Mar 26 08:52:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22507 for ; Mon, 26 Mar 2001 08:52:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiah11272; Mon, 26 Mar 2001 13:50:35 GMT Received: by mail-control.mail.uu.net id QQkiah03308 for mpls-outgoing; Mon, 26 Mar 2001 13:49:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiah03290 for ; Mon, 26 Mar 2001 13:49:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiah13822 for ; Mon, 26 Mar 2001 13:49:22 GMT Received: from yc.shu.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.120.127.220]) id QQkiah12613 for ; Mon, 26 Mar 2001 13:49:21 GMT Received: from xyx ([202.120.127.81]) by yc.shu.edu.cn (8.9.3+Sun/8.9.1) with SMTP id VAA12757 for ; Mon, 26 Mar 2001 21:51:47 +0800 (CST) Message-ID: <001e01c0b5fc$4385c480$517f78ca@xyx> From: "Xu Yingxiao" To: Subject: What happened to "A Framework for Internet Traffic Engineering" Date: Mon, 26 Mar 2001 21:54:22 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C0B63F.512A5EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0B63F.512A5EA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBjYW4ndCBmaW5kIGl0ICBpbiBJRVRGIG1vdyhuZWl0aGVyIERyYWZ0IG5vciBSRkMgaW5kZXgp Lg0KaW4gIE1hcmNoIDIwMDAgDQpodHRwOi8vd3d3LmlpaGUuYWMuYmUvaW50ZXJuYWwtcmVwb3J0 LzIwMDAvc3RjLTAwLTAzLmh0bWwNCnNhaWQNCiJpdCB3b3VsZCBiZSBwcm9wb3NlZCBhcyBhbiBp bmZvcm1hdGlvbmFsIFJGQyBhZnRlciBzb21lIFRlcm1pbm9sb2d5IGNvbnNpZGVyYXRpb25zIHdp dGggcmVzcGVjdCB0byBjb21wYXRpYmlsaXR5IHdpdGggdGhlIERpZmZzZXJ2IFdvcmsgR3JvdXAg IGRvY3VtZW50cyBhcmUgYWRkcmVzc2VkLiAiDQoNCldoYXQgZG9lcyBpdCBtZWFucz8gV2h5IGNh bid0IGZpbmQgaW4gSUVGVCBub3c/DQo= ------=_NextPart_000_001B_01C0B63F.512A5EA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40MTM0LjEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgY2FuJ3QmbmJzcDtmaW5k IGl0Jm5ic3A7Jm5ic3A7aW4gSUVURiBtb3cobmVpdGhlciBEcmFmdCBub3IgDQpSRkMgaW5kZXgp LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmluJm5ic3A7IDxTUEFOIGxhbmc9RU4t VVM+PEZPTlQgc2l6ZT0rMT5NYXJjaCANCjwvRk9OVD48L1NQQU4+MjAwMCA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48QSANCmhyZWY9Imh0dHA6Ly93d3cuaWloZS5hYy5iZS9pbnRl cm5hbC1yZXBvcnQvMjAwMC9zdGMtMDAtMDMuaHRtbCI+aHR0cDovL3d3dy5paWhlLmFjLmJlL2lu dGVybmFsLXJlcG9ydC8yMDAwL3N0Yy0wMC0wMy5odG1sPC9BPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPnNhaWQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4iaXQgPC9G T05UPjxGT05UIHNpemU9Mz53b3VsZCBiZSBwcm9wb3NlZCBhcyBhbiBpbmZvcm1hdGlvbmFsIA0K UkZDIGFmdGVyIHNvbWUgVGVybWlub2xvZ3kgY29uc2lkZXJhdGlvbnMgd2l0aCByZXNwZWN0IHRv IGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgDQpEaWZmc2VydiBXb3JrIEdyb3VwJm5ic3A7IGRvY3Vt ZW50cyBhcmUgYWRkcmVzc2VkLiAiPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPldoYXQgZG9lcyBpdCBtZWFucz8gV2h5IGNhbid0IGZpbmQgaW4gSUVG VCANCm5vdz88L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_001B_01C0B63F.512A5EA0-- From owner-mpls@UU.NET Mon Mar 26 09:17:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26008 for ; Mon, 26 Mar 2001 09:17:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiai14174; Mon, 26 Mar 2001 14:14:54 GMT Received: by mail-control.mail.uu.net id QQkiai21658 for mpls-outgoing; Mon, 26 Mar 2001 14:14:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiai21653 for ; Mon, 26 Mar 2001 14:14:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiai28110 for ; Mon, 26 Mar 2001 14:13:22 GMT Received: from zrtps06u.us.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) id QQkiai03101 for ; Mon, 26 Mar 2001 14:13:22 GMT Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f2QEBtK25872 for ; Mon, 26 Mar 2001 09:11:55 -0500 (EST) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 26 Mar 2001 09:12:42 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Mar 2001 09:12:45 -0500 Message-ID: From: "Don Fedyk" To: manoj juneja , mpls@UU.NET Cc: gash@att.com, "Peter Ashwood-Smith" , "Bilel Jamoussi" , fedyk@nortelnetworks.com, skalecki@nortelnetworks.com, lili@ss8networks.com, ylee@irislabs.com Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" Date: Mon, 26 Mar 2001 09:12:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B5FE.CAC98920" 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_01C0B5FE.CAC98920 Content-Type: text/plain; charset="iso-8859-1" Manoj Usually the path modification is for TE LSP that are routed via an Explicit route. This means that they are not affected by next hop changes in IP routing. If the existing path is torn down due to a failure on the path then you have a couple of options. 1. Abort any modification and treat as a normal failure. 2. Handle the path release but wait for the new modification path in hope that it will still be valid. We have built 1. in the past. 2. is more difficult and a low percentage success rate. Don > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Wednesday, March 21, 2001 6:06 PM > To: mpls@UU.NET > Cc: gash@att.com; Ashwood-Smith, Peter [CAR:CS0I:EXCH]; > Jamoussi, Bilel > [BL60:2868-M:EXCH]; fedyk@nortelnetworks.com; > skalecki@nortelnetworks.com; lili@ss8networks.com; ylee@irislabs.com > Subject: Valid Race Condition related to draft > "draft-ietf-mpls-crlsp-modify-03.txt" > > > Hi All, > > Please comment on the following : > > If the LSP modification is in progress and in the meantime the > next hop for the same LSP changes then should the modification > procedure be aborted ? > > Regards, > manoj. > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > ------_=_NextPart_001_01C0B5FE.CAC98920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Valid Race Condition related to draft = "draft-ietf-mpls-crlsp-modify-03.txt"

Manoj


Usually the path modification is for TE LSP that are = routed via an Explicit route. This means that they are not affected by = next hop changes in IP routing. If the existing path is torn down due = to a failure on the path then you have a couple of options.

1. Abort any modification and treat as a normal = failure.
2. Handle the path release but wait for the new = modification path in hope that it will still be valid.

We have built 1. in the past. 2. is more difficult = and a low percentage success rate.

Don


> -----Original Message-----
> From: manoj juneja [mailto:manojkumarjuneja@hot= mail.com]
> Sent: Wednesday, March 21, 2001 6:06 PM
> To: mpls@UU.NET
> Cc: gash@att.com; Ashwood-Smith, Peter = [CAR:CS0I:EXCH];
> Jamoussi, Bilel
> [BL60:2868-M:EXCH]; = fedyk@nortelnetworks.com;
> skalecki@nortelnetworks.com; = lili@ss8networks.com; ylee@irislabs.com
> Subject: Valid Race Condition related to = draft
> = "draft-ietf-mpls-crlsp-modify-03.txt"
>
>
> Hi All,
>
>    Please comment on the = following :
>
>         = If the LSP modification is in progress and in the meantime the
> next hop for the same LSP changes then should = the modification
> procedure be aborted ?
>
> Regards,
> manoj.
>
>
>
>
> = _________________________________________________________________=
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>

------_=_NextPart_001_01C0B5FE.CAC98920-- From owner-mpls@UU.NET Mon Mar 26 09:27:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27471 for ; Mon, 26 Mar 2001 09:27:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiaj07498; Mon, 26 Mar 2001 14:25:20 GMT Received: by mail-control.mail.uu.net id QQkiaj22501 for mpls-outgoing; Mon, 26 Mar 2001 14:24:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiaj22488 for ; Mon, 26 Mar 2001 14:24:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiaj23160 for ; Mon, 26 Mar 2001 14:24:24 GMT Received: from mxtlv1.corrigent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.203.64.34]) id QQkiaj06748 for ; Mon, 26 Mar 2001 14:24:23 GMT Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 16:21:53 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B3531686FD@mxtlv1.corrigent.com> From: Jaakov Berkovitch To: mpls@UU.NET Subject: MPLS CIM schema Date: Mon, 26 Mar 2001 16:21:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: owner-mpls@UU.NET Precedence: bulk Hello, Is anybody know if there are some extension to the CIM Network schema for MPLS ? Thanks for any information. Yaakov Berkovitch Tel: 972 + 36945298 E-mail: jaakovb@corrigent.com WEB site: http://www.corrigent.com From owner-mpls@UU.NET Mon Mar 26 09:41:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29177 for ; Mon, 26 Mar 2001 09:41:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiak20681; Mon, 26 Mar 2001 14:39:32 GMT Received: by mail-control.mail.uu.net id QQkiak23702 for mpls-outgoing; Mon, 26 Mar 2001 14:38:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiak23685 for ; Mon, 26 Mar 2001 14:38:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiak04540 for ; Mon, 26 Mar 2001 14:37:26 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkiak17870 for ; Mon, 26 Mar 2001 14:37:26 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 JAA06885 for ; Mon, 26 Mar 2001 09:37:25 -0500 (EST) 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 JAA06869; Mon, 26 Mar 2001 09:37:25 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.183]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA09217; Mon, 26 Mar 2001 09:37:23 -0500 (EST) Message-ID: <3ABF5423.D7BE73D@lucent.com> Date: Mon, 26 Mar 2001 09:37:23 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: egray@sandburst.com CC: Fong Liaw , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Question regarding bi-directional connection set up - And Port-ID in Label object References: <4611AD058694D4118FD5009027B0A6622B8C30@ICARIAN> <3AB0DA8F.B364BEB0@lucent.com> <3AB7CA17.187DCE1E@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, Please see my comments embedded: > I'm not sure that merging them is the right thing to do. > They do not represent the same thing. I believe the > suggested label is the label the upstream would like the > downstream to assign/recognize while the upstream label > (I believe) is the label that the upstream _has_ assigned > for the use of the downstream in a corresponding reverse > LSP. > I agree with your understanding. However, one of the key differences between layer 1 transport network and IP network is data traffic direction is not related to connection creation direction in transport network. For example, A----B----.....----F----G (1) A uni-directional (user-traffic from A-->G) light path can be initiated either by A or G (2) So does a bi-directional light path So, in layer 1 transport network, downstream/upstream is according to signaling direction in control plane. It should have nothing to do with user plane traffic. Suggested label, upstream label ... are used to specify which trib to use for light path. What we need to have is directionality attribute for label. > There are two problems with trying to force the two to > be the same: > > o one is being assigned and the other is being requested > (assignment may not occur as requested), and In layer 1 transport network, label is bound to certain physical resource. Upstream label is only useful for a bi-directional LSP in a network where ports are uni-directionally identified. If all ports are uni-directional, this shouldn't happen. Label should directionality attribute. > o it is not always the case that the same label can be > assigned, in both directions, and associated with the > two halves of the same bi-directional LSP. > Directionality should be one attribute for "bundling". Transmit ports, receive ports and bi-directional ports can be assigned to different bundles, with unique bundle ID. Source node should choose the correct bundle ID for the connection it desires. Regards, Yangguang From owner-mpls@UU.NET Mon Mar 26 10:40:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09694 for ; Mon, 26 Mar 2001 10:40:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiao19181; Mon, 26 Mar 2001 15:37:47 GMT Received: by mail-control.mail.uu.net id QQkiao16467 for mpls-outgoing; Mon, 26 Mar 2001 15:37:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiao16462 for ; Mon, 26 Mar 2001 15:37:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiao10486 for ; Mon, 26 Mar 2001 15:36:35 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkiao16435 for ; Mon, 26 Mar 2001 15:36: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 HAA18171 for ; Mon, 26 Mar 2001 07:36:37 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA03229 for mpls@uu.net; Mon, 26 Mar 2001 10:36:32 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhps02277 for ; Fri, 23 Mar 2001 17:09:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkhps14570 for ; Fri, 23 Mar 2001 17:07:50 GMT Received: from ftpbox.mot.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ftpbox.mot.com [129.188.136.101]) id QQkhps27503 for ; Fri, 23 Mar 2001 17:07:50 GMT Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA04854 for ; Fri, 23 Mar 2001 10:07:49 -0700 (MST)] Received: [from il02exb01.comm.mot.com (il02exb01.comm.mot.com [145.1.204.17]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA22269 for ; Fri, 23 Mar 2001 10:07:49 -0700 (MST)] Received: by il02exb01.comm.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Mar 2001 11:07:48 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D9C5@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'Thomas D. Nadeau'" , mpls@UU.NET, swallow@cisco.com Subject: RE: MPLS WG Meeting Minutes Date: Fri, 23 Mar 2001 11:07:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Framework for multicast recovery. Authors feel it is ready to go to wg last call. Is there a "Framework for Multicast recovery" draft in the MPLS WG? Could you please give me the URL to the draft? Thanks, Vidya -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thursday, March 22, 2001 5:47 PM To: mpls@UU.NET; swallow@cisco.com Subject: MPLS WG Meeting Minutes MPLS WG Meeting Thursday, March 22, 2001 Agenda Bashing George provided document status on existing documents which are in last call. Mpls-bgp4-mpls-05: Not sure what the current state is. Applicability statement for extensions to rsvp for lsp-tunnels: some minor edits needed. Rsvp-te extensions to rsvp for lsp tunnels LDP "boxed" set: Needs some editorial changes. Eric Gray needs to do some editing. MPLS-LSR/LDP MIB are currently working on IESG changes. Another round of last call probably not required. MPLS DiffServ Update: Francois L. provided an update. Last call finished in diffServ WG. Mostly minor comments to fix. Re-issue a final version which gets sent over to the IESG. Who to hand it over to? Rob Coltun: Hand it over to Scott/Bert. Framework for IP Multicast in MPLS: read for IESG last call. Generalized MPLS Signaling drafts: join last call with CCAMP. Updated by Kireeti. There were a few changes in CCAMP. Lou Berger needs to make a few changes. Some changes to spin Sonet documents off into another document, and will then be ready to go to last call. This is related to the TSPEC for Sonet. George, should we go to last call? No hands opposed. Consensus to send to last call. Framework for multicast recovery. Authors feel it is ready to go to wg last call. Unnumbered, Bundle, Hierarchy documents will remain as wg drafts in MPLS. Accept draft-kompella-mpls-undle-05.txt as working group draft. Modify the draft slightly as draft-mpls-bundle-00.txt. Draft will then go to wg last call. None opposed; consensus. Kellstrand MPLS recovery framework -- draft-ietf-mpls-recovery-framework Gave update on progress of document. This document was presented to TE WG. Many comments received on this document. Minor changes were required (editorial). Updated WG on current updates to the document. Outlined recovery principles: initiation of the recovery path setup: pre-established, prequalified, established-on-demand. Recovery principles covered. Asked to send to WG last call and move it to an informational RFC. No questions from crowd. George asked Ads to move this forward to wg last call. Scott wants to wait until TE wg design teams return their results before we bring this to wg last call, but doesn't want to hold the document. Kellstrand noted that this document was on hold for 2 meetings, and wants to move forward with bringing it to last call. Will send out on TE WG mailing list and ask for comments. George: TE WG design teams can use this document for their work. Question A: Are there any performance benchmarks provided for recovery or should this be somewhere in the requrirements? Kellstrand: No, there are no benchmarking in draft. Question A: Performance benchmarks need to be added. George: This document contains things in a much higher level than this. Curtis: This document is a little too complete. This document is useful regardless and advanced anyway while the TE wg can progress with its own work. George: This document is really a taxonomy. Scott: There might be a taxonomy, but the te wg might want to use it. Kellstrand: we can include additional minor changes during last call. Curtis: Rename as "taxonomy"? Scott: Wants to take a sense of the room, and then get comments from the mailing list for last call, but still wants te design team to make sure that they don't want to add to it. Don't want to wait for more than a month. George: Any objections on moving to last call within a month? None were voiced. Swallow MPLS Resilience Objective is to do FRR in MPLS to allow for temporary routing around a failed link or node while the head-end is reoptimizing the lsp. Rerouting under 50ms. Scalable. Allows for sonnet-speed recovery times. Two mechanisms provided in draft: use rsvp to signal backup paths, or a frame-based switch using the global label space can simply record labels in the rro. Although linkstate changes may be the primary means of adding need to notify the head end. Draft available for the past 1.5 years. It is purely informational; doesn't propose anything new. Would like to publish as a wg informational draft. Scott (as chair): Is there support in the room for this. No objections. Question A: Does not see quite how it works if wanting to route around a few hops versus routing around a few links. George: The assumption is that you set up a tunnel to the hop around the one being protected. Q A: No, the outer tunnel needs to use one of the outer tunnels to get around? George: Lets take it offline and I will explain the details. Q B: If the tunnel follows the green tunnel, then the RSVP object is set to this object. George: Explains how messages are sent. Q B: Two path messages are sent? George: Yes, two path messages are sent. Q B: More clarification requested... George: Lets take it offline. Q C: There are two objectives: 50ms + large numbers of LSPs backed up. How are these both achieved. George: All information is in each router at the time of failure. Scalability by allowing many tunnels allowed to be backed up by a single tunnel. Scott: Confusion needs to be set up. Support seems to be there. Bert and I will take a look at the draft. Matthews LDP Fault Tollerance draft-ietf-mpls-ldp-ft-01.txt Summarized draft. Discussed changes between last version and current version. Expect to ask for wg last call soon. Requested comments now or via mailing list. George: Consensus to put this draft to a wg last call. Luca Martini opposes wg last call; no other objections. Luca: Since ldp is not a controlling protocol, why bother making it fault tolerant? Matthews: Enhance software upgrades and you don't want to disrupt the LSPs that are running over the network. Luca: But other protocols need to be made redundant too. Matt: OSPF etc... are being made fault tolerant. We stole this proposal from IDR. George: Last call to be issued. Scott: Shouldn't we wait until the work on the routing protocols is finished before we finish this up? George: The idea is for this state to be useful, this work needs to be done. The state of this protocol needs to be done, and can be done in parallel. Scott: Should we serialize them? George: There is no hardm. Curtis: There was some work in OSPF that helped quicken the detection of faults in the database. Prevents premature changes in database. Are those applicable to this draft? Matt: That is true. This is useful by itself because you can use this to upgrade your LDP software. For OSPF it is not clear how this will work. Curtis: A router is loading software takes a long time relative to changes in the routing protocol. The static tables in hardware should be okay. If there are changes in the network, then there can be problems. Matt: I don't see this being used this way. If you use hot standby hardware, then there is no disruption. You need to sift information across between cards. It is easier to do at the ldp level than at the tcp level. Eric: there is a lot of interaction between ldp and routing protocols. It is orthogonal between what is used to modify the routing protocols. We can get into a problem if we mix routing protocols in this specification. Lets not worry about OSPF, ISIS, etc... Curtis: The issue is not to do the same as ospf. If there is a small router, should this be in the protocol to handle the overhead of this switchover? Matt: We want to support this ability? Curtis: OSPF/IDR changes were intended to use for switchovers. It might be better to abort graceful restart and just assume the router is down. Q: There are applications of LDP that do not depend on upgrades to other protocols. Scott: Is there an applicability statement in this document to show where it can be used? M: There are, but there are not which describe where it should not be used. Scott: It might benefit from this. There doesn't seem like there is a lot of support for this. George: Lets continue this discussion on the mailing list. If no resolution there, we can talk about it later. Curtis: If there is no problem in last call, just move it forward? Small changes may be required to support OSPF/RTP changes. George: that is okay with me. We will do a last call, raise these issues and try to close them. If closed, then document is finished. Sharma Vishal Expanded ERO for RSVP-TE Overview. Lets make this an informational document on how to form EROs and move it forward that way. George: Questions? Matt: Asked to clarify. Vishal: Yes. George: Turn another draft and will ask later. Qa: Don't want to move it forward. G: Isn't being moved forward. We will re-spin another version of this document. Come to London for more information. Agarawal TTL Processing in MPLS Networks Draft covers different ways of processing TTL. Overview. Would like to update according to comments from list and move forward to last call. Matt: Document is useful and technical content is good. Figures would be useful. Document is difficult to read. Pipe/Hose model are mixed in document. Put them in a their own places in the document? Q1: I don't see how TTLs are specified in NTAPs draft. A: Some models are not described in that document. Q1: There might be some difficulty with your approach. Rosen: There is already a document that specifies how TTL processing works. Lets just put pipe model in here only, otherwise we duplicate things explained in RFC 3032. I think that we need to organize the discussion around the point of the organization of this document (what is not covered and what is). E: You don't need a separate procedure for nested procedure; already covered in 3032. Discussion did not complete on mailing list. There is a lot that needs to be clarified. A: What are you proposing? E: I think that you are proposing changes and additions (specified and unspecified). Need to specified which is which. Need to reach consensus on whether or not they are necessary. Do we need a document that obsoletes pieces of rfc3033. George: this is an information proposal. We cannot contradict something that is in a standard. Lets continue this discussion on the mailing list. Egray: I was going to say what george just said. Define something in a standard specification and explain something in an informational. George: Cannot contradict what was in the rfc. Take it to the list. Matsushima ttl processing expansion for 1 hop lsp Overview. Next steps: merge with Puneet's ttl draft. Would like to become a wg draft. Need signaling extensions for 1-hop lsp. George: Discussion? Rosen: There are two schools of thought on TTL processing. Don't think there is a need to specify TTL on a per-lsp basis. I don't think that there is a problem that we need to solve here. Matt: I agree with eric. The terminology for a 1-hop lsp is different from what they define. Luca: I agree with Eric's comments. I don't see the use of specifying the behavior on a per-lsp basis. Q: I don't think that this is what ttl was designed for. George: Continue discussion on mailing list. Paridaens End to End Authentication for ldp Overview. Presented requirements. What we are asking is that this be adopted as a wg draft. This work is part of the charter, so it should be accepted. Scott: What operators have expressed interest in this technology and have the security geeks looked at this? Q: I don't see any carriers looking at this. This method is expensive. Parid: The cost is not so heavy. Q: The other routing protocols work fine without authentication. If that is not a problem there, then why is this necessary here? Paris: There are options as part of other protocols for authentication. It is necessary in other protocols and applications of them. Q: All vendors are required to implement these drafts, and I don't think that it is necessary. I would like to see the requirements document for this sort of work. George: I would like to see a clear indication from the carriers that this is necessary. Q: We had this discussion in San Diego. The consensus there was that this is overkill. Similar mechanisms are already available in TCP. George: The charter items must not be worked on, they can be worked on. Q: There is no explicit "why" about doing this from carriers. Qb: I am not comfortable with this solution, but there seemed to be a clear statement in San Diego for non-hop-by-hop authentication. George: Can some of those people speak up? Qd: I made this proposal. There was some support at this time. Qe: This looks like S-BGP which was roundly rejected because it was overkill/unfeasible. There is precident for this not being what vendors want. George: We need to figure out what providers want first. We don't have consensus. Qf: Providers want security, but this is not really what we are looking for. George: Lets get some carriers to give us some contributions for what they would like to see in this space. Continue discussion on this mailing list. Black Update on LDP Path MTU black-ldp-mtu-extensions-00.txt Overview. Simple extension to ldp to allow automatic signaling of mtu detection. Allows proper fragmentation of packets within the MPLS domain. Support RFC1191 too. Version 00 has been out for some time. Lots of comments received. Asked that this be accepted as a wg document. George: discussion Curtis: What happens if along the way, one hop is inside a hierarchtical tunnel or if bypass tunnels are used. In both cases, the router negotiating a hop is not aware that somewhere in the middle that a bypass exists. Black: If hierarchtical, the outermost tunnel's mtu is used. There is an lsr somewhere that can see the bypass which can unsolicited signal the mtu change. It will pick the lesser of the two's path. George: Anything that causes an impulse into signaling during a failure is bad. Rosen: In practice, a typical situation a packet with dm bit set, packets go through Firewalls that strip the tos bits off the packet. This solution does not solve the problem. Black: In some cases, path MTU signaling in some cases is not valid to not solve the problem altogether. Second, there are other reasons for doing this: packets being fragmented in/out of MPLS domain. Rosen: Both packets have df bits set. Curtis: There are places where this is necessary: no NATs and high performance IP. Matt: I haven't seen demands from the carriers for this functionality, eventhough I like it. Scott: Process point: is this in the charter? George: Gray area. We should work to get MPLS to work. Scott: WG can change charter if necessary. Charter is description of what we should be doing within a certain time period. Q1: Carriers are interested in this. Black: RSVP has this functionality. George: We now have three presentations that are not in the gray area. They are outside of the charter. We are going into "BOF" mode to see if there is interest to expand the charter. Senevirath -- Secure MPLS draft-tsenevir-smpls-01, tsenevir-smpls-doi-00 Overview. Applications: Most metro applications use MPLS. Q1: In your first slide, you stated that most MPLS Metro carriers use MPLS. Which country are you talking about? Sen: US. Q1: Do you know which vendors are supporting MPLS in the metro area. Q2: Most operators use f/r links. The law prohibits them from monitoring authentications. Can authentications be monitored on MPLS. Even if we have mpls security on a backbone. MPLS is an end-to-end problem. This does not seem to be useful unless it is end to end. Bilel J: Where are you getting the requirements for this draft. Sen: These requirements are coming from the optical development going on in the world. George: Take the discussion to the mailing list. Disk Ooms MPLS multicast Traffic Engineering Overview. Questions. George: This work was started a long time ago. There was no interest in this at that time. What has changed? Disk: Now there is SSMulticast. George: I think that you should change the name of your document to "support for SSM". Describe your document in this way. Disk: this is an alternative to SSM, not a tunnel through it. George: I guess the amount of time we have left, we should see if there is interest on the mailing list. Rosen: As far as SSM, there are other solutions to the problem of passing multicast packets back to the root. Disk: There are other solutions, but they are undocumented as of yet. Q1: I wasn't clear why SSM makes this more interesting. Also it isn't clear how you distribute the labels using TE. Where is the definition of TE is not clearly defined in the draft. Disk: Traffic engineering allows you to construct a tree, which deviates from the one created in unicast. George: The interest in SSM is more interesting than general multicast, and it is an easier problem to solve. Lets continue discussion on the mailing list. Davari MPLS OAM draft-harrison-mpls-oam-00.txt Overview. Status of this document: ITU SG14-Q3. Requirements are defined. Availability is defined. OAM Packets are defined. Connectivity verification is worked out. Future work: LSP performance work. Summary: OAM is necessary for user-plane, independent of control-plane. This draft introduces OAM requirements and simple OAM functions. Determining connectivity/availability. MPLS OAM was previously defined in MPLS charter. If interested, it should be added to charter and document accepted as a work item. Q: I think this work is very useful. It will increase the performance of the MPLS network. Recovery framework is applicable. Performance benchmarking applies. This is useful for fault-tollerance. Curtis: How does this apply to the Bonica work? We should go to the TE Wg and see what their requirements are for this. Rosen: I think that some of the stuff in the beginning is important. I think this document is not a good piece of work that are not defined in the IETF. It has a very ATM-flavor. It does not handle a lot of stuff like multi-point-to-point. Even if we were to add measurement to charter, lets not accept this document to the charter. Davari This is optional. Carriers want this. Q2: I don't think that this is useful. I think that it is not useful in an LSR. I can see this to be useful if GSMP is being used. Useful in detecting configuration errors, otherwise lets assume that the LSR works okay. Q3: I second that. I don't buy the argument that software is broken, so we need to add more software. Scott: My problem with the document is that it mixes light requirements with lots of suggestions. It would be useful to have a clear requirements document (TE WG) that specifies what it is that you are trying to find out with this approach. That would be helpful for TE WG. Q4: I think that the notion at the MPLS Layer is a useful construct for fault diagnosis. Q5: The ITU is working on this. Can you send a pointer to this information on the ITU. Davari: The information at the ITU is exactly the same information. ITU study group SG-13 Q6: I am not sure if the finding of errors is to be found in the te wg. Davari: is it in the charter of te? Scott: Thinking is in the charter of te. Management of this kind is not in the charter. However, if requirements can come forward and hint at which tools they could have would be a good thing. Q6: I am not sure that availability is specified. Davari: What we have done is take this from ATM and reduce most of what was there, and kept the best %1. George: End of the agenda. See you in London. From owner-mpls@UU.NET Mon Mar 26 10:41:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09741 for ; Mon, 26 Mar 2001 10:41:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiao19157; Mon, 26 Mar 2001 15:39:40 GMT Received: by mail-control.mail.uu.net id QQkiao16535 for mpls-outgoing; Mon, 26 Mar 2001 15:38:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiao16495 for ; Mon, 26 Mar 2001 15:38:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiao03531 for ; Mon, 26 Mar 2001 15:37:01 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkiao06311 for ; Mon, 26 Mar 2001 15:36: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 HAA13999 for ; Mon, 26 Mar 2001 07:37:19 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA03235 for mpls@uu.net; Mon, 26 Mar 2001 10:36:57 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkhqt21834 for ; Fri, 23 Mar 2001 23:57:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkhqt23546 for ; Fri, 23 Mar 2001 23:57:11 GMT Received: from mail7.netsgo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [211.39.33.57]) id QQkhqt23300 for ; Fri, 23 Mar 2001 23:57:10 GMT Received: from LocalHost ([210.111.160.244]) by mail7.netsgo.com with Microsoft SMTPSVC(5.5.1877.447.44); Sat, 24 Mar 2001 08:57:06 +0900 Message-ID: <002501c0b3f4$c48c6020$77131796@LocalHost> From: =?ks_c_5601-1987?B?vsbB8bb1?= To: Subject: Any references to MPLS TE routing algorithms? Date: Sat, 24 Mar 2001 08:55:39 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C0B440.3336A620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C0B440.3336A620 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpXZSdyZSBzZWFyY2hpbmcgZm9yIGFueSByZWZlcmVuY2VzIG9yIHBvaW50 ZXJzIHRvIHJvdXRpbmcgYWxnb3JpdGhtcyBmb3IgdGhlIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmlu Zy4NCkknbSB3b25kZXJpbmcgaWYgdGhlIGFsZ29yaXRobXMgb3IgbWV0aG9kb2xvZ2llcyBoYXZl IGFueSBkaWZmZXJlbnQgZmVhdHVyZXMgY29tcGFyZWQgd2l0aCB0aGUgZXhpc3RpbmcgDQpyb3V0 aW5nIG1ldGhvZHMgb2YgdGhlIHByZXZpb3VzIGxpdGVyYXR1cmUuIEFueXdheSwgeW91ciBoZWxw IHdpbGwgYmUgdmVyeSBhcHByZWNpYXRlZC4NClRoYW5rcyBmb3IgeW91ciByZWFkaW5nLg0KDQpS YWUuDQoNCg0K ------=_NextPart_000_0020_01C0B440.3336A620 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvIGFs bCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5XZSdyZSBzZWFyY2hpbmcgZm9yIGFueSByZWZlcmVuY2VzIG9yIHBv aW50ZXJzIHRvIHJvdXRpbmcgDQphbGdvcml0aG1zIGZvciB0aGUgTVBMUyBUcmFmZmljIEVuZ2lu ZWVyaW5nLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkknbSB3b25kZXJpbmcgaWYg dGhlIGFsZ29yaXRobXMgb3IgbWV0aG9kb2xvZ2llcyBoYXZlIGFueSANCmRpZmZlcmVudCBmZWF0 dXJlcyBjb21wYXJlZCB3aXRoIHRoZSBleGlzdGluZyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5yb3V0aW5nIG1ldGhvZHMgb2YgdGhlIHByZXZpb3VzIGxpdGVyYXR1cmUuIEFueXdh eSwgeW91ciBoZWxwIA0Kd2lsbCBiZSB2ZXJ5IGFwcHJlY2lhdGVkLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPlRoYW5rcyBmb3IgeW91ciByZWFkaW5nLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJh ZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0020_01C0B440.3336A620-- From owner-mpls@UU.NET Mon Mar 26 10:43:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09793 for ; Mon, 26 Mar 2001 10:43:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiao23419; Mon, 26 Mar 2001 15:41:09 GMT Received: by mail-control.mail.uu.net id QQkiao16569 for mpls-outgoing; Mon, 26 Mar 2001 15:39:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiao16540 for ; Mon, 26 Mar 2001 15:38:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiao23917 for ; Mon, 26 Mar 2001 15:38:33 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkiao18179 for ; Mon, 26 Mar 2001 15:38: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 HAA19361 for ; Mon, 26 Mar 2001 07:38:36 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA03255 for mpls@uu.net; Mon, 26 Mar 2001 10:38:31 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkial25337 for ; Mon, 26 Mar 2001 14:55:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkial08686 for ; Mon, 26 Mar 2001 14:55:05 GMT Received: from ariadne.dt.fee.unicamp.br by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dt.fee.unicamp.br [143.106.8.45]) id QQkial07403 for ; Mon, 26 Mar 2001 14:55:04 GMT Received: from proteus (proteus.dt.fee.unicamp.br [143.106.12.29]) by ariadne.dt.fee.unicamp.br (8.9.3/8.9.3) with SMTP id LAA02656 for ; Mon, 26 Mar 2001 11:54:59 -0300 (EST) Message-ID: <003701c0b606$df589f40$1d0c6a8f@dt.fee.unicamp.br> From: "padua" To: Subject: MPLS over DWDM Date: Mon, 26 Mar 2001 12:10:18 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C0B5ED.B92944A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C0B5ED.B92944A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I'd like to know about MPLS over DWDM. Does it exists some norm for this = technology? Regards, _________________________________ Fabiano Jo=E3o L. P=E1dua BRASIL =20 ------=_NextPart_000_0034_01C0B5ED.B92944A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
I'd like to know about MPLS over DWDM. = Does it=20 exists some norm for this technology?
 
Regards,
 
_________________________________
    &nb= sp;     =20 Fabiano Jo=E3o L.=20 P=E1dua
          &n= bsp;           &nb= sp;=20 BRASIL         =20
------=_NextPart_000_0034_01C0B5ED.B92944A0-- From owner-mpls@UU.NET Mon Mar 26 10:44:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09832 for ; Mon, 26 Mar 2001 10:44:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiao24876; Mon, 26 Mar 2001 15:42:32 GMT Received: by mail-control.mail.uu.net id QQkiao16581 for mpls-outgoing; Mon, 26 Mar 2001 15:39:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiao16541 for ; Mon, 26 Mar 2001 15:38:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiao21935 for ; Mon, 26 Mar 2001 15:37:41 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkiao06679 for ; Mon, 26 Mar 2001 15:37:20 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 HAA14215 for ; Mon, 26 Mar 2001 07:37:39 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA03239 for mpls@uu.net; Mon, 26 Mar 2001 10:37:18 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhtt20147 for ; Sat, 24 Mar 2001 19:18:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhtt21583 for ; Sat, 24 Mar 2001 19:18:22 GMT Received: from ns.gnupg.cz by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.gnupg.cz [193.165.192.251]) id QQkhtt13946 for ; Sat, 24 Mar 2001 19:18:03 GMT Received: from bubak.m3a.cz (unknown [212.11.96.5]) by ns.gnupg.cz (Postfix) with ESMTP id C30311B32C for ; Sat, 24 Mar 2001 21:18:20 +0100 (CET) Received: by bubak.m3a.cz (Postfix, from userid 1000) id 35ADB39328; Sat, 24 Mar 2001 15:47:04 +0100 (CET) Date: Sat, 24 Mar 2001 15:47:03 +0100 From: Martin Machacek To: mpls@UU.NET Subject: Re: Dest IP addr in MPLS Message-ID: <20010324154703.G14264@bubak.m3a.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from esaheb@hyperchip.com on Fri, Mar 23, 2001 at 05:19:24PM -0500 Sender: owner-mpls@UU.NET Precedence: bulk On Fri, Mar 23, 2001 at 05:19:24PM -0500, Eyad Saheb wrote: > I am unclear on the proper IP address to use as IP_DEST in > RSVP-TE packets, especially when switches are involved. Unfortunately, > the "standards" docs aren't too clear on this point (IMHO). I will > illustrate my point: > > 1 - 2 - 3 - 4 > \ / > 5 -----/ > > In the above topology, if Router 1 wants to establish a path to Router 4 > through 2 & 3 it will create an RSVP-TE packet with IP_DEST = 4 & and > ERO = 2,3,4. Correct ? Yes. > This should override the IGP routing table > which would probably indicate router 5 as the 'correct' next-hop from > router 1. > > However, consider the following: > > +-+ > | |- 2 > 1 -| |- 3 > | |- 4 > +-+ > > In this case, all routers are connected via a switch. If the same > RSVP-TE packet is sent over this network, it would reach router 4 > directly. It would then reject the packet since it'snot the first node > in the ERO. Is this expected ? Well, you are mixing L3 and L2 topology. Your first figure shows L3 (IP) topology, so lines are links in the IP sense (i.e they can be implemented by any combination of compatible L2 links - there may be several LAN switchech, ATM switchech, FrameRelay switches on every link). Your second figure shows L2 topology so lines are links in Ethernet sense (i.e. cables eventually with repeaters). IP topology of your second figure would look like this: 1 2 3 4 | | | | ---------------- 4 nodes connected to one shared media segment. Nevetheless, assuming that ERO processing is implemented correctly in all nodes, using the above explicit route (2,3,4) and target address 4 you should be able to force LSP between 1 and 4 to traverse 2 and 3 (instead of going directly to 4). Each node should send the RSVP packet explicitly to the next node in the ERO (by doing L2 address resolution) instead to node 4 (which is the target and is directly reachable). Disclaimer: I've tried this setup. > Was RSVP-TE designed to be run over 'switched' networks ? RSVP-TE does not care which L2 topology it runs on. The only requirement is IP connectivity. Martin -- [PGP KeyID F3F409C4] From owner-mpls@UU.NET Mon Mar 26 10:45:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09870 for ; Mon, 26 Mar 2001 10:45:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiao26614; Mon, 26 Mar 2001 15:43:38 GMT Received: by mail-control.mail.uu.net id QQkiao16599 for mpls-outgoing; Mon, 26 Mar 2001 15:39:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiao16551 for ; Mon, 26 Mar 2001 15:38:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiao23535 for ; Mon, 26 Mar 2001 15:38:24 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkiao07873 for ; Mon, 26 Mar 2001 15:38:21 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 HAA14809 for ; Mon, 26 Mar 2001 07:38:40 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA03251 for mpls@uu.net; Mon, 26 Mar 2001 10:38:19 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkhyl26062 for ; Mon, 26 Mar 2001 01:48:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkhyl22217 for ; Mon, 26 Mar 2001 01:47:48 GMT Received: from mail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQkhyl22065 for ; Mon, 26 Mar 2001 01:47:45 GMT Received: by mail.in.huawei.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 07:22:55 +0500 Message-ID: <70EB682332F4D41187D6000629AE2C651FE70B@mail.in.huawei.com> From: Aditya Chugh To: Philip Matthews , mpls@UU.NET Cc: af@dataconnection.com Subject: RE: What exactly constitutes the State info in FT-LDP and what do we mean by "Securing the message" ?? Date: Mon, 26 Mar 2001 07:22:54 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B59B.AA116430" 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_01C0B59B.AA116430 Content-Type: text/plain; charset="iso-8859-1" Hello Philip, Thanks for your mail. I recieved a reply from Adrian(enclosed below)......but I asked him a further question based on his answer(also enclosed below)...regarding which I am yet to hear from him. It would really help if you could shed some light on the matter !!!! The question I had asked Adrian was:-- "Could you explain what you exactly mean by "state and information related to the previous incarnation of the session " In section 3.4 of your draft you say that "If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT Session TLV, both LDP peers MUST release any state information and resources associated with the previous instantiation of the LDP session between the same LDP peers, including FT label state and Addresses" Could you please tell me as to what specifically constitutes the "state information and resources" ?? Secondly in Section 4.2 of your draft you write "When an LDP Peer receives a message containing the FT Protection TLV, it MUST take steps to secure this message (or the state information derived from processing the message). Once the message is secured, it MUST be ACKed. However, there is no requirement on the LSR to send this ACK immediately." What do you exactly mean by the term "SECURED".....obviously it does not mean "PROCESS" the message ? So what does "secure this message" mean ???? Looking forward to your reply. Thanks in Advance, Aditya Dear Adrian, Thanks for your reply.Could you kindly explain what you exactly mean by "state and information related to the previous incarnation of the session " In section 3.4 of your draft you say that "If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT Session TLV, both LDP peers MUST release any state information and resources associated with the previous instantiation of the LDP session between the same LDP peers, including FT label state and Addresses" I broadly understand what you mean by "state information and resources "..but could you give me the specifics as to what constitutes the "state information and resources" . Sorry for bothering you with the gory details...but I guess it is better to be safe rather than sorry Thanks for your help warm regards, Aditya >>Hi again Aditya, >>Fair question. >>It's your choice whether you re-use the same session control block, but you should throw out state and information related >>to the previous incarnation of the session and only populate the new/re-used control block with information about the re- >>established session. >>OK? >>Regards, >>Adrian -----Original Message----- From: Philip Matthews [mailto:philipma@nortelnetworks.com] Sent: Tuesday, March 20, 2001 9:23 AM To: Aditya Chugh (Leela) Subject: Re: If we recieve FT reconnect Flag = 0...can we use same session ?? I saw this posted to the MPLS-OPS list run by the MPLS Resource Center.... If you have questions on our Fault Tolerance draft, it would be best to send them directly to the authors. Some of us are a little behind in our reading of various mailing lists ... And don't send them to MPLS-OPS list, which is for operational questions, but to the MPLS WG list instead (mpls@uu.net). Anyway, nice to see someone else implementing the draft. - Philip PS. Did Adrian every reply to your question?? "Aditya Chugh (Leela)" wrote: > > Dear Adrian, > I need to bother you again...!!!!!! > > If our FT-LDP implementation is to conform to your draft " draft-ietf-mpls-ldp-ft-00.txt "...then how should the following be handled ???? > > Consider the case when the TCP connection (of an FT session) needs to be reestablished. > Before the Reconnection Timer Expires > if I recieve an Initialization message( with valid Session TLV).. > ....but FT reconnect flag set to 0( which means that peer has not preserved state info for previous instantiations of this LDP session ) > > I am supposed to release all the label state and resources associated with the previous instantiation of the LDP session. > > this would mean that I release the Labels and the Control Blocks ( since Labels are stored in the Control Blocks). > > But do I need to tear down the session also ??...that is do I also need to > release the Session Block ...or I can use the same session block to establish a "Brand New" FT session.?? > > Thanks in advance, > Aditya ------_=_NextPart_001_01C0B59B.AA116430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: What exactly constitutes the State info in FT-LDP and what = do we mean by "Securing the message" ??

Hello Philip,
 Thanks for your mail.
I recieved a reply from Adrian(enclosed = below)......but I asked him a
further question based on his answer(also enclosed = below)...regarding which I am yet to hear
from him. It would really help if you could shed = some light on the matter !!!!


The question I had asked Adrian was:-- "Could = you explain what you
exactly mean by "state and information related = to the previous incarnation of the session "

In section 3.4 of your draft you say that
"If either LDP peer sets the FT Reconnect Flag = to 0, or omits the FT
   Session TLV, both LDP peers MUST = release any state information and
   resources associated with the previous = instantiation of the LDP
   session between the same LDP peers, = including FT label state and
   Addresses"

Could you please tell me as to what specifically = constitutes the "state information and resources" ??


Secondly in Section 4.2 of your draft you = write
   "When an LDP Peer receives a = message containing the FT Protection TLV,
   it MUST take steps to secure this = message (or the state information
   derived from processing the = message).  Once the message is secured,
   it MUST be ACKed.  However, there = is no requirement on the LSR to
   send this ACK immediately."

What do you exactly mean by the term = "SECURED".....obviously it does not mean "PROCESS" = the message ?
So what does "secure this message" mean = ????

Looking forward to your reply.
Thanks in Advance,
Aditya



Dear Adrian,
 Thanks for your reply.Could you kindly explain = what you
exactly mean by "state and information related = to the previous incarnation of the session "

In section 3.4 of your draft you say that
"If either LDP peer sets the FT Reconnect Flag = to 0, or omits the FT
   Session TLV, both LDP peers MUST = release any state information and
   resources associated with the previous = instantiation of the LDP
   session between the same LDP peers, = including FT label state and
   Addresses"


I broadly understand what you mean by  = "state information and resources "..but could you
give me the specifics as to what constitutes the = "state information and resources" .
Sorry for bothering you with the gory details...but = I guess it is better to be safe rather than sorry
Thanks for your help
warm regards,
Aditya




>>Hi again Aditya,
>>Fair question.
>>It's your choice whether you re-use the same = session control block, but you should throw out state and information = related >>to the previous incarnation of the session and only = populate the new/re-used control block with information about the = re-

>>established session.
>>OK?
>>Regards,
>>Adrian



-----Original Message-----
From: Philip Matthews [mailto:philipma@nortelnetwor= ks.com]
Sent: Tuesday, March 20, 2001 9:23 AM
To: Aditya Chugh (Leela)
Subject: Re: If we recieve FT reconnect Flag =3D = 0...can we use same
session ??


I saw this posted to the MPLS-OPS list run by the = MPLS Resource Center....

If you have questions on our Fault Tolerance draft, = it would be best to
send them directly to the authors. Some of us are a = little behind in our
reading of various mailing lists ...

And don't send them to MPLS-OPS list, which is for = operational questions,
but to the MPLS WG list instead = (mpls@uu.net).

Anyway, nice to see someone else implementing the = draft.

- Philip

PS. Did Adrian every reply to your question??


"Aditya Chugh (Leela)" wrote:
>
> Dear Adrian,
> I need to bother you again...!!!!!!
>
> If our FT-LDP implementation is to conform to = your draft " draft-ietf-mpls-ldp-ft-00.txt "...then how = should the following be handled ????

>
> Consider the case when the TCP connection (of = an FT session)  needs to be reestablished.
> Before the Reconnection Timer Expires
> if I recieve an Initialization message( with = valid Session TLV)..
> ....but FT reconnect flag set to 0( which means = that peer has not preserved state info for previous instantiations of = this LDP session )

>
> I am supposed to release all the label state = and resources associated with the previous instantiation of the LDP = session.

>
> this would mean that I release the Labels and = the Control Blocks ( since Labels are stored in the Control = Blocks).
>
> But do I need to tear down the session also = ??...that is do I also need to
> release the Session Block ...or I can use the = same session block to establish a "Brand New" FT = session.??
>
> Thanks in advance,
> Aditya

------_=_NextPart_001_01C0B59B.AA116430-- From owner-mpls@UU.NET Mon Mar 26 10:53:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10011 for ; Mon, 26 Mar 2001 10:53:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiap06288; Mon, 26 Mar 2001 15:51:23 GMT Received: by mail-control.mail.uu.net id QQkiap18156 for mpls-outgoing; Mon, 26 Mar 2001 15:50:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiap18146 for ; Mon, 26 Mar 2001 15:50:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiap11140 for ; Mon, 26 Mar 2001 15:49:32 GMT Received: from mailer.syr.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailer.syr.edu [128.230.18.29]) id QQkiap29035 for ; Mon, 26 Mar 2001 15:49:31 GMT Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.0002DC5B@mailer.syr.edu>; Mon, 26 Mar 2001 10:49:31 -0500 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id KAA06676; Mon, 26 Mar 2001 10:49:31 -0500 (EST) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Mon, 26 Mar 2001 10:49:30 -0500 (EST) From: Ibrahim Okumus X-Sender: iokumus@rodan.syr.edu To: =?ks_c_5601-1987?B?vsbB8bb1?= cc: mpls@UU.NET Subject: Re: Any references to MPLS TE routing algorithms? In-Reply-To: <002501c0b3f4$c48c6020$77131796@LocalHost> 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 KAA10011 you can check the following paper: "Minimum interference routing of bandwidth guaranteed tunnels with MPLS traffic engineering applications" IEEE Journal on Selected Areas in Communications December 2000 _ Ibrahim Taner OKUMUS On Sat, 24 Mar 2001, [ks_c_5601-1987] ¾ÆÁñ¶õ wrote: > Hello all, > > We're searching for any references or pointers to routing algorithms for the MPLS Traffic Engineering. > I'm wondering if the algorithms or methodologies have any different features compared with the existing > routing methods of the previous literature. Anyway, your help will be very appreciated. > Thanks for your reading. > > Rae. > > > From owner-mpls@UU.NET Mon Mar 26 11:11:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10671 for ; Mon, 26 Mar 2001 11:11:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiaq21831; Mon, 26 Mar 2001 16:09:38 GMT Received: by mail-control.mail.uu.net id QQkiaq06407 for mpls-outgoing; Mon, 26 Mar 2001 16:09:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiaq06402 for ; Mon, 26 Mar 2001 16:08:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiaq07476 for ; Mon, 26 Mar 2001 16:07:52 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkiaq18975 for ; Mon, 26 Mar 2001 16:07:51 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 LAA11888; Mon, 26 Mar 2001 11:07:47 -0500 (EST) 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 LAA26447; Mon, 26 Mar 2001 11:07:38 -0500 (EST) Message-ID: <3ABF6969.9A636C6F@marconi.com> Date: Mon, 26 Mar 2001 11:08:09 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Eyad Saheb CC: "'mpls@uu.net'" Subject: Re: Dest IP addr in MPLS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eyad Saheb wrote: > > Hello, > > I am unclear on the proper IP address to use as IP_DEST in RSVP-TE > packets, especially when switches are involved. Unfortunately, the > "standards" docs aren't too clear on this point (IMHO). I will > illustrate my point: > > 1 - 2 - 3 - 4 > \ / > 5 -----/ > > In the above topology, if Router 1 wants to establish a path to > Router 4 through 2 & 3 it will create an RSVP-TE packet with IP_DEST > = 4 & and ERO = 2,3,4. Correct ? This should override the IGP > routing table which would probably indicate router 5 as the 'correct' > next-hop from router 1. Yes. > However, consider the following: > > +-+ > | |- 2 > 1 -| |- 3 > | |- 4 > +-+ > > In this case, all routers are connected via a switch. If the same > RSVP-TE packet is sent over this network, it would reach router 4 > directly. It would then reject the packet since it'snot the first > node in the ERO. Is this expected ? as Martin wrote, you're confusing layer-2 with layer-3. In this topology, router 1 should send the Path message to 2, which will then send it to 3, which will then send it to 4. As per the ERO. The fact that 1 is directly conneted to 4 changes nothing. 1 will use 2 as it's next-hop router, and therefore will use 2's Ethernet address when sending the packet. The fact that the routing table shows 4 as the next hop on the shortest path doesn't matter - an ERO is supposed to override the routing table. -- David From owner-mpls@UU.NET Mon Mar 26 11:26:38 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11362 for ; Mon, 26 Mar 2001 11:26:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiar01669; Mon, 26 Mar 2001 16:24:29 GMT Received: by mail-control.mail.uu.net id QQkiar08146 for mpls-outgoing; Mon, 26 Mar 2001 16:23:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiar08133 for ; Mon, 26 Mar 2001 16:23:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiar07236 for ; Mon, 26 Mar 2001 16:23:06 GMT From: afarrel@movaz.com Received: from ims000.dcat.ops.broadbandoffice.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: external00.dca55.ops.bbo.com [64.47.146.7]) id QQkiar29809 for ; Mon, 26 Mar 2001 16:23:06 GMT Received: by ims000.dcat.ops.broadbandoffice.net with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 11:23:06 -0500 Message-ID: <4F9E13BCC53ED411A629009027E8D00C04333688@msg001.dcat.ops.broadbandoffice.net> To: Aditya@in.huawei.com, philipma@nortelnetworks.com, mpls@UU.NET Subject: RE: What exactly constitutes the State info in FT-LDP and what do we mean by "Securing the message" ?? Date: Mon, 26 Mar 2001 11:23:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B611.07BD0020" 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_01C0B611.07BD0020 Content-Type: text/plain; charset="iso-8859-1" Hi Aditya, Sorry for the break in communications, I have moved company and am now at Movaz Networks. > The question I had asked Adrian was:-- "Could > you explain what you exactly mean by "state > and information related to the previous > incarnation of the session " > In section 3.4 of your draft you say that > "If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT > Session TLV, both LDP peers MUST release any state information and > resources associated with the previous instantiation of the LDP > session between the same LDP peers, including FT label state and > Addresses" > Could you please tell me as to what specifically > constitutes the "state information and resources" ?? Well, the most obvious resources are labels. If you're doing CR-LDP there may be bufferage, bandwidth etc. to release. Basically any resources in the switch that were reserved or utilized in support of the LSPs established using the previous instantiation of the LDP session. Additionally, there will be internal control blocks and the like that your code is maintaining for the session and associated LSPs. These should be freed or reset at this time. > Secondly in Section 4.2 of your draft you write > "When an LDP Peer receives a message containing the FT Protection TLV, > it MUST take steps to secure this message (or the state information > derived from processing the message). Once the message is secured, > it MUST be ACKed. However, there is no requirement on the LSR to > send this ACK immediately." > What do you exactly mean by the term "SECURED". > ....obviously it does not mean "PROCESS" the message ? > So what does "secure this message" mean ???? Well it COULD mean processed. The minimum requirement is based on the understanding that once the message has been ACK'ed the message-sender will assume the message receiver has already or will eventually process the message. This means that the message sender does not need to retransmit the message in order to achieve the desired effect. The only let-out for this is that the session can be re-established saying that _no_ state information was preserved. This will ensure that both peers have the same view of the LSPs between them. Regards, Adrian -- Adrian Farrel Movaz Networks Inc afarrel@movaz.com ------_=_NextPart_001_01C0B611.07BD0020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: What exactly constitutes the State info in FT-LDP and what = do we mean by "Securing the message" ??

Hi Aditya,

Sorry for the break in communications, I have moved = company and am now at Movaz Networks.

> The question I had asked Adrian was:-- = "Could
> you explain what you exactly mean by = "state
> and information related to the previous
> incarnation of the session "

> In section 3.4 of your draft you say that =
> "If either LDP peer sets the FT Reconnect = Flag to 0, or omits the FT
>  Session TLV, both LDP peers MUST release = any state information and
>  resources associated with the previous = instantiation of the LDP
>  session between the same LDP peers, = including FT label state and
>  Addresses"
> Could you please tell me as to what = specifically
> constitutes the "state information and = resources" ??

Well, the most obvious resources are labels.
If you're doing CR-LDP there may be bufferage, = bandwidth etc. to release.  Basically any resources in the switch = that were reserved or utilized in support of the LSPs established using = the previous instantiation of the LDP session.

Additionally, there will be internal control blocks = and the like that your code is maintaining for the session and = associated LSPs.  These should be freed or reset at this = time.

> Secondly in Section 4.2 of your draft you write =
>   "When an LDP Peer receives a = message containing the FT Protection TLV,
>   it MUST take steps to secure this = message (or the state information
>   derived from processing the = message).  Once the message is secured,
>   it MUST be ACKed.  However, = there is no requirement on the LSR to
>   send this ACK immediately." =
> What do you exactly mean by the term = "SECURED".
> ....obviously it does not mean = "PROCESS" the message ?
> So what does "secure this message" = mean ????

Well it COULD mean processed.

The minimum requirement is based on the understanding = that once the message has been ACK'ed the message-sender will assume = the message receiver has already or will eventually process the = message.  This means that the message sender does not need to = retransmit the message in order to achieve the desired = effect.

The only let-out for this is that the session can be = re-established saying that _no_ state information was preserved.  = This will ensure that both peers have the same view of the LSPs between = them.

Regards,
Adrian
--
Adrian Farrel
Movaz Networks Inc
afarrel@movaz.com

------_=_NextPart_001_01C0B611.07BD0020-- From owner-mpls@UU.NET Mon Mar 26 11:38:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11760 for ; Mon, 26 Mar 2001 11:38:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkias18963; Mon, 26 Mar 2001 16:36:06 GMT Received: by mail-control.mail.uu.net id QQkias09605 for mpls-outgoing; Mon, 26 Mar 2001 16:35:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkias09585 for ; Mon, 26 Mar 2001 16:35:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkias27351 for ; Mon, 26 Mar 2001 16:34:47 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkias11269 for ; Mon, 26 Mar 2001 16:34:47 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 4FFA794009; Mon, 26 Mar 2001 11:34:42 -0500 (EST) Message-ID: <3ABF6FA2.42B4EB1C@sandburst.com> Date: Mon, 26 Mar 2001 11:34:42 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Aditya Chugh Cc: Philip Matthews , mpls@UU.NET, af@dataconnection.com Subject: Re: What exactly constitutes the State info in FT-LDP and what dowe mean by "Securing the message" ?? References: <70EB682332F4D41187D6000629AE2C651FE70B@mail.in.huawei.com> Content-Type: multipart/alternative; boundary="------------73DDAFA15C7F66CC3DFD001B" Sender: owner-mpls@UU.NET Precedence: bulk --------------73DDAFA15C7F66CC3DFD001B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Aditya, I will attempt to answer your questions. You wrote: > > > Hello Philip, > Thanks for your mail. > I recieved a reply from Adrian(enclosed below)......but I asked him a > further question based on his answer(also enclosed below)...regarding > which I am yet to hear > from him. It would really help if you could shed some light on the > matter !!!! > > The question I had asked Adrian was:-- "Could you explain what you > exactly mean by "state and information related to the previous > incarnation of the session " Previous incarnation relates to fact that the proposal is intended to provide a means to preserve state over loss of TCP connectivity. Incarnation may not be the best word to capture the notion that the previous (now dead) TCP connection is now represented by a new TCP connection that is intended to continue the same session. > > > In section 3.4 of your draft you say that > "If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT > Session TLV, both LDP peers MUST release any state information and > resources associated with the previous instantiation of the LDP > session between the same LDP peers, including FT label state and > Addresses" > > Could you please tell me as to what specifically constitutes the > "state information and resources" ?? Assigned labels and LSP related resources - i.e. queuing related resources associated with an LSP associated with an LDP peer session. > > > Secondly in Section 4.2 of your draft you write > "When an LDP Peer receives a message containing the FT Protection > TLV, > it MUST take steps to secure this message (or the state information > > derived from processing the message). Once the message is secured, > > it MUST be ACKed. However, there is no requirement on the LSR to > send this ACK immediately." > > What do you exactly mean by the term "SECURED".....obviously it does > not mean "PROCESS" the message ? > So what does "secure this message" mean ???? The precise meaning of secured is implementation specific. An example would be to have stored pertinent information relating to a transaction in progress in non-volatile memory. > > > Looking forward to your reply. > Thanks in Advance, > Aditya > > > Dear Adrian, > Thanks for your reply.Could you kindly explain what you > exactly mean by "state and information related to the previous > incarnation of the session " > > In section 3.4 of your draft you say that > "If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT > Session TLV, both LDP peers MUST release any state information and > resources associated with the previous instantiation of the LDP > session between the same LDP peers, including FT label state and > Addresses" > > I broadly understand what you mean by "state information and > resources "..but could you > give me the specifics as to what constitutes the "state information > and resources" . > Sorry for bothering you with the gory details...but I guess it is > better to be safe rather than sorry > Thanks for your help > warm regards, > Aditya > > > > >>Hi again Aditya, > >>Fair question. > >>It's your choice whether you re-use the same session control block, > but you should throw out state and information related >>to the > previous incarnation of the session and only populate the new/re-used > control block with information about the re- > > >>established session. > >>OK? > >>Regards, > >>Adrian > > > -----Original Message----- > From: Philip Matthews [mailto:philipma@nortelnetworks.com] > Sent: Tuesday, March 20, 2001 9:23 AM > To: Aditya Chugh (Leela) > Subject: Re: If we recieve FT reconnect Flag = 0...can we use same > session ?? > > I saw this posted to the MPLS-OPS list run by the MPLS Resource > Center.... > > If you have questions on our Fault Tolerance draft, it would be best > to > send them directly to the authors. Some of us are a little behind in > our > reading of various mailing lists ... > > And don't send them to MPLS-OPS list, which is for operational > questions, > but to the MPLS WG list instead (mpls@uu.net). > > Anyway, nice to see someone else implementing the draft. > > - Philip > > PS. Did Adrian every reply to your question?? > > "Aditya Chugh (Leela)" wrote: > > > > Dear Adrian, > > I need to bother you again...!!!!!! > > > > If our FT-LDP implementation is to conform to your draft " > draft-ietf-mpls-ldp-ft-00.txt "...then how should the following be > handled ???? > > > > > Consider the case when the TCP connection (of an FT session) needs > to be reestablished. > > Before the Reconnection Timer Expires > > if I recieve an Initialization message( with valid Session TLV).. > > ....but FT reconnect flag set to 0( which means that peer has not > preserved state info for previous instantiations of this LDP session ) > > > > > I am supposed to release all the label state and resources > associated with the previous instantiation of the LDP session. > > > > > this would mean that I release the Labels and the Control Blocks ( > since Labels are stored in the Control Blocks). > > > > But do I need to tear down the session also ??...that is do I also > need to > > release the Session Block ...or I can use the same session block to > establish a "Brand New" FT session.?? > > > > Thanks in advance, > > Aditya --------------73DDAFA15C7F66CC3DFD001B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Aditya,

    I will attempt to answer your questions.

You wrote:

 

Hello Philip,
 Thanks for your mail.
I recieved a reply from Adrian(enclosed below)......but I asked him a
further question based on his answer(also enclosed below)...regarding which I am yet to hear
from him. It would really help if you could shed some light on the matter !!!!

The question I had asked Adrian was:-- "Could you explain what you
exactly mean by "state and information related to the previous incarnation of the session "

Previous incarnation relates to fact that the proposal
is intended to provide a means to preserve state over
loss of TCP connectivity.  Incarnation may not be the
best word to capture the notion that the previous (now
dead) TCP connection is now represented by a new
TCP connection that is intended to continue the same
session.
 

In section 3.4 of your draft you say that
"If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT
   Session TLV, both LDP peers MUST release any state information and
   resources associated with the previous instantiation of the LDP
   session between the same LDP peers, including FT label state and
   Addresses"

Could you please tell me as to what specifically constitutes the "state information and resources" ??

Assigned labels and LSP related resources - i.e. queuing
related resources associated with an LSP associated
with an LDP peer session.
 

Secondly in Section 4.2 of your draft you write
   "When an LDP Peer receives a message containing the FT Protection TLV,
   it MUST take steps to secure this message (or the state information
   derived from processing the message).  Once the message is secured,
   it MUST be ACKed.  However, there is no requirement on the LSR to
   send this ACK immediately."

What do you exactly mean by the term "SECURED".....obviously it does not mean "PROCESS" the message ?
So what does "secure this message" mean ????

The precise meaning of secured is implementation specific.
An example would be to have stored pertinent information
relating to a transaction in progress in non-volatile memory.
 

Looking forward to your reply.
Thanks in Advance,
Aditya
 

Dear Adrian,
 Thanks for your reply.Could you kindly explain what you
exactly mean by "state and information related to the previous incarnation of the session "

In section 3.4 of your draft you say that
"If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT
   Session TLV, both LDP peers MUST release any state information and
   resources associated with the previous instantiation of the LDP
   session between the same LDP peers, including FT label state and
   Addresses"

I broadly understand what you mean by  "state information and resources "..but could you
give me the specifics as to what constitutes the "state information and resources" .
Sorry for bothering you with the gory details...but I guess it is better to be safe rather than sorry
Thanks for your help
warm regards,
Aditya
 
 

>>Hi again Aditya,
>>Fair question.
>>It's your choice whether you re-use the same session control block, but you should throw out state and information related >>to the previous incarnation of the session and only populate the new/re-used control block with information about the re-

>>established session.
>>OK?
>>Regards,
>>Adrian
 

-----Original Message-----
From: Philip Matthews [mailto:philipma@nortelnetworks.com]
Sent: Tuesday, March 20, 2001 9:23 AM
To: Aditya Chugh (Leela)
Subject: Re: If we recieve FT reconnect Flag = 0...can we use same
session ??

I saw this posted to the MPLS-OPS list run by the MPLS Resource Center....

If you have questions on our Fault Tolerance draft, it would be best to
send them directly to the authors. Some of us are a little behind in our
reading of various mailing lists ...

And don't send them to MPLS-OPS list, which is for operational questions,
but to the MPLS WG list instead (mpls@uu.net).

Anyway, nice to see someone else implementing the draft.

- Philip

PS. Did Adrian every reply to your question??

"Aditya Chugh (Leela)" wrote:
>
> Dear Adrian,
> I need to bother you again...!!!!!!
>
> If our FT-LDP implementation is to conform to your draft " draft-ietf-mpls-ldp-ft-00.txt "...then how should the following be handled ????

>
> Consider the case when the TCP connection (of an FT session)  needs to be reestablished.
> Before the Reconnection Timer Expires
> if I recieve an Initialization message( with valid Session TLV)..
> ....but FT reconnect flag set to 0( which means that peer has not preserved state info for previous instantiations of this LDP session )

>
> I am supposed to release all the label state and resources associated with the previous instantiation of the LDP session.

>
> this would mean that I release the Labels and the Control Blocks ( since Labels are stored in the Control Blocks).
>
> But do I need to tear down the session also ??...that is do I also need to
> release the Session Block ...or I can use the same session block to establish a "Brand New" FT session.??
>
> Thanks in advance,
> Aditya

--------------73DDAFA15C7F66CC3DFD001B-- From owner-mpls@UU.NET Mon Mar 26 12:02:03 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12198 for ; Mon, 26 Mar 2001 12:02:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiau04969; Mon, 26 Mar 2001 17:00:07 GMT Received: by mail-control.mail.uu.net id QQkiat12132 for mpls-outgoing; Mon, 26 Mar 2001 16:59:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiat12127 for ; Mon, 26 Mar 2001 16:59:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiat17769 for ; Mon, 26 Mar 2001 16:58:14 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkiat03186 for ; Mon, 26 Mar 2001 16:58:14 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 572B69400A; Mon, 26 Mar 2001 11:58:14 -0500 (EST) Message-ID: <3ABF7525.51BFB27F@sandburst.com> Date: Mon, 26 Mar 2001 11:58:14 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Michael H. O'Meara" Cc: mpls@UU.NET Subject: Re: Use of the U-bit for TLV encoding in LDP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mike, The two TLVs you mention are used in link hello messages and must be understood by any compliant LDP implementation. Hence, the U bit must be clear (=0). Since the U bit must be clear, the F bit is without meaning and should be clear (=0) as well (this would be the correct setting in any case). This could be considered an over-sight, but it should not be an important one. The U and F bits are added in order to allow for compatibility with future LDP extensions and it was NEVER intended that any LDP implementation should be allowed to not understand TLVs defined in this version and in this specification. You can verify this simply by looking for the string "|1|" which would be present in the specification if any of the TLV formats specified a "U bit" value of '1'. I believe the oversight occurred because these bit values were (in earlier iterations) previously included in the TLV type number and were moved to the ASCII art formats. As there are no 'pictures' of the format for the TLVs you point out, this didn't happen for these TLVs. -- Eric Gray "Michael H. O'Meara" wrote: > Hello all, > Section 3.3 of RFC 3036, the LDP Specification, states the > following about the usage of the U-bit in TLV encoding: > > U bit > Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear > (=0), a notification must be returned to the message originator > and the entire message must be ignored; if U is set (=1), the > unknown TLV is silently ignored and the rest of the message is > processed as if the unknown TLV did not exist. The sections > following that define TLVs specify a value for the U-bit. > > The RFC goes on to specify the value of the U-bit for most TLVs. However, > no value is specified for certain optional TLVs, such as the Configuration > Sequence TLV and Transport Address TLVs that are optional in Hello > messages. Is it safe to assume, then, that the value for the U-bit in > these optional TLVs is left to the discretion of those implementing the > RFC? While an expected value for the U-bit is obvious for certain of these > TLVs (as silently ignoring a Transport Address TLV, for example, could > lead to some difficulty in establishing an LDP session TCP connection), > there seems to be some leeway, and thus the potential for occasional > interoperability problems, for some of the other optional TLVs. If I am > missing something in the RFC, or making problems where there are none, > please point me in the right direction. > > Thanks in advance, > Mike > > *************************** > Michael O'Meara > Technician > MPLS Consortium > InterOperability Lab > University of New Hampshire > *************************** From owner-mpls@UU.NET Mon Mar 26 12:45:43 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13031 for ; Mon, 26 Mar 2001 12:45:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiaw12227; Mon, 26 Mar 2001 17:43:15 GMT Received: by mail-control.mail.uu.net id QQkiaw02448 for mpls-outgoing; Mon, 26 Mar 2001 17:42:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkiaw02422 for ; Mon, 26 Mar 2001 17:42:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiaw08942 for ; Mon, 26 Mar 2001 17:41:41 GMT Received: from exchange-west.photuris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.3.135.228]) id QQkiaw22952 for ; Mon, 26 Mar 2001 17:41:41 GMT Received: from PH0260739277U (PH02-60739277U [192.168.3.134]) by exchange-west.photuris.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H4X2MT9G; Mon, 26 Mar 2001 09:28:47 -0800 Message-ID: <000e01c0b61c$43c000d0$8603a8c0@PH0260739277U> Reply-To: "Xipeng Xiao" From: "Xipeng Xiao" To: "Xu Yingxiao" , Cc: , , , "Xipeng Xiao" References: <001e01c0b5fc$4385c480$517f78ca@xyx> Subject: Re: What happened to "A Framework for Internet Traffic Engineering" Date: Mon, 26 Mar 2001 09:43:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yingxiao, We are doing a final round of "touching-up". We will send it to the list sometime this week. Xi-Peng ----- Original Message ----- From: "Xu Yingxiao" To: Sent: Monday, March 26, 2001 5:54 AM Subject: What happened to "A Framework for Internet Traffic Engineering" > I can't find it in IETF mow(neither Draft nor RFC index). > in March 2000 > http://www.iihe.ac.be/internal-report/2000/stc-00-03.html > said > "it would be proposed as an informational RFC after some Terminology considerations with respect to compatibility with the Diffserv Work Group documents are addressed. " > > What does it means? Why can't find in IEFT now? > From owner-mpls@UU.NET Mon Mar 26 13:04:39 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13344 for ; Mon, 26 Mar 2001 13:04:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiay00538; Mon, 26 Mar 2001 18:02:05 GMT Received: by mail-control.mail.uu.net id QQkiay08560 for mpls-outgoing; Mon, 26 Mar 2001 18:01:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiay08139 for ; Mon, 26 Mar 2001 18:01:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiay20142 for ; Mon, 26 Mar 2001 18:01:00 GMT Received: from thumper.research.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQkiay13382 for ; Mon, 26 Mar 2001 18:01:00 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f2QI0iO29421; Mon, 26 Mar 2001 13:00:45 -0500 (EST) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id NAA00601; Mon, 26 Mar 2001 13:00:44 -0500 (EST) Message-Id: <200103261800.NAA00601@monday.research.telcordia.com> Date: Mon, 26 Mar 2001 13:00:44 -0500 (EST) From: Ritu Chadha Reply-To: Ritu Chadha Subject: Re: MPLS CIM schema To: mpls@UU.NET, Jaakovb@corrigent.com Cc: chadha@mailee.research.telcordia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zb3/DD064cb/SwgQFY10SQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk There isn't any yet, primarily due to lack of interest in the IETF. If people are interested in working on this, please let me know. Also, the following draft may be of interest: http://search.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt Ritu >From: Jaakov Berkovitch >To: mpls@UU.NET >Subject: MPLS CIM schema >Date: Mon, 26 Mar 2001 16:21:52 +0200 >MIME-Version: 1.0 > >Hello, > >Is anybody know if there are some extension to the CIM Network schema for >MPLS ? > >Thanks for any information. > >Yaakov Berkovitch > >Tel: 972 + 36945298 >E-mail: jaakovb@corrigent.com >WEB site: http://www.corrigent.com > ============================================================================= Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From owner-mpls@UU.NET Mon Mar 26 14:35:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14793 for ; Mon, 26 Mar 2001 14:35:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibe12990; Mon, 26 Mar 2001 19:33:17 GMT Received: by mail-control.mail.uu.net id QQkibe15226 for mpls-outgoing; Mon, 26 Mar 2001 19:32:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkibe15217 for ; Mon, 26 Mar 2001 19:32:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkibe05534 for ; Mon, 26 Mar 2001 19:32:29 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkibe10103 for ; Mon, 26 Mar 2001 19:32:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA12681 for mpls@uu.net; Mon, 26 Mar 2001 14:32:28 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkibe15196 for ; Mon, 26 Mar 2001 19:31:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkibe12092 for ; Mon, 26 Mar 2001 19:31:28 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkibe03608 for ; Mon, 26 Mar 2001 19:31:27 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA16030; Mon, 26 Mar 2001 14:30:23 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (rtp-dial-1-156.cisco.com [10.83.97.156]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA30182; Mon, 26 Mar 2001 14:31:08 -0500 (EST) Message-Id: <4.3.2.7.2.20010326143017.01d70478@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Mar 2001 14:30:50 -0500 To: "Xipeng Xiao" , "Xu Yingxiao" , From: "Thomas D. Nadeau" Subject: Re: What happened to "A Framework for Internet Traffic Engineering" Cc: , , , "Xipeng Xiao" In-Reply-To: <000e01c0b61c$43c000d0$8603a8c0@PH0260739277U> References: <001e01c0b5fc$4385c480$517f78ca@xyx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I believe that Jim Boyle mentioned at the meeting that it had expired and that it was being edited and will then be re-posted to the TE WG in the near future. --Tom >We are doing a final round of "touching-up". We will send it to >the list sometime this week. > >Xi-Peng > >----- Original Message ----- >From: "Xu Yingxiao" >To: >Sent: Monday, March 26, 2001 5:54 AM >Subject: What happened to "A Framework for Internet Traffic Engineering" > > > > I can't find it in IETF mow(neither Draft nor RFC index). > > in March 2000 > > http://www.iihe.ac.be/internal-report/2000/stc-00-03.html > > said > > "it would be proposed as an informational RFC after some Terminology > considerations with >respect to compatibility with the Diffserv Work Group documents are >addressed. " > > > > What does it means? Why can't find in IEFT now? > > From owner-mpls@UU.NET Mon Mar 26 14:48:21 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14994 for ; Mon, 26 Mar 2001 14:48:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibf21886; Mon, 26 Mar 2001 19:45:26 GMT Received: by mail-control.mail.uu.net id QQkibe16021 for mpls-outgoing; Mon, 26 Mar 2001 19:44:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkibe16014 for ; Mon, 26 Mar 2001 19:44:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkibe20843 for ; Mon, 26 Mar 2001 19:43:46 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkibe20044 for ; Mon, 26 Mar 2001 19:43:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA14266 for mpls@uu.net; Mon, 26 Mar 2001 14:43:45 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkibe15962 for ; Mon, 26 Mar 2001 19:43:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkibe06802 for ; Mon, 26 Mar 2001 19:42:26 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkibe19141 for ; Mon, 26 Mar 2001 19:42:25 GMT Received: (qmail 17141 invoked by uid 104); 26 Mar 2001 19:42:24 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 1.171286 secs); 26/03/2001 11:42:23 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 26 Mar 2001 19:42:23 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f2QJgMV20577 for ; Mon, 26 Mar 2001 11:42:22 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 11:42:44 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B55@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: Explicit null label ? Date: Mon, 26 Mar 2001 11:42:36 -0800 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0B62C.E86986A0" 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_01C0B62C.E86986A0 Content-Type: text/plain; charset="ISO-8859-1" Hi All, In an MPLS network that supports TE, the constraint-based routing is done via CR-LDP or RSVP-TE signaling. My question is which one of the following methods have people adapted or is envisioned to be superior: 1) CR-LDP/RSV-TE signaling be done using unlabeled IP packets. 2) CR-LDP/RSVP-TE signaling be done using MPLS labeled packet with label=0 (explicit null label). Thanks, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 <> ------_=_NextPart_000_01C0B62C.E86986A0 Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C0B62C.E86986A0-- From owner-mpls@UU.NET Mon Mar 26 16:26:45 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16862 for ; Mon, 26 Mar 2001 16:26:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibl11076; Mon, 26 Mar 2001 21:23:38 GMT Received: by mail-control.mail.uu.net id QQkibl27461 for mpls-outgoing; Mon, 26 Mar 2001 21:22:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkibl27452 for ; Mon, 26 Mar 2001 21:22:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkibl17931 for ; Mon, 26 Mar 2001 21:21:23 GMT Received: from imchub1.cosinecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imchub1.cosinecom.com [63.88.104.18]) id QQkibl16345 for ; Mon, 26 Mar 2001 21:21:23 GMT Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Mar 2001 13:21:22 -0800 Message-ID: <5E686636124A2042B4E5EE1F15191F270838FA@exchsrv3> From: Anoop Ghanwani To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: Explicit null label ? Date: Mon, 26 Mar 2001 13:21:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Is there any reason why would you even consider the second option? -Anoop > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, March 26, 2001 11:43 AM > To: 'mpls@uu.net' > Subject: Explicit null label ? > Importance: Low > > > Hi All, > > In an MPLS network that supports TE, the constraint-based > routing is done via CR-LDP or RSVP-TE signaling. My question > is which one of the following methods have people adapted or > is envisioned to be superior: > > 1) CR-LDP/RSV-TE signaling be done using unlabeled IP packets. > 2) CR-LDP/RSVP-TE signaling be done using MPLS labeled packet > with label=0 (explicit null label). > > > > Thanks, > Shahram Davari > Systems Engineer > Product Research Group > PMC-Sierra, Inc. (Ottawa) > Phone: (613) 271-4018 > Fax: (613) 271-7007 > <> > From owner-mpls@UU.NET Mon Mar 26 16:44:56 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17169 for ; Mon, 26 Mar 2001 16:44:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibm06086; Mon, 26 Mar 2001 21:41:53 GMT Received: by mail-control.mail.uu.net id QQkibm29472 for mpls-outgoing; Mon, 26 Mar 2001 21:41:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkibm29444 for ; Mon, 26 Mar 2001 21:40:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkibm16655 for ; Mon, 26 Mar 2001 21:40:37 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkibm04596 for ; Mon, 26 Mar 2001 21:40:36 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA24643 for mpls@uu.net; Mon, 26 Mar 2001 16:40:35 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkibm28988 for ; Mon, 26 Mar 2001 21:36:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkibm04994 for ; Mon, 26 Mar 2001 21:35:22 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkibm28041 for ; Mon, 26 Mar 2001 21:35:21 GMT Received: (qmail 13247 invoked by uid 104); 26 Mar 2001 21:35:21 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.904287 secs); 26/03/2001 13:35:20 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 26 Mar 2001 21:35:19 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f2QLZIV13259; Mon, 26 Mar 2001 13:35:19 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 13:35:41 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B57@BBY1EXM01> From: Shahram Davari To: "'Anoop Ghanwani'" Cc: "'mpls@uu.net'" Subject: RE: Explicit null label ? Date: Mon, 26 Mar 2001 13:35:32 -0800 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 Anoop, In the second option, the LSRs recieve only labeled packets. This could potentially reduce hardware requirement. Yours, -Shahram > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@cosinecom.com] > Sent: Monday, March 26, 2001 4:21 PM > To: Shahram Davari; 'mpls@uu.net' > Subject: RE: Explicit null label ? > > > > Is there any reason why would you even consider the second > option? > > -Anoop > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, March 26, 2001 11:43 AM > > To: 'mpls@uu.net' > > Subject: Explicit null label ? > > Importance: Low > > > > > > Hi All, > > > > In an MPLS network that supports TE, the constraint-based > > routing is done via CR-LDP or RSVP-TE signaling. My question > > is which one of the following methods have people adapted or > > is envisioned to be superior: > > > > 1) CR-LDP/RSV-TE signaling be done using unlabeled IP packets. > > 2) CR-LDP/RSVP-TE signaling be done using MPLS labeled packet > > with label=0 (explicit null label). > > > > > > > > Thanks, > > Shahram Davari > > Systems Engineer > > Product Research Group > > PMC-Sierra, Inc. (Ottawa) > > Phone: (613) 271-4018 > > Fax: (613) 271-7007 > > <> > > > From owner-mpls@UU.NET Mon Mar 26 16:57:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17704 for ; Mon, 26 Mar 2001 16:57:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibn20691; Mon, 26 Mar 2001 21:54:09 GMT Received: by mail-control.mail.uu.net id QQkibn00966 for mpls-outgoing; Mon, 26 Mar 2001 21:53:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkibn00913 for ; Mon, 26 Mar 2001 21:52:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkibn15116 for ; Mon, 26 Mar 2001 21:51:56 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkibn18738 for ; Mon, 26 Mar 2001 21:51:56 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id BDBB194009; Mon, 26 Mar 2001 16:51:52 -0500 (EST) Message-ID: <3ABFB9F8.8C15E445@sandburst.com> Date: Mon, 26 Mar 2001 16:51:52 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Anoop Ghanwani Cc: "'Shahram Davari'" , MPLS Mailing List Subject: Re: Explicit null label ? References: <5E686636124A2042B4E5EE1F15191F270838FA@exchsrv3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anoop, There are two cases. The first is when LSP signaling is used hierarchically (in which case, the explicit null may be used by the penultimate hop for the LSP being used). It would only be used at the last hop of an LSP hierarchy. This does not appear to be the case that Shahram is asking about. The other is illustrated below. You have these two implementations - call them Butch Cassidy and Sundance Kid. Both are technically LSRs, but Butch Cassidy signals the implicit null whenever it can (possibly because it doesn't have a clue what to do with a real label) and the explicit null in ALL other cases - while Sundance Kid can't send anything but labeled packets. Since the explicit null label is well defined in RFC 3032, there's theoretically no reason why Sundance Kid cannot use explicit null labeled packets to talk to Butch Cassidy. Understand that I am not advocating this behavior. In fact far from it. I think Butch Cassidy and Sundance Kid should be shot. But, that is another story... -- Eric Gray You wrote: > Is there any reason why would you even consider the second > option? > > -Anoop > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, March 26, 2001 11:43 AM > > To: 'mpls@uu.net' > > Subject: Explicit null label ? > > Importance: Low > > > > > > Hi All, > > > > In an MPLS network that supports TE, the constraint-based > > routing is done via CR-LDP or RSVP-TE signaling. My question > > is which one of the following methods have people adapted or > > is envisioned to be superior: > > > > 1) CR-LDP/RSV-TE signaling be done using unlabeled IP packets. > > 2) CR-LDP/RSVP-TE signaling be done using MPLS labeled packet > > with label=0 (explicit null label). > > > > > > > > Thanks, > > Shahram Davari > > Systems Engineer > > Product Research Group > > PMC-Sierra, Inc. (Ottawa) > > Phone: (613) 271-4018 > > Fax: (613) 271-7007 > > <> > > From owner-mpls@UU.NET Mon Mar 26 17:01:32 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18138 for ; Mon, 26 Mar 2001 17:01:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibn18412; Mon, 26 Mar 2001 21:58:37 GMT Received: by mail-control.mail.uu.net id QQkibn01408 for mpls-outgoing; Mon, 26 Mar 2001 21:57:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkibn01212 for ; Mon, 26 Mar 2001 21:55:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkibn20227 for ; Mon, 26 Mar 2001 21:55:02 GMT Received: from enst.enst.fr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: enst.enst.fr [137.194.2.16]) id QQkibn21061 for ; Mon, 26 Mar 2001 21:54:37 GMT Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by enst.enst.fr (Postfix) with ESMTP id 1BA611C8CD; Mon, 26 Mar 2001 23:54:33 +0200 (MET DST) Received: from mercure.rezel.enst.fr (mercure.maisel1.rezel.enst.fr [137.194.9.30]) by email.enst.fr (8.9.3/8.9.3) with SMTP id XAA27786; Mon, 26 Mar 2001 23:54:32 +0200 (MET DST) From: Vincent Jardin Organization: ENST Paris Date: Mon, 26 Mar 2001 23:58:13 +0200 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-15" To: "padua" References: <003701c0b606$df589f40$1d0c6a8f@dt.fee.unicamp.br> In-Reply-To: <003701c0b606$df589f40$1d0c6a8f@dt.fee.unicamp.br> Subject: Re: MPLS over DWDM Cc: mpls@UU.NET MIME-Version: 1.0 Message-Id: <0103262358130A.11206@mercure.rezel.enst.fr> Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQkibn18412 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA18138 Le Lundi 26 Mars 2001 17:10, vous avez écrit : > > Hi! > I'd like to know about MPLS over DWDM. Does it exists some norm for this > technology? You should start getting informations about GMPLS (previously MP(lambda)S) on: http://www.mplsrc.com/articles.shtml and SRLG. Tibor Cinkler has written a good paper about an "ILP formulation of grooming over wavelength routing with protection" (Sorry I just have a paper release). Then he has written some papers on IEEE that get some heuristics to solve the Wavelength Routing (WR). He has formalized the SRLG (Shared Resource Link Group) constrains in his formulations. Moreover, the drafts draft-many-inference-srlg-00.txt draft-papadimitriou-enhanced-lsps-03.txt draft-ietf-mpls-generalized-signaling-02.txt draft-ietf-mpls-generalized-cr-ldp-01.txt draft-ietf-mpls-generalized-rsvp-te-01.txt are 3 good starts. I hope it was usefull, Vincent From owner-mpls@UU.NET Mon Mar 26 17:17:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18955 for ; Mon, 26 Mar 2001 17:17:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibo02949; Mon, 26 Mar 2001 22:13:56 GMT Received: by mail-control.mail.uu.net id QQkibo19435 for mpls-outgoing; Mon, 26 Mar 2001 22:13:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkibo19394 for ; Mon, 26 Mar 2001 22:12:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkibo00479 for ; Mon, 26 Mar 2001 22:12:24 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkibo08414 for ; Mon, 26 Mar 2001 22:12:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA28615 for mpls@uu.net; Mon, 26 Mar 2001 17:12:23 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkibo19256 for ; Mon, 26 Mar 2001 22:11:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkibo15362 for ; Mon, 26 Mar 2001 22:08:55 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkibo16214 for ; Mon, 26 Mar 2001 22:08:54 GMT Received: (qmail 16418 invoked by uid 104); 26 Mar 2001 22:08:53 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 1.163945 secs); 26/03/2001 14:08:52 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 26 Mar 2001 22:08:52 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f2QM8oV20227; Mon, 26 Mar 2001 14:08:51 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 14:09:13 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B59@BBY1EXM01> From: Shahram Davari To: "'Eric Gray'" , Anoop Ghanwani Cc: MPLS Mailing List Subject: RE: Explicit null label ? Date: Mon, 26 Mar 2001 14:09:06 -0800 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 Eric, Thanks for your nice explanation. I also am not advocating such as behavior, it is just that somebody in IETF told me that they are doing this, and I just wanted to see whether this is the current practice. The logic as you said is that if an LSR (not LER) for reasons can't accept unlabeled packets, then using explicit null label could be a solution, although at each hop a extra push and pop would be needed. Yours, -Shahram > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Monday, March 26, 2001 4:52 PM > To: Anoop Ghanwani > Cc: Shahram Davari; MPLS Mailing List > Subject: Re: Explicit null label ? > > > Anoop, > > There are two cases. The first is when LSP signaling > is used hierarchically (in which case, the explicit null may > be used by the penultimate hop for the LSP being used). > It would only be used at the last hop of an LSP hierarchy. > This does not appear to be the case that Shahram is asking > about. The other is illustrated below. > > You have these two implementations - call them Butch > Cassidy and Sundance Kid. Both are technically LSRs, > but Butch Cassidy signals the implicit null whenever it can > (possibly because it doesn't have a clue what to do with a > real label) and the explicit null in ALL other cases - while > Sundance Kid can't send anything but labeled packets. > > Since the explicit null label is well defined in RFC 3032, > there's theoretically no reason why Sundance Kid cannot > use explicit null labeled packets to talk to Butch Cassidy. > > Understand that I am not advocating this behavior. In fact > far from it. I think Butch Cassidy and Sundance Kid should > be shot. But, that is another story... > > -- > Eric Gray > > You wrote: > > > Is there any reason why would you even consider the second > > option? > > > > -Anoop > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Monday, March 26, 2001 11:43 AM > > > To: 'mpls@uu.net' > > > Subject: Explicit null label ? > > > Importance: Low > > > > > > > > > Hi All, > > > > > > In an MPLS network that supports TE, the constraint-based > > > routing is done via CR-LDP or RSVP-TE signaling. My question > > > is which one of the following methods have people adapted or > > > is envisioned to be superior: > > > > > > 1) CR-LDP/RSV-TE signaling be done using unlabeled IP packets. > > > 2) CR-LDP/RSVP-TE signaling be done using MPLS labeled packet > > > with label=0 (explicit null label). > > > > > > > > > > > > Thanks, > > > Shahram Davari > > > Systems Engineer > > > Product Research Group > > > PMC-Sierra, Inc. (Ottawa) > > > Phone: (613) 271-4018 > > > Fax: (613) 271-7007 > > > <> > > > > From owner-mpls@UU.NET Mon Mar 26 17:41:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19633 for ; Mon, 26 Mar 2001 17:41:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibq00650; Mon, 26 Mar 2001 22:38:28 GMT Received: by mail-control.mail.uu.net id QQkibq21980 for mpls-outgoing; Mon, 26 Mar 2001 22:37:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkibq21975 for ; Mon, 26 Mar 2001 22:37:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkibq27394 for ; Mon, 26 Mar 2001 22:37:40 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkibq25089 for ; Mon, 26 Mar 2001 22:37:40 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 49A4394006; Mon, 26 Mar 2001 17:37:36 -0500 (EST) Message-ID: <3ABFC4B0.7E28E49C@sandburst.com> Date: Mon, 26 Mar 2001 17:37:36 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari Cc: Anoop Ghanwani , MPLS Mailing List Subject: Re: Explicit null label ? References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B59@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, Not too many months ago, I had an off-line discussion with someone about this kind of problem. The conclusion arrived at was that we have two different perspectives: A) Pragmatism and the reality of implementation complexity; B) Protocol Purity or the end of the world as we know it. At the risk of exposing my position in the discussion, I have to say that the behavior you describe is allowed and - thus - it cannot be much of a surprise that it will happen. But I feel that it is not healthy behavior - and may be pathological. There are lots of reasons why an implementation may assign special significance to packets received with a label - even the explicit null label. In fact, it is possible that a system might assign the explicit null label specifically to differentiate some packets from IP packets (possibly received as a result of an implicit null assignment). A chance meeting between an implementation that assigns specific significance to the explicit null label (believing that the explicit null label will only be used in the cases where it has been assigned) and another implementation that always uses the explicit null label except when it has a legitimate label alternative is likely to produce surprises for both sets of implementers. In protocol implementation and deployment, surprises are seldom good. -- Eric Gray You wrote: > Hi Eric, > > Thanks for your nice explanation. I also am not advocating > such as behavior, it is just that somebody in IETF told me > that they are doing this, and I just wanted to see whether > this is the current practice. > > The logic as you said is that if an LSR (not LER) for reasons > can't accept unlabeled packets, then using explicit null label > could be a solution, although at each hop a extra push and pop > would be needed. > > Yours, > -Shahram > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@sandburst.com] > > Sent: Monday, March 26, 2001 4:52 PM > > To: Anoop Ghanwani > > Cc: Shahram Davari; MPLS Mailing List > > Subject: Re: Explicit null label ? > > > > > > Anoop, > > > > There are two cases. The first is when LSP signaling > > is used hierarchically (in which case, the explicit null may > > be used by the penultimate hop for the LSP being used). > > It would only be used at the last hop of an LSP hierarchy. > > This does not appear to be the case that Shahram is asking > > about. The other is illustrated below. > > > > You have these two implementations - call them Butch > > Cassidy and Sundance Kid. Both are technically LSRs, > > but Butch Cassidy signals the implicit null whenever it can > > (possibly because it doesn't have a clue what to do with a > > real label) and the explicit null in ALL other cases - while > > Sundance Kid can't send anything but labeled packets. > > > > Since the explicit null label is well defined in RFC 3032, > > there's theoretically no reason why Sundance Kid cannot > > use explicit null labeled packets to talk to Butch Cassidy. > > > > Understand that I am not advocating this behavior. In fact > > far from it. I think Butch Cassidy and Sundance Kid should > > be shot. But, that is another story... > > > > -- > > Eric Gray > > > > You wrote: > > > > > Is there any reason why would you even consider the second > > > option? > > > > > > -Anoop > > > > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Monday, March 26, 2001 11:43 AM > > > > To: 'mpls@uu.net' > > > > Subject: Explicit null label ? > > > > Importance: Low > > > > > > > > > > > > Hi All, > > > > > > > > In an MPLS network that supports TE, the constraint-based > > > > routing is done via CR-LDP or RSVP-TE signaling. My question > > > > is which one of the following methods have people adapted or > > > > is envisioned to be superior: > > > > > > > > 1) CR-LDP/RSV-TE signaling be done using unlabeled IP packets. > > > > 2) CR-LDP/RSVP-TE signaling be done using MPLS labeled packet > > > > with label=0 (explicit null label). > > > > > > > > > > > > > > > > Thanks, > > > > Shahram Davari > > > > Systems Engineer > > > > Product Research Group > > > > PMC-Sierra, Inc. (Ottawa) > > > > Phone: (613) 271-4018 > > > > Fax: (613) 271-7007 > > > > <> > > > > > > From owner-mpls@UU.NET Mon Mar 26 17:54:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19989 for ; Mon, 26 Mar 2001 17:54:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkibr15808; Mon, 26 Mar 2001 22:52:37 GMT Received: by mail-control.mail.uu.net id QQkibr23071 for mpls-outgoing; Mon, 26 Mar 2001 22:52:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkibr23030 for ; Mon, 26 Mar 2001 22:51:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkibr24267 for ; Mon, 26 Mar 2001 22:51:16 GMT From: PDiamond@semtech.com Received: from mail.semtech.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [209.241.157.179]) id QQkibr14352 for ; Mon, 26 Mar 2001 22:51:16 GMT Received: by mail.semtech.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 88256A1B.007D8204 ; Mon, 26 Mar 2001 15:50:52 -0700 X-Lotus-FromDomain: SEMNP To: Eric Gray cc: Anoop Ghanwani , MPLS Mailing List , Shahram Davari Message-ID: <88256A1B.007D819A.00@mail.semtech.com> Date: Mon, 26 Mar 2001 15:51:02 -0700 Subject: Re: Explicit null label ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Eric, You gave yourself away...I agree...implementation is the step before revenue and deep into the cost cycle...an achillies heel. Your; "In protocol implementation and deployment, surprises are seldom good." an axion to live by! Patrick Diamond From owner-mpls@UU.NET Tue Mar 27 03:39:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15328 for ; Tue, 27 Mar 2001 03:39:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkide29056; Tue, 27 Mar 2001 08:36:05 GMT Received: by mail-control.mail.uu.net id QQkide10905 for mpls-outgoing; Tue, 27 Mar 2001 08:35:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkide10900 for ; Tue, 27 Mar 2001 08:35:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkide17988 for ; Tue, 27 Mar 2001 08:34:38 GMT Received: from yc.shu.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.120.127.220]) id QQkide28037 for ; Tue, 27 Mar 2001 08:34:37 GMT Received: from xyx ([202.120.127.81]) by yc.shu.edu.cn (8.9.3+Sun/8.9.1) with SMTP id QAA16740 for ; Tue, 27 Mar 2001 16:37:06 +0800 (CST) Message-ID: <001001c0b699$5a0b10a0$517f78ca@xyx> From: "Xu Yingxiao" To: Subject: search "Formulation of the Traffic Engineering.." by Muckai K Girish Date: Tue, 27 Mar 2001 16:38:51 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C0B6DC.67A809A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C0B6DC.67A809A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhbSBsb29raW5nIGZvciBiZWxvdyBkb2N1bWVudC4NCkZvcm11bGF0aW9uIG9mIHRoZSBUcmFm ZmljIEVuZ2luZWVyaW5nIFByb2JsZW1zIGluIE1QTFMgQmFzZWQgSVAgTmV0d29ya3MgTXVja2Fp IEsgR2lyaXNoICBTQkMgVGVjaG5vbG9neSBSZXNvdXJjZXMsIEluYy4gQmVpIFpob3UgYW5kIEpp YW4tUWlhbmcgSHUgQm9zdG9uIFVuaXZlcnNpdHkNCg0KSXQgc2VlbXMgaXQgY2FuIGJlIGRvd25s b2FkZWQgZnJvbSBodHRwOi8vZGxpYi5jb21wdXRlci5vcmcvY29uZmVyZW4vaXNjYy8wNzIyL3Bk Zi8wNzIyMDIxNC5wZGYNCkJ1dCBwYXNzd29yZCBpcyBuZWVkZWQgYW5kIEkgaGF2ZW4ndC4NCkFu eW9uZSB3aG8gaGFzIHRoZSBkb2N1bWVudCBwbGVhc2UgbWFpbCBhIGNvcHkgdG8gbWUuIFRoYW5r cyBhIGxvdCENCg0KDQoNCg== ------=_NextPart_000_000D_01C0B6DC.67A809A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40MTM0LjEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPEgzPkkgYW0gbG9va2lu ZyBmb3ImbmJzcDtiZWxvdyBkb2N1bWVudC48L0gzPg0KPERJVj5Gb3JtdWxhdGlvbiBvZiB0aGUg VHJhZmZpYyBFbmdpbmVlcmluZyBQcm9ibGVtcyBpbiBNUExTIEJhc2VkIElQIE5ldHdvcmtzIA0K PEI+TXVja2FpIEsgR2lyaXNoPC9CPiZuYnNwOyA8ST5TQkMgVGVjaG5vbG9neSBSZXNvdXJjZXMs IEluYy4gPC9JPjxCPkJlaSBaaG91IA0KYW5kIEppYW4tUWlhbmcgSHU8L0I+IDxJPkJvc3RvbiBV bml2ZXJzaXR5PC9JPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPkl0IHNlZW1zIGl0IGNhbiBiZSBkb3dubG9hZGVk IGZyb20gPEEgDQpocmVmPSJodHRwOi8vZGxpYi5jb21wdXRlci5vcmcvY29uZmVyZW4vaXNjYy8w NzIyL3BkZi8wNzIyMDIxNC5wZGYiPmh0dHA6Ly9kbGliLmNvbXB1dGVyLm9yZy9jb25mZXJlbi9p c2NjLzA3MjIvcGRmLzA3MjIwMjE0LnBkZjwvQT48L0RJVj48L0ZPTlQ+PC9ESVY+DQo8RElWPkJ1 dCBwYXNzd29yZCBpcyBuZWVkZWQgYW5kIEkgaGF2ZW4ndC48L0RJVj4NCjxESVY+QW55b25lIHdo byBoYXMgdGhlIGRvY3VtZW50IHBsZWFzZSBtYWlsIGEgY29weSB0byBtZS4gVGhhbmtzIGEgbG90 ITwvRElWPg0KPEgzPiZuYnNwOzwvSDM+DQo8RElWPiZuYnNwOzwvRElWPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000D_01C0B6DC.67A809A0-- From owner-mpls@UU.NET Tue Mar 27 03:50:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15415 for ; Tue, 27 Mar 2001 03:50:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkidf08863; Tue, 27 Mar 2001 08:48:32 GMT Received: by mail-control.mail.uu.net id QQkidf11887 for mpls-outgoing; Tue, 27 Mar 2001 08:48:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkidf11859 for ; Tue, 27 Mar 2001 08:47:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkidf23377 for ; Tue, 27 Mar 2001 08:46:12 GMT Received: from yc.shu.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.120.127.220]) id QQkidf06705 for ; Tue, 27 Mar 2001 08:46:11 GMT Received: from xyx ([202.120.127.81]) by yc.shu.edu.cn (8.9.3+Sun/8.9.1) with SMTP id QAA16812 for ; Tue, 27 Mar 2001 16:48:41 +0800 (CST) Message-ID: <002901c0b69a$f732e320$517f78ca@xyx> From: "Xu Yingxiao" To: Subject: any advice is appreciated Date: Tue, 27 Mar 2001 16:50:25 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C0B6DE.05349160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C0B6DE.05349160 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhbSBwcmVwYXJpbmcgbXkgUEhELiBkaXNzZXJ0YXRpb24uIEkgYW0gIGRvaW5nIHJlc2VhcmNo IG9uIE1QTFMgUW9TLiANCkkgYW0gcmVhZHkgdG8gZG8gcmVzZWFyY2ggb24gdHdvIGl0ZW1zOiAx LiBNUExTICYgVEUsIGZvY3VzaW5nIG9uIE1QTFMgUW9TIFJvdXRpbmcgYWxvZ3JpdGhtICAgMi5N UExTICYgRGlmZi1TZXJ2Lg0KDQpJcyB0aGVzZSB0b3BpYyB3b3J0aHkgdG8gc3R1ZHkgYW5kIGNh biBpdCBmb3JtIGEgUEhELiBkaXNzZXJ0YXRpb24/DQpJIGFtIGVzcGVjaWFsbHkgcHV6emxlZCBp biAgTVBMUyAmIERpZmYtU2VydiBhcyAgbW9zdCBzdHVkeWluZyBpcyBmb2N1cyBvbiBhcmNoaXRl Y3R1cmUgYW5kIHByb2Nlc3Mgc2NoZW1lIHdoaWNoIGlzIGhhcmQgdG8gaGF2ZSBhbnkgbm90aW9u IGZvciBwZXJzb24gd2hvIGlzIG5vdCBpbiBJbnRlcm5hdGlvbmFsIHN0dWR5aW5nIGdyb3VwLg0K ------=_NextPart_000_0026_01C0B6DE.05349160 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40MTM0LjEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgYW0gcHJlcGFyaW5nIG15 IFBIRC4gZGlzc2VydGF0aW9uLiBJJm5ic3A7YW0gDQombmJzcDtkb2luZyZuYnNwO3Jlc2VhcmNo IG9uIE1QTFMgUW9TLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JJm5ic3A7YW0g cmVhZHkgdG8mbmJzcDtkbyByZXNlYXJjaCBvbiB0d28gaXRlbXM6IDEuIE1QTFMgDQomYW1wOyBU RSwgZm9jdXNpbmcgb24gTVBMUyBRb1MgUm91dGluZyBhbG9ncml0aG0mbmJzcDsmbmJzcDsgMi5N UExTICZhbXA7IA0KRGlmZi1TZXJ2LjxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5JcyZuYnNwO3RoZXNlIHRvcGljJm5ic3A7d29ydGh5Jm5ic3A7dG8gc3R1ZHkgYW5kIGNhbiBp dCBmb3JtIA0KYSBQSEQuIGRpc3NlcnRhdGlvbj88QlI+SSZuYnNwO2FtJm5ic3A7ZXNwZWNpYWxs eSBwdXp6bGVkIGluICZuYnNwO01QTFMgJmFtcDsgDQpEaWZmLVNlcnYgYXMmbmJzcDsgbW9zdCZu YnNwO3N0dWR5aW5nIGlzIGZvY3VzIG9uIGFyY2hpdGVjdHVyZSBhbmQgcHJvY2VzcyANCnNjaGVt ZSB3aGljaCBpcyBoYXJkIHRvIGhhdmUgYW55IG5vdGlvbiBmb3IgcGVyc29uIHdobyBpcyBub3Qg aW4gSW50ZXJuYXRpb25hbCANCnN0dWR5aW5nIGdyb3VwLjwvRk9OVD48L0RJVj48L0JPRFk+PC9I VE1MPg0K ------=_NextPart_000_0026_01C0B6DE.05349160-- From owner-mpls@UU.NET Tue Mar 27 04:27:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15699 for ; Tue, 27 Mar 2001 04:27:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkidh01843; Tue, 27 Mar 2001 09:24:42 GMT Received: by mail-control.mail.uu.net id QQkidh00128 for mpls-outgoing; Tue, 27 Mar 2001 09:24:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkidh00123 for ; Tue, 27 Mar 2001 09:24:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkidh19757 for ; Tue, 27 Mar 2001 09:23:53 GMT Received: from smtp1.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.cluster.oleane.net [195.25.12.16]) id QQkidh01169 for ; Tue, 27 Mar 2001 09:23:53 GMT Received: from oleane (dyn-1-2-159.Vin.dialup.oleane.fr [194.2.4.159]) by smtp1.cluster.oleane.net with SMTP id f2R9NoV54728 for ; Tue, 27 Mar 2001 11:23:51 +0200 (CEST) Message-ID: <005501c0b69f$d592d900$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP.Net Convention Date: Tue, 27 Mar 2001 11:25:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C0B6B0.96531320" 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_0052_01C0B6B0.96531320 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What does the IP standard protocol really afford today in terms of = security, quality of service, mobility and billing?=20 What types of virtual networks can be set up? Can a private network use = VoIP technologies to convey voice? Can a mobile network be included in that equation? What tools are = available and are they interoperable?=20 What services do operators propose today? The IP.Net Convention, to be held in Paris, June 19 to 22, will provide = technical and commercial answers to these questions, illustrated by = concrete implementation cases.=20 http://www.upperside.fr/ipnetworks/ipnet.htm ------=_NextPart_000_0052_01C0B6B0.96531320 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What does the IP standard protocol really afford = today in=20 terms of security, quality of service, mobility and billing?
What = types of=20 virtual networks can be set up? Can a private network use VoIP = technologies to=20 convey voice?
Can a mobile network be included in that equation? What = tools=20 are available and are they interoperable?
What services do operators = propose=20 today?

The IP.Net Convention, to be held in = Paris, June=20 19 to 22, will provide technical and commercial answers to these = questions,=20 illustrated by concrete implementation cases.
http://www.uppersid= e.fr/ipnetworks/ipnet.htm
 
------=_NextPart_000_0052_01C0B6B0.96531320-- From owner-mpls@UU.NET Tue Mar 27 04:52:21 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16098 for ; Tue, 27 Mar 2001 04:52:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkidj25496; Tue, 27 Mar 2001 09:50:10 GMT Received: by mail-control.mail.uu.net id QQkidj01924 for mpls-outgoing; Tue, 27 Mar 2001 09:49:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkidj01913 for ; Tue, 27 Mar 2001 09:49:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkidj18661 for ; Tue, 27 Mar 2001 09:49:05 GMT Received: from hclhprnd.hclt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkidj24607 for ; Tue, 27 Mar 2001 09:49:04 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id PAA07561 for ; Tue, 27 Mar 2001 15:45:51 +0530 Received: from MALLIKPC ([192.168.232.110]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2M20VMD; Tue, 27 Mar 2001 15:18:29 +0530 Message-ID: <005f01c0b6a3$4468b090$6ee8a8c0@hclt.com> From: "gopinathg" To: Subject: CRLDP Tunnel Egress Date: Tue, 27 Mar 2001 15:19:37 +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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, I have a question regarding the determination of the CRLSP tunnel egress. There is a problem in determining the egress of CRLDP tunnels 1) If the LSP was established using ER-HOPs and the last ER-HOP is a prefix element , then how will the ingress(ans also the other nodes int the LSP which maintain tunnel state ) know the tunnel egress. 2) If there are no ER-HOPs and only a FEC element with a prefix or host element, how will the ingress and the other LSRs in the LSP which maintain tunnel state know the tunnel egress. The need for knowing egress of the tunnel is two-fold. 1)If the LSPID is a hop in a ER-HOP TLV then there is a need for the source end of the inner LSP(which is a ER-HOP) to peer with the tunnel egress. 2)For indexing the tunnel the LSP ingress and the other nodes in the LSP need to know the IP address of the LSP egress. Please clarify. Thanks in advance Regards, gopinathg From owner-mpls@UU.NET Tue Mar 27 10:58:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20804 for ; Tue, 27 Mar 2001 10:58:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkieh16655; Tue, 27 Mar 2001 15:56:01 GMT Received: by mail-control.mail.uu.net id QQkieh04170 for mpls-outgoing; Tue, 27 Mar 2001 15:55:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkieh04162 for ; Tue, 27 Mar 2001 15:55:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkieh11493 for ; Tue, 27 Mar 2001 15:55:01 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQkieh16024 for ; Tue, 27 Mar 2001 15:55:01 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 KAA02867 for ; Tue, 27 Mar 2001 10:55:00 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id KAA02841; Tue, 27 Mar 2001 10:54:59 -0500 (EST) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA16723; Tue, 27 Mar 2001 10:54:59 -0500 Message-ID: <3AC0B88A.314C5939@hotair.hobl.lucent.com> Date: Tue, 27 Mar 2001 10:58:02 -0500 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?=BE=C6=C1=F1=B6=F5?= CC: mpls@UU.NET Subject: Re: Any references to MPLS TE routing algorithms? References: <002501c0b3f4$c48c6020$77131796@LocalHost> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQkieh16655 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA20804 If you are looking for algorithms for diversely routed MPLS paths, you should look up the book "Survivable Networks: Algorithms for Diverse Routing, Kluwer Academic Publishers (1999)", ISBN 0-7923-8381-8. > ¾ÆÁñ¶õ wrote: > > Hello all, > > We're searching for any references or pointers to routing algorithms > for the MPLS Traffic Engineering. > I'm wondering if the algorithms or methodologies have any different > features compared with the existing > routing methods of the previous literature. Anyway, your help will be > very appreciated. > Thanks for your reading. > > Rae. > > From owner-mpls@UU.NET Tue Mar 27 22:59:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15372 for ; Tue, 27 Mar 2001 22:59:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkigd12731; Wed, 28 Mar 2001 03:57:22 GMT Received: by mail-control.mail.uu.net id QQkigd22668 for mpls-outgoing; Wed, 28 Mar 2001 03:56:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkigd22662 for ; Wed, 28 Mar 2001 03:56:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkigd13592 for ; Wed, 28 Mar 2001 03:56:08 GMT Received: from zcars04e.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQkigd27583 for ; Wed, 28 Mar 2001 03:56:07 GMT Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Tue, 27 Mar 2001 22:55:06 -0500 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HS2C07HX; Tue, 27 Mar 2001 22:55:05 -0500 Received: from americasm01.nt.com (artpt30z.us.nortel.com [47.140.68.19]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRVYLTB; Tue, 27 Mar 2001 22:55:06 -0500 Message-ID: <3AC116A2.8F2D25B4@americasm01.nt.com> Date: Tue, 27 Mar 2001 17:39:30 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Aditya Chugh CC: mpls@UU.NET, af@dataconnection.com Subject: Re: What exactly constitutes the State info in FT-LDP and what do we mean by "Securing the message" ?? References: <70EB682332F4D41187D6000629AE2C651FE70B@mail.in.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Aditya: Adrian beat me to the reply, but I agree with everything he said. Does this answer your question? - Philip Aditya Chugh wrote: > > Hello Philip, > Thanks for your mail. > I recieved a reply from Adrian(enclosed below)......but I asked him a > further question based on his answer(also enclosed below)...regarding which I am yet to hear > from him. It would really help if you could shed some light on the matter !!!! > > The question I had asked Adrian was:-- "Could you explain what you > exactly mean by "state and information related to the previous incarnation of the session " > > In section 3.4 of your draft you say that > "If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT > Session TLV, both LDP peers MUST release any state information and > resources associated with the previous instantiation of the LDP > session between the same LDP peers, including FT label state and > Addresses" > > Could you please tell me as to what specifically constitutes the "state information and resources" ?? > > Secondly in Section 4.2 of your draft you write > "When an LDP Peer receives a message containing the FT Protection TLV, > it MUST take steps to secure this message (or the state information > derived from processing the message). Once the message is secured, > it MUST be ACKed. However, there is no requirement on the LSR to > send this ACK immediately." > > What do you exactly mean by the term "SECURED".....obviously it does not mean "PROCESS" the message ? > So what does "secure this message" mean ???? > > Looking forward to your reply. > Thanks in Advance, > Aditya > > Dear Adrian, > Thanks for your reply.Could you kindly explain what you > exactly mean by "state and information related to the previous incarnation of the session " > > In section 3.4 of your draft you say that > "If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT > Session TLV, both LDP peers MUST release any state information and > resources associated with the previous instantiation of the LDP > session between the same LDP peers, including FT label state and > Addresses" > > I broadly understand what you mean by "state information and resources "..but could you > give me the specifics as to what constitutes the "state information and resources" . > Sorry for bothering you with the gory details...but I guess it is better to be safe rather than sorry > Thanks for your help > warm regards, > Aditya > > >>Hi again Aditya, > >>Fair question. > >>It's your choice whether you re-use the same session control block, but you should throw out state and information related >>to the previous > incarnation of the session and only populate the new/re-used control block with information about the re- > > >>established session. > >>OK? > >>Regards, > >>Adrian > > -----Original Message----- > From: Philip Matthews [mailto:philipma@nortelnetworks.com] > Sent: Tuesday, March 20, 2001 9:23 AM > To: Aditya Chugh (Leela) > Subject: Re: If we recieve FT reconnect Flag = 0...can we use same > session ?? > > I saw this posted to the MPLS-OPS list run by the MPLS Resource Center.... > > If you have questions on our Fault Tolerance draft, it would be best to > send them directly to the authors. Some of us are a little behind in our > reading of various mailing lists ... > > And don't send them to MPLS-OPS list, which is for operational questions, > but to the MPLS WG list instead (mpls@uu.net). > > Anyway, nice to see someone else implementing the draft. > > - Philip > > PS. Did Adrian every reply to your question?? > > "Aditya Chugh (Leela)" wrote: > > > > Dear Adrian, > > I need to bother you again...!!!!!! > > > > If our FT-LDP implementation is to conform to your draft " draft-ietf-mpls-ldp-ft-00.txt "...then how should the following be handled ???? > > > > > Consider the case when the TCP connection (of an FT session) needs to be reestablished. > > Before the Reconnection Timer Expires > > if I recieve an Initialization message( with valid Session TLV).. > > ....but FT reconnect flag set to 0( which means that peer has not preserved state info for previous instantiations of this LDP session ) > > > > > I am supposed to release all the label state and resources associated with the previous instantiation of the LDP session. > > > > > this would mean that I release the Labels and the Control Blocks ( since Labels are stored in the Control Blocks). > > > > But do I need to tear down the session also ??...that is do I also need to > > release the Session Block ...or I can use the same session block to establish a "Brand New" FT session.?? > > > > Thanks in advance, > > Aditya From owner-mpls@UU.NET Wed Mar 28 01:05:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21110 for ; Wed, 28 Mar 2001 01:05:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkigm18748; Wed, 28 Mar 2001 06:02:52 GMT Received: by mail-control.mail.uu.net id QQkigm12367 for mpls-outgoing; Wed, 28 Mar 2001 06:02:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkigm11967 for ; Wed, 28 Mar 2001 06:02:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkigm09810 for ; Wed, 28 Mar 2001 06:01:41 GMT Received: from hclhprnd.hclt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkigm14860 for ; Wed, 28 Mar 2001 06:01:39 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id MAA02044; Wed, 28 Mar 2001 12:00:14 +0530 Received: from VIJAYC ([192.168.232.145]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2M20YTM; Wed, 28 Mar 2001 11:30:31 +0530 From: "Vijayanand Chandrasekar" To: Cc: , Subject: RE: LDP MIB Date: Wed, 28 Feb 2001 11:30:28 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <01C0B3D8.4002B140.mohanvak@future.futsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Is it always true that for per platform label space there is a one to many relationship between Entity and Session. If so, what is the significance of Entity Index.Why is given in LDP MIB that entity Index is optional for implementations. Thanks in advance, Regards, Vijay -----Original Message----- From: Mohan Varma K [mailto:mohanvak@future.futsoft.com] Sent: Friday, March 23, 2001 3:02 PM To: 'Vijayanand Chandrasekar' Subject: RE: LDP MIB Hi, The Entity and the session will be one -one in per interface(ATM/FR) scenario but not in per platform. The Entities configuration will never get changed and the negotiated information will be in the session table like the intersected label range(etc..). Mohan I have asked this question twice before but have'nt been able to get a reply.Can anyone please reply. IF there is a one to one correspondence between Entity and Session how will the entity be initialised. Should'nt each entity be configured initially with Label range, Label space, Targetted peer address etc, so that this info will be used for peer discovery and session establishment.The LdpId used in the PDU is that of the entity which should have been configured.If this is so then how can the number of sessions(hence entities) be known apriori, since this is as a result of peer discovery. Also, in the Entity Table the Enity Index is given as optional for implementations, what is the reason for this? Does it mean that we start of with an Enity configuration intially and for each new peer discovered and sesssion established the Entity Table is updated. Thanks in advance, Regards, Vijay From owner-mpls@UU.NET Wed Mar 28 03:35:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13002 for ; Wed, 28 Mar 2001 03:35:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkigw28921; Wed, 28 Mar 2001 08:34:08 GMT Received: by mail-control.mail.uu.net id QQkigw07862 for mpls-outgoing; Wed, 28 Mar 2001 08:33:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkigw07857 for ; Wed, 28 Mar 2001 08:33:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkigw23702 for ; Wed, 28 Mar 2001 08:33:18 GMT Received: from mailrelay1.alcatel.de by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75]) id QQkigw27959 for ; Wed, 28 Mar 2001 08:33:18 GMT Received: from ks.sel.alcatel.de (actually host slsv0d.stgl.sel.alcatel.de) by mailrelay1.alcatel.de with SMTP (XT-PP); Wed, 28 Mar 2001 10:31:32 +0200 Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.16) id 14iBMW-0000C7-00; Wed, 28 Mar 2001 10:31:28 +0200 Received: from sls7bw ([149.204.78.31] helo=sls7bw.stgl.sel.alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.16) id 14iBMW-00045X-00; Wed, 28 Mar 2001 10:31:28 +0200 Message-ID: <3AC1A160.2668ADE0@alcatel.de> Date: Wed, 28 Mar 2001 10:31:28 +0200 From: Patrick McGleenon Organization: Alcatel X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Xu Yingxiao CC: mpls Subject: Re: any advice is appreciated References: <002901c0b69a$f732e320$517f78ca@xyx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yingxiao, This is a valid thesis topic, and if you search the literature you can find existing research. A good place to start could be this paper from the COMET team at Columbia university: http://www.cs.columbia.edu/~hgs/papers/Zhao0002_Internet.pdf Also you might like to look at the PhD thesis from Xipeng Xiao 'Providing Quality of Service in the Internet': http://www.cse.msu.edu/~xiaoxipe/download.thesis.html Regards Patrick > Xu Yingxiao wrote: > > I am preparing my PHD. dissertation. I am doing research on MPLS QoS. > I am ready to do research on two items: 1. MPLS & TE, focusing on MPLS QoS Routing > alogrithm 2.MPLS & Diff-Serv. > Is these topic worthy to study and can it form a PHD. dissertation? > I am especially puzzled in MPLS & Diff-Serv as most studying is focus on architecture > and process scheme which is hard to have any notion for person who is not in > International studying group. From owner-mpls@UU.NET Wed Mar 28 06:19:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22394 for ; Wed, 28 Mar 2001 06:19:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkige28983; Wed, 28 Mar 2001 04:00:30 GMT Received: by mail-control.mail.uu.net id QQkigd22824 for mpls-outgoing; Wed, 28 Mar 2001 03:59:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkigd22815 for ; Wed, 28 Mar 2001 03:59:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkigd12530 for ; Wed, 28 Mar 2001 03:59:44 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkigd15724 for ; Wed, 28 Mar 2001 03:59:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA18376 for mpls@uu.net; Tue, 27 Mar 2001 22:59:43 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkigd22762 for ; Wed, 28 Mar 2001 03:59:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkigd07981 for ; Wed, 28 Mar 2001 03:58:29 GMT Received: from rumor.cps.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rumor.cps.intel.com [192.102.198.242]) id QQkigd13671 for ; Wed, 28 Mar 2001 03:58:28 GMT Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id DAA26130; Wed, 28 Mar 2001 03:56:40 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 28 Mar 2001 03:56:43 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Mar 2001 19:56:42 -0800 Message-ID: From: "Sharma, Prem" To: "'Don Fedyk'" , manoj juneja , mpls@UU.NET Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" Date: Tue, 27 Mar 2001 19:56:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B73B.18E4DFA0" 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_01C0B73B.18E4DFA0 Content-Type: text/plain; charset="iso-8859-1" Hi Don, But what about the cases when you have loose hops in the explicit routes and route pinning is not requested? Can there be a scenario where the arrival of a next hop change trigger (for a loosely routed hop), while the original LSP is being re-routed, may potentially lead to race condition? Thanks. Prem -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortelnetworks.com] Sent: Monday, March 26, 2001 6:12 AM To: manoj juneja; mpls@UU.NET Cc: gash@att.com; Peter Ashwood-Smith; Bilel Jamoussi; fedyk@nortelnetworks.com; skalecki@nortelnetworks.com; lili@ss8networks.com; ylee@irislabs.com Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" Manoj Usually the path modification is for TE LSP that are routed via an Explicit route. This means that they are not affected by next hop changes in IP routing. If the existing path is torn down due to a failure on the path then you have a couple of options. 1. Abort any modification and treat as a normal failure. 2. Handle the path release but wait for the new modification path in hope that it will still be valid. We have built 1. in the past. 2. is more difficult and a low percentage success rate. Don > -----Original Message----- > From: manoj juneja [ mailto:manojkumarjuneja@hotmail.com ] > Sent: Wednesday, March 21, 2001 6:06 PM > To: mpls@UU.NET > Cc: gash@att.com; Ashwood-Smith, Peter [CAR:CS0I:EXCH]; > Jamoussi, Bilel > [BL60:2868-M:EXCH]; fedyk@nortelnetworks.com; > skalecki@nortelnetworks.com; lili@ss8networks.com; ylee@irislabs.com > Subject: Valid Race Condition related to draft > "draft-ietf-mpls-crlsp-modify-03.txt" > > > Hi All, > > Please comment on the following : > > If the LSP modification is in progress and in the meantime the > next hop for the same LSP changes then should the modification > procedure be aborted ? > > Regards, > manoj. > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > ------_=_NextPart_001_01C0B73B.18E4DFA0 Content-Type: text/html; charset="iso-8859-1" RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp-modify-03.txt"
Hi Don,
 
But what about the cases when you have loose hops in the explicit routes and route pinning is not requested? Can there be a scenario where the arrival of a next hop change trigger (for a loosely routed hop), while the original LSP is being re-routed, may potentially lead to race condition?
 
Thanks.
Prem

 
 
 -----Original Message-----
From: Don Fedyk [mailto:dwfedyk@nortelnetworks.com]
Sent: Monday, March 26, 2001 6:12 AM
To: manoj juneja; mpls@UU.NET
Cc: gash@att.com; Peter Ashwood-Smith; Bilel Jamoussi; fedyk@nortelnetworks.com; skalecki@nortelnetworks.com; lili@ss8networks.com; ylee@irislabs.com
Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt"

Manoj


Usually the path modification is for TE LSP that are routed via an Explicit route. This means that they are not affected by next hop changes in IP routing. If the existing path is torn down due to a failure on the path then you have a couple of options.

1. Abort any modification and treat as a normal failure.
2. Handle the path release but wait for the new modification path in hope that it will still be valid.

We have built 1. in the past. 2. is more difficult and a low percentage success rate.

Don


> -----Original Message-----
> From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
> Sent: Wednesday, March 21, 2001 6:06 PM
> To: mpls@UU.NET
> Cc: gash@att.com; Ashwood-Smith, Peter [CAR:CS0I:EXCH];
> Jamoussi, Bilel
> [BL60:2868-M:EXCH]; fedyk@nortelnetworks.com;
> skalecki@nortelnetworks.com; lili@ss8networks.com; ylee@irislabs.com
> Subject: Valid Race Condition related to draft
> "draft-ietf-mpls-crlsp-modify-03.txt"
>
>
> Hi All,
>
>    Please comment on the following :
>
>         If the LSP modification is in progress and in the meantime the
> next hop for the same LSP changes then should the modification
> procedure be aborted ?
>
> Regards,
> manoj.
>
>
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>

------_=_NextPart_001_01C0B73B.18E4DFA0-- From owner-mpls@UU.NET Wed Mar 28 08:35:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27204 for ; Wed, 28 Mar 2001 08:35:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkihq22844; Wed, 28 Mar 2001 13:33:32 GMT Received: by mail-control.mail.uu.net id QQkihq19101 for mpls-outgoing; Wed, 28 Mar 2001 13:32:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkihq19093 for ; Wed, 28 Mar 2001 13:32:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkihq11062 for ; Wed, 28 Mar 2001 13:32:33 GMT Received: from prue.eim.surrey.ac.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQkihq05310 for ; Wed, 28 Mar 2001 13:32:33 GMT Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14iG3Y-0004Ud-00; Wed, 28 Mar 2001 14:32:12 +0100 Date: Wed, 28 Mar 2001 14:32:09 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Vincent Jardin cc: padua , mpls@UU.NET Subject: Re: MPLS over DWDM In-Reply-To: <0103262358130A.11206@mercure.rezel.enst.fr> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *14iG3Y-0004Ud-00*CTkuDWhY3Vk* Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 26 Mar 2001, Vincent Jardin wrote: > You should start getting informations about GMPLS (previously MP(lambda)S) entirely separate things. L. PGP From owner-mpls@UU.NET Wed Mar 28 11:16:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03421 for ; Wed, 28 Mar 2001 11:16:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiht21868; Wed, 28 Mar 2001 14:20:14 GMT Received: by mail-control.mail.uu.net id QQkiht09294 for mpls-outgoing; Wed, 28 Mar 2001 14:19:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiht09289 for ; Wed, 28 Mar 2001 14:19:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiht09293 for ; Wed, 28 Mar 2001 14:19:12 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkiht02390 for ; Wed, 28 Mar 2001 14:19:12 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA16713 for ; Wed, 28 Mar 2001 06:19:15 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA00436 for mpls@uu.net; Wed, 28 Mar 2001 09:19:06 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkieu16064 for ; Tue, 27 Mar 2001 19:06:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkieu10722 for ; Tue, 27 Mar 2001 19:05:20 GMT Received: from interceptor.mahinetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: 216-174-224-194.atgi.net [216.174.224.194]) id QQkieu11325 for ; Tue, 27 Mar 2001 19:05:19 GMT Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Tue, 27 Mar 2001 11:09:57 -0800 (Pacific Standard Time) Received: by main.mahinetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Mar 2001 11:06:39 -0800 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C9921344@main.mahinetworks.com> From: Jayaram Beladakere To: "'mpls@uu.net'" Subject: Preconfigured EXP<-->PHB mapping for E-LSPs Date: Tue, 27 Mar 2001 11:06:29 -0800 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 following is from "MPLS Support of Differentiated Services" (draft-ietf-mpls-diff-ext-08.txt). 3.2.1 Preconfigured EXP<-->PHB mapping .... In case, the preconfigured EXP<-->PHB mapping has not actually been configured by the Network Administrator, the LSR should use a default preconfigured EXP<-->PHB mapping which maps all EXP values to the Default PHB. In the above case, the LSR provides Default PHB treatment to all labeled packets (belonging to LSPs with preconfigured EXP<-->PHB mapping). What shall be the value of the outgoing EXP field for such labeled packets, both with label-swap and label-push operations at the LSR? In particular, shall the outgoing EXP match incoming EXP, or shall it be '000'? Is there a difference if the label operation is swap rather than push? Regards, Jayaram Beladakere Mahi Networks, Inc. From owner-mpls@UU.NET Wed Mar 28 11:27:52 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04022 for ; Wed, 28 Mar 2001 11:27:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiib28222; Wed, 28 Mar 2001 16:25:01 GMT Received: by mail-control.mail.uu.net id QQkiib24111 for mpls-outgoing; Wed, 28 Mar 2001 16:24:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiib24090 for ; Wed, 28 Mar 2001 16:24:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiib20611 for ; Wed, 28 Mar 2001 16:23:39 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkiib08669 for ; Wed, 28 Mar 2001 16:23:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA25984 for mpls@uu.net; Wed, 28 Mar 2001 11:23:38 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiib24042 for ; Wed, 28 Mar 2001 16:22:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiib14456 for ; Wed, 28 Mar 2001 16:20:57 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkiib22041 for ; Wed, 28 Mar 2001 16:20:56 GMT Received: (qmail 15668 invoked by uid 104); 28 Mar 2001 16:20:55 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.88424 secs); 28/03/2001 08:20:55 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 28 Mar 2001 16:20:54 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f2SGKsV24272; Wed, 28 Mar 2001 08:20:54 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Mar 2001 08:21:23 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B64@BBY1EXM01> From: Shahram Davari To: "'Jayaram Beladakere'" , "'mpls@uu.net'" Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs Date: Wed, 28 Mar 2001 08:21:23 -0800 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 Jayaram, The intention of configured E-LSPs is to have the MPLS+Diffserv network behave the same as a Diffserv-only network. Since RFC-2474 section 3 says: " Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and their codepoints should not be changed. Such packets MUST NOT cause the network node to malfunction. " So the answer to you question is that the EXP should be left unchanged in the normal swap operation. It is however, possible to push another label and have either non-configured, configured or even signaled E-LSP for the new LSP (which we call tunnel-LSP). In that case depending on the type of the tunnel (Uniform or pipe), the top label could have its EXP set to the same EXP, or to the Default EXP or something else. In case the tunnel-LSP is a uniform tunnel that is a non-configured (and non-signaled) E-LSP, then the same behavior as explained in the above quote from RFC-2474 is the correct behavior (i.e., setting the EXP of the pushed label to the same EXP as the incoming label). Yours, -Shahram > -----Original Message----- > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > Sent: Tuesday, March 27, 2001 2:06 PM > To: 'mpls@uu.net' > Subject: Preconfigured EXP<-->PHB mapping for E-LSPs > > > The following is from "MPLS Support of Differentiated Services" > (draft-ietf-mpls-diff-ext-08.txt). > > 3.2.1 Preconfigured EXP<-->PHB mapping > .... > In case, the preconfigured EXP<-->PHB mapping has not actually been > configured by the Network Administrator, the LSR should use a > default preconfigured EXP<-->PHB mapping which maps all EXP values > to the Default PHB. > > In the above case, the LSR provides Default PHB treatment to > all labeled > packets (belonging to LSPs with preconfigured EXP<-->PHB > mapping). What > shall be the value of the outgoing EXP field for such labeled > packets, both > with label-swap and label-push operations at the LSR? In > particular, shall > the outgoing EXP match incoming EXP, or shall it be '000'? Is there a > difference if the label operation is swap rather than push? > > Regards, > Jayaram Beladakere > Mahi Networks, Inc. > From owner-mpls@UU.NET Wed Mar 28 18:10:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14604 for ; Wed, 28 Mar 2001 18:10:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkijc23266; Wed, 28 Mar 2001 23:06:14 GMT Received: by mail-control.mail.uu.net id QQkijc24081 for mpls-outgoing; Wed, 28 Mar 2001 23:05:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkijc24031 for ; Wed, 28 Mar 2001 23:05:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkijb09529 for ; Wed, 28 Mar 2001 22:59:05 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkijb13125 for ; Wed, 28 Mar 2001 22:59:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA27111 for mpls@uu.net; Wed, 28 Mar 2001 17:59:04 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkijb07939 for ; Wed, 28 Mar 2001 22:58:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkijb03892 for ; Wed, 28 Mar 2001 22:56:48 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkijb11558 for ; Wed, 28 Mar 2001 22:56:47 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA14952 for ; Wed, 28 Mar 2001 17:56:46 -0500 (EST) Message-Id: <200103282256.RAA14952@pilgrim.cisco.com> To: mpls@UU.NET Subject: Draft MPLS minutes Date: Wed, 28 Mar 2001 17:56:46 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk MPLS WG Meeting Thursday, March 22, 2001 ======================================== I. George provided document status on existing documents which are in or near last call. 1. Carrying Label Information in BGP-4 (awaiting publication) On RFC editor's queue 2. RSVP-TE (awaiting publication) Applicability Statement for Extensions to RSVP for LSP-Tunnels RSVP-TE: Extensions to RSVP for LSP Tunnels Note: the latter draft needs some final edits. This will be handled as part of the RFC editors last authors comments. 3. LDP "boxed set" (awaiting publication) LDP State Machine Applicability Statement for CR-LDP Constraint-Based LSP Setup using LDP LSP Modification Using CR-LDP These are awaiting a Table of Contents for LDP State machine. As of this writing, Eric Gray has supplied an updated draft. 4. MIBs (in IESG last call) Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) MPLS Label Switch Router Management Information Base Using SMIv2 Authors are in the process addressing comments from the IESG. Another round of last calls is probably not required. 5. Framework for IP Multicast in MPLS Will be sent to IESG for last call. 6. MPLS Support of Differentiated Services Francois needs to turn a new draft incorporating updates from the recent WG last call after which it will go for IESG last call. 7. Generalized MPLS Signaling drafts These drafts are nearly complete. They will be updated based on the results of CCAMP. Once updated they will be sent for joint CCAMP and MPLS WG last call. Consensus to do the MPLS WG last call was reached in this meeting. 8. Unnumbered, Bundle, Hierarchy drafts After the "sub IP" re-org, these drafts remain in MPLS. Proposal: Accept draft-kompella-mpls-undle-05.txt as working group draft. Update the draft as draft-mpls-bundle-00.txt. Some of the other drafts will also be updated. Once updated a WG last call will be issued. None opposed; consensus. II. MPLS Recovery Framework Fifi Hellstrand This document provides a high-level overview of protection mechanisms which could be employed by MPLS. The document was also presented to the TE wg. Many comments received on this document. Minor changes were required (editorial). Fifi requested that the document be sent to WG last call and move it to an informational RFC. No questions from crowd. Within the sub IP area, the TEWG has the charter to come up with an overall recovery framework. George therefore asked the ADs if a WG last call for this document could be done at this time. Scott: Wants to take a sense of the room, and then get comments from the mailing list for last call, but still wants the TE design team to make sure that they don't want to add to it. Don't want to wait for more than a month. George: Any objections on moving to last call within a month? None were voiced. The document will be sent to the TE WG mailing list for comments to facilitate the process outlined by Scott. III. RSVP Label Allocation for Backup Tunnels George Swallow Objective is to do FRR in MPLS to allow for temporary routing around a failed link or node while the head-end is reoptimizing the lsp. The technique uses a bypass tunnel to the node two hops down the path. All tunnels between the current node and that node may share the same bypass tunnel. Rerouting is done locally and thus can be done in < 50ms. In order to use this, a label needs be obtained for the hop across the bypass tunnel. Two mehanism are described in the draft. A separate RSVP Path message can be generated. This applies in all cases. If the tail of the bypass tunnel is a frame-based switch using the global label space, then labels can simply be recorded in the RRO. The draft has been available for the past 1.5 years. It is purely informational; doesn't propose anything new. Would like to publish as a WG informational draft. Scott (as chair): Is there support in the room for this. No objections. A WG last call will be issued after which it will be forwarded to Scott and Bert for IESG review. IV. LDP Fault Tollerance Philip Matthews Summarized draft. Discussed changes between last version and current version. Expect to ask for wg last call soon. Requested comments now or via mailing list. George: Consensus to put this draft to a wg last call. Luca Martini opposes wg last call; no other objections. Luca: Since ldp is not a controlling protocol, why bother making it fault tolerant? Matthews: Enhance software upgrades and you don't want to disrupt the LSPs that are running over the network. Luca: But other protocols need to be made redundant too. Matt: OSPF etc. are being made fault tolerant. We stole this proposal from IDR. A long discussion enused on the relationship of LDP recovery to recovery of information from other protocols. There is work in progress on this in OSPF and IDR. In fact the LDP recovery is based on BGP recovery. Details of this discussion can be found in the raw minutes sent by Tom Nadeau. The result of all the discussion was that the issue of the relationship of LDP recovery to other stateful recovery will be handled in the last call. Scott commented that the applicability section of the document should be enhanced to reflect this. George: We will do a last call, raise these issues and try to close them. If closed, then document is finished. V. An Expanded ERO for RSVP-TE Vishal Sharma Given the recent changes in the unnumber draft, the mechanism proposed in this draft is no longer necessary. The authors therefore propose to turn this draft into an informational document on how to form EROs and move it forward that way. VI. TTL Processing in MPLS networks Puneet Agarwal Draft covers different ways of processing TTL. Overview. Would like to update according to comments from list and move forward to last call. Matt: Document is useful and technical content is good. Figures would be useful. Document is difficult to read. Pipe/Hose model are mixed in document. Put them in a their own places in the document? Q1: I don't see how TTLs are specified in NTAPs draft. A: Some models are not described in that document. Q1: There might be some difficulty with your approach. Rosen: There is already a document that specifies how TTL processing works. Lets just put pipe model in here only, otherwise we duplicate things explained in RFC 3032. I think that we need to organize the discussion around the point of the organization of this document (what is not covered and what is). E: You don=92t need a separate procedure for nested procedure; already covered in 3032. Discussion did not complete on mailing list. There is a lot that needs to be clarified. A: What are you proposing? E: I think that you are proposing changes and additions (specified and unspecified). Need to specified which is which. Need to reach consensus on whether or not they are necessary. Do we need a document that obsoletes pieces of rfc3033. George: this is an information proposal. We cannot contradict something that is in a standard. Lets continue this discussion on the mailing list. Egray: I was going to say what george just said. Define something in a standard specification and explain something in an informational. George: Cannot contradict what was in the rfc. Take it to the list. VII. TTL Processing expansion for 1-hop LSP Satoru Matsushima Overview. Next steps: merge with Puneet's ttl draft. Would like to become a wg draft. Need signaling extensions for 1-hop lsp. George: Discussion? Eric Rosen: There are two schools of thought on TTL processing. Don't think there is a need to specify TTL on a per-lsp basis. I don't think that there is a problem that we need to solve here. Luca: I agree with Eric's comments. I don't see the use of specifying the behavior on a per-lsp basis. George: Continue discussion on mailing list. VIII. LDP End-to-end Authorization Olivier Paridaens Overview. Presented requirements. What we are asking is that this be adopted as a wg draft. This work is part of the charter, so it should be accepted. Scott: What operators have expressed interest in this technology and have the security geeks looked at this? A general discussion ensued on what was required and what had been discussed in San Diego. Several carriers and vendors spoke up saying that the proposal on the table was expensive and over-kill. This was counter with a statement that the method was not all that expensive and that the feature is optional. It was also claimed that carriers voiced support in San Diego. Another speaker pointed out that optional pertained to use and that vendors most likely would be required to implement. Before committing to such a course they would like to see the requirements document for this sort of work. George: We need to figure out what providers want first. We don't have any consensus at this point. Lets get some carriers to give us some contributions for what they would like to see in this space. Continue discussion on this mailing list. IX. Update on LDP Path MTU Ben Black Overview. Simple extension to ldp to allow automatic signaling of mtu detection. Allows proper fragmentation of packets within the MPLS domain. Support RFC1191 too. Version 00 has been out for some time. Lots of comments received. Asked that this be accepted as a wg document. George: discussion Curtis: What happens if along the way, one hop is inside a hierarchtical tunnel or if bypass tunnels are used. In both cases, the router negotiating a hop is not aware that somewhere in the middle that a bypass exists. Black: If hierarchtical, the outermost tunnel=92s mtu is used. There is an lsr somewhere that can see the bypass which can unsolicited signal the mtu change. It will pick the lesser of the two=92s path. George: Anything that causes an impulse into signaling during a failure is bad. Eric Rosen pointed out that in practice, firewalls often thwart Path MTU discovery by dropping ICMP messages. Ben Black said that simply because it wouldn't work in some cases, was no reason not to work on solving the problem where it would work. Curtis: There are places where this is necessary: no NATs and high performance IP. Matt: I haven't seen demands from the carriers for this functionality, eventhough I like it. Scott: Process point: is this in the charter? George: Gray area. We should work to get MPLS to work. Scott: WG can change charter if necessary. Charter is description of what we should be doing within a certain time period. Q1: Carriers are interested in this. Black: RSVP has this functionality. Discussion will be continued on the list. George: We now have three presentations that are not in the gray area. They are outside of the current charter. We are going into "BOF" mode to see if there is interest to expand the charter. X. Secure MPLS Tissa Senevirath Overview. Applications: Most metro applications use MPLS. Q1: In your first slide, you stated that most MPLS Metro carriers use MPLS. Which country are you talking about? Sen: US. Q1: Do you know which vendors are supporting MPLS in the metro area. Q2: Most operators use f/r links. The law prohibits them from monitoring authentications. Can authentications be monitored on MPLS. Even if we have mpls security on a backbone. MPLS is an end-to-end problem. This does not seem to be useful unless it is end to end. Bilel J: Where are you getting the requirements for this draft. Sen: These requirements are coming from the optical development going on in the world. George: Take the discussion to the mailing list. XI. Multicast Traffic Engineering Dirk Ooms Overview. Questions. George: This work was started a long time ago. There was no interest in this at that time. What has changed? Dirk: Now there is SSMulticast. George: Perhaps you should change the name of your document to "support for SSM". Dirk: this is an alternative to SSM. Rosen: As far as SSM, there are other solutions to the problem of knowing the source of a packet. Dirk: There are other solutions, but they are undocumented as of yet. Q1: I wasn't clear why SSM makes this more interesting. Also it isn't clear how you distribute the labels using TE. Where is the definition of TE is not clearly defined in the draft. Dirk: Traffic engineering allows you to construct a tree, which deviates from the one created in unicast. George: Given the time, lets continue discussion on the mailing list. XII. MPLS OAM Shahram Davari Davari MPLS OAM draft-harrison-mpls-oam-00.txt Overview. Status of this document: ITU SG13-Q3. Requirements are defined. Availability is defined. OAM Packets are defined. Connectivity verification is worked out. Future work: LSP performance work. Summary: OAM is necessary for user-plane, independent of control-plane. This draft introduces OAM requirements and simple OAM functions. Determining connectivity/availability. What we have done is taken this from ATM and reduced most of what was there, and kept the best %1. MPLS OAM was previously defined in MPLS charter. If interested, it should be added to charter and document accepted as a work item. Q: I think this work is very useful. It will increase the performance of the MPLS network. Recovery framework is applicable. Performance benchmarking applies. This is useful for fault-tollerance. Curtis: How does this relate to the Bonica draft on tunnel trace? We should go to the TE Wg and see what there are requirements are for this. Rosen: I think that some of the stuff in the beginning is important. I think this document is not a good piece of work. There are many terms that are not defined in the IETF. It has a very ATM-flavor. It does not handle a lot of stuff like multi-point-to-point. Even if we were to add measurement to charter, lets not accept this document to the charter. Davari: This is optional. Carriers want this. Q2: I don't think that this is useful. I think that it is not useful in an LSR. I can see this to be useful if GSMP is being used. Useful in detecting configuration errors, otherwise lets assume that the LSR works okay. Q3: I second that. I don't buy the argument that software is broken, so we need to add more software. Scott: My problem with the document is that it mixes light requirements with lots of suggestions. It would be useful to have a clear requirements document that specifies what it is that you are trying to accomplish with this approach. The requirements document should be taken to the TE WG. Davari: is it in the charter of te? Scott: Thinking is in the charter of te. Management of this kind is not in the charter. However, if requirements can come forward and hint at which tools they could have would be a good thing. George: End of the agenda. See you in London. From owner-mpls@UU.NET Wed Mar 28 18:15:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14675 for ; Wed, 28 Mar 2001 18:15:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkijc02923; Wed, 28 Mar 2001 23:13:24 GMT Received: by mail-control.mail.uu.net id QQkijc25313 for mpls-outgoing; Wed, 28 Mar 2001 23:12:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkijc25276 for ; Wed, 28 Mar 2001 23:12:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkijc04828 for ; Wed, 28 Mar 2001 23:05:45 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkijc27615 for ; Wed, 28 Mar 2001 23:05:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA27527 for mpls@uu.net; Wed, 28 Mar 2001 18:05:44 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkijc21565 for ; Wed, 28 Mar 2001 23:05:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkijc28507 for ; Wed, 28 Mar 2001 23:00:05 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkijc13630 for ; Wed, 28 Mar 2001 23:00:04 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA15343 for ; Wed, 28 Mar 2001 18:00:04 -0500 (EST) Message-Id: <200103282300.SAA15343@pilgrim.cisco.com> To: mpls@UU.NET Subject: Last Call on LDP Fault Tollerance Date: Wed, 28 Mar 2001 18:00:03 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message commences a workgroup last call on LDP Fault Tollerance, . The last call closes April 11, 12 pm GMT. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Mar 28 18:28:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14847 for ; Wed, 28 Mar 2001 18:28:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkijd14155; Wed, 28 Mar 2001 23:26:14 GMT Received: by mail-control.mail.uu.net id QQkijd26686 for mpls-outgoing; Wed, 28 Mar 2001 23:25:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkijd26674 for ; Wed, 28 Mar 2001 23:25:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkijc09507 for ; Wed, 28 Mar 2001 23:11:15 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkijc18060 for ; Wed, 28 Mar 2001 23:11:14 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA27962 for mpls@uu.net; Wed, 28 Mar 2001 18:11:14 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkijc24435 for ; Wed, 28 Mar 2001 23:06:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkijc20590 for ; Wed, 28 Mar 2001 23:03:32 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkijc14958 for ; Wed, 28 Mar 2001 23:03:31 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA15707 for ; Wed, 28 Mar 2001 18:03:30 -0500 (EST) Message-Id: <200103282303.SAA15707@pilgrim.cisco.com> To: mpls@UU.NET Subject: Last Call on RSVP Label Allocation for Backup Tunnels Date: Wed, 28 Mar 2001 18:03:30 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message commences a workgroup last call on "RSVP Label Allocation for Backup Tunnels" . This draft is informational. The last call closes April 11, 12 PM GMT. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Mar 28 19:24:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15499 for ; Wed, 28 Mar 2001 19:24:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkijh09796; Thu, 29 Mar 2001 00:21:44 GMT Received: by mail-control.mail.uu.net id QQkijh18672 for mpls-outgoing; Thu, 29 Mar 2001 00:21:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkijh18631 for ; Thu, 29 Mar 2001 00:20:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkijh28173 for ; Thu, 29 Mar 2001 00:20:33 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkijh08443 for ; Thu, 29 Mar 2001 00:20:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA02701 for mpls@uu.net; Wed, 28 Mar 2001 19:20:31 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkijh18582 for ; Thu, 29 Mar 2001 00:20:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkijg01904; Thu, 29 Mar 2001 00:14:53 GMT Received: from netmail2.alcatel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkijg03395; Thu, 29 Mar 2001 00:14:52 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id SAA03608; Wed, 28 Mar 2001 18:14:51 -0600 (CST) Received: from adn.alcatel.com ([198.205.41.68]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA398C; Wed, 28 Mar 2001 19:27:36 -0500 Message-ID: <3AC27EDB.A886E8B2@adn.alcatel.com> Date: Wed, 28 Mar 2001 19:16:27 -0500 From: "Rao Vadlamani" Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: mpls@UU.NET, te-wg@UU.NET, "Thomas D. Nadeau" , cheenu Srinivasan , Arun Viswanathan Subject: Re: Two TE MIBs References: <2413FED0DFE6D111B3F90008C7FA61FB0BC0B6A4@nl0006exch002u.nl.lucent.com> Content-Type: multipart/mixed; boundary="------------01100351289B64D57D7E3769" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------01100351289B64D57D7E3769 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bert, Pl. see my comments inlined. Thanks Rao "Wijnen, Bert (Bert)" wrote: > Inline > > > ---------- > > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > > Sent: Sunday, March 25, 2001 3:07 PM > > To: Rao Vadlamani; mpls@UU.NET; te-wg@UU.NET > > Cc: cheenu Srinivasan; Arun Viswanathan > > Subject: Re: Two TE MIBs > > > > > > Hi, > > > > >Could someone clarify as to why there are 2 draft TE MIB's > > >draft-ietf-mpls-te-mib-06.txt of Thomas D. Nadeu etal and > > >draft-ietf-tewg-mib-00.txt of Kireeti ? If I understand, both are going > > >for a IESG approval, too. If my understanding is correct both the MIBs > > >are giving more or less the same information. except in the second MIB > > >of kireeti, all the objects are only read-only and operator can't > My understanding is that Kireeti was going to change MAX-ACCESS to > read-create or read-write That's indeed good. > > > >exercise control over them ? What's the motivation behind this ? > > >Thanks in advance for the clarification and I am sorry to pose this > > >question if this is already raised and discussed. > > > > Beats me why there are two, but I am not going to beat > > a dead horse and argue about it any longer though. This was discussed > > at length late last summer, and I suggest you go back and re-read > > the archive so that you can come to your own informed conclusion. > > The outcome of the discussion at that time was that IESG agreed to > > have two. > > > But we prefer to have no (or as few as possible) overlaps. > Maybe we need to check how this can be achieved. > > My understanding at the time of a quick briefing was that they do different > things. Specifically the MIB(s) developed in MPLS WG have lots of stuff > to be able to "debug" MPLS. Also... the message I got was that the MIB > from MPLS WG was to be run at each node, while the TE-WG MIB > does not need to run at each node. A single MIB can still do both the above said functionality, I guess. > > > I will look into these MIBs in more detail over the next weeks. I look forward to your comments. > > > Bert > > > --Tom > > > > > > --------------01100351289B64D57D7E3769 Content-Type: text/x-vcard; charset=us-ascii; name="Rao.Vadlamani.vcf" Content-Description: Card for Rao Vadlamani Content-Disposition: attachment; filename="Rao.Vadlamani.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vadlamani;Rao tel;cell:(703)-282-7399 tel;fax:(703)-679-6450 tel;home:(703)-390-1174 tel;work:(703)-679-6430 x-mozilla-html:FALSE url:www.alcatel.com org:Alcatel USA version:2.1 email;internet:rao.vadlamani@adn.alcatel.com adr;quoted-printable:;;15036 Conference Center Drive=0D=0A=0D=0A=0D=0A;Chantilly;VA;20151;USA fn:Rao Vadlamani end:vcard --------------01100351289B64D57D7E3769-- From owner-mpls@UU.NET Thu Mar 29 03:50:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26601 for ; Thu, 29 Mar 2001 03:50:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkikp29503; Thu, 29 Mar 2001 08:49:34 GMT Received: by mail-control.mail.uu.net id QQkikp17003 for mpls-outgoing; Thu, 29 Mar 2001 08:49:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkikp16989 for ; Thu, 29 Mar 2001 08:48:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkikp22645 for ; Thu, 29 Mar 2001 08:47:46 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQkikp16123 for ; Thu, 29 Mar 2001 08:47:45 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Thu, 29 Mar 2001 09:45:19 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 29 Mar 2001 09:45:24 +0100 Message-ID: To: swallow@cisco.com, mpls@UU.NET Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Thu, 29 Mar 2001 09:45:07 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Some comments: 1 Where did the requirements in section 1 come (and is there a reference?): "In order to meet the needs of realtime applications such as Voice over IP, it is highly desirable to be able to repair LSP tunnels in 10s of milliseconds. "? I would suggest voice would be one application where 1-2s of outage was tolerable, cf someone not answering a question immediately, but instead thinking for a short period of time before answering. In general I do not believe customers would close down a voice call for an outage of the order of 10ms, but they might on the order >3s. 2 At the top of page 5 in section 2 it says: " When a failure occurs and the backup comes into use,......" All user-plane (and indeed control-plane) failure modes must be identified and specified in terms of entry/exit criteria and consequent actions before we can meaningfully proceed with this draft. For the user-plane, the failure modes which must be considered/defined are: - simple below MPLS fabric server layer connectivity breaks; - simple within MPLS fabric connectivity breaks (at or below the LSP level considered); - swapped LSPs, ie instead of A1->A2 and B1->B2 a defect creates A1->B2 and B1->A2; - mismerged LSPs, eg instead of A1->A2 and B1->B2 a defect creates A1->A2 and A1+B1->B2 say (though there are potentially several variations on this). For the latter 2 defects it will be vital to suppress the traffic due to potential security/censorship/misbilling implications for carriers and customers. Speaking as a carrier these issues are requirements that must be addressed. This is not optional, and rigorous definitions must be provided (or referenced). Neil Harrison BT/Ignite/CTO/Network Architecture Tel +44 1 604 820 724 mail neil.2.harrison@bt.com > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: 29 March 2001 00:04 > To: mpls@UU.NET > Subject: Last Call on RSVP Label Allocation for Backup Tunnels > > > This message commences a workgroup last call on "RSVP Label Allocation > for Backup Tunnels" . This > draft is informational. The last call closes April 11, 12 PM GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > From owner-mpls@UU.NET Thu Mar 29 09:42:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15922 for ; Thu, 29 Mar 2001 09:42:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkilm05179; Thu, 29 Mar 2001 14:39:01 GMT Received: by mail-control.mail.uu.net id QQkilm19398 for mpls-outgoing; Thu, 29 Mar 2001 14:38:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkilm19389 for ; Thu, 29 Mar 2001 14:38:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkilm17383 for ; Thu, 29 Mar 2001 14:32:04 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkilm08848 for ; Thu, 29 Mar 2001 14:32:03 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 GAA24150 for ; Thu, 29 Mar 2001 06:32:03 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA04325 for mpls@uu.net; Thu, 29 Mar 2001 09:32:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkikm12998 for ; Thu, 29 Mar 2001 08:09:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkikm07699 for ; Thu, 29 Mar 2001 08:07:41 GMT Received: from mailgw.local.ipunplugged.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.88.134.217]) id QQkikm05879 for ; Thu, 29 Mar 2001 08:07:40 GMT Received: from HANSPC ([192.168.4.247]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA04204; Thu, 29 Mar 2001 10:07:06 +0200 From: =?iso-8859-1?Q?Hans_Sj=F6strand?= To: "Vijayanand Chandrasekar" , Cc: Subject: RE: LDP MIB Date: Thu, 29 Mar 2001 10:06:43 +0200 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.2911.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijay, I don't understand where you've read that the entity Index is optional. An index can never be optional, it has to have a legel value (in this case 1..4294967295) and should be obtained from the 'mplsLdpEntityIndexNext' object as written in the mib. Joan earlier replied to Anil on the subject some week agoe. > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Cucchiara, Joan > Sent: den 12 mars 2001 18:52 > To: 'anilg@acc.am.ericsson.se'; mpls@UU.NET > Subject: RE: mplsLdpEntityIndex > > > -----Original Message----- > > From: Anil Gunturu [mailto:anilg@acc.com] > > Sent: Monday, March 12, 2001 5:05 AM > > To: mpls@UU.NET > > Subject: mplsLdpEntityIndex > > > > Hi Anil, > > > > > I know that this issue has a been addressed before. But, I am > > still unclear > > on the concept of mplsLdpEntityIndex. > > This is a secondary index which is needed for ppp. > It may not be needed for your specific implementation,but would have to > be supported (e.g. it would have to have a valid value as specified > in the MIB). > Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Vijayanand Chandrasekar > Sent: den 28 februari 2001 07:00 > To: mohanvak@future.futsoft.com > Cc: mpls@UU.NET; manis@future.futsoft.com > Subject: RE: LDP MIB > > > Hello, > > Is it always true that for per platform label space there is a one to many > relationship between Entity and Session. If so, what is the > significance of > Entity Index.Why is given in LDP MIB that entity Index is optional for > implementations. > > Thanks in advance, > Regards, > Vijay > > -----Original Message----- > From: Mohan Varma K [mailto:mohanvak@future.futsoft.com] > Sent: Friday, March 23, 2001 3:02 PM > To: 'Vijayanand Chandrasekar' > Subject: RE: LDP MIB > > > Hi, > The Entity and the session will be one -one in per interface(ATM/FR) > scenario > but not in per platform. > The Entities configuration will never get changed and the > negotiated > information will be in the session table like the intersected label > range(etc..). > Mohan > > I have asked this question twice before but have'nt been able to get a > reply.Can anyone please reply. > > IF there is a one to one correspondence between Entity and > Session how will > the entity be initialised. Should'nt each entity be configured initially > with Label range, Label space, Targetted peer address etc, so > that this info > will be used for peer discovery and session establishment.The > LdpId used in > the PDU is that of the entity which should have been configured.If this is > so then how can the number of sessions(hence entities) be known apriori, > since this is as a result of peer discovery. > Also, in the Entity Table the Enity Index is given as optional for > implementations, what is the reason for this? > > > Does it mean that we start of with an Enity configuration intially and for > each new peer discovered and sesssion established the Entity Table is > updated. > > > Thanks in advance, > Regards, > Vijay From owner-mpls@UU.NET Thu Mar 29 10:22:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17958 for ; Thu, 29 Mar 2001 10:22:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkilp10398; Thu, 29 Mar 2001 15:19:37 GMT Received: by mail-control.mail.uu.net id QQkilp09247 for mpls-outgoing; Thu, 29 Mar 2001 15:19:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkilp09236 for ; Thu, 29 Mar 2001 15:18:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkilp13850 for ; Thu, 29 Mar 2001 15:17:32 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkilp07922 for ; Thu, 29 Mar 2001 15:17:32 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id DA7E194009; Thu, 29 Mar 2001 10:17:27 -0500 (EST) Message-ID: <3AC35207.64F8967C@sandburst.com> Date: Thu, 29 Mar 2001 10:17:27 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow Cc: mpls@UU.NET Subject: Re: Last Call on LDP Fault Tollerance References: <200103282300.SAA15343@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George, A couple of last call comments. 1) Author information needs updating. 2) There needs to be a clarifying statement made to the effect that the specification does not prevent an implementer from attempting to recover from an unexpected loss of connection, not does it require an implementer to do so. The statement should put the onus of verifying the correctness of the recovery mechanism on its implementer and should point out that the specification does provide for detection of inconsistency after session recovery. -- Eric Gray You wrote: > This message commences a workgroup last call on LDP Fault Tollerance, > . The last call closes April 11, 12 pm > GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Mar 29 15:37:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09431 for ; Thu, 29 Mar 2001 15:37:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkimk15362; Thu, 29 Mar 2001 20:34:23 GMT Received: by mail-control.mail.uu.net id QQkimk29390 for mpls-outgoing; Thu, 29 Mar 2001 20:33:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkimk29377 for ; Thu, 29 Mar 2001 20:33:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkimk23824 for ; Thu, 29 Mar 2001 20:33:18 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkimk13166 for ; Thu, 29 Mar 2001 20:33:17 GMT Received: from goneto.net (dhcp64-134-18-62.sssj.sjc.wayport.net [64.134.18.62]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 1621715F80A; Thu, 29 Mar 2001 21:33:11 +0100 (BST) Message-ID: <3AC3A8C0.F8433A12@goneto.net> Date: Thu, 29 Mar 2001 22:27:28 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com Cc: swallow@cisco.com, mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com wrote: > > Some comments: > > 1 Where did the requirements in section 1 come (and is there a > reference?): > "In order to meet the needs of realtime applications such as Voice > over IP, it is highly desirable to be able to repair LSP tunnels in > 10s of milliseconds. "? > > I would suggest voice would be one application where 1-2s of outage was > tolerable, cf someone not answering a question immediately, but instead > thinking for a short period of time before answering. In general I do not > believe customers would close down a voice call for an outage of the order > of 10ms, but they might on the order >3s. Definitely. I've never quite understood where the whole 10s of milliseconds thing came from. Sure, SONET/SDH can do this - but how many applications need it? We had a voice network long before SONET was invented... > 2 At the top of page 5 in section 2 it says: > " When a failure occurs and the backup comes into use,......" > > All user-plane (and indeed control-plane) failure modes must be identified > and specified in terms of entry/exit criteria and consequent actions before > we can meaningfully proceed with this draft. > > For the user-plane, the failure modes which must be considered/defined are: > - simple below MPLS fabric server layer connectivity breaks; > - simple within MPLS fabric connectivity breaks (at or below the LSP > level considered); Both of these will be detected by the RSVP signalling, won't they? > - swapped LSPs, ie instead of A1->A2 and B1->B2 a defect creates > A1->B2 and B1->A2; > - mismerged LSPs, eg instead of A1->A2 and B1->B2 a defect creates > A1->A2 and A1+B1->B2 say (though there are potentially several variations on > this). Both of these would only occur (as far as I can tell) if the router software is buggy. As I have stated before I don't really see the benefit of adding code to fix buggy code. > For the latter 2 defects it will be vital to suppress the traffic due to > potential security/censorship/misbilling implications for carriers and > customers. Speaking as a carrier these issues are requirements that must be > addressed. This is not optional, and rigorous definitions must be provided > (or referenced). Speaking as another carrier I *don't* see these as requirements that must be addressed. If software is buggy things go wrong. So let's fix the software rather than adding another layer to "manage" the bugs. Giles > > Neil Harrison > BT/Ignite/CTO/Network Architecture > Tel +44 1 604 820 724 > mail neil.2.harrison@bt.com > > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: 29 March 2001 00:04 > > To: mpls@UU.NET > > Subject: Last Call on RSVP Label Allocation for Backup Tunnels > > > > > > This message commences a workgroup last call on "RSVP Label Allocation > > for Backup Tunnels" . This > > draft is informational. The last call closes April 11, 12 PM GMT. > > > > ...George > > > > ====================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Thu Mar 29 16:30:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12099 for ; Thu, 29 Mar 2001 16:30:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkimn29158; Thu, 29 Mar 2001 21:27:36 GMT Received: by mail-control.mail.uu.net id QQkimn20819 for mpls-outgoing; Thu, 29 Mar 2001 21:27:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkimn20811 for ; Thu, 29 Mar 2001 21:26:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkimn16228 for ; Thu, 29 Mar 2001 21:26:35 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkimn21381 for ; Thu, 29 Mar 2001 21:26:35 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 QAA03214; Thu, 29 Mar 2001 16:26:32 -0500 (EST) 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 QAA00240; Thu, 29 Mar 2001 16:26:35 -0500 (EST) Message-ID: <3AC3A8B6.CD1D4BDD@marconi.com> Date: Thu, 29 Mar 2001 16:27:18 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: giles@goneto.net CC: neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <3AC3A8C0.F8433A12@goneto.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Giles Heron wrote: > > Definitely. I've never quite understood where the whole 10s of > milliseconds thing came from. Sure, SONET/SDH can do this - but how > many applications need it? We had a voice network long before SONET > was invented... In a circuit emulation environment, <10ms rerouting means you can reroute around a failure before SONET APS kicks in. This is why it is used in the ATM world, anyway. For applications other than circuit emulation, you're right. There shouldn't be a need for _that_ level of performance. -- David From owner-mpls@UU.NET Thu Mar 29 17:27:35 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14609 for ; Thu, 29 Mar 2001 17:27:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkimr18680; Thu, 29 Mar 2001 22:25:29 GMT Received: by mail-control.mail.uu.net id QQkimr11712 for mpls-outgoing; Thu, 29 Mar 2001 22:24:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkimr11698 for ; Thu, 29 Mar 2001 22:24:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkimr28544 for ; Thu, 29 Mar 2001 22:24:09 GMT Received: from mail.ispsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.119.223.138]) id QQkimr17094 for ; Thu, 29 Mar 2001 22:24:09 GMT Received: from metallica (metallica.tf.ispsoft.com [192.168.2.48]) by mail.ispsoft.com (8.10.1/8.10.1) with SMTP id f2TMO8c29378 for ; Thu, 29 Mar 2001 17:24:08 -0500 Message-ID: <071f01c0b89e$ed906260$3002a8c0@tf.ispsoft.com> From: "raghu arni" To: Subject: mpls deployment archs Date: Thu, 29 Mar 2001 17:23:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Are there any other docs that talk about real mpls deployment architectures/experiences/issues...? I have seen the level3 and the globalcenter docs but want to see some more ;) Thx. Arni From owner-mpls@UU.NET Fri Mar 30 07:14:00 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09901 for ; Fri, 30 Mar 2001 07:14:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiou17059; Fri, 30 Mar 2001 12:12:38 GMT Received: by mail-control.mail.uu.net id QQkiou25392 for mpls-outgoing; Fri, 30 Mar 2001 12:12:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiou25316 for ; Fri, 30 Mar 2001 12:11:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiou00984 for ; Fri, 30 Mar 2001 12:04:37 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkiou11578 for ; Fri, 30 Mar 2001 12:04:36 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f2UC43718711; Fri, 30 Mar 2001 14:04:03 +0200 (MET DST) Received: from alcatel.be ([138.203.253.200]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A1F.00418E61; Fri, 30 Mar 2001 13:56:03 +0200 Message-ID: <3AC473D7.7A50CB85@alcatel.be> Date: Fri, 30 Mar 2001 13:53:59 +0200 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rgoguen@cisco.com, swallow@cisco.com CC: mpls@UU.NET Subject: Comments to Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Rob, George, Please find included my comments to your draft. Regards, Francis. -------------- 1) PHP vs global label space. The text of section 2 states the following: "The penultimate hop of the backup tunnel would pop the label for the backup tunnel, revealing the label which M expects." However, when reading your proposal, the use of PHP does not seem mandatory, even when a global space is used in the merge node M. Please add an explicit statement to the text whether or not PHP is mandatory in the global label space case. 2) Bypass tunnel. The text of section 2 states the following: "When a failure occurs and the backup comes into use, a means of maintaining the RSVP state is required. In this simple case the Path messages can simply be sent via the backup link or tunnel as the case may be." Refreshing RSVP messages down a bypass tunnel is not described in any RFC or ID (also not in draft-ietf-mpls-rsvp-lsp-tunnel-08). Therefore, the mechanism needs to be explained in your draft. e.g. Which value should be used for the PHOP object when refreshing the PATH message down the bypass tunnel? Note: You could consider reusing the signalling mechanisms Kireeti Kompella has defined for LSPs used as FAs. 3) Local label space. The text in section 4 states the following: "In this case no Path message is sent down the bypass tunnel prior to a failure." Does a similar approach hold when the merge node uses a non-global label space? That is, when using a non-global label space, is the label binding **through the bypass tunnel** for the LSPs being protected, established before or after the failure occurs? Please make an explicit statement in the text. 4) p.6, section 2, extended tunnel id. Is it for the purpose of your draft allowed to set the extended tunnel id to all 0s as well as setting it to an IPv4 address of the ingress LSR? 5) p.6, section 2, last but one paragraph. The text states that 'it is thus necessary to properly associate the LSP_ID of a backup tunnel with the LSP_ID of the tunnel being backed up'. However, from the text (p.6, section 2, last but one paragraph) it does not seem to be necessary to copy the LSP_ID since the 'other LSP' mentioned in the text, has another 'IPv4 tunnel sender address' in the SENDER_TEMPLATE. A drawing showing an example, would be useful. From owner-mpls@UU.NET Fri Mar 30 07:26:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10532 for ; Fri, 30 Mar 2001 07:26:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiov17104; Fri, 30 Mar 2001 12:25:30 GMT Received: by mail-control.mail.uu.net id QQkiov26176 for mpls-outgoing; Fri, 30 Mar 2001 12:25:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiov26163 for ; Fri, 30 Mar 2001 12:24:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiov20561 for ; Fri, 30 Mar 2001 12:24:23 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkiov20677 for ; Fri, 30 Mar 2001 12:24:22 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA16305 for mpls@uu.net; Fri, 30 Mar 2001 07:24:21 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiov26124 for ; Fri, 30 Mar 2001 12:23:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiov08264 for ; Fri, 30 Mar 2001 12:22:01 GMT Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.dataconnection.com [192.91.191.8]) id QQkiov19224 for ; Fri, 30 Mar 2001 12:22:00 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Mar 2001 13:21:45 +0100 Message-ID: <37701240971DD31193970000F6CCB9F7027AFBF2@duke.datcon.co.uk> From: Ben Miller To: "'sehcheok@china.com'" Cc: "'mpls@UU.NET'" Subject: RE: Network Restoration Date: Fri, 30 Mar 2001 13:21:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Norman My apologies for the delay in responding to this. Data Connection has just published a whitepaper on exactly this subject. You can download it from http://www.dataconnection.com/mpls/. Regards Ben ----------------------------------------------- Ben Miller Business Unit Manager, Network Convergence Group Data Connection Ltd Tel: +44 (0) 20 8366 1177 Fax: +44 (0) 20 8363 1468 Email: bmm@dataconnection.com Web: http://www.dataconnection.com > -----Original Message----- > From: Norman Ng [mailto:sehcheok@china.com] > Sent: Tuesday, March 06, 2001 7:30 PM > To: mpls@UU.NET > Subject: Network Restoration > > > Hi to all, I am new mpls technology and I would like to know > more about the > network restoration and protection in MPLS. Could anyone let > me know more > information or references in this area. > > Also I have some queries, what happens if a MPLS network has > a span failure > or node failure in say a mesh network? > > Does it performs convergence like in OSPF?? > > If restoration is performed, how fast does it takes? > > Can this area be improved upon as I am looking into for an > area to work on > for my thesis. > > > Thanks in advance for helping. > > Warmest Regards, > Norman > From owner-mpls@UU.NET Fri Mar 30 07:42:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11617 for ; Fri, 30 Mar 2001 07:42:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiow11057; Fri, 30 Mar 2001 12:40:59 GMT Received: by mail-control.mail.uu.net id QQkiow26648 for mpls-outgoing; Fri, 30 Mar 2001 12:40:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiow26643 for ; Fri, 30 Mar 2001 12:40:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiow20360 for ; Fri, 30 Mar 2001 12:36:11 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkiow01931 for ; Fri, 30 Mar 2001 12:36:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA17235 for mpls@uu.net; Fri, 30 Mar 2001 07:36:10 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiow26461 for ; Fri, 30 Mar 2001 12:35:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiow14700 for ; Fri, 30 Mar 2001 12:30:55 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkiow25250 for ; Fri, 30 Mar 2001 12:30:55 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10928; Fri, 30 Mar 2001 07:30:56 -0500 (EST) Message-Id: <200103301230.HAA10928@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-state-04.txt Date: Fri, 30 Mar 2001 07:30:56 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP State Machine Author(s) : C. Boscher, P. Cheval, L. Wu, E. Gray Filename : draft-ietf-mpls-ldp-state-04.txt Pages : 78 Date : 29-Mar-01 In the current LDP specification [4], there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This document provides state machine tables for ATM switch LSRs. We begin in section 2 by defining a list of terminologies. Then in section 3, we propose two sets of state machine tables for ATM switch LSRs which use downstream-on-demand mode, one method can be used for non-vc merge capable ATM LSRs, while the other one can be used for the vc-merge capable ATM LSRs. In section 4, we provides a state machine for downstream unsolicited mode ATM LSRs. We focus on the LDP state machines and the associated control blocks used for establishing and maintaining LSPs. We do not describe state machines for the 'LDP controller' which is in charge of LDP session initialization, address mapping messages management, routing interface, etc. which is defined in the LDP specification [4]. Even though the state machines in this document are specific for ATM-LSR, they can be easily adapted for other types of LSRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-state-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-ldp-state-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-ldp-state-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: <20010329145250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-state-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-state-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010329145250.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 30 10:03:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19292 for ; Fri, 30 Mar 2001 10:03:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkipg22246; Fri, 30 Mar 2001 15:00:59 GMT Received: by mail-control.mail.uu.net id QQkipg11435 for mpls-outgoing; Fri, 30 Mar 2001 15:00:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkipg11192 for ; Fri, 30 Mar 2001 15:00:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkipf04002 for ; Fri, 30 Mar 2001 14:59:00 GMT Received: from mail.ispsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.119.223.138]) id QQkipf10783 for ; Fri, 30 Mar 2001 14:59:00 GMT Received: from metallica (metallica.tf.ispsoft.com [192.168.2.48]) by mail.ispsoft.com (8.10.1/8.10.1) with SMTP id f2UEx0c04009 for ; Fri, 30 Mar 2001 09:59:00 -0500 Message-ID: <004901c0b929$ed7fb060$3002a8c0@tf.ispsoft.com> From: "raghu arni" To: Subject: mpls arch docs..pointers Date: Fri, 30 Mar 2001 09:58:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C0B900.048668F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C0B900.048668F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, I did not get any additional pointers but I got a lot of mail asking me = for the docs that I mentioned in my earlier mail..I thought it would be = convenient to mail it to the list than to send out to each one = separately=20 So here goes: http://www.watersprings.org/links/mlr/id/draft-springer-te-level3bcp-00.t= xt http://www.cse.msu.edu/~xiaoxipe/papers/mplsTE/mpls.te.pdf Any additional docs would be appreciated.. hth, Arni ------=_NextPart_000_0046_01C0B900.048668F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
I did not get any additional pointers = but I got a=20 lot of mail asking me for the docs that I mentioned in my earlier = mail..I=20 thought it would be convenient to mail it to the list than to send out = to each=20 one separately
 
So here goes:
http://www.watersprings.org/links/mlr/id/draft-springer-te-le= vel3bcp-00.txt
http:= //www.cse.msu.edu/~xiaoxipe/papers/mplsTE/mpls.te.pdf
 
Any additional docs would be=20 appreciated..
 
hth,
Arni
------=_NextPart_000_0046_01C0B900.048668F0-- From owner-mpls@UU.NET Fri Mar 30 11:12:30 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22959 for ; Fri, 30 Mar 2001 11:12:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkipk17266; Fri, 30 Mar 2001 16:08:53 GMT Received: by mail-control.mail.uu.net id QQkipk19563 for mpls-outgoing; Fri, 30 Mar 2001 16:08:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkipk19553 for ; Fri, 30 Mar 2001 16:08:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkipk02868 for ; Fri, 30 Mar 2001 16:06:45 GMT Received: from babelfish.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: babelfish.axion.bt.co.uk [132.146.17.20]) id QQkipk20378 for ; Fri, 30 Mar 2001 16:06:45 GMT Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) by babelfish (local) with SMTP; Fri, 30 Mar 2001 17:06:25 +0100 Received: from ip-engineering.bt.com by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id RAA07767; Fri, 30 Mar 2001 17:06:24 +0100 (BST) Message-Id: <200103301606.RAA07767@celiborn.ip-engineering.bt.com> X-Mailer: exmh version 2.0.3 9/28/98 To: giles@goneto.net cc: neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels In-reply-to: Your message of "Thu, 29 Mar 2001 22:27:28 BST." <3AC3A8C0.F8433A12@goneto.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Mar 2001 17:06:24 +0100 From: Peter Willis Sender: owner-mpls@UU.NET Precedence: bulk > Both of these would only occur (as far as I can tell) if the router > software is buggy. As I have stated before I don't really see the > benefit of adding code to fix buggy code. If the LSR software was sufficiently simple that it could be proved to be correct, I guess we're all aware of formal software validation and testing methods, then the value of adding more software to monitor for "bugs" could be questioned. I guess, and the vendors will no doubt shout if I'm wrong, that they have NOT formally validated their software. Safety Critical Systems use the practice of "watchdog" code to check for abnormal conditions and limit the damage caused by the abnormal conditions. Safety Critical Systems should also handle "rare" conditions. I guess that no one is planing to use MPLS networks to support safety critical systems so we have no need to worry about having "watchdog" code to detect abnormal conditions and limit the hazard they may cause. By the way the car I drive has a low brake fluid detector but no bulb on the dashboard to display when its detected low brake fluid. At least I don't have to worry about checking the low brake fluid bulb is working (its a British sports car!) and I don't get stopped by false alerts from the low brake fluid detector, besides I know when the brake fluid is low when the brakes stop working. Peter. From owner-mpls@UU.NET Fri Mar 30 11:13:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23020 for ; Fri, 30 Mar 2001 11:13:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkipk18710; Fri, 30 Mar 2001 16:10:10 GMT Received: by mail-control.mail.uu.net id QQkipk19566 for mpls-outgoing; Fri, 30 Mar 2001 16:08:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkipk19558 for ; Fri, 30 Mar 2001 16:08:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkipk03373 for ; Fri, 30 Mar 2001 16:06:57 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkipk13434 for ; Fri, 30 Mar 2001 16:06:56 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Fri, 30 Mar 2001 17:02:25 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 30 Mar 2001 17:00:50 +0100 Message-ID: To: giles@goneto.net Cc: mpls@UU.NET Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Fri, 30 Mar 2001 17:00:39 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron [mailto:giles@goneto.net] wrote 29 March 2001 22:27 > neil.2.harrison@bt.com wrote: > > > > 2 At the top of page 5 in section 2 it says: > > " When a failure occurs and the backup comes into use,......" > > > > All user-plane (and indeed control-plane) failure modes > must be identified > > and specified in terms of entry/exit criteria and > consequent actions before > > we can meaningfully proceed with this draft. > > > > For the user-plane, the failure modes which must be > considered/defined are: > > - simple below MPLS fabric server layer connectivity breaks; > > - simple within MPLS fabric connectivity breaks (at > or below the LSP > > level considered); > > Both of these will be detected by the RSVP signalling, won't they? NH=> Not necessarily. The functionality/processing of the user-plane and control-traffic is not identical......and they can be subject to different failure modes. Each needs its own OAM to handle defects relevant to its own case. Further, one would like to have SLAs for the user-plane (for customers) that require specific and consistent measurement. They also require certain 'consequential actions' which are not currently specified anywhere else but in our ID. And in general, one should not look at just 'some' cases of defect in isolation.....they all require a harmonised approach and, with careful up-front thought, this should also yield simplicity of design. If you don't think about these aspects at the outset then things can get very complex later should you require to add such functionality. > > > - swapped LSPs, ie instead of A1->A2 and B1->B2 a > defect creates > > A1->B2 and B1->A2; > > - mismerged LSPs, eg instead of A1->A2 and B1->B2 a > defect creates > > A1->A2 and A1+B1->B2 say (though there are potentially > several variations on > > this). > > Both of these would only occur (as far as I can tell) if the router > software is buggy. As I have stated before I don't really see the > benefit of adding code to fix buggy code. NH=> It can be HW as well as SW that is faulty. The OAM has nothing to do with 'fixing buggy code'....indeed it will not *fix* the defects, but only allow correct handling should they occur to protect my customers and help my Ops people diagnose the problem. It is also there to ensure a consistent (and indeed simple) method of measuring availability and QoS (the former is *the* critical metric, and the latter is dependent on former since it only applies to the up-state). I have not seen any work (other than what is in our ID) which shows how availability/QoS metrics can be consistently and simply measured for all defect cases. And as a carrier this is something I want. However, the overall purpose of the OAM is stated in the principles section of the ID. I refer people back to this rather than repeat here. > > > For the latter 2 defects it will be vital to suppress the > traffic due to > > potential security/censorship/misbilling implications for > carriers and > > customers. Speaking as a carrier these issues are > requirements that must be > > addressed. This is not optional, and rigorous definitions > must be provided > > (or referenced). > > Speaking as another carrier I *don't* see these as requirements that > must be addressed. If software is buggy things go wrong. So > let's fix > the software rather than adding another layer to "manage" the bugs. NH=> How are you going to decide/detect that the SW (or HW) is wrong in order to fix it? Are you really also telling me you have no requirements to offer/measure availability/QoS SLAs for customers?......but if you do then I would be interested to know how you are going to do this, ie do you have an alternative proposal you can share with us for evaluation please? It would also be nice to hear from more carriers on this subject.....I know BT, FT, DT, NTT and AT&T have an interest since they have seen/commented on what appears in the work you have seen. From owner-mpls@UU.NET Fri Mar 30 11:47:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25195 for ; Fri, 30 Mar 2001 11:47:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkipm17229; Fri, 30 Mar 2001 16:44:11 GMT Received: by mail-control.mail.uu.net id QQkipm22254 for mpls-outgoing; Fri, 30 Mar 2001 16:43:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkipm22249 for ; Fri, 30 Mar 2001 16:43:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkipm26765 for ; Fri, 30 Mar 2001 16:41:36 GMT Received: from hoemlsrv.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkipm02436 for ; Fri, 30 Mar 2001 16:41:36 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA02622 for ; Fri, 30 Mar 2001 11:41:35 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA02606 for ; Fri, 30 Mar 2001 11:41:34 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 18:41:33 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0BD4F7AD@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: mpls@UU.NET, George Swallow Subject: RE: Draft MPLS minutes Date: Fri, 30 Mar 2001 18:41:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Sorry to bother you with admib/process like issues See inline > ---------- > From: George Swallow[SMTP:swallow@cisco.com] > Sent: Thursday, March 29, 2001 12:56 AM > To: mpls@UU.NET > Subject: Draft MPLS minutes > > > MPLS WG Meeting Thursday, March 22, 2001 > ======================================== > .. snip ... > 4. MIBs (in IESG last call) > > Definitions of Managed Objects for the Multiprotocol Label Switching, > Label Distribution Protocol (LDP) > > > MPLS Label Switch Router Management Information Base Using SMIv2 > > > Authors are in the process addressing comments from the IESG. > Another round of last calls is probably not required. > I am not so sure of that. Some serious issues have been found, and I think some real changes may occur. Let's see what the next rev of these drafts will look like first. ... snip .... > 7. Generalized MPLS Signaling drafts > > These drafts are nearly complete. They will be updated based on > the results of CCAMP. Once updated they will be sent for joint > CCAMP and MPLS WG last call. Consensus to do the MPLS WG last call > was reached in this meeting. > This point 7 does not harm I guess... But in principle, "consensus is never reached in a f2f meeting". Need to check for consensus on the WG mailing list. But I guess this could be reworded to say "the meeting agreed to do a WG last call for this doc to gauge consensus on the document". > 8. Unnumbered, Bundle, Hierarchy drafts > > After the "sub IP" re-org, these drafts remain in MPLS. > > Proposal: Accept draft-kompella-mpls-undle-05.txt as working group > draft. Update the draft as draft-mpls-bundle-00.txt. Some of the > other drafts will also be updated. Once updated a WG last call > will be issued. None opposed; consensus. > Again... consensus on this MUST be sought on the WG mailing list. ... snip .... > IV. LDP Fault Tollerance Philip Matthews > > > Summarized draft. Discussed changes between last version and current > version. Expect to ask for wg last call soon. Requested comments now or > via > mailing list. > > George: Consensus to put this draft to a wg last call. Luca Martini > opposes > wg last call; no other objections. > Make sure we have consensus on WG mailing list! Bert From owner-mpls@UU.NET Fri Mar 30 14:43:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08887 for ; Fri, 30 Mar 2001 14:43:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkipy19004; Fri, 30 Mar 2001 19:40:38 GMT Received: by mail-control.mail.uu.net id QQkipy27295 for mpls-outgoing; Fri, 30 Mar 2001 19:40:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkipy27276 for ; Fri, 30 Mar 2001 19:39:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkipy01072 for ; Fri, 30 Mar 2001 19:39:32 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkipy17384 for ; Fri, 30 Mar 2001 19:39:32 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 6BC1B94006; Fri, 30 Mar 2001 14:39:28 -0500 (EST) Message-ID: <3AC4E0F0.8B8E0191@sandburst.com> Date: Fri, 30 Mar 2001 14:39:28 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: mpls@UU.NET, George Swallow Subject: Re: Draft MPLS minutes References: <2413FED0DFE6D111B3F90008C7FA61FB0BD4F7AD@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bert, It can be a pleasure to second guess a second guesser. :-) You wrote: > Sorry to bother you with admib/process like issues > See inline > > > ---------- > > From: George Swallow[SMTP:swallow@cisco.com] > > Sent: Thursday, March 29, 2001 12:56 AM > > To: mpls@UU.NET > > Subject: Draft MPLS minutes > > > > > > MPLS WG Meeting Thursday, March 22, 2001 > > ======================================== > > > .. snip ... > > > 4. MIBs (in IESG last call) > > > > Definitions of Managed Objects for the Multiprotocol Label Switching, > > Label Distribution Protocol (LDP) > > > > > > MPLS Label Switch Router Management Information Base Using SMIv2 > > > > > > Authors are in the process addressing comments from the IESG. > > Another round of last calls is probably not required. > > > I am not so sure of that. Some serious issues have been found, and I > think some real changes may occur. Let's see what the next rev > of these drafts will look like first. Please state which drafts you think this observation applies to. There is no sense in holding a last call on all regenerated drafts because there is a sense that some serious issues (may) have been raised with respect to some drafts. > > > ... snip .... > > > 7. Generalized MPLS Signaling drafts > > > > These drafts are nearly complete. They will be updated based on > > the results of CCAMP. Once updated they will be sent for joint > > CCAMP and MPLS WG last call. Consensus to do the MPLS WG last call > > was reached in this meeting. > > > This point 7 does not harm I guess... But in principle, "consensus is never > reached in a f2f meeting". Need to check for consensus on the WG > mailing list. But I guess this could be reworded to say "the meeting > agreed to do a WG last call for this doc to gauge consensus on the > document". "Rough consensus" is basically obtained when the chairs say it has been. I'm not sure where your quote comes from and I'm having trouble making it fit with my experiences with the IETF. > > > > 8. Unnumbered, Bundle, Hierarchy drafts > > > > After the "sub IP" re-org, these drafts remain in MPLS. > > > > Proposal: Accept draft-kompella-mpls-undle-05.txt as working group > > draft. Update the draft as draft-mpls-bundle-00.txt. Some of the This should read "draft-ietf-mpls-bundle-00.txt" > > > other drafts will also be updated. Once updated a WG last call > > will be issued. None opposed; consensus. > > > Again... consensus on this MUST be sought on the WG mailing list. On the contrary, in order to successfully argue that rough consensus has not been achieved, there needs to be more than one or two lone voices in the wilderness that disagree. > > > ... snip .... > > > IV. LDP Fault Tollerance Philip Matthews > > > > > > Summarized draft. Discussed changes between last version and current > > version. Expect to ask for wg last call soon. Requested comments now or > > via > > mailing list. > > > > George: Consensus to put this draft to a wg last call. Luca Martini > > opposes > > wg last call; no other objections. > > > Make sure we have consensus on WG mailing list! On this, we can agree. However, the process is simple - the chair asserts that "rough consensus" was achieved, and the people on the mailing list have an opportunity to disagree. Do you disagree that these things should happen, or are you strictly arguing process? > > > Bert -- Eric Gray From owner-mpls@UU.NET Fri Mar 30 16:00:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13955 for ; Fri, 30 Mar 2001 16:00:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiqd28833; Fri, 30 Mar 2001 20:57:29 GMT Received: by mail-control.mail.uu.net id QQkiqd21486 for mpls-outgoing; Fri, 30 Mar 2001 20:56:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiqd21473 for ; Fri, 30 Mar 2001 20:56:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiqd26156 for ; Fri, 30 Mar 2001 20:55:24 GMT Received: from localhost.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host197.pluris.com [208.227.9.197]) id QQkiqd25522 for ; Fri, 30 Mar 2001 20:55:23 GMT Received: from localhost (localhost [127.0.0.1] (may be forged)) by localhost.pluris.com (8.10.2/8.10.2) with ESMTP id f2UKrmd00747; Fri, 30 Mar 2001 12:53:48 -0800 (PST) Message-Id: <200103302053.f2UKrmd00747@localhost.pluris.com> Date: Fri, 30 Mar 2001 12:53:48 -0800 From: Bora Akyol Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels Cc: mpls@UU.NET, Kireeti Kompella , ccamp@ops.ietf.org To: George Swallow X-Mailer: Apple Mail (2.387) In-Reply-To: <200103282303.SAA15707@pilgrim.cisco.com> Mime-Version: 1.0 (Apple Message framework v387) Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit As far as I understand this draft outlines a mechanism for fast reroute in MPLS networks. With this in mind, shouldn't we delay the last call on this draft until ther **other** fast reroute related drafts in CCAMP run to completion? Regards Bora On Wednesday, March 28, 2001, at 03:03 PM, George Swallow wrote: > This message commences a workgroup last call on "RSVP Label Allocation > for Backup Tunnels" . This > draft is informational. The last call closes April 11, 12 PM GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Fri Mar 30 16:11:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14741 for ; Fri, 30 Mar 2001 16:11:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiqe09554; Fri, 30 Mar 2001 21:07:29 GMT Received: by mail-control.mail.uu.net id QQkiqe07237 for mpls-outgoing; Fri, 30 Mar 2001 21:06:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiqe05707 for ; Fri, 30 Mar 2001 21:06:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiqe12817 for ; Fri, 30 Mar 2001 21:06:23 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkiqe08415 for ; Fri, 30 Mar 2001 21:06:23 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 1D0A494009; Fri, 30 Mar 2001 16:06:23 -0500 (EST) Message-ID: <3AC4F54F.16BCD6E@sandburst.com> Date: Fri, 30 Mar 2001 16:06:23 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol Cc: George Swallow , mpls@UU.NET, Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <200103302053.f2UKrmd00747@localhost.pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora, Why? -- Eric Gray You wrote: > As far as I understand this draft outlines a mechanism for fast reroute > in MPLS networks. With this in mind, shouldn't we delay the last call on > this draft until ther **other** fast reroute related drafts in CCAMP run > to completion? > > Regards > > Bora > > On Wednesday, March 28, 2001, at 03:03 PM, George Swallow wrote: > > > This message commences a workgroup last call on "RSVP Label Allocation > > for Backup Tunnels" . This > > draft is informational. The last call closes April 11, 12 PM GMT. > > > > ...George > > > > ====================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Fri Mar 30 16:14:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14880 for ; Fri, 30 Mar 2001 16:14:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiqe27949; Fri, 30 Mar 2001 21:11:38 GMT Received: by mail-control.mail.uu.net id QQkiqe09079 for mpls-outgoing; Fri, 30 Mar 2001 21:10:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiqe09071 for ; Fri, 30 Mar 2001 21:10:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiqe18867 for ; Fri, 30 Mar 2001 21:09:42 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkiqe26255 for ; Fri, 30 Mar 2001 21:09:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA25016 for mpls@uu.net; Fri, 30 Mar 2001 16:09:41 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkiqe01283 for ; Fri, 30 Mar 2001 21:05:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiqe05838 for ; Fri, 30 Mar 2001 21:05:04 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkiqe22746 for ; Fri, 30 Mar 2001 21:05:03 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA19411; Fri, 30 Mar 2001 16:04:23 -0500 (EST) Message-Id: <200103302104.QAA19411@pilgrim.cisco.com> To: Bora Akyol cc: George Swallow , mpls@UU.NET, Kireeti Kompella , ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels In-reply-to: Your message of "Fri, 30 Mar 2001 12:53:48 PST." <200103302053.f2UKrmd00747@localhost.pluris.com> Date: Fri, 30 Mar 2001 16:04:23 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > As far as I understand this draft outlines a mechanism for fast reroute > in MPLS networks. With this in mind, shouldn't we delay the last call on > this draft until ther **other** fast reroute related drafts in CCAMP run > to completion? > > Regards > > Bora Bora - I don't get your point. Would you suggest that Sonet not specify BLSR or closer to home IPoPTR not work on rerouting schemes? This is a technology specific mechanism which has immediate application. How or even if it fits into a larger picture is irrelavant. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Mar 30 20:12:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24375 for ; Fri, 30 Mar 2001 20:12:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiqu20645; Sat, 31 Mar 2001 01:11:00 GMT Received: by mail-control.mail.uu.net id QQkiqu06309 for mpls-outgoing; Sat, 31 Mar 2001 01:10:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkiqu06304 for ; Sat, 31 Mar 2001 01:10:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiqu10791 for ; Sat, 31 Mar 2001 01:09:36 GMT Received: from localhost.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host197.pluris.com [208.227.9.197]) id QQkiqu12970 for ; Sat, 31 Mar 2001 01:09:35 GMT Received: from localhost (localhost [127.0.0.1] (may be forged)) by localhost.pluris.com (8.10.2/8.10.2) with ESMTP id f2V184d00890; Fri, 30 Mar 2001 17:08:04 -0800 (PST) Message-Id: <200103310108.f2V184d00890@localhost.pluris.com> Date: Fri, 30 Mar 2001 17:08:03 -0800 From: Bora Akyol Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels Cc: mpls@UU.NET, Kireeti Kompella , ccamp@ops.ietf.org To: George Swallow X-Mailer: Apple Mail (2.387) In-Reply-To: <200103302104.QAA19411@pilgrim.cisco.com> Mime-Version: 1.0 (Apple Message framework v387) Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George The point that I was trying to make is that there is **other** reroute work going on within the CCAMP WG and I am not sure about the interaction between that work and the draft that is in question. Hence I asked **a** question below. If it turns out that the WG consensus is to do a last call and send the draft forward, fine by me. However, the draft may get obsoleted quickly once the CCAMP WG concludes the fast reroute work. Bora On Friday, March 30, 2001, at 01:04 PM, George Swallow wrote: >> As far as I understand this draft outlines a mechanism for fast reroute >> in MPLS networks. With this in mind, shouldn't we delay the last call >> on >> this draft until ther **other** fast reroute related drafts in CCAMP >> run >> to completion? >> >> Regards >> >> Bora > > Bora - > > I don't get your point. Would you suggest that Sonet not specify BLSR > or closer to home IPoPTR not work on rerouting schemes? This is a > technology specific mechanism which has immediate application. How or > even if it fits into a larger picture is irrelavant. > > ...George > > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Sat Mar 31 09:16:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06621 for ; Sat, 31 Mar 2001 09:16:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkisu17984; Sat, 31 Mar 2001 14:14:50 GMT Received: by mail-control.mail.uu.net id QQkisu28008 for mpls-outgoing; Sat, 31 Mar 2001 14:14:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkisu27992 for ; Sat, 31 Mar 2001 14:14:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkisu20718 for ; Sat, 31 Mar 2001 14:13:34 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkisu16906 for ; Sat, 31 Mar 2001 14:13:33 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f2VEDBV12403; Sat, 31 Mar 2001 16:13:16 +0200 (MET DST) Received: from alcatel.be ([138.203.253.199]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A20.004E15BA; Sat, 31 Mar 2001 16:12:54 +0200 Message-ID: <3AC5E5EB.92003593@alcatel.be> Date: Sat, 31 Mar 2001 16:12:59 +0200 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: kireeti@juniper.net CC: mpls@UU.NET Subject: Comments to draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Kireeti, Please find included some comments to your draft. Kind regards, Francis. ---------------------- 1) p.13, 'tePathExclude' object. The text states that 'for each link that this path goes through, the link MUST have colors associated with it, and the intersection of the link's colors and the 'exclude' set MUST be null. Question: * Why is it mandatory for a link to have colors in order to pass the 'tePathExclude' test? Referring to section 4.7.2 in draft, the text does not impose this restriction. Therefore, according to my understanding of the draft, if all bits in the 'exclude-any' field of the SESSION ATTRIBUTE object are set to 0, the test passes automatically. 2) tePathExclude. Question: Could we rename the tePathExclude' object to 'tePathExcludeAny' in order to follow a similar convention as is done for the 'tePathIncludeAny' object and in order to align with the terminology used in section 4.7.2 of the draft? 3) Include vs exclude. For the include case 2 variants are indicated ('include-any' and 'include-all'). However, for the exclude case only 1 variant is defined ('exclude-any'). Why is the other case ('exclude-all') not defined, just as was done for the 'include-all'? [Of course, this would also require similar adaptations in the SESSION ATTRIBUTE object of the RSVP signalling protocol.] From owner-mpls@UU.NET Sat Mar 31 10:00:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11858 for ; Sat, 31 Mar 2001 10:00:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkisx26674; Sat, 31 Mar 2001 14:59:16 GMT Received: by mail-control.mail.uu.net id QQkisx00602 for mpls-outgoing; Sat, 31 Mar 2001 14:58:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkisx00597 for ; Sat, 31 Mar 2001 14:58:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkisx07982 for ; Sat, 31 Mar 2001 14:57:57 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkisx13914 for ; Sat, 31 Mar 2001 14:57:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA00652 for mpls@uu.net; Sat, 31 Mar 2001 09:57:52 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkisx00407 for ; Sat, 31 Mar 2001 14:53:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkisx24227 for ; Sat, 31 Mar 2001 14:53:34 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkisx17548 for ; Sat, 31 Mar 2001 14:53:34 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA02507; Sat, 31 Mar 2001 09:52:39 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAC26282; Sat, 31 Mar 2001 09:53:28 -0500 (EST) Message-Id: <4.3.2.7.2.20010331095310.01b0abf0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 31 Mar 2001 09:53:47 -0500 To: "raghu arni" , From: "Thomas D. Nadeau" Subject: Re: mpls deployment archs In-Reply-To: <071f01c0b89e$ed906260$3002a8c0@tf.ispsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:23 PM 3/29/2001 -0500, raghu arni wrote: >Hi, >Are there any other docs that talk about real mpls deployment >architectures/experiences/issues...? > >I have seen the level3 and the globalcenter docs but want to see some more >;) You can try the Nanog or TE WG mailing lists for more information too. There are lots of operators there willing (usually) to discuss their deployment experiences. --Tom >Thx. >Arni