From owner-mpls@UU.NET Sun Apr 2 22:56:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00509 for ; Sun, 2 Apr 2000 22:56:11 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijgl22967; Mon, 3 Apr 2000 02:54:40 GMT Received: by mail-control.mail.uu.net id QQijgl17197 for mpls-outgoing; Mon, 3 Apr 2000 02:54:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijgl17192 for ; Mon, 3 Apr 2000 02:54:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijgl15938 for ; Sun, 2 Apr 2000 22:53:54 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijgl22457 for ; Mon, 3 Apr 2000 02:53:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA16956 for mpls@uu.net; Sun, 2 Apr 2000 22:53:52 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijgl17179 for ; Mon, 3 Apr 2000 02:53:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijgl15894 for ; Sun, 2 Apr 2000 22:53:35 -0400 (EDT) Received: from ficon-tech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.198.190]) id QQijgl28167 for ; Mon, 3 Apr 2000 02:53:31 GMT Received: from ficon-tech.com (acheru.india.ficon-tech.com [172.25.1.113]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id IAA15703; Mon, 3 Apr 2000 08:17:12 +0530 (IST) (envelope-from acheru@ficon-tech.com) Message-ID: <38E806F2.1B17A31@ficon-tech.com> Date: Mon, 03 Apr 2000 08:20:27 +0530 From: Anup Anil Cheruvathoor Organization: Ficon Technology X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Zhong.Hu@comsat.com CC: mpls@UU.NET Subject: Re: Question about where to calculate the next hop References: <001913EB.003332@comsat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Zhong, The label request has a field called the FEC ( Forwarding equivalence class, ref MPLS architecure draft ). FEC decides the forwarding behaviour of the packets, for at least the hop-by-hop LSPs. The forwarding equivalence class can currently take in the following type of classifications: a) A Destination Network. b) A destination Host address. This would be used by the downstream LSR also to identify the destination of the Control Messages. Reference would be found in draft-ietf-mpls-ldp-06.txt, 3.4.1 FEC TLV. -Cheru Zhong.Hu@comsat.com wrote: > If the MPLS uses the conventional routing and the next hop address is calculated > according to the routing table, the destination address, for example, IP > destination address, should be passed to the next hop so that next next hop > address can be calculated, when LDP "label request" message is sent. However, in > the "label request" message, no such a field involves the destination address. > > I might miss something when I read the LDP draft. If anyone can point out how > the next hop adress is calculated, I would appreciate it. Thank you. > > Zhong Hu > Comsat Labs -- Name : Anup Anil Chervathoor E-mail : mailto:acheru@ficon-tech.com Web : www.ficon-tech.com From owner-mpls@UU.NET Mon Apr 3 05:54:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15463 for ; Mon, 3 Apr 2000 05:54:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijhn26170; Mon, 3 Apr 2000 09:52:35 GMT Received: by mail-control.mail.uu.net id QQijhn02523 for mpls-outgoing; Mon, 3 Apr 2000 09:52:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijhn02518 for ; Mon, 3 Apr 2000 09:52:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijhn19184 for ; Mon, 3 Apr 2000 05:51:37 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijhn25110 for ; Mon, 3 Apr 2000 09:51:36 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA05473 for mpls@uu.net; Mon, 3 Apr 2000 05:51:35 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijhn02474 for ; Mon, 3 Apr 2000 09:51:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijhn21552 for ; Mon, 3 Apr 2000 05:50:50 -0400 (EDT) Received: from qhars002.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19]) id QQijhn01798 for ; Mon, 3 Apr 2000 09:50:50 GMT Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Mon, 3 Apr 2000 10:44:04 +0100 Received: from zadcd002.europe.nortel.com ([47.217.51.232]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2BFXFZM0; Mon, 3 Apr 2000 10:44:04 +0100 Received: from nortelnetworks.com (wmlvs004.europe.nortel.com [47.49.5.35]) by zadcd002.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2D8T4MJ0; Mon, 3 Apr 2000 11:44:02 +0200 Message-ID: <38E8680C.D85FBBC7@nortelnetworks.com> Date: Mon, 03 Apr 2000 11:44:44 +0200 From: "Saso Stojanovski" X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit subscribe From owner-mpls@UU.NET Mon Apr 3 09:00:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16759 for ; Mon, 3 Apr 2000 09:00:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijhz07337; Mon, 3 Apr 2000 12:59:43 GMT Received: by mail-control.mail.uu.net id QQijhz07341 for mpls-outgoing; Mon, 3 Apr 2000 12:59:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijhz07336 for ; Mon, 3 Apr 2000 12:59:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijhz05701 for ; Mon, 3 Apr 2000 08:57:56 -0400 (EDT) Received: from kickme.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQijhz17770 for ; Mon, 3 Apr 2000 12:57:56 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA15776 for ; Mon, 3 Apr 2000 05:57:20 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA28581 for mpls@uu.net; Mon, 3 Apr 2000 08:57:54 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijha29347 for ; Mon, 3 Apr 2000 06:44:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijha06485 for ; Mon, 3 Apr 2000 02:44:36 -0400 (EDT) Received: from hotmail.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: f46.law9.hotmail.com [64.4.9.46]) id QQijha16831 for ; Mon, 3 Apr 2000 06:44:36 GMT Received: (qmail 17045 invoked by uid 0); 3 Apr 2000 06:44:35 -0000 Message-ID: <20000403064435.17044.qmail@hotmail.com> Received: from 128.230.151.26 by www.hotmail.com with HTTP; Sun, 02 Apr 2000 23:44:35 PDT X-Originating-IP: [128.230.151.26] From: "Mike Badil" To: mpls@UU.NET Subject: MPLS simulater Date: Mon, 03 Apr 2000 02:44:35 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, Does anybody know any MPLS simulater?, Is there any public code exist? Thanks ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-mpls@UU.NET Mon Apr 3 10:32:48 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17850 for ; Mon, 3 Apr 2000 10:32:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijig05583; Mon, 3 Apr 2000 14:30:14 GMT Received: by mail-control.mail.uu.net id QQijif00503 for mpls-outgoing; Mon, 3 Apr 2000 14:29:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijif00498 for ; Mon, 3 Apr 2000 14:29:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijif19705 for ; Mon, 3 Apr 2000 10:29:01 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQijif03955 for ; Mon, 3 Apr 2000 14:29:00 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA07828 for ; Mon, 3 Apr 2000 07:29:02 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA29129 for mpls@uu.net; Mon, 3 Apr 2000 10:28:58 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijif00314 for ; Mon, 3 Apr 2000 14:24:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijif20109 for ; Mon, 3 Apr 2000 10:24:02 -0400 (EDT) Received: from sarah.mindvision.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [207.138.35.26]) id QQijif28869 for ; Mon, 3 Apr 2000 14:24:02 GMT Received: (from alan@localhost) by sarah.mindvision.com (8.10.0/8.8.7) id e33EP8701990; Mon, 3 Apr 2000 09:25:08 -0500 Date: Mon, 3 Apr 2000 09:25:08 -0500 From: Alan Hannan To: Mike Badil Cc: mpls@UU.NET Subject: Re: MPLS simulater Message-ID: <20000403092508.D29363@globalcenter.net> References: <20000403064435.17044.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000403064435.17044.qmail@hotmail.com>; from hasko10@hotmail.com on Mon, Apr 03, 2000 at 02:44:35AM -0400 Sender: owner-mpls@UU.NET Precedence: bulk I dunno about public code, however WANDL [www.wandl.com] is awesome. -alan Thus spake Mike Badil (hasko10@hotmail.com) on or about Mon, Apr 03, 2000 at 02:44:35AM -0400: > Hi, > > Does anybody know any MPLS simulater?, > Is there any public code exist? > > Thanks > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > From owner-mpls@UU.NET Mon Apr 3 10:32:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17864 for ; Mon, 3 Apr 2000 10:32:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijig18310; Mon, 3 Apr 2000 14:31:36 GMT Received: by mail-control.mail.uu.net id QQijig00613 for mpls-outgoing; Mon, 3 Apr 2000 14:31:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijig00574 for ; Mon, 3 Apr 2000 14:30:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijig21388 for ; Mon, 3 Apr 2000 10:30:31 -0400 (EDT) Received: from adn.alcatel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: workstation.adn.alcatel.com [198.205.32.33] (may be forged)) id QQijig17353 for ; Mon, 3 Apr 2000 14:30:30 GMT Received: from postal.adn.alcatel.com (postal [143.209.80.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id KAA28282 for ; Mon, 3 Apr 2000 10:23:23 -0400 (EDT) Received: from adn.alcatel.com ([143.209.82.55]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA1456; Mon, 3 Apr 2000 10:37:11 -0400 Message-ID: <38E8AAC6.270BEDF3@adn.alcatel.com> Date: Mon, 03 Apr 2000 10:29:26 -0400 From: Ben Abarbanel X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sumitg@rocketmail.com CC: mpls@UU.NET Subject: Re: MPLS routing accross AS boundaries References: <20000401012228.18825.qmail@web2905.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sumit: Yes, I have a solution. I am working on a draft now, and have nailed down the basic concept and mechanism. I need a few more days to clean it up and will make it public. If others are interested in coauthoring it with me, I will be delighted. Regards, Ben Sumit Garg wrote: > Ben: > > > James: > > [snip] > > > in the Internet. I say we need a mechanism that has total > > picture view of the entire > > Internet > > at the source or Ingress router of the first LSP. Thereby, it > > could choose the right > > I think the current internet "only" supports the hop-by-hop > paradigm. Can/ does one view of the entire Internet at all exist/ > possible. After all the Internet is pretty dynamic. And I think > there is no (routing) protocol that really facilitates an entire > view of the internet. Correct me if I'm wrong > > > LSP that > > will be considered with all the others down the path to the > > destination. I have a > > solution for > > that with BGP. > > Could you share this. Sounds interesting ... > > Regards > Sumit > > ===== > Sumit Garg > sumitg@rocketmail.com > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com -- Remember ======== "Don't be afraid to try something new. Amateurs built the Arc, professionals built Titanic" From owner-mpls@UU.NET Mon Apr 3 14:34:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21430 for ; Mon, 3 Apr 2000 14:34:15 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijiw17514; Mon, 3 Apr 2000 18:33:27 GMT Received: by mail-control.mail.uu.net id QQijiw16860 for mpls-outgoing; Mon, 3 Apr 2000 18:32:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijiw16851 for ; Mon, 3 Apr 2000 18:32:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijiw00550 for ; Mon, 3 Apr 2000 14:32:24 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [207.71.195.18]) id QQijiw25214 for ; Mon, 3 Apr 2000 18:32:23 GMT Received: by LUX with Internet Mail Service (5.5.2448.0) id ; Mon, 3 Apr 2000 11:32:14 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC013E2B7@LUX> From: Jonathan Lang To: "'Krishna Bala'" , "James V. Luciani" , Jagan Shantigram , Jonathan Lang , curtis@avici.com Cc: Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Mon, 3 Apr 2000 11:32:07 -0700 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 The Architecture Working Group of the OIF is discussing both the Peer model and the Overlay model. Regards, Jonathan -----Original Message----- From: Krishna Bala [mailto:kbala@tellium.com] Sent: Tuesday, March 28, 2000 11:27 PM To: James V. Luciani; Jagan Shantigram; Jonathan Lang; curtis@avici.com Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt Jim, Hmm! The OIF is using the terms 1) Peer 2) Open So, if possible ... so as to avoid creating yet another term for the same thing (X in this case) I suggest we call it "open". Krishna > -----Original Message----- > From: James V. Luciani [mailto:jluciani@tollbridgetech.com] > Sent: Monday, March 27, 2000 6:42 PM > To: Krishna Bala; Jagan Shantigram; Jonathan Lang; curtis@avici.com > Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > > Just to beat a dead horse .. the difference between the open model > > and the overlay is just that the overlay model typically suggests that > > That depends... see below. > > > there would be N^2 connectivity (i.e., every router, for instance, is > > statically connected to every other). In any case, the open model allows > > While there may indeed be some misunderstanding as to the meaning of the > "overlay model" (not to mention the meaning of the other models :-)), the > traditional definition of overlay is not one of static operation. > NHRP and > MPOA, for example, are overlay in my book (and most folks that I know). > They most certainly imply non-static connections by defintion > (i.e., use of > SVCs). This having been said, I believe that we can do one of two things > here. One, keep the current terms and potentially risk an ad nauseum > inspection of the meaning of these terms; or two, come up with a > term which > is satisfactory to all. In the second case we would have models: > 1) X > 2) Peer > where X is the PC term for what we want to get at. So my opine is that > X="augmented routing model"/ARM model. > > Do I hear a hmmmm??? > --Jim > > > for fully dynamic operation. The overlay model suggests static operation > of > > the optical layer. > > > > As I see it there are only two architectures that are worth considering: > > 1. Peer > > 2. Open > > > > I agree with you that there is no need to add the "overlay" model to > > this list. The open model covers the static and the dynamic cases. > > > > Krishna > > > > > -----Original Message----- > > > From: Jagan Shantigram [mailto:jagan@photonex.com] > > > Sent: Monday, March 27, 2000 10:14 AM > > > To: Krishna Bala; Jonathan Lang; curtis@avici.com > > > Cc: Khaled Elsayed; mpls@UU.NET; > ip-optical@lists.research.bell-labs.com > > > Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > > > > > > > At 05:04 PM 3/24/00 -0500, Krishna Bala wrote: > > > >Jonathan, > > > >Point 1: Let me clarify the "open model". > > > > > > > >Open refers to the fact that this model supports the > interconnection of > > > >several types of clients to an optical network (server layer). > > > >Examples of Clients: > > > >IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" > > > > > > > >The open model also allows the interconnection of other > Optical Network > > > >Elements to > > > >each other. > > > >Examples of other Network Elements: > > > >Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, > Wavelength > > > >Interchanging XC > > > > > > > >In general, since it offers the capability to support ALL > > > services (not just > > > >IP) > > > >it is an Open Model. > > > > > > Krishna, > > > > > > It seems like the above just described what people understand > > > by the overlay model. In this model the optical layer presents > > > itself as a layer that can provide a bunch of services to the > > > upper data/IP layer. These services could include point > > > to point clear channel, 1+1 protection, negotiable bandwidth > > > etc.. (just to give examples). How the optical layer > > > achieves these services is yet to be determined - which as you > > > mention will require standardized interfaces between the various > > > optical components and as well as a standardized API for these > > > services to be requested. > > > > > > My question is what are these services that would be useful > > > for the optical layer to provide and what are the tasks that > > > have to be taken up to enable it? > > > > > > In any case it seems risky to take up a model that requires > > > too much cooperation between the various layers - since that > > > will mean that there will be inter-dependence in the development > > > of that technology. Ofcourse there are others who have more > > > experience on questions like this. > > > > > > > > > > > > > >Point 2: Overlay Model vs. Open > > > > > > > >The connotation that goes typically with the Overlay model > is that the > > > >optical > > > >layer is quasi static and might require N^2 connectivity at the > IP/client > > > >layer. > > > > > > Am afraid I missed the point here. > > > > > > thanks, > > > -jagan. > > > > > > > > > >Hence, I prefer to distinguish the open model from overlay. > > > >Krishna Bala > > > > > > > >> -----Original Message----- > > > >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Jonathan > > > >> Lang > > > >> Sent: Thursday, March 23, 2000 4:55 PM > > > >> To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram > > > >> Cc: Khaled Elsayed; mpls@UU.NET; > > > ip-optical@lists.research.bell-labs.com > > > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > >> > > > >> > > > >> Krishna, > > > >> The Open model seems quite "Closed" to me - the very nature of > clouds > > > >> implies information hiding in my mind. What is exactly meant by > open? > > > >> Also, I'm not sure I agree with your definition of overlay, as > > > many people > > > >> allow the overlay model to encompass both your (2) and (3). > > > >> Furthermore, I > > > >> don't think the Peer Model implies OXCs are "agile but fat & > > > >> dumb" since as > > > >> they are "peers", this would also imply routers are "agile but > > > fat & dumb" > > > >> as well - and at some point, someone needs to have > > > intelligence. I would > > > >> suggest that the Peer model allows both routers and OXCs to > > > interoperate > > > >> intelligently. > > > >> > > > >> Regards, > > > >> Jonathan > > > >> > > > >> -----Original Message----- > > > >> From: Krishna Bala [mailto:kbala@tellium.com] > > > >> Sent: Thursday, March 23, 2000 11:59 AM > > > >> To: curtis@avici.com; Jagan Shantigram > > > >> Cc: Khaled Elsayed; mpls@UU.NET; > > > ip-optical@lists.research.bell-labs.com > > > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > >> > > > >> > > > >> Jagan, > > > >> There are several architectural models for IP over Optical > > > Networks that > > > >> are emerging: > > > >> > > > >> 1. Peer Model > > > >> In this model the IP router is entirely aware of the details on the > > > >> underlying > > > >> optical network (topology information, wavelength and port > > > usage and lamda > > > >> assignment). > > > >> It is able to control and manage entire end to end paths. In this > > > >> model the > > > >> OXC is "agile but fat & dumb". > > > >> 2. Overlay Model > > > >> The optical layer is "fat & dumb". The lamda connections > between the > IP > > > >> routers behave as if they were dedicated fibers between them. The > > > >> IP routes > > > >> provision logical optical circuits over a fixed or at best a > > > quasi-fixed > > > >> optical > > > >> layer. > > > >> 3. Open Model > > > >> In this scenario the optical layer comprises of several > "vendor/network > > > >> operator clouds" > > > >> that have well defined interfaces. For example, an Optical UNI > > > can be used > > > >> to > > > >> interconnect the IP router to the OXC and the Optical NNI can > > > be used to > > > >> connect > > > >> two optical network domains together. Here the optical layer is > > > >> "fat, smart > > > >> and agile". > > > >> > > > >> It is unclear at this time which of these models will prevail. > > > >> > > > >> Krishna Bala > > > >> Tellium > > > >> > > > >> > > > >> > > > >> > -----Original Message----- > > > >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Curtis > > > >> > Villamizar > > > >> > Sent: Thursday, March 23, 2000 1:55 PM > > > >> > To: Jagan Shantigram > > > >> > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > > > >> > ip-optical@lists.research.bell-labs.com > > > >> > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > >> > > > > >> > > > > >> > > > > >> > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > > > >> > Shantigram wr > > > >> > ites: > > > >> > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > >> > > > > > > >> > > >In message <38D76337.478CA5FC@ieee.org>, Khaled > Elsayed writes: > > > >> > > >> > > > >> > > >> > > > >> > > >> Hello Jagan, > > > >> > > >> > > > >> > > >> > When we do not have lambda conversion however, this > > > >> problem cannot > > > >> > > >> > be solved optimally.. it is akin to the graph coloring > > > >> > > >> > problem - which ofcourse has heuristics that can get us to > > > >> > > >> > a factor (?) of the optimal solution. So, connections may > > > >> > > >> > be blocked even though there is capacity on the fiber to > > > >> > > >> > support it, just because the wavelength is > already used up. > > > >> > > >> > > > > >> > > >> > > > >> > > >> Connections can be blocked when?? At service > > > provisioning time or > > > >> > > >> at the time the connection is requested?? My point is a > > > >> > > >> connection of 2.48 Gbps is not likely to be a > random event or > an > > > >> > > >> ATM-like SVC. If a customer would require such huge > > > bandwidth, it > > > >> > > >> would need that BW to go through or it would better look for > > > >> > > >> another carrier that will provide a TDM/leased line?? Of > course > > > >> > > >> wavelength conversion can help build a better-utilized > network, > > > >> > > >> no question about that. > > > >> > > >> > > > >> > > >> Khaled > > > >> > > > > > > >> > > > > > > >> > > >The exception to the rule that "a connection of 2.48 > Gbps is not > > > >> > > >likely to be a random event" is where a very major event, > > > possilble > > > >> > > >external to one's own network results in a shift in > > > traffic patterns > > > >> > > >that is significant enough to require that additional > > > >> lambdas be added > > > >> > > >to existing paths. > > > >> > > > > > > >> > > >The real world example in the ISP world is a failure of a > peering > > > >> > > >point of some sort, a provider interconnect, a NAP or NAP > > > >> connectivity > > > >> > > >of some party. Since all major ISPs are connected to > > > each other at > > > >> > > >more than one geographically diverse peering point, the > > > traffic will > > > >> > > >still flow, but the path will have changed. > > > >> > > > > > > >> > > >This may mean that a path that previously required 3 lambdas > (for > > > >> > > >example), now requires 4 lambdas. There are at least > 3 ways to > > > >> > > >accommodate this requirement: > > > >> > > > > > > >> > > > 1. An external management system adds a lambda to both > > > the routers > > > >> > > > at either end and the optical switches > > > (demonstrated at OFC). > > > >> > > > > > > >> > > > 2. The router signals the requirement/desire for an > additional > > > >> > > > lambda to the adjacent optical switch which sets up a > path. > > > >> > > > This is the overlay model. It can be trivially > > > >> implemented with > > > >> > > > MPLS by having the router send a loose source hop in the > ERO > > > >> > > > allowing the switch to create the path or reject > > > the request. > > > >> > > > > > >> > > Curtis, > > > >> > > > > > >> > > Am trying to understand the model here. Does the overlay model > > > >> > > as you put above imply that the optical devices need to be > > > >> mini-routers > > > >> > > in their own right? They have to be able to set up > > > end-to-end optical > > > >> > > paths.. perhaps some kind of binding between the end-host > > > IP address > > > >> > > and an addressing scheme for Optical devices.. ala ATM? > > > >> > > What does the overlay model entail? > > > >> > > > > >> > The optical devices run the same IGP (ISIS or OSPF) and use RSVP > (or > > > >> > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > > >> > > > > >> > Alternately, the lambdas can be set statically and the > edge router > > > >> > simple advertises a Lambda-Switch Capable link ala > > > >> > draft-kompella-mpls-optical-00.txt (if I understand their intent > wrt > > > >> > accommodating the overlay model). > > > >> > > > > >> > I don't think draft-kompella-mpls-optical-00.txt has all the > details > > > >> > sufficiently ironed out for the case where the optical switch > > > >> > advertises the availability of an optical link. If it does, then > the > > > >> > details ar just not clear to me. (Could be my careless reading). > > > >> > > > > >> > > > 3. The router has enough information about the > > > characteristics of > > > >> > > > the optical devices to compute the path and so it does > > > >> so. This > > > >> > > > is the peer model. > > > >> > > > > > > >> > > > > > >> > > What does this model need.. a protocol for exchanging > information > > > >> > > between the router and the optical device? > > > >> > > > > >> > It needs a means to communicate OOB wrt the primary lightpath. > That > > > >> > means would again be running the IGP and RSVP. Based on reading > the > > > >> > draft-kompella-mpls-optical-00.txt draft, I'm not clear > on how the > > > >> > optical switch exchanges this information OOB although I > > > would imagine > > > >> > that it would be quite easy to maintian another > interface (perhaps > > > >> > even an electrical, though gig-E would do fine) between the > > > router and > > > >> > optical device in which the optical device advertises the optical > > > >> > links. The router on either end of an optical link, seeing or > having > > > >> > set up a Packet-Switch Capable link would then have to > bring up an > > > >> > RSVP adjacency over it, though I think it would not need an IGP > > > >> > adjacency. (I'm not clear on this last point.) > > > >> > > > > >> > The availability of certain types of links > (Packet-Switch Capable, > > > >> > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > > > >> > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. > I'm > > > >> > not clear on whether the adjacent LSR should advertise a > Forwarding > > > >> > Adjacency PSC after RSVP comes up over a set of optical links (it > > > >> > seems to be the intent) but maybe the authors can clarify the > usage. > > > >> > > > > >> > The ongoing discussion and the topic of the (way too numerous) > > > >> > framework documents floating around has been what additional > > > >> > information would be needed in order to provide adequate > constraints > > > >> > to set up optical paths, a particularly difficult problem for > > > >> > transparent paths. > > > >> > > > > >> > > -jagan. > > > >> > > > > > >> > > >The way this might manifest itself is LSPs that might > > > take an optical > > > >> > > >path from A to C are going from A to B to C because A to C > > > >> lambdas are > > > >> > > >too full. If so, then A could in principle request an > additional > > > >> > > >lambda, but in practice the means to signal this has not > > > >> been defined. > > > >> > > > > > > >> > > >Curtis > > > >> > > > > > >> > > Jagannath Shantigram > > > >> > > Photonex Corporation > > > >> > > > > >> > btw- I exchanged some private email with one of the authors of > > > >> > draft-kompella-mpls-optical.txt and owe them some > detailed comments > > > >> > (appologies to them for the delay, busy). After some brief > > > discussion > > > >> > and after a second reading, the intent seems a lot more > clear. The > > > >> > usage material is at the end so when reading the document from > front > > > >> > to back the intent is not clear until the end and then a second > > > >> > reading is required. > > > >> > > > > >> > Curtis > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > Jagannath Shantigram > > > Photonex Corporation > > > > From owner-mpls@UU.NET Mon Apr 3 16:52:48 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24610 for ; Mon, 3 Apr 2000 16:52:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijjf08196; Mon, 3 Apr 2000 20:52:10 GMT Received: by mail-control.mail.uu.net id QQijjf12434 for mpls-outgoing; Mon, 3 Apr 2000 20:51:48 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijjf12427 for ; Mon, 3 Apr 2000 20:51:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijjf24235 for ; Mon, 3 Apr 2000 16:51:30 -0400 (EDT) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQijjf07224 for ; Mon, 3 Apr 2000 20:51:30 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Mon, 3 Apr 2000 16:51:02 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A48CFDA@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: LSPID as ER Hop in TE-MIB Date: Mon, 3 Apr 2000 16:51:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi I'm not sure, but I think there was a discussion about this - having an explicit hop specified as an LSPID - I couldn't find in my mailing list archive Is this going to be supported ?? Let me also add another twist to this - If the ER hop is used to specify the local interface, this kind of an object will allow initiating a "stacked" label. I'm not aware of having any other way of specifying such a thing. Thanx, Andi. From owner-mpls@UU.NET Mon Apr 3 21:48:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01777 for ; Mon, 3 Apr 2000 21:48:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijjz10198; Tue, 4 Apr 2000 01:47:59 GMT Received: by mail-control.mail.uu.net id QQijjz07225 for mpls-outgoing; Tue, 4 Apr 2000 01:47:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijjz07220 for ; Tue, 4 Apr 2000 01:47:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijjz27179 for ; Mon, 3 Apr 2000 21:47:18 -0400 (EDT) Received: from dgesmtp01.wcom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dgesmtp01.wcom.com [199.249.16.16]) id QQijjz09775 for ; Tue, 4 Apr 2000 01:47:18 GMT Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FSG0004OYAT8L@firewall.mcit.com> for mpls@uu.net; Tue, 4 Apr 2000 01:47:17 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0FSG00601YATAH@pmismtp02.wcomnet.com>; Tue, 04 Apr 2000 01:47:17 +0000 (GMT) Received: from omzmta03.mcit.com ([166.37.214.9]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0FSG003HKYASME@pmismtp02.wcomnet.com>; Tue, 04 Apr 2000 01:47:16 +0000 (GMT) Received: from pc9910023938 ([166.44.152.140]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000404014714.CDNF18788@pc9910023938>; Tue, 04 Apr 2000 01:47:14 +0000 Date: Mon, 03 Apr 2000 12:03:39 -0500 From: Lee Thomas Subject: RE: Comments on draft-ip-optical-framework-00.txt In-reply-to: <200003281519.KAA54508@curtis-lt.avici.com> To: curtis@avici.com Cc: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-to: lee.thomas@wcom.com Message-id: <000701bf9dd7$90416ec0$9571fea9@pc9910023938> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, I took vacation all last week and am just now reading this thread so I apologize for harkening back to old mail. Having read through the week's discussion of open, peer and overlays, I like your descriptions the best. As Grenville pointed out, the overlay simply implies an independence and not necessarily an assumption that the underlying is static. I agree with your comments that ATM PVC-based IP backbones are not built as full-mesh networks. I like having the static overlay model identified as this reflects many current network implementations and I like the Signaled Overlay Model as it describes a model that may be implemented as a new network, or a Static Overlay network could be transitioned to a SOM. Similarly, a SOM could be migrated to a Peer model network. The options are there and I think these three model descriptions relate well to current implementations and a number of migration scenarios. Lee -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Curtis Villamizar Sent: Tuesday, March 28, 2000 9:19 AM To: Krishna Bala Cc: Jagan Shantigram; Jonathan Lang; curtis@avici.com; Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In message <00f801bf9843$888c2560$425cc697@tempest>, "Krishna Bala" writes: > Jagan, > Just to beat a dead horse .. the difference between the open model > and the overlay is just that the overlay model typically suggests that > there would be N^2 connectivity (i.e., every router, for instance, is > statically connected to every other). In any case, the open model allows > for fully dynamic operation. The overlay model suggests static operation of > the optical layer. > > As I see it there are only two architectures that are worth considering: > 1. Peer > 2. Open > > I agree with you that there is no need to add the "overlay" model to > this list. The open model covers the static and the dynamic cases. > > Krishna In terms of visibility into the optical layer and control over path selection, the proposals on the talbe can be characterized as follows: 1. Static Overlay Model - paths endpoints are specified through a network management system though the paths may be laid out statically (by the NMS system) or dynamically (by the network elements). This is similar to ATM PVCs and SPVCs. [Note: networks built using the overlay model need not provide a full mesh contrary to misinformation provided on this mailing list. Today ATM PVC based IP backbones are often not built as full mesh networks to reduce the nuber of routing adjacencies.] 2. Signaled Overlay Model (aka "Open" model) - paths endpoints are specified through signaling via a UNI. Paths must be laid out dynamically since they are specified by signaling. This is similar to ATM SVCs. 3. Peer model - The network elements are provided enough information such that they MAY attempt to set up path in addition to specifying their endpoints. Paths may be laid out by the optical elements if the edge LSR provides only a static hop. Paths may be laid out by the LSR. Paths may also be laid out statically by having the NMS system configure explicit paths on the LSR and have those paths signaled. It was my understanding that the MPLS WG traffic engineering work was motivated largely by major Internet service provider's experience with ATM and was making an effort to avoid repeating the mistakes of the ATMF and therfore (among other differences between ATM and MPLS) is interested in the peer model. Note - If the OIF wants to ignore the experience that the Internet community has had with ATM and wants to ignore the feedback through the IETF of people involved in building those networks and and build IP routers with ATM interfaces that were constrained to make use of the interfaces that the ATMF chose to provide (in some cases omiting capabilities over the loud objections within IETF WGs such as IP over ATM) then that is a matter for OIF. If we are putting together a framework, then in addition to the "static overlay model" and "peer model", a distinction should be made and a separate "signaled overlay model" can be provided. In the interest of completelness the framework can point out that the OIF is working on a UNI which is based on the signaled overlay model. I prefer the term "signaled overlay model" over "open model" because the former is descriptive and that latter seems motivated by the desire to use the marketing buzzword "open" rather than provide a descriptive term. Some people had envisioned going directly from static overlay model to peer model or going directly to the peer model with the understanding that the LSR can still be configured with explicit paths from an NMS as long as quantifying and signaling impairments remains slightly beyond the state of the art and determining the impact of optical impairments remains a black art. Curtis From owner-mpls@UU.NET Tue Apr 4 00:04:31 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06422 for ; Tue, 4 Apr 2000 00:04:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijki17717; Tue, 4 Apr 2000 04:03:55 GMT Received: by mail-control.mail.uu.net id QQijki04190 for mpls-outgoing; Tue, 4 Apr 2000 04:03:30 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijki04175 for ; Tue, 4 Apr 2000 04:03:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijki10165 for ; Tue, 4 Apr 2000 00:03:27 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijki17139 for ; Tue, 4 Apr 2000 04:03:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA22882 for mpls@uu.net; Tue, 4 Apr 2000 00:03:26 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijki03803 for ; Tue, 4 Apr 2000 04:03:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijki10125 for ; Tue, 4 Apr 2000 00:03:08 -0400 (EDT) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQijki16835 for ; Tue, 4 Apr 2000 04:03:07 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id HAA26746; Tue, 4 Apr 2000 07:03:01 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14569.26997.850641.44794@lohi.eng.telia.fi> Date: Tue, 4 Apr 2000 07:03:01 +0300 (EEST) To: lee.thomas@wcom.com Cc: curtis@avici.com, mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt In-Reply-To: <000701bf9dd7$90416ec0$9571fea9@pc9910023938> References: <200003281519.KAA54508@curtis-lt.avici.com> <000701bf9dd7$90416ec0$9571fea9@pc9910023938> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lee Thomas writes: > I like having the static overlay model identified as this > reflects many current network implementations and I like the Signaled > Overlay Model as it describes a model that may be implemented as a new > network, or a Static Overlay network could be transitioned to a SOM. opposite of static is not signaled but dynamic. we do all of our ip/atm overlays using signaled svcs between the routers, but the topology is still static. so better names would be static and dynamic overlays. an example of dynamic overlays was documented as ftp://lohi.eng.telia.fi/tmp/draft-ietf-ion-intra-area-unicast-01.txt which unfortunately never got progressed because in the atm world it had a dependency with the ospf ara option. since signaling in mpls is based on ip addresses, the ara thing is not anymore needed and i may respin the i-d for mpls. -- juha From owner-mpls@UU.NET Tue Apr 4 01:33:24 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12441 for ; Tue, 4 Apr 2000 01:33:23 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijko13797; Tue, 4 Apr 2000 05:32:48 GMT Received: by mail-control.mail.uu.net id QQijko20103 for mpls-outgoing; Tue, 4 Apr 2000 05:32:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijko20098 for ; Tue, 4 Apr 2000 05:32:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijko18166 for ; Tue, 4 Apr 2000 01:32:10 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijko12962 for ; Tue, 4 Apr 2000 05:32:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA29865 for mpls@uu.net; Tue, 4 Apr 2000 01:32:09 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijko20080 for ; Tue, 4 Apr 2000 05:31:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijko18114 for ; Tue, 4 Apr 2000 01:31:43 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: inet-tsb.toshiba.co.jp [202.33.96.40]) id QQijko16686 for ; Tue, 4 Apr 2000 05:31:36 GMT Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id OAA11567; Tue, 4 Apr 2000 14:30:56 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id OAA03315; Tue, 4 Apr 2000 14:30:55 +0900 (JST) Received: by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id OAA26336; Tue, 4 Apr 2000 14:30:54 +0900 (JST) To: santoshg@daewoo.dti.daewoo.co.kr Cc: mpls@UU.NET Subject: Re: CR-LDP In-Reply-To: Your message of "Thu, 30 Mar 2000 11:15:15 +0530" <00aa01bf9a0b$20ad2880$100d85a5@dti.daewoo.co.kr> References: <00aa01bf9a0b$20ad2880$100d85a5@dti.daewoo.co.kr> X-Mailer: Mew version 1.92 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004040530.OAA26336@toshiba.co.jp> Date: Tue, 04 Apr 2000 14:11:46 +0900 From: Yoshihiro Ohba X-Dispatcher: imput version 980905(IM100) Lines: 15 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >> I don't think there is any standard draft proposing to distribute >> LSPID information to/from the global entity. But is there a >> situation where the supposed scenario is useful? > This could be useful in the case when lots of traffic is meant for the same > destination. If we make the traffic go thru the same LSP that would reduce > load on the switch as it will have less no. of LSPs in the state > information. This case is the same as "Merging" of LSPs. Then, you may want to use RSVP-TE rather than CR-LDP for that purpose, since RSVP-TE optionally supports merging. Yoshihiro Ohba > Santosh From owner-mpls@UU.NET Tue Apr 4 10:23:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04381 for ; Tue, 4 Apr 2000 10:23:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijlx15121; Tue, 4 Apr 2000 14:22:40 GMT Received: by mail-control.mail.uu.net id QQijlx00605 for mpls-outgoing; Tue, 4 Apr 2000 14:22:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijlx00573 for ; Tue, 4 Apr 2000 14:22:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijlx11941 for ; Tue, 4 Apr 2000 10:21:26 -0400 (EDT) Received: from PMESMTP02.wcom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pmesmtp02.wcom.com [199.249.20.2]) id QQijlx13285 for ; Tue, 4 Apr 2000 14:21:22 GMT Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FSH00CEHX5X8R@firewall.mcit.com> for mpls@UU.NET; Tue, 4 Apr 2000 14:20:26 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0FSH00E01X5X1F@pmismtp02.wcomnet.com>; Tue, 04 Apr 2000 14:20:21 +0000 (GMT) Received: from omzmta01.mcit.com ([166.37.214.7]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0FSH00APYX5WOC@pmismtp02.wcomnet.com>; Tue, 04 Apr 2000 14:20:20 +0000 (GMT) Received: from pc9910023938 ([166.44.153.26]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000404142019.JBCB1523@pc9910023938>; Tue, 04 Apr 2000 14:20:19 +0000 Date: Tue, 04 Apr 2000 09:19:18 -0500 From: Lee Thomas Subject: RE: Comments on draft-ip-optical-framework-00.txt In-reply-to: <14569.26997.850641.44794@lohi.eng.telia.fi> To: "'Juha Heinanen'" Cc: curtis@avici.com, mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-to: lee.thomas@wcom.com Message-id: <000601bf9e40$c3e62a40$0562fea9@pc9910023938> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Juha, > > Lee Thomas writes: > > > I like having the static overlay model identified as this > > reflects many current network implementations and I like > the Signaled > > Overlay Model as it describes a model that may be > implemented as a new > > network, or a Static Overlay network could be transitioned > to a SOM. > > opposite of static is not signaled but dynamic. we do all of > our ip/atm > overlays using signaled svcs between the routers, but the topology is > still static. so better names would be static and dynamic overlays. I agree. > > an example of dynamic overlays was documented as > ftp://lohi.eng.telia.fi/tmp/draft-ietf-ion-intra-area-unicast-01.txt which unfortunately never got progressed because in the atm world it had a dependency with the ospf ara option. since signaling in mpls is based on ip addresses, the ara thing is not anymore needed and i may respin the i-d for mpls. -- juha From owner-mpls@UU.NET Tue Apr 4 10:33:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04735 for ; Tue, 4 Apr 2000 10:33:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijly26816; Tue, 4 Apr 2000 14:31:15 GMT Received: by mail-control.mail.uu.net id QQijly00971 for mpls-outgoing; Tue, 4 Apr 2000 14:30:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijly00938 for ; Tue, 4 Apr 2000 14:30:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijly13506 for ; Tue, 4 Apr 2000 10:30:17 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijly25357 for ; Tue, 4 Apr 2000 14:30:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA01812 for mpls@uu.net; Tue, 4 Apr 2000 10:30:09 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijlx00872 for ; Tue, 4 Apr 2000 14:29:49 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijlx13307 for ; Tue, 4 Apr 2000 10:29:30 -0400 (EDT) Received: from smtprich.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprich.nortel.com [192.135.215.8]) id QQijlx26921 for ; Tue, 4 Apr 2000 14:29:30 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 4 Apr 2000 09:16:52 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2BF05JKX>; Tue, 4 Apr 2000 09:15:46 -0500 Message-ID: From: "Monika Torok" To: "'mpls@UU.NET'" Subject: subscribe Date: Tue, 4 Apr 2000 09:15:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9E40.4506F484" 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_01BF9E40.4506F484 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01BF9E40.4506F484 Content-Type: text/html; charset="iso-8859-1" subscribe

------_=_NextPart_001_01BF9E40.4506F484-- From owner-mpls@UU.NET Tue Apr 4 10:57:47 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05448 for ; Tue, 4 Apr 2000 10:57:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijlz22054; Tue, 4 Apr 2000 14:56:39 GMT Received: by mail-control.mail.uu.net id QQijlz02362 for mpls-outgoing; Tue, 4 Apr 2000 14:56:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijlz02357 for ; Tue, 4 Apr 2000 14:56:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijlz22089 for ; Tue, 4 Apr 2000 10:55:53 -0400 (EDT) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQijlz20781 for ; Tue, 4 Apr 2000 14:55:53 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id KAA07455; Tue, 4 Apr 2000 10:55:50 -0400 (EDT) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA65324; Tue, 4 Apr 2000 10:56:16 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200004041456.KAA65324@curtis-lt.avici.com> To: Juha Heinanen cc: lee.thomas@wcom.com, curtis@avici.com, mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Tue, 04 Apr 2000 07:03:01 +0300." <14569.26997.850641.44794@lohi.eng.telia.fi> Date: Tue, 04 Apr 2000 10:56:16 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <14569.26997.850641.44794@lohi.eng.telia.fi>, Juha Heinanen writes: > Lee Thomas writes: > > > I like having the static overlay model identified as this > > reflects many current network implementations and I like the Signaled > > Overlay Model as it describes a model that may be implemented as a new > > network, or a Static Overlay network could be transitioned to a SOM. > > opposite of static is not signaled but dynamic. we do all of our ip/atm > overlays using signaled svcs between the routers, but the topology is > still static. so better names would be static and dynamic overlays. > > an example of dynamic overlays was documented as > > ftp://lohi.eng.telia.fi/tmp/draft-ietf-ion-intra-area-unicast-01.txt > > which unfortunately never got progressed because in the atm world it had > a dependency with the ospf ara option. since signaling in mpls is based > on ip addresses, the ara thing is not anymore needed and i may respin > the i-d for mpls. > > -- juha We are splitting hairs but please recall that there were three cases: static signaled peer One could argue that the latter two are dynamic and that the peer model is just a bit more dynamic that the signaled model. The PVC style is certainly the most static. Since the first two have limited or no visibility into the underlying topology they are overlay. Juha may have added a fourth case. The following table might help. router's topology type of visibility path setup model name example configured* none static overlay ATM-PVC configured* endpoint signaled overlay ATM-SVC endpoints endpoint dynamic overlay MPLS-loose full full path peer MPLS-strict *configured here means endpoints only are configured in the router. The model Juha proposed is a slight improvement over the pure ATM SVC model in that the endpoints to the ATM are advertised for the purpose of making ATM call setups. This model seems similar to the use of MPLS with a single loose hop in the explicit route. It is similar in that the ingress knows about the endpoint through signaling rather than configuration but leaves it to the next (signaling) hop (which would be an optical device) to figure out how to get there. If the ingress had enough information to compute the path, we'd have the peer model and the ingress would use strict hops in the explicit route. It wouldn't hurt to add the distinction that Juha has pointed out and adapt the term "dynamic overlay" that he suggested. I hope this terminology is clear. We seem to have some growing consensus on these model names. Curtis From owner-mpls@UU.NET Tue Apr 4 12:15:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07732 for ; Tue, 4 Apr 2000 12:15:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijme08140; Tue, 4 Apr 2000 16:14:01 GMT Received: by mail-control.mail.uu.net id QQijme24503 for mpls-outgoing; Tue, 4 Apr 2000 16:13:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijme24494 for ; Tue, 4 Apr 2000 16:13:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijme06827 for ; Tue, 4 Apr 2000 12:13:00 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijme07277 for ; Tue, 4 Apr 2000 16:12:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA17813 for mpls@uu.net; Tue, 4 Apr 2000 12:12:58 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijme24418 for ; Tue, 4 Apr 2000 16:12:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijme06635 for ; Tue, 4 Apr 2000 12:12:08 -0400 (EDT) Received: from gorilla.mchh.siemens.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQijme18929 for ; Tue, 4 Apr 2000 16:12:08 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 SAA09699; Tue, 4 Apr 2000 18:11:04 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA10622; Tue, 4 Apr 2000 18:11:53 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id <22P4D2LA>; Tue, 4 Apr 2000 18:13:16 +0200 Message-ID: From: Hummel Heinrich To: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Tue, 4 Apr 2000 18:13:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Does this discussion (overlay-, peer-model and the reference to IP over ATM) really meet the relation between knowledgable LSRs and not so knowledgable OXCs? Also: I assume, both LSRs as well as OXCs have the same types of addresses: IPv4 and maybe IPv6 addresses. This is different compared with IP over ATM where we have to deal with IP addresses versus AESAs. If the talk is about overlay model, is it a model which uses (at least) a label stack of 2 labels ? Heinrich Hummel Siemens AG > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Tue Apr 4 12:54:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08780 for ; Tue, 4 Apr 2000 12:54:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijmh05651; Tue, 4 Apr 2000 16:53:22 GMT Received: by mail-control.mail.uu.net id QQijmh26798 for mpls-outgoing; Tue, 4 Apr 2000 16:52:51 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijmh26789 for ; Tue, 4 Apr 2000 16:52:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijmh13110 for ; Tue, 4 Apr 2000 12:52:11 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQijmh28839 for ; Tue, 4 Apr 2000 16:52:11 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id MAA15623; Tue, 4 Apr 2000 12:47:01 -0400 Message-ID: <38EA1FD2.6FDB1170@tellium.com> Date: Tue, 04 Apr 2000 13:01:06 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Juha Heinanen , lee.thomas@wcom.com, mpls@UU.NET, ip-optical@lists.research.bell-labs.com, Krishna Bala Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <200004041456.KAA65324@curtis-lt.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis: The dynamic overlay, as suggested, is somewhat close to the intent of what we were calling "open". However, we need to clarify a few things. First is the routing interaction between IP and optical domains. I'm not sure what you mean by "endpoints" in the dynamic overlay case. If you mean ATM endpoints, then the so-called "open" model is different. As Heinrich pointed out in an earlier email, the addressing is the same in IP and optical domains. In the "open" model scenario, there could be routing exchange between the domains (e.g., BGP), so there is really no need to know about optical endpoints corresponding to destinations in the IP domain (but as in the dynamic overlay case, the optical network will take care of routing within). Second, a distinction has to be made between control and data planes. Even if you use the peer model with full exchange of topology etc in the control plane, the connectivity between routers in the data plane is over a pipe in the optical domain. That is, the interior nodes in the optical domain cannot see the IP data or LSPs, and data plane connectivity is still overlay. The establishment of the pipes and management of pipe bandwidth will be similar in each of signalled, dynamic or peer models. Specifically, the end routers are solely responsible for setting up and managing the pipe bandwidth. So, it's perhaps useful to just focus on interface functional requirements (including routing) and not worry too much about the terminology. Regards, Bala Curtis Villamizar wrote: > > > We are splitting hairs but please recall that there were three cases: > > static > signaled > peer > > One could argue that the latter two are dynamic and that the peer > model is just a bit more dynamic that the signaled model. The PVC > style is certainly the most static. > > Since the first two have limited or no visibility into the underlying > topology they are overlay. > > Juha may have added a fourth case. The following table might help. > > router's topology type of > visibility path setup model name example > > configured* none static overlay ATM-PVC > configured* endpoint signaled overlay ATM-SVC > endpoints endpoint dynamic overlay MPLS-loose > full full path peer MPLS-strict > > *configured here means endpoints only are configured in the router. > > The model Juha proposed is a slight improvement over the pure ATM SVC > model in that the endpoints to the ATM are advertised for the purpose > of making ATM call setups. This model seems similar to the use of > MPLS with a single loose hop in the explicit route. It is similar in > that the ingress knows about the endpoint through signaling rather > than configuration but leaves it to the next (signaling) hop (which > would be an optical device) to figure out how to get there. If the > ingress had enough information to compute the path, we'd have the peer > model and the ingress would use strict hops in the explicit route. > > It wouldn't hurt to add the distinction that Juha has pointed out and > adapt the term "dynamic overlay" that he suggested. I hope this > terminology is clear. We seem to have some growing consensus on these > model names. > > Curtis -- 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 From owner-mpls@UU.NET Tue Apr 4 15:50:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14124 for ; Tue, 4 Apr 2000 15:50:15 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijmt09424; Tue, 4 Apr 2000 19:49:24 GMT Received: by mail-control.mail.uu.net id QQijmt01183 for mpls-outgoing; Tue, 4 Apr 2000 19:48:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijmt01178 for ; Tue, 4 Apr 2000 19:48:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijmt16550 for ; Tue, 4 Apr 2000 15:48:27 -0400 (EDT) Received: from ginger.lcs.mit.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQijmt28346 for ; Tue, 4 Apr 2000 19:48:27 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id PAA27522; Tue, 4 Apr 2000 15:48:18 -0400 Date: Tue, 4 Apr 2000 15:48:18 -0400 From: "J. Noel Chiappa" Message-Id: <200004041948.PAA27522@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: Comments on draft-ip-optical-framework-00.txt Cc: ip-optical@lists.research.bell-labs.com, jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Bala Rajagopalan > I'm not sure what you mean by "endpoints" in the dynamic overlay > case. I think he means "border router" (generally exit border router), where the BR is also a participant of some sort in the lower-level network (even if it's purely as a client). > the addressing is the same in IP and optical domains. As is I hope obvious from my earlier (long, sorry) note about abstractions, which names you use is far less important (indeed, unimportant, really) than what representation of the topology you're passing across. > In the "open" model scenario, there could be routing exchange between > the domains (e.g., BGP), so there is really no need to know about > optical endpoints corresponding to destinations in the IP domain (but > as in the dynamic overlay case, the optical network will take care of > routing within). I'm not sure what you meant by this (in part since you used the term "endpoint", of which you just finished saying, above, you didn't know what it meant :-). Even after staring at this for a long time, I can't single out your likely meaning - can you restate it in a bit more detail? (Also, can you please be careful to distinguish between i) "domains" - which in this particular discussion I am thinking of as an area of the network where a particular technology [e.g. optical] is being used - and ii) "layers"/ - which to me implies something about the functional relationship between two different systems, e.g. optical routing and IP routing. I think you're tending to use the same word for both, and it's a bit confusing...) (Can I also be a bit of a nit-picker and point out that no matter what model you're using, there is *some* sort of "routing exchange" between the layers - even if it's a static configuration - since *some* representation of connectivity has to be propogated into the IP layer before it can send traffic. I would assume what you really meant was "a dynamic routing exchange".) > a distinction has to be made between control and data planes. Even if > you use the peer model with full exchange of topology etc in the > control plane, the connectivity between routers in the data plane is > over a pipe in the optical domain. That is, the interior nodes in the > optical domain cannot see the IP data or LSPs True. What's important is i) who is in control of deciding paths, and ii) to the extent that there are two separate entities doing so (e.g. long-haul IP routing, and a local optical path-selection mechanism), what representation of the topology the lower-level entity is propogating to the higher-level one. Note that sometimes the "propogating a represntation" may be implicit; e.g. if the optical nodes are peer participants at the control plane for routing (i.e. operating a common IGP with some non-optical nodes, and it's all one area), that counts as "full topology advertisement" - even though there's no interface where anyone is handing across a full map. Noel From owner-mpls@UU.NET Tue Apr 4 18:57:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19789 for ; Tue, 4 Apr 2000 18:57:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijnf01449; Tue, 4 Apr 2000 22:56:46 GMT Received: by mail-control.mail.uu.net id QQijnf07030 for mpls-outgoing; Tue, 4 Apr 2000 22:56:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijnf07007 for ; Tue, 4 Apr 2000 22:56:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijnf18681 for ; Tue, 4 Apr 2000 18:56:04 -0400 (EDT) Received: from lightera2.lightera.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lightera2.lightera.com [206.86.139.36]) id QQijnf00672 for ; Tue, 4 Apr 2000 22:56:03 GMT Received: by LIGHTERA2 with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Apr 2000 15:56:42 -0700 Message-ID: From: "Bernstein, Greg" To: "'mpls@UU.NET'" Subject: Comments on optical and circuit switching with MPLS Date: Tue, 4 Apr 2000 15:56:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Folks, been following some of the discussions of network abstractions, and various models. The Shared Risk Link Group TLV of Kompella, et. al., is one such abstraction of lower layer properties and provides some interesting examples, and questions. Also looking at both optical and circuit switched examples gives more interesting layering issues. As an example suppose we are given a non-dynamic WDM layer composed of spans and optical add/drop multiplexers (OADMs), i.e., no dynamic switching but where I add/drop wavelengths or bands of wavelengths onto fibers. For each general span, i.e., a chain of WDM links where no lambdas are added or dropped, I can assign a 32 bit "span ID". Every branch point where lambdas are added or dropped can be defined as a new general span (my DWDM friends may not like my loose terminology here) and would be assigned a new 32 bit "span ID". Given that I have a SONET line (the layer about the SONET section layer) that traverses this WDM system on its way from its source to destination, I could assign the shared risk link group (SRLG) TLV to this line by using the list of "span IDs" traversed (note that due to the OADMs a single number may not suffice). So I've just used WDM layer info to set the properties of a SONET layer link (and this information can be used for diverse routing calculations for example). This brings a number of questions to mind. (a) Okay, I've got friends at the WDM layer who can get me this info, who else would really want this information? There are no active switching devices down there to control. A similar situation comes up in applying MPLS more generally to the circuit switched world where much use is made of "fixed" multiplexers. See draft-mannie-mpls-sdh-control-00.txt for examples of the intricate SDH hierarchy. (b) Currently the SRLG of Kompella et. al. is an unordered list of 32 bit numbers. If I made this an ordered list in the above application I would get more topology information concerning the SONET line, basically an abstraction of the WDM path that it takes. Is there a reason why we want this unordered vs. ordered? (c) Being on the same fiber is just one example of the SRLG TLV, we could have fibers in the conduits or conduits in the same right of way. Some of this physical plant information would probably need to be configured. Given that one can't always find a diverse path based on the SRLG lists of the various lines available (example routing SONET paths over SONET line with these SRLG lists) it would be nice to introduce some structure into the 32 bit SRLG number so we could in some way optimize (or at least make better decisions) the diversity of the paths. For example, fiber diverse is most important, conduit of second most importance, etc... (d) So now we go an throw some optical switches into the mix. Now how much info needs to to distributed about the optical layer topology (lots of analog info too?). And who should set up the routes (my nice smart SONET level switch right? but what does he know of power budgets etc...). How much information should the optical switch/DWDM system know about the SONET layer? At the OIF we've be talking about at least end system discovery via J0 snooping. How much does he really want to know? Similar issues would arise in application of MPLS to the circuit switched hierarchy, e.g., would a SONET switch really want to know about DS0 level detail? (e) Seems like a good approach to hierarchy and info sharing across layers is needed... Some of the various documents out there have some of the pieces... Adjacencies, SRLG, bundling, etc.. But not quite the full story yet. For example, what if a node really doesn't want to be bothered with higer layer routing information? Note that sometimes its good to look at the circuit switched examples or the IP and circuit switching examples rather than IP and ATM examples (more hierarchy, very different worlds from the routing point of view, i.e., packet and switched rather than packet and packet). Also, can we use the some of these natural hierarchical switching boundaries to allow for easier configuration of OSPF areas or something like them to allow the networks to scale up in size (think about the circuit switched world and all those T1 and E1 lines that could be configured and managed better...) Greg B. **************************************************************** Dr. Greg M. Bernstein, Senior Scientist Ciena Core Switching Division From owner-mpls@UU.NET Tue Apr 4 19:25:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20438 for ; Tue, 4 Apr 2000 19:25:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijnh27401; Tue, 4 Apr 2000 23:25:08 GMT Received: by mail-control.mail.uu.net id QQijnh17276 for mpls-outgoing; Tue, 4 Apr 2000 23:24:38 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijnh17270 for ; Tue, 4 Apr 2000 23:24:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijnh21757 for ; Tue, 4 Apr 2000 19:24:19 -0400 (EDT) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQijnh27575 for ; Tue, 4 Apr 2000 23:24:19 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id TAA15562; Tue, 4 Apr 2000 19:24:15 -0400 (EDT) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id TAA66125; Tue, 4 Apr 2000 19:24:39 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200004042324.TAA66125@curtis-lt.avici.com> To: Bala Rajagopalan cc: curtis@avici.com, Juha Heinanen , lee.thomas@wcom.com, mpls@UU.NET, ip-optical@lists.research.bell-labs.com, Krishna Bala Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Tue, 04 Apr 2000 13:01:06 EDT." <38EA1FD2.6FDB1170@tellium.com> Date: Tue, 04 Apr 2000 19:24:39 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <38EA1FD2.6FDB1170@tellium.com>, Bala Rajagopalan writes: > Curtis: > > ... So, it's perhaps useful to just focus on > interface functional requirements (including routing) and not > worry too much about the terminology. > > Regards, > > Bala The OIF can continue to work on the "open" model and they can, just like the ATMF before them, ignore issues (like IP routing) that are critical to building IP networks if that is what they are inclined to do. Is so, the outcome may be no more useful than the ATMF vision of a big global ATM network with IP routers and host around the perimeter finding the right path by magic (or by NHRP which doesn't work). In the IETF (not the OIF) we may need terminology to describe a set of proposals that involve using MPLS over optical. If so, the terms below might be appropriate and descriptive and cover the set of (reasonably sane) proposals that have been discussed. btw- By endpoints I do mean endpoints of an ATM VC or endpoints of a PSC in the terminology used in draft-kompella-mpls-optical-00.txt. This does not imply endpoints on the Internet (a pair of hosts) or even customer ingress or egress, just boundaries of an optical region which could be a traffic engineered optical backbone or a traffic engineered regional or metropolitan area that makes up part of a provider's network. Curtis [...] > > Juha may have added a fourth case. The following table might help. > > > > router's topology type of > > visibility path setup model name example > > > > configured* none static overlay ATM-PVC > > configured* endpoint signaled overlay ATM-SVC > > endpoints endpoint dynamic overlay MPLS-loose > > full full path peer MPLS-strict > > > > *configured here means endpoints only are configured in the router. > > > > The model Juha proposed is a slight improvement over the pure ATM SVC > > model in that the endpoints to the ATM are advertised for the purpose > > of making ATM call setups. This model seems similar to the use of > > MPLS with a single loose hop in the explicit route. It is similar in > > that the ingress knows about the endpoint through signaling rather > > than configuration but leaves it to the next (signaling) hop (which > > would be an optical device) to figure out how to get there. If the > > ingress had enough information to compute the path, we'd have the peer > > model and the ingress would use strict hops in the explicit route. > > > > It wouldn't hurt to add the distinction that Juha has pointed out and > > adapt the term "dynamic overlay" that he suggested. I hope this > > terminology is clear. We seem to have some growing consensus on these > > model names. From owner-mpls@UU.NET Tue Apr 4 22:25:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22473 for ; Tue, 4 Apr 2000 22:25:43 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijnt29618; Wed, 5 Apr 2000 02:24:29 GMT Received: by mail-control.mail.uu.net id QQijnt24602 for mpls-outgoing; Wed, 5 Apr 2000 02:24:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijnt24594 for ; Wed, 5 Apr 2000 02:23:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijnt06200 for ; Tue, 4 Apr 2000 22:23:49 -0400 (EDT) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQijnt28708 for ; Wed, 5 Apr 2000 02:23:49 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id WAA23893; Tue, 4 Apr 2000 22:23:45 -0400 (EDT) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id WAA73848; Tue, 4 Apr 2000 22:24:07 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200004050224.WAA73848@curtis-lt.avici.com> To: Hummel Heinrich cc: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Tue, 04 Apr 2000 18:13:17 +0200." Date: Tue, 04 Apr 2000 22:24:07 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Hummel Heinrich w rites: > Does this discussion (overlay-, peer-model and the reference to IP over > ATM) really meet > the relation between knowledgable LSRs and not so knowledgable OXCs? > > Also: I assume, both LSRs as well as OXCs have the same types of addresses: > IPv4 and maybe IPv6 addresses. > This is different compared with IP over ATM where we have to deal with IP > addresses versus AESAs. > If the talk is about overlay model, is it a model which uses (at least) a > label stack of 2 labels ? > > Heinrich Hummel > Siemens AG Talk of overlay is mainly in the context of framework but it may also be handy in time to market products which may not be the ultimate in traffic engineering masterpeices but if they work will prove useful. If the framework and the work that the MPLS WG undertakes provides an easy migration, we'll probably be better off. Either way having some reasonably precise terms should make it easier to discuss the problems and proposed solutions. Curtis From owner-mpls@UU.NET Wed Apr 5 07:35:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08341 for ; Wed, 5 Apr 2000 07:35:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijpe03612; Wed, 5 Apr 2000 11:34:36 GMT Received: by mail-control.mail.uu.net id QQijpe17428 for mpls-outgoing; Wed, 5 Apr 2000 11:34:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijpe17390 for ; Wed, 5 Apr 2000 11:33:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijpe24882 for ; Wed, 5 Apr 2000 07:33:37 -0400 (EDT) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQijpe22845 for ; Wed, 5 Apr 2000 11:33:36 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Apr 2000 12:33:32 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E14061E@monk.datcon.co.uk> From: Adrian Farrel To: "Abes, Andi" , MPLS mailing list Subject: RE: LSPID as ER Hop in TE-MIB Date: Wed, 5 Apr 2000 12:33:14 +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 Andi, Yes, I proposed this (with some suggested ASN.1) on Jan 7th and again requested it on Mar 20th. Tom says that he and the other authors are looking at this point together with some of the other issues that I raised. It has probably got a bit buried under the Flurry of activity around the LSR MIB. Tom, any news? Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Abes, Andi [mailto:aabes@quarrytech.com] >Sent: Monday, April 03, 2000 9:51 PM >To: MPLS mailing list >Subject: LSPID as ER Hop in TE-MIB > > >Hi >I'm not sure, but I think there was a discussion about this - having an >explicit >hop specified as an LSPID - I couldn't find in my mailing list archive >Is this going to be supported ?? > >Let me also add another twist to this - >If the ER hop is used to specify the local interface, this >kind of an object > >will allow initiating a "stacked" label. I'm not aware of >having any other >way of specifying such a thing. > > >Thanx, >Andi. > > From owner-mpls@UU.NET Wed Apr 5 07:47:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08411 for ; Wed, 5 Apr 2000 07:47:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijpe28743; Wed, 5 Apr 2000 11:44:16 GMT Received: by mail-control.mail.uu.net id QQijpe18029 for mpls-outgoing; Wed, 5 Apr 2000 11:43:43 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijpe18016 for ; Wed, 5 Apr 2000 11:43:32 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijpe04309 for ; Wed, 5 Apr 2000 07:43:31 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijpe15124 for ; Wed, 5 Apr 2000 11:43:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA26249 for mpls@uu.net; Wed, 5 Apr 2000 07:43:30 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijpe17996 for ; Wed, 5 Apr 2000 11:43:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijpe04283 for ; Wed, 5 Apr 2000 07:43:05 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQijpe14583 for ; Wed, 5 Apr 2000 11:43:04 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA18075; Wed, 5 Apr 2000 07:42:53 -0400 (EDT) Message-Id: <4.2.2.20000405074042.06d1ca60@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Apr 2000 07:42:16 -0400 To: Adrian Farrel , "Abes, Andi" , MPLS mailing list From: "Thomas D. Nadeau" Subject: RE: LSPID as ER Hop in TE-MIB In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E14061E@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_38570147==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_38570147==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi guys, Yes, Adrian is correct in that it was buried in the flurry of activity around the LSR MIB. Since the LSR MIB's Last Call is finishing shortly, we are giving priority in our tight schedules to trying to resolve the issues related to the LSR. Rest assured that we will be addressing the TE MIB's issues shortly. One thing at a time though. 8) --Tom >Tom says that he and the other authors are looking at this point together >with some of the other issues that I raised. It has probably got a bit >buried under the Flurry of activity around the LSR MIB. > >Tom, any news? > >Regards, >Adrian >-- >Adrian Farrel mailto:af@datcon.co.uk >Network Convergence Group >Data Connection Ltd., Chester, UK >http://www.datcon.co.uk/ >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > >-----Original Message----- > >From: Abes, Andi [mailto:aabes@quarrytech.com] > >Sent: Monday, April 03, 2000 9:51 PM > >To: MPLS mailing list > >Subject: LSPID as ER Hop in TE-MIB > > > > > >Hi > >I'm not sure, but I think there was a discussion about this - having an > >explicit > >hop specified as an LSPID - I couldn't find in my mailing list archive > >Is this going to be supported ?? > > > >Let me also add another twist to this - > >If the ER hop is used to specify the local interface, this > >kind of an object > > > >will allow initiating a "stacked" label. I'm not aware of > >having any other > >way of specifying such a thing. > > > > > >Thanx, > >Andi. > > > > --=====================_38570147==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi guys,

        Yes, Adrian is correct in that it was buried in
the flurry of activity around the LSR MIB. Since the LSR
MIB's Last Call is finishing shortly, we are giving priority
in our tight schedules to trying to resolve the issues
related to the LSR. Rest assured that we will be addressing
the TE MIB's issues shortly. One thing at a time though. 8)

        --Tom

Tom says that he and the other authors are looking at this point together
with some of the other issues that I raised.  It has probably got a bit
buried under the Flurry of activity around the LSR MIB.

Tom, any news?

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


>-----Original Message-----
>From: Abes, Andi [mailto:aabes@quarrytech.com]
>Sent: Monday, April 03, 2000 9:51 PM
>To: MPLS mailing list
>Subject: LSPID as ER Hop in TE-MIB
>
>
>Hi
>I'm not sure, but I think there was a discussion about this - having an
>explicit
>hop specified as an LSPID - I couldn't find in my mailing list archive
>Is this going to be supported ??
>
>Let me also add another twist to this -
>If the ER hop is used to specify the local interface, this
>kind of an object
>
>will allow initiating a "stacked" label. I'm not aware of
>having any other
>way of specifying such a thing.
>
>
>Thanx,
>Andi.
>
>
--=====================_38570147==_.ALT-- From owner-mpls@UU.NET Wed Apr 5 10:29:24 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10706 for ; Wed, 5 Apr 2000 10:29:23 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijpp26073; Wed, 5 Apr 2000 14:27:41 GMT Received: by mail-control.mail.uu.net id QQijpp26393 for mpls-outgoing; Wed, 5 Apr 2000 14:27:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijpp26383 for ; Wed, 5 Apr 2000 14:26:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijpp27907 for ; Wed, 5 Apr 2000 10:26:32 -0400 (EDT) Received: from smtp1.cluster.oleane.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.cluster.oleane.net [195.25.12.16]) id QQijpp00237 for ; Wed, 5 Apr 2000 14:26:31 GMT Received: from oleane (dyn-1-1-004.Vin.dialup.oleane.fr [195.25.4.4]) by smtp1.cluster.oleane.net with SMTP id QAA80123; Wed, 5 Apr 2000 16:25:57 +0200 (CEST) Message-ID: <013b01bf9f0a$359af3e0$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP Based Cellular Networks Conference Date: Wed, 5 Apr 2000 16:21:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0138_01BF9F1A.F13F8060" 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_0138_01BF9F1A.F13F8060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP Based Cellular Networks Conference.=20 A scientific committe composed of the most eminent experts in this = technology will review the abstracts submitted from the Call For Papers: http://www.upperside.fr/baipcn.htm =20 ------=_NextPart_000_0138_01BF9F1A.F13F8060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IP Based Cellular Networks = Conference.=20
A scientific committe composed of = the most=20 eminent experts in this technology will review the abstracts submitted = from the=20 Call For Papers:
http://www.upperside.fr/baipc= n.htm
 
 
------=_NextPart_000_0138_01BF9F1A.F13F8060-- From owner-mpls@UU.NET Wed Apr 5 11:37:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11779 for ; Wed, 5 Apr 2000 11:37:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijpu09400; Wed, 5 Apr 2000 15:35:29 GMT Received: by mail-control.mail.uu.net id QQijpu08520 for mpls-outgoing; Wed, 5 Apr 2000 15:35:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijpu08515 for ; Wed, 5 Apr 2000 15:35:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijpu00860 for ; Wed, 5 Apr 2000 11:34:58 -0400 (EDT) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQijpu15400 for ; Wed, 5 Apr 2000 15:34:57 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Wed, 5 Apr 2000 09:18:23 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2HZJ76XW; Wed, 5 Apr 2000 10:17:12 -0400 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNNLV9BB; Wed, 5 Apr 2000 10:17:13 -0400 Message-ID: <38EB4AE9.3C2C8B8B@americasm01.nt.com> Date: Wed, 05 Apr 2000 10:17:13 -0400 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: MPLS mailing list Subject: Any more comments on draft-ietf-mpls-te-feed-00.txt? References: <4.2.2.20000405074042.06d1ca60@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit RE: draft-ietf-mpls-te-feed-00 Still looking for feedback on the feedback draft ... pun intended. I will be asking the WG chairs for a last call on this in the next few days unless somebody has some issues with it. Cheers Peter Ashwood-Smith From owner-mpls@UU.NET Wed Apr 5 15:27:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15285 for ; Wed, 5 Apr 2000 15:27:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijqj12339; Wed, 5 Apr 2000 19:24:40 GMT Received: by mail-control.mail.uu.net id QQijqj22696 for mpls-outgoing; Wed, 5 Apr 2000 19:24:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijqj22691 for ; Wed, 5 Apr 2000 19:24:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijqj25673 for ; Wed, 5 Apr 2000 15:23:49 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijqj05436 for ; Wed, 5 Apr 2000 19:23:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA28604 for mpls@uu.net; Wed, 5 Apr 2000 15:23:47 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijqj22654 for ; Wed, 5 Apr 2000 19:23:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijqj11715 for ; Wed, 5 Apr 2000 15:23:07 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQijqj04908 for ; Wed, 5 Apr 2000 19:23:07 GMT Received: from tnadeau-pc02 (ch2-dhcp134-185.cisco.com [161.44.134.185]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA08984; Wed, 5 Apr 2000 15:23:00 -0400 (EDT) Message-Id: <4.2.2.20000405151705.07236620@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Apr 2000 15:22:32 -0400 To: "Cucchiara, Joan" From: "Thomas D. Nadeau" Subject: RE: LSR MIB comments and questions Cc: "'mpls@uu.net'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F8FC@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18711394==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_18711394==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Sorry about the delay in response. It was a long flight back from Adelaide! ;) > > >I also question why this extra variable is required to > > >convey the label space membership attributes. > > > > > >If mplsInterfaceConfIndex is zero, then it uneqivocally > > >has the attributes 'in global label space' and 'not in > > >local label space'. > > > > > >If mplsInterfaceConfIndex is non-zero, that it uneqivocally > > >has the attribute 'in local label space' and the 'in > > >global label space' variable arbitrates that (optional) > > >attribute. > > > > Yes, but there are cases in ATM where an interface needs > > to be part of both label spaces. This is why we have > > provided two separate variables here. > >The combination of the index and ONE of these >objects would (I think) allow all combinations. For example, Yes, that is true, although it implicitly notes which interfaces are per-interface and which are per-platform. Our intention was to be explicit about this. The reason is that if you use the implicit version, it is unclear as to how the implementation should note the label ranges. We do agree however, that changing the names to IsPerPlatformLabelSpace and IsPerIfLabelSpace is a great idea as it makes this consistent with the architecture. --Tom --=====================_18711394==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

        Sorry about the delay in response. It was  a
long flight back from Adelaide! ;)


> >I also question why this extra variable is required to
> >convey the label space membership attributes.
> >
> >If  mplsInterfaceConfIndex is zero, then it uneqivocally
> >has the attributes 'in global label space' and 'not in
> >local label space'.
> >
> >If mplsInterfaceConfIndex is non-zero, that it uneqivocally
> >has the attribute 'in local label space' and the 'in
> >global label space' variable arbitrates that (optional)
> >attribute.
>
>          Yes, but there are cases in ATM where an interface needs
> to be part of both label spaces. This is why we have
> provided two separate variables here.

The combination of the index and ONE of these
objects would (I think) allow all combinations.  For example,

        Yes, that is true, although it implicitly notes
which interfaces are per-interface and which are per-platform.
Our intention was to be explicit about this. The reason is
that if you use the implicit version, it is unclear as to
how the implementation should note the label ranges. We do
agree however, that changing the names to IsPerPlatformLabelSpace
and IsPerIfLabelSpace is a great idea as it makes this consistent
with the architecture.

        --Tom

--=====================_18711394==_.ALT-- From owner-mpls@UU.NET Wed Apr 5 16:53:12 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16342 for ; Wed, 5 Apr 2000 16:53:11 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijqp29585; Wed, 5 Apr 2000 20:50:39 GMT Received: by mail-control.mail.uu.net id QQijqp05583 for mpls-outgoing; Wed, 5 Apr 2000 20:50:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijqp05575 for ; Wed, 5 Apr 2000 20:50:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijqp29096 for ; Wed, 5 Apr 2000 16:49:58 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijqp28984 for ; Wed, 5 Apr 2000 20:49:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA11938 for mpls@uu.net; Wed, 5 Apr 2000 16:49:52 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijqp05505 for ; Wed, 5 Apr 2000 20:49:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijqp29020 for ; Wed, 5 Apr 2000 16:49:11 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQijqp18133 for ; Wed, 5 Apr 2000 20:49:10 GMT Received: from tnadeau-pc02 (ch2-dhcp134-185.cisco.com [161.44.134.185]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19592; Wed, 5 Apr 2000 16:49:04 -0400 (EDT) Message-Id: <4.2.2.20000405152811.0722b430@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Apr 2000 16:17:26 -0400 To: "Cucchiara, Joan" , "'Arun Viswanathan'" , "Cucchiara, Joan" , "'cheenu@tachion.com'" From: "Thomas D. Nadeau" Subject: RE: Additional comments on the LSR MIB Cc: "'mpls@uu.net'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F8E9@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23862143==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_23862143==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, > > > * The mplsLabelStackTable should be made optional for LDP LSPs > > > which use ATM or FR. Could this be added in > > > the conformance section? > > > > It already supports non-stackable environments. > >That is not really the issue, the issue is why does >LDP using ATM or FR need to support this table? > >It is some amount of overhead and no help whatsoever >for this case. Also, the concept of having to support >a LabelStack in these cases is misleading. This >should be made optional. The labelstack table is optional in the LSR MIB. It is not specified in the conformance statement. > > > * mplsTSpecIndexNext should start at zero. > > > > See description of mplsTSpecIndexNext. > >DESCRIPTION says: > >"...The value 0 indicates that no unassigned entries >are available...." > >The SYNTAX clause starts at 1 and it should start at 0. Fixed. > > > * mplsTSpecMeanRate -- what is the agent or mpls > > > supposed to do with this value? > > > > > > Is the mean rate for an LSP calculated over time? > > > > No. This is one of the tuple for defining a token bucket. > > The agent has to ensure that the specified QoS requirement > > for the LSP is met. > > > > > > > > * mplsTSpecMaxRate and mplsTSpecMaxBurstSize: are > > > these objects related? If so, could an explanation > > > be given of how they are related? Can the BurstSize > > > exceed the MaxRate? What does it mean if this happens? > > > > See above comments. > > > > > > > > * Is this table going to be made optional for LDP? > > > > See my comments to your previous set of comments. > >Which ones? The tSpec table is not mandatory in the LSR MIB. > > > * Could we have a description of what happens when the > > > InSegment TSpec values are lower than the OutSegment > > > TSpec values? (Seems like there should be some > > > co-operation between the objects, or at least some > > > "actual" objects which reflect what the true values > > > are.) > > > > The implication of such things may be platform specific. > >I completely agree which is why I suggest adding "actual" >objects to see what the "real" values are. > >Just because something is configured does not mean that >those are the actual rates/burst size. We patterned this after how it is implemented in the AToM MIB. In that MIB it is widely accepted that this value may or may not reflect that actual value, but just the configured value. Furthermore, if you wish to incorporate more sophisticated TSpec functionality, we have agreed in an earlier thread to provide a RowPointer such that you may point this to an external TSpec which may suit your implementation's needs more closely. > > > Why does one need to specify the TSpec for the > > > InSegment? It would seem that the OutSegment is > > > relevant and that the InSegment is not really > > > configurable, could you explain why it is needed > > > for the InSegment? > > > > Multipoint-to-point LSPs. > >That still doesn't explain what it means to configure >values for an InSegment and how it relates to the OutSegment >which could have different (i.e. higher values). > >Could an explanation be added for the situations where the >OutSegment is lower than the InSegment and vice versa? It really depends on the implementation. Those objects were designed to allow the maximum amount of flexibility for the implementation. For example, one implementation may allow different in/out segment bw configurations and will mark traffic in-coming on higher-bw in-segments before forwarding to lower-bw out-segments. On the other hand, some implementations may choose to drop those packets and not forward them at all. This is why we do not want to be more specify here. > > > OBJECT mplsInSegmentAddrFamily > > > SYNTAX INTEGER { other(0) } > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required. A value of > > > other(0) should be supported." > > > > > > If the agent can't tell or doesn't know what the Address Family > > > is, then how are all the counters effected (specifically > > > packet and octet counters) that are related to this > > > InSegment on an MPLS Interface? > > > > Addr family if for the MPLS payload. Counters are for MPLS 'frames'. > > MPLS counters may go up independent of payload type. > >The only time that other(0) would be valid is when the >value is not one of the other AddressFamily types. The >way this Conformance Info is written leads me to believe >that "other" is being used to mean something different. > >What does the value of "other" in this context mean? I changed the description to the following: "Write access is not required. A value of other(0) should be supported because there may be cases where the agent may not know about or support any of the other address types." --Tom >Thanks, Joan > > > > > > > > > > > OBJECT mplsOutSegmentIndexNext > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required." > > > > > > OBJECT mplsXCIndexNext > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required." > > > > > > OBJECT mplsXCLabelStackIndexNext > > > MIN-ACCESS read-only > > > DESCRIPTION > > > "Write access is not required." > > > > > > The above already have a MAX-ACCESS of read-only. > > > > > > > > > > > > -arun > > > --=====================_23862143==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

> > * The mplsLabelStackTable should be made optional for LDP LSPs
> >   which use ATM or FR.  Could this be added in
> >   the conformance section?
>
> It already supports non-stackable environments.

That is not really the issue, the issue is why does
LDP using ATM or FR need to support this table?

It is some amount of overhead and no help whatsoever
for this case.  Also, the concept of having to support
a LabelStack in these cases is misleading.  This
should be made optional.

        The labelstack table is optional in the LSR MIB. It
is not specified in the conformance statement.


> > * mplsTSpecIndexNext should start at zero.
>
> See description of mplsTSpecIndexNext.

DESCRIPTION says:

"...The value 0 indicates that no unassigned entries
are available...."

The SYNTAX clause starts at 1 and it should start at 0.

        Fixed.


> > * mplsTSpecMeanRate -- what is the agent or mpls
> >   supposed to do with this value? 
> >
> >   Is the mean rate for an LSP calculated over time?
>
> No. This is one of the tuple for defining a token bucket.
> The agent has to ensure that the specified QoS requirement
> for the LSP is met.
>
> >
> > * mplsTSpecMaxRate and mplsTSpecMaxBurstSize:  are
> >   these objects related?  If so, could an explanation
> >   be given of how they are related?  Can the BurstSize
> >   exceed the MaxRate?  What does it mean if this happens?
>
> See above comments.
>
> >
> > * Is this table going to be made optional for LDP?
>
> See my comments to your previous set of comments.

Which ones?


        The tSpec table is not mandatory in the LSR MIB.


> > * Could we have a description of what happens when the
> >   InSegment TSpec values are lower than the OutSegment
> >   TSpec values?  (Seems like there should be some
> >   co-operation between the objects, or at least some
> >   "actual" objects which reflect what the true values
> >   are.)
>
> The implication of such things may be platform specific.

I completely agree which is why I suggest adding "actual"
objects to see what the "real" values are.

Just because something is configured does not mean that
those are the actual rates/burst size.

        We patterned this after how it is implemented in the
AToM MIB. In that MIB it is widely accepted that this value
may or may not reflect that actual value, but just the
configured value. Furthermore, if you wish to incorporate
more sophisticated TSpec functionality, we have agreed in
an earlier thread to provide a RowPointer such that you may
point this to an external TSpec which may suit your
implementation's needs more closely.

> >   Why does one need to specify the TSpec for the
> >   InSegment?  It would seem that the OutSegment is
> >   relevant and that the InSegment is not really
> >   configurable, could you explain why it is needed
> >   for the InSegment?
>
> Multipoint-to-point LSPs.

That still doesn't explain what it means to configure
values for an InSegment and how it relates to the OutSegment
which could have different (i.e. higher values).

Could an explanation be added for the situations where the
OutSegment is lower than the InSegment and vice versa?

        It really depends on the implementation. Those objects
were designed to allow the maximum amount of flexibility
for the implementation. For example, one implementation may
allow different in/out segment bw configurations and will mark
traffic in-coming on higher-bw in-segments before forwarding
to lower-bw out-segments. On the other hand, some implementations
may choose to drop those packets and not forward them at all.
This is why we do not want to be more specify here.

> >       OBJECT      mplsInSegmentAddrFamily
> >       SYNTAX      INTEGER { other(0) }
> >       MIN-ACCESS  read-only
> >       DESCRIPTION
> >           "Write access is not required.  A value of
> >            other(0) should be supported."
> >
> > If the agent can't tell or doesn't know what the Address Family
> > is, then how are all the counters effected (specifically
> > packet and octet counters) that are related to this
> > InSegment on an MPLS Interface? 
>
> Addr family if for the MPLS payload. Counters are for MPLS 'frames'.
> MPLS counters may go up independent of payload type.

The only time that other(0) would be valid is when the
value is not one of the other AddressFamily types.  The
way this Conformance Info is written leads me to believe
that "other" is being used to mean something different.

What does the value of "other" in this context mean?

        I changed the description to the following:

        "Write access is not required.  A value of other(0) should be
supported because there may be cases where the agent may not know about
or support any of the other address types."

        --Tom




Thanks, Joan



>
> >
> >       OBJECT mplsOutSegmentIndexNext
> >       MIN-ACCESS    read-only
> >       DESCRIPTION
> >           "Write access is not required."
> >
> >       OBJECT mplsXCIndexNext
> >       MIN-ACCESS    read-only
> >       DESCRIPTION
> >           "Write access is not required."
> >
> >       OBJECT mplsXCLabelStackIndexNext
> >       MIN-ACCESS    read-only
> >       DESCRIPTION
> >           "Write access is not required."
> >
> > The above already have a MAX-ACCESS of read-only.
> >
> >
>
>
> -arun
>

--=====================_23862143==_.ALT-- From owner-mpls@UU.NET Wed Apr 5 16:54:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16357 for ; Wed, 5 Apr 2000 16:54:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijqp20082; Wed, 5 Apr 2000 20:51:15 GMT Received: by mail-control.mail.uu.net id QQijqp05613 for mpls-outgoing; Wed, 5 Apr 2000 20:50:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijqp05605 for ; Wed, 5 Apr 2000 20:50:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijqp29133 for ; Wed, 5 Apr 2000 16:50:11 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijqp29158 for ; Wed, 5 Apr 2000 20:50:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA12010 for mpls@uu.net; Wed, 5 Apr 2000 16:50:10 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijqp05484 for ; Wed, 5 Apr 2000 20:49:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijqp14785 for ; Wed, 5 Apr 2000 16:49:09 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQijqp18105 for ; Wed, 5 Apr 2000 20:49:08 GMT Received: from tnadeau-pc02 (ch2-dhcp134-185.cisco.com [161.44.134.185]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19560; Wed, 5 Apr 2000 16:48:56 -0400 (EDT) Message-Id: <4.2.2.20000405154620.06511f00@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Apr 2000 16:48:14 -0400 To: "Cucchiara, Joan" , "'Arun Viswanathan'" , "Cucchiara, Joan" , "'cheenu@tachion.com'" From: "Thomas D. Nadeau" Subject: RE: LSR MIB comments and questions Cc: "'mpls@uu.net'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F8E8@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23854838==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_23854838==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, > > > * mplsInSegmentXCIndex description is incorrect. A value > > > of zero could certainly indicates a valid cross connect. > > > The XC table does model XCs even for terminating InSegments > > > and Originating OutSegments. > > > > > > The syntax clause should be changed in either this > > > table or in the XC table since the syntax should be > > > the same in both places. > > > > We meant it to be this way, that is, 0 is not a valid > > XC index. 0 is used to indicate that the XC entries > > have exhausted. > > >Currently, mplsInSegmentXCIndex has: > >SYNTAX Integer32(1..2147483647) >DESCRIPTION > "The index into mplsXCTable is used to identify which > cross-connect entry this segment is part of. Note > that a value of zero indicates that it is not being > referred to by any cross-connect entry." >DEFVAL {0} > >Could this object be made a RowPointer? Why do you want this to be a RowPointer? I think that doing so would unnecessarily complicate the indexing for the agent, so we would like to leave it as is. > > > * mplsInSegmentTSpecIndex -- this object needs to be made > > > optional for LDP. > > > > Is already optional. A value of zero to indicate best effort. > > See description. > >Why is it necessary for an LDP only implementation to >support this? It is not necessary. Although an implementation must implement this value, it can certainly return 0. > > > * mplsInSegmentOwner -- could this be removed from the > > > table. > > > > > > These object are of little value in my opinion because > > > who really cares how the row got created? > > > > > > Also, if you have snmp and policyAgent, then you should > > > add cli, config file, web, etc.... > > > > > > Just seems to be a big rat hole in my opinion. > > > > If you don't want to identify yourself, you can choose the > > 'other' option ;-) > > > > It is there because folks asked for it. It provides > > tracking for usage information, for troubleshooting, > > and erroneous deletion by somebody how did not create > > it in the first place. > >Are you planning on specifying in the enum the >other possibilities (cli, config file, web, etc...)? No. >Also, why is policyAgent one of the choices, this is >a MIB and it was my understanding that policyAgent's used >PIBs. PolicyAgents can't support RowStatus, so I believe >that choice should be removed. The PIB may not support RowStatus, but the agent which interacts with the PIB/PolicyAgent may create an entry. It is our intent for this enumeration to note this case. > > > * mplsOutSegmentIndexNext object range should start at 0 (zero). > > > > No. 0 is bad index; is used to identify terminating connections > > in the cross-connect. > >The description for this object says: >"If the number of unassigned entries is exhausted, >this object will take on the value of 0...." > >But the SYNTAX starts at 1, I believe that the SYNTAX should >start at 0. Good catch. Fixed. > > A label swapping is modelled as a pop followed by a push. > > See mplsInSegmentNPop. The description also talks about > > the ATM case. > > > > > > > > Could you rephrase this section to specifically > > > call out that for Version 1 of LDP using ATM or FR this should > > > be set to true and Reference Section 5. of the LDP Spec? > > > > I don't think we need to specially qualify LDP for this. This > > is common to any protocol on ATM. > >I think that if you expect that people support this MIB >for LDP then you should be more accomodating. I'm only >asking for a clarifying description and reference to be >added. Sure. How does this sound: The number of labels to pop from the incoming packet. Normally only the top label is popped from the packet and used for all switching decisions for that packet. Note that technologies which do not support label popping should set this value to its default value of 1. > > > * mplsOutSegmentTopLabel > > > > > > Could this object be changed to contain the value of > > > the top label on egress? I think it would be > > > much more interesting to point to the egress label > > > especially since the prior object (mplsOutSegmentPushTopLabel) > > > tells whether or not this was pushed. > > > > > > Hmm..I guess I don't understand the comment. > > It already is what you are asking it to be. > >Sorry, my mistake. I think the name confused me, >would you consider a name change to mplsOutSegmentLabel? I think that mpslOutSegmentTopLabel is more specific. I modified the description a bit to make it (hopefully) be more explicit: If mplsOutSegmentPushTopLabel is true then this represents the label that should be pushed onto the top of the outgoing packet's label stack. Note that the contents of the label field can be interpreted in an outgoing interface-specific fashion. For example, the label carried in the MPLS shim header is 20 bits wide and the top 12 bits must be zero. The Frame Relay label is 24 bits wide and the top 8 bits must be zero. For ATM interfaces the lowermost 16 bits are interpreted as the VCI, the next 8 bits as the VPI and the remaining bits must be zero. >I know that we discussed this before and the reason >that you gave was that the MIB had been this way since >Feb 1999, but I am still confused as to why you >believe the indexing of this table to be better >than (mplsOutSegmentIfIndex, mplsOutSegmentLabel) This won't work for the case where we want to pop the top label and forward the packet with whatever label is underneath, without knowing or wanting to know the underlying labels. > > > * mplsXCIndexNext object's range should start at 0. > > > > It is alright the way it is. 0 is reserved to indicate > > "no more cross-connect entries available". > >I agree but the SYNTAX clause starts at 1 and should >start at 0. Good catch. Fixed. > > > * INDEX clause and description of the entry: > > > > > > The description redefines what a values of zero means > > > for the mplsInSegmentIfIndex and mplsInSegmentLabel; > > > in the mplsInSegmentTable they mean one thing, > > > and yet, they mean something else in the XC table. > > > > > > > Yes, they are different tables. > > Index zero is valid only for the InSegemntTable. > >They may be different tables but they are the same indices, >so they should be used the same everywhere they are referenced. >It is not acceptable to redefine what a value means just because >they are in different tables. The index's definition is meaningful within the context of each table. We went to great lengths to make the meaning within each context explicit. > > > * What do the AdminStatus and OperStatus objects mean when > > > the LSP is terminating or Originating for this entry? > > > > > > > Admin status is provided to control the cross-connect from > > passing data. Oper status may reflect the overall health of > > the cross-connect, for example, if the outgoing interface is > > down, then the cross-connect oper status may reflect that. > >But what do they mean in the case of a terminating or originating >LSP which is in the XC table? >If AdminStatus is down, what does this imply for a terminating LSP? >Could the description be clarified to call this out, because this >is something which could be interpretted differently by different >vendors and needs to be clarified. This means that the LSP should not forward packets. We have updated section 7.0 Brief Description of MIB Objects, to add some additional text explaining this more explicitly. --Tom --=====================_23854838==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

> > * mplsInSegmentXCIndex description is incorrect.  A value
> >   of zero could certainly indicates a valid cross connect.
> >   The XC table does model XCs even for terminating InSegments
> >   and Originating OutSegments.
> >
> >   The syntax clause should be changed in either this
> >   table or in the XC table since the syntax should be
> >   the same in both places.
>
> We meant it to be this way, that is, 0 is not a valid
> XC index. 0 is used to indicate that the XC entries
> have exhausted.


Currently, mplsInSegmentXCIndex has:

SYNTAX  Integer32(1..2147483647)
DESCRIPTION 
   "The index into mplsXCTable is used to identify which
   cross-connect entry this segment is part of.  Note
   that a value of zero indicates that it is not being
   referred to by any cross-connect entry."
DEFVAL {0}

Could this object be made a RowPointer?

        Why do you want this to be a RowPointer? I think
that doing so would unnecessarily complicate the indexing
for the agent, so we would like to leave it as is.

> > * mplsInSegmentTSpecIndex -- this object needs to be made
> >   optional for LDP.
>
> Is already optional. A value of zero to indicate best effort.
> See description.

Why is it necessary for an LDP only implementation to
support this?

        It is not necessary. Although an implementation
must implement this value, it can certainly return 0.

> > * mplsInSegmentOwner -- could this be removed from the
> >   table. 
> >
> >   These object are of little value in my opinion because
> >   who really cares how the row got created?
> >
> >   Also, if you have snmp and policyAgent, then you should
> >   add cli, config file, web, etc....
> >
> >   Just seems to be a big rat hole in my opinion.
>
> If you don't want to identify yourself, you can choose the
> 'other' option ;-)
>
> It is there because folks asked for it. It provides
> tracking for usage information, for troubleshooting,
> and erroneous deletion by somebody how did not create
> it in the first place.

Are you planning on specifying in the enum the
other possibilities (cli, config file, web, etc...)?

        No.

Also, why is policyAgent one of the choices, this is
a MIB and it was my understanding that policyAgent's used
PIBs.  PolicyAgents can't support RowStatus, so I believe
that choice should be removed.

        The PIB may not support RowStatus, but the agent which
interacts with the PIB/PolicyAgent may create an entry. It
is our intent for this enumeration to note this case.

> > * mplsOutSegmentIndexNext object range should start at 0 (zero).
>
> No. 0 is bad index; is used to identify terminating connections
> in the cross-connect.

The description for this object says:
"If the number of unassigned entries is exhausted,
this object will take on the value of 0...."

But the SYNTAX starts at 1, I believe that the SYNTAX should
start at 0.

        Good catch. Fixed.

> A label swapping is modelled as a pop followed by a push.
> See mplsInSegmentNPop. The description also talks about
> the ATM case.
>
> >
> >   Could you rephrase this section to specifically
> >   call out that for Version 1 of LDP using ATM or FR this should
> >   be set to true and Reference Section 5. of the LDP Spec?
>
> I don't think we need to specially qualify LDP for this. This
> is common to any protocol on ATM.

I think that if you expect that people support this MIB
for LDP then you should be more accomodating.  I'm only
asking for a clarifying description and reference to be
added.

        Sure. How does this sound:

The number of labels to pop from the incoming packet.  Normally only the top label is popped from the packet and used for all switching decisions for that packet. Note that technologies which do not support label popping should set this value to its default value of 1.           


> > * mplsOutSegmentTopLabel
> > 
> >   Could this object be changed to contain the value of
> >   the top label on egress?  I think it would be
> >   much more interesting to point to the egress label
> >   especially since the prior object (mplsOutSegmentPushTopLabel)
> >   tells whether or not this was pushed.
>
>
> Hmm..I guess I don't understand the comment.
> It already is what you are asking it to be.

Sorry, my mistake.  I think the name confused me,
would you consider a name change to mplsOutSegmentLabel?

        I think that mpslOutSegmentTopLabel is more
specific. I modified the description a bit to make it (hopefully)
be more explicit:

If mplsOutSegmentPushTopLabel is true then this represents the label that should be pushed onto the top of the outgoing packet's label stack. Note that the contents of the label field can be interpreted in an outgoing interface-specific fashion.  For example, the label carried in the MPLS shim header is 20 bits wide and the top 12 bits must be zero. The Frame Relay label is 24 bits wide and the top 8 bits must be zero.  For ATM interfaces the lowermost 16 bits are interpreted as the VCI, the next 8 bits as the VPI and the remaining bits must be zero.

I know that we discussed this before and the reason
that you gave was that the MIB had been this way since
Feb 1999, but I am still confused as to why you
believe the indexing of this table to be better
than (mplsOutSegmentIfIndex, mplsOutSegmentLabel)

This won't work for the case where we want to pop the top label and
forward the packet with whatever label is underneath, without knowing
or wanting to know the underlying labels.

> > * mplsXCIndexNext object's range should start at 0.
>
> It is alright the way it is. 0 is reserved to indicate
> "no more cross-connect entries available".

I agree but the SYNTAX clause starts at 1 and should
start at 0.

        Good catch. Fixed.

> > * INDEX clause and description of the entry:
> >
> >   The description redefines what a values of zero means
> >   for the mplsInSegmentIfIndex and mplsInSegmentLabel;
> >   in the mplsInSegmentTable they mean one thing,
> >   and yet, they mean something  else in the XC table. 
> >
>
> Yes, they are different tables.
> Index zero is valid only for the InSegemntTable.

They may be different tables but they are the same indices,
so they should be used the same everywhere they are referenced.
It is not acceptable to redefine what a value means just because
they are in different tables.

        The index's definition is meaningful within the
context of each table. We went to great lengths to
make the meaning within each context explicit.

> > *  What do the AdminStatus and OperStatus objects mean when
> >    the LSP is terminating or Originating for this entry?
> >
>
> Admin status is provided to control the cross-connect from
> passing data. Oper status may reflect the overall health of
> the cross-connect, for example, if the outgoing interface is
> down, then the cross-connect oper status may reflect that.

But what do they mean in the case of a terminating or originating
LSP which is in the XC table?
If AdminStatus is down, what does this imply for a terminating LSP?
Could the description be clarified to call this out, because this
is something which could be interpretted differently by different
vendors and needs to be clarified.

        This means that the LSP should not forward packets.
We have updated section 7.0 Brief Description of MIB Objects,
to add some additional text explaining this more explicitly.

        --Tom

--=====================_23854838==_.ALT-- From owner-mpls@UU.NET Wed Apr 5 17:01:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16476 for ; Wed, 5 Apr 2000 17:01:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijqp27318; Wed, 5 Apr 2000 20:58:47 GMT Received: by mail-control.mail.uu.net id QQijqp06245 for mpls-outgoing; Wed, 5 Apr 2000 20:58:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijqp06240 for ; Wed, 5 Apr 2000 20:58:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijqp00414 for ; Wed, 5 Apr 2000 16:58:06 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijqp06702 for ; Wed, 5 Apr 2000 20:58:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA13737 for mpls@uu.net; Wed, 5 Apr 2000 16:58:05 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijqp06219 for ; Wed, 5 Apr 2000 20:57:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijqp16037 for ; Wed, 5 Apr 2000 16:57:29 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQijqp25855 for ; Wed, 5 Apr 2000 20:57:29 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Apr 2000 16:57:33 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F95F@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Thomas D. Nadeau'" , "Cucchiara, Joan" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Wed, 5 Apr 2000 16:57:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk -----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Wednesday, April 05, 2000 3:23 PM >To: Cucchiara, Joan >Cc: 'mpls@uu.net' >Subject: RE: LSR MIB comments and questions > > Hi, > > Sorry about the delay in response. It was a > long flight back from Adelaide! ;) > > >I also question why this extra variable is required to > > >convey the label space membership attributes. > > > > > >If mplsInterfaceConfIndex is zero, then it uneqivocally > > >has the attributes 'in global label space' and 'not in > > >local label space'. > > > > > >If mplsInterfaceConfIndex is non-zero, that it uneqivocally > > >has the attribute 'in local label space' and the 'in > > >global label space' variable arbitrates that (optional) > > >attribute. > > > > Yes, but there are cases in ATM where an interface needs > > to be part of both label spaces. This is why we have > > provided two separate variables here. > > The combination of the index and ONE of these > objects would (I think) allow all combinations. For example, > > Yes, that is true, although it implicitly notes > which interfaces are per-interface and which are per-platform. > Our intention was to be explicit about this. The reason is > that if you use the implicit version, it is unclear as to > how the implementation should note the label ranges. We do Tom, Could I suggest combining these two boolean objects into one enum object, mplsInterfaceLabelParticipationType, with values ( perPlatformOnly, perInterfaceOnly, both)?? DESCRIPTION: "If the value of the mplsInterfaceConfIndex for this entry is zero, then this object MUST be perPlatformOnly. If the value of the mplsInterfaceConfIndex for this entry is non-zero, then this object may be either 'perInterfaceOnly' or 'both'. If the value is perInterfaceOnly then this means that the value of the MIN/MAX IN/OUT Label Range objects for this entry contain valid values. If the value is both, then the value of the MIN/MAX IN/OUT label Range objects do not contain valid values (???? OR maybe need to contain the same values as the MIN/MAX IN/OUT Label Range objects for the entry which has the mplsInterfaceConfIndex of zero????)" [NOTE: The description needs work because it needs to be co-ordinated with the MIN/MAX IN/OUT Label objects.] I think this enum would be explicit enough (and also combines the two boolean objects into one enum object -- so one less object!). What do you think? Thanks, Joan > agree however, that changing the names to IsPerPlatformLabelSpace > and IsPerIfLabelSpace is a great idea as it makes this consistent > with the architecture. > > --Tom From owner-mpls@UU.NET Wed Apr 5 17:12:46 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16558 for ; Wed, 5 Apr 2000 17:12:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijqq18896; Wed, 5 Apr 2000 21:09:53 GMT Received: by mail-control.mail.uu.net id QQijqq15064 for mpls-outgoing; Wed, 5 Apr 2000 21:09:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijqq15059 for ; Wed, 5 Apr 2000 21:09:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijqq02275 for ; Wed, 5 Apr 2000 17:09:14 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijqq18143 for ; Wed, 5 Apr 2000 21:09:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA15651 for mpls@uu.net; Wed, 5 Apr 2000 17:09:13 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijqq15045 for ; Wed, 5 Apr 2000 21:08:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijqq02135 for ; Wed, 5 Apr 2000 17:08:39 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQijqq06323 for ; Wed, 5 Apr 2000 21:08:39 GMT Received: from tnadeau-pc02 (ch2-dhcp134-185.cisco.com [161.44.134.185]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21783; Wed, 5 Apr 2000 17:08:35 -0400 (EDT) Message-Id: <4.2.2.20000405170529.0723d7f0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Apr 2000 17:07:46 -0400 To: "Cucchiara, Joan" , "Cucchiara, Joan" From: "Thomas D. Nadeau" Subject: RE: LSR MIB comments and questions Cc: "'mpls@uu.net'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F95F@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_25027069==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_25027069==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, This sounds like a reasonable thing to us. I will make the change. --Tom >Could I suggest combining these two boolean objects into >one enum object, mplsInterfaceLabelParticipationType, >with values ( perPlatformOnly, perInterfaceOnly, both)?? > >DESCRIPTION: > "If the value of the mplsInterfaceConfIndex for this > entry is zero, then this object MUST be perPlatformOnly. > > If the value of the mplsInterfaceConfIndex for this entry > is non-zero, then this object may be either 'perInterfaceOnly' > or 'both'. If the value is perInterfaceOnly then this means that > the value of the MIN/MAX IN/OUT Label Range objects for > this entry contain valid values. If the value is both, then > the value of the MIN/MAX IN/OUT label Range objects do not contain > valid values (???? OR maybe need to contain the same values as > the MIN/MAX IN/OUT Label Range objects for the > entry which has the mplsInterfaceConfIndex of zero????)" > >[NOTE: The description needs work because it needs to be >co-ordinated with the MIN/MAX IN/OUT Label objects.] > >I think this enum would be explicit enough (and also combines >the two boolean objects into one enum object -- so one less object!). >What do you think? > > Thanks, > Joan > > > agree however, that changing the names to IsPerPlatformLabelSpace > > and IsPerIfLabelSpace is a great idea as it makes this consistent > > with the architecture. > > > > --Tom --=====================_25027069==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

        This sounds like a reasonable thing to us. I
will make the change.

        --Tom           
        


Could I suggest combining these two boolean objects into
one enum object, mplsInterfaceLabelParticipationType,
with values ( perPlatformOnly, perInterfaceOnly, both)??

DESCRIPTION:
   "If the value of the mplsInterfaceConfIndex for this
   entry is zero, then this object MUST be perPlatformOnly. 
  
   If the value of the mplsInterfaceConfIndex for this entry
   is non-zero, then this object may be either 'perInterfaceOnly'
   or 'both'.  If the value is perInterfaceOnly then this means that
   the value of the MIN/MAX IN/OUT Label Range objects for
   this entry contain valid values.  If the value is both, then
   the value of the MIN/MAX IN/OUT label Range objects do not contain
   valid values  (???? OR maybe  need to contain the same values as
   the MIN/MAX IN/OUT Label Range objects for the
   entry which has the mplsInterfaceConfIndex of zero????)"

[NOTE:  The description needs work because it needs to be
co-ordinated with the MIN/MAX IN/OUT Label objects.]

I think this enum would be explicit enough (and also combines
the two boolean objects into one enum object -- so one less object!). 
What do you think?

   Thanks,
     Joan

> agree however, that changing the names to IsPerPlatformLabelSpace
> and IsPerIfLabelSpace is a great idea as it makes this consistent
> with the architecture.
>
>         --Tom
--=====================_25027069==_.ALT-- From owner-mpls@UU.NET Wed Apr 5 19:49:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17733 for ; Wed, 5 Apr 2000 19:49:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijrb22357; Wed, 5 Apr 2000 23:47:00 GMT Received: by mail-control.mail.uu.net id QQijrb09390 for mpls-outgoing; Wed, 5 Apr 2000 23:46:22 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijrb09385 for ; Wed, 5 Apr 2000 23:46:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijrb08929 for ; Wed, 5 Apr 2000 19:46:02 -0400 (EDT) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQijrb21330 for ; Wed, 5 Apr 2000 23:46:01 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id TAA12136 for ; Wed, 5 Apr 2000 19:46:00 -0400 (EDT) Received: by localhost with Microsoft MAPI; Wed, 5 Apr 2000 19:46:00 -0400 Message-ID: <01BF9F37.91BBE0D0.mjork@avici.com> From: Markus Jork To: "'mpls@uu.net'" Subject: tunnel bandwidth change and RSVP-TE Date: Wed, 5 Apr 2000 19:45:59 -0400 Organization: Avici 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 The problem is as follows: I want to increase the bandwidth of an already established tunnel without the danger of deleting the tunnel when this change attempt fails. (The same problem exists for any other parameter subject to admission control such as the holding priority.) In traditional RSVP, the receiver would make the decision of increasing the flowspec for a session. If that attempt fails at any node, the old flowspec would stay in place and a ResvErr message would be sent back to the receiver. There is an "InPlace" flag in the error object that indicates this situation. Things are different with RSVP-TE. Here, the sender (i.e. tunnel ingress) should be in charge of modifying the bandwidth of a tunnel. If the attempt to increase the bandwidth fails at any node, an "Admission Control Failure" PathErr message has to be sent back to the ingress. This is a new concept introduced by RSVP-TE and so I'm wondering what exactly the semantics of that PathErr message are. A PathErr message has always implied that a Path message cannot reach the destination and thus the ingress has to assume that the tunnel lsp went down. Or was the intention to handle an admission control error in a PathErr message like a ResvErr including the "InPlace" flag? In the first case (PathErr indicates the path could not be established), one can use the make-before-break approach for increasing the tunnel bandwidth. This will work fine as long as admission control is done on the Path message travelling downstream and not on the Resv message coming back upstream. Markus From owner-mpls@UU.NET Wed Apr 5 20:12:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17949 for ; Wed, 5 Apr 2000 20:12:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijrc12216; Thu, 6 Apr 2000 00:09:59 GMT Received: by mail-control.mail.uu.net id QQijrc18300 for mpls-outgoing; Thu, 6 Apr 2000 00:09:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijrc18295 for ; Thu, 6 Apr 2000 00:09:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijrc23655 for ; Wed, 5 Apr 2000 20:09:06 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQijrc11210 for ; Thu, 6 Apr 2000 00:09:06 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id TAA20602; Wed, 5 Apr 2000 19:07:49 -0500 Message-Id: <4.3.1.2.20000405200040.00be6190@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 05 Apr 2000 20:08:13 -0400 To: Markus Jork From: Lou Berger Subject: Re: tunnel bandwidth change and RSVP-TE Cc: "'mpls@uu.net'" In-Reply-To: <01BF9F37.91BBE0D0.mjork@avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 07:45 PM 4/5/00 -0400, Markus Jork wrote: >The problem is as follows: I want to increase the bandwidth >of an already established tunnel without the danger of >deleting the tunnel when this change attempt fails. >(The same problem exists for any other parameter subject >to admission control such as the holding priority.) > >In traditional RSVP, the receiver would make the decision >of increasing the flowspec for a session. If that attempt >fails at any node, the old flowspec would stay in place and >a ResvErr message would be sent back to the receiver. >There is an "InPlace" flag in the error object that indicates >this situation. > >Things are different with RSVP-TE. Here, the sender (i.e. tunnel >ingress) should be in charge of modifying the bandwidth >of a tunnel. If the attempt to increase the bandwidth fails at any >node, an "Admission Control Failure" PathErr message has to be >sent back to the ingress. This presumes allocation on path. While this can be done, the semantics of RSVP really don't properly handle this case. (as you point out.) The normal way this would work, even with RSVP-TE is for the updated tspec to be passed to the receiver (the egress) and for the egress to then request an increase. this will lead to normal RSVP processing. >This is a new concept introduced by >RSVP-TE and so I'm wondering what exactly the semantics of >that PathErr message are. I believe this is introduced by some implementations, not by RSVP-TE. >A PathErr message has always implied that a Path message >cannot reach the destination and thus the ingress has to assume >that the tunnel lsp went down. Or was the intention to handle >an admission control error in a PathErr message like a ResvErr >including the "InPlace" flag? While such a modification to RSVP is possible, I don't believe it's covered in the current documents. Some thing along these lines may result from some of the proposed optical related extension, but it's still a bit too early to tell. Lou >In the first case (PathErr indicates the path could not be established), >one can use the make-before-break approach for increasing >the tunnel bandwidth. This will work fine as long as admission >control is done on the Path message travelling downstream >and not on the Resv message coming back upstream. > >Markus From owner-mpls@UU.NET Wed Apr 5 20:25:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18096 for ; Wed, 5 Apr 2000 20:25:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijrd24770; Thu, 6 Apr 2000 00:22:39 GMT Received: by mail-control.mail.uu.net id QQijrd19197 for mpls-outgoing; Thu, 6 Apr 2000 00:22:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijrd19172 for ; Thu, 6 Apr 2000 00:22:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijrd24967 for ; Wed, 5 Apr 2000 20:21:51 -0400 (EDT) Received: from research.gate.nec.co.jp by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: research.gate.nec.co.jp [202.247.6.217]) id QQijrd23829 for ; Thu, 6 Apr 2000 00:21:50 GMT Received: from tomato.nwk.cl.nec.co.jp (IDENT:p0/2f6w4S9UGweqiv/EvdCubSB+9iQ4z@tomato.nwk.cl.nec.co.jp [10.56.32.1]) by research.gate.nec.co.jp (8.9.3+3.2W/000201) with ESMTP id JAA17324; Thu, 6 Apr 2000 09:21:42 +0900 (JST) Received: from tea.nwk.cl.nec.co.jp by tomato.nwk.cl.nec.co.jp (8.9.3/NWKM20000322) with ESMTP id JAA29483; Thu, 6 Apr 2000 09:21:36 +0900 (JST) Received: from iwata-pc2 (iwata-pc2.nwk.cl.nec.co.jp [10.56.32.77]) by tea.nwk.cl.nec.co.jp (8.9.0/3.7W) with ESMTP id JAA16415; Thu, 6 Apr 2000 09:21:36 +0900 (JST) Message-Id: <4.2.0.58.J.20000406092149.00a03420@tea.nwk.cl.nec.co.jp> X-Sender: iwata@tea.nwk.cl.nec.co.jp Reply-To: iwata@ccm.CL.nec.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 06 Apr 2000 09:30:07 +0900 To: "Peter Ashwood-Smith" From: Atsushi Iwata Subject: Re: Any more comments on draft-ietf-mpls-te-feed-00.txt? Cc: MPLS mailing list , Norihito Fujita In-Reply-To: <38EB4AE9.3C2C8B8B@americasm01.nt.com> References: <4.2.2.20000405074042.06d1ca60@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, Peter, I have one comment. At 10:17 00/04/05 -0400, Peter Ashwood-Smith wrote: >RE: draft-ietf-mpls-te-feed-00 > > Still looking for feedback on the feedback draft ... pun >intended. > > I will be asking the WG chairs for a last call on this in the >next few days unless somebody has some issues with it. As I explained our draft, draft-fujita-mpls-crldp-crankback-00.txt, in the last IETF, there are several possibilities of indicating of links or nodes. If you use unnumbered point-to-point links between routers, you cannot specify IPv4 address of interfaces for IPV4 specificed link feedback TLV and IPV6 specified link feedback TLV. In that case, you have to use a routing protocol (OSPF etc) dependent TLV to indicate links or nodes. Our draft specifies protocol independent TLV (using ER-HOPS information) and routing protocol dependent TLV (OSPF, ISIS-specific information). I guess that our draft could be an one of possible solution to indicate such links or nodes. What do you think ? Best regards, ---------------------------------------------------------------- Atsushi Iwata Assistant Manager Network Architecture TG, Networking Research Laboratory C&C Media Research Laboratories NEC Corporation 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 E-mail: a-iwata@ah.jp.nec.com ** New organization has started since Apr.1, 2000. *** From owner-mpls@UU.NET Wed Apr 5 20:36:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18219 for ; Wed, 5 Apr 2000 20:36:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijre05440; Thu, 6 Apr 2000 00:33:59 GMT Received: by mail-control.mail.uu.net id QQijre19665 for mpls-outgoing; Thu, 6 Apr 2000 00:33:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijre19660 for ; Thu, 6 Apr 2000 00:33:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijre13923 for ; Wed, 5 Apr 2000 20:33:13 -0400 (EDT) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQijre03793 for ; Thu, 6 Apr 2000 00:33:13 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id UAA14607; Wed, 5 Apr 2000 20:33:00 -0400 (EDT) Received: by localhost with Microsoft MAPI; Wed, 5 Apr 2000 20:33:01 -0400 Message-ID: <01BF9F3E.22F4F1D0.mjork@avici.com> From: Markus Jork To: "'Lou Berger'" Cc: "'mpls@uu.net'" Subject: RE: tunnel bandwidth change and RSVP-TE Date: Wed, 5 Apr 2000 20:33:00 -0400 Organization: Avici 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 On Wednesday, April 05, 2000 8:08 PM, Lou Berger wrote: > At 07:45 PM 4/5/00 -0400, Markus Jork wrote: > >The problem is as follows: I want to increase the bandwidth > >of an already established tunnel without the danger of > >deleting the tunnel when this change attempt fails. > >(The same problem exists for any other parameter subject > >to admission control such as the holding priority.) > > > >In traditional RSVP, the receiver would make the decision > >of increasing the flowspec for a session. If that attempt > >fails at any node, the old flowspec would stay in place and > >a ResvErr message would be sent back to the receiver. > >There is an "InPlace" flag in the error object that indicates > >this situation. > > > >Things are different with RSVP-TE. Here, the sender (i.e. tunnel > >ingress) should be in charge of modifying the bandwidth > >of a tunnel. If the attempt to increase the bandwidth fails at any > >node, an "Admission Control Failure" PathErr message has to be > >sent back to the ingress. > > This presumes allocation on path. While this can be done, the semantics of > RSVP really don't properly handle this case. (as you point out.) The > normal way this would work, even with RSVP-TE is for the updated tspec to > be passed to the receiver (the egress) and for the egress to then request > an increase. this will lead to normal RSVP processing. > > >This is a new concept introduced by > >RSVP-TE and so I'm wondering what exactly the semantics of > >that PathErr message are. > > I believe this is introduced by some implementations, not by RSVP-TE. Section 4.7 of the draft says: "If the requested bandwidth is not available a PathErr message is returned with an Error Code of 01, Admission Control Failure, and an Error Value of 0x0002." Markus From owner-mpls@UU.NET Wed Apr 5 21:55:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19970 for ; Wed, 5 Apr 2000 21:55:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijrj07507; Thu, 6 Apr 2000 01:53:06 GMT Received: by mail-control.mail.uu.net id QQijrj01450 for mpls-outgoing; Thu, 6 Apr 2000 01:52:50 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijrj01445 for ; Thu, 6 Apr 2000 01:52:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijrj21786 for ; Wed, 5 Apr 2000 21:52:36 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijrj24566 for ; Thu, 6 Apr 2000 01:52:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA12364 for mpls@uu.net; Wed, 5 Apr 2000 21:52:34 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijrj01412 for ; Thu, 6 Apr 2000 01:51:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijrj21750 for ; Wed, 5 Apr 2000 21:51:40 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQijrj23498 for ; Thu, 6 Apr 2000 01:51:40 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Apr 2000 21:51:44 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F963@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Thomas D. Nadeau'" , "Cucchiara, Joan" , "'Arun Viswanathan'" , "Cucchiara, Joan" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Wed, 5 Apr 2000 21:51:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > > * mplsInSegmentXCIndex description is incorrect. A value > > of zero could certainly indicates a valid cross connect. > > The XC table does model XCs even for terminating InSegments > > and Originating OutSegments. > > > > The syntax clause should be changed in either this > > table or in the XC table since the syntax should be > > the same in both places. > > We meant it to be this way, that is, 0 is not a valid > XC index. 0 is used to indicate that the XC entries > have exhausted. Currently, mplsInSegmentXCIndex has: SYNTAX Integer32(1..2147483647) DESCRIPTION "The index into mplsXCTable is used to identify which cross-connect entry this segment is part of. Note that a value of zero indicates that it is not being referred to by any cross-connect entry." DEFVAL {0} Could this object be made a RowPointer? Why do you want this to be a RowPointer? I think that doing so would unnecessarily complicate the indexing for the agent, so we would like to leave it as is. Joan's questions are in (): (The object is not correct as it appears in the MIB. SYNTAX should start at 0 (OR get rid of the DEFVAL {0}). It is not clear from the above description what the value of this object represents. Does this object take on the same value as 'mplsXCIndex' in the mplsXCTable'? Is the value of 'mplsXCIndex' unique within the table? Also, the value of 'mplsXCIndex' should have range which starts at 1, currently it is not specified so this means zero would be an acceptable value. Since mplsInSegmentXCIndex uses zero to mean that there is no corresponding entry in the mplsXCTable, this needs to be changed.) > > * mplsInSegmentTSpecIndex -- this object needs to be made > > optional for LDP. > > Is already optional. A value of zero to indicate best effort. > See description. Why is it necessary for an LDP only implementation to support this? It is not necessary. Although an implementation must implement this value, it can certainly return 0. Joan's comments are in (): (But this really makes no sense for LDP, there is no Tspec or Traffic Engineering, that is why we also have CR-LDP, right? So having an LDP only implementations support objects which have no meaning for LDP is not acceptable. Thus, it should be made optional in the conformance statements. I thought we reached agreement that the TSpec table would also be made optional for LDP. Is this not the case?) > > * mplsInSegmentOwner -- could this be removed from the > > table. > > > > These object are of little value in my opinion because > > who really cares how the row got created? > > > > Also, if you have snmp and policyAgent, then you should > > add cli, config file, web, etc.... > > > > Just seems to be a big rat hole in my opinion. > > If you don't want to identify yourself, you can choose the > 'other' option ;-) > > It is there because folks asked for it. It provides > tracking for usage information, for troubleshooting, > and erroneous deletion by somebody how did not create > it in the first place. Are you planning on specifying in the enum the other possibilities (cli, config file, web, etc...)? No. Joan's question in (): (why? don't you think you need these other ways of configuring for completeness of this object?) Also, why is policyAgent one of the choices, this is a MIB and it was my understanding that policyAgent's used PIBs. PolicyAgents can't support RowStatus, so I believe that choice should be removed. The PIB may not support RowStatus, but the agent which interacts with the PIB/PolicyAgent may create an entry. It is our intent for this enumeration to note this case. Joan's comments in (): (This may or may not be the case, it is not yet defined what the interactions between the Policy Agent and the SNMP Agent are going to be. You have no way to know if the Policy Agent will be able to inform the SNMP Agent to create a Row or any other MIB entries for that matter. Besides, if this was already defined, why would there even be a need for a PIB? we could just use MIB, right? I would also like to understand what the heck difference this makes for the LSR MIB. It is putting many restrictions on what the agent does and is of no relevance to the LSR MIB. Could we compromise and have this object made optional in the conformance section?) > > * mplsOutSegmentIndexNext object range should start at 0 (zero). > > No. 0 is bad index; is used to identify terminating connections > in the cross-connect. The description for this object says: "If the number of unassigned entries is exhausted, this object will take on the value of 0...." But the SYNTAX starts at 1, I believe that the SYNTAX should start at 0. Good catch. Fixed. > A label swapping is modelled as a pop followed by a push. > See mplsInSegmentNPop. The description also talks about > the ATM case. > > > > > Could you rephrase this section to specifically > > call out that for Version 1 of LDP using ATM or FR this should > > be set to true and Reference Section 5. of the LDP Spec? > > I don't think we need to specially qualify LDP for this. This > is common to any protocol on ATM. I think that if you expect that people support this MIB for LDP then you should be more accomodating. I'm only asking for a clarifying description and reference to be added. Sure. How does this sound: The number of labels to pop from the incoming packet. Normally only the top label is popped from the packet and used for all switching decisions for that packet. Note that technologies which do not support label popping should set this value to its default value of 1. Joan: Good. > > * mplsOutSegmentTopLabel > > > > Could this object be changed to contain the value of > > the top label on egress? I think it would be > > much more interesting to point to the egress label > > especially since the prior object (mplsOutSegmentPushTopLabel) > > tells whether or not this was pushed. > > > Hmm..I guess I don't understand the comment. > It already is what you are asking it to be. Sorry, my mistake. I think the name confused me, would you consider a name change to mplsOutSegmentLabel? I think that mpslOutSegmentTopLabel is more specific. I modified the description a bit to make it (hopefully) be more explicit: If mplsOutSegmentPushTopLabel is true then this represents the label that should be pushed onto the top of the outgoing packet's label stack. Note that the contents of the label field can be interpreted in an outgoing interface-specific fashion. For example, the label carried in the MPLS shim header is 20 bits wide and the top 12 bits must be zero. The Frame Relay label is 24 bits wide and the top 8 bits must be zero. For ATM interfaces the lowermost 16 bits are interpreted as the VCI, the next 8 bits as the VPI and the remaining bits must be zero. Joan(): (it was pointed out to us that there is a type in the MplsLabel TC -- the vpi should be 12 bits. Okay, adding the "the top" seemed to help). I know that we discussed this before and the reason that you gave was that the MIB had been this way since Feb 1999, but I am still confused as to why you believe the indexing of this table to be better than (mplsOutSegmentIfIndex, mplsOutSegmentLabel) This won't work for the case where we want to pop the top label and forward the packet with whatever label is underneath, without knowing or wanting to know the underlying labels. Joan(): (I'm a little confused because the LIB (or XC) is supposed to be a ingress, egress pairing and other info, right? If you don't keep the egress label used in forwarding, then not sure that I understand what you are saying here. Anyway, if you say that you can't change it then I so be it.) > > * mplsXCIndexNext object's range should start at 0. > > It is alright the way it is. 0 is reserved to indicate > "no more cross-connect entries available". I agree but the SYNTAX clause starts at 1 and should start at 0. Good catch. Fixed. > > * INDEX clause and description of the entry: > > > > The description redefines what a values of zero means > > for the mplsInSegmentIfIndex and mplsInSegmentLabel; > > in the mplsInSegmentTable they mean one thing, > > and yet, they mean something else in the XC table. > > > > Yes, they are different tables. > Index zero is valid only for the InSegemntTable. They may be different tables but they are the same indices, so they should be used the same everywhere they are referenced. It is not acceptable to redefine what a value means just because they are in different tables. The index's definition is meaningful within the context of each table. We went to great lengths to make the meaning within each context explicit. Joan(): (What if there is an entry in the InSegment table with values of MplsInSegmentLabel == 0 and mplsInSegmentIfIndex == 0, which is an actual InSegment and is cross connecting to an actual outsegment. How is this InSegment and its associated OutSegment represented in the XC table, such that the NMS understand that this is a real XC and not an originating LSP? This is exactly the reason that you cannot redefine the SAME object to mean different things just because it is a different table. That is not accepted MIB practice.) > > * What do the AdminStatus and OperStatus objects mean when > > the LSP is terminating or Originating for this entry? > > > > Admin status is provided to control the cross-connect from > passing data. Oper status may reflect the overall health of > the cross-connect, for example, if the outgoing interface is > down, then the cross-connect oper status may reflect that. But what do they mean in the case of a terminating or originating LSP which is in the XC table? If AdminStatus is down, what does this imply for a terminating LSP? Could the description be clarified to call this out, because this is something which could be interpretted differently by different vendors and needs to be clarified. This means that the LSP should not forward packets. We have updated section 7.0 Brief Description of MIB Objects, to add some additional text explaining this more explicitly. Joan: (I realize that perhaps I wasn't very clear, to put it another way, does AdminStatus in the XC table differ from the AdminStatus in the InSegment table? If not, could you just say so, or otherwise say how these are different?) Thanks, Joan --Tom From owner-mpls@UU.NET Thu Apr 6 10:30:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08935 for ; Thu, 6 Apr 2000 10:30:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijth22226; Thu, 6 Apr 2000 14:28:54 GMT Received: by mail-control.mail.uu.net id QQijth24493 for mpls-outgoing; Thu, 6 Apr 2000 14:28:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijth24487 for ; Thu, 6 Apr 2000 14:28:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijth19281 for ; Thu, 6 Apr 2000 10:28:11 -0400 (EDT) Received: from sj-mailhub-3.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQijth21335 for ; Thu, 6 Apr 2000 14:28:10 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA22492 for ; Thu, 6 Apr 2000 07:29:29 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA11073 for mpls@uu.net; Thu, 6 Apr 2000 10:28:07 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijrw12314 for ; Thu, 6 Apr 2000 05:04:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijrw21537 for ; Thu, 6 Apr 2000 01:04:10 -0400 (EDT) Received: from flower.comeng.chungnam.ac.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [168.188.44.2]) id QQijrw17700 for ; Thu, 6 Apr 2000 05:04:09 GMT Received: from ce.cnu.ac.kr (wchun.comeng.chungnam.ac.kr [168.188.44.19]) by flower.comeng.chungnam.ac.kr (8.9.1/8.9.1) with ESMTP id NAA20234; Thu, 6 Apr 2000 13:59:55 +0900 (KST) Message-ID: <38EC1B8F.D7801C1E@ce.cnu.ac.kr> Date: Thu, 06 Apr 2000 14:07:28 +0900 From: Woojik Chun Organization: Dept. Compuer Eng. Chungnam National Univ. X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: ko,en MIME-Version: 1.0 To: MPLS , "=?EUC-KR?B?scfFw7HZ?=" , shah@nist.gov, Chris Develder , Wichit Saiklao Subject: MPLS Network Simulator Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit About a month ago, I posted our work on MPLS network simulator. Now I anounce the preliminary version of MNS (MPLS Network Simulator) This version MPLS Network Simulator is based on NS-2. The primary purpose of MNS is to simulate MPLS networks and their applications. This version includes : MPLS Packet switching -- label swapping operation, TTL decrement, and penultimate hop popping LDP -- handling LDP messages (Request, Mapping, Withdraw, Release, and Notification) CR-LDP -- handling CR-LDP messages (Request and Mapping) You will find breif introduction, manual, and some examples. And also you can download the source code. If you have any comment, question, or suggestion, post it via Q&A. Please visit our Home page ( http://raonet.com/mns/ ) From owner-mpls@UU.NET Thu Apr 6 11:36:09 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10011 for ; Thu, 6 Apr 2000 11:36:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijtm19860; Thu, 6 Apr 2000 15:34:37 GMT Received: by mail-control.mail.uu.net id QQijtm07561 for mpls-outgoing; Thu, 6 Apr 2000 15:34:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijtm07554 for ; Thu, 6 Apr 2000 15:34:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijtm22848 for ; Thu, 6 Apr 2000 11:33:55 -0400 (EDT) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQijtm19067 for ; Thu, 6 Apr 2000 15:33:55 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Thu, 6 Apr 2000 11:33:24 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A48CFF2@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: Higher labels and RSVP Date: Thu, 6 Apr 2000 11:33:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I'm trying to resolve a question that looked simple at first: Is it correct to say that higher level labels can only be drawn from the per-platform label space ? At first it seemed natural, and then I even found in my archives discussions before the BGP draft was issued that reinforced my conviction: since packets labeld with BGP labels can arrive at an LSR over different interfaces, and the route my vary depending on IGP activity, at packet reception time - the LSR can not tell by what interface the labeled packet should have arrived at. This is all fine, and sound fine for BGP assigned labels. But... When labels are assigned using RSVP the whole label stack is assigned at once - such that it depends on the semantics - is the label stack valid only as a whole ? Can the LSR that received the label binding (with 2+ labels) use the higher levels stacked on other top labels ? If the former is the case - then per-interface label space can be used. if the latter, then only per-platform space can be used. To make things interesting, in draft-swallow-rsvp-bypass-label-00 it is explicitly assumed that the higher labels can be used with different top labels (one for the original tunnel and a different one for the bypass tunnel). Ok, so what say you ? Andi. From owner-mpls@UU.NET Thu Apr 6 13:10:24 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11532 for ; Thu, 6 Apr 2000 13:10:24 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijts01670; Thu, 6 Apr 2000 17:10:25 GMT Received: by mail-control.mail.uu.net id QQijts29495 for mpls-outgoing; Thu, 6 Apr 2000 17:09:51 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijts29490 for ; Thu, 6 Apr 2000 17:09:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijts09038 for ; Thu, 6 Apr 2000 13:09:31 -0400 (EDT) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQijts06028 for ; Thu, 6 Apr 2000 17:09:31 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id KAA07361; Thu, 6 Apr 2000 10:09:21 -0700 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 10:09:21 -0700 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346872@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Cucchiara, Joan'" , "'Thomas D. Nadeau'" , "'Arun Viswanathan'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Thu, 6 Apr 2000 10:09:20 -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 > Joan(): (What if there is an entry in the InSegment table > with values of MplsInSegmentLabel == 0 and mplsInSegmentIfIndex == 0, > which is an actual InSegment and is cross connecting to > an actual outsegment. How is this InSegment and its > associated OutSegment represented in the XC table, such that > the NMS understand that this is a real XC and not an originating > LSP? > There is no ambiguity here. Label 0 cannot have an outgoing segment. See label encap draft for explicit NULL label. -arun From owner-mpls@UU.NET Thu Apr 6 13:54:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11987 for ; Thu, 6 Apr 2000 13:54:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijtv20163; Thu, 6 Apr 2000 17:54:55 GMT Received: by mail-control.mail.uu.net id QQijtv03783 for mpls-outgoing; Thu, 6 Apr 2000 17:54:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijtv03776 for ; Thu, 6 Apr 2000 17:54:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijtv16105 for ; Thu, 6 Apr 2000 13:54:11 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijtv19620 for ; Thu, 6 Apr 2000 17:54:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA01291 for mpls@uu.net; Thu, 6 Apr 2000 13:54:10 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijtv03684 for ; Thu, 6 Apr 2000 17:52:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijtv22318 for ; Thu, 6 Apr 2000 13:52:36 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQijtv28834 for ; Thu, 6 Apr 2000 17:52:35 GMT Received: from tnadeau-pc02 (ch2-dhcp134-185.cisco.com [161.44.134.185]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14089; Thu, 6 Apr 2000 13:52:28 -0400 (EDT) Message-Id: <4.2.2.20000405235639.07229490@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Apr 2000 13:51:58 -0400 To: "Cucchiara, Joan" , "Cucchiara, Joan" , "'Arun Viswanathan'" , "Cucchiara, Joan" , "'cheenu@tachion.com'" From: "Thomas D. Nadeau" Subject: RE: LSR MIB comments and questions Cc: "'mpls@uu.net'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F963@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Joan, >Currently, mplsInSegmentXCIndex has: > >SYNTAX Integer32(1..2147483647) >DESCRIPTION > "The index into mplsXCTable is used to identify which > cross-connect entry this segment is part of. Note > that a value of zero indicates that it is not being > referred to by any cross-connect entry." >DEFVAL {0} > >Could this object be made a RowPointer? > > Why do you want this to be a RowPointer? I think >that doing so would unnecessarily complicate the indexing >for the agent, so we would like to leave it as is. > >Joan's questions are in (): >(The object is not correct as it appears in the MIB. >SYNTAX should start at 0 (OR get rid of the DEFVAL {0}). Yes, this value has been fixed to have the correct range. >It is not clear from the above description what >the value of this object represents. Does this >object take on the same value as 'mplsXCIndex' in >the mplsXCTable'? Yes. We will add a sentence indicating this. I think that it was our assumption that the name indicated this. >Is the value of 'mplsXCIndex' unique within the table? No. In cases of multipoint/multicast connections, it is possible to have several segments "point at" the same XC. >Also, the value of 'mplsXCIndex' should have range which >starts at 1, currently it is not specified so this means >zero would be an acceptable value. Since mplsInSegmentXCIndex >uses zero to mean that there is no corresponding entry >in the mplsXCTable, this needs to be changed.) Yes, this has been fixed. > > > * mplsInSegmentTSpecIndex -- this object needs to be made > > > optional for LDP. > > > > Is already optional. A value of zero to indicate best effort. > > See description. > >Why is it necessary for an LDP only implementation to >support this? > > It is not necessary. Although an implementation >must implement this value, it can certainly return 0. > >Joan's comments are in (): >(But this really makes no sense for LDP, there is >no Tspec or Traffic Engineering, that is why we >also have CR-LDP, right? So having an LDP only implementations >support objects which have no meaning for LDP is not acceptable. >Thus, it should be made optional in the conformance statements. Is it really a big deal for an implementation to support this just by setting the value to 0? The DEFVAL specifies 0 as a default value, so most implementations will not have to do anything here, and can support it as read-only, so it will never be changed. >I thought we reached agreement that the TSpec table would >also be made optional for LDP. Is this not the case?) Yes, the Tspec table is optional (i.e.: not included in the module conformance statement). > > > * mplsInSegmentOwner -- could this be removed from the > > > table. > > > > > > These object are of little value in my opinion because > > > who really cares how the row got created? > > > > > > Also, if you have snmp and policyAgent, then you should > > > add cli, config file, web, etc.... > > > > > > Just seems to be a big rat hole in my opinion. > > > > If you don't want to identify yourself, you can choose the > > 'other' option ;-) > > > > It is there because folks asked for it. It provides > > tracking for usage information, for troubleshooting, > > and erroneous deletion by somebody how did not create > > it in the first place. > >Are you planning on specifying in the enum the >other possibilities (cli, config file, web, etc...)? > > No. > >Joan's question in (): >(why? don't you think you need these other >ways of configuring for completeness of this object?) What the intent was with this object was to identify either the signaling protocol, policy agent (i.e.: COPS), agent (SNMP) or "other" configuration of this object. The point here was to let external sources know that if they did not create an object, that they may not be allowed to delete/modify it depending on the implementation. We distinguished SNMP since it seemed obvious. We also provided "other" for managers who did not want to use "SNMP", but wanted to note that something else configured the object (i.e.: cli, web, etc...). >Also, why is policyAgent one of the choices, this is >a MIB and it was my understanding that policyAgent's used >PIBs. PolicyAgents can't support RowStatus, so I believe >that choice should be removed. > > The PIB may not support RowStatus, but the agent which >interacts with the PIB/PolicyAgent may create an entry. It >is our intent for this enumeration to note this case. > >Joan's comments in (): >(This may or may not be the case, it is not yet >defined what the interactions between the Policy Agent and >the SNMP Agent are going to be. You have no way to know >if the Policy Agent will be able to inform the SNMP Agent >to create a Row or any other MIB entries for that matter. As you pointed out, it may or may not be the case. We are focusing on the "may" case. I believe the original request for this object came from one of the reference implementations. >I would also like to understand what the heck difference >this makes for the LSR MIB. It is putting many restrictions >on what the agent does and is of no relevance to the LSR MIB. >Could we compromise and have this object made optional in >the conformance section?) I think that this is reasonable, since I believe that we have stated already that the implementation of this object is implementation-specific. Certainly implementation of this object at all. How about leaving the object there, but adding another option called "unknown" and making this the DEFVAL? >Joan: (I realize that perhaps I wasn't very clear, to put it >another way, does AdminStatus in the XC table differ from >the AdminStatus in the InSegment table? If not, could you >just say so, or otherwise say how these are different?) Yes, their values *may* differ. I think that the distinction should be clear from the definitions of admin and oper status. It may be the case that some implementations do not allow modification of these values, and hence might want different admin/operStatus values just like in any other MIB. However, in other cases, where they do not allow modification of these values, then they will be the same thing: whatever the agent has set them to. --Tom From owner-mpls@UU.NET Thu Apr 6 13:58:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12055 for ; Thu, 6 Apr 2000 13:58:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijtv03702; Thu, 6 Apr 2000 17:58:38 GMT Received: by mail-control.mail.uu.net id QQijtv04048 for mpls-outgoing; Thu, 6 Apr 2000 17:58:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijtv04043 for ; Thu, 6 Apr 2000 17:58:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijtv23129 for ; Thu, 6 Apr 2000 13:57:52 -0400 (EDT) Received: from smtprich.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprich.nortel.com [192.135.215.8]) id QQijtv22699 for ; Thu, 6 Apr 2000 17:57:51 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Thu, 6 Apr 2000 12:57:42 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2NF783LZ>; Thu, 6 Apr 2000 12:56:39 -0500 Message-ID: From: "Don Fedyk" To: iwata@ccm.CL.nec.co.jp, "Peter Ashwood-Smith" Cc: MPLS mailing list , Norihito Fujita Subject: RE: Any more comments on draft-ietf-mpls-te-feed-00.txt? Date: Thu, 6 Apr 2000 12:56:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9FF1.75871528" 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_01BF9FF1.75871528 Content-Type: text/plain; charset="iso-8859-1" Dear Atsushi Iwata, The feedback draft is aimed at numbered links only. The cycle is a path is selected from a topology database that is populated by an IGP. Both IGPs use the same format so it does not matter which IGP. The path becomes the ER MPLS LSP. Next the ER LSP is established and our Draft uses CR-LDP to accomplish this. If a link that is not able to support the path is encountered, the bandwidth profile (independent of the IGP for the number link) is added to the failure notification. This information is generated for every link along the traversed section of the path. This information can then be added to the topology database improving its accuracy for all subsequent path requests. A crankback as you describe cannot update the database since it may not have an accurate bandwidth profile. This could happen if you encountered a node that did not support the feedback. So crankback could be the degenerate case of feedback. ER paths can support un-numbered links in some cases. When the path is loose routed, for example, but this is not the constraint based case we were covering in the draft. Don > -----Original Message----- > From: Atsushi Iwata [mailto:iwata@ccm.CL.nec.co.jp] > Sent: Wednesday, April 05, 2000 8:30 PM > To: Ashwood-Smith, Peter [CAR:CS57:EXCH] > Cc: MPLS mailing list; Norihito Fujita > Subject: Re: Any more comments on draft-ietf-mpls-te-feed-00.txt? > > > Hi, Peter, > > I have one comment. > > At 10:17 00/04/05 -0400, Peter Ashwood-Smith wrote: > >RE: draft-ietf-mpls-te-feed-00 > > > > Still looking for feedback on the feedback draft ... pun > >intended. > > > > I will be asking the WG chairs for a last call on this in the > >next few days unless somebody has some issues with it. > > As I explained our draft, > draft-fujita-mpls-crldp-crankback-00.txt, in the > last IETF, there are several possibilities of indicating of > links or nodes. > If you use unnumbered point-to-point links between routers, > you cannot > specify IPv4 address of interfaces for IPV4 specificed link > feedback TLV > and IPV6 specified link feedback TLV. In that case, you have to use a > routing protocol (OSPF etc) dependent TLV to indicate links or nodes. > > Our draft specifies protocol independent TLV (using ER-HOPS > information) > and routing protocol dependent TLV (OSPF, ISIS-specific > information). I > guess that our draft could be an one of possible solution to > indicate such > links or nodes. > > What do you think ? > > Best regards, > ---------------------------------------------------------------- > Atsushi Iwata > Assistant Manager > Network Architecture TG, Networking Research Laboratory > C&C Media Research Laboratories > NEC Corporation > 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 > TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) > NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 > E-mail: a-iwata@ah.jp.nec.com > > ** New organization has started since Apr.1, 2000. *** > > ------_=_NextPart_001_01BF9FF1.75871528 Content-Type: text/html; charset="iso-8859-1" RE: Any more comments on draft-ietf-mpls-te-feed-00.txt?

Dear Atsushi Iwata,

The feedback draft is aimed at numbered links only. The cycle is
a path is selected from a topology database that is populated by
an IGP. Both IGPs use the same format so it does not matter which
IGP. The path becomes the ER MPLS LSP.

Next the ER LSP is established and our Draft uses CR-LDP to accomplish
this. If a link that is not able to support the path is encountered,
the bandwidth profile (independent of the IGP for the number link) is
added to the failure notification. This information is generated for
every link along the traversed section of the path.

This information can then be added to the topology database improving its
accuracy for all subsequent path requests. 

A crankback as you describe cannot update the database since it may
not have an accurate bandwidth profile. This could happen if you
encountered a node that did not support the feedback. So crankback
could be the degenerate case of feedback.

ER paths can support un-numbered links in some cases. When the path is
loose routed, for example, but this is not the constraint based case
we were covering in the draft.

Don

> -----Original Message-----
> From: Atsushi Iwata [mailto:iwata@ccm.CL.nec.co.jp]
> Sent: Wednesday, April 05, 2000 8:30 PM
> To: Ashwood-Smith, Peter [CAR:CS57:EXCH]
> Cc: MPLS mailing list; Norihito Fujita
> Subject: Re: Any more comments on draft-ietf-mpls-te-feed-00.txt?
>
>
> Hi, Peter,
>
> I have one comment.
>
> At 10:17 00/04/05 -0400, Peter Ashwood-Smith wrote:
> >RE: draft-ietf-mpls-te-feed-00
> >
> >   Still looking for feedback on the feedback draft ... pun
> >intended.
> >
> >   I will be asking the WG chairs for a last call on this in the
> >next few days unless somebody has some issues with it.
>
> As I explained our draft,
> draft-fujita-mpls-crldp-crankback-00.txt, in the
> last IETF, there are several possibilities of indicating of
> links or nodes.
> If you use unnumbered point-to-point links between routers,
> you cannot
> specify IPv4 address of interfaces for IPV4 specificed link
> feedback TLV
> and IPV6 specified link feedback TLV. In that case, you have to use a
> routing protocol (OSPF etc) dependent TLV to indicate links or nodes.
>
> Our draft specifies protocol independent TLV (using ER-HOPS
> information)
> and routing protocol dependent TLV (OSPF, ISIS-specific
> information). I
> guess that our draft could be an one of possible solution to
> indicate such
> links or nodes.
>
> What do you think ?
>
> Best regards,
> ----------------------------------------------------------------
> Atsushi Iwata
> Assistant Manager
> Network Architecture TG, Networking Research Laboratory
> C&C Media Research Laboratories
> NEC Corporation
> 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555
> TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
> NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
> E-mail: a-iwata@ah.jp.nec.com
>
> ** New organization has started since Apr.1, 2000. ***
>
>

------_=_NextPart_001_01BF9FF1.75871528-- From owner-mpls@UU.NET Thu Apr 6 14:47:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12742 for ; Thu, 6 Apr 2000 14:47:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijtz07890; Thu, 6 Apr 2000 18:47:06 GMT Received: by mail-control.mail.uu.net id QQijtz15149 for mpls-outgoing; Thu, 6 Apr 2000 18:46:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijtz15144 for ; Thu, 6 Apr 2000 18:46:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijtz29040 for ; Thu, 6 Apr 2000 14:46:05 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijtz06970 for ; Thu, 6 Apr 2000 18:46:04 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA10578 for mpls@uu.net; Thu, 6 Apr 2000 14:46:04 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijty14854 for ; Thu, 6 Apr 2000 18:44:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijty04469 for ; Thu, 6 Apr 2000 14:44:36 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijty05861 for ; Thu, 6 Apr 2000 18:44:36 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA10318; Thu, 6 Apr 2000 14:44:35 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA22945; Thu, 6 Apr 2000 14:44:33 -0400 (EDT) Message-Id: <200004061844.OAA22945@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Markus Jork cc: "'mpls@uu.net'" , swallow@cisco.com Subject: Re: tunnel bandwidth change and RSVP-TE In-reply-to: Your message of "Wed, 05 Apr 2000 19:45:59 EDT." <01BF9F37.91BBE0D0.mjork@avici.com> Date: Thu, 06 Apr 2000 14:44:33 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Markus - > one can use the make-before-break approach for increasing > the tunnel bandwidth. This will work fine as long as admission > control is done on the Path message travelling downstream > and not on the Resv message coming back upstream. I always intended that BW changes be handled exactly this way. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Apr 6 16:33:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14342 for ; Thu, 6 Apr 2000 16:33:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijug04255; Thu, 6 Apr 2000 20:33:08 GMT Received: by mail-control.mail.uu.net id QQijug07663 for mpls-outgoing; Thu, 6 Apr 2000 20:32:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijug07658 for ; Thu, 6 Apr 2000 20:32:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijug18384 for ; Thu, 6 Apr 2000 16:32:26 -0400 (EDT) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQijug03653 for ; Thu, 6 Apr 2000 20:32:25 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id QAA27314; Thu, 6 Apr 2000 16:32:21 -0400 (EDT) Received: by localhost with Microsoft MAPI; Thu, 6 Apr 2000 16:32:21 -0400 Message-ID: <01BF9FE5.AEB7EE00.mjork@avici.com> From: Markus Jork To: "'George Swallow'" Cc: "'mpls@uu.net'" Subject: RE: tunnel bandwidth change and RSVP-TE Date: Thu, 6 Apr 2000 16:32:20 -0400 Organization: Avici 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 On Thursday, April 06, 2000 2:45 PM, George Swallow wrote: > Markus - > > > one can use the make-before-break approach for increasing > > the tunnel bandwidth. This will work fine as long as admission > > control is done on the Path message travelling downstream > > and not on the Resv message coming back upstream. > > I always intended that BW changes be handled exactly this way. > > ...George Ok, works for us. But I guess it would be good to clarify this in the spec. thanks, Markus From owner-mpls@UU.NET Thu Apr 6 17:17:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14974 for ; Thu, 6 Apr 2000 17:17:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijuj11782; Thu, 6 Apr 2000 21:17:44 GMT Received: by mail-control.mail.uu.net id QQijuj18206 for mpls-outgoing; Thu, 6 Apr 2000 21:17:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijuj18197 for ; Thu, 6 Apr 2000 21:17:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijuj26004 for ; Thu, 6 Apr 2000 17:17:13 -0400 (EDT) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQijuj11103 for ; Thu, 6 Apr 2000 21:17:13 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id RAA00762; Thu, 6 Apr 2000 17:17:11 -0400 (EDT) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id RAA78865; Thu, 6 Apr 2000 17:17:39 -0400 (EDT) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200004062117.RAA78865@curtis-lt.avici.com> To: George Swallow cc: Markus Jork , "'mpls@uu.net'" Reply-To: curtis@avici.com Subject: Re: tunnel bandwidth change and RSVP-TE In-reply-to: Your message of "Thu, 06 Apr 2000 14:44:33 EDT." <200004061844.OAA22945@lir.cisco.com> Date: Thu, 06 Apr 2000 17:17:39 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200004061844.OAA22945@lir.cisco.com>, George Swallow writes: > Markus - > > > one can use the make-before-break approach for increasing > > the tunnel bandwidth. This will work fine as long as admission > > control is done on the Path message travelling downstream > > and not on the Resv message coming back upstream. > > I always intended that BW changes be handled exactly this way. > > ...George George, Does that mean that: 1. Once a set of parameters are set in a PATH message, all PATH messages MUST have the same set of parameters. or 2. Once a set of parameters are set in a PATH message, all PATH messages SHOULD have the same set of parameters. If not, there is a risk of admission control rejecting the request. For some cases such as reduction in bandwidth, the risk of being rejected by admission control is nil (excluding the possibility of bugs) or small. If you mean 2 (path messages SHOULD use the same parameters), then there is a requirement for midpoint nodes to try to accommodate the change. If so, can any parameter change, such as holding and reserving priority. If you mean 1 (path messages MUST use the same parameters), then midpoint implementations can be simplified somewhat. We would appreciate it if you would clarify this by telling us if you meant MUST or SHOULD in the above context, and update the draft to make the clarification explicit. Thanks, Curtis From owner-mpls@UU.NET Thu Apr 6 17:52:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15596 for ; Thu, 6 Apr 2000 17:52:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijul00214; Thu, 6 Apr 2000 21:52:51 GMT Received: by mail-control.mail.uu.net id QQijul20177 for mpls-outgoing; Thu, 6 Apr 2000 21:52:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijul20172 for ; Thu, 6 Apr 2000 21:52:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijul01317 for ; Thu, 6 Apr 2000 17:52:25 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijul18192 for ; Thu, 6 Apr 2000 21:52:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA08027 for mpls@uu.net; Thu, 6 Apr 2000 17:52:24 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijul20163 for ; Thu, 6 Apr 2000 21:52:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijul04621 for ; Thu, 6 Apr 2000 17:51:58 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQijul29520 for ; Thu, 6 Apr 2000 21:51:58 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA11958; Thu, 6 Apr 2000 17:51:57 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA10043; Thu, 6 Apr 2000 17:51:57 -0400 (EDT) Message-Id: <200004062151.RAA10043@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: curtis@avici.com cc: George Swallow , Markus Jork , "'mpls@uu.net'" , swallow@cisco.com Subject: Re: tunnel bandwidth change and RSVP-TE In-reply-to: Your message of "Thu, 06 Apr 2000 17:17:39 EDT." <200004062117.RAA78865@curtis-lt.avici.com> Date: Thu, 06 Apr 2000 17:51:56 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Curtis - I meant SHOULD. Or more precisely it is RECOMMENDED for the TE Application's use of RSVP. A MUST would be a significant change to RSVP and I didn't think that would fly. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Apr 6 19:17:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16899 for ; Thu, 6 Apr 2000 19:17:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijur29860; Thu, 6 Apr 2000 23:17:15 GMT Received: by mail-control.mail.uu.net id QQijur10685 for mpls-outgoing; Thu, 6 Apr 2000 23:16:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijur10676 for ; Thu, 6 Apr 2000 23:16:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijur15057 for ; Thu, 6 Apr 2000 19:16:36 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQijur07676 for ; Thu, 6 Apr 2000 23:16:35 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 16:20:39 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A66225E809@ICARIAN> From: Fong Liaw To: "'Markus Jork'" , "'George Swallow'" Cc: "'mpls@uu.net'" , "'berson@isi.edu'" Subject: RE: tunnel bandwidth change and RSVP-TE Date: Thu, 6 Apr 2000 16:20:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Markus I might be stretching my knowledge about RSVP and RSVP-TE. But I believe the old reservation using a different sender id will not be deleted even if the new one failed. I believe RESV message carries the "largest" reservations by all listed senders. When reservation of one sender timed out, the reservation will be recalculated on next refresh cycle or error message which would result in the old reservation. This is exactly the "make before break" behavior you wanted. There might be issue on efficiency of the control messages, but I believe that is not what you are asking. -Fong -----Original Message----- From: Markus Jork [mailto:mjork@avici.com] Sent: Thursday, April 06, 2000 1:32 PM To: 'George Swallow' Cc: 'mpls@uu.net' Subject: RE: tunnel bandwidth change and RSVP-TE On Thursday, April 06, 2000 2:45 PM, George Swallow wrote: > Markus - > > > one can use the make-before-break approach for increasing > > the tunnel bandwidth. This will work fine as long as admission > > control is done on the Path message travelling downstream > > and not on the Resv message coming back upstream. > > I always intended that BW changes be handled exactly this way. > > ...George Ok, works for us. But I guess it would be good to clarify this in the spec. thanks, Markus From owner-mpls@UU.NET Thu Apr 6 20:22:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17443 for ; Thu, 6 Apr 2000 20:22:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijuv08839; Fri, 7 Apr 2000 00:22:50 GMT Received: by mail-control.mail.uu.net id QQijuv22014 for mpls-outgoing; Fri, 7 Apr 2000 00:22:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijuv22008 for ; Fri, 7 Apr 2000 00:22:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijuv18388 for ; Thu, 6 Apr 2000 20:22:17 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijuv08083 for ; Fri, 7 Apr 2000 00:22:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA20918 for mpls@uu.net; Thu, 6 Apr 2000 20:22:12 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijuv21966 for ; Fri, 7 Apr 2000 00:21:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijuv18342 for ; Thu, 6 Apr 2000 20:21:35 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQijuv13803 for ; Fri, 7 Apr 2000 00:21:34 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 20:21:39 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F96B@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Thomas D. Nadeau'" , "Cucchiara, Joan" , "Cucchiara, Joan" , "'Arun Viswanathan'" , "Cucchiara, Joan" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Thu, 6 Apr 2000 20:21:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, > Is it really a big deal for an implementation to support > this just by setting the value to 0? The DEFVAL specifies 0 as > a default value, so most implementations will not have to do anything > here, and can support it as read-only, so it will never be > changed. If no one else minds that they support this object for LDP implementations then it is okay with me. > >Are you planning on specifying in the enum the > >other possibilities (cli, config file, web, etc...)? > > > > No. > > > >Joan's question in (): > >(why? don't you think you need these other > >ways of configuring for completeness of this object?) > > What the intent was with this object was to > identify either the signaling protocol, policy agent > (i.e.: COPS), agent (SNMP) or "other" configuration of this > object. The point here was to let external sources know > that if they did not create an object, that they may not > be allowed to delete/modify it depending on the implementation. > We distinguished SNMP since it seemed obvious. We also provided > "other" for managers who did not want to use "SNMP", but wanted > to note that something else configured the object (i.e.: cli, > web, etc...). > > >Also, why is policyAgent one of the choices, this is > >a MIB and it was my understanding that policyAgent's used > >PIBs. PolicyAgents can't support RowStatus, so I believe > >that choice should be removed. > > > > The PIB may not support RowStatus, but the agent which > >interacts with the PIB/PolicyAgent may create an entry. It > >is our intent for this enumeration to note this case. > > > >Joan's comments in (): > >(This may or may not be the case, it is not yet > >defined what the interactions between the Policy Agent and > >the SNMP Agent are going to be. You have no way to know > >if the Policy Agent will be able to inform the SNMP Agent > >to create a Row or any other MIB entries for that matter. > > As you pointed out, it may or may not be the case. We > are focusing on the "may" case. I believe the original request > for this object came from one of the reference implementations. It is not acceptable to put enums like this in a standard mib which "may" be defined. If the interaction between a policyAgent and an SNMP Agent for row-creation is ever defined, it is a long long way off (YEARS). By then this MIB will be on its 57th revision :) There is not one other standard's track MIB which indicates whether a row was created by a policyAgent/PIB vs. a snmpAgent/MIB. If someone really wants this enum then it belongs in their enterprise MIB and NOT in a standard MIB. Could you take this policyAgent enum out now and put it in when someone describes how a Policy Agent instructs an SNMP agent to create a row? If you could remove the policyAgent enum and the SNMP enum and just use a generic "mgmt" enum, that would be an acceptable alternative. Also, I disagree with the premise that the row needs to be destroyed by the same protocol which created it. If a human being wants to take down an LSP which was created via signalling what is the problem with that? I would also like to understand what the agent is supposed to return for an error code in this situation? -Thanks, Joan From owner-mpls@UU.NET Thu Apr 6 20:41:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17596 for ; Thu, 6 Apr 2000 20:41:36 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijuw28531; Fri, 7 Apr 2000 00:41:37 GMT Received: by mail-control.mail.uu.net id QQijuw22825 for mpls-outgoing; Fri, 7 Apr 2000 00:41:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijuw22808 for ; Fri, 7 Apr 2000 00:41:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijuw23427 for ; Thu, 6 Apr 2000 20:40:55 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijuw27607 for ; Fri, 7 Apr 2000 00:40:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA22377 for mpls@uu.net; Thu, 6 Apr 2000 20:40:54 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijuw22711 for ; Fri, 7 Apr 2000 00:40:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijuw23392 for ; Thu, 6 Apr 2000 20:40:17 -0400 (EDT) Received: from tnnt3.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQijuw23373 for ; Fri, 7 Apr 2000 00:40:17 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id <2NCNF34T>; Thu, 6 Apr 2000 20:41:51 -0400 Message-ID: From: Cheenu Srinivasan To: "'Cucchiara, Joan'" , "'Thomas D. Nadeau'" , "'Arun Viswanathan'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Thu, 6 Apr 2000 20:41:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA02A.1032588E" 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_01BFA02A.1032588E Content-Type: text/plain; charset="iso-8859-1" > > >Joan's question in (): > > >(why? don't you think you need these other > > >ways of configuring for completeness of this object?) > > > > What the intent was with this object was to > > identify either the signaling protocol, policy agent > > (i.e.: COPS), agent (SNMP) or "other" configuration of this > > object. The point here was to let external sources know > > that if they did not create an object, that they may not > > be allowed to delete/modify it depending on the implementation. > > We distinguished SNMP since it seemed obvious. We also provided > > "other" for managers who did not want to use "SNMP", but wanted > > to note that something else configured the object (i.e.: cli, > > web, etc...). > > > > >Also, why is policyAgent one of the choices, this is > > >a MIB and it was my understanding that policyAgent's used > > >PIBs. PolicyAgents can't support RowStatus, so I believe > > >that choice should be removed. > > > > > > The PIB may not support RowStatus, but the agent which > > >interacts with the PIB/PolicyAgent may create an entry. It > > >is our intent for this enumeration to note this case. > > > > > >Joan's comments in (): > > >(This may or may not be the case, it is not yet > > >defined what the interactions between the Policy Agent and > > >the SNMP Agent are going to be. You have no way to know > > >if the Policy Agent will be able to inform the SNMP Agent > > >to create a Row or any other MIB entries for that matter. > > > > As you pointed out, it may or may not be the case. We > > are focusing on the "may" case. I believe the original request > > for this object came from one of the reference implementations. > > > It is not acceptable to put enums like this in a standard mib > which "may" be defined. If the interaction between a policyAgent > and an SNMP Agent for row-creation is ever defined, it is a long > long way off (YEARS). By then this MIB will be on its 57th > revision :) Let me try to clarify before we drift too far afield (if we haven't already). The intent of this object is to indicate the owner/creator of this conceptual row. Just because we expose something via an SNMP interface does not mean that these are/should be manipulated via SNMP. This is true of all the standard MIBs we have out there. The interaction/interface between the owner of the object and the LSR is irrelevant here. This applies equally to any of the signaling protocols, a policy agent etc. Any of them can and probably will use a proprietary interface to create objects inside the LSR. Do you imagine that LDP or RSVP is going to issue SNMP protocol requests to create/configure anything? The concept of a PIB is also irrelevant here for the same reason and only governs the interaction between the policy server and policy agent. Cheenu ------_=_NextPart_001_01BFA02A.1032588E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: LSR MIB comments and questions

> > >Joan's question in ():
> > >(why? don't you think you need these = other
> > >ways of configuring for completeness = of this object?)
> >
> = >          What the = intent was with this object was to
> > identify either the signaling protocol, = policy agent
> > (i.e.: COPS), agent (SNMP) or = "other" configuration of this
> > object. The point here was to let external = sources know
> > that if they did not create an object, = that they may not
> > be allowed to delete/modify it depending = on the implementation.
> > We distinguished SNMP since it seemed = obvious. We also provided
> > "other" for managers who did not = want to use "SNMP", but wanted
> > to note that something else configured the = object (i.e.: cli,
> > web, etc...).
> >
> > >Also, why is policyAgent one of the = choices, this is
> > >a MIB and it was my understanding that = policyAgent's used
> > >PIBs.  PolicyAgents can't support = RowStatus, so I believe
> > >that choice should be removed.
> > >
> > = >         The PIB may not = support RowStatus, but the agent which
> > >interacts with the PIB/PolicyAgent may = create an entry. It
> > >is our intent for this enumeration to = note this case.
> > >
> > >Joan's comments in ():
> > >(This may or may not be the case, it = is not yet
> > >defined what the interactions between = the Policy Agent and
> > >the SNMP Agent are going to be.  = You have no way to know
> > >if the Policy Agent will be able to = inform the SNMP Agent
> > >to create a Row or any other MIB = entries for that matter.
> >
> = >          As you = pointed out, it may or may not be the case. We
> > are focusing on the "may" case. = I believe the original request
> > for this object came from one of the = reference implementations.
>
>
> It is not acceptable to put enums like this in = a standard mib
> which "may" be defined.  If the = interaction between a policyAgent
> and an SNMP Agent for row-creation is ever = defined, it is a long
> long way off (YEARS).  By then this MIB = will be on its 57th
> revision :)

Let me try to clarify before we drift too far afield = (if we haven't already).

The intent of this object is to indicate the = owner/creator of this
conceptual row. Just because we expose something via = an SNMP interface
does not mean that these are/should be manipulated = via SNMP. This is
true of all the standard MIBs we have out there. = The
interaction/interface between the owner of the = object and the LSR is
irrelevant here. This applies equally to any of the = signaling protocols,
a policy agent etc. Any of them can and probably = will use a proprietary
interface to create objects inside the LSR. Do you = imagine that
LDP or RSVP is going to issue SNMP protocol requests = to create/configure
anything? The concept of a PIB is also irrelevant = here for the same reason
and only governs the interaction between the policy = server and policy
agent.

Cheenu

------_=_NextPart_001_01BFA02A.1032588E-- From owner-mpls@UU.NET Thu Apr 6 21:07:19 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17798 for ; Thu, 6 Apr 2000 21:07:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijuy22504; Fri, 7 Apr 2000 01:07:20 GMT Received: by mail-control.mail.uu.net id QQijuy02103 for mpls-outgoing; Fri, 7 Apr 2000 01:07:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijuy02098 for ; Fri, 7 Apr 2000 01:06:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijuy22533 for ; Thu, 6 Apr 2000 21:06:53 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijuy21923 for ; Fri, 7 Apr 2000 01:06:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA24417 for mpls@uu.net; Thu, 6 Apr 2000 21:06:52 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijuy02089 for ; Fri, 7 Apr 2000 01:06:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijuy22463 for ; Thu, 6 Apr 2000 21:06:35 -0400 (EDT) Received: from foxhound.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: foxhound.cisco.com [171.69.192.161]) id QQijuy21609 for ; Fri, 7 Apr 2000 01:06:35 GMT Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id SAA26980; Thu, 6 Apr 2000 18:06:16 -0700 (PDT) From: Keith McCloghrie Message-Id: <200004070106.SAA26980@foxhound.cisco.com> Subject: Re: LSR MIB comments and questions To: JCucchiara@Brixnet.com (Cucchiara Joan) Date: Thu, 6 Apr 2000 18:06:15 -0700 (PDT) Cc: tnadeau@cisco.com ('Thomas D. Nadeau'), JCucchiara@Brixnet.com (Cucchiara Joan), arun@force10networks.com ('Arun Viswanathan'), cheenu@tachion.com ('cheenu@tachion.com'), mpls@UU.NET ('mpls@uu.net') In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F96B@brixcorp2.brixnet.com> from "Cucchiara, Joan" at Apr 06, 2000 08:21:38 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > >Are you planning on specifying in the enum the > > >other possibilities (cli, config file, web, etc...)? > > > > > > No. > > > > > >Joan's question in (): > > >(why? don't you think you need these other > > >ways of configuring for completeness of this object?) > > > > What the intent was with this object was to > > identify either the signaling protocol, policy agent > > (i.e.: COPS), agent (SNMP) or "other" configuration of this > > object. The point here was to let external sources know > > that if they did not create an object, that they may not > > be allowed to delete/modify it depending on the implementation. > > We distinguished SNMP since it seemed obvious. We also provided > > "other" for managers who did not want to use "SNMP", but wanted > > to note that something else configured the object (i.e.: cli, > > web, etc...). > > > > >Also, why is policyAgent one of the choices, this is > > >a MIB and it was my understanding that policyAgent's used > > >PIBs. PolicyAgents can't support RowStatus, so I believe > > >that choice should be removed. > > > > > > The PIB may not support RowStatus, but the agent which > > >interacts with the PIB/PolicyAgent may create an entry. It > > >is our intent for this enumeration to note this case. > > > > > >Joan's comments in (): > > >(This may or may not be the case, it is not yet > > >defined what the interactions between the Policy Agent and > > >the SNMP Agent are going to be. You have no way to know > > >if the Policy Agent will be able to inform the SNMP Agent > > >to create a Row or any other MIB entries for that matter. > > > > As you pointed out, it may or may not be the case. We > > are focusing on the "may" case. I believe the original request > > for this object came from one of the reference implementations. > > It is not acceptable to put enums like this in a standard mib > which "may" be defined. If the interaction between a policyAgent > and an SNMP Agent for row-creation is ever defined, it is a long > long way off (YEARS). By then this MIB will be on its 57th revision :) Actually, the "interaction between a policyAgent and an SNMP Agent for row-creation" is already defined. > There is not one other standard's track MIB which indicates whether a > row was created by a policyAgent/PIB vs. a snmpAgent/MIB. > If someone really wants this enum then it belongs in their enterprise > MIB and NOT in a standard MIB. Actually, Kwok Ho Chan (khchan@nortelnetworks.com) proposed included similar information in the DiffServ MIB some time ago. If multiple vendors want it, then perhaps it does belong in some standard MIB. > Could you take this policyAgent enum out now and put it in > when someone describes how a Policy Agent instructs an SNMP agent > to create a row? A Policy Agent does *not* instruct an SNMP agent to create a row. Rather, the Policy Agent creates the underlying instrumentation, i.e., a DiffServ Classifier, or an LSP, or whatever, based on instructions it receives using the features of whatever protocol it happens to be using. Once it is created, it shows up in the SNMP MIB. RowStatus is needed only when a row is to be created/modified/deleted using SNMP Sets. For example, some people (but not me) believe that a Policy Agent should extract policies directly out of a Directory using LDAP, but that doesn't mean the LDAP schema needs a RowStatus in it. > Also, I disagree with the premise that the row needs to be destroyed > by the same protocol which created it. If a human being wants to > take down an LSP which was created via signalling what is the problem > with that? I would also like to understand what the agent is supposed > to return for an error code in this situation? I agree with this. Keith. From owner-mpls@UU.NET Thu Apr 6 21:46:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18654 for ; Thu, 6 Apr 2000 21:46:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijvb26103; Fri, 7 Apr 2000 01:46:54 GMT Received: by mail-control.mail.uu.net id QQijvb04464 for mpls-outgoing; Fri, 7 Apr 2000 01:46:34 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijvb04459 for ; Fri, 7 Apr 2000 01:46:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijvb26013 for ; Thu, 6 Apr 2000 21:46:23 -0400 (EDT) Received: from research.gate.nec.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: research.gate.nec.co.jp [202.247.6.217]) id QQijvb25467 for ; Fri, 7 Apr 2000 01:46:13 GMT Received: from tomato.nwk.cl.nec.co.jp (IDENT:yG4A8uMNL0WDZwXkjdIgMnHyMLLxdXto@tomato.nwk.cl.nec.co.jp [10.56.32.1]) by research.gate.nec.co.jp (8.9.3+3.2W/000201) with ESMTP id KAA27414; Fri, 7 Apr 2000 10:45:48 +0900 (JST) Received: from tea.nwk.cl.nec.co.jp by tomato.nwk.cl.nec.co.jp (8.9.3/NWKM20000322) with ESMTP id KAA73524; Fri, 7 Apr 2000 10:45:47 +0900 (JST) Received: from iwata-pc2 (iwata-pc2.nwk.cl.nec.co.jp [10.56.32.77]) by tea.nwk.cl.nec.co.jp (8.9.0/3.7W) with ESMTP id KAA00406; Fri, 7 Apr 2000 10:45:46 +0900 (JST) Message-Id: <4.2.0.58.J.20000407104840.009ca420@tea.nwk.cl.nec.co.jp> X-Sender: iwata@tea.nwk.cl.nec.co.jp Reply-To: iwata@ccm.CL.nec.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 07 Apr 2000 10:54:30 +0900 To: "Don Fedyk" From: Atsushi Iwata Subject: RE: Any more comments on draft-ietf-mpls-te-feed-00.txt? Cc: "Peter Ashwood-Smith" , MPLS mailing list , Norihito Fujita In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear Don Fedyk, Thank you for your reponse. I understand the target of your draft. Could you add any sections which clarify the current limitation of your draft, such as not supporting unnumbered links, or something like that ? Regards, At 12:56 00/04/06 -0500, Don Fedyk wrote: >Dear Atsushi Iwata, > >The feedback draft is aimed at numbered links only. The cycle is >a path is selected from a topology database that is populated by >an IGP. Both IGPs use the same format so it does not matter which >IGP. The path becomes the ER MPLS LSP. > >Next the ER LSP is established and our Draft uses CR-LDP to accomplish >this. If a link that is not able to support the path is encountered, >the bandwidth profile (independent of the IGP for the number link) is >added to the failure notification. This information is generated for >every link along the traversed section of the path. > >This information can then be added to the topology database improving its >accuracy for all subsequent path requests. > >A crankback as you describe cannot update the database since it may >not have an accurate bandwidth profile. This could happen if you >encountered a node that did not support the feedback. So crankback >could be the degenerate case of feedback. > >ER paths can support un-numbered links in some cases. When the path is >loose routed, for example, but this is not the constraint based case >we were covering in the draft. > >Don > > > -----Original Message----- > > From: Atsushi Iwata > [mailto:iwata@ccm.CL.nec.co.jp] > > Sent: Wednesday, April 05, 2000 8:30 PM > > To: Ashwood-Smith, Peter [CAR:CS57:EXCH] > > Cc: MPLS mailing list; Norihito Fujita > > Subject: Re: Any more comments on draft-ietf-mpls-te-feed-00.txt? > > > > > > Hi, Peter, > > > > I have one comment. > > > > At 10:17 00/04/05 -0400, Peter Ashwood-Smith wrote: > > >RE: draft-ietf-mpls-te-feed-00 > > > > > > Still looking for feedback on the feedback draft ... pun > > >intended. > > > > > > I will be asking the WG chairs for a last call on this in the > > >next few days unless somebody has some issues with it. > > > > As I explained our draft, > > draft-fujita-mpls-crldp-crankback-00.txt, in the > > last IETF, there are several possibilities of indicating of > > links or nodes. > > If you use unnumbered point-to-point links between routers, > > you cannot > > specify IPv4 address of interfaces for IPV4 specificed link > > feedback TLV > > and IPV6 specified link feedback TLV. In that case, you have to use a > > routing protocol (OSPF etc) dependent TLV to indicate links or nodes. > > > > Our draft specifies protocol independent TLV (using ER-HOPS > > information) > > and routing protocol dependent TLV (OSPF, ISIS-specific > > information). I > > guess that our draft could be an one of possible solution to > > indicate such > > links or nodes. > > > > What do you think ? > > > > Best regards, > > ---------------------------------------------------------------- > > Atsushi Iwata > > Assistant Manager > > Network Architecture TG, Networking Research Laboratory > > C&C Media Research Laboratories > > NEC Corporation > > 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 > > TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) > > NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 > > E-mail: a-iwata@ah.jp.nec.com > > > > ** New organization has started since Apr.1, 2000. *** > > > > ---------------------------------------------------------------- Atsushi Iwata Assistant Manager Network Architecture TG, Networking Research Laboratory C&C Media Research Laboratories, NEC Corporation 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 Internet E-mail: a-iwata@ah.jp.nec.com NEC-internal E-mail: iwata@ccm.CL.nec.co.jp ** New organization has started since Apr.1, 2000. *** From owner-mpls@UU.NET Thu Apr 6 22:08:23 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19181 for ; Thu, 6 Apr 2000 22:08:23 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijvc15825; Fri, 7 Apr 2000 02:08:25 GMT Received: by mail-control.mail.uu.net id QQijvc13373 for mpls-outgoing; Fri, 7 Apr 2000 02:08:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijvc13364 for ; Fri, 7 Apr 2000 02:07:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijvc28108 for ; Thu, 6 Apr 2000 22:07:49 -0400 (EDT) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQijvc14884 for ; Fri, 7 Apr 2000 02:07:48 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id TAA26087; Thu, 6 Apr 2000 19:07:44 -0700 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 19:07:44 -0700 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346873@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Cucchiara, Joan'" , "'Thomas D. Nadeau'" , "'Arun Viswanathan'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Thu, 6 Apr 2000 19:07:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, > > >Joan's comments in (): > > >(This may or may not be the case, it is not yet > > >defined what the interactions between the Policy Agent and > > >the SNMP Agent are going to be. You have no way to know > > >if the Policy Agent will be able to inform the SNMP Agent > > >to create a Row or any other MIB entries for that matter. > > > > As you pointed out, it may or may not be the case. We > > are focusing on the "may" case. I believe the original request > > for this object came from one of the reference implementations. > > > It is not acceptable to put enums like this in a standard mib > which "may" be defined. If the interaction between a policyAgent > and an SNMP Agent for row-creation is ever defined, it is a long > long way off (YEARS). For some it may be years away, perhaps not so for others. Besides, the policy agent doesn't have to go through SNMP agent to create entries in the table. There is no need for a standard on how policy agent creates entries in the LIB. > By then this MIB will be on its 57th > revision :) At this rate even version 1 looks remote to me :-) > > There is not one other standard's track MIB which indicates whether a > row was created by a policyAgent/PIB vs. a snmpAgent/MIB. > If someone really wants this enum then it belongs in their enterprise > MIB and NOT in a standard MIB. > > Could you take this policyAgent enum out now and put it in > when someone describes how a Policy Agent instructs an SNMP agent > to create a row? > > If you could remove the policyAgent enum and the SNMP enum and > just use a generic "mgmt" enum, that would be an acceptable > alternative. What your are suggesting is useless and doesn't serve any purpose. Just defining one enum defeats the whole purpose of this object. How do you suggest we track which entity created a row in this table? > > Also, I disagree with the premise that the row needs to be destroyed > by the same protocol which created it. This is a non-issue. This is an implementation choice. > If a human being wants to > take down an LSP which was created via signalling what is the problem > with that? Same as above. > I would also like to understand what the agent is supposed > to return for an error code in this situation? > I think you are laboring a rather innocuous but useful object. The ONLY purpose of the object is to track which entity created an entry in the table for the purpose of trouble-shooting and reporting. The object's purpose is NOT to allow or disallow an entity from creating entries into LIB. So, even if we choose to remove some of the enum doesn't mean those entities cannot create rows in the LIB. -arun From owner-mpls@UU.NET Fri Apr 7 07:05:45 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05989 for ; Fri, 7 Apr 2000 07:05:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijwm03348; Fri, 7 Apr 2000 11:05:41 GMT Received: by mail-control.mail.uu.net id QQijwm17257 for mpls-outgoing; Fri, 7 Apr 2000 11:05:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijwm17252 for ; Fri, 7 Apr 2000 11:05:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijwm19799 for ; Fri, 7 Apr 2000 07:05:01 -0400 (EDT) Received: from relay05.netaddress.usa.net by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: relay05.netaddress.usa.net [204.68.24.185]) id QQijwm02891 for ; Fri, 7 Apr 2000 11:05:00 GMT Received: (qmail 25718 invoked from network); 7 Apr 2000 10:10:32 -0000 Received: from nwcst283.netaddress.usa.net (204.68.23.28) by outbound.netaddress.usa.net with SMTP; 7 Apr 2000 10:10:32 -0000 Received: (qmail 22909 invoked by uid 60001); 7 Apr 2000 10:10:32 -0000 Message-ID: <20000407101032.22908.qmail@nwcst283.netaddress.usa.net> Received: from 204.68.23.28 by nwcst283 for [165.133.13.22] via web-mailer(M3.4.0.33) on Fri Apr 7 10:10:32 GMT 2000 Date: 7 Apr 00 04:10:32 MDT From: Babla Babla To: mpls@UU.NET Subject: Hello X-Mailer: USANET web-mailer (M3.4.0.33) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA05989 Hi! Is there any draft for support of Integrated and Differentiated Services for CR-LDP ? ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-mpls@UU.NET Fri Apr 7 09:45:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08120 for ; Fri, 7 Apr 2000 09:45:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijwx06001; Fri, 7 Apr 2000 13:45:30 GMT Received: by mail-control.mail.uu.net id QQijww16853 for mpls-outgoing; Fri, 7 Apr 2000 13:44:53 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijww16845 for ; Fri, 7 Apr 2000 13:44:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijww08976 for ; Fri, 7 Apr 2000 09:44:44 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.104.68.2]) id QQijww05418 for ; Fri, 7 Apr 2000 13:44:43 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Apr 2000 07:42:38 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE76F619B@BGSLC02> From: Irwin Lazar To: "'Babla Babla'" , mpls@UU.NET Subject: RE: Hello Date: Fri, 7 Apr 2000 07:42:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk There are several related drafts on the MPLS Resource Center - http://www.mplsrc.com/ Irwin -----Original Message----- From: Babla Babla [mailto:babla_76@usa.net] Sent: Friday, April 07, 2000 6:11 AM To: mpls@UU.NET Subject: Hello Hi! Is there any draft for support of Integrated and Differentiated Services for CR-LDP ? ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-mpls@UU.NET Fri Apr 7 10:32:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09008 for ; Fri, 7 Apr 2000 10:32:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijxa19262; Fri, 7 Apr 2000 14:32:50 GMT Received: by mail-control.mail.uu.net id QQijxa28020 for mpls-outgoing; Fri, 7 Apr 2000 14:32:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijxa28015 for ; Fri, 7 Apr 2000 14:32:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijxa17106 for ; Fri, 7 Apr 2000 10:32:10 -0400 (EDT) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQijxa05171 for ; Fri, 7 Apr 2000 14:32:10 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Fri, 7 Apr 2000 10:31:38 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A48CFFB@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: encoding 2 labels in vpi/vci fieds Date: Fri, 7 Apr 2000 10:31:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, In the back of my mind I have this recolection of reading about this possible encoding - the VPI encodes the top level label and the VCI the next higher label. I think it was in atm-mpls-00, but I don't have that version anymore. In the current atm-mpls-02 this encoding not mentioned. Is this a valid way to encode labels over ATM ? Thanx. From owner-mpls@UU.NET Fri Apr 7 10:52:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09567 for ; Fri, 7 Apr 2000 10:52:59 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijxb01870; Fri, 7 Apr 2000 14:52:55 GMT Received: by mail-control.mail.uu.net id QQijxb29238 for mpls-outgoing; Fri, 7 Apr 2000 14:52:22 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijxb29212 for ; Fri, 7 Apr 2000 14:52:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijxb19146 for ; Fri, 7 Apr 2000 10:51:50 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijxb00222 for ; Fri, 7 Apr 2000 14:51:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA18138 for mpls@uu.net; Fri, 7 Apr 2000 10:51:49 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQijxb29068 for ; Fri, 7 Apr 2000 14:51:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijxb19022 for ; Fri, 7 Apr 2000 10:50:51 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQijxb28904 for ; Fri, 7 Apr 2000 14:50:51 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA07414; Fri, 7 Apr 2000 07:50:48 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <2J27TSHZ>; Fri, 7 Apr 2000 07:50:48 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4049D@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Abes, Andi'" , MPLS mailing list Subject: RE: encoding 2 labels in vpi/vci fieds Date: Fri, 7 Apr 2000 07:48:05 -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 Abes, Check section 3.25.2. of : http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-06.txt -Shahram >-----Original Message----- >From: Abes, Andi [mailto:aabes@quarrytech.com] >Sent: Friday, April 07, 2000 10:32 AM >To: MPLS mailing list >Subject: encoding 2 labels in vpi/vci fieds > > >Hi, > >In the back of my mind I have this recolection of reading about this >possible encoding - >the VPI encodes the top level label and the VCI the next higher label. > >I think it was in atm-mpls-00, but I don't have that version anymore. >In the current atm-mpls-02 this encoding not mentioned. > >Is this a valid way to encode labels over ATM ? > > >Thanx. > From owner-mpls@UU.NET Fri Apr 7 11:03:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09789 for ; Fri, 7 Apr 2000 11:03:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijxc17812; Fri, 7 Apr 2000 15:03:42 GMT Received: by mail-control.mail.uu.net id QQijxc03768 for mpls-outgoing; Fri, 7 Apr 2000 15:03:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijxc03597 for ; Fri, 7 Apr 2000 15:03:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijxc21257 for ; Fri, 7 Apr 2000 11:03:08 -0400 (EDT) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQijxc16097 for ; Fri, 7 Apr 2000 15:03:08 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 7 Apr 2000 09:56:01 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2NF79D6C>; Fri, 7 Apr 2000 09:55:03 -0500 Message-ID: From: "Don Fedyk" To: iwata@ccm.CL.nec.co.jp Cc: "Peter Ashwood-Smith" , MPLS mailing list , Norihito Fujita Subject: RE: Any more comments on draft-ietf-mpls-te-feed-00.txt? Date: Fri, 7 Apr 2000 09:55:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA0A1.402BB20C" 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_01BFA0A1.402BB20C Content-Type: text/plain; charset="iso-8859-1" Dear Atsushi Iwata Usually, we do not specify limitations that are required attributes of the design. Numbered links are a required part of the current TE design. Don > -----Original Message----- > From: Atsushi Iwata [mailto:iwata@ccm.CL.nec.co.jp] > Sent: Thursday, April 06, 2000 9:55 PM > To: Fedyk, Don [BL60:2001:EXCH] > Cc: Ashwood-Smith, Peter [CAR:CS57:EXCH]; MPLS mailing list; Norihito > Fujita > Subject: RE: Any more comments on draft-ietf-mpls-te-feed-00.txt? > > > Dear Don Fedyk, > > Thank you for your reponse. > > I understand the target of your draft. > Could you add any sections which clarify the current > limitation of your > draft, such as not supporting unnumbered links, or something > like that ? > > Regards, > > At 12:56 00/04/06 -0500, Don Fedyk wrote: > > >Dear Atsushi Iwata, > > > >The feedback draft is aimed at numbered links only. The cycle is > >a path is selected from a topology database that is populated by > >an IGP. Both IGPs use the same format so it does not matter which > >IGP. The path becomes the ER MPLS LSP. > > > >Next the ER LSP is established and our Draft uses CR-LDP to > accomplish > >this. If a link that is not able to support the path is encountered, > >the bandwidth profile (independent of the IGP for the number link) is > >added to the failure notification. This information is generated for > >every link along the traversed section of the path. > > > >This information can then be added to the topology database > improving its > >accuracy for all subsequent path requests. > > > >A crankback as you describe cannot update the database since it may > >not have an accurate bandwidth profile. This could happen if you > >encountered a node that did not support the feedback. So crankback > >could be the degenerate case of feedback. > > > >ER paths can support un-numbered links in some cases. When > the path is > >loose routed, for example, but this is not the constraint based case > >we were covering in the draft. > > > >Don > > > > ---------------------------------------------------------------- > Atsushi Iwata > Assistant Manager > Network Architecture TG, Networking Research Laboratory > C&C Media Research Laboratories, NEC Corporation > 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 > TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) > NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 > Internet E-mail: a-iwata@ah.jp.nec.com > NEC-internal E-mail: iwata@ccm.CL.nec.co.jp > > ** New organization has started since Apr.1, 2000. *** > > ------_=_NextPart_001_01BFA0A1.402BB20C Content-Type: text/html; charset="iso-8859-1" RE: Any more comments on draft-ietf-mpls-te-feed-00.txt?

Dear Atsushi Iwata

Usually, we do not specify limitations that are required attributes of
the design. Numbered links are a required part of the current TE design.

Don


> -----Original Message-----
> From: Atsushi Iwata [mailto:iwata@ccm.CL.nec.co.jp]
> Sent: Thursday, April 06, 2000 9:55 PM
> To: Fedyk, Don [BL60:2001:EXCH]
> Cc: Ashwood-Smith, Peter [CAR:CS57:EXCH]; MPLS mailing list; Norihito
> Fujita
> Subject: RE: Any more comments on draft-ietf-mpls-te-feed-00.txt?
>
>
> Dear Don Fedyk,
>
> Thank you for your reponse.
>
> I understand the target of your draft.
> Could you add any sections which clarify the current
> limitation of your
> draft, such as not supporting unnumbered links, or something
> like that ?
>
> Regards,
>
> At 12:56 00/04/06 -0500, Don Fedyk wrote:
>
> >Dear Atsushi Iwata,
> >
> >The feedback draft is aimed at numbered links only. The cycle is
> >a path is selected from a topology database that is populated by
> >an IGP. Both IGPs use the same format so it does not matter which
> >IGP. The path becomes the ER MPLS LSP.
> >
> >Next the ER LSP is established and our Draft uses CR-LDP to
> accomplish
> >this. If a link that is not able to support the path is encountered,
> >the bandwidth profile (independent of the IGP for the number link) is
> >added to the failure notification. This information is generated for
> >every link along the traversed section of the path.
> >
> >This information can then be added to the topology database
> improving its
> >accuracy for all subsequent path requests.
> >
> >A crankback as you describe cannot update the database since it may
> >not have an accurate bandwidth profile. This could happen if you
> >encountered a node that did not support the feedback. So crankback
> >could be the degenerate case of feedback.
> >
> >ER paths can support un-numbered links in some cases. When
> the path is
> >loose routed, for example, but this is not the constraint based case
> >we were covering in the draft.
> >
> >Don
> >
>
> ----------------------------------------------------------------
> Atsushi Iwata
> Assistant Manager
> Network Architecture TG, Networking Research Laboratory
> C&C Media Research Laboratories, NEC Corporation
> 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555
> TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
> NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
> Internet E-mail:     a-iwata@ah.jp.nec.com
> NEC-internal E-mail: iwata@ccm.CL.nec.co.jp
>
> ** New organization has started since Apr.1, 2000. ***
>
>

------_=_NextPart_001_01BFA0A1.402BB20C-- From owner-mpls@UU.NET Fri Apr 7 11:08:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09968 for ; Fri, 7 Apr 2000 11:08:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijxc21137; Fri, 7 Apr 2000 15:08:04 GMT Received: by mail-control.mail.uu.net id QQijxc08471 for mpls-outgoing; Fri, 7 Apr 2000 15:07:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijxc08466 for ; Fri, 7 Apr 2000 15:07:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijxc23260 for ; Fri, 7 Apr 2000 11:07:04 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQijxc19931 for ; Fri, 7 Apr 2000 15:07:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA20846 for mpls@uu.net; Fri, 7 Apr 2000 11:07:02 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQijxc08395 for ; Fri, 7 Apr 2000 15:06:37 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijxc21841 for ; Fri, 7 Apr 2000 11:06:32 -0400 (EDT) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQijxc19711 for ; Fri, 7 Apr 2000 15:06:31 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Apr 2000 16:06:19 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E140659@monk.datcon.co.uk> From: Paul Brittain To: "Abes, Andi" , MPLS mailing list Subject: RE: encoding 2 labels in vpi/vci fieds Date: Fri, 7 Apr 2000 16:06:23 +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 Andi, I think there was a discussion in an earlier draft on ATM VP-switching (draft-feldman-mpls-atmvp??) that likened use of VP switching to the use of a VCI lower label within a VPI top label. However the MPLS Architecture doesn't treat VP switching like this any more - it just considers it to be a means of achieving label merge. I think the only currently documented way to carry a label stack in ATM is to put the top-most label in the cell header and carry the lower labels in shim headers on the packet. Hope this helps, Paul. -----Original Message----- From: Abes, Andi [mailto:aabes@quarrytech.com] Sent: 07 April 2000 15:32 To: MPLS mailing list Subject: encoding 2 labels in vpi/vci fieds Hi, In the back of my mind I have this recolection of reading about this possible encoding - the VPI encodes the top level label and the VCI the next higher label. I think it was in atm-mpls-00, but I don't have that version anymore. In the current atm-mpls-02 this encoding not mentioned. Is this a valid way to encode labels over ATM ? Thanx. From owner-mpls@UU.NET Fri Apr 7 13:06:09 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12678 for ; Fri, 7 Apr 2000 13:06:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijxk01180; Fri, 7 Apr 2000 17:05:59 GMT Received: by mail-control.mail.uu.net id QQijxk02079 for mpls-outgoing; Fri, 7 Apr 2000 17:05:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijxk02057 for ; Fri, 7 Apr 2000 17:05:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijxk12729 for ; Fri, 7 Apr 2000 13:05:18 -0400 (EDT) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQijxk00469 for ; Fri, 7 Apr 2000 17:05:17 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Fri, 7 Apr 2000 13:04:45 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A48D000@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: RE: Higher labels and RSVP Date: Fri, 7 Apr 2000 13:04:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi again, thanx to Shahram Davari for giving me the reference - The MPLS arch allows (section 3.25.2 - bullet 2. SVP Encoding) to encode 2 labels in the VPI/VCI fields, and states that this might not always be usable. So, when allocating a higher label (not a top one), it could concievably by used in an SVP encoding - like in the case of 2 directly connected LSR using LCATM interfaces. In this case, the second label has to be from a per-interface label pool. Is this encoding still supported ? Any of this make sense ? Can a statement that says that higher level label are always from the per-platform label space still be made ? Andi. > -----Original Message----- > From: Abes, Andi [mailto:aabes@quarrytech.com] > Sent: Thursday, April 06, 2000 11:33 AM > To: MPLS mailing list > Subject: Higher labels and RSVP > > > Hi, > > I'm trying to resolve a question that looked simple at first: > > Is it correct to say that higher level labels can only be > drawn from the > per-platform label space ? > > At first it seemed natural, and then I even found in my > archives discussions > before the BGP draft was issued that reinforced my conviction: > > since packets labeld with BGP labels can arrive at an LSR > over different > interfaces, and the route my vary depending on IGP activity, > at packet reception time - the LSR can not tell by what interface the > labeled > packet should have arrived at. > > > This is all fine, and sound fine for BGP assigned labels. But... > When labels are assigned using RSVP the whole label stack > is assigned at once - such that it depends on the semantics - > is the label stack valid only as a whole ? > Can the LSR that received the label binding (with 2+ labels) > use the higher levels stacked on other top labels ? > > If the former is the case - then per-interface label space > can be used. > if the latter, then only per-platform space can be used. > > To make things interesting, in draft-swallow-rsvp-bypass-label-00 it > is explicitly assumed that the higher labels can be used with > different > top labels (one for the original tunnel and a different one > for the bypass > tunnel). > > Ok, > so what say you ? > > > Andi. > > > > > > From owner-mpls@UU.NET Fri Apr 7 14:07:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14023 for ; Fri, 7 Apr 2000 14:07:59 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijxo06324; Fri, 7 Apr 2000 18:07:45 GMT Received: by mail-control.mail.uu.net id QQijxo13852 for mpls-outgoing; Fri, 7 Apr 2000 18:07:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijxo13844 for ; Fri, 7 Apr 2000 18:07:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQijxo21955 for ; Fri, 7 Apr 2000 14:07:02 -0400 (EDT) Received: from relay05.netaddress.usa.net by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: relay05.netaddress.usa.net [204.68.24.185]) id QQijxo25946 for ; Fri, 7 Apr 2000 18:07:01 GMT Received: (qmail 26680 invoked from network); 7 Apr 2000 11:51:55 -0000 Received: from nwcst322.netaddress.usa.net (204.68.23.67) by outbound.netaddress.usa.net with SMTP; 7 Apr 2000 11:51:55 -0000 Received: (qmail 28028 invoked by uid 60001); 7 Apr 2000 11:51:55 -0000 Message-ID: <20000407115155.28027.qmail@nwcst322.netaddress.usa.net> Received: from 204.68.23.67 by nwcst322 for [165.133.13.22] via web-mailer(M3.4.0.33) on Fri Apr 7 11:51:55 GMT 2000 Date: 7 Apr 00 05:51:55 MDT From: Babla Babla To: mpls@UU.NET Subject: CR-LDP X-Mailer: USANET web-mailer (M3.4.0.33) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA14023 Hi Everybody, I have few questions: 1. Is Multipoint-to-point LSPs same as Label Merging? 2. Do CR-LDP support Multipoint-to-point LSPs? 3. RSVP supports Class of Service like Guaranteed Service and Control Load.How does this is provided through CR-LDP. 4. In traffic parameter TLV, there are 3 fields: a. PBS : Peak Burst Size b. CBS : Committed Burst Size c. EBS : Excess Burst Size Whats the relation between these . ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-mpls@UU.NET Fri Apr 7 16:50:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18138 for ; Fri, 7 Apr 2000 16:50:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQijxz13601; Fri, 7 Apr 2000 20:49:37 GMT Received: by mail-control.mail.uu.net id QQijxz11470 for mpls-outgoing; Fri, 7 Apr 2000 20:49:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQijxz11462 for ; Fri, 7 Apr 2000 20:49:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijxz20666 for ; Fri, 7 Apr 2000 16:48:08 -0400 (EDT) Received: from smtprich.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprich.nortel.com [192.135.215.8]) id QQijxz19999 for ; Fri, 7 Apr 2000 20:48:04 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Fri, 7 Apr 2000 15:48:40 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2NF79QV4>; Fri, 7 Apr 2000 15:47:38 -0500 Message-ID: From: "Don Fedyk" To: Babla Babla , mpls@UU.NET Subject: RE: CR-LDP Date: Fri, 7 Apr 2000 15:47:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA0D2.829F78AE" 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_01BFA0D2.829F78AE Content-Type: text/plain; charset="iso-8859-1" Babla You must be new to the MPLS list! Please see documents listed below, Don > -----Original Message----- > From: Babla Babla [mailto:babla_76@usa.net] > Sent: Friday, April 07, 2000 7:52 AM > To: mpls@UU.NET > Subject: CR-LDP > > > Hi Everybody, > I have few questions: > 1. Is Multipoint-to-point LSPs same as Label Merging? Please refer to: draft-ietf-mpls-arch-06.txt > 2. Do CR-LDP support Multipoint-to-point LSPs? No Niether of the Constraint based signaling protocols do. See: draft-ietf-mpls-cr-ldp-03.txt > 3. RSVP supports Class of Service like Guaranteed Service and > Control Load.How > does this is provided through CR-LDP. See :draft-aboulmagd-srvc-def-crldp-00.txt > 4. In traffic parameter TLV, there are 3 fields: > a. PBS : Peak Burst Size > b. CBS : Committed Burst Size > c. EBS : Excess Burst Size > Whats the relation between these . > ------_=_NextPart_001_01BFA0D2.829F78AE Content-Type: text/html; charset="iso-8859-1" RE: CR-LDP

Babla

You must be new to the MPLS list!

Please see documents listed below,

Don

> -----Original Message-----
> From: Babla Babla [mailto:babla_76@usa.net]
> Sent: Friday, April 07, 2000 7:52 AM
> To: mpls@UU.NET
> Subject: CR-LDP
>
>
> Hi Everybody,
> I have few questions:
> 1. Is Multipoint-to-point LSPs same as Label Merging?

Please refer to: draft-ietf-mpls-arch-06.txt

> 2. Do CR-LDP support Multipoint-to-point LSPs?

No Niether of the Constraint based signaling protocols do.
See: draft-ietf-mpls-cr-ldp-03.txt

> 3. RSVP supports Class of Service like Guaranteed Service and
> Control Load.How
> does this is provided through CR-LDP.

See :draft-aboulmagd-srvc-def-crldp-00.txt

> 4. In traffic parameter TLV, there are 3 fields:
>  a. PBS : Peak Burst Size
>  b. CBS : Committed Burst Size
>  c. EBS : Excess Burst Size   
> Whats the relation between these .
>

------_=_NextPart_001_01BFA0D2.829F78AE-- From owner-mpls@UU.NET Mon Apr 10 01:07:15 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20072 for ; Mon, 10 Apr 2000 01:07:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikgq21130; Mon, 10 Apr 2000 05:07:08 GMT Received: by mail-control.mail.uu.net id QQikgq27719 for mpls-outgoing; Mon, 10 Apr 2000 05:06:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQikgq27714 for ; Mon, 10 Apr 2000 05:06:28 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikgq04595 for ; Mon, 10 Apr 2000 01:06:20 -0400 (EDT) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQikgq01877 for ; Mon, 10 Apr 2000 05:06:19 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id <2CFS5ZXD>; Sun, 9 Apr 2000 22:05:59 -0700 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Subject: LSR MIB last call Date: Sun, 9 Apr 2000 22:05:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA2AA.755DA678" 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_01BFA2AA.755DA678 Content-Type: text/plain; charset="iso-8859-1" The LSR MIB last call has closed. Would the authors please update the draft based on comments received during the last call and publish a new version asap? Thanks, - Vijay ------_=_NextPart_001_01BFA2AA.755DA678 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LSR MIB last call

The LSR MIB last call has closed.  Would the = authors please update the draft based on comments received during the = last call and publish a new version asap?

Thanks,
- Vijay

------_=_NextPart_001_01BFA2AA.755DA678-- From owner-mpls@UU.NET Mon Apr 10 01:11:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20594 for ; Mon, 10 Apr 2000 01:11:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikgq24061; Mon, 10 Apr 2000 05:11:29 GMT Received: by mail-control.mail.uu.net id QQikgq27866 for mpls-outgoing; Mon, 10 Apr 2000 05:11:00 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQikgq27853 for ; Mon, 10 Apr 2000 05:10:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikgq07097 for ; Mon, 10 Apr 2000 01:10:26 -0400 (EDT) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQikgq04270 for ; Mon, 10 Apr 2000 05:10:26 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id <2CFS5ZXL>; Sun, 9 Apr 2000 22:10:06 -0700 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Cc: "'swallow@cisco.com'" , "'gash@att.com'" Subject: last call for draft-ietf-mpls-crlsp-modify-01.txt Date: Sun, 9 Apr 2000 22:10:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA2AB.08C68B00" 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_01BFA2AB.08C68B00 Content-Type: text/plain; charset="iso-8859-1" The authors of draft-ietf-mpls-crlsp-modify-01.txt have requested that the draft be progressed to WG last call. This e-mail serves as a commencement of last call for this document, ending in two weeks. Please post your comments to the list. Thanks, - Vijay ------_=_NextPart_001_01BFA2AB.08C68B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable last call for draft-ietf-mpls-crlsp-modify-01.txt =

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

Thanks,
- Vijay

------_=_NextPart_001_01BFA2AB.08C68B00-- From owner-mpls@UU.NET Mon Apr 10 04:31:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03466 for ; Mon, 10 Apr 2000 04:31:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikhe07075; Mon, 10 Apr 2000 08:31:30 GMT Received: by mail-control.mail.uu.net id QQikhe01561 for mpls-outgoing; Mon, 10 Apr 2000 08:31:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQikhe01536 for ; Mon, 10 Apr 2000 08:30:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQikhe22556 for ; Mon, 10 Apr 2000 04:30:48 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQikhe06603 for ; Mon, 10 Apr 2000 08:30:47 GMT Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id RAA21343 for ; Mon, 10 Apr 2000 17:30:46 +0900 (JST) (envelope-from ohta.hiroshi@nslab.ntt.co.jp) Received: from ns.nslab.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/18/00) with SMTP id RAA21798 for ; Mon, 10 Apr 2000 17:30:44 +0900 (JST) (envelope-from ohta.hiroshi@nslab.ntt.co.jp) Received: (qmail 10486 invoked from network); 10 Apr 2000 17:30:45 +0900 Received: from mx.yk.nslab.ntt.co.jp (129.60.229.2) by ns.nslab.ntt.co.jp with SMTP; 10 Apr 2000 17:30:45 +0900 Received: by mx.yk.nslab.ntt.co.jp (8.8.8+3.0Wbeta13/3.5Wpl4/yk+mx) with SMTP id RAA02980; Mon, 10 Apr 2000 17:32:03 +0900 (JST) Message-Id: <200004100832.RAA02980@mx.yk.nslab.ntt.co.jp> X-Sender: ohta.hiroshi@nslab.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5-J (32) Date: Mon, 10 Apr 2000 17:27:54 +0900 To: mpls@UU.NET From: Hiroshi Ohta Subject: ITU-T SG13 started a Recommendation on IP OAM and protection switching Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello all, My name is Hiroshi Ohta, the rapporteur on Q.6 of ITU-T SG13 which is responsible for OAM and protection switching. I would like to inform you that ITU-T Q.6/SG13 started to draft a new Recommendation on OAM and protection switching for IP-based networks. It was provisionally numbered Y.17oam. Please see the attached initial draft. I would like to welcome your contributions to the future meetings. We are planning to have a meeting as below: Date: June 26 - June 30, 2000 Place: Ottawa, Canada Objectives: The main objective is to progress the work on Y.17oam. Work on next release of Recs. I.610 and I.630 will be done if time permits. If you are interested to attend the meeting, please send me an e-mail before May 29. Best regards, Hiroshi Ohta ----------------------------------- Draft Recommendation Y.17oam OAM and protection switching for IP-based networks (Geneva, 200?) 1 Scope This Recommendation provides requirements and mechanisms for OAM functions and protection switching for IP-based networks. It is recognized that OAM (Operation and Maintenance) functionality is important in public networks for ease of network operation, for verifying network performance and to reduce network operating costs. OAM functionality is especially important for networks in which Quality of Service is an important issue. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of currently valid ITU-T Recommendations is regularly published. [References are to be added (contributions are invited).] 3. Definitions to be added (contributions are invited) 4. Symbols and abbreviations to be added (contributions are invited) 5. Requirements for OAM functions and protection switching 5.1 General requirements for IP-based networks for further study (contributions are invited) 5.2 Requirements for MPLS OAM It is to be noted that MPLS OAM functionality is not seen as a substitute for physical layer (e.g. SONET/SDH) OAM functionality. However, MPLS layer OAM functions may nevertheless be seen as desirable in addition to physical layer OAM: They will be required whenever OAM functionality is needed that permits differentiation per individual LSP. OAM functionality is useful because - it allows the Operator to verify whether Quality of Service guarantees given in SLAs (Service Level Agreements) are in fact being met by the connection, - it allows the Operator to reduce network operating costs. Long term statistics show that the costs of operating a public network are higher than the initial installation costs, - it allows the Operator to improve traffic flow/distribution through the network, and - it gives support for improved accounting/billing procedures. The following is a preliminary list of possible requirements. 1. in-service verification of connection availability (whether a connection is "up" or "down") and error performance (counting of lost frames) 2. in-service verification of delay and delay variation 3. in-service verification of connection throughput guarantees. 4. tools for fast and efficient fault detection and fault localization 5. tools for efficient network setup and configuration. 6. Traffic Engineering functionality for load-dependent route selection of traffic. 7. measurement of throughput per connection for throughput based billing 8. detection of violations to a SLA traffic contract that can be given consideration for billing. 5.3 Requirements for MPLS protection switching Protection switching for MPLS is useful because it allows the operator to improve network reliability. Details are for further study (contributions are invited). 6 Mechanisms of OAM functions and protection switching 6.1 General mechanisms for IP-based networks For further study (contributions are invited). 6.2 Mechanisms of MPLS OAM Examples of MPLS OAM functionalities are the followings: - Fault management and continuity check - Loopbacks - Performance monitoring These examples are oriented towards OAM functions defined for ATM networks. Note, however, that in defining OAM functions for MPLS networks, the intention is not necessarily to reapply ATM mechanisms without modifications. Different functions may be defined as necessary. An OAM indicator in the MPLS header could enable a simple differentiation between user packets and OAM packets in equipment supporting MPLS. Further study is required to clarify the need for such an OAM indicator and to identify a suitable encoding. 6.3 Mechanisms of MPLS protection switching For further study (contributions are invited). ---------- end of draft Y.17oam ----------- Hiroshi OHTA NTT Network Service Systems Laboratories Tel: +81 468 59 8840 Fax: +81 468 59 8569 E-mail: ohta.hiroshi@nslab.ntt.co.jp From owner-mpls@UU.NET Mon Apr 10 07:36:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05780 for ; Mon, 10 Apr 2000 07:36:15 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikhq23808; Mon, 10 Apr 2000 11:35:55 GMT Received: by mail-control.mail.uu.net id QQikhq04437 for mpls-outgoing; Mon, 10 Apr 2000 11:35:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQikhq04432 for ; Mon, 10 Apr 2000 11:35:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikhq09843 for ; Mon, 10 Apr 2000 07:35:16 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQikhq23392 for ; Mon, 10 Apr 2000 11:35:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA15700 for mpls@uu.net; Mon, 10 Apr 2000 07:35:15 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQikhq04415 for ; Mon, 10 Apr 2000 11:34:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQikhq07702 for ; Mon, 10 Apr 2000 07:34:26 -0400 (EDT) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQikhq13339 for ; Mon, 10 Apr 2000 11:34:26 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05509; Mon, 10 Apr 2000 07:34:25 -0400 (EDT) Message-Id: <200004101134.HAA05509@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-tunnel-applicability-01.txt Date: Mon, 10 Apr 2000 07:34:24 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Applicability Statement for Extensions to RSVP for LSP-Tunnels Author(s) : D. Awduche, A. Hannan, X. Xiao Filename : draft-ietf-mpls-rsvp-tunnel-applicability-01.txt Pages : 8 Date : 06-Apr-00 This memo discusses the applicability of 'Extensions to RSVP for LSP Tunnels' [1]. It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of 'Extensions to RSVP for LSP Tunnels' onto the Internet standards track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-tunnel-applicability-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-tunnel-applicability-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-tunnel-applicability-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: <20000406142853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-tunnel-applicability-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-tunnel-applicability-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000406142853.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Apr 10 08:01:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06449 for ; Mon, 10 Apr 2000 08:01:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikhs28428; Mon, 10 Apr 2000 12:01:02 GMT Received: by mail-control.mail.uu.net id QQikhs06332 for mpls-outgoing; Mon, 10 Apr 2000 12:00:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQikhs05896 for ; Mon, 10 Apr 2000 12:00:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikhs12389 for ; Mon, 10 Apr 2000 08:00:05 -0400 (EDT) Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQikhr07311 for ; Mon, 10 Apr 2000 11:59:55 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 10 Apr 2000 17:38:55 +0530 Received: from manishs (manishs.future.futsoft.com [10.0.12.32]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id RAA21134 for ; Mon, 10 Apr 2000 17:18:14 +0530 Received: by localhost with Microsoft MAPI; Mon, 10 Apr 2000 17:27:32 +0530 Message-Id: <01BFA312.0DC7CD00.manishs@future.futsoft.com> From: "Manish R. Shah." Reply-To: "manishs@future.futsoft.com" To: "'mpls@uu.net'" Subject: Query !!! Date: Mon, 10 Apr 2000 17:27:31 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am having a few queries !! 1> How is a Forwarding Equivalence Class (FEC) created? 2> What are the factors which decide a FEC? 3> what is the difference between Address prefix FEC and a Host Address FEC ? Kindly reply at the earliest !!! Regds Manish. From owner-mpls@UU.NET Mon Apr 10 08:15:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06954 for ; Mon, 10 Apr 2000 08:15:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikht06849; Mon, 10 Apr 2000 12:15:11 GMT Received: by mail-control.mail.uu.net id QQikhs14787 for mpls-outgoing; Mon, 10 Apr 2000 12:14:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQikhs14778 for ; Mon, 10 Apr 2000 12:14:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikhs14069 for ; Mon, 10 Apr 2000 08:14:03 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQikhs15041 for ; Mon, 10 Apr 2000 12:13:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA17874 for mpls@uu.net; Mon, 10 Apr 2000 08:13:58 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQikhs14755 for ; Mon, 10 Apr 2000 12:13:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikhs11673 for ; Mon, 10 Apr 2000 08:13:29 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQikhs14778 for ; Mon, 10 Apr 2000 12:13:28 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA02225; Mon, 10 Apr 2000 08:13:13 -0400 (EDT) Message-Id: <4.2.2.20000410075222.06d9a3c0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Apr 2000 07:53:10 -0400 To: Vijay Srinivasan , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: Re: LSR MIB last call Cc: cheenu@tachion.com, arun Viswanathan In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_259803834==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_259803834==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Vijay, We are nearly complete with all of the changes and will have a version published by this Friday (April, 14). --Tom >The LSR MIB last call has closed. Would the authors please update the >draft based on comments received during the last call and publish a new >version asap? > >Thanks, >- Vijay --=====================_259803834==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Vijay,       

        We are nearly complete with all of the changes and
will have a version published by this Friday (April, 14).

        --Tom


The LSR MIB last call has closed.  Would the authors please update the draft based on comments received during the last call and publish a new version asap?

Thanks,
- Vijay
--=====================_259803834==_.ALT-- From owner-mpls@UU.NET Mon Apr 10 10:16:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13323 for ; Mon, 10 Apr 2000 10:16:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikib10158; Mon, 10 Apr 2000 14:15:43 GMT Received: by mail-control.mail.uu.net id QQikib08105 for mpls-outgoing; Mon, 10 Apr 2000 14:15:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQikib08040 for ; Mon, 10 Apr 2000 14:15:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikia04101 for ; Mon, 10 Apr 2000 10:14:53 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQikia09335 for ; Mon, 10 Apr 2000 14:14:53 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 HAA21683 for ; Mon, 10 Apr 2000 07:14:53 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA00887 for mpls@uu.net; Mon, 10 Apr 2000 10:14:50 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQijxz11804 for ; Fri, 7 Apr 2000 20:56:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQijxz21639 for ; Fri, 7 Apr 2000 16:55:21 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQijxz26616 for ; Fri, 7 Apr 2000 20:55:21 GMT Received: from pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA19065 for ; Fri, 7 Apr 2000 13:55:20 -0700 (PDT) Message-ID: <38EE4B38.80BC3505@pluris.com> Date: Fri, 07 Apr 2000 13:55:20 -0700 From: Bora Akyol X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET Subject: draft-hsmit-mpls-igp-spf-01... archived copy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Does anyone have an archived copy of this? Thanks Bora From owner-mpls@UU.NET Mon Apr 10 19:41:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06977 for ; Mon, 10 Apr 2000 19:41:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikjm28561; Mon, 10 Apr 2000 23:41:02 GMT Received: by mail-control.mail.uu.net id QQikjm25972 for mpls-outgoing; Mon, 10 Apr 2000 23:40:15 GMT Received: from neserve0.corp.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.203.88]) id QQikjm25928 for ; Mon, 10 Apr 2000 23:40:12 GMT Received: by neserve0.corp.us.uu.net id QQikjm26473; Mon, 10 Apr 2000 19:40:02 -0400 (EDT) Date: Mon, 10 Apr 2000 19:40:01 -0400 From: Daniel Awduche To: Bora Akyol Cc: mpls@UU.NET, Daniel Awduche Subject: Re: draft-hsmit-mpls-igp-spf-01... archived copy Message-ID: <20000410194001.B24946@uu.net> References: <38EE4B38.80BC3505@pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <38EE4B38.80BC3505@pluris.com>; from akyol@pluris.com on Fri, Apr 07, 2000 at 01:55:20PM -0700 Sender: owner-mpls@UU.NET Precedence: bulk Not sure there's an -01- version of this draft... The original draft (draft-hsmit-mpls-igp-spf-00.txt) is available from: http://ftp.uni-bremen.de/pub/doc/internet-drafts/ Cheers, /Dan On Fri, Apr 07, 2000 at 01:55:20PM -0700, Bora Akyol wrote: > Does anyone have an archived copy of this? > > Thanks > > Bora > > From owner-mpls@UU.NET Tue Apr 11 09:04:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02187 for ; Tue, 11 Apr 2000 09:04:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiklo13616; Tue, 11 Apr 2000 13:04:12 GMT Received: by mail-control.mail.uu.net id QQiklo16896 for mpls-outgoing; Tue, 11 Apr 2000 13:03:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiklo16728 for ; Tue, 11 Apr 2000 13:03:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiklo01527 for ; Tue, 11 Apr 2000 09:03:09 -0400 (EDT) Received: from redbaron.nexabit.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQiklo13450 for ; Tue, 11 Apr 2000 13:03:08 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id JAA10754 for ; Tue, 11 Apr 2000 09:03:08 -0400 Received: by BANDITO with Internet Mail Service (5.5.2650.21) id <2T34GF6D>; Mon, 10 Apr 2000 15:05:04 -0400 Message-ID: From: Dimitry Haskin To: mpls@UU.NET Subject: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt Date: Mon, 10 Apr 2000 15:05:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The last paragraph on Page 3: ... To be definite, in the original RSVP protocol [3], a session was defined as a data flow with a particular destination and transport layer protocol. In the RSVP-TE specification, however, a session is implicitly defined as the set of packets that are assigned the same MPLS label value at the originating node of an LSP-tunnel. I believe there is an issue with the RSVP-TE session definition in the above statement. To my reading, nowhere the RSVP-TE draft implies that a set of packets have to be assigned the same MPLS label at the originating node in order to constitute a session. (If my reading is incorrect, then I've an issue with the RSVP-TE spec.) Moreover, Section 2.5 (Rerouting LSP Tunnels) of the RSVP-TE specification seems to clearly imply that multiple LSPs can belong to a single session. Another example where multiple LSPs belonging to the same RSVP session can originate at the same note is a load sharing multipath tunnel between ingress and egress LSRs. In summary, this at the first glance an insignificant matter has significant implementation implications. ---------------------------------------------------------------------- Dimitry Haskin Lucent Technologies Internetworking Systems From owner-mpls@UU.NET Tue Apr 11 11:36:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09365 for ; Tue, 11 Apr 2000 11:36:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikly29895; Tue, 11 Apr 2000 15:34:19 GMT Received: by mail-control.mail.uu.net id QQikly17082 for mpls-outgoing; Tue, 11 Apr 2000 15:33:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQikly17075 for ; Tue, 11 Apr 2000 15:33:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikly00719 for ; Tue, 11 Apr 2000 11:33:27 -0400 (EDT) Received: from mailgate.fore.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQikly28800 for ; Tue, 11 Apr 2000 15:33:26 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA16868 for ; Tue, 11 Apr 2000 11:33:24 -0400 (EDT) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA04391 for ; Tue, 11 Apr 2000 11:33:26 -0400 (EDT) Message-ID: <38F345CF.E03BABDD@fore.com> Date: Tue, 11 Apr 2000 11:33:35 -0400 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dimitry Haskin wrote: > > The last paragraph on Page 3: > > ... To be definite, in the original RSVP protocol [3], a session > was defined as a data flow with a particular destination and > transport layer protocol. In the RSVP-TE specification, however, a > session is implicitly defined as the set of packets that are assigned > the same MPLS label value at the originating node of an LSP-tunnel. > > > I believe there is an issue with the RSVP-TE session definition in the > above statement. To my reading, nowhere the RSVP-TE draft implies > that a set of packets have to be assigned the same MPLS label at the > originating node in order to constitute a session. (If my reading is > incorrect, then I've an issue with the RSVP-TE spec.) Moreover, > Section 2.5 (Rerouting LSP Tunnels) of the RSVP-TE specification seems > to clearly imply that multiple LSPs can belong to a single session. > Another example where multiple LSPs belonging to the same RSVP session > can originate at the same note is a load sharing multipath tunnel > between ingress and egress LSRs. In summary, this at the first glance > an insignificant matter has significant implementation implications. I think you may have found a bug in this draft. Under RSVP, whether MPLS or not, a session is defined as the set of paths that share a common destination. The difference is that with MPLS, a destination is defined as the tunnel endpoint address, tunnel ID and extended tunnel ID. (Instead of the destination address, protocol and port of non-MPLS RSVP.) This is explicitly spelled out in the new definition of the SESSION object. See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, section 4.6.1. It is further spelled out in the reroute rules (section 2.5) - which could not work if the two tunnels were in different sessions. The reroute algorithm depends on the fact that two tunnels (the original and the new one) will have different labels - otherwise the two tunnels could not coexist during between the time of the second tunnel's creation and the first's destruction. It should further be noted that labels are not assigned until after reservations are made. They are propagated in the Resv message. Therefore, any definition of session that depends on labels is meaningless, since sessions are created during Path message processing. BTW, this bug is also reflected in the draft-ietf-mpls-rsvp-lsp-tunnel-05.txt document. In section 2.1, it defines "session" and "flow" to be synonymous. This must be incorrect, because during the reroute processing, two flows share a common session. More accurately, a session is defined as one or more flows to a common destination (as described by the SESSION object), however, normal MPLS operation will only have one flow per session, except during tunnel rerouting. -- David From owner-mpls@UU.NET Tue Apr 11 13:57:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15015 for ; Tue, 11 Apr 2000 13:57:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikmh21504; Tue, 11 Apr 2000 17:56:03 GMT Received: by mail-control.mail.uu.net id QQikmh14737 for mpls-outgoing; Tue, 11 Apr 2000 17:55:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQikmh14732 for ; Tue, 11 Apr 2000 17:55:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikmh21600 for ; Tue, 11 Apr 2000 13:55:35 -0400 (EDT) Received: from redbaron.nexabit.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQikmh20897 for ; Tue, 11 Apr 2000 17:55:35 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id NAA17774; Tue, 11 Apr 2000 13:55:29 -0400 Received: by BANDITO with Internet Mail Service (5.5.2650.21) id <2T34GH0G>; Tue, 11 Apr 2000 13:55:29 -0400 Message-ID: From: Dimitry Haskin To: David Charlap , mpls@UU.NET Subject: RE: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt Date: Tue, 11 Apr 2000 13:55:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > > Dimitry Haskin wrote: > > > > The last paragraph on Page 3: > > > > ... To be definite, in the original RSVP protocol [3], a session > > was defined as a data flow with a particular destination and > > transport layer protocol. In the RSVP-TE specification, however, a > > session is implicitly defined as the set of packets that > are assigned > > the same MPLS label value at the originating node of an LSP-tunnel. > > > > > > I believe there is an issue with the RSVP-TE session > definition in the > > above statement. To my reading, nowhere the RSVP-TE draft implies > > that a set of packets have to be assigned the same MPLS label at the > > originating node in order to constitute a session. (If my reading is > > incorrect, then I've an issue with the RSVP-TE spec.) Moreover, > > Section 2.5 (Rerouting LSP Tunnels) of the RSVP-TE > specification seems > > to clearly imply that multiple LSPs can belong to a single session. > > Another example where multiple LSPs belonging to the same > RSVP session > > can originate at the same note is a load sharing multipath tunnel > > between ingress and egress LSRs. In summary, this at the > first glance > > an insignificant matter has significant implementation implications. > > I think you may have found a bug in this draft. > > Under RSVP, whether MPLS or not, a session is defined as the set of > paths that share a common destination. The difference is that with > MPLS, a destination is defined as the tunnel endpoint > address, tunnel ID > and extended tunnel ID. (Instead of the destination address, protocol > and port of non-MPLS RSVP.) > > This is explicitly spelled out in the new definition of the SESSION > object. See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, section > 4.6.1. It > is further spelled out in the reroute rules (section 2.5) - > which could > not work if the two tunnels were in different sessions. The reroute > algorithm depends on the fact that two tunnels (the original > and the new > one) will have different labels - otherwise the two tunnels could not > coexist during between the time of the second tunnel's > creation and the > first's destruction. > > It should further be noted that labels are not assigned until after > reservations are made. They are propagated in the Resv message. > Therefore, any definition of session that depends on labels is > meaningless, since sessions are created during Path message > processing. > > BTW, this bug is also reflected in the > draft-ietf-mpls-rsvp-lsp-tunnel-05.txt document. In section 2.1, it > defines "session" and "flow" to be synonymous. This must be > incorrect, because during the reroute processing, two flows share a common > session. More accurately, a session is defined as one or more flows to > a common destination (as described by the SESSION object), however, > normal MPLS operation will only have one flow per session, > except during tunnel rerouting. As I've mentioned, another important example of such an arrangement is a session that utilizes multiple MPLS paths for load sharing purposes. Such paths can merge at some downstream LSR. LSP merging decision is more straightforward and is in line with the classical RSVP if LSPs that can be merged are identified with the same session object. While on the merging topic, I believe the following statement on Page 43 in RSVP-TE spec is to be revisited: 0x02 Merging permitted This flag permits transit routers to merge this session with other RSVP sessions for the purpose of reducing resource overhead on downstream transit routers, thereby providing better network scalability. I would think that the intention was to permit merging of LSPs that belong to the same session as opposed to merging LSPs from different sessions. I've difficulties to see how merging of sessions is achieved within the RSVP framework. > -- David > From owner-mpls@UU.NET Tue Apr 11 16:12:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19274 for ; Tue, 11 Apr 2000 16:12:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikmq22571; Tue, 11 Apr 2000 20:10:44 GMT Received: by mail-control.mail.uu.net id QQikmq15983 for mpls-outgoing; Tue, 11 Apr 2000 20:10:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQikmq15961 for ; Tue, 11 Apr 2000 20:10:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikmq15951 for ; Tue, 11 Apr 2000 16:09:54 -0400 (EDT) Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQikmq21570 for ; Tue, 11 Apr 2000 20:09:53 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id PAA29511 for ; Tue, 11 Apr 2000 15:09:50 -0500 (CDT) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id PAA11712; Tue, 11 Apr 2000 15:09:05 -0500 (CDT) Received: by localhost with Microsoft MAPI; Tue, 11 Apr 2000 16:13:00 -0400 Message-ID: <01BFA3D0.CEC38B70.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'mpls@uu.net'" Cc: "Ben Mack-Crane (E-mail)" , "Chang Huang (E-mail)" , "Ken Owens (E-mail)" , "Srinivas Makam (E-mail)" Subject: Comments on draft-chang-mpls-path-protection-00.txt Date: Tue, 11 Apr 2000 16:12:59 -0400 Organization: Tellabs Research Center X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, After my presentation of the path protection mechanism draft at the Wednesday session in Adelaide, the Chairs had suggested that we initiate some discussion on our draft on the mailing list to obtain feedback from the group. Also, several people had come to me after the talk, and discussed various aspects of our solution, or indicated agreement with what we were proposing. We would therefore like to request comments from the list on our draft --- suggestions, ideas for extensions, criticisms etc., so that we can incorporate those in our draft. This will be very valuable in moving this work forward, and in aligning it with other recovery work currently being pursued in the WG. Thanks very much. -Vishal ******************************************************* Vishal Sharma, Ph.D. A small group of determined spirits with an Research Engineer unquenchable thirst for their mission can alter the course of history. --- Gandhi Tellabs Research Center One Kendall Square Phone: (617).577.8760 Bldg. 100, Suite 121 Fax: (617).494.0118 Cambridge, MA 02139 e-mail: Vishal.Sharma@tellabs.com sharmav@acm.org ******************************************************* From owner-mpls@UU.NET Tue Apr 11 19:17:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23849 for ; Tue, 11 Apr 2000 19:17:15 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiknd21508; Tue, 11 Apr 2000 23:16:20 GMT Received: by mail-control.mail.uu.net id QQiknd23062 for mpls-outgoing; Tue, 11 Apr 2000 23:15:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiknd23053 for ; Tue, 11 Apr 2000 23:15:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiknd24363 for ; Tue, 11 Apr 2000 19:15:43 -0400 (EDT) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQiknd20661 for ; Tue, 11 Apr 2000 23:15:43 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Tue, 11 Apr 2000 19:15:06 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A48D025@email.quarrytech.com> From: "Abes, Andi" To: Dimitry Haskin , David Charlap , mpls@UU.NET Subject: RE: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt Date: Tue, 11 Apr 2000 19:15:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Let's clear things a little: The RSVP-TE session object includes the following: - Tunnel ID, - Eggress LSR IP address - Extended tunnel ID. The extended tunnel ID can either be 0 or contain the IP address of the source. Ok, now what does that mean. I understand it as such: A session identifies the "tunnel" that ends at the specified egress. This could mean many ingress LSR's if the extended ID is 0, or just one specific ingress if the extended ID contains its IP address. This basicaly means that a "session" can have many ingress points which can share resources while traversing the network towards the egress. In the same spirit as in the original RSVP, although with no support for explicit multicast - many senders can send traffic to the same session, and each is identified by the "sender_template" - by the IP address of the sender (in oRSVP). The "deviation" in RSVP-TE is that there could be many senders in one host, such that it is not enough to denote the ingress IP address, but the LSP ID is also needed. Each "Sender" is assigned a label,a "flow_spec" and optionaly an Explicit Route. The reroute is performed on LSP basis - not Tunnel. So - a session is a COLLECTION of LSP's that are targeted at the same egress point, that were assigned to the same administrativly selected "Tunnel ID" In order for LSP's to share resources, they have to be assigned to the same "TunnelID". I agree that the wording in the applicability draft is somewhat lacking, but the RSVP-TE draft itself is clear about this - if you dig hard looking at the implications of the object formats. Andi. From owner-mpls@UU.NET Tue Apr 11 19:48:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24077 for ; Tue, 11 Apr 2000 19:48:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiknf17313; Tue, 11 Apr 2000 23:47:40 GMT Received: by mail-control.mail.uu.net id QQiknf25697 for mpls-outgoing; Tue, 11 Apr 2000 23:46:58 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiknf25681 for ; Tue, 11 Apr 2000 23:46:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiknf27658 for ; Tue, 11 Apr 2000 19:46:37 -0400 (EDT) Received: from mailgate.fore.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQiknf16561 for ; Tue, 11 Apr 2000 23:46:37 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id TAA29829 for ; Tue, 11 Apr 2000 19:46:34 -0400 (EDT) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id TAA17249 for ; Tue, 11 Apr 2000 19:46:36 -0400 (EDT) Message-ID: <38F3B967.8C84672B@fore.com> Date: Tue, 11 Apr 2000 19:46:47 -0400 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt References: <496A8683261CD211BF6C0008C733261A48D025@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Abes, Andi" wrote: > > The "deviation" in RSVP-TE is that there could be many senders in one > host, such that it is not enough to denote the ingress IP address, but > the LSP ID is also needed. Each "Sender" is assigned a label, a > "flow_spec" and optionaly an Explicit Route. You're confusing a few things here, I think. Each sender (actually, each PHOP node along the path from each sender) is assigned a label by its NHOP node during Resv processing. FLOWSPEC objects contain the Qos parameters (could be "best effort" if the CoS CType is used) and are also signalled from NHOP to PHOP during Resv processing. Explicit route objects are signalled from PHOP to NHOP during Path processing. They are not assigned to senders, but are generated by senders. (Or ingress routers in the MPLS world.) -- David From owner-mpls@UU.NET Tue Apr 11 20:55:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25274 for ; Tue, 11 Apr 2000 20:55:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiknj27784; Wed, 12 Apr 2000 00:54:31 GMT Received: by mail-control.mail.uu.net id QQiknj08941 for mpls-outgoing; Wed, 12 Apr 2000 00:53:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiknj08930 for ; Wed, 12 Apr 2000 00:53:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiknj25427 for ; Tue, 11 Apr 2000 20:53:43 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiknj27037 for ; Wed, 12 Apr 2000 00:53:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA03730 for mpls@uu.net; Tue, 11 Apr 2000 20:53:42 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiknj08890 for ; Wed, 12 Apr 2000 00:53:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiknj25379 for ; Tue, 11 Apr 2000 20:53:01 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiknj06617 for ; Wed, 12 Apr 2000 00:53:01 GMT Received: from pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA15699; Tue, 11 Apr 2000 17:53:01 -0700 (PDT) Message-ID: <38F3C8EE.39852C79@pluris.com> Date: Tue, 11 Apr 2000 17:53:02 -0700 From: Bora Akyol X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET, Bora Akyol Subject: draft-chang-mpls-path-protection Comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I have read the draft and have the following comments: 1. It is unclear how the RNT mechanism with its FIS/FRS timers differs from RSVP with TE extensions. Specifically, the timers and the RNT mechanism resemble RSVP reservations with soft state but with inverted logic. This should be explained. 2. The text does not specify via what mechanism the FIS/FRS packets are transmitted? Via UDP/TCP over IP, via the DCC in the SONET overhead using ISO CLNS? It would be nice to have some packet formats and outlines of transmission routines. 3. It is pointed in the text that MPLS protection reserves bandwidth but the text fails to mention SONET also reserves bandwidth. Moreover, in most current IP/MPLS LSRs, unused bandwidth is usually used for lower traffic classes. 4. I found sect. 2.2.1 useful. 5. Are FIS and FRS defined somewhere? 6. Timers: There are way too many timers. I do understand that the RNT cuts down on the amount of notifications, but on core routers with large number of interfaces with large number of LSPs flowing through them, 8 timers per RNT is a bit much. This is sort of related to the question 1 above too. 7. It seems to me that there is a lot of state associated with each RNT especially when the inverse forking ratio (IFR) is high. It would help to clearly specify exactly what state needs to be maintained in a list. 8. In general, people are not concerned with the volume (bw) of signaling traffic but the overhead it costs in terms of processing. In general, I found the draft of some value, but I think the RNT mechanism should be either separated from the protection procedure or put in an appendix. RNT bears striking similarity to RSVP and there are already quite a number of fields defined in RSVP-TE for the purpose of protection switching signaling, so can we just add what is needed to RSVP-TE? The text also omits all discussion of how restoration paths are computed, what constraints need to be imposed, etc. There is also a lack of specificity in the text, which I hope will improve in a subsequent version. Ideally, an Internet draft should lend itself to being read and then implemented unlike a research paper. Finally, a question to the audience, how does the proposed scheme interoperate with vendor proprieatry implementations of protection switching? Now that the cat is out of the bag, we may want to open up and agree on a standard. Thanks Bora Akyol From owner-mpls@UU.NET Wed Apr 12 13:11:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27987 for ; Wed, 12 Apr 2000 13:11:59 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikpw27616; Wed, 12 Apr 2000 17:11:20 GMT Received: by mail-control.mail.uu.net id QQikpw08847 for mpls-outgoing; Wed, 12 Apr 2000 17:10:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQikpw08835 for ; Wed, 12 Apr 2000 17:10:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikpw18931 for ; Wed, 12 Apr 2000 13:10:21 -0400 (EDT) Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQikpw24010 for ; Wed, 12 Apr 2000 17:10:21 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id MAA01167; Wed, 12 Apr 2000 12:10:17 -0500 (CDT) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA25246; Wed, 12 Apr 2000 12:10:17 -0500 (CDT) Received: by localhost with Microsoft MAPI; Wed, 12 Apr 2000 13:14:07 -0400 Message-ID: <01BFA480.FBD8ECD0.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'akyol@pluris.com'" , "mpls@UU.NET" Cc: "Chang Huang (E-mail)" , "Srinivas Makam (E-mail)" , "Ken Owens (E-mail)" Subject: RE: draft-chang-mpls-path-protection Comments Date: Wed, 12 Apr 2000 13:14:06 -0400 Organization: Tellabs Research Center X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bora, Thanks very much for your detailed comments. Some of your questions that can be answered immediately, we'll answer right away. For others, we'll defer to a bit later, so that my co-authors and I have a chance to discuss and prepare a respone. -Vishal On Tuesday, April 11, 2000 8:53 PM, akyol@pluris.com [SMTP:akyol@pluris.com] wrote: > I have read the draft and have the following comments: > > > 1. It is unclear how the RNT mechanism with its FIS/FRS timers differs > from RSVP with TE extensions. Specifically, the timers and the RNT > mechanism resemble RSVP reservations with soft state but with > inverted logic. This should be explained. We want to develop a general algorithm that can be used by RSVP, CR-LDP or other mechanisms (e.g. layer 2). For the RSVP case, maybe there are some overlaps. But we need to check that. Our initial reaction is that they are different. Our algorithm requires each node to send their notifications actively while RSVP will send error message as a response to refresh message. In other words, our approach may be viewed as a trap while RSVP is a poll. However, we need to check these conclusioins. Another point is that if the notification is through layer 2, it will be different from the RSVP approach. Therefore, our approach is more general. Thus, I am not sure that the RNT mechanism can be folded into RSVP-TE, but thanks for pointing this out. We will examine this more carefully, and provide an explanation. > 2. The text does not specify via what mechanism the FIS/FRS packets > are transmitted? Via UDP/TCP over IP, via the DCC in the SONET > overhead using ISO CLNS? It would be nice to have some packet > formats and outlines of transmission routines. This is actually explained in Section 2.1 and in Section 3.2 paras 2 and 3 (for the Layer 2 and hop-by-hop cases, respectively). Essentially, our initial thought was to have the FIS/FRS packets be either UDP packets (for the hop-by-hop case) or MPLS labeled IP packets. The point on the packet formats, however, is well taken. We will try to include that in the sequel. If you have any specific suggestions, please let us have them. > 3. It is pointed in the text that MPLS protection reserves bandwidth > but the text fails to mention SONET also reserves bandwidth. > Moreover, in most current IP/MPLS LSRs, unused bandwidth is usually > used for lower traffic classes. I'm a little unclear on why this is important to mention, since we make no assumptions about how the protection bandwidth is used, and that does not affect the path protection mechanism per se. This is a good point though, and we have discussed some of this in the first paragraph of section 3.3. > 4. I found sect. 2.2.1 useful. Thanks! > 5. Are FIS and FRS defined somewhere? Actually, these are defined in the MPLS recovery framework draft, draft-makam-mpls-recovery-frmwrk-00.txt. We see your point though, and we'll repeat the definitions in our draft for easy reference (like what we've done for the PSL, PML etc.). > 6. Timers: There are way too many timers. I do understand that the RNT > cuts down on the amount of notifications, but on core routers with > large number of interfaces with large number of LSPs flowing > through them, 8 timers per RNT is a bit much. This is sort of > related to the question 1 above too. Please note that timers for failure detection are on a per-link not a per-LSP basis. Additionally, the timers for FIS and FRS will not exist simultaneously, this cuts the states in half. Other timers such as the hold-off timer may also be shared on a per-node or per-link basis. So the timers are not as many as may appear at first. Also, the states for the FIS and FRS are deterministic (time-wise), and they only exist for a fixed amount of time. Also, a point to be noted is that we have defined timers that we think are useful. However, not all timers need to be used in a specific implementation. Many of these timers may have a default value of zero, if they introduce processing that a particular LSR cannot handle, or if the network provider feels that they do not need certain timers. > 7. It seems to me that there is a lot of state associated with each > RNT especially when the inverse forking ratio (IFR) is high. It > would help to clearly specify exactly what state needs to be > maintained in a list. We have tried to specify some of this in Section 3.1, and by saying what information each of PSL, PML and intermediate LSRs need to maintain. However, this is a good point, and we'll introduce a list with the needed state information in the revision. Also, note that using a layer 2 approach will be better. And this is not covered in RSVP. > 8. In general, people are not concerned with the volume (bw) of > signaling traffic but the overhead it costs in terms of processing. Thanks for pointing this out. I think if we address some of the points you raised earlier, it would be easier to see the amount of processing that might be needed. We note, however, that any path protection scheme, by its very nature (due to the need for notification, switchover, etc.), will entail some amount of processing. > In general, I found the draft of some value, but I think the RNT > mechanism should be either separated from the protection procedure or > put in an appendix. This is a little confusing to me. Essentially, the RNT mechanism is the heart of the path protection procedure described in the draft. How could we separate the two? > RNT bears striking similarity to RSVP and there are already quite a > number of fields defined in RSVP-TE for the purpose of protection > switching signaling, so can we just add what is needed to RSVP-TE? This goes back to my response to Question 1 above. We need to think about this. > The text also omits all discussion of how restoration paths are > computed, what constraints need to be imposed, etc. This was done on purpose. The goal of the draft is to specify a mechanism to perform path protection. It is not a goal of this draft to discuss the specific algorithms that are used to compute paths, incorporate network constraints etc. First, the protection mechanism itself does not depend at all on how paths are computed. Second, we expect those to be proprietary, but the mechanism and its associated signaling to be standardized. For instance, the alternate path computation may use one of several available choices. For example, Slosiar and Latin's algorithm that appeared in Infocom'00 A Polynomial-Time Algorithm for the Establishment of Primary and Alternate Paths in ATM Networks Rasti Slosiar (Telstra Research Laboratories (now with Swisscom AG)), David Latin (Telstra Research Laboratories) http://comnet.technion.ac.il/infocom2000/ > There is also a lack of specificity in the text, which I hope will > improve in a subsequent version. Ideally, an Internet draft should lend > itself to being read and then implemented unlike a research paper. As we receive more comments from the list and try to incorporate them in subsequent revisions, I'm sure we'll more towards becoming more specific. Please note, however, that it was not the objective of this draft to specify particular formats (for instance we haven't specified here signaling extensions to LDP/CR-LDP or RSVP-TE that would be required to implement this mechanism). This was partly because the mechanism allows for flexibility in how certain parts of it are implemented. Nonetheless, I agree that it would be useful to specify some formats for some of the alternatives to help implementation. > Finally, a question to the audience, how does the proposed scheme > interoperate with vendor proprieatry implementations of protection > switching? Now that the cat is out of the bag, we may want to open up > and agree on a standard. Good one. I guess the audience is the best one to answer that! From owner-mpls@UU.NET Wed Apr 12 13:19:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28154 for ; Wed, 12 Apr 2000 13:19:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikpx28957; Wed, 12 Apr 2000 17:16:39 GMT Received: by mail-control.mail.uu.net id QQikpx09459 for mpls-outgoing; Wed, 12 Apr 2000 17:16:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQikpx09425 for ; Wed, 12 Apr 2000 17:16:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikpx01322 for ; Wed, 12 Apr 2000 13:16:00 -0400 (EDT) Received: from smtprtp1.ntcom.nortel.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQikpx28260 for ; Wed, 12 Apr 2000 17:16:00 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Wed, 12 Apr 2000 13:15:41 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2K7T7AMS>; Wed, 12 Apr 2000 13:15:35 -0400 Message-ID: <6DDA62170439D31185750000F80826AC022964D7@zmerd004.ca.nortel.com> From: "David Allan" To: Bora Akyol , mpls@UU.NET Subject: RE: draft-chang-mpls-path-protection Comments Date: Wed, 12 Apr 2000 13:15:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA4A2.B6D61E6A" 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_01BFA4A2.B6D61E6A Content-Type: text/plain A few comments: 1.0 - The discussion of the limits of SONET protection I find a bit contentious. I'd suggest the difference between protection at various layers is when the degree or style of protection is being used as a product or class of service differentiator and one is trying to bundle that differentiation into a specific layer. Otherwise everyone gets the same treatment that the underlying layer provides. 2.1 - What is an FIS and FRS? 2.1 - I'd like to see a better definition of "PSLs affected by a fault". 3.1 - discussion of establishing the path suggests that the only properties required is that the path transit the PML and the PSL. Ideally it transits nothing in common between those two entities (nodes, fibers, conduits etc.) if multiple simultaneous failures are to be minimized. An equally interesting problem is nodal redundancy on the boundaries of protected domains to protect against catastrophic nodal failure (like an LSR crashing... or being crashed into ;-). 3.3 - I'm missing somthing in the discussion of bandwidth reuse in the protection path. Are we discussing linear protection where the only opportunity for re-use for LSPs which have common routing between the PSL and the PML? 3.3 - 1:1 is the only protection mode discussed. n+1 is a possibility. and 1+1 may be derided for bandwidth ineffeciency, but it does not require the establishment of an RNT, simple forward livliness messages are sufficient for a PML to select an appropriate source. At some point in the future, bandwidth for administrative time/simplicity may be a worthwhile tradeoff. This would suggest common livliness mechanisms are required, and this should be acknowledged by attempting to encompass the whole problem/solution space. Ultimately I'm skeptical about the ability to construct parallel mp2p trees that are usefully diverse and for which the backup is remotely near optimal due to the constraint of having common PSLs and PML. The apparent requirement to have both working and protection paths converge on the PML seems artificial and unnecessary (if I am understanding this correctly???). All a PSL needs to know is that a path has failed, and have a viable alternative to switch to. For that RNT may be a viable solution, but simply each protected mp2p LSP has an RNT associated with it so the PSL can make reasonable and timely decisions and there may be no topological entities in common between the working path and the protection path (other than the egress node from the network). Realistically the useful functionality of an RNT can be distributed across all intermediate LSRs and the concept of an PML should be capped as simply an administrative concept defining a point past which an RNT will not propagate (for whatever reason). cheers Dave ------_=_NextPart_001_01BFA4A2.B6D61E6A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-chang-mpls-path-protection Comments

A few = comments:

1.0 - The discussion = of the limits of SONET protection I find a bit contentious. I'd suggest = the difference between protection at various layers is when the degree = or style of protection is being used as a product or class of service = differentiator and one is trying to bundle that differentiation into a = specific layer. Otherwise everyone gets the same treatment that the = underlying layer provides.

2.1 - What is an FIS = and FRS?

2.1 - I'd like to = see a better definition of "PSLs affected by a fault". =

3.1 - discussion of = establishing the path suggests that the only properties required is = that the path transit the PML and the PSL. Ideally it transits nothing = in common between those two entities (nodes, fibers, conduits etc.) if = multiple simultaneous failures are to be minimized. An equally = interesting problem is nodal redundancy on the boundaries of protected = domains to protect against catastrophic nodal failure (like an LSR = crashing... or being crashed into ;-).

3.3 - I'm missing = somthing in the discussion of bandwidth reuse in the protection path. = Are we discussing linear protection where the only opportunity for = re-use for LSPs which have common routing between the PSL and the = PML?

3.3 - 1:1 is the = only protection mode discussed. n+1 is a possibility. and 1+1 may be = derided for bandwidth ineffeciency, but it does not require the = establishment of an RNT, simple forward livliness messages are = sufficient for a PML to select an appropriate source. At some point in = the future, bandwidth for administrative time/simplicity may be a = worthwhile tradeoff. This would suggest common livliness mechanisms are = required, and this should be acknowledged by attempting to encompass = the whole problem/solution space.


Ultimately I'm = skeptical about the ability to construct parallel mp2p trees that are = usefully diverse and for which the backup is remotely near optimal due = to the constraint of having common PSLs and PML. The apparent = requirement to have both working and protection paths converge on the = PML seems artificial and unnecessary (if I am understanding this = correctly???). All a PSL needs to know is that a path has failed, and = have a viable alternative to switch to. For that RNT may be a viable = solution, but simply each protected mp2p LSP has an RNT associated with = it so the PSL can make reasonable and timely decisions and there may be = no topological entities in common between the working path and the = protection path (other than the egress node from the network). = Realistically the useful functionality of an RNT can be distributed = across all intermediate LSRs and the concept of an PML should be capped = as simply an administrative concept defining a point past which an RNT = will not propagate (for whatever reason).

cheers
Dave


------_=_NextPart_001_01BFA4A2.B6D61E6A-- From owner-mpls@UU.NET Wed Apr 12 18:34:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04745 for ; Wed, 12 Apr 2000 18:34:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikqs11965; Wed, 12 Apr 2000 22:32:30 GMT Received: by mail-control.mail.uu.net id QQikqs16508 for mpls-outgoing; Wed, 12 Apr 2000 22:32:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQikqs16499 for ; Wed, 12 Apr 2000 22:32:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikqs24119 for ; Wed, 12 Apr 2000 18:31:47 -0400 (EDT) Received: from arthur.caida.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: arthur.caida.org [204.212.46.6]) id QQikqs05621 for ; Wed, 12 Apr 2000 22:31:47 GMT Received: from arthur.caida.org (localhost.caida.org [127.0.0.1]) by arthur.caida.org (8.9.0/8.9.0.Beta5) with ESMTP id SAA74908 for ; Wed, 12 Apr 2000 18:31:47 -0400 (EDT) Message-Id: <200004122231.SAA74908@arthur.caida.org> To: mpls@UU.NET Subject: draft-ietf-mpls-te-mib-03.txt IMPORTS nitpick Date: Wed, 12 Apr 2000 18:31:47 -0400 From: Daniel McRobb Sender: owner-mpls@UU.NET Precedence: bulk DisplayString should be imported from SNMPv2-TC since it's used as the syntax for mplsTunnelName and mplsTunnelDescr. Daniel ~~~~~~ From owner-mpls@UU.NET Wed Apr 12 20:27:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05724 for ; Wed, 12 Apr 2000 20:27:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikqz24447; Thu, 13 Apr 2000 00:25:06 GMT Received: by mail-control.mail.uu.net id QQikqz08000 for mpls-outgoing; Thu, 13 Apr 2000 00:24:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQikqz07991 for ; Thu, 13 Apr 2000 00:24:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikqz25832 for ; Wed, 12 Apr 2000 20:24:19 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQikqz23881 for ; Thu, 13 Apr 2000 00:24:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA10766 for mpls@uu.net; Wed, 12 Apr 2000 20:24:13 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQikqz07976 for ; Thu, 13 Apr 2000 00:23:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQikqz06347 for ; Wed, 12 Apr 2000 20:23:43 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQikqz21414 for ; Thu, 13 Apr 2000 00:23:43 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA05499; Wed, 12 Apr 2000 20:23:05 -0400 (EDT) Message-Id: <4.2.2.20000412202425.045f3780@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Apr 2000 20:25:53 -0400 To: Daniel McRobb , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-te-mib-03.txt IMPORTS nitpick Cc: cheenu@tachion.com, arun Viswanathan In-Reply-To: <200004122231.SAA74908@arthur.caida.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1137969==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_1137969==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Daniel, Yes, you are correct. I caught that (and many other) error after the MIB was first compiled with SMIC a few weeks ago. I will be working to correct the compilation errors and warnings found in the MIB as soon as we have finished the next version of the LSR MIB, which is planned to be released this Friday. --Tom >DisplayString should be imported from SNMPv2-TC since it's used as the >syntax for mplsTunnelName and mplsTunnelDescr. > >Daniel >~~~~~~ --=====================_1137969==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Daniel,

        Yes, you are correct. I caught that (and many other)
error after the MIB was first compiled with SMIC a few
weeks ago. I will be working to correct the compilation
errors and warnings found in the MIB as soon as we have
finished the next version of the LSR MIB, which is planned
to be released this Friday.

        --Tom

DisplayString should be imported from SNMPv2-TC since it's used as the
syntax for mplsTunnelName and mplsTunnelDescr.

Daniel
~~~~~~~
--=====================_1137969==_.ALT-- From owner-mpls@UU.NET Thu Apr 13 02:40:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23435 for ; Thu, 13 Apr 2000 02:40:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikry18499; Thu, 13 Apr 2000 06:38:57 GMT Received: by mail-control.mail.uu.net id QQikry14629 for mpls-outgoing; Thu, 13 Apr 2000 06:38:39 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQikry14624 for ; Thu, 13 Apr 2000 06:38:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikry14355 for ; Thu, 13 Apr 2000 02:38:15 -0400 (EDT) Received: from ind.alcatel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.xylan.com [208.8.0.248]) id QQikry18012 for ; Thu, 13 Apr 2000 06:38:14 GMT Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id XAA17644 for ; Wed, 12 Apr 2000 23:38:14 -0700 (PDT) X-Origination-Site: Received: from indc.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id XAA23966; Wed, 12 Apr 2000 23:38:10 -0700 Received: from ind.alcatel.com by indc.xylan.com (8.8.8+Sun/SMI-SVR4 (xylan india [SPOOL])) id XAA16263; Wed, 12 Apr 2000 23:38:05 -0700 (PDT) Message-ID: <38F56B4C.D51BF25E@ind.alcatel.com> Date: Thu, 13 Apr 2000 12:08:04 +0530 From: Prosenjit Pal Organization: Alcatel Internetworking Pvt. Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls Subject: MIB for enabling MPLS options in BGP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, Can anybody give me a pointer on following : 1. MIB for configuring BGP with Route reflection and/or Multi-protocol extension 2. MIB for MPLS-enhanced BGP (carrying labels in BGP UPDATE message) With regards, Prosenjit Pal -- Prosenjit Pal Alcatel Internetworking Pvt. Ltd. voice : +91-80-5097607/8 Extn. 218 (O) +91-80-5211891 (R) fax : +91-80-5097609 email : ppal@ind.alcatel.com (O) prosenjitp@yahoo.com (P) From owner-mpls@UU.NET Thu Apr 13 02:53:17 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23502 for ; Thu, 13 Apr 2000 02:53:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQikrz25471; Thu, 13 Apr 2000 06:52:29 GMT Received: by mail-control.mail.uu.net id QQikrz15291 for mpls-outgoing; Thu, 13 Apr 2000 06:51:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQikrz15286 for ; Thu, 13 Apr 2000 06:51:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQikrz15605 for ; Thu, 13 Apr 2000 02:51:35 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQikrz25646 for ; Thu, 13 Apr 2000 06:50:57 GMT Received: from testras ([165.133.13.22]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id MAA03839 for ; Thu, 13 Apr 2000 12:17:00 -0600 (GMT) Message-ID: <011701bfa514$2449d290$160d85a5@dti.daewoo.co.kr> From: "ashish" To: Subject: cr-ldp Date: Thu, 13 Apr 2000 12:17:25 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0114_01BFA542.3C0246F0" 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_0114_01BFA542.3C0246F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Everybody, I have few queries regarding CR-LDP draft : draft-ietf-mpls-crldp-03.txt = . 1. In traffic parameter TLV, there are 3 fields:=20 a. PBS : Peak Burst Size=20 b. CBS : Committed Burst Size=20 c. EBS : Excess Burst Size =20 Whats the relation between these .=20 2. In Resource Class TLV, its said there are 32 administrative groups or = colors of Resources.=20 Is there any document or draft explaining these Resource Classes. I have checked=20 a)cr-ldp draft and=20 b)RFC -2702 - requirements for Traffic Enggineering over MPLS. But there is not much detail regarding Resource Classes and how = Resources are classified into 32 Resource Classes. Are these Resource Classes Implementation Dependent or there are some = standards for these. Please Clarify Cheers ashish ------=_NextPart_000_0114_01BFA542.3C0246F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Everybody,
I have few queries regarding CR-LDP = draft :=20 draft-ietf-mpls-crldp-03.txt .
1. In traffic=20 parameter TLV, there are 3 fields: 
  a. PBS = : Peak=20 Burst Size 
  b. CBS : Committed = Burst=20 Size 
  c. EBS : Excess Burst=20 Size    
 Whats the relation = between these=20 .
 
2. In Resource Class TLV, its said = there are 32=20 administrative groups or colors of Resources.
Is there any document or draft = explaining these=20 Resource Classes.
I have checked
a)cr-ldp draft and
b)RFC -2702 - requirements for Traffic = Enggineering=20 over MPLS.
But there is not much detail regarding = Resource=20 Classes and how Resources are classified into 32 Resource = Classes.
Are these Resource Classes = Implementation Dependent=20 or there are some standards for these.
Please Clarify
Cheers
ashish
------=_NextPart_000_0114_01BFA542.3C0246F0-- From owner-mpls@UU.NET Thu Apr 13 10:24:18 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02970 for ; Thu, 13 Apr 2000 10:24:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiktd06958; Thu, 13 Apr 2000 14:22:01 GMT Received: by mail-control.mail.uu.net id QQiktd13833 for mpls-outgoing; Thu, 13 Apr 2000 14:21:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiktd13820 for ; Thu, 13 Apr 2000 14:21:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiktd06399 for ; Thu, 13 Apr 2000 10:20:53 -0400 (EDT) From: NENDERLE@bouyguestelecom.fr Received: from bt1sqt7v.bouyguestelecom.fr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: bt1sqt7v.bouyguestelecom.fr [212.208.45.52]) id QQiktd06061 for ; Thu, 13 Apr 2000 14:20:52 GMT Received: from bt1sqt70.bpa.bouyguestelecom.fr (unverified) by bt1sqt7v.bouyguestelecom.fr (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; jeu., 13 avr. 2000 16:15:32 +0200 Received: from bt1sqtbc.bpa.bouyguestelecom.fr (unverified) by bt1sqt70.bpa.bouyguestelecom.fr (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 13 Apr 2000 16:19:17 +0200 Received: by bt1sqtbc.bpa.bouyguestelecom.fr with Internet Mail Service (5.5.2448.0) id <26HBNW2A>; Thu, 13 Apr 2000 16:19:17 +0200 Message-Id: <0717A79626F4D311BAAA00508B9565BF196CB6@bt1sqtem.bpa.bouyguestelecom.fr> To: mpls@UU.NET Subject: LSR and/or IP router ? Date: Thu, 13 Apr 2000 16:19:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02970 Hello, I have a few questions about IP routing capability of LSRs : 1 - Does a core LSR is able to achieve classic IP routing and is there a special label to mean that the MPLS packet is to be considered as an IP packet ? 2 - If not, how LDP (relying on TCP) messages (LABEL_REQUEST and LABEL_MAPPING) can be adressed to a core LSR without a label ? Thanks, Nicolas. > ************************************************************************** > **** > Nicolas ENDERLE > Bouygues Telecom - R & D > Engineer at the Research and Developpement Center > Tél : +33 1 39 45 38 67 > +33 6 61 31 38 67 email : nenderle@bouyguestelecom.fr > Fax : +33 1 39 26 86 13 > ************************************************************************** > **** > From owner-mpls@UU.NET Thu Apr 13 12:37:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07107 for ; Thu, 13 Apr 2000 12:37:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiktm28724; Thu, 13 Apr 2000 16:36:17 GMT Received: by mail-control.mail.uu.net id QQiktm08141 for mpls-outgoing; Thu, 13 Apr 2000 16:35:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiktm08134 for ; Thu, 13 Apr 2000 16:35:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiktm21820 for ; Thu, 13 Apr 2000 12:35:36 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiktm15087 for ; Thu, 13 Apr 2000 16:35:36 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 JAA18747 for ; Thu, 13 Apr 2000 09:35:37 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA09319 for mpls@uu.net; Thu, 13 Apr 2000 12:35:34 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQikrx14229 for ; Thu, 13 Apr 2000 06:26:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQikrx02362 for ; Thu, 13 Apr 2000 02:26:41 -0400 (EDT) Received: from ind.alcatel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.xylan.com [208.8.0.248]) id QQikrx11971 for ; Thu, 13 Apr 2000 06:26:40 GMT Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id XAA17499 for ; Wed, 12 Apr 2000 23:26:40 -0700 (PDT) X-Origination-Site: Received: from indc.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id XAA15755; Wed, 12 Apr 2000 23:26:28 -0700 Received: from ind.alcatel.com by indc.xylan.com (8.8.8+Sun/SMI-SVR4 (xylan india [SPOOL])) id XAA15924; Wed, 12 Apr 2000 23:26:00 -0700 (PDT) Message-ID: <38F56877.A585CFCA@ind.alcatel.com> Date: Thu, 13 Apr 2000 11:55:59 +0530 From: Prosenjit Pal Organization: Alcatel Internetworking Pvt. Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls Subject: Regd. MIB for enabling MPLS options in BGP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, Can anybody give me a pointer on following : 1. MIB for configuring BGP with Route reflection and/or Multi-protocol extension 2. MIB for MPLS-enhanced BGP (carrying labels in BGP UPDATE message) With regards, Prosenjit Pal -- Prosenjit Pal Alcatel Internetworking Pvt. Ltd. voice : +91-80-5097607/8 Extn. 218 (O) +91-80-5211891 (R) fax : +91-80-5097609 email : ppal@ind.alcatel.com (O) prosenjitp@yahoo.com (P) From owner-mpls@UU.NET Thu Apr 13 12:48:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07505 for ; Thu, 13 Apr 2000 12:48:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiktn05911; Thu, 13 Apr 2000 16:47:27 GMT Received: by mail-control.mail.uu.net id QQiktn08878 for mpls-outgoing; Thu, 13 Apr 2000 16:46:54 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiktn08869 for ; Thu, 13 Apr 2000 16:46:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiktn02899 for ; Thu, 13 Apr 2000 12:46:41 -0400 (EDT) Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQiktn05292 for ; Thu, 13 Apr 2000 16:46:40 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id LAA15141; Thu, 13 Apr 2000 11:46:38 -0500 (CDT) Received: from tellabs.com (hdqpcm139.lisle.tellabs.com [138.111.22.139]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA16418; Thu, 13 Apr 2000 11:46:39 -0500 (CDT) Message-ID: <38F5F9F2.A35D8D97@tellabs.com> Date: Thu, 13 Apr 2000 11:46:43 -0500 From: Changcheng Huang X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: akyol@pluris.com CC: mpls@UU.NET, Vishal Sharma , Srinivas Makam , Ken Owens Subject: Re: draft-chang-mpls-path-protection Comments References: <38F3C8EE.39852C79@pluris.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, Thank you for your comments. One particular question you have raised is about using RSVP-TE to support the mechanism defined in this draft. This is a very good question. We have been working on both RSVP and CR-LDP extensions for a while. Currently we see the following problems with RSVP-TE: 1. There are no objects defined in RSVP-TE to identify PSL, PML and a protected path; 2. No mechanism has been provided in RSVP-TE to setup a p2mp LSP for RNT if one carrier choose to use MPLS forwarding rather than hop-by-hop. Currently we are thinking to use the RESV message for the request and Confirmation message for the actual label allocation; 3. There is no notification mechanism defined in RSVP-TE to support FIS or FRS. Currently we are thinking to use PathErr message for this purpose. It requires changing the behavior of a RSVP node. Therefore we are actually thinking an extension to RSVP-TE to support the features defined in this contribution. We would like to listen to your comments and comments from the community on this direction. Thanks, Chang -- Changcheng Huang, Ph.D. Tellabs 4951 Indiana Avenue, MS 64 Lisle, IL 60532 Tel: (630) 512-7954 Fax: (630) 512-8037 akyol@pluris.com wrote: > I have read the draft and have the following comments: > > 1. It is unclear how the RNT mechanism with its FIS/FRS timers differs > from RSVP with TE extensions. Specifically, the timers and the RNT > mechanism resemble RSVP reservations with soft state but with > inverted logic. This should be explained. > 2. The text does not specify via what mechanism the FIS/FRS packets > are transmitted? Via UDP/TCP over IP, via the DCC in the SONET > overhead using ISO CLNS? It would be nice to have some packet > formats and outlines of transmission routines. > 3. It is pointed in the text that MPLS protection reserves bandwidth > but the text fails to mention SONET also reserves bandwidth. > Moreover, in most current IP/MPLS LSRs, unused bandwidth is usually > used for lower traffic classes. > 4. I found sect. 2.2.1 useful. > 5. Are FIS and FRS defined somewhere? > 6. Timers: There are way too many timers. I do understand that the RNT > cuts down on the amount of notifications, but on core routers with > large number of interfaces with large number of LSPs flowing > through them, 8 timers per RNT is a bit much. This is sort of > related to the question 1 above too. > 7. It seems to me that there is a lot of state associated with each > RNT especially when the inverse forking ratio (IFR) is high. It > would help to clearly specify exactly what state needs to be > maintained in a list. > 8. In general, people are not concerned with the volume (bw) of > signaling traffic but the overhead it costs in terms of processing. > > In general, I found the draft of some value, but I think the RNT > mechanism should be either separated from the protection procedure or > put in an appendix. > > RNT bears striking similarity to RSVP and there are already quite a > number of fields defined in RSVP-TE for the purpose of protection > switching signaling, so can we just add what is needed to RSVP-TE? > > The text also omits all discussion of how restoration paths are > computed, what constraints need to be imposed, etc. > > There is also a lack of specificity in the text, which I hope will > improve in a subsequent version. Ideally, an Internet draft should lend > itself to being read and then implemented unlike a research paper. > > Finally, a question to the audience, how does the proposed scheme > interoperate with vendor proprieatry implementations of protection > switching? Now that the cat is out of the bag, we may want to open up > and agree on a standard. > > Thanks > > Bora Akyol From owner-mpls@UU.NET Thu Apr 13 13:26:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08677 for ; Thu, 13 Apr 2000 13:26:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiktp18957; Thu, 13 Apr 2000 17:24:53 GMT Received: by mail-control.mail.uu.net id QQiktp18799 for mpls-outgoing; Thu, 13 Apr 2000 17:24:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiktp18794 for ; Thu, 13 Apr 2000 17:24:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiktp09027 for ; Thu, 13 Apr 2000 13:24:17 -0400 (EDT) Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQiktp28427 for ; Thu, 13 Apr 2000 17:24:16 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id MAA17545; Thu, 13 Apr 2000 12:24:13 -0500 (CDT) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA07773; Thu, 13 Apr 2000 12:24:12 -0500 (CDT) Received: by localhost with Microsoft MAPI; Thu, 13 Apr 2000 13:28:08 -0400 Message-ID: <01BFA54C.1B65D7E0.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'dallan@nortelnetworks.com'" , "akyol@pluris.com" , "mpls@UU.NET" Cc: "Srinivas Makam (E-mail)" , "Chang Huang (E-mail)" , "Ken Owens (E-mail)" Subject: RE: draft-chang-mpls-path-protection Comments Date: Thu, 13 Apr 2000 13:28:07 -0400 Organization: Tellabs Research Center X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dave, Thanks for your comments and observations. Please see our responses below. -Vishal On Wednesday, April 12, 2000 1:15 PM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] wrote: > A few comments: > > 1.0 - The discussion of the limits of SONET protection I find a bit > contentious. I'd suggest the difference between protection at various layers > is when the degree or style of protection is being used as a product or > class of service differentiator and one is trying to bundle that > differentiation into a specific layer. Otherwise everyone gets the same > treatment that the underlying layer provides. We are a little unclear on exactly which portion of 1.0 you are objecting to. We feel that we tried to say things similar to what you say above. > 2.1 - What is an FIS and FRS? Failure Information Signal and Failure Recovery Signal (defined in draft-makam-mpls-recovery-frmwrk-00.txt). Same comment as to Bora, we'll include definitions in our draft in the next revision. > 2.1 - I'd like to see a better definition of "PSLs affected by a fault". Essentially, it means those PSLs that have LSPs going through the faulty link or node. When we have merged working paths, a fault on a particular branch of the mp-p tree may affect only a subset of all PSLs whose traffic is being merged on that tree. We'll make this more precise in the revision. > 3.1 - discussion of establishing the path suggests that the only properties > required is that the path transit the PML and the PSL. Ideally it transits > nothing in common between those two entities (nodes, fibers, conduits etc.) > if multiple simultaneous failures are to be minimized. That is correct. We could add that to the text. > An equally > interesting problem is nodal redundancy on the boundaries of protected > domains to protect against catastrophic nodal failure (like an LSR > crashing... or being crashed into ;-). Yes, but not one we are trying to solve or address in this draft. We recognize in our draft that the PSL and PML can be points of failure. > 3.3 - I'm missing somthing in the discussion of bandwidth reuse in the > protection path. Are we discussing linear protection where the only > opportunity for re-use for LSPs which have common routing between the PSL > and the PML? Actually, I think we implicitly assumed this. However, as you point out, this assumption isn't necessary. We will make this clearer in the revision. > 3.3 - 1:1 is the only protection mode discussed. n+1 is a possibility. and > 1+1 may be derided for bandwidth ineffeciency, but it does not require the > establishment of an RNT, simple forward livliness messages are sufficient > for a PML to select an appropriate source. 1+1 was not covered in our draft, for several reasons: (i) In the 1+1 case, what is the criterion a PML uses to select the traffic from a particular path? Does it make a decision on a packet-by-packet case? How? How does that work if the paths have quite different delays. (ii) 1+1 also introduces complications because 1+1 does not easily allow for merging of working paths (which is the main case we address in our draft). Also, if one does allow for merging of working paths *and* tries to do 1+1 protection, the situation gets fairly complicated. For example, consider the figure in our draft, and assume that the paths 1-2-3-4-6-7 and 8-9-3-4-6-7, are both 1+1 protected. Node 7 now has to select between traffic coming on link 6-7 or that coming on links 5-7 *and* 10-7. Moreover, a fault on link 2-3, which affects only the first path, will require 7 to switch to selecting traffic from the backup paths impinging on it via link 5-7 and via link 6-7. It appears that the simplest way to implement 1+1 protection is to not allow any traffic using 1+1 protection to merge with any other traffic. BTW, even assuming that one does 1+1 protection as described above, the liveness message alone will not be enough to inform the PML, since it is a hop-by-hop mechanism. If a fault occurs more than one link away from the PML, you need another message to let the PML know about that. What we will need in that case is a FIS that propagates in the upstream direction. I assume you mean 1:n (1 for n) in the message above. Yes, that can certainly be done. Again, that pertains to how the path selection algorithm does its job (of course signaling support to indicate 1:n protection is also needed). > At some point in the future, > bandwidth for administrative time/simplicity may be a worthwhile tradeoff. > This would suggest common livliness mechanisms are required, and this should > be acknowledged by attempting to encompass the whole problem/solution space. We could still try to formulate requirements for the 1+1 case, and see if a common FIS mechanism can be propsed. > Ultimately I'm skeptical about the ability to construct parallel mp2p trees > that are usefully diverse and for which the backup is remotely near optimal > due to the constraint of having common PSLs and PML. There is no "requirement" to construct mp2p trees. Rather, it is a natural outcome of the desire or need to merge working traffic. The backup paths may form a tree or they may not. And of course, some intelligence needs to calculate them in accordance with appropriate constraints. > The apparent > requirement to have both working and protection paths converge on the PML > seems artificial and unnecessary (if I am understanding this correctly???). Again, this is not a requirement, but rather an outcome of where the working and protection paths are desired to be merged (selected by the algorithm that selects these paths). The PML is whatever LSR these paths (for a given working path) merge at. Thus, the working and protection paths naturally converge on the PML, by definition, not by any artificial requirement. Also, there could be different PMLs for different working paths (even if these paths merge), and for a particular LSPs, their PMLs could be the egress LSRs for those LSPs. > All a PSL needs to know is that a path has failed, and have a viable > alternative to switch to. For that RNT may be a viable solution, but simply > each protected mp2p LSP has an RNT associated with it so the PSL can make > reasonable and timely decisions and there may be no topological entities in > common between the working path and the protection path (other than the > egress node from the network). Correct. See response above. > Realistically the useful functionality of an > RNT can be distributed across all intermediate LSRs and the concept of an > PML should be capped as simply an administrative concept defining a point > past which an RNT will not propagate (for whatever reason). Indeed that is what it pretty much is. Except that a PML is the LSR at which a working and protection path merge, and not an administrative concept beyond which an RNT will not propagate, since you can have multiple PMLs on the same RNT. (There needs to be a slight correction in our draft, because we say the PML sources the RNT. We need to clarify, that the last PML on a merged working path is the one that sources the RNT.) From owner-mpls@UU.NET Thu Apr 13 13:26:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08691 for ; Thu, 13 Apr 2000 13:26:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiktp19766; Thu, 13 Apr 2000 17:25:49 GMT Received: by mail-control.mail.uu.net id QQiktp18841 for mpls-outgoing; Thu, 13 Apr 2000 17:25:28 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiktp18836 for ; Thu, 13 Apr 2000 17:25:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiktp09165 for ; Thu, 13 Apr 2000 13:25:16 -0400 (EDT) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQiktp28952 for ; Thu, 13 Apr 2000 17:25:16 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id <2Z6RSR48>; Thu, 13 Apr 2000 13:24:38 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A48D02D@email.quarrytech.com> From: "Abes, Andi" To: David Charlap , mpls@UU.NET Subject: RE: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt Date: Thu, 13 Apr 2000 13:24:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David, The following are quoted from rsvp-tunnel-05, sections 3.1 and 3.2 It's the description of the Path and RESV messages - the parts that apply to sender specification. Both messages contain a session object as well (qouted from 4.6.1) (4.6.1) LSP_TUNNEL_IPv4 Session Object Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (4.6.2.1. LSP_TUNNEL_IPv4 Sender Template Object) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (3.1 - path message) ::= [ ] [ ] (3.2 - resv message) ::= | ::= [ ]