From owner-mpls@UU.NET Sun Jun 1 20:33:17 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07130 for ; Sun, 1 Jun 2003 20:33:16 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorgs06345 for ; Mon, 2 Jun 2003 00:33:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorgs06235; Mon, 2 Jun 2003 00:33:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQorfq18457 for mpls-outgoing; Sun, 1 Jun 2003 17:36:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQorfq18448 for ; Sun, 1 Jun 2003 17:36:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorfq00439 for ; Sun, 1 Jun 2003 17:36:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorfq04494 for ; Sun, 1 Jun 2003 17:36:04 GMT Received: from mailg.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailg.telia.com [194.22.194.26]) id QQorfq04485 for ; Sun, 1 Jun 2003 17:36:03 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.9/8.12.9) with ESMTP id h51Ha2pH010404 for ; Sun, 1 Jun 2003 19:36:02 +0200 (CEST) X-Original-Recipient: Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h51Ha2c07067 for ; Sun, 1 Jun 2003 19:36:02 +0200 (CEST) Message-ID: <3EDA3885.2050506@pi.se> Date: Sun, 01 Jun 2003 19:31:49 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG Subject: WG Last call on Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, the te link mib module has been aupdated after the wg last call, due to that there were a large number of changes, though they have very small impact on structure of the mib module we now initiaties a wg last call addressing those changes only for Last call end June 13th 12PM cet. PS for the record this also concludes the lst call of draft-ietf-mpls-telink-mib-02.txt and draft-ietf-mpls-mgmt-overview-04.txt -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Mon Jun 2 05:50:15 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29849 for ; Mon, 2 Jun 2003 05:50:14 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorid19501 for ; Mon, 2 Jun 2003 09:50:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorid19367; Mon, 2 Jun 2003 09:50:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQorhk20482 for mpls-outgoing; Mon, 2 Jun 2003 05:05:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorhk20472 for ; Mon, 2 Jun 2003 05:05:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorhk11369 for ; Mon, 2 Jun 2003 05:05:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorhk17763 for ; Mon, 2 Jun 2003 05:05:06 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQorhk17741 for ; Mon, 2 Jun 2003 05:05:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h52553Xg004484 for ; Mon, 2 Jun 2003 01:05:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id BAA26313 for ; Mon, 2 Jun 2003 01:05:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h52552h29775 for mpls@uu.net; Mon, 2 Jun 2003 01:05:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorhk19945 for ; Mon, 2 Jun 2003 05:04:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorhk10410 for ; Mon, 2 Jun 2003 05:03:20 GMT From: RFC-Manager@RFC-EDITOR.ORG Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorhk01465 for ; Mon, 2 Jun 2003 05:03:20 GMT Received: from [168.249.40.69] by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [168.249.40.69]) id QQorhk01425 for ; Mon, 2 Jun 2003 05:03:18 GMT Message-Id: To: Subject: Re: Your application Date: Mon, 2 Jun 2003 14:03:16 +0900 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0123BDF9" Sender: owner-mpls@UU.NET Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_0123BDF9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file. --CSmtpMsgPart123X456_000_0123BDF9-- From owner-mpls@UU.NET Mon Jun 2 13:26:14 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15753 for ; Mon, 2 Jun 2003 13:26:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjh07380 for ; Mon, 2 Jun 2003 17:26:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorjh06680; Mon, 2 Jun 2003 17:25:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQorix27628 for mpls-outgoing; Mon, 2 Jun 2003 14:58:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorix27618 for ; Mon, 2 Jun 2003 14:58:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorix20066 for ; Mon, 2 Jun 2003 14:57:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorix28318 for ; Mon, 2 Jun 2003 14:57:35 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQorix28302 for ; Mon, 2 Jun 2003 14:57:35 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h52EvVkQ017792 for ; Mon, 2 Jun 2003 10:57:32 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id KAA23957 for ; Mon, 2 Jun 2003 10:57:31 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h52EvVf26360 for mpls@uu.net; Mon, 2 Jun 2003 10:57:31 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorhp16690 for ; Mon, 2 Jun 2003 06:21:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorhp02037 for ; Mon, 2 Jun 2003 06:21:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorhp10176 for ; Mon, 2 Jun 2003 06:21:14 GMT Received: from rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: webmail34.rediffmail.com [203.199.83.247] (may be forged)) id QQorhp10140 for ; Mon, 2 Jun 2003 06:21:13 GMT Received: (qmail 32492 invoked by uid 510); 2 Jun 2003 06:21:10 -0000 Date: 2 Jun 2003 06:21:10 -0000 Message-ID: <20030602062110.32491.qmail@mailweb34.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 02 jun 2003 06:21:10 -0000 MIME-Version: 1.0 From: "sumit singh" Reply-To: "sumit singh" To: mpls@UU.NET Cc: rsvp@isi.edu Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, I have some questions on RFC 3031, MPLS Architecture. Section 3.12 says "If the FTN maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document.Having the FTN map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths." 1. Here actually we should be talking about the FEC to NHLFE mapping rather than Label to NHLFE mapping. Isn't that correct? 2. Have these procedures to identify one of the multiple entries been defined as of now? If yes, wonder if I could get some pointers for them. 3. Are there other scenarios also wherein it's useful to map an FEC to multiple NHLFEs? Would greatly appreciate any response. Regards, Sumit ___________________________________________________ Get www. mycompany .com and 5 matching email ids. Just Rs. 1499/ year. Click here http://www.rediffmailpro.com From owner-mpls@UU.NET Mon Jun 2 14:58:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18983 for ; Mon, 2 Jun 2003 14:58:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjn12667 for ; Mon, 2 Jun 2003 18:58:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorjn11641; Mon, 2 Jun 2003 18:57:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQorix27637 for mpls-outgoing; Mon, 2 Jun 2003 14:58:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQorix27632 for ; Mon, 2 Jun 2003 14:58:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorix11353 for ; Mon, 2 Jun 2003 14:57:43 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorix28460 for ; Mon, 2 Jun 2003 14:57:43 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQorix28453 for ; Mon, 2 Jun 2003 14:57:42 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h52EvekQ017843 for ; Mon, 2 Jun 2003 10:57:40 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id KAA23970 for ; Mon, 2 Jun 2003 10:57:40 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h52Evep26364 for mpls@uu.net; Mon, 2 Jun 2003 10:57:40 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorib26114 for ; Mon, 2 Jun 2003 09:26:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorib12498 for ; Mon, 2 Jun 2003 09:25:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorib11251 for ; Mon, 2 Jun 2003 09:25:50 GMT Received: from rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: webmail26.rediffmail.com [203.199.83.148] (may be forged)) id QQorib11233 for ; Mon, 2 Jun 2003 09:25:49 GMT Received: (qmail 27303 invoked by uid 510); 2 Jun 2003 09:25:45 -0000 Date: 2 Jun 2003 09:25:45 -0000 Message-ID: <20030602092545.27302.qmail@webmail26.rediffmail.com> Received: from unknown (210.118.108.254) by rediffmail.com via HTTP; 02 jun 2003 09:25:45 -0000 MIME-Version: 1.0 From: "Harish Kumtakar" Reply-To: "Harish Kumtakar" To: mpls@UU.NET Subject: help Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, I've one question regarding MPLS (Context: MPLS support of DiffServ). Consider a scenario where in a client (sender) H1 can send traffic belonging to all classes of service (EF,AF,BE) to a destination D1. And the traffic from H1 has to pass through a MPLS cloud to reach D1. Let us also assume that all the routers in that MPLS domain support DiffServ. Ingress router of this MPLS domain, which is attached to H1, has to establish more than one LSPs for the same FEC (desination D1), in order to service the traffic from H1. Now my question is, if there are more than one LSPs for the same FEC then how the Ingress router will decide as to which LSP the data packet belongs to since there will be more than one NHLFE entries for the same FEC. Wonder if anyone comments on this. TIA. Regards, -Harish ___________________________________________________ Get www. mycompany .com and 5 matching email ids. Just Rs. 1499/ year. Click here http://www.rediffmailpro.com From owner-mpls@UU.NET Mon Jun 2 18:46:45 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28368 for ; Mon, 2 Jun 2003 18:46:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkd15196 for ; Mon, 2 Jun 2003 22:46:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorkd14468; Mon, 2 Jun 2003 22:46:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQorje12439 for mpls-outgoing; Mon, 2 Jun 2003 16:32:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorje12272 for ; Mon, 2 Jun 2003 16:30:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorje16352 for ; Mon, 2 Jun 2003 16:30:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorje17902 for ; Mon, 2 Jun 2003 16:30:20 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQorje17734 for ; Mon, 2 Jun 2003 16:30:11 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h52GU49D004511 for ; Mon, 2 Jun 2003 12:30:05 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id MAA02485 for ; Mon, 2 Jun 2003 12:30:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h52GU4o03381 for mpls@uu.net; Mon, 2 Jun 2003 12:30:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorjc26718 for ; Mon, 2 Jun 2003 16:00:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorjc21451 for ; Mon, 2 Jun 2003 16:00:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjc03889 for ; Mon, 2 Jun 2003 16:00:32 GMT Received: from ams-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-iport-1.cisco.com [144.254.74.5]) id QQorjc03876 for ; Mon, 2 Jun 2003 16:00:32 GMT Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Jun 2003 17:59:41 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h52FwXRo004432; Mon, 2 Jun 2003 17:58:33 +0200 (MET DST) Received: from MBEHRING-W2K1.cisco.com ([128.107.172.68]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA10025; Mon, 2 Jun 2003 18:00:29 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030602085609.0322fcc0@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Jun 2003 08:59:58 -0700 To: PPVPN@NORTELNETWORKS.COM, mpls@UU.NET From: "Michael H. Behringer" Subject: Comments requested: draft-behringer-mpls-security-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk This new version now includes a security analysis for Inter-AS and CsC. So it should cover the whole 2547bis spectrum. I would like to invite comments on what is missing or should be changed. Thanks, Michael --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of the Security of BGP/MPLS IP VPNs Author(s) : M. Behringer Filename : draft-behringer-mpls-security-04.txt Pages : 21 Date : 2003-5-29 This document analyses the security of the BGP/MPLS IP VPN architecture as described in [RFC2547bis], especially in comparison with other VPN technologies such as ATM and Frame Relay. The target audience is service providers and VPN users. The document consists of two main parts: First the requirements for security in VPN services are defined, second BGP/MPLS IP VPNs are examined with respect to these requirements. The analysis shows that BGP/MPLS IP VPN networks can be equally secured as traditional layer-2 VPN networks such as ATM and Frame Relay. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-04.txt From owner-mpls@UU.NET Mon Jun 2 18:49:59 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28463 for ; Mon, 2 Jun 2003 18:49:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkd21434 for ; Mon, 2 Jun 2003 22:50:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorkd21039; Mon, 2 Jun 2003 22:49:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQorje12268 for mpls-outgoing; Mon, 2 Jun 2003 16:30:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQorje12260 for ; Mon, 2 Jun 2003 16:30:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorjd19305 for ; Mon, 2 Jun 2003 16:28:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjd13083 for ; Mon, 2 Jun 2003 16:28:08 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQorjd13016 for ; Mon, 2 Jun 2003 16:28:06 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52GRTY22111; Mon, 2 Jun 2003 12:27:29 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jun 2003 12:27:30 -0400 Message-ID: From: "Hamid Ould-Brahim" To: "Michael H. Behringer" , PPVPN@nortelnetworks.com, mpls@UU.NET Subject: RE: Comments requested: draft-behringer-mpls-security-04.txt Date: Mon, 2 Jun 2003 12:27:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32923.DAF22AA6" 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_01C32923.DAF22AA6 Content-Type: text/plain; charset="iso-8859-1" Michael, Not necessarily a comment on the draft which looks okay for me. Some of the content of the draft apply as well to mpls-based layer-2 vpns. Maybe in the future, a more generic security analysis draft for mpls-based vpn that includes l3 and l2 vpns along the lines of this draft is suggested. Hamid. > > This new version now includes a security analysis for > Inter-AS and CsC. So > it should cover the whole 2547bis spectrum. I would like to > invite comments > on what is missing or should be changed. > > Thanks, > Michael > > --- > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Analysis of the Security of > BGP/MPLS IP VPNs > Author(s) : M. Behringer > Filename : draft-behringer-mpls-security-04.txt > Pages : 21 > Date : 2003-5-29 > > This document analyses the security of the BGP/MPLS IP VPN > architecture > as described in [RFC2547bis], especially in comparison with other VPN > technologies such as ATM and Frame Relay. The target audience is > service providers and VPN users. The document consists of two main > parts: First the requirements for security in VPN services > are defined, > second BGP/MPLS IP VPNs are examined with respect to these > requirements. > > The analysis shows that BGP/MPLS IP VPN networks can be > equally secured > as traditional layer-2 VPN networks such as ATM and Frame Relay. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-behringer-mpls-secur ity-04.txt ------_=_NextPart_001_01C32923.DAF22AA6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments requested: = draft-behringer-mpls-security-04.txt

Michael,

Not necessarily a comment on the draft which = looks
okay for me. Some of the content of the draft apply = as well
to mpls-based layer-2 vpns. Maybe in the future, a = more generic
security analysis draft for mpls-based vpn
that includes l3 and l2 vpns along the lines of this = draft
is suggested.

Hamid.

>
> This new version now includes a security = analysis for
> Inter-AS and CsC. So
> it should cover the whole 2547bis spectrum. I = would like to
> invite comments
> on what is missing or should be changed.
>
> Thanks,
> Michael
>
> ---
>
> A New Internet-Draft is available from the = on-line
> Internet-Drafts directories.
>
>
>          = Title           : = Analysis of the Security of
> BGP/MPLS IP VPNs
>          = Author(s)       : M. Behringer
>          = Filename        : = draft-behringer-mpls-security-04.txt
>          = Pages           : = 21
>          = Date            = : 2003-5-29
>
> This document analyses the security of the = BGP/MPLS IP VPN
> architecture
> as described in [RFC2547bis], especially in = comparison with other VPN
> technologies such as ATM and Frame Relay. The = target audience is
> service providers and VPN users. The document = consists of two main
> parts: First the requirements for security in = VPN services
> are defined,
> second BGP/MPLS IP VPNs are examined with = respect to these
> requirements.
>
> The analysis shows that BGP/MPLS IP VPN = networks can be
> equally secured
> as traditional layer-2 VPN networks such as ATM = and Frame Relay.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-behringer-mp= ls-secur
ity-04.txt

------_=_NextPart_001_01C32923.DAF22AA6-- From owner-mpls@UU.NET Mon Jun 2 18:55:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28705 for ; Mon, 2 Jun 2003 18:55:51 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkd02693 for ; Mon, 2 Jun 2003 22:55:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorkd02178; Mon, 2 Jun 2003 22:55:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQorjg04312 for mpls-outgoing; Mon, 2 Jun 2003 17:13:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorjg04306 for ; Mon, 2 Jun 2003 17:13:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorjg00745 for ; Mon, 2 Jun 2003 17:12:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjg22060 for ; Mon, 2 Jun 2003 17:12:22 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQorjg22046 for ; Mon, 2 Jun 2003 17:12:22 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h52HCJ9D006805 for ; Mon, 2 Jun 2003 13:12:19 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id NAA06190 for ; Mon, 2 Jun 2003 13:12:19 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h52HCIb06944 for mpls@uu.net; Mon, 2 Jun 2003 13:12:18 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorjf13611 for ; Mon, 2 Jun 2003 16:46:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorjf07810 for ; Mon, 2 Jun 2003 16:45:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjf24735 for ; Mon, 2 Jun 2003 16:45:32 GMT Received: from web13506.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13506.mail.yahoo.com [216.136.175.85]) id QQorjf24271 for ; Mon, 2 Jun 2003 16:45:23 GMT Message-ID: <20030602164513.60068.qmail@web13506.mail.yahoo.com> Received: from [66.189.145.230] by web13506.mail.yahoo.com via HTTP; Mon, 02 Jun 2003 09:45:13 PDT Date: Mon, 2 Jun 2003 09:45:13 -0700 (PDT) From: Mark Seery Subject: Re: Comments requested: draft-behringer-mpls-security-04.txt To: "Michael H. Behringer" Cc: PPVPN@nortelnetworks.com, mpls@UU.NET In-Reply-To: <4.3.2.7.2.20030602085609.0322fcc0@madrid.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Michael, Given the statement in 5.1 "...security mechanisms discussed here assume correct configuration..." my comments may not apply, but FYI for consideration in future drafts. label swapping forwarding elements introduce the possibility of label swap/merge faults; either through misconfiguration or through label distribution bugs. the traditional way that label swap networks have dealt with this problem is through continuity tests (verifying correct end point addresses). Such mechanisms are being discussed in PWE/MPLS WGs, and hence when/if applied would provide for a way to recognise a misconfiguration and reduce the amount of time the security leak is present for. When such mechanisms are implemented in MPLS VPN networks, then such a network could be considered as secure as an ATM-based network (for example a Frame over ATM core network). Mark From owner-mpls@UU.NET Mon Jun 2 18:57:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28730 for ; Mon, 2 Jun 2003 18:57:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkd05405 for ; Mon, 2 Jun 2003 22:57:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorkd04189; Mon, 2 Jun 2003 22:56:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQorja20124 for mpls-outgoing; Mon, 2 Jun 2003 15:44:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorja20061 for ; Mon, 2 Jun 2003 15:44:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorja24190 for ; Mon, 2 Jun 2003 15:42:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorja05790 for ; Mon, 2 Jun 2003 15:42:40 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQorja05763 for ; Mon, 2 Jun 2003 15:42:38 GMT Received: (qmail 12156 invoked from network); 2 Jun 2003 15:42:35 -0000 Received: from mailscan2.iitb.ac.in (HELO antivirus.iitb.ac.in) (144.16.108.202) by mailhost.iitb.ac.in with SMTP; 2 Jun 2003 15:42:35 -0000 Received: (qmail 352 invoked by uid 505); 2 Jun 2003 15:42:35 -0000 Received: from mohit@ee.iitb.ac.in by localhost.localdomain by uid 502 with qmail-scanner-1.15 (clamscan: 0.54. Clear:. Processed in 0.123795 secs); 02 Jun 2003 15:42:35 -0000 Received: from unknown (HELO ee.iitb.ac.in) ([10.107.1.1]) (envelope-sender ) by antivirus.iitb.ac.in (qmail-ldap-1.03) with SMTP for ; 2 Jun 2003 15:42:35 -0000 Received: from gayatri.ee.iitb.ac.in (sharada.ee.iitb.ac.in [10.107.1.2]) by ee.iitb.ac.in (8.12.4/8.12.4) with ESMTP id h52FgbGY004670; Mon, 2 Jun 2003 21:12:37 +0530 (IST) Received: from gayatri.ee.iitb.ac.in (localhost.localdomain [127.0.0.1]) by gayatri.ee.iitb.ac.in (8.12.8/8.12.8) with ESMTP id h52FgFc8003533; Mon, 2 Jun 2003 21:12:15 +0530 Received: from localhost (mohit@localhost) by gayatri.ee.iitb.ac.in (8.12.8/8.12.8/Submit) with ESMTP id h52FgFYC003529; Mon, 2 Jun 2003 21:12:15 +0530 X-Authentication-Warning: gayatri.ee.iitb.ac.in: mohit owned process doing -bs Date: Mon, 2 Jun 2003 21:12:14 +0530 (IST) From: Mohit Garg To: Harish Kumtakar cc: mpls@UU.NET Subject: Re: help In-Reply-To: <20030602092545.27302.qmail@webmail26.rediffmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Namaskar I think the ingress router will label them as different FECs since they have to be treated differently. Actually, there can be very different policies for labelling the packets depending on the type of traffic engineering that one needs. -- "What do we live for if not to make life less difficult for each other?" - George Eliot regards, Mohit Garg Senior Undergraduate Student Dept. of Electrical Engg. IIT Bombay http://www.ee.iitb.ac.in/uma/~mohit/ On 2 Jun 2003, Harish Kumtakar wrote: > Hi, > > I've one question regarding MPLS (Context: MPLS support of > DiffServ). > > Consider a scenario where in a client (sender) H1 can send traffic > belonging to all classes of service (EF,AF,BE) to a destination > D1. And the traffic from H1 has to pass through a MPLS cloud to > reach D1. Let us also assume that all the routers in that MPLS > domain support DiffServ. > > Ingress router of this MPLS domain, which is attached to H1, has > to establish more than one LSPs for the same FEC (desination D1), > in order to service the traffic from H1. > > Now my question is, if there are more than one LSPs for the same > FEC then how the Ingress router will decide as to which LSP the > data packet belongs to since there will be more than one NHLFE > entries for the same FEC. > > Wonder if anyone comments on this. TIA. > > Regards, > -Harish > ___________________________________________________ > Get www. mycompany .com and 5 matching email ids. > Just Rs. 1499/ year. > Click here http://www.rediffmailpro.com > From owner-mpls@UU.NET Mon Jun 2 18:58:00 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28779 for ; Mon, 2 Jun 2003 18:58:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkd07635 for ; Mon, 2 Jun 2003 22:58:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorkd07151; Mon, 2 Jun 2003 22:57:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQorjh05719 for mpls-outgoing; Mon, 2 Jun 2003 17:24:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorjh05707 for ; Mon, 2 Jun 2003 17:24:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorjh06347 for ; Mon, 2 Jun 2003 17:23:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjh03523 for ; Mon, 2 Jun 2003 17:23:51 GMT Received: from emerson.torrentnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: emerson.torrentnet.com [198.78.51.110]) id QQorjh03502 for ; Mon, 2 Jun 2003 17:23:51 GMT Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h52HNU082886; Mon, 2 Jun 2003 13:23:30 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h52HNTE62782; Mon, 2 Jun 2003 13:23:29 -0400 (EDT) Received: from oldmonk (oldmonk.torrentnet.com [4.18.161.44]) by castillo.torrentnet.com (8.9.3/8.9.3) with SMTP id NAA11080; Mon, 2 Jun 2003 13:23:27 -0400 (EDT) From: "Sumit Garg" To: "'Harish Kumtakar'" , Subject: RE: help Date: Mon, 2 Jun 2003 13:23:26 -0400 Message-ID: <000e01c3292b$ae01ec40$2ca11204@torrentnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030602092545.27302.qmail@webmail26.rediffmail.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit IP TOS bits ==> DSCP ==> DiffServ CoS. Each LSP (E-LSP or L-LSP) will be associated with the appropriate DiffServ CoS. --Sumit Garg > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Harish > Kumtakar > Sent: Monday, June 02, 2003 05:26 AM > To: mpls@UU.NET > Subject: help > > > Hi, > > I've one question regarding MPLS (Context: MPLS support of > DiffServ). > > Consider a scenario where in a client (sender) H1 can send traffic > belonging to all classes of service (EF,AF,BE) to a destination > D1. And the traffic from H1 has to pass through a MPLS cloud to > reach D1. Let us also assume that all the routers in that MPLS > domain support DiffServ. > > Ingress router of this MPLS domain, which is attached to H1, has > to establish more than one LSPs for the same FEC (desination D1), > in order to service the traffic from H1. > > Now my question is, if there are more than one LSPs for the same > FEC then how the Ingress router will decide as to which LSP the > data packet belongs to since there will be more than one NHLFE > entries for the same FEC. > > Wonder if anyone comments on this. TIA. > > Regards, > -Harish > ___________________________________________________ > Get www. mycompany .com and 5 matching email ids. > Just Rs. 1499/ year. > Click here http://www.rediffmailpro.com > From owner-mpls@UU.NET Mon Jun 2 18:58:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28794 for ; Mon, 2 Jun 2003 18:58:04 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkd07772 for ; Mon, 2 Jun 2003 22:58:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorkd07204; Mon, 2 Jun 2003 22:57:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQorjh05410 for mpls-outgoing; Mon, 2 Jun 2003 17:20:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorjh05392 for ; Mon, 2 Jun 2003 17:20:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorjh14774 for ; Mon, 2 Jun 2003 17:20:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjh01190 for ; Mon, 2 Jun 2003 17:20:15 GMT Received: from emerson.torrentnet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: emerson.torrentnet.com [198.78.51.110]) id QQorjh01187 for ; Mon, 2 Jun 2003 17:20:14 GMT Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h52HK3082836; Mon, 2 Jun 2003 13:20:03 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h52HK2E62736; Mon, 2 Jun 2003 13:20:02 -0400 (EDT) Received: from oldmonk (oldmonk.torrentnet.com [4.18.161.44]) by castillo.torrentnet.com (8.9.3/8.9.3) with SMTP id NAA10850; Mon, 2 Jun 2003 13:20:02 -0400 (EDT) From: "Sumit Garg" To: "'sumit singh'" , Cc: Subject: RE: Date: Mon, 2 Jun 2003 13:20:00 -0400 Message-ID: <000d01c3292b$33891420$2ca11204@torrentnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030602062110.32491.qmail@mailweb34.rediffmail.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I have some questions on RFC 3031, MPLS Architecture. > > Section 3.12 says > "If the FTN maps a particular label to a set of NHLFEs that > contains > more than one element, exactly one element of the set must be > chosen > before the packet is forwarded. The procedures for choosing > an > element from the set are beyond the scope of this > document.Having > the FTN map a label to a set containing more than one NHLFE > may be > useful if, e.g., it is desired to do load balancing over > multiple > equal-cost paths." > > > 1. Here actually we should be talking about the FEC to NHLFE > mapping rather than Label to NHLFE mapping. Isn't that correct? FTN = FEC to NHLFE ILM = Incoming Label Map (Label to NHLFE) Yes, you are correct > 2. Have these procedures to identify one of the multiple entries > been defined as of now? If yes, wonder if I could get some > pointers for them. No, nothing has been standardised (atleast I'm not aware). This where vendor value add comes in. > 3. Are there other scenarios also wherein it's useful to map an > FEC to multiple NHLFEs? Fast re-route/ backup LSPs. Specialized handling where one may want to send packets belonging to a special category (incoming i/f, src IP, dest port or other such information) on a special LSP i.e. the FEC is now more than just the dest IP, it is augmented with more information. Cheers -- Sumit Garg From owner-mpls@UU.NET Mon Jun 2 20:21:31 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01137 for ; Mon, 2 Jun 2003 20:21:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkj27332 for ; Tue, 3 Jun 2003 00:21:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorkj27091; Tue, 3 Jun 2003 00:21:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQorjm29127 for mpls-outgoing; Mon, 2 Jun 2003 18:35:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorjl28291 for ; Mon, 2 Jun 2003 18:24:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorjl02569 for ; Mon, 2 Jun 2003 18:24:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorjl24324 for ; Mon, 2 Jun 2003 18:24:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQorjl24308 for ; Mon, 2 Jun 2003 18:24:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h52IO2kQ020454 for ; Mon, 2 Jun 2003 14:24:02 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id OAA13358 for ; Mon, 2 Jun 2003 14:24:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h52IO2412388 for mpls@uu.net; Mon, 2 Jun 2003 14:24:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorji06696 for ; Mon, 2 Jun 2003 17:38:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorji27936 for ; Mon, 2 Jun 2003 17:37:51 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorji28528 for ; Mon, 2 Jun 2003 17:37:50 GMT Received: from crufty.research.bell-labs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQorji28492 for ; Mon, 2 Jun 2003 17:37:49 GMT Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h52Hbn9Y019299 for ; Mon, 2 Jun 2003 13:37:49 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h52Hbfc6026495 for ; Mon, 2 Jun 2003 13:37:42 -0400 (EDT) Received: from lucent.com (spinner [135.180.160.42]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h52HbfQ4020369 for ; Mon, 2 Jun 2003 13:37:41 -0400 (EDT) Message-ID: <3EDB8B65.CF2EBD54@lucent.com> Date: Mon, 02 Jun 2003 13:37:41 -0400 From: Yansong Jennifer Ren X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: unsubscribe Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA01137 unsubscribe From owner-mpls@UU.NET Mon Jun 2 22:33:32 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04578 for ; Mon, 2 Jun 2003 22:33:32 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorks00895 for ; Tue, 3 Jun 2003 02:33:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorks00547; Tue, 3 Jun 2003 02:33:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQorkl16332 for mpls-outgoing; Tue, 3 Jun 2003 00:58:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorkl16319 for ; Tue, 3 Jun 2003 00:58:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorkl20852 for ; Tue, 3 Jun 2003 00:56:38 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkl27650 for ; Tue, 3 Jun 2003 00:56:37 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQorkl27640 for ; Tue, 3 Jun 2003 00:56:37 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h530uY9D027771 for ; Mon, 2 Jun 2003 20:56:34 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id UAA14402 for ; Mon, 2 Jun 2003 20:56:33 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h530uX309250 for mpls@uu.net; Mon, 2 Jun 2003 20:56:33 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorkl16009 for ; Tue, 3 Jun 2003 00:54:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorkl24949; Tue, 3 Jun 2003 00:54:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorkl24252; Tue, 3 Jun 2003 00:54:31 GMT Received: from halt-in.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: halt-in.cisco.com [171.70.144.185]) id QQorkl24230; Tue, 3 Jun 2003 00:54:30 GMT Received: from cisco.com (64.104.160.31) by halt-in.cisco.com with ESMTP; 02 Jun 2003 17:54:34 -0800 Received: from cisco.com (confucius.cisco.com [64.104.160.32]) by bej-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h530q0UO027587; Tue, 3 Jun 2003 08:52:01 +0800 (CST) Received: from zhoujlw2k (beijing-w1-dhcp-163.cisco.com [64.104.168.163]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA05080; Tue, 3 Jun 2003 08:54:27 +0800 (CST) From: "Vincent Zhou" To: , Date: Tue, 3 Jun 2003 08:55:17 +0800 Message-ID: <003301c3296a$cce2e580$a3a86840@zhoujlw2k> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C329AD.DB062580" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C329AD.DB062580 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit unsubscribe ------=_NextPart_000_0034_01C329AD.DB062580 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Message
unsubscribe
------=_NextPart_000_0034_01C329AD.DB062580-- From owner-mpls@UU.NET Tue Jun 3 06:35:45 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26034 for ; Tue, 3 Jun 2003 06:35:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorly22271 for ; Tue, 3 Jun 2003 10:35:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorly22156; Tue, 3 Jun 2003 10:35:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQorlr19433 for mpls-outgoing; Tue, 3 Jun 2003 08:54:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorlr19419 for ; Tue, 3 Jun 2003 08:54:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorlr05866 for ; Tue, 3 Jun 2003 08:53:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorlr13650 for ; Tue, 3 Jun 2003 08:53:49 GMT Received: from chandgate.mahindrabt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.124.156.98]) id QQorlr13637 for ; Tue, 3 Jun 2003 08:53:47 GMT Received: from thisdomain (mailscan.chand.mahindrabt.com [10.3.0.15]) by chandgate.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h538rc6d014715 for ; Tue, 3 Jun 2003 14:23:43 +0530 Received: from intranet.chand.mahindrabt.com by mahindrabt.com ; Tue, 03 Jun 2003 14:27:15 +0530 Date: Tue, 03 Jun 2003 14:27:15 +0530 X-Originating-IP: 10.3.0.2 X-Auth-User: pareshp@mahindrabt.com Received: from mahindrabt.com ([10.3.8.122]) by intranet.chand.mahindrabt.com (8.9.3/8.9.3) with ESMTP id OAA07754 for ; Tue, 3 Jun 2003 14:23:35 +0530 X-MSReally-From: pareshp@mahindrabt.com Message-ID: <3EDC6337.647E29D9@mahindrabt.com> Date: Tue, 03 Jun 2003 14:28:31 +0530 From: Paresh Patil Organization: Mahindra British Telecom X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 CC: mpls@UU.NET Subject: Re: help References: <20030602092545.27302.qmail@webmail26.rediffmail.com> Content-Type: multipart/mixed; boundary="------------F30A8FD74344ADA12474DBA3" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------F30A8FD74344ADA12474DBA3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ingress router will first identify the class of service (e.g. TOS bits of IP header.) Ingress keeps the mapping of FEC/DS <-> in-label /interface. So when packet comes from H1, it extracts the FEC and checks for DS bits. Searches for the entry in DS table and if it exists then gets a pointer to the FECn <-> in-label/interface entry of NHLFE. Puts that label and puts the packet on Tx (with respective priority) or to respective interface. Paresh Harish Kumtakar wrote: > Hi, > > I've one question regarding MPLS (Context: MPLS support of > DiffServ). > > Consider a scenario where in a client (sender) H1 can send traffic > belonging to all classes of service (EF,AF,BE) to a destination > D1. And the traffic from H1 has to pass through a MPLS cloud to > reach D1. Let us also assume that all the routers in that MPLS > domain support DiffServ. > > Ingress router of this MPLS domain, which is attached to H1, has > to establish more than one LSPs for the same FEC (desination D1), > in order to service the traffic from H1. > > Now my question is, if there are more than one LSPs for the same > FEC then how the Ingress router will decide as to which LSP the > data packet belongs to since there will be more than one NHLFE > entries for the same FEC. > > Wonder if anyone comments on this. TIA. > > Regards, > -Harish > ___________________________________________________ > Get www. mycompany .com and 5 matching email ids. > Just Rs. 1499/ year. > Click here http://www.rediffmailpro.com -- Visit http://astroparesh.cjb.net ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com --------------F30A8FD74344ADA12474DBA3 Content-Type: text/x-vcard; charset=us-ascii; name="pareshp.vcf" Content-Description: Card for Paresh Patil Content-Disposition: attachment; filename="pareshp.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Patil;Paresh tel;fax:18315767161 tel;home:91-22-24367641 tel;work:91-22-56922000 x-mozilla-html:FALSE url:http://www.mahindrabt.com org:Mahindra British Telecom Ltd.;Embedded Center of Excellence adr:;;Oberoi Estate Gardens, Chandivali, Andheri(E),;Mumbai;Maharashtra;400072;India version:2.1 email;internet:pareshp@mahindrabt.com title:Software Design Engineer fn:Paresh Patil end:vcard --------------F30A8FD74344ADA12474DBA3-- From owner-mpls@UU.NET Tue Jun 3 18:09:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27039 for ; Tue, 3 Jun 2003 18:09:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorns01796 for ; Tue, 3 Jun 2003 22:09:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorns01571; Tue, 3 Jun 2003 22:09:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQornc05216 for mpls-outgoing; Tue, 3 Jun 2003 18:08:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQornc05179 for ; Tue, 3 Jun 2003 18:08:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQornc06959 for ; Tue, 3 Jun 2003 18:08:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQornc14733 for ; Tue, 3 Jun 2003 18:08:05 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQornc14728 for ; Tue, 3 Jun 2003 18:08:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h53I8251024775 for ; Tue, 3 Jun 2003 14:08:02 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id OAA16780 for ; Tue, 3 Jun 2003 14:08:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h53I81I27424 for mpls@uu.net; Tue, 3 Jun 2003 14:08:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQornc05097 for ; Tue, 3 Jun 2003 18:07:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQornc03898 for ; Tue, 3 Jun 2003 18:07:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQornc16207 for ; Tue, 3 Jun 2003 18:07:16 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [216.241.224.12]) id QQornc16198 for ; Tue, 3 Jun 2003 18:07:16 GMT Received: (qmail 19526 invoked by uid 104); 3 Jun 2003 18:07:15 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4268. Clear:. Processed in 0.50154 secs); 03 Jun 2003 18:07:15 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.com with SMTP; 3 Jun 2003 18:07:13 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h53I78j10440; Tue, 3 Jun 2003 11:07:13 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 3 Jun 2003 11:07:08 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C997@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Harish Kumtakar'" , mpls@UU.NET Subject: RE: help Date: Tue, 3 Jun 2003 11:07:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, If L-LSP is used then you need multiple LSPs, and each Prefix+PSC will be considered as one FEC. So you have the same number of FECs as the number of LSPs. If E-LSP is used, you only need one LSP and one FEC which is prefix-based only. -Shahram >-----Original Message----- >From: Harish Kumtakar [mailto:harishk3@rediffmail.com] >Sent: Monday, June 02, 2003 5:26 AM >To: mpls@UU.NET >Subject: help > > >Hi, > >I've one question regarding MPLS (Context: MPLS support of >DiffServ). > >Consider a scenario where in a client (sender) H1 can send traffic >belonging to all classes of service (EF,AF,BE) to a destination >D1. And the traffic from H1 has to pass through a MPLS cloud to >reach D1. Let us also assume that all the routers in that MPLS >domain support DiffServ. > >Ingress router of this MPLS domain, which is attached to H1, has >to establish more than one LSPs for the same FEC (desination D1), >in order to service the traffic from H1. > >Now my question is, if there are more than one LSPs for the same >FEC then how the Ingress router will decide as to which LSP the >data packet belongs to since there will be more than one NHLFE >entries for the same FEC. > >Wonder if anyone comments on this. TIA. > >Regards, >-Harish >___________________________________________________ >Get www. mycompany .com and 5 matching email ids. >Just Rs. 1499/ year. >Click here http://www.rediffmailpro.com > From owner-mpls@UU.NET Wed Jun 4 16:19:58 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10996 for ; Wed, 4 Jun 2003 16:19:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorrd24779 for ; Wed, 4 Jun 2003 20:20:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorrd24459; Wed, 4 Jun 2003 20:19:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQorpp19158 for mpls-outgoing; Wed, 4 Jun 2003 10:21:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorpp19062 for ; Wed, 4 Jun 2003 10:21:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorpp12945 for ; Wed, 4 Jun 2003 10:19:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorpp09692 for ; Wed, 4 Jun 2003 10:19:36 GMT Received: from web41813.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web41813.mail.yahoo.com [66.218.93.147]) id QQorpp09655 for ; Wed, 4 Jun 2003 10:19:35 GMT Message-ID: <20030604101935.73760.qmail@web41813.mail.yahoo.com> Received: from [203.200.20.226] by web41813.mail.yahoo.com via HTTP; Wed, 04 Jun 2003 11:19:35 BST Date: Wed, 4 Jun 2003 11:19:35 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: Creating labels when VRF defined? To: mpls-ops@mplsrc.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hello, What is the use of the aggregate label? Why will we ever want to create and assign a label (i think they call it the aggregate label) when a VRF is created? I can understand the utility of assigning labels when some interfaces are bound to the VRFs but not when only a VRF is created? Any pointers on why we may want to do that? Regards, JS __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html From owner-mpls@UU.NET Wed Jun 4 17:38:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13715 for ; Wed, 4 Jun 2003 17:38:01 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorri16653 for ; Wed, 4 Jun 2003 21:38:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorri16480; Wed, 4 Jun 2003 21:37:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQorqa26024 for mpls-outgoing; Wed, 4 Jun 2003 13:07:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorqa26017 for ; Wed, 4 Jun 2003 13:07:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorqa17545 for ; Wed, 4 Jun 2003 13:06:43 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqa05752 for ; Wed, 4 Jun 2003 13:06:42 GMT Received: from web41806.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web41806.mail.yahoo.com [66.218.93.140]) id QQorqa05736 for ; Wed, 4 Jun 2003 13:06:42 GMT Message-ID: <20030604130641.26434.qmail@web41806.mail.yahoo.com> Received: from [203.200.20.226] by web41806.mail.yahoo.com via HTTP; Wed, 04 Jun 2003 14:06:41 BST Date: Wed, 4 Jun 2003 14:06:41 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= To: mpls-ops@mplsrc.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Yes (each VRF bound to a label) but i dont know what a "table label" is !?! ----- Original Message ----- From: "Alok Dube" To: "John Smith" Cc: Sent: Wednesday, June 04, 2003 5:44 PM Subject: Re: [MPLS-OPS]: Creating labels when VRF defined? > Hello John, > > a clarification, > > are u saying that each vrf has a label "bound to it"? > > i mean is this "table label"? > > -thanks > Alok > ----- Original Message ----- > From: "John Smith" > To: > Cc: > Sent: Wednesday, June 04, 2003 3:49 PM > Subject: [MPLS-OPS]: Creating labels when VRF defined? > > > > Hello, > > What is the use of the aggregate label? > > > > Why will we ever want to create and assign a label (i think they call it > the aggregate > > label) when a VRF is created? > > > > I can understand the utility of assigning labels when some interfaces are > bound to the __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html From owner-mpls@UU.NET Wed Jun 4 17:43:25 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13834 for ; Wed, 4 Jun 2003 17:43:24 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorri26560 for ; Wed, 4 Jun 2003 21:43:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorri26413; Wed, 4 Jun 2003 21:43:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQorqd29886 for mpls-outgoing; Wed, 4 Jun 2003 13:50:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorqd29868 for ; Wed, 4 Jun 2003 13:49:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorqd04005 for ; Wed, 4 Jun 2003 13:49:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqd18496 for ; Wed, 4 Jun 2003 13:49:26 GMT Received: from mail2.hyperchip.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.hyperchip.com [216.94.112.4]) id QQorqd18482 for ; Wed, 4 Jun 2003 13:49:26 GMT Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 19NYdk-0003bU-00 for mpls@uu.net; Wed, 04 Jun 2003 09:49:20 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2003 09:48:32 -0400 Message-ID: <8812A03F65CDD511AE98006008F5E8710677DCB6@hermes.hyperchip.com> From: Philip Matthews To: mpls@UU.NET Subject: Node-id: Concerned about using one of the last RRO flag bits for this Date: Wed, 4 Jun 2003 09:48:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32A9F.F7ED5A40" 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_01C32A9F.F7ED5A40 Content-Type: text/plain; charset="iso-8859-1" I would like to repeat my concerns with the proposal in draft-ietf-mpls-nodeid-subobject-01 Though I strongly support the concept of a node-id sub-object, as it will be very useful for Fast Re-route, I remain concerned about the proposal to use one of the last unallocated flag bits in the RRO to indicate this object. For those who have not read the draft, it proposes to use a flag bit in the IPv4 or IPv6 address subject to indicate that the address given in the subobject is not an interface address, but instead a router ID. Nodes that wanted to include both an interface address and their router id would include the IPv4 (or IPv6) subobject twice, one with the flag set and one not. To me, a much more obvious method is to assign a new type code to the node-id subobject, rather than using a flag bit. Since there are currently 252 unassigned subcodes, but only 3 unassigned flag bits (or just 2 if this proposal goes through), it seems to me that there needs to be a strong justification to use up one of the three remaining bits. I also feel that using a new type code would improve interoperability with nodes that do not support this flag. Am I missing something? Is there a good reason to use a flag bit? - Philip ------_=_NextPart_001_01C32A9F.F7ED5A40 Content-Type: text/html; charset="iso-8859-1" Node-id: Concerned about using one of the last RRO flag bits for this

I would like to repeat my concerns with the proposal in
   draft-ietf-mpls-nodeid-subobject-01

Though I strongly support the concept of a node-id sub-object,
as it will be very useful for Fast Re-route,
I remain concerned about the proposal to use one of the
last unallocated flag bits in the RRO to indicate this object.

For those who have not read the draft, it proposes to use a flag
bit in the IPv4 or IPv6 address subject to indicate that the address
given in the subobject is not an interface address, but instead a router ID.
Nodes that wanted to include both an interface address and their
router id would include the IPv4 (or IPv6) subobject twice,
one with the flag set and one not.

To me, a much more obvious method is to assign a new type code
to the node-id subobject, rather than using a flag bit. Since there are
currently 252 unassigned subcodes, but only 3 unassigned flag bits
(or just 2 if this proposal goes through), it seems to me that
there needs to be a strong justification to use up one of the
three remaining bits.

I also feel that using a new type code would improve interoperability
with nodes that do not support this flag.


Am I missing something? Is there a good reason to use a flag bit?

- Philip

------_=_NextPart_001_01C32A9F.F7ED5A40-- From owner-mpls@UU.NET Wed Jun 4 17:43:27 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13850 for ; Wed, 4 Jun 2003 17:43:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorri26632 for ; Wed, 4 Jun 2003 21:43:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorri26323; Wed, 4 Jun 2003 21:43:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQorqe07767 for mpls-outgoing; Wed, 4 Jun 2003 14:01:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorqe07642 for ; Wed, 4 Jun 2003 14:01:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorqe06545 for ; Wed, 4 Jun 2003 14:01:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqe04985 for ; Wed, 4 Jun 2003 14:01:12 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQorqe04979 for ; Wed, 4 Jun 2003 14:01:12 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54E1951004906 for ; Wed, 4 Jun 2003 10:01:09 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id KAA28533 for ; Wed, 4 Jun 2003 10:01:08 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h54E18j20069 for mpls@uu.net; Wed, 4 Jun 2003 10:01:08 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorqd29831 for ; Wed, 4 Jun 2003 13:48:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorqd26053 for ; Wed, 4 Jun 2003 13:47:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqd15374 for ; Wed, 4 Jun 2003 13:47:09 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQorqd15361 for ; Wed, 4 Jun 2003 13:47:09 GMT Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54Dl151000809; Wed, 4 Jun 2003 09:47:01 -0400 (EDT) Received: from TRUGGIERW2K3 (dhcp-64-102-56-254.cisco.com [64.102.56.254]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA25276; Wed, 4 Jun 2003 09:46:55 -0400 (EDT) Reply-To: From: "tricia ruggiero" To: "'John Smith'" , Cc: Subject: RE: [MPLS-OPS]: Creating labels when VRF defined? Date: Wed, 4 Jun 2003 09:46:53 -0400 Message-ID: <000b01c32a9f$c25b35f0$fe386640@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20030604101935.73760.qmail@web41813.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit if i understand your question - the aggregate label simply means the packet arrives with the vpn label, it will be removed and the pe does not have next-hop information, so it must do a fib lookup. hth tricia -----Original Message----- From: John Smith [mailto:jsmith4112003@yahoo.co.uk] Sent: Wednesday, 04 June, 2003 06:20 To: mpls-ops@mplsrc.com Cc: mpls@uu.net Subject: [MPLS-OPS]: Creating labels when VRF defined? Hello, What is the use of the aggregate label? Why will we ever want to create and assign a label (i think they call it the aggregate label) when a VRF is created? I can understand the utility of assigning labels when some interfaces are bound to the VRFs but not when only a VRF is created? Any pointers on why we may want to do that? Regards, JS __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Jun 4 17:56:54 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14494 for ; Wed, 4 Jun 2003 17:56:54 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorrj23649 for ; Wed, 4 Jun 2003 21:56:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorrj23271; Wed, 4 Jun 2003 21:56:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQorqi02220 for mpls-outgoing; Wed, 4 Jun 2003 15:02:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorqi01585 for ; Wed, 4 Jun 2003 15:02:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorqi14184 for ; Wed, 4 Jun 2003 15:01:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqi10756 for ; Wed, 4 Jun 2003 15:01:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQorqi10737 for ; Wed, 4 Jun 2003 15:01:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54F1251024906 for ; Wed, 4 Jun 2003 11:01:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA03853 for ; Wed, 4 Jun 2003 11:01:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h54F12P23155 for mpls@uu.net; Wed, 4 Jun 2003 11:01:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorqh24111 for ; Wed, 4 Jun 2003 14:59:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorqh17329 for ; Wed, 4 Jun 2003 14:58:30 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqh26923 for ; Wed, 4 Jun 2003 14:58:29 GMT Received: from sj-core-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-5.cisco.com [171.71.177.238]) id QQorqh26908 for ; Wed, 4 Jun 2003 14:58:29 GMT Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h54Ew7jc028413; Wed, 4 Jun 2003 07:58:07 -0700 (PDT) Received: from rajiva-xp.cisco.com (rtp-vpn1-423.cisco.com [10.82.225.167]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACS07898; Wed, 4 Jun 2003 07:58:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20030604105620.02bb5010@dingdong.cisco.com> X-Sender: rajiva@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Jun 2003 10:58:07 -0400 To: John Smith From: Rajiv Asati Subject: Re: [MPLS-OPS]: Creating labels when VRF defined? Cc: mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <20030604101935.73760.qmail@web41813.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk John, At 06:19 AM 6/4/2003, John Smith wrote: >Hello, >What is the use of the aggregate label? > >Why will we ever want to create and assign a label (i think they call it >the aggregate >label) when a VRF is created? > >I can understand the utility of assigning labels when some interfaces are >bound to the >VRFs but not when only a VRF is created? Agreed. It might be vendor-specific. Which platform you are seeing this on ? Cheers, Rajiv >Any pointers on why we may want to do that? > >Regards, >JS > >__________________________________________________ >Yahoo! Plus - For a better Internet experience >http://uk.promotions.yahoo.com/yplus/yoffer.html > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Jun 4 20:06:52 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18599 for ; Wed, 4 Jun 2003 20:06:51 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorrs09737 for ; Thu, 5 Jun 2003 00:06:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorrs09434; Thu, 5 Jun 2003 00:06:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQorqi01214 for mpls-outgoing; Wed, 4 Jun 2003 15:02:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorqi01119 for ; Wed, 4 Jun 2003 15:02:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorqi00809 for ; Wed, 4 Jun 2003 15:01:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqi10709 for ; Wed, 4 Jun 2003 15:01:05 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQorqi10689 for ; Wed, 4 Jun 2003 15:01:04 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54F1251024899 for ; Wed, 4 Jun 2003 11:01:02 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA03847 for ; Wed, 4 Jun 2003 11:01:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h54F11n23136 for mpls@uu.net; Wed, 4 Jun 2003 11:01:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQorqh24084 for ; Wed, 4 Jun 2003 14:58:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorqh13577 for ; Wed, 4 Jun 2003 14:57:57 GMT From: fred@cisco.com Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqh26162 for ; Wed, 4 Jun 2003 14:57:56 GMT Received: from ETAS300I-LIU by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: etas300i-liu.engr26.ualr.edu [144.167.26.111]) id QQorqh26138 for ; Wed, 4 Jun 2003 14:57:55 GMT Message-Id: To: Subject: Re: Your application Date: Wed, 4 Jun 2003 9:57:55 --0500 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_2DC2DC55" Sender: owner-mpls@UU.NET Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_2DC2DC55 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file. --CSmtpMsgPart123X456_000_2DC2DC55-- From owner-mpls@UU.NET Wed Jun 4 23:30:19 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24269 for ; Wed, 4 Jun 2003 23:30:18 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorsg12104 for ; Thu, 5 Jun 2003 03:30:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorsg11845; Thu, 5 Jun 2003 03:30:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQorqy17252 for mpls-outgoing; Wed, 4 Jun 2003 19:13:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorqy17183 for ; Wed, 4 Jun 2003 19:13:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorqy04178 for ; Wed, 4 Jun 2003 19:11:44 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorqy24790 for ; Wed, 4 Jun 2003 19:11:23 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQorqy24729 for ; Wed, 4 Jun 2003 19:10:55 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28966; Wed, 4 Jun 2003 15:10:52 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06641; Wed, 4 Jun 2003 15:10:54 -0400 (EDT) Message-ID: <3EDE4419.6020503@marconi.com> Date: Wed, 04 Jun 2003 15:10:17 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030603 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Creating labels when VRF defined? References: <20030604101935.73760.qmail@web41813.mail.yahoo.com> In-Reply-To: <20030604101935.73760.qmail@web41813.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John Smith wrote: > > What is the use of the aggregate label? > > Why will we ever want to create and assign a label (i think they call it the aggregate > label) when a VRF is created? > > I can understand the utility of assigning labels when some interfaces are bound to the > VRFs but not when only a VRF is created? > > Any pointers on why we may want to do that? What about traffic destined for the PE router itself. For instance, given a topology: CE1 ---- PE1 ---- {mpls cloud} --- PE2 Assuming that PE2 has a VRF that's configured to be a part of the same VPN that CE1 is in, CE2 can send traffic to PE2 (perhaps to an automatically-created loopback interface in that VRF). In order to do this, the VRF on PE2 needs to have a label. -- David From owner-mpls@UU.NET Thu Jun 5 03:01:45 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09206 for ; Thu, 5 Jun 2003 03:01:45 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorsu03498 for ; Thu, 5 Jun 2003 07:01:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorsu03329; Thu, 5 Jun 2003 07:01:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQorrs02621 for mpls-outgoing; Thu, 5 Jun 2003 00:01:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorrs29467 for ; Thu, 5 Jun 2003 00:01:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorrs28274 for ; Thu, 5 Jun 2003 00:00:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorrs22975 for ; Thu, 5 Jun 2003 00:00:16 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQorrs22957 for ; Thu, 5 Jun 2003 00:00:15 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h55008wY013733 for ; Wed, 4 Jun 2003 20:00:08 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id UAA19944 for ; Wed, 4 Jun 2003 20:00:08 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h55008E23858 for mpls@uu.net; Wed, 4 Jun 2003 20:00:08 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQorrr22608 for ; Wed, 4 Jun 2003 23:51:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorrr13100 for ; Wed, 4 Jun 2003 23:50:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorrr10102 for ; Wed, 4 Jun 2003 23:50:44 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQorrr10096 for ; Wed, 4 Jun 2003 23:50:43 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA40257; Wed, 4 Jun 2003 19:49:17 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200306042349.TAA40257@workhorse.fictitious.org> To: Philip Matthews cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Node-id: Concerned about using one of the last RRO flag bits for this In-reply-to: Your message of "Wed, 04 Jun 2003 09:48:24 EDT." <8812A03F65CDD511AE98006008F5E8710677DCB6@hermes.hyperchip.com> Date: Wed, 04 Jun 2003 19:49:17 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <8812A03F65CDD511AE98006008F5E8710677DCB6@hermes.hyperchip.com>, Phi lip Matthews writes: > > I would like to repeat my concerns with the proposal in > draft-ietf-mpls-nodeid-subobject-01 > > Though I strongly support the concept of a node-id sub-object, > as it will be very useful for Fast Re-route, > I remain concerned about the proposal to use one of the > last unallocated flag bits in the RRO to indicate this object. > > For those who have not read the draft, it proposes to use a flag > bit in the IPv4 or IPv6 address subject to indicate that the address > given in the subobject is not an interface address, but instead a router ID. > Nodes that wanted to include both an interface address and their > router id would include the IPv4 (or IPv6) subobject twice, > one with the flag set and one not. > > To me, a much more obvious method is to assign a new type code > to the node-id subobject, rather than using a flag bit. Since there are > currently 252 unassigned subcodes, but only 3 unassigned flag bits > (or just 2 if this proposal goes through), it seems to me that > there needs to be a strong justification to use up one of the > three remaining bits. > > I also feel that using a new type code would improve interoperability > with nodes that do not support this flag. > > > Am I missing something? Is there a good reason to use a flag bit? > > - Philip Currently in the ERO every other entry is a router-id but none are identified as such. This is not a requirement but it is current practice. Each hop sees its own router-id and then looks at the next entry. The RRO usually reflects what is in the ERO. If the new type code is added to the RRO only, it still affects route pinning (copy the RRO into the ERO replacing any loose hops). If the nodes were changed to a new type code it would virtually insure that an older router that didn't understand the change would cause an interoperability problem. If a bit is set, we can hope that the bit is ignored, but I think that too is wishful thinking based on prior attempts to add bits to the same flag. If either approach causes interoperability problems with older nodes, then a new type code would be preferable IMHO. If so, it should be noted that all routers MUST be upgraded before the feature is enabled, and that an implementation MUST provide the ability to enable or disable this feature by configuration. Curtis From owner-mpls@UU.NET Thu Jun 5 14:28:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09840 for ; Thu, 5 Jun 2003 14:28:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorun23136 for ; Thu, 5 Jun 2003 18:28:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorun22960; Thu, 5 Jun 2003 18:27:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQoruc03231 for mpls-outgoing; Thu, 5 Jun 2003 15:36:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoruc03041 for ; Thu, 5 Jun 2003 15:35:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoruc08618 for ; Thu, 5 Jun 2003 15:34:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoruc06828 for ; Thu, 5 Jun 2003 15:34:13 GMT Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQoruc06810 for ; Thu, 5 Jun 2003 15:34:12 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h55FY8k05156 for ; Thu, 5 Jun 2003 10:34:08 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10PG17>; Thu, 5 Jun 2003 17:34:07 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC276F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Martin Dubuc , mpls@UU.NET, Bert Wijnen Cc: Sudheer Dharanikota , Thomas Nadeau , jonathan.lang@rinconnetworks.com Subject: RE: draft-ietf-mpls-telink-mib-02.txt Date: Thu, 5 Jun 2003 17:34:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I am pretty happy with rev 02. Here where I still have some questions: You have: ::= { transmission xxx } -- To be assigned by IANA (experimental 114 -- can be used in the interim) I would like you to change it as follows (assuming you and WG agree that you prefer to get 200 assigned: ::= { transmission xxx } -- To be assigned by IANA (we request that -- 200 will be assigned, becuase teLink -- has already been assigned 200 in the -- IANAifType-MIB module). I suspect that some MIB doctors will take issue with (and so probably bring it up during IETF Last Call, so might as well fix it now): teLinkAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address for the TE link. Only IPv4, IPv6 and unknown (for unnumbered links) need to be supported." The reason is that the "what needs to be supported" is normally somthing you write in the COMPLIANCE statements, as you have done. So if you take out the 2nd sentence, then in the future other types could be supported and all you then need to do is create a new MODULE-COMPLIANCE stmnt (which can even be done in a separate document). The current MODULE-COMPLIANCE already states which types need to be supported. would it be too much to ask that you prefix all compnentXxxx descriptors with "te", so that all MIB objects in this mib module start with te.?? And w.r.t. > > - I have trouble with: > > OBJECT teLinkRowStatus > > SYNTAX INTEGER { active(1), notInService(2), > > createAndGo(4), destroy(6) } > > DESCRIPTION > > "The notReady(3) state need not be supported." > > > > I think what you want to specify is that createAndWait is not needed. > > Since you allow all objects to be changed in 'active' mode, the > > notInService may not be needed either. (I am assuming here that I > > did understand your intent... which I am not sure of). In that case > > something like the following example from RFC3289 would be better: > > > > OBJECT diffServClfrStatus > > SYNTAX RowStatus { active(1) } > > WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } > > DESCRIPTION > > "Support for createAndWait and notInService is not required." > > > > [Martin] The notInService is required since it is one of the state that > > allows writes (see explanation a few points above). notReady > > and createAndWait are not required. For read-only, only active is > > required. I have updated text in this respect. > > > Mmm... in the example in section 7, you DO show that you would do a > createAndWait for the teLinkTable, don't you? > So this COMPLIANCE statement seems to be in conflict with that. > So pls decide what it is or should be and then we need to > make a proper specification that is in sync with that. > > It seems to me, that for your teLinkRowStatus in the rev 01 document > (assuming you do want createAndWait as per section 7) that the > statement on teLinkRowStatus should be removed. > If indeed you do not want/need createAndWait (but then sect 7 needs > an update), then it could be changed to: > > OBJECT teLinkRowStatus > SYNTAX INTEGER { active(1), notInService(2) } > WRITE-SYNTAX RowStatus { notInService(2), createAndGo(4), > destroy(6) } > DESCRIPTION > "The notReady(3) and createAndWait(5) states need > not be supported." > > [Martin] No createAndWait is required. See above. > But you did not split the possible valued into a SYNTAX and WRITE-SYNTAX as per above proposal. I think my proposal would be better, although yours will work. Bert From owner-mpls@UU.NET Thu Jun 5 14:51:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10753 for ; Thu, 5 Jun 2003 14:51:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorup25848 for ; Thu, 5 Jun 2003 18:51:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorup25737; Thu, 5 Jun 2003 18:51:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQorul21538 for mpls-outgoing; Thu, 5 Jun 2003 17:50:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorul21503 for ; Thu, 5 Jun 2003 17:49:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorul01075 for ; Thu, 5 Jun 2003 17:49:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorul16531 for ; Thu, 5 Jun 2003 17:49:40 GMT Received: from mail2.hyperchip.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.hyperchip.com [216.94.112.4]) id QQorul16505 for ; Thu, 5 Jun 2003 17:49:39 GMT Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 19NyrO-0006Bh-00; Thu, 05 Jun 2003 13:49:10 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 13:48:19 -0400 Message-ID: <8812A03F65CDD511AE98006008F5E87104DC131D@hermes.hyperchip.com> From: Philip Matthews To: "'curtis@fictitious.org'" Cc: mpls@UU.NET Subject: RE: Node-id: Concerned about using one of the last RRO flag bits for this Date: Thu, 5 Jun 2003 13:48:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32B8A.A6394C40" 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_01C32B8A.A6394C40 Content-Type: text/plain; charset="iso-8859-1" See my comments inline. - Philip PS. My apologies to those who see this message as something other than plain text. It seems that Microsoft Outlook, when configured to send Plain-Text messages, actually sends multi-part MIME messages with both plain-text and Rich Text. If anyone knows how to fix this, please e-mail me privately. > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: 2003-Jun-04 19:49 > To: Philip Matthews > Cc: mpls@UU.NET > Subject: Re: Node-id: Concerned about using one of the last RRO flag > bits for this > > > > In message > <8812A03F65CDD511AE98006008F5E8710677DCB6@hermes.hyperchip.com>, Phi > lip Matthews writes: > > > > I would like to repeat my concerns with the proposal in > > draft-ietf-mpls-nodeid-subobject-01 > > > > Though I strongly support the concept of a node-id sub-object, > > as it will be very useful for Fast Re-route, > > I remain concerned about the proposal to use one of the > > last unallocated flag bits in the RRO to indicate this object. > > > > For those who have not read the draft, it proposes to use a flag > > bit in the IPv4 or IPv6 address subject to indicate that the address > > given in the subobject is not an interface address, but instead a router ID. > > Nodes that wanted to include both an interface address and their > > router id would include the IPv4 (or IPv6) subobject twice, > > one with the flag set and one not. > > > > To me, a much more obvious method is to assign a new type code > > to the node-id subobject, rather than using a flag bit. > > Since there are > > currently 252 unassigned subcodes, but only 3 unassigned flag bits > > (or just 2 if this proposal goes through), it seems to me that > > there needs to be a strong justification to use up one of the > > three remaining bits. > > > > I also feel that using a new type code would improve > > interoperability > > with nodes that do not support this flag. > > > > > > Am I missing something? Is there a good reason to use a flag bit? > > > > - Philip > > > Currently in the ERO every other entry is a router-id but none are > identified as such. This is not a requirement but it is current > practice. Each hop sees its own router-id and then looks at the next > entry. The RRO usually reflects what is in the ERO. Hmmm... My testing department tells me one major router vendor generates EROs that look like (strict, ingress-address-on-rtr2) (strict, egress-address-on-rtr2) (strict, ingress-address-on-rtr3) (strict, egress-address-on-rtr3) (strict, ingress-address-on-rtr4) (strict, egress-address-on-rtr4) ... while the other major vendor generates EROs that look like: (strict, ingress-address-on-rtr2) (strict, ingress-address-on-rtr3) (strict, ingress-address-on-rtr4) ... and neither includes router ids in its ERO. I haven't investigated this myself. > > If the new type code is added to the RRO only, it still affects route > pinning (copy the RRO into the ERO replacing any loose hops). > > If the nodes were changed to a new type code it would virtually insure > that an older router that didn't understand the change would cause an > interoperability problem. If a bit is set, we can hope that the bit > is ignored, but I think that too is wishful thinking based on prior > attempts to add bits to the same flag. Well, perhaps it is wishful thinking on my part, but I was hoping that most routers supported section 4.4.5 of RFC 3209, which starts: 4.4.5. Forward Compatibility New subobjects may be defined for the RRO. When processing an RRO, unrecognized subobjects SHOULD be ignored and passed on. [Rest of text omitted] My thought was that all routers would include the existing sub-object and use it to specify the egress interface (as described in section 4.4.3). In addition, routers that wanted to include their router id would include the new Node-ID subobject, which would be ignored by routers that did not understand it. Routers that want to do route pinning would create the ERO from the RRO by stripping out sub-objects they did not understand. > > If either approach causes interoperability problems with older nodes, > then a new type code would be preferable IMHO. If so, it should be > noted that all routers MUST be upgraded before the feature is enabled, > and that an implementation MUST provide the ability to enable or > disable this feature by configuration. > Perhaps one of the authors of the draft might say why they chose the flag bit approach? - Philip ------_=_NextPart_001_01C32B8A.A6394C40 Content-Type: text/html; charset="iso-8859-1" RE: Node-id: Concerned about using one of the last RRO flag bits for this

See my comments inline.

- Philip

PS. My apologies to those who see this message as something other than
    plain text. It seems that Microsoft Outlook, when configured to send
    Plain-Text messages, actually sends multi-part MIME messages with both
    plain-text and Rich Text. If anyone knows how to fix this, please e-mail
    me privately.


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: 2003-Jun-04 19:49
> To: Philip Matthews
> Cc: mpls@UU.NET
> Subject: Re: Node-id: Concerned about using one of the last RRO flag
> bits for this
>
>
>
> In message
> <8812A03F65CDD511AE98006008F5E8710677DCB6@hermes.hyperchip.com>, Phi
> lip Matthews writes:
> >
> > I would like to repeat my concerns with the proposal in
> >    draft-ietf-mpls-nodeid-subobject-01
> >
> > Though I strongly support the concept of a node-id sub-object,
> > as it will be very useful for Fast Re-route,
> > I remain concerned about the proposal to use one of the
> > last unallocated flag bits in the RRO to indicate this object.
> >
> > For those who have not read the draft, it proposes to use a flag
> > bit in the IPv4 or IPv6 address subject to indicate that the address
> > given in the subobject is not an interface address, but instead a router ID.
> > Nodes that wanted to include both an interface address and their
> > router id would include the IPv4 (or IPv6) subobject twice,
> > one with the flag set and one not.
> >
> > To me, a much more obvious method is to assign a new type code
> > to the node-id subobject, rather than using a flag bit.
> > Since there are
> > currently 252 unassigned subcodes, but only 3 unassigned flag bits
> > (or just 2 if this proposal goes through), it seems to me that
> > there needs to be a strong justification to use up one of the
> > three remaining bits.
> >
> > I also feel that using a new type code would improve
> > interoperability
> > with nodes that do not support this flag.
> >
> >
> > Am I missing something? Is there a good reason to use a flag bit?
> >
> > - Philip
>
>
> Currently in the ERO every other entry is a router-id but none are
> identified as such.  This is not a requirement but it is current
> practice.  Each hop sees its own router-id and then looks at the next
> entry.  The RRO usually reflects what is in the ERO.

Hmmm... My testing department tells me one major router vendor generates
EROs that look like
        (strict, ingress-address-on-rtr2)
      (strict, egress-address-on-rtr2)
      (strict, ingress-address-on-rtr3)
      (strict, egress-address-on-rtr3)
      (strict, ingress-address-on-rtr4)
      (strict, egress-address-on-rtr4)
      ...
while the other major vendor generates EROs that look like:
        (strict, ingress-address-on-rtr2)
      (strict, ingress-address-on-rtr3)
      (strict, ingress-address-on-rtr4)
      ...
and neither includes router ids in its ERO.
I haven't investigated this myself.


>
> If the new type code is added to the RRO only, it still affects route
> pinning (copy the RRO into the ERO replacing any loose hops).
>
> If the nodes were changed to a new type code it would virtually insure
> that an older router that didn't understand the change would cause an
> interoperability problem.  If a bit is set, we can hope that the bit
> is ignored, but I think that too is wishful thinking based on prior
> attempts to add bits to the same flag.

Well, perhaps it is wishful thinking on my part, but I was hoping that
most routers supported section 4.4.5 of RFC 3209, which starts:

    4.4.5. Forward Compatibility

       New subobjects may be defined for the RRO.  When processing an RRO,
       unrecognized subobjects SHOULD be ignored and passed on. 
       [Rest of text omitted]

My thought was that all routers would include the existing sub-object
and use it to specify the egress interface (as described in section 4.4.3).
In addition, routers that wanted to include their router id would include
the new Node-ID subobject, which would be ignored by routers that did not
understand it. Routers that want to do route pinning would create the ERO
from the RRO by stripping out sub-objects they did not understand.


>
> If either approach causes interoperability problems with older nodes,
> then a new type code would be preferable IMHO.  If so, it should be
> noted that all routers MUST be upgraded before the feature is enabled,
> and that an implementation MUST provide the ability to enable or
> disable this feature by configuration.
>

Perhaps one of the authors of the draft might say why they chose the
flag bit approach?

- Philip

------_=_NextPart_001_01C32B8A.A6394C40-- From owner-mpls@UU.NET Thu Jun 5 15:44:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13875 for ; Thu, 5 Jun 2003 15:44:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorus21513 for ; Thu, 5 Jun 2003 19:44:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorus21322; Thu, 5 Jun 2003 19:44:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQorup16644 for mpls-outgoing; Thu, 5 Jun 2003 18:57:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorup16637 for ; Thu, 5 Jun 2003 18:56:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorup22705 for ; Thu, 5 Jun 2003 18:54:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorup07260 for ; Thu, 5 Jun 2003 18:54:09 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQorup07249 for ; Thu, 5 Jun 2003 18:54:08 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h55Is551002746 for ; Thu, 5 Jun 2003 14:54:06 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id OAA01715 for ; Thu, 5 Jun 2003 14:54:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h55Is5g14913 for mpls@uu.net; Thu, 5 Jun 2003 14:54:05 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQorup16279 for ; Thu, 5 Jun 2003 18:52:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorup00023 for ; Thu, 5 Jun 2003 18:51:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorup02730 for ; Thu, 5 Jun 2003 18:51:31 GMT Received: from ams-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-iport-1.cisco.com [144.254.74.5]) id QQorup02715 for ; Thu, 5 Jun 2003 18:51:31 GMT Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jun 2003 20:50:36 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h55InVrH009868; Thu, 5 Jun 2003 20:49:31 +0200 (MET DST) Received: from jvasseur-w2k01.cisco.com (sjc-vpn1-298.cisco.com [10.21.97.42]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA19782; Thu, 5 Jun 2003 20:51:27 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030605144736.01fbaee8@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 14:51:26 -0400 To: Philip Matthews From: Jean Philippe Vasseur Subject: Re: Node-id: Concerned about using one of the last RRO flag bits for this Cc: mpls@UU.NET In-Reply-To: <8812A03F65CDD511AE98006008F5E8710677DCB6@hermes.hyperchip. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_789665979==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_789665979==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Philipp, At 09:48 AM 6/4/2003 -0400, Philip Matthews wrote: >I would like to repeat my concerns with the proposal in > draft-ietf-mpls-nodeid-subobject-01 > >Though I strongly support the concept of a node-id sub-object, >as it will be very useful for Fast Re-route, >I remain concerned about the proposal to use one of the >last unallocated flag bits in the RRO to indicate this object. > >For those who have not read the draft, it proposes to use a flag >bit in the IPv4 or IPv6 address subject to indicate that the address >given in the subobject is not an interface address, but instead a router ID. >Nodes that wanted to include both an interface address and their >router id would include the IPv4 (or IPv6) subobject twice, >one with the flag set and one not. > >To me, a much more obvious method is to assign a new type code >to the node-id subobject, rather than using a flag bit. Since there are >currently 252 unassigned subcodes, but only 3 unassigned flag bits >(or just 2 if this proposal goes through), it seems to me that >there needs to be a strong justification to use up one of the >three remaining bits. > >I also feel that using a new type code would improve interoperability >with nodes that do not support this flag. > >Am I missing something? Is there a good reason to use a flag bit? if you define a new type code, you would need to add the new subobject in addition to the existing IPv4 subobject in order to be compliant with the FRR draft. Defining a new flag allows to use the same required IPv4 but just set the flag and use the router-id address instead of the outgoing interface. thanks JP. >- Philip --=====================_789665979==_.ALT Content-Type: text/html; charset="us-ascii" Hi Philipp,

At 09:48 AM 6/4/2003 -0400, Philip Matthews wrote:

I would like to repeat my concerns with the proposal in
   draft-ietf-mpls-nodeid-subobject-01

Though I strongly support the concept of a node-id sub-object,
as it will be very useful for Fast Re-route,
I remain concerned about the proposal to use one of the
last unallocated flag bits in the RRO to indicate this object.

For those who have not read the draft, it proposes to use a flag
bit in the IPv4 or IPv6 address subject to indicate that the address
given in the subobject is not an interface address, but instead a router ID.
Nodes that wanted to include both an interface address and their
router id would include the IPv4 (or IPv6) subobject twice,
one with the flag set and one not.

To me, a much more obvious method is to assign a new type code
to the node-id subobject, rather than using a flag bit. Since there are
currently 252 unassigned subcodes, but only 3 unassigned flag bits
(or just 2 if this proposal goes through), it seems to me that
there needs to be a strong justification to use up one of the
three remaining bits.

I also feel that using a new type code would improve interoperability
with nodes that do not support this flag.

Am I missing something? Is there a good reason to use a flag bit?

if you define a new type code, you would need to add the new subobject in addition to the existing IPv4 subobject in order to be compliant with the FRR draft. Defining a new flag allows to use the same required IPv4 but just set the flag and use the router-id address instead of the outgoing interface.

thanks

JP.

- Philip
--=====================_789665979==_.ALT-- From owner-mpls@UU.NET Thu Jun 5 20:33:17 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23603 for ; Thu, 5 Jun 2003 20:33:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorvm22725 for ; Fri, 6 Jun 2003 00:33:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorvm22252; Fri, 6 Jun 2003 00:33:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQorur08237 for mpls-outgoing; Thu, 5 Jun 2003 19:20:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorur08215 for ; Thu, 5 Jun 2003 19:20:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorur04890 for ; Thu, 5 Jun 2003 19:15:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorur02415 for ; Thu, 5 Jun 2003 19:15:08 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQorur02396 for ; Thu, 5 Jun 2003 19:15:08 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h55JF66m001460 for ; Thu, 5 Jun 2003 15:15:06 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id PAA03972 for ; Thu, 5 Jun 2003 15:15:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h55JF5H16796 for mpls@uu.net; Thu, 5 Jun 2003 15:15:05 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoruq07215 for ; Thu, 5 Jun 2003 19:13:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoruq18885 for ; Thu, 5 Jun 2003 19:12:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoruq00316 for ; Thu, 5 Jun 2003 19:12:01 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoruq00252 for ; Thu, 5 Jun 2003 19:11:59 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA49587; Thu, 5 Jun 2003 15:10:17 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200306051910.PAA49587@workhorse.fictitious.org> To: Philip Matthews cc: "'curtis@fictitious.org'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Node-id: Concerned about using one of the last RRO flag bits for this In-reply-to: Your message of "Thu, 05 Jun 2003 13:48:19 EDT." <8812A03F65CDD511AE98006008F5E87104DC131D@hermes.hyperchip.com> Date: Thu, 05 Jun 2003 15:10:17 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <8812A03F65CDD511AE98006008F5E87104DC131D@hermes.hyperchip.com>, Phi lip Matthews writes: > 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_01C32B8A.A6394C40 > Content-Type: text/plain; > charset="iso-8859-1" > > See my comments inline. > > - Philip > > PS. My apologies to those who see this message as something other than > plain text. It seems that Microsoft Outlook, when configured to send > Plain-Text messages, actually sends multi-part MIME messages with both > plain-text and Rich Text. If anyone knows how to fix this, please e-mail > me privately. > > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: 2003-Jun-04 19:49 > > To: Philip Matthews > > Cc: mpls@UU.NET > > Subject: Re: Node-id: Concerned about using one of the last RRO flag > > bits for this > > > > > > > > In message > > <8812A03F65CDD511AE98006008F5E8710677DCB6@hermes.hyperchip.com>, Phi > > lip Matthews writes: > > > > > > I would like to repeat my concerns with the proposal in > > > draft-ietf-mpls-nodeid-subobject-01 > > > > > > Though I strongly support the concept of a node-id sub-object, > > > as it will be very useful for Fast Re-route, > > > I remain concerned about the proposal to use one of the > > > last unallocated flag bits in the RRO to indicate this object. > > > > > > For those who have not read the draft, it proposes to use a flag > > > bit in the IPv4 or IPv6 address subject to indicate that the address > > > given in the subobject is not an interface address, but instead a router > ID. > > > Nodes that wanted to include both an interface address and their > > > router id would include the IPv4 (or IPv6) subobject twice, > > > one with the flag set and one not. > > > > > > To me, a much more obvious method is to assign a new type code > > > to the node-id subobject, rather than using a flag bit. > > > Since there are > > > currently 252 unassigned subcodes, but only 3 unassigned flag bits > > > (or just 2 if this proposal goes through), it seems to me that > > > there needs to be a strong justification to use up one of the > > three remaining bits. > > > > > > I also feel that using a new type code would improve > > > interoperability > > > with nodes that do not support this flag. > > > > > > > > > Am I missing something? Is there a good reason to use a flag bit? > > > > > > - Philip > > > > > > Currently in the ERO every other entry is a router-id but none are > > identified as such. This is not a requirement but it is current > > practice. Each hop sees its own router-id and then looks at the next > > entry. The RRO usually reflects what is in the ERO. > > Hmmm... My testing department tells me one major router vendor generates > EROs that look like > (strict, ingress-address-on-rtr2) > (strict, egress-address-on-rtr2) > (strict, ingress-address-on-rtr3) > (strict, egress-address-on-rtr3) > (strict, ingress-address-on-rtr4) > (strict, egress-address-on-rtr4) > ... > while the other major vendor generates EROs that look like: > (strict, ingress-address-on-rtr2) > (strict, ingress-address-on-rtr3) > (strict, ingress-address-on-rtr4) > ... > and neither includes router ids in its ERO. > I haven't investigated this myself. Third is: (strict, ingress-address-on-rtr2) (strict, router-id-of-rtr2) (strict, ingress-address-on-rtr3) (strict, router-id-of-rtr3) (strict, ingress-address-on-rtr4) (strict, router-id-of-rtr4) and it interoperates with the other two. > > If the new type code is added to the RRO only, it still affects route > > pinning (copy the RRO into the ERO replacing any loose hops). > > > > If the nodes were changed to a new type code it would virtually insure > > that an older router that didn't understand the change would cause an > > interoperability problem. If a bit is set, we can hope that the bit > > is ignored, but I think that too is wishful thinking based on prior > > attempts to add bits to the same flag. > > Well, perhaps it is wishful thinking on my part, but I was hoping that > most routers supported section 4.4.5 of RFC 3209, which starts: > > 4.4.5. Forward Compatibility > > New subobjects may be defined for the RRO. When processing an RRO, > unrecognized subobjects SHOULD be ignored and passed on. > [Rest of text omitted] > > My thought was that all routers would include the existing sub-object > and use it to specify the egress interface (as described in section 4.4.3). > In addition, routers that wanted to include their router id would include > the new Node-ID subobject, which would be ignored by routers that did not > understand it. Routers that want to do route pinning would create the ERO > from the RRO by stripping out sub-objects they did not understand. The addition of a subobject to RRO object is not as much of an issue as the RRO being used to create an ERO in route pinning. It does say ignored and passed on. If passed into the ERO, then any router that didn't understand the new subobject would not be able to proccess the first entry in the ERO that it needed to look at. > > If either approach causes interoperability problems with older nodes, > > then a new type code would be preferable IMHO. If so, it should be > > noted that all routers MUST be upgraded before the feature is enabled, > > and that an implementation MUST provide the ability to enable or > > disable this feature by configuration. > > Perhaps one of the authors of the draft might say why they chose the > flag bit approach? > > - Philip Probably because two of the three implementations ignores flags that it doesn't understand as discovered with soft preempt testing and it was suggested that ignoring flag bits that are not understood should be mandated in the next spin of rfc3209. We should mandate ignoring flag bits that are not understood but that is a separate issue. The new type code is still attractive because it doesn't take up another flag bit. If there were a way for the ingress to indicate it understands this, then stripping it when pinning would not be an issue (if the ingress doesn't understand, don't use the new type code). It might be worth considering a capabilities advertisement (new TE TLV) for each router to be flooded into the IGP more for other features in which the ingress must know capabilities along the path. For this it would be worth having a capabilities object in the PATH message for features where ingress capability must be known. For other extensions it may be useful to have capabilities subobjects in both path or resv for features where there is a need to know if each hop has a given capability. Curtis From owner-mpls@UU.NET Thu Jun 5 20:38:43 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23753 for ; Thu, 5 Jun 2003 20:38:43 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorvm03513 for ; Fri, 6 Jun 2003 00:38:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorvm03329; Fri, 6 Jun 2003 00:38:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQorur08604 for mpls-outgoing; Thu, 5 Jun 2003 19:26:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorur08513 for ; Thu, 5 Jun 2003 19:25:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorur26171 for ; Thu, 5 Jun 2003 19:24:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorur19756 for ; Thu, 5 Jun 2003 19:24:54 GMT Received: from smtp101.mail.sc5.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp101.mail.sc5.yahoo.com [216.136.174.139]) id QQorur19742 for ; Thu, 5 Jun 2003 19:24:53 GMT Received: from 12-234-100-254.client.attbi.com (HELO METANOIA) (vsharma87@12.234.100.254 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Jun 2003 19:24:53 -0000 Reply-To: From: "Vishal Sharma" To: , , Subject: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Call for Papers Date: Thu, 5 Jun 2003 12:24:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The IEEE Communications Magazine has just approved the publication of a Feature Topic issue on "OAM-in MPLS-based Networks." The CFP is attached below. We invite those working in this area to consider sending in their contributions. If you intend to submit a paper for this special issue, please drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your participation! Thanks, -Vishal ************************************* Vishal Sharma Metanoia, Inc. http://www.metanoia-inc.com ************************************* ==================================================================== CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "OAM in MPLS-Based Networks" ********************************************** As carriers and service providers converge multiple services and associated networks on to an MPLS-based infrastructure, OAM functionality becomes pivotal for enabling them to provide service level agreement (SLA) guarantees, service assurance, quality of service (QoS) assurance and overall interworking service management. The advent of new applications of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs) also means the emergence of added OAM requirements from operators deploying those networks. As a result, providers today require more efficient means of monitoring network health, performance, and robustness, and of quickly identifying and resolving performance problems. This is leading to the emergence of improved or novel tools and techniques, whose goal is to improve security and billing/accounting, aid in verifying QoS commitments, and reduce operating costs. Standards organizations such as the IETF and the ITU have in the recent past done significant work in this area, and this subject is also being investigated by the IEEE and the Metro Ethernet Forum. This feature topic issue of the IEEE Communications Magazine has a dual focus: to highlight operator requirements and deployment experiences with OAM in MPLS-based networks, and to present a survey of the current engineering and research developments in this area. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but not limited to) the following: * Operational consequences of inadequate OAM capabilities * Service provider requirements for efficient OAM - current operational needs and future demands * Deployment experiences with OAM over MPLS-based networks * Overview or comparative analysis of different approaches/philosophies for OAM * Standards activities o Emerging architectures o New mechanisms for OAM in development (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit connection verification (VCCV)) * Platform support for OAM * OAM impact on edge services (such as metro Ethernet) using MPLS transport * Interoperability issues, interworking with other technologies (e.g. ATM) * Review of current research in the area - E.g. setting parameters for connectivity verification and their impact on LSP recovery, trade-offs between bandwidth usage by OAM traffic and efficiency of failure/anomaly detection, and results from testbed deployments or simulations On-line CFP with submission instructions can be found at: http://www.comsoc.org/pubs/commag/cfpcommag1004.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided the consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at: http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please submit no later than November 30, 2003. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Schedule: Manuscript Due: November 30, 2003 Acceptance Notification: February 28, 2004 Final Manuscript Due: April 15, 2004 Publication Date: October 2004 Guest Editors: Monique J. Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Tom Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824, USA. Email: tnadeau@cisco.com Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA. Email: v.sharma@ieee.org About the IEEE Communications Magazine: The IEEE Comm. Mag. is the official technical publication of conferences such as Supercomm, and has the unique distinction of being the most widely read IEEE journal, with its over 50,000 paid subscribers representing key communications engineers and technical managers in our industry. More information on the IEEE Comm. Mag., may be found here: www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt From owner-mpls@UU.NET Fri Jun 6 01:13:39 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28966 for ; Fri, 6 Jun 2003 01:13:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorwe27663 for ; Fri, 6 Jun 2003 05:13:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorwe27517; Fri, 6 Jun 2003 05:13:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQorvo19435 for mpls-outgoing; Fri, 6 Jun 2003 01:06:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorvo19419 for ; Fri, 6 Jun 2003 01:06:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQorvo02345 for ; Fri, 6 Jun 2003 01:06:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorvo16097 for ; Fri, 6 Jun 2003 01:06:06 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQorvo16063 for ; Fri, 6 Jun 2003 01:06:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h56162pi015931 for ; Thu, 5 Jun 2003 21:06:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id VAA29337 for ; Thu, 5 Jun 2003 21:06:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h56162l05713 for mpls@uu.net; Thu, 5 Jun 2003 21:06:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorvo18877 for ; Fri, 6 Jun 2003 01:05:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorvo00830 for ; Fri, 6 Jun 2003 01:05:23 GMT Received: from ams-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-iport-1.cisco.com [144.254.74.5]) id QQorva23468 for ; Thu, 5 Jun 2003 21:41:11 GMT Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jun 2003 23:40:07 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h55Ld2id004106; Thu, 5 Jun 2003 23:39:02 +0200 (MET DST) Received: from jvasseur-w2k01.cisco.com (sjc-vpn1-298.cisco.com [10.21.97.42]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA27191; Thu, 5 Jun 2003 23:40:58 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030605172946.0618a4a0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 17:40:57 -0400 To: Philip Matthews From: Jean Philippe Vasseur Subject: RE: Node-id: Concerned about using one of the last RRO flag bits for this Cc: mpls@UU.NET, "'Curtis Villamizar'" In-Reply-To: <8812A03F65CDD511AE98006008F5E87104DC1325@hermes.hyperchip. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_799836764==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_799836764==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Philip, At 05:22 PM 6/5/2003 -0400, Philip Matthews wrote: >Jean Philippe Vasseur wrote: > > if you define a new type code, you would need to add the new subobject > in addition to the existing > > IPv4 subobject in order to be compliant with the FRR draft. Defining a > new flag allows to use the > > same required IPv4 but just set the flag and use the router-id address > instead of the outgoing > > interface. > >I think I understand now: >a) You want each node to independently decide whether to push an interface >address, > a router id, or both. That's exactly right. Actually, pushing an router id is the only thing that FRR requires. In addition, an additional IPv4 sub-object can be added to record the interface. >b) I would like each node to always push an interface address, and >optionally push a router id. The problem is that you may need to add a router id for each fast reroutable LSP since it can potentially be an inter-area or inter-AS TE LSP and trying to determine whether a TE LSP is inter-area/AS may not be so obvious. Hence, this simple solution of pushing the router-id and setting up the flag. Routers that do not understand the flag will just ignore it and the RRO will be shorter with this option. >With option (a), there may be some advantage in using a flag, since >routers out >there today that do not understand the flag will see just an IPv4/v6 >Address subobject >and will hopefully do more-or-less the right thing. However, as Curtis >points out, >there are routers out there that are known to have problems with new flags. > >With option (b), there is no advantage to using a flag, assuming nodes can >ignore >unknown sub-objects. but the RRO length will be unnecessarily increased. >My concern with option (a) is that it removes my ability to parse the RRO and >tell which sub-objects belong to the same node. For example, if the RRO >contains: > > (address-1, flag=0), (address-2, flag=1), (address-3, flag=0) > >then I don't know whether this represents 2 nodes or 3 nodes. This makes it >impossible for a router to display the RRO to the operator in a nicely >formatted >manner (that groups together the information for a single node). Well no I do not agree here ... this is even worse without the flag since currently an implementation can perfectly add more than one IPv4 subobject in every RRO object. So you can have the following: (address-1, flag=0), (address-2, flag=0), (address-3, flag=0). Then you can still use the TE database to determine that they all belong to the same node. >Option (a) also gives the operator less information, because he/she will >not always >see the egress interface of the LSP. The outgoing address can also be added >However, option (a) does have the advantage that RROs can be shorter. > >So there seem to be three questions for the WG to decide: >1) Do we want to do for option (a) or option (b)? JP. >2) Do we want to use a flag or a new sub-object? >3) Do we need to add capability advertisements to do any of this > (as Curtis is suggesting)? > >I personally have a medium preference for option (b), and a medium preference >for a new sub-object. I also hope that people will simply fix their routers >so we don't need to introduce capability advertisements. > >- Philip --=====================_799836764==_.ALT Content-Type: text/html; charset="us-ascii" Hi Philip,

At 05:22 PM 6/5/2003 -0400, Philip Matthews wrote:

Jean Philippe Vasseur wrote:
> if you define a new type code, you would need to add the new subobject in addition to the existing
> IPv4 subobject in order to be compliant with the FRR draft. Defining a new flag allows to use the
> same required IPv4 but just set the flag and use the router-id address instead of the outgoing
> interface.

I think I understand now:
a) You want each node to independently decide whether to push an interface address,
   a router id, or both.

That's exactly right. Actually, pushing an router id is the only thing that FRR requires. In addition, an additional IPv4 sub-object can be added to record the interface.

b) I would like each node to always push an interface address, and optionally push a router id.

The problem is that you may need to add a router id for each fast reroutable LSP since it can potentially be an inter-area or inter-AS TE LSP and trying to determine whether a TE LSP is inter-area/AS may not be so obvious. Hence, this simple solution of pushing the router-id and setting up the flag. Routers that do not understand the flag will just ignore it and the RRO will be shorter with this option.

With option (a), there may be some advantage in using a flag, since routers out
there today that do not understand the flag will see just an IPv4/v6 Address subobject
and will hopefully do more-or-less the right thing. However, as Curtis points out,
there are routers out there that are known to have problems with new flags.

With option (b), there is no advantage to using a flag, assuming nodes can ignore
unknown sub-objects.

but the RRO length will be unnecessarily increased.

My concern with option (a) is that it removes my ability to parse the RRO and
tell which sub-objects belong to the same node. For example, if the RRO contains:

     (address-1, flag=0), (address-2, flag=1), (address-3, flag=0)

then I don't know whether this represents 2 nodes or 3 nodes. This makes it
impossible for a router to display the RRO to the operator in a nicely formatted
manner (that groups together the information for a single node).

Well no I do not agree here ... this is even worse without the flag since currently an implementation can perfectly add more than one IPv4 subobject in every RRO object. So you can have the following: (address-1, flag=0), (address-2, flag=0), (address-3, flag=0). Then you can still use the TE database to determine that they all belong to the same node.

Option (a) also gives the operator less information, because he/she will not always
see the egress interface of the LSP.

The outgoing address can also be added

However, option (a) does have the advantage that RROs can be shorter.

So there seem to be three questions for the WG to decide:
1) Do we want to do for option (a) or option (b)?

JP.

2) Do we want to use a flag or a new sub-object?
3) Do we need to add capability advertisements to do any of this
   (as Curtis is suggesting)?

I personally have a medium preference for option (b), and a medium preference
for a new sub-object. I also hope that people will simply fix their routers
so we don't need to introduce capability advertisements.

- Philip
--=====================_799836764==_.ALT-- From owner-mpls@UU.NET Fri Jun 6 04:05:20 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13551 for ; Fri, 6 Jun 2003 04:05:19 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorwq28748 for ; Fri, 6 Jun 2003 08:05:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorwq28582; Fri, 6 Jun 2003 08:05:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQoruz24937 for mpls-outgoing; Thu, 5 Jun 2003 21:24:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoruz24918 for ; Thu, 5 Jun 2003 21:24:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoruz14854 for ; Thu, 5 Jun 2003 21:23:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoruz22123 for ; Thu, 5 Jun 2003 21:23:10 GMT Received: from mail2.hyperchip.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.hyperchip.com [216.94.112.4]) id QQoruz22119 for ; Thu, 5 Jun 2003 21:23:10 GMT Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 19O2CL-0004zY-00; Thu, 05 Jun 2003 17:23:01 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 17:22:10 -0400 Message-ID: <8812A03F65CDD511AE98006008F5E87104DC1325@hermes.hyperchip.com> From: Philip Matthews To: "'Jean Philippe Vasseur'" Cc: mpls@UU.NET, "'Curtis Villamizar'" Subject: RE: Node-id: Concerned about using one of the last RRO flag bits for this Date: Thu, 5 Jun 2003 17:22:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32BA8.8590B820" 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_01C32BA8.8590B820 Content-Type: text/plain; charset="iso-8859-1" Jean Philippe Vasseur wrote: > if you define a new type code, you would need to add the new subobject in addition to the existing > IPv4 subobject in order to be compliant with the FRR draft. Defining a new flag allows to use the > same required IPv4 but just set the flag and use the router-id address instead of the outgoing > interface. I think I understand now: a) You want each node to independently decide whether to push an interface address, a router id, or both. b) I would like each node to always push an interface address, and optionally push a router id. With option (a), there may be some advantage in using a flag, since routers out there today that do not understand the flag will see just an IPv4/v6 Address subobject and will hopefully do more-or-less the right thing. However, as Curtis points out, there are routers out there that are known to have problems with new flags. With option (b), there is no advantage to using a flag, assuming nodes can ignore unknown sub-objects. My concern with option (a) is that it removes my ability to parse the RRO and tell which sub-objects belong to the same node. For example, if the RRO contains: (address-1, flag=0), (address-2, flag=1), (address-3, flag=0) then I don't know whether this represents 2 nodes or 3 nodes. This makes it impossible for a router to display the RRO to the operator in a nicely formatted manner (that groups together the information for a single node). Option (a) also gives the operator less information, because he/she will not always see the egress interface of the LSP. However, option (a) does have the advantage that RROs can be shorter. So there seem to be three questions for the WG to decide: 1) Do we want to do for option (a) or option (b)? 2) Do we want to use a flag or a new sub-object? 3) Do we need to add capability advertisements to do any of this (as Curtis is suggesting)? I personally have a medium preference for option (b), and a medium preference for a new sub-object. I also hope that people will simply fix their routers so we don't need to introduce capability advertisements. - Philip ------_=_NextPart_001_01C32BA8.8590B820 Content-Type: text/html; charset="iso-8859-1" RE: Node-id: Concerned about using one of the last RRO flag bits for this

Jean Philippe Vasseur wrote:
> if you define a new type code, you would need to add the new subobject in addition to the existing
> IPv4 subobject in order to be compliant with the FRR draft. Defining a new flag allows to use the
> same required IPv4 but just set the flag and use the router-id address instead of the outgoing
> interface.


I think I understand now:
a) You want each node to independently decide whether to push an interface address,
   a router id, or both.
b) I would like each node to always push an interface address, and optionally push a router id.

With option (a), there may be some advantage in using a flag, since routers out
there today that do not understand the flag will see just an IPv4/v6 Address subobject
and will hopefully do more-or-less the right thing. However, as Curtis points out,
there are routers out there that are known to have problems with new flags.

With option (b), there is no advantage to using a flag, assuming nodes can ignore
unknown sub-objects.


My concern with option (a) is that it removes my ability to parse the RRO and
tell which sub-objects belong to the same node. For example, if the RRO contains:

     (address-1, flag=0), (address-2, flag=1), (address-3, flag=0)

then I don't know whether this represents 2 nodes or 3 nodes. This makes it
impossible for a router to display the RRO to the operator in a nicely formatted
manner (that groups together the information for a single node).

Option (a) also gives the operator less information, because he/she will not always
see the egress interface of the LSP.

However, option (a) does have the advantage that RROs can be shorter.


So there seem to be three questions for the WG to decide:
1) Do we want to do for option (a) or option (b)?
2) Do we want to use a flag or a new sub-object?
3) Do we need to add capability advertisements to do any of this
   (as Curtis is suggesting)?

I personally have a medium preference for option (b), and a medium preference
for a new sub-object. I also hope that people will simply fix their routers
so we don't need to introduce capability advertisements.

- Philip

------_=_NextPart_001_01C32BA8.8590B820-- From owner-mpls@UU.NET Fri Jun 6 05:45:17 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15635 for ; Fri, 6 Jun 2003 05:45:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorwx27170 for ; Fri, 6 Jun 2003 09:45:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorwx27038; Fri, 6 Jun 2003 09:45:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQorwm09001 for mpls-outgoing; Fri, 6 Jun 2003 07:10:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQorwm08965 for ; Fri, 6 Jun 2003 07:10:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorwm14809 for ; Fri, 6 Jun 2003 07:09:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorwm10841 for ; Fri, 6 Jun 2003 07:09:26 GMT Received: from mailf.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailf.telia.com [194.22.194.25]) id QQorwm10830 for ; Fri, 6 Jun 2003 07:09:25 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailf.telia.com (8.12.9/8.12.9) with ESMTP id h5679G3n015298; Fri, 6 Jun 2003 09:09:16 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h5679Gc07898; Fri, 6 Jun 2003 09:09:16 +0200 (CEST) Message-ID: <3EE03D0E.3000809@pi.se> Date: Fri, 06 Jun 2003 09:04:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG CC: "Thomas D. Nadeau" , Bert Wijnen Subject: prequeal to WG lat call om the LSR mib module Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLSers, included are two major items that the authors, wg-chairs and ADs want specific comments on when the LSR mib module is published and last called. The MIB will be sent to the Internet Drafts today (Friaday) but will take a few days before it is announced. The last call will be started by a specific mail, as soon as we see it publiched, and will be limitied to changes since the last version. The discussion on the items below could take place as a part of the wg last call. The items are: 1) The indexing of the in/out/XC tables has changed from Unsigned32s to Octet Strings of up to 24 bytes in length. The reason this was done was to facilitate LSRs that support multiple applications of MPLS in a distribute fashion. Use of a flat 32 bit indexing space on these platforms ends up with VERY slot N^2+ GetNext searches due to the fact that labels are distributed among different applications. The GetNext routine must then query each application's "bag" of labels to determine the next index. This change is compatible with implementations that wish to remain with the 4 byte indexing; they just use a 4 byte octet string, while others are free to use the more specific indexing. 2) The addition of a RowPointer to the in/out/label stack tables to support "long" or GMPLS-style labels. The RowPointer is normally set to zeroDotZero except when the MIB needs to refer to an external table that defines labels that exceed the 32bits of space alloted in the tables today. This in essence, future-proofs the MIB and makes it compatible immediately with the GMPLS MIBs defined in CCAMP. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Fri Jun 6 21:36:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20634 for ; Fri, 6 Jun 2003 21:36:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorzi28306 for ; Sat, 7 Jun 2003 01:36:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorzi27852; Sat, 7 Jun 2003 01:36:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQorxr25629 for mpls-outgoing; Fri, 6 Jun 2003 14:52:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQorxr25614 for ; Fri, 6 Jun 2003 14:52:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorxr23096 for ; Fri, 6 Jun 2003 14:51:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorxr25565 for ; Fri, 6 Jun 2003 14:51:02 GMT Received: from jera.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQorxr25550 for ; Fri, 6 Jun 2003 14:51:02 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 900528229; Fri, 6 Jun 2003 10:51:01 -0400 (EDT) Message-ID: <0b8301c32c3b$0c3d1c50$681810ac@movaz.com> From: "Adrian Farrel" To: "Loa Andersson" , "MPLS WG" Cc: "Thomas D. Nadeau" , "Bert Wijnen" References: <3EE03D0E.3000809@pi.se> Subject: Re: prequeal to WG lat call om the LSR mib module Date: Fri, 6 Jun 2003 10:51:01 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Loa, Thanks for the opportunity to comment publicly about this issue. I believe there is a degree of cyclic redundancy about this debate. In my view, part of the problem is caused by an attempt to place a tight association between labels and segment indexing which is not a requirement for successful implementation. For the sake of history... At the MIB meeting in Atlanta there was reluctant agreement to accept an octet string. This octet string, however, was agreed as a combination of the two fields (and three functions) that are now being proposed. That is, it provided an identifier of the label, acted as an index into segment tables, and provided an index into an external table containing labels. In effect it circumvented issues of making a rowPointer an index (yuck) and provided a place to store labels 'in line'. This was a compromise designed to help implementers who believed that they needed a more complex index than a single integer equivalent to the label because the labels might be distributed across multiple label management components *and* who believed that adding a secondary integer index to point to the appropriate label management component was not sufficient - they needed an 'arbitrary' secondary index which could only be held in an octet string. The value of that solution was that an non-32 bit label could be held 'in line' in the octet string without needing to implement a label table provided that it was clear from the context how the label should be interpreted. Looking at the inSegmentTable The old solution (version 9) had - an interface index that was an index into the inSegmentTable - a 23-bit label value that was an index into the inSegmentTable The requirements are - to be future-proofed ready to upgrade to GMPLS - to support distributed solutions For a while the proposal was - an interface index that was an index into the inSegmentTable - a 32-bit value that could be interpreted as - a label and an index into the inSegmentTable OR - an index into a labelTable and an index into the inSegmentTable This went by the board because - the labelTable may need to be distributed across components making a single 32-bit index hard to implement The Atlanta solution was - an interface index that was an index into the inSegmentTable - an octet string that could be interpreted as - a label and an index into the inSegmentTable OR - an index into a labelTable and an index into the inSegmentTable This was discarded (as far as I can tell) at least because - arbitrary indexing of the inSegmentTable was preferred (matches the outSegmentTable) - finding a 23-bit label in an octet string is not nice This new solution (it is hard to be specific without seeing the relevant bits of the MIB, but I was allowed to see some early versions) appears to include - an arbitrary octet string index for the segment table - an object to contain the label if it will fit into a 23(sic)-bit value - a pointer into an external table to hold labels otherwise - an object to contain the interface index I do not understand why an octet string index is needed. If you need your insegment index to identify the location of the component that maintains the segment, and you need that location to dictate the index, why do you not simply use two integers? Integer searches are cheaper to implement - octet string searches are a mess. (Yes, I know you can encode two integers into an octet string, but that is hardly the point.) Why not have - an arbitrary primary integer index for the segment table this could be used as the component id or set to zero this could be used to contain the interface index if you want - an arbitrary secondary integer index for the segment table this could be used as the label value if that is how your mind works - a 32-bit object to contain the label if it will fit thus MPLS 23-bit labels and GMPLS 32-bit labels will fit - a pointer into an external table to hold labels otherwise - an object to contain the interface index Adrian ----- Original Message ----- From: "Loa Andersson" To: "MPLS WG" Cc: "Thomas D. Nadeau" ; "Bert Wijnen" Sent: Friday, June 06, 2003 3:04 AM Subject: prequeal to WG lat call om the LSR mib module > > > MPLSers, > > included are two major items that the authors, wg-chairs and ADs > want specific comments on when the LSR mib module is published and > last called. The MIB will be sent to the Internet Drafts today (Friaday) > but will take a few days before it is announced. The last call will be > started by a specific mail, as soon as we see it publiched, and will be > limitied to changes since the last version. The discussion on the items > below could take place as a part of the wg last call. > > > The items are: > > 1) The indexing of the in/out/XC > tables has changed from Unsigned32s > to Octet Strings of up to 24 bytes > in length. > > The reason this was done was to facilitate > LSRs that support multiple applications of > MPLS in a distribute fashion. Use of a > flat 32 bit indexing space on these platforms > ends up with VERY slot N^2+ GetNext searches > due to the fact that labels are distributed > among different applications. The GetNext > routine must then query each application's > "bag" of labels to determine the next index. > > This change is compatible with implementations > that wish to remain with the 4 byte indexing; > they just use a 4 byte octet string, while others > are free to use the more specific indexing. > > 2) The addition of a RowPointer to the in/out/label > stack tables to support "long" or GMPLS-style > labels. The RowPointer is normally set to zeroDotZero > except when the MIB needs to refer to an external > table that defines labels that exceed the 32bits > of space alloted in the tables today. This > in essence, future-proofs the MIB and makes > it compatible immediately with the GMPLS MIBs > defined in CCAMP. > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > From owner-mpls@UU.NET Fri Jun 6 21:39:58 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20758 for ; Fri, 6 Jun 2003 21:39:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorzi05909 for ; Sat, 7 Jun 2003 01:39:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorzi05452; Sat, 7 Jun 2003 01:39:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQorxs15518 for mpls-outgoing; Fri, 6 Jun 2003 15:14:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQorxs15475 for ; Fri, 6 Jun 2003 15:14:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQorxs10435 for ; Fri, 6 Jun 2003 15:14:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorxs24843 for ; Fri, 6 Jun 2003 15:14:13 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQorxs24838 for ; Fri, 6 Jun 2003 15:14:13 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h56FE9g14990 for ; Fri, 6 Jun 2003 10:14:10 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10PZSJ>; Fri, 6 Jun 2003 17:14:08 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC297C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: MPLS WG Subject: RE: prequeal to WG lat call om the LSR mib module Date: Fri, 6 Jun 2003 17:13:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk All... As soon as you get to see the MIB module, you can all check for yourself. Here is why I have a serious concern with using 24-octet index objects. Specifically for the mplsXCTable, where 3 of such 24-octet objects are used as index. My comments below are based on a pre-relase version of the doc I got to see/check, so if things have changed since then, it may not be 100% accurate. Take the mplsXCTable. It has 3 of these objects as index onjects. It has 7 columns of which 5 are read-create. The read-create objects are all pretty small in size. Like 3 integer based that would contain some 9 octets on the wire together, then an LSPID (4 or 8 octets on the wire), and another index type, possibly 26 octets on the wire. So the actual DATA values on the wire to create (or read) such a row consists of max 43 octets. The OID for the mplsXCEntry is: 1.3.6.1.2.1.10.166.2.1.9.1 So if each of the indices is 24 octets, then it adds 3*25 or 75 octets to each OID. So the OID for each column is 87 octets. So to transport the 5 objects (containing max 43 octets of real data) you potentially have to send 435 + 43 or 478 octets. Add to that the overhead for SNMP header and PDU header data, and it does not even fit in a 484 SNMP packet anymore and so a createAndGo may not be working in some implementations anymore. When you had 3 Unsigned32 as index. the OID for each column would have been max 29 octets or so. So the total would have been 145 + 23 is some 168 or so octets (the data for the mplsXCLabelStackIndex would also be reduced from 26 to 6). Thanks, Bert From owner-mpls@UU.NET Fri Jun 6 21:58:48 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21208 for ; Fri, 6 Jun 2003 21:58:48 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorzj16011 for ; Sat, 7 Jun 2003 01:58:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorzj15683; Sat, 7 Jun 2003 01:58:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQorys06448 for mpls-outgoing; Fri, 6 Jun 2003 21:36:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQorys06255 for ; Fri, 6 Jun 2003 21:35:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQorys18875 for ; Fri, 6 Jun 2003 21:35:48 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorys12451 for ; Fri, 6 Jun 2003 21:35:48 GMT Received: from auemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQorys12435 for ; Fri, 6 Jun 2003 21:35:47 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h56LZek05188 for ; Fri, 6 Jun 2003 16:35:41 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10P8BB>; Fri, 6 Jun 2003 23:35:39 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC29AD@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: MPLS WG Subject: RE: prequeal to WG lat call om the LSR mib module Date: Fri, 6 Jun 2003 23:35:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > MPLSers, > > > > included are two major items that the authors, wg-chairs and ADs > > want specific comments on when the LSR mib module is published and > > last called. The MIB will be sent to the Internet Drafts today (Friaday) > > but will take a few days before it is announced. The last call will be > > started by a specific mail, as soon as we see it publiched, and will be > > limitied to changes since the last version. The discussion on the items > > below could take place as a part of the wg last call. > > > > > > The items are: > > > > 1) The indexing of the in/out/XC > > tables has changed from Unsigned32s > > to Octet Strings of up to 24 bytes > > in length. > > > > The reason this was done was to facilitate > > LSRs that support multiple applications of > > MPLS in a distribute fashion. Use of a > > flat 32 bit indexing space on these platforms > > ends up with VERY slot N^2+ GetNext searches > > due to the fact that labels are distributed > > among different applications. The GetNext > > routine must then query each application's > > "bag" of labels to determine the next index. > > > > This change is compatible with implementations > > that wish to remain with the 4 byte indexing; > > they just use a 4 byte octet string, while others > > are free to use the more specific indexing. > > So... my understanding is that the mplsInSegmentTable and mplsOutSegmentTable are both read-create tables. I do not see how the index object (the 24 octets) is structured, and so I do not understand how an NMS application that wants to create a specific entry in this table is going to understand the structure. It now looks as if the NMS app needs to pickup mplsInSegmentIndexNext or mplsOutSegmentIndexNext and use that as an index. But will that always work, no matter what kind of new entry the NMS app wants to create? > > 2) The addition of a RowPointer to the in/out/label > > stack tables to support "long" or GMPLS-style > > labels. The RowPointer is normally set to zeroDotZero > > except when the MIB needs to refer to an external > > table that defines labels that exceed the 32bits > > of space alloted in the tables today. This > > in essence, future-proofs the MIB and makes > > it compatible immediately with the GMPLS MIBs > > defined in CCAMP. > > > I do not exactly understand that complexity either. Why can it not be a longer octet string that represents the label. Why does it have to be an integer for a <32bit label and if that value is zero then one needs to follow a ptr to some other place where it is basically an octet string? The WG needs to decide... but I find it more complex than needed. Maybe it is just me. Bert From owner-mpls@UU.NET Fri Jun 6 22:33:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21980 for ; Fri, 6 Jun 2003 22:33:35 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQorzm09390 for ; Sat, 7 Jun 2003 02:33:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQorzm09229; Sat, 7 Jun 2003 02:33:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQoryw29024 for mpls-outgoing; Fri, 6 Jun 2003 22:35:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoryw29003 for ; Fri, 6 Jun 2003 22:34:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoryw07005 for ; Fri, 6 Jun 2003 22:34:25 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoryw08802 for ; Fri, 6 Jun 2003 22:34:25 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQoryw08794 for ; Fri, 6 Jun 2003 22:34:24 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 84D7A155D; Fri, 6 Jun 2003 18:34:24 -0400 (EDT) Message-ID: <0c3801c32c7b$c80b01f0$681810ac@movaz.com> From: "Adrian Farrel" To: "Wijnen, Bert (Bert)" , "MPLS WG" References: <7D5D48D2CAA3D84C813F5B154F43B15501BC29AD@nl0006exch001u.nl.lucent.com> Subject: Re: prequeal to WG lat call om the LSR mib module Date: Fri, 6 Jun 2003 18:34:24 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Bert, In answer to your second point... > > > 2) The addition of a RowPointer to the in/out/label > > > stack tables to support "long" or GMPLS-style > > > labels. The RowPointer is normally set to zeroDotZero > > > except when the MIB needs to refer to an external > > > table that defines labels that exceed the 32bits > > > of space alloted in the tables today. This > > > in essence, future-proofs the MIB and makes > > > it compatible immediately with the GMPLS MIBs > > > defined in CCAMP. > > I do not exactly understand that complexity either. > Why can it not be a longer octet string that represents the > label. Why does it have to be an integer for a <32bit label > and if that value is zero then one needs to follow a ptr > to some other place where it is basically an octet string? The issue here is that GMPLS labels may have some format associated with them. The format dictates subfields, and it may be useful to allow those subfields to be separately settable/viewable. Arguments have been made that the context (and perhaps a type indicator) can dictate the structure of a GMPLS label and it can be left to the NMS to format the label and present it to the operator. IMHO this is not good enough because that structure has to be learned from somewhere. It is either encoded in the NMS (which means the NMS is GMPLS-aware) or in the MIB module. If it is in the MIB module it could go in a description (which is no help to the NMS), a display hint (which is possible, but would probably be overly complex), or we break the label up into its constituent subfields. I can refer you to the proto-labelTable in the gmpls-lsr-mib (which is sadly old and blocked behind the MPLS LSR MIB) which gives some impression of what was in our minds with regard to a table specially for labels. An index from the LSR MIB into the labelTable is sufficient for most purposes, and the original plan was to have a field that was either an in-place label or an index into the labelTable (note that a large number of GMPLS labels have no substructure and can be encoded in a 32-bit label). But there was concern from some quarters that multiple labelTables need to be maintained in some implementations, so a more complex indexing scheme is needed. The three possible answers (multiple indexes, rowPointer, octetString) have all been tried and we dance around in circles preferring one then another. I am still a fan of multiple (i.e. dual) integer indexes (so that I can leave the primary index as zero in my implementation which does not need this function). Adrian From owner-mpls@UU.NET Sat Jun 7 12:51:33 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16514 for ; Sat, 7 Jun 2003 12:51:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbr00469 for ; Sat, 7 Jun 2003 16:51:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosbr00148; Sat, 7 Jun 2003 16:51:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQosbb22532 for mpls-outgoing; Sat, 7 Jun 2003 12:48:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosbb22519 for ; Sat, 7 Jun 2003 12:48:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosbb13300 for ; Sat, 7 Jun 2003 12:48:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbb02731 for ; Sat, 7 Jun 2003 12:48:06 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosbb02722 for ; Sat, 7 Jun 2003 12:48:06 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h57Cm2pi004522 for ; Sat, 7 Jun 2003 08:48:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id IAA01347 for ; Sat, 7 Jun 2003 08:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h57Cm2509138 for mpls@uu.net; Sat, 7 Jun 2003 08:48:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosbb22161 for ; Sat, 7 Jun 2003 12:45:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosba29004 for ; Sat, 7 Jun 2003 12:44:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosba28199 for ; Sat, 7 Jun 2003 12:44:15 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosba28193 for ; Sat, 7 Jun 2003 12:44:15 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h57Ci3pi004422; Sat, 7 Jun 2003 08:44:04 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-261.cisco.com [10.86.243.6]) by bucket.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC03588; Sat, 7 Jun 2003 08:44:02 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Adrian Farrel'" , "'Loa Andersson'" , "'MPLS WG'" Cc: "'Bert Wijnen'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Sat, 7 Jun 2003 08:43:51 -0400 Organization: Cisco Systems Message-ID: <08bc01c32cf2$761792b0$6601a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <0b8301c32c3b$0c3d1c50$681810ac@movaz.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Adrian Farrel [mailto:afarrel@movaz.com] > Sent: Friday, June 06, 2003 10:51 AM > To: Loa Andersson; MPLS WG > Cc: Thomas D. Nadeau; Bert Wijnen > Subject: Re: prequeal to WG lat call om the LSR mib module > > > Loa, > Thanks for the opportunity to comment publicly about this issue. > > I believe there is a degree of cyclic redundancy about this debate. > > In my view, part of the problem is caused by an attempt to > place a tight association between labels and segment indexing > which is not a requirement for successful implementation. > > For the sake of history... > > At the MIB meeting in Atlanta there was reluctant agreement > to accept an octet string. This octet string, however, was > agreed as a combination of the two fields (and three > functions) that are now being proposed. That is, it provided > an identifier of the label, acted as an index into segment > tables, and provided an index into an external table > containing labels. In effect it circumvented issues of making > a rowPointer an index (yuck) and provided a place to store > labels 'in line'. This was a compromise designed to help > implementers who believed that they needed a more complex > index than a single integer equivalent to the label because > the labels might be distributed across multiple label > management components *and* who believed that adding a > secondary integer index to point to the appropriate label > management component was not sufficient - they needed an > 'arbitrary' secondary index which could only be held in an > octet string. > > The value of that solution was that an non-32 bit label could > be held 'in line' in the octet string without needing to > implement a label table provided that it was clear from the > context how the label should be interpreted. > > Looking at the inSegmentTable > > The old solution (version 9) had > - an interface index that was an index into the inSegmentTable > - a 23-bit label value that was an index into the inSegmentTable > > The requirements are > - to be future-proofed ready to upgrade to GMPLS > - to support distributed solutions > > For a while the proposal was > - an interface index that was an index into the inSegmentTable > - a 32-bit value that could be interpreted as > - a label and an index into the inSegmentTable > OR > - an index into a labelTable and an index into the inSegmentTable > > This went by the board because > - the labelTable may need to be distributed across components > making a single 32-bit index hard to implement > > The Atlanta solution was > - an interface index that was an index into the inSegmentTable > - an octet string that could be interpreted as > - a label and an index into the inSegmentTable > OR > - an index into a labelTable and an index into the inSegmentTable > > This was discarded (as far as I can tell) at least because > - arbitrary indexing of the inSegmentTable was preferred (matches the > outSegmentTable) > - finding a 23-bit label in an octet string is not nice > > This new solution (it is hard to be specific without seeing > the relevant bits of the MIB, but I was allowed to see some > early versions) appears to include > - an arbitrary octet string index for the segment table > - an object to contain the label if it will fit into a > 23(sic)-bit value > - a pointer into an external table to hold labels otherwise > - an object to contain the interface index > > I do not understand why an octet string index is needed. If > you need your insegment index to identify the location of the > component that maintains the segment, and you need that > location to dictate the index, why do you not simply use two > integers? Because it may be insufficient to identify the application's indexing. Although I agree with you that having an integer indicate the application's internal ID, I don't see this as having any advantage over using a longer addressing space. The reason being that if you allow each application to index its entries as it may (i.e.: LDP might use destination IPv4 or IPv6 prefixes), then it is a straight O(1) indexing operation to get to both the application's bag of labels and the entry itself. The semantical meaning between an octet string or two integers is the same, but the flexibility that the octet string affords you is much better. > Integer searches are cheaper to implement - octet > string searches are a mess. (Yes, I know you can encode two > integers into an octet string, but that is hardly the point.) I wouldn't characterize it that way. Personally, having implemented this and many other MIBs, I will say that octet strings are not necessarily a mess, especially in this case since the octet string truly represents just a potentially large unsigned integer (or a really small one if that is all you want to support). > Why not have > - an arbitrary primary integer index for the segment table > this could be used as the component id or set to zero > this could be used to contain the interface index if you want > - an arbitrary secondary integer index for the segment table > this could be used as the label value if that is how your > mind works > - a 32-bit object to contain the label if it will fit > thus MPLS 23-bit labels and GMPLS 32-bit labels will fit > - a pointer into an external table to hold labels otherwise > - an object to contain the interface index This scheme will not work unless we also include an ifIndex. The reason being that the same application may want to distribute the same label on different interfaces (per-interface label spaces). Using only those two indexes will not uniquely identify both instances of the same label. I think that we had arrived at this in Atlanta: (ifIndex, appId, label) So using this scheme, we now have a triple index to iterate over, making your GetNext way less efficient and straight-forward than just using a single octet string. I think this is what pushed us towards using an octet string. --Tom > Adrian > > > ----- Original Message ----- > From: "Loa Andersson" > To: "MPLS WG" > Cc: "Thomas D. Nadeau" ; "Bert Wijnen" > > Sent: Friday, June 06, 2003 3:04 AM > Subject: prequeal to WG lat call om the LSR mib module > > > > > > > > MPLSers, > > > > included are two major items that the authors, wg-chairs > and ADs want > > specific comments on when the LSR mib module is published and last > > called. The MIB will be sent to the Internet Drafts today (Friaday) > > but will take a few days before it is announced. The last > call will be > > started by a specific mail, as soon as we see it publiched, > and will > > be limitied to changes since the last version. The > discussion on the > > items below could take place as a part of the wg last call. > > > > > > The items are: > > > > 1) The indexing of the in/out/XC > > tables has changed from Unsigned32s > > to Octet Strings of up to 24 bytes > > in length. > > > > The reason this was done was to facilitate > > LSRs that support multiple applications of > > MPLS in a distribute fashion. Use of a > > flat 32 bit indexing space on these platforms > > ends up with VERY slot N^2+ GetNext searches > > due to the fact that labels are distributed > > among different applications. The GetNext > > routine must then query each application's > > "bag" of labels to determine the next index. > > > > This change is compatible with implementations > > that wish to remain with the 4 byte indexing; > > they just use a 4 byte octet string, while others > > are free to use the more specific indexing. > > > > 2) The addition of a RowPointer to the in/out/label > > stack tables to support "long" or GMPLS-style > > labels. The RowPointer is normally set to zeroDotZero > > except when the MIB needs to refer to an external > > table that defines labels that exceed the 32bits > > of space alloted in the tables today. This > > in essence, future-proofs the MIB and makes > > it compatible immediately with the GMPLS MIBs > > defined in CCAMP. > > > > > -- > > /Loa > > > > mobile + 46 739 81 21 64 > > email: loa@pi.se > > > > > From owner-mpls@UU.NET Sat Jun 7 12:54:42 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16547 for ; Sat, 7 Jun 2003 12:54:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbr05696 for ; Sat, 7 Jun 2003 16:54:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosbr05519; Sat, 7 Jun 2003 16:54:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQosba21673 for mpls-outgoing; Sat, 7 Jun 2003 12:41:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosba21668 for ; Sat, 7 Jun 2003 12:41:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosba07574 for ; Sat, 7 Jun 2003 12:40:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosba24317 for ; Sat, 7 Jun 2003 12:40:54 GMT Received: from imf19aec.bellsouth.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail101.mail.bellsouth.net [205.152.58.41]) id QQosba24307 for ; Sat, 7 Jun 2003 12:40:53 GMT Received: from localHost ([209.214.160.64]) by imf19aec.bellsouth.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030607124159.PCHX28459.imf19aec.bellsouth.net@localHost> for ; Sat, 7 Jun 2003 08:41:59 -0400 Date: Sat, 07 Jun 2003 08:42 -0400 (EDT) From: Len Nieman X-Mailer: MailRoom for Internet v3.1b (www.SierraSol.com) To: mpls Subject: Howdy! Message-Id: <20030607124159.PCHX28459.imf19aec.bellsouth.net@localHost> Sender: owner-mpls@UU.NET Precedence: bulk Don't mean to interrupt the technical discussions, but I just subscribed to the mpls WG. I figured a quick "Howdy!" would be best to let you all know I'm here and give you a 'quick and dirty' on my background, rather than just dropping a comment in out of the blue. I've been involved with data communications since 55 baud (does anyone remember what a baud is?) teletype was considered high speed, primarily as a trouble shooter and occasionally working with development groups putting together network management systems. From most of your perspectives, you could say I'm an end user of MIBs. I've been using them with Frame Relay and ATM networks for some time now, and lately started having to deal with MPLS based networks. I've been following the discussions on this forum for a week or so now, and have already found it extremely useful in understanding how some things got the way they are in the MIBs. For what it's worth to the group, I'm proficient with the MG-SOFT(tm) MIB Editor, Compiler, and Browser. And I'm more than willing to try compiling modules to see if they 'blow up' due to typos, open {}, syntax errors, and such. Which, unfortunately, I seem to run into fairly often with MIB modules extracted from RFCs. Oh, almost forgot. I currently work for the MCI Data Network Application Support group, but follow this group from home due to time and workload constraints. Len Nieman From owner-mpls@UU.NET Sat Jun 7 13:43:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17073 for ; Sat, 7 Jun 2003 13:43:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbu12421 for ; Sat, 7 Jun 2003 17:43:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosbu12221; Sat, 7 Jun 2003 17:43:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQosbd14175 for mpls-outgoing; Sat, 7 Jun 2003 13:24:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosbd14153 for ; Sat, 7 Jun 2003 13:24:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosbd00357 for ; Sat, 7 Jun 2003 13:20:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbd09920 for ; Sat, 7 Jun 2003 13:20:10 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosbd09915 for ; Sat, 7 Jun 2003 13:20:09 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h57DK6LU006249 for ; Sat, 7 Jun 2003 09:20:06 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA02384 for ; Sat, 7 Jun 2003 09:20:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h57DK6n12155 for mpls@uu.net; Sat, 7 Jun 2003 09:20:06 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosbd13621 for ; Sat, 7 Jun 2003 13:17:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosbd28028 for ; Sat, 7 Jun 2003 13:17:26 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbd06990 for ; Sat, 7 Jun 2003 13:17:24 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosbd06977 for ; Sat, 7 Jun 2003 13:17:24 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h57DHCLU005984; Sat, 7 Jun 2003 09:17:13 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-261.cisco.com [10.86.243.6]) by bucket.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC03759; Sat, 7 Jun 2003 09:17:11 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Adrian Farrel'" , "'Wijnen, Bert \(Bert\)'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Sat, 7 Jun 2003 09:17:02 -0400 Organization: Cisco Systems Message-ID: <08c201c32cf7$1919a080$6601a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <0c3801c32c7b$c80b01f0$681810ac@movaz.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Adrian Farrel > Sent: Friday, June 06, 2003 6:34 PM > To: Wijnen, Bert (Bert); MPLS WG > Subject: Re: prequeal to WG lat call om the LSR mib module > > > Bert, > In answer to your second point... > > > > > 2) The addition of a RowPointer to the in/out/label > > > > stack tables to support "long" or GMPLS-style > > > > labels. The RowPointer is normally set to zeroDotZero > > > > except when the MIB needs to refer to an external > > > > table that defines labels that exceed the 32bits > > > > of space alloted in the tables today. This > > > > in essence, future-proofs the MIB and makes > > > > it compatible immediately with the GMPLS MIBs > > > > defined in CCAMP. > > > > I do not exactly understand that complexity either. > > Why can it not be a longer octet string that represents the > label. Why > > does it have to be an integer for a <32bit label and if > that value is > > zero then one needs to follow a ptr to some other place where it is > > basically an octet string? > > The issue here is that GMPLS labels may have some format > associated with them. The format dictates subfields, and it > may be useful to allow those subfields to be separately > settable/viewable. > > Arguments have been made that the context (and perhaps a type > indicator) can dictate the structure of a GMPLS label and it > can be left to the NMS to format the label and present it to > the operator. IMHO this is not good enough because that > structure has to be learned from somewhere. It is either > encoded in the NMS (which means the NMS is GMPLS-aware) or in > the MIB module. If it is in the MIB module it could go in a > description (which is no help to the NMS), a display hint > (which is possible, but would probably be overly complex), or > we break the label up into its constituent subfields. > > I can refer you to the proto-labelTable in the gmpls-lsr-mib > (which is sadly old and blocked behind the MPLS LSR MIB) > which gives some impression of what was in our minds with > regard to a table specially for labels. > > An index from the LSR MIB into the labelTable is sufficient > for most purposes, and the original plan was to have a field > that was either an in-place label or an index into the > labelTable (note that a large number of GMPLS labels have no > substructure and can be encoded in a 32-bit label). Right, IMHO the GMPLS-LSR inSegmentTable indexing will be for example: ( mplsInSegmentIndex, gmplsLabelSegment ) where the latter index shows you which chunk of the label you are getting at. Each row in this table can have other fields such as label type and so on. > But there was concern from some quarters that multiple > labelTables need to be maintained in some implementations, so > a more complex indexing scheme is needed. The three possible > answers (multiple indexes, rowPointer, octetString) have all > been tried and we dance around in circles preferring one then another. > > I am still a fan of multiple (i.e. dual) integer indexes (so > that I can leave the primary index as zero in my > implementation which does not need this function). You can do this too with an Octet String and make other implementations happy as well, just encode your index as (applicationId + ifIndex + label). Your search time will be exactly the same as if they were three indexes, and your GetNext function will be simplified. --Tom From owner-mpls@UU.NET Sat Jun 7 13:44:03 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17089 for ; Sat, 7 Jun 2003 13:44:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbu13590 for ; Sat, 7 Jun 2003 17:44:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosbu13383; Sat, 7 Jun 2003 17:43:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQosbd14550 for mpls-outgoing; Sat, 7 Jun 2003 13:28:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosbd14530 for ; Sat, 7 Jun 2003 13:27:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosbd28813 for ; Sat, 7 Jun 2003 13:26:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbd16641 for ; Sat, 7 Jun 2003 13:26:18 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosbd16634 for ; Sat, 7 Jun 2003 13:26:18 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h57DQFpi005648 for ; Sat, 7 Jun 2003 09:26:15 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA02550 for ; Sat, 7 Jun 2003 09:26:14 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h57DQEf12933 for mpls@uu.net; Sat, 7 Jun 2003 09:26:14 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosbd14209 for ; Sat, 7 Jun 2003 13:24:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosbd04977 for ; Sat, 7 Jun 2003 13:22:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbd13010 for ; Sat, 7 Jun 2003 13:22:30 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosbd12998 for ; Sat, 7 Jun 2003 13:22:30 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h57DMMpi005548; Sat, 7 Jun 2003 09:22:23 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-261.cisco.com [10.86.243.6]) by bucket.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC03774; Sat, 7 Jun 2003 09:22:22 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Sat, 7 Jun 2003 09:22:11 -0400 Organization: Cisco Systems Message-ID: <08c401c32cf7$d2350460$6601a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC29AD@nl0006exch001u.nl.lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Wijnen, Bert (Bert) > Sent: Friday, June 06, 2003 5:36 PM > To: MPLS WG > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > MPLSers, > > > > > > included are two major items that the authors, wg-chairs and ADs > > > want specific comments on when the LSR mib module is > published and > > > last called. The MIB will be sent to the Internet Drafts today > > > (Friaday) but will take a few days before it is > announced. The last > > > call will be started by a specific mail, as soon as we see it > > > publiched, and will be limitied to changes since the last > version. > > > The discussion on the items below could take place as a > part of the > > > wg last call. > > > > > > > > > The items are: > > > > > > 1) The indexing of the in/out/XC > > > tables has changed from Unsigned32s > > > to Octet Strings of up to 24 bytes > > > in length. > > > > > > The reason this was done was to facilitate > > > LSRs that support multiple applications of > > > MPLS in a distribute fashion. Use of a > > > flat 32 bit indexing space on these platforms > > > ends up with VERY slot N^2+ GetNext searches > > > due to the fact that labels are distributed > > > among different applications. The GetNext > > > routine must then query each application's > > > "bag" of labels to determine the next index. > > > > > > This change is compatible with implementations > > > that wish to remain with the 4 byte indexing; > > > they just use a 4 byte octet string, while others > > > are free to use the more specific indexing. > > > > So... my understanding is that the mplsInSegmentTable > and mplsOutSegmentTable are both read-create tables. > > I do not see how the index object (the 24 octets) is > structured, It isn't, view it as a large Unsigned32. > and so I do not understand how an NMS application > that wants to create a specific entry in this table is going > to understand the structure. It now looks as if the NMS app > needs to pickup mplsInSegmentIndexNext or > mplsOutSegmentIndexNext and use that as an index. But will > that always work, no matter what kind of new entry the NMS > app wants to create? I don't see why not. > > > 2) The addition of a RowPointer to the in/out/label > > > stack tables to support "long" or GMPLS-style > > > labels. The RowPointer is normally set to zeroDotZero > > > except when the MIB needs to refer to an external > > > table that defines labels that exceed the 32bits > > > of space alloted in the tables today. This > > > in essence, future-proofs the MIB and makes > > > it compatible immediately with the GMPLS MIBs > > > defined in CCAMP. > > > > > > I do not exactly understand that complexity either. > Why can it not be a longer octet string that represents the > label. Why does it have to be an integer for a <32bit label > and if that value is zero then one needs to follow a ptr to > some other place where it is basically an octet string? I personally don't care whether there is a RowPointer there or a boolean. Between version 09 and 10 the co-authors had considered both, and it seemed that the RowPointer one out. IMHO I think that we can re-use the tabular indexing from each MPLS-LSR MIB table in the GMPLS MIB and only require some indicator that tells someone looking at the MPLS-LSR MIB's tables that they need to look elsewhere for the rest of the label. At one point we had a simple boolean that told you this. Now we have a RowPointer that is set to zeroDotZero or an OID. To me, it means the same thing, so at the end of the day either approach will work just fine. --Tom > The WG needs to decide... but I find it more complex than > needed. Maybe it is just me. > > Bert > From owner-mpls@UU.NET Sat Jun 7 13:57:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17326 for ; Sat, 7 Jun 2003 13:57:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbv05034 for ; Sat, 7 Jun 2003 17:57:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosbv04849; Sat, 7 Jun 2003 17:57:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQosbc13093 for mpls-outgoing; Sat, 7 Jun 2003 13:14:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosbc13084 for ; Sat, 7 Jun 2003 13:14:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosbc16584 for ; Sat, 7 Jun 2003 13:14:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbc03503 for ; Sat, 7 Jun 2003 13:14:08 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosbc03487 for ; Sat, 7 Jun 2003 13:14:08 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h57DE4pi005273 for ; Sat, 7 Jun 2003 09:14:05 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA02189 for ; Sat, 7 Jun 2003 09:14:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h57DE4r11434 for mpls@uu.net; Sat, 7 Jun 2003 09:14:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosbc12821 for ; Sat, 7 Jun 2003 13:13:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosbc29153 for ; Sat, 7 Jun 2003 13:13:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosbc02469 for ; Sat, 7 Jun 2003 13:13:08 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosbc02464 for ; Sat, 7 Jun 2003 13:13:07 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h57DD0pi005238; Sat, 7 Jun 2003 09:13:00 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-261.cisco.com [10.86.243.6]) by bucket.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC03743; Sat, 7 Jun 2003 09:12:58 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Sat, 7 Jun 2003 09:12:54 -0400 Organization: Cisco Systems Message-ID: <08c101c32cf6$81fcc830$6601a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC297C@nl0006exch001u.nl.lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Wijnen, Bert (Bert) > Sent: Friday, June 06, 2003 11:14 AM > To: MPLS WG > Subject: RE: prequeal to WG lat call om the LSR mib module > > > All... > > As soon as you get to see the MIB module, you can all check > for yourself. Here is why I have a serious concern with using > 24-octet index objects. Specifically for the mplsXCTable, where > 3 of such 24-octet objects are used as index. > > My comments below are based on a pre-relase version of the > doc I got to see/check, so if things have changed since then, > it may not be 100% accurate. > > Take the mplsXCTable. It has 3 of these objects as index onjects. > > It has 7 columns of which 5 are read-create. The read-create > objects are all pretty small in size. Like 3 integer based > that would contain some 9 octets on the wire together, then > an LSPID (4 or 8 octets on the wire), and another index type, > possibly 26 octets on the wire. So the actual DATA values on > the wire to create (or read) such a row consists of max 43 octets. > > The OID for the mplsXCEntry is: 1.3.6.1.2.1.10.166.2.1.9.1 > > So if each of the indices is 24 octets, then it adds 3*25 or > 75 octets to each OID. So the OID for each column is 87 octets. > > So to transport the 5 objects (containing max 43 octets of > real data) you potentially have to send 435 + 43 or 478 > octets. Add to that the overhead for SNMP header and PDU > header data, and it does not even fit in a 484 SNMP packet > anymore and so a > createAndGo may not be working in some implementations anymore. > > When you had 3 Unsigned32 as index. the OID for each column > would have been max 29 octets or so. So the total would have > been 145 + 23 is some 168 or so octets (the data for the > mplsXCLabelStackIndex would also be reduced from 26 to 6). Well Bert, it is always an matter of time versus space. The use of the larger index allows implementations to efficiently index things in O(1) fashion rather than doing O(N)->O(N)^3 searches based on a single Unsigned32. I speak from real experience on this. Consider what implementations that have distributed label tables must do on a GetNext operation in a configuration such as this. Note that each application resides in a different process space: Application Incoming Labels Owned by Application LDP { 15, 29, 45 } VPN { 30, 31, 32 } TE { 16, 17, 18 } Using the original indexing of (ifIndex, mplsLabel) worked for the above example, but as VERY inefficient for a GetNext operation. Think about what happens when the manager issues a GetNext(14). In this case, I first have to visit each application and ask it if it has a label that is greater than 14. This costs O(N)* num appliations in the worse case. Now consider how most implementations store the outgoing label. It is my understanding that most implementations do not index on the outgoing label; rather only on the incoming one since they do not own the outgoing label. This means that to find the outgoing label, you have a search that requires you do search first through all of the incoming labels, and then for each one, search make sure that the outgoing label is "best". This results in O(N^2). My operational experience with this MIB and my customers who are using it over the past 3 or so years is that such searches translate into is essentially an unusable MIB considering how many entries are often contained -- O(100,000+) on a P router -- and how long it will take to download each entry * the number of entries in the table. Now consider if you had used Adrian's original approach of (applicationId, ifIndex, label): The searhes would be vastly faster -- O(N) in all cases -- because you would quickly know if you were in the right collection of labels or not, and then search through its list of labels. If not in the right collection, you simply move on to the next one and search there. The only problem with this approach is that you have do do at least an O(N) search to find the "next" best label. Using more indexing space allows implementations to customize the index to match EXACTLY how they index internally, thus giving the potential for searches to happen in O(1) time, so no matter how large the table is, you can get the data returned to you very, very quickly with minor extra overhead on the wire to achieve this. So as you can see, some extra bits on the wire can go a long, long way to making this MIB extremely useful. --Tom > Thanks, > Bert > From owner-mpls@UU.NET Sat Jun 7 22:08:25 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28753 for ; Sat, 7 Jun 2003 22:08:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosdc12197 for ; Sun, 8 Jun 2003 02:08:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosdc11813; Sun, 8 Jun 2003 02:08:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQoscj19532 for mpls-outgoing; Sat, 7 Jun 2003 21:29:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoscj19525 for ; Sat, 7 Jun 2003 21:28:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoscj29041 for ; Sat, 7 Jun 2003 21:28:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoscj05595 for ; Sat, 7 Jun 2003 21:28:18 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQoscj05581 for ; Sat, 7 Jun 2003 21:28:17 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h57LSHu01434 for ; Sat, 7 Jun 2003 14:28:17 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id h57LSHn21040 for mpls@uu.net; Sat, 7 Jun 2003 14:28:17 -0700 (PDT) (envelope-from kireeti) Date: Sat, 7 Jun 2003 14:28:17 -0700 (PDT) From: Kireeti Kompella Message-Id: <200306072128.h57LSHn21040@kummer.juniper.net> To: mpls@UU.NET Subject: draft-ietf-mpls-ldp-mtu-extensions-01.txt Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I've just submitted a new version of the LDP MTU doc; it should be available in a couple of days. There are some significant changes; please read and comment. Thanks! Kireeti. From owner-mpls@UU.NET Mon Jun 9 11:32:13 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08879 for ; Mon, 9 Jun 2003 11:32:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosiw02368 for ; Mon, 9 Jun 2003 15:32:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosiw02211; Mon, 9 Jun 2003 15:32:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQosih23085 for mpls-outgoing; Mon, 9 Jun 2003 11:48:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosih23064 for ; Mon, 9 Jun 2003 11:48:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosih29116 for ; Mon, 9 Jun 2003 11:48:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosih23613 for ; Mon, 9 Jun 2003 11:48:06 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosih23594 for ; Mon, 9 Jun 2003 11:48:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h59Bm3LU028774 for ; Mon, 9 Jun 2003 07:48:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id HAA15794 for ; Mon, 9 Jun 2003 07:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h59Bm2115119 for mpls@uu.net; Mon, 9 Jun 2003 07:48:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosih23018 for ; Mon, 9 Jun 2003 11:46:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosih21013 for ; Mon, 9 Jun 2003 11:45:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosih20154 for ; Mon, 9 Jun 2003 11:45:52 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQosih20146 for ; Mon, 9 Jun 2003 11:45:51 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28708; Mon, 9 Jun 2003 07:45:50 -0400 (EDT) Message-Id: <200306091145.HAA28708@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-lsr-mib-10.txt Date: Mon, 09 Jun 2003 07:45:50 -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 : Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base Author(s) : C. Srinivasan, A. Viswanathan, T.Nadeau Filename : draft-ietf-mpls-lsr-mib-10.txt Pages : 54 Date : 2003-6-6 This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multi-Protocol Label Switching (MPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsr-mib-10.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-lsr-mib-10.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: <2003-6-6133243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsr-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsr-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-6133243.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jun 9 16:10:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19653 for ; Mon, 9 Jun 2003 16:10:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosjo26139 for ; Mon, 9 Jun 2003 20:10:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosjo25667; Mon, 9 Jun 2003 20:10:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQosih23088 for mpls-outgoing; Mon, 9 Jun 2003 11:48:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosih23066 for ; Mon, 9 Jun 2003 11:48:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosih11760 for ; Mon, 9 Jun 2003 11:48:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosih23718 for ; Mon, 9 Jun 2003 11:48:09 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosih23698 for ; Mon, 9 Jun 2003 11:48:09 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h59Bm2LU028772 for ; Mon, 9 Jun 2003 07:48:02 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id HAA15790 for ; Mon, 9 Jun 2003 07:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h59Bm2815110 for mpls@uu.net; Mon, 9 Jun 2003 07:48:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosih23019 for ; Mon, 9 Jun 2003 11:46:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosih21002 for ; Mon, 9 Jun 2003 11:45:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosih20148 for ; Mon, 9 Jun 2003 11:45:52 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQosih20014 for ; Mon, 9 Jun 2003 11:45:47 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28693; Mon, 9 Jun 2003 07:45:45 -0400 (EDT) Message-Id: <200306091145.HAA28693@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-tc-mib-07.txt Date: Mon, 09 Jun 2003 07:45:45 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau, J. Cucchiara Filename : draft-ietf-mpls-tc-mib-07.txt Pages : 23 Date : 2003-6-6 This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Mulitprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-tc-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-tc-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-6133231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-tc-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-tc-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-6133231.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jun 9 20:55:27 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26837 for ; Mon, 9 Jun 2003 20:55:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoskh13786 for ; Tue, 10 Jun 2003 00:55:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoskh13604; Tue, 10 Jun 2003 00:55:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQosjr21842 for mpls-outgoing; Mon, 9 Jun 2003 20:53:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosjr21830 for ; Mon, 9 Jun 2003 20:53:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosjr26765 for ; Mon, 9 Jun 2003 20:51:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosjr11230 for ; Mon, 9 Jun 2003 20:51:15 GMT Received: from maila.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maila.telia.com [194.22.194.231]) id QQosjr11210 for ; Mon, 9 Jun 2003 20:51:14 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maila.telia.com (8.12.9/8.12.9) with ESMTP id h59Kp6Ms019611; Mon, 9 Jun 2003 22:51:06 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h59Kp5c03414; Mon, 9 Jun 2003 22:51:05 +0200 (CEST) Message-ID: <3EE4F226.4030104@pi.se> Date: Mon, 09 Jun 2003 22:46:30 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG , Bert Wijnen , Alex Zinin Subject: WG lat call on LSR and LDP MIB moduels Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, this is to initiate a two week wg last call on Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base and Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) this wg last call ends June 22nd, and is limited to the changes in the IDs since the previous wg last call, as well as interdepencies between the two mib modules and the mib modules listed below. For the LSR MIB please re-read the mail I sent to the list June 6 called "prequeal to WG lat call om the LSR mib module" (OK - my spelling, but admit that it is charming :) ) A usual silence will be understood as support, but this would not necessarily stop you from giving positive comments. Please do. There are more MIB modules coming up for wg last call and that have been through wg last call, all of those will have interdependencies. 1. the TC mib module are wg last called and updated, but waiting for the others to be ready for IESG review 2. the TE link MIB module is in wg last call (to end June 13) 3. the management overview has been through wg lst call and has been uppdated Two other MIB modules are in the pipe and new version will be released shortly 5. The TE mib module 6. The FTN mib module It is important that we complete this process of reviewing and updtating before the ID cut off date (June 30) for the Vienna meeting. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Mon Jun 9 20:59:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26888 for ; Mon, 9 Jun 2003 20:59:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoskh21494 for ; Tue, 10 Jun 2003 00:59:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoskh21416; Tue, 10 Jun 2003 00:59:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQosjs25323 for mpls-outgoing; Mon, 9 Jun 2003 21:00:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosjs24160 for ; Mon, 9 Jun 2003 21:00:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosjs03652 for ; Mon, 9 Jun 2003 21:00:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosjs04094 for ; Mon, 9 Jun 2003 21:00:17 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQosjs04077 for ; Mon, 9 Jun 2003 21:00:17 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h59L0DB25809 for ; Mon, 9 Jun 2003 17:00:14 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10QVF0>; Mon, 9 Jun 2003 23:00:11 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2B9D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Loa Andersson , MPLS WG , Bert Wijnen , Alex Zinin Subject: RE: WG lat call on LSR and LDP MIB moduels Date: Mon, 9 Jun 2003 23:00:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > and > Definitions of Managed Objects for the Multiprotocol Label > Switching, Label Distribution Protocol (LDP) > > Was this MIB not gonna be revised to follow the new STD naming convention? In order to do MIB compiles for syntax checking, I now need to go in manually and fix all that otherwsie the various IMPORTs don't work !!?? Bert From owner-mpls@UU.NET Tue Jun 10 00:18:06 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00396 for ; Tue, 10 Jun 2003 00:18:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoskv24499 for ; Tue, 10 Jun 2003 04:18:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoskv23813; Tue, 10 Jun 2003 04:17:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQosks26448 for mpls-outgoing; Tue, 10 Jun 2003 03:36:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosks26441 for ; Tue, 10 Jun 2003 03:36:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosks22794 for ; Tue, 10 Jun 2003 03:36:34 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosks22559 for ; Tue, 10 Jun 2003 03:36:34 GMT Received: from web41809.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web41809.mail.yahoo.com [66.218.93.143]) id QQosks22547 for ; Tue, 10 Jun 2003 03:36:33 GMT Message-ID: <20030610033633.16256.qmail@web41809.mail.yahoo.com> Received: from [203.200.20.226] by web41809.mail.yahoo.com via HTTP; Tue, 10 Jun 2003 04:36:33 BST Date: Tue, 10 Jun 2003 04:36:33 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: IMplicit NULL Label To: mpls-ops@mplsrc.com, ppvpn@nortelnetworks.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Folks, Can BGP ever recieve an Implicit NULL Label from one of its PE peers. If yes, then when and what does it signify? Thanks, John Smith __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html From owner-mpls@UU.NET Tue Jun 10 01:52:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02392 for ; Tue, 10 Jun 2003 01:52:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoslb06121 for ; Tue, 10 Jun 2003 05:52:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoslb05972; Tue, 10 Jun 2003 05:52:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQoskv17814 for mpls-outgoing; Tue, 10 Jun 2003 04:19:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoskv17809 for ; Tue, 10 Jun 2003 04:18:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoskv13338 for ; Tue, 10 Jun 2003 04:16:03 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoskv18491 for ; Tue, 10 Jun 2003 04:16:02 GMT Received: from blount.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: blount.mail.mindspring.net [207.69.200.226]) id QQoskv18238 for ; Tue, 10 Jun 2003 04:15:57 GMT Received: from dialup-67.75.27.22.dial1.boston1.level3.net ([67.75.27.22] helo=jluciani-laptop) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 19PaY1-0005xa-00; Tue, 10 Jun 2003 00:15:50 -0400 Message-Id: <3.0.1.32.20030610001641.017482d4@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Jun 2003 00:16:41 -0400 To: "Wijnen, Bert (Bert)" , Loa Andersson , MPLS WG , Bert Wijnen , Alex Zinin Subject: RE: WG lat call on LSR and LDP MIB moduels In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC2B9D@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Bert and Loa, I just submitted version 11 which should compile with the STD change (you were cc'd on this email). I apologize for my incorrect email to Loa earlier on sending the MIB to last call. I forgot about the STD change and that it wouldn't compile without it. Please do working group last call on Version 11. And again, I apologize for my missing this. thanks, Joan At 11:00 PM 6/9/03 +0200, Wijnen, Bert (Bert) wrote: >> and >> Definitions of Managed Objects for the Multiprotocol Label >> Switching, Label Distribution Protocol (LDP) >> >> >Was this MIB not gonna be revised to follow the new STD naming >convention? In order to do MIB compiles for syntax checking, I >now need to go in manually and fix all that otherwsie the >various IMPORTs don't work !!?? > >Bert > From owner-mpls@UU.NET Tue Jun 10 05:20:48 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18255 for ; Tue, 10 Jun 2003 05:20:47 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoslp19416 for ; Tue, 10 Jun 2003 09:20:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoslp19305; Tue, 10 Jun 2003 09:20:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQosld03077 for mpls-outgoing; Tue, 10 Jun 2003 06:18:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosld03072 for ; Tue, 10 Jun 2003 06:18:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosld09045 for ; Tue, 10 Jun 2003 06:18:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosld27393 for ; Tue, 10 Jun 2003 06:18:01 GMT Received: from mailg.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailg.telia.com [194.22.194.26]) id QQosld27363 for ; Tue, 10 Jun 2003 06:18:00 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.9/8.12.9) with ESMTP id h5A6HpPn020317; Tue, 10 Jun 2003 08:17:51 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h5A6Gac20168; Tue, 10 Jun 2003 08:16:36 +0200 (CEST) Message-ID: <3EE576B0.7090200@pi.se> Date: Tue, 10 Jun 2003 08:12:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG CC: Loa Andersson , Bert Wijnen , Alex Zinin Subject: Re: WG lat call on LSR and LDP MIB modules - CORRECTION! References: <3EE4F226.4030104@pi.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, a missundertanding between me and the authors resulted in that the wrong version of the LDP mib module was sent to this wg last call. THe correct version is this has just been sent for publication (and with a copy to the mailing list). My take is that we continue the wg last call as planned, but as soon as I see the LDP mib being published I will extend the last call period. This way will get both a head start and the required period of time. /Loa Loa Andersson wrote: > All, > > this is to initiate a two week wg last call on > > Multiprotocol Label Switching (MPLS) Label Switching > Router (LSR) Management Information Base > > > and > Definitions of Managed Objects for the Multiprotocol Label > Switching, Label Distribution Protocol (LDP) > > > this wg last call ends June 22nd, and is limited to the changes in the > IDs since the previous wg last call, as well as interdepencies between > the two mib modules and the mib modules listed below. > > For the LSR MIB please re-read the mail I sent to the list June 6 called > "prequeal to WG lat call om the LSR mib module" > (OK - my spelling, but admit that it is charming :) ) > > A usual silence will be understood as support, but this would not > necessarily stop you from giving positive comments. Please do. > > There are more MIB modules coming up for wg last call and that have been > through wg last call, all of those will have interdependencies. > > 1. the TC mib module are wg last called and updated, but waiting for the > others to be ready for IESG review > > 2. the TE link MIB module is in wg last call (to end June 13) > > 3. the management overview has been through wg lst call and has been > uppdated > > > Two other MIB modules are in the pipe and new version will be released > shortly > > 5. The TE mib module > 6. The FTN mib module > > It is important that we complete this process of reviewing and updtating > before the ID cut off date (June 30) for the Vienna meeting. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Tue Jun 10 11:06:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04690 for ; Tue, 10 Jun 2003 11:06:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosmm23351 for ; Tue, 10 Jun 2003 15:06:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosmm23184; Tue, 10 Jun 2003 15:06:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQoslz28202 for mpls-outgoing; Tue, 10 Jun 2003 11:54:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoslz28195 for ; Tue, 10 Jun 2003 11:54:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoslz13320 for ; Tue, 10 Jun 2003 11:54:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoslz12550 for ; Tue, 10 Jun 2003 11:54:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoslz12547 for ; Tue, 10 Jun 2003 11:54:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5ABs3LU015454 for ; Tue, 10 Jun 2003 07:54:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id HAA15916 for ; Tue, 10 Jun 2003 07:54:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5ABs2w21579 for mpls@uu.net; Tue, 10 Jun 2003 07:54:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoslz28160 for ; Tue, 10 Jun 2003 11:53:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoslz11664 for ; Tue, 10 Jun 2003 11:52:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoslz10673 for ; Tue, 10 Jun 2003 11:52:41 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQoslz10662 for ; Tue, 10 Jun 2003 11:52:41 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21716; Tue, 10 Jun 2003 07:52:39 -0400 (EDT) Message-Id: <200306101152.HAA21716@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-mtu-extensions-01.txt Date: Tue, 10 Jun 2003 07:52:39 -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 : MTU Signalling Extensions for LDP Author(s) : B. Black, K. Kompella Filename : draft-ietf-mpls-ldp-mtu-extensions-01.txt Pages : 10 Date : 2003-6-9 Proper functioning of RFC 1191 path MTU discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent, off-line mechanisms. This document specifies extensions to LDP in support of LSP MTU discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mtu-extensions-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-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: <2003-6-9151125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mtu-extensions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9151125.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jun 10 14:00:50 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10969 for ; Tue, 10 Jun 2003 14:00:50 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosmy15919 for ; Tue, 10 Jun 2003 18:00:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosmy15037; Tue, 10 Jun 2003 18:00:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQosma28556 for mpls-outgoing; Tue, 10 Jun 2003 12:00:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoslz28497 for ; Tue, 10 Jun 2003 11:59:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoslz17378 for ; Tue, 10 Jun 2003 11:58:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoslz15160 for ; Tue, 10 Jun 2003 11:58:07 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoslz15149 for ; Tue, 10 Jun 2003 11:58:07 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5ABw4pi027688 for ; Tue, 10 Jun 2003 07:58:04 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id HAA16119 for ; Tue, 10 Jun 2003 07:58:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5ABw3Y21776 for mpls@uu.net; Tue, 10 Jun 2003 07:58:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoslz28409 for ; Tue, 10 Jun 2003 11:56:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoslz07492 for ; Tue, 10 Jun 2003 11:52:47 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoslz10750 for ; Tue, 10 Jun 2003 11:52:46 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQoslz10741 for ; Tue, 10 Jun 2003 11:52:46 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21737; Tue, 10 Jun 2003 07:52:44 -0400 (EDT) Message-Id: <200306101152.HAA21737@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET, ppvpn@nortelnetworks.com, te-wg@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-06.txt Date: Tue, 10 Jun 2003 07:52:44 -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 : Multiprotocol Label Switching (MPLS) Management Overview Author(s) : T. Nadeau, C. Srinivasan, A. Farrel Filename : draft-ietf-mpls-mgmt-overview-06.txt Pages : 28 Date : 2003-6-9 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This memo describes the management architecture for MPLS and indicates the inter-relationships between the different MIB modules used for MPLS network management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-mgmt-overview-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-9151134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-mgmt-overview-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9151134.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jun 10 23:27:09 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27994 for ; Tue, 10 Jun 2003 23:27:09 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosoj14098 for ; Wed, 11 Jun 2003 03:27:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosoj13240; Wed, 11 Jun 2003 03:26:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQosmg12967 for mpls-outgoing; Tue, 10 Jun 2003 13:44:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosmg12934 for ; Tue, 10 Jun 2003 13:43:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosmg24671 for ; Tue, 10 Jun 2003 13:42:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosmg28899 for ; Tue, 10 Jun 2003 13:42:52 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQosmg28883 for ; Tue, 10 Jun 2003 13:42:51 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 5892F637D; Tue, 10 Jun 2003 09:42:51 -0400 (EDT) Message-ID: <018701c32f56$2ff23040$681810ac@movaz.com> From: "Adrian Farrel" To: , , References: <200306101152.HAA21737@ietf.org> Subject: Re: I-D ACTION:draft-ietf-mpls-mgmt-overview-06.txt Date: Tue, 10 Jun 2003 09:42:51 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk For those excited readers following this draft... Version 6 includes updates - to change all MIB module names to include "-STD" in line with changes to the MIB documents - in line with the latest TE-LINK MIB (thanks Martin) I anticipate another set of changes to pick up the new indexing from the LSR MIB once the WG has agreed it. Adrian ----- Original Message ----- From: To: Cc: ; ; Sent: Tuesday, June 10, 2003 7:52 AM Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-06.txt > 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 : Multiprotocol Label Switching (MPLS) Management > Overview > Author(s) : T. Nadeau, C. Srinivasan, A. Farrel > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-06.txt > From owner-mpls@UU.NET Wed Jun 11 02:25:27 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22371 for ; Wed, 11 Jun 2003 02:25:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosov15143 for ; Wed, 11 Jun 2003 06:25:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosov14870; Wed, 11 Jun 2003 06:25:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQosmq18087 for mpls-outgoing; Tue, 10 Jun 2003 16:07:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosmq18079 for ; Tue, 10 Jun 2003 16:07:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosmq13176 for ; Tue, 10 Jun 2003 16:05:56 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosmq01197 for ; Tue, 10 Jun 2003 16:05:55 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQosmq01192 for ; Tue, 10 Jun 2003 16:05:55 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23662 for ; Tue, 10 Jun 2003 12:05:53 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13285 for ; Tue, 10 Jun 2003 12:05:50 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 12:05:50 -0400 Message-ID: <313680C9A886D511A06000204840E1CF8F54CC@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'mpls@UU.NET'" Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Tue, 10 Jun 2003 12:05:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi! Few comments in-line regarding the indexing of the mplsInSegmentTable > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Saturday, June 07, 2003 9:13 AM > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > Subject: RE: prequeal to WG lat call om the LSR mib module > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > Of Wijnen, Bert (Bert) > > Sent: Friday, June 06, 2003 11:14 AM > > To: MPLS WG > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > Application Incoming Labels Owned by Application > LDP { 15, 29, 45 } > VPN { 30, 31, 32 } > TE { 16, 17, 18 } > > Using the original indexing of (ifIndex, mplsLabel) > worked for the above example, but as VERY inefficient > for a GetNext operation. Think about what happens when > the manager issues a GetNext(14). In this case, I first > have to visit each application and ask it if it has a > label that is greater than 14. This costs O(N)* num appliations > in the worse case. > Comments on the indexing of the mplsInSegmentTable: 1. O(N)*num-applications cost for a getNext() on mplsInSegmentTable, appears to be an artifact of specific agent implementations. [when the underlying container is distributed.] 2. Description for the mplsInSegmentTable, points out that the new indexing structure is designed to handle multiple implementations. I think this is not a good idea to design MIB tables to fit individual implementations. In my personal opinion the original indexing for the mplsInSegmentTable was more natural and appropriate. 3. It is true that there is always a memory and speed tread-off in real world designs. However, this tread-off should be a choice of the individual implementations. Boxes with higher amount of memory might choose an implementation approach that provides relatively efficient GetNext(), even with the original indexing (ifIndex,label) Thanks, sanjay > Now consider how most implementations store the outgoing > label. It is my understanding that most implementations do > not index on the outgoing label; rather only on the incoming > one since they do not own the outgoing label. This means > that to find the outgoing label, you have a search > that requires you do search first through all of the > incoming labels, and then for each one, search make > sure that the outgoing label is "best". This results > in O(N^2). > > My operational experience with this MIB and > my customers who are using it over the past 3 or so > years is that such searches translate into is essentially > an unusable MIB considering how many entries are > often contained -- O(100,000+) on a P router -- and > how long it will take to download each entry * the > number of entries in the table. > > Now consider if you had used Adrian's > original approach of (applicationId, ifIndex, label): > The searhes would be vastly faster -- O(N) > in all cases -- because you would quickly know if > you were in the right collection of labels or not, > and then search through its list of labels. If not > in the right collection, you simply move on to the next > one and search there. The only problem with this approach > is that you have do do at least an O(N) search to find > the "next" best label. Using more indexing space allows > implementations to customize the index to match EXACTLY > how they index internally, thus giving the potential > for searches to happen in O(1) time, so no matter how > large the table is, you can get the data returned > to you very, very quickly with minor extra overhead on > the wire to achieve this. > > So as you can see, some extra bits on the wire > can go a long, long way to making this MIB extremely > useful. > > --Tom > > > > Thanks, > > Bert > > > From owner-mpls@UU.NET Wed Jun 11 02:34:06 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27025 for ; Wed, 11 Jun 2003 02:34:06 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosow02201 for ; Wed, 11 Jun 2003 06:34:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosow01964; Wed, 11 Jun 2003 06:33:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQosng19446 for mpls-outgoing; Tue, 10 Jun 2003 20:11:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosng19441 for ; Tue, 10 Jun 2003 20:11:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosng25121 for ; Tue, 10 Jun 2003 20:10:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosng18516 for ; Tue, 10 Jun 2003 20:10:10 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosng18504 for ; Tue, 10 Jun 2003 20:10:09 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5AKA5pi023291 for ; Tue, 10 Jun 2003 16:10:05 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id QAA02819 for ; Tue, 10 Jun 2003 16:10:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5AKA4V18718 for mpls@uu.net; Tue, 10 Jun 2003 16:10:04 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosng01808 for ; Tue, 10 Jun 2003 20:00:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosnf00335 for ; Tue, 10 Jun 2003 19:59:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosnf02495 for ; Tue, 10 Jun 2003 19:59:40 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosnf02486 for ; Tue, 10 Jun 2003 19:59:40 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5AJxWLU003729; Tue, 10 Jun 2003 15:59:32 -0400 (EDT) Received: from tnadeauw2k ([161.44.71.237]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAA12357; Tue, 10 Jun 2003 15:59:30 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Tue, 10 Jun 2003 15:59:21 -0400 Organization: Cisco Systems Message-ID: <00a401c32f8a$cc799be0$ed472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC2E68@nl0006exch001u.nl.lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, June 10, 2003 3:46 PM > To: tnadeau@cisco.com; 'MPLS WG' > Subject: RE: prequeal to WG lat call om the LSR mib module > > > So if you have 3 application managing Label Space as > in the following example. > > > > Application Incoming Labels Owned by Application > > LDP { 15, 29, 45 } > > VPN { 30, 31, 32 } > > TE { 16, 17, 18 } > > > And then you have the object mplsInSegmentIndexNext > > How does that IndexNext object provide me with a proper > new index value that I can use. Cause it does not know > if I (as an application) want to create a new InSegment > for LPD, VPN or TE... or does it? If it does, then I > do not understand how. Maybe I missed the explanation in > some text in the MIB document... if so, pls point me to it. It knows because it knows which device it is provisioning and thus knows what the application ID values need to be (from its agent cap statement or other documentation). I don't see this as a problem since there is a whole slew of non-standard things that a provisioning system needs to know about devices it manages. In fact, I would bet that %100 of the implementations out there will require some bit of proprietary MIB support to facilitate provisioning of static LSPs via SNMP (if they even will allow this). IMHO the fact that we have %90 of what most people need is not too bad. --Tom From owner-mpls@UU.NET Wed Jun 11 05:35:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00575 for ; Wed, 11 Jun 2003 05:35:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospi28503 for ; Wed, 11 Jun 2003 09:35:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQospi28368; Wed, 11 Jun 2003 09:35:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQosnf29503 for mpls-outgoing; Tue, 10 Jun 2003 19:46:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosnf29496 for ; Tue, 10 Jun 2003 19:46:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosnf24758 for ; Tue, 10 Jun 2003 19:46:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosnf12950 for ; Tue, 10 Jun 2003 19:46:23 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQosnf12932 for ; Tue, 10 Jun 2003 19:46:22 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5AJkIg01878 for ; Tue, 10 Jun 2003 14:46:19 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10RL1Y>; Tue, 10 Jun 2003 21:46:17 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2E68@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: tnadeau@cisco.com, "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Tue, 10 Jun 2003 21:46:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk So if you have 3 application managing Label Space as in the following example. > > Application Incoming Labels Owned by Application > LDP { 15, 29, 45 } > VPN { 30, 31, 32 } > TE { 16, 17, 18 } > And then you have the object mplsInSegmentIndexNext How does that IndexNext object provide me with a proper new index value that I can use. Cause it does not know if I (as an application) want to create a new InSegment for LPD, VPN or TE... or does it? If it does, then I do not understand how. Maybe I missed the explanation in some text in the MIB document... if so, pls point me to it. Bert From owner-mpls@UU.NET Wed Jun 11 05:38:05 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00608 for ; Wed, 11 Jun 2003 05:38:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospi02478 for ; Wed, 11 Jun 2003 09:38:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQospi02365; Wed, 11 Jun 2003 09:38:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQosni21130 for mpls-outgoing; Tue, 10 Jun 2003 20:43:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosni20757 for ; Tue, 10 Jun 2003 20:30:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosnh09381 for ; Tue, 10 Jun 2003 20:29:58 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosnh14503 for ; Tue, 10 Jun 2003 20:29:58 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQosnh14498 for ; Tue, 10 Jun 2003 20:29:58 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id D03461531; Tue, 10 Jun 2003 16:29:57 -0400 (EDT) Message-ID: <026e01c32f8f$0f467390$681810ac@movaz.com> From: "Adrian Farrel" To: , "'Wijnen, Bert (Bert)'" , "'MPLS WG'" References: <00a401c32f8a$cc799be0$ed472ca1@amer.cisco.com> Subject: Re: prequeal to WG lat call om the LSR mib module Date: Tue, 10 Jun 2003 16:29:57 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Tom, This comes close to my question a little while back. The issue is not "How does the management application know what it is provisioning?", but "How does the device know what is being provisioned?" If you are saying - it knows it through some proprietary MIB field that people will add to the their own MIBs - this is fine, but I say let's add an explicit applicationIndex field that implementations can interpret freely. If you are saying - the application index is embedded in the inSegementIndex - I say this doesn't work because there is no way of communicating the requirements to the getNext object on a GET command. Adrian ----- Original Message ----- From: "Thomas D. Nadeau" To: "'Wijnen, Bert (Bert)'" ; "'MPLS WG'" Sent: Tuesday, June 10, 2003 3:59 PM Subject: RE: prequeal to WG lat call om the LSR mib module > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, June 10, 2003 3:46 PM > > To: tnadeau@cisco.com; 'MPLS WG' > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > So if you have 3 application managing Label Space as > > in the following example. > > > > > > Application Incoming Labels Owned by Application > > > LDP { 15, 29, 45 } > > > VPN { 30, 31, 32 } > > > TE { 16, 17, 18 } > > > > > And then you have the object mplsInSegmentIndexNext > > > > How does that IndexNext object provide me with a proper > > new index value that I can use. Cause it does not know > > if I (as an application) want to create a new InSegment > > for LPD, VPN or TE... or does it? If it does, then I > > do not understand how. Maybe I missed the explanation in > > some text in the MIB document... if so, pls point me to it. > > It knows because it knows which device it is > provisioning and thus knows what the application ID > values need to be (from its agent cap statement or > other documentation). I don't see this as a problem since > there is a whole slew of non-standard things that a > provisioning system needs to know about devices it > manages. In fact, I would bet that %100 of the implementations > out there will require some bit of proprietary MIB support > to facilitate provisioning of static LSPs via SNMP (if > they even will allow this). IMHO the fact that we have %90 > of what most people need is not too bad. > > --Tom > > From owner-mpls@UU.NET Wed Jun 11 05:45:12 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00709 for ; Wed, 11 Jun 2003 05:45:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospj17186 for ; Wed, 11 Jun 2003 09:45:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQospj17068; Wed, 11 Jun 2003 09:45:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQosno04341 for mpls-outgoing; Tue, 10 Jun 2003 22:14:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosno04334 for ; Tue, 10 Jun 2003 22:14:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosno18621 for ; Tue, 10 Jun 2003 22:13:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosno18945 for ; Tue, 10 Jun 2003 22:13:01 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQosno18919 for ; Tue, 10 Jun 2003 22:13:00 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5AMCvt12885 for ; Tue, 10 Jun 2003 17:12:57 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10RMKC>; Wed, 11 Jun 2003 00:12:56 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2E79@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: tnadeau@cisco.com, "'Wijnen, Bert (Bert)'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Wed, 11 Jun 2003 00:12:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > So if you have 3 application managing Label Space as > > in the following example. > > > > > > Application Incoming Labels Owned by Application > > > LDP { 15, 29, 45 } > > > VPN { 30, 31, 32 } > > > TE { 16, 17, 18 } > > > > > And then you have the object mplsInSegmentIndexNext > > > > How does that IndexNext object provide me with a proper > > new index value that I can use. Cause it does not know > > if I (as an application) want to create a new InSegment > > for LPD, VPN or TE... or does it? If it does, then I > > do not understand how. Maybe I missed the explanation in > > some text in the MIB document... if so, pls point me to it. > > It knows because it knows which device it is > provisioning and thus knows what the application ID > values need to be (from its agent cap statement or > other documentation). Sorry... I cannot understand. Your "it knows" is your agent, right? Your agent accoding to the above table supports 3 applications, namely LDP, VPN, TE. So your agent should accept rowCreates for each of those 3 apps. How does you agent know what application type label I want to setup with my next create? Your mplsInSegmentIndexNext will have to be a value that representes one of those 3 apps, right? What if I want to configure for the other app? You told me yourself (If I remember correctly) that you implemented this MIB module in read-only mode. In that case, this is not a problem, but when you support it in read-write mode... I still see the problem, not matter that you keep repeating that it is not problem in your view. Bert > I don't see this as a problem since > there is a whole slew of non-standard things that a > provisioning system needs to know about devices it > manages. In fact, I would bet that %100 of the implementations > out there will require some bit of proprietary MIB support > to facilitate provisioning of static LSPs via SNMP (if > they even will allow this). IMHO the fact that we have %90 > of what most people need is not too bad. > > --Tom > > > From owner-mpls@UU.NET Wed Jun 11 05:47:36 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00840 for ; Wed, 11 Jun 2003 05:47:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospj22428 for ; Wed, 11 Jun 2003 09:47:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQospj22187; Wed, 11 Jun 2003 09:47:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQosnl12715 for mpls-outgoing; Tue, 10 Jun 2003 21:23:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosnk24129 for ; Tue, 10 Jun 2003 21:00:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosnk10952 for ; Tue, 10 Jun 2003 21:00:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosnk04893 for ; Tue, 10 Jun 2003 21:00:11 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosnk04863 for ; Tue, 10 Jun 2003 21:00:10 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5AL06pi025619 for ; Tue, 10 Jun 2003 17:00:07 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id RAA07821 for ; Tue, 10 Jun 2003 17:00:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5AL06N21822 for mpls@uu.net; Tue, 10 Jun 2003 17:00:06 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosnj22322 for ; Tue, 10 Jun 2003 20:56:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosnj19460 for ; Tue, 10 Jun 2003 20:56:39 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosnj08062 for ; Tue, 10 Jun 2003 20:56:39 GMT Received: from sj-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-2.cisco.com [171.71.177.254]) id QQosnj08048 for ; Tue, 10 Jun 2003 20:56:38 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5AKuTCL029730; Tue, 10 Jun 2003 13:56:29 -0700 (PDT) Received: from tnadeauw2k ([161.44.71.237]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAA13649; Tue, 10 Jun 2003 16:56:27 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Adrian Farrel'" , "'Wijnen, Bert \(Bert\)'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Tue, 10 Jun 2003 16:56:24 -0400 Organization: Cisco Systems Message-ID: <00cf01c32f92$c0dc0040$ed472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <026e01c32f8f$0f467390$681810ac@movaz.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Tom, > > This comes close to my question a little while back. > The issue is not "How does the management application know > what it is provisioning?", but "How does the device know what > is being provisioned?" Simple, it knows the format of the index based on local information. This IMHO is no better than having an explicit application ID because the NMS still needs to know how that is encoded. The benefit of just having an opaque value again is that it is a LOCAL decision as to how to encode the application ID. If I only have 2 applications, I can just use 1 bit instead of 32, for instance, and reduce the over-all length of the indexes. > If you are saying - it knows it through some proprietary MIB > field that people will add to the their own MIBs - this is > fine, but I say let's add an explicit applicationIndex field > that implementations can interpret freely. Yes, this is what I was thinking sans the extra index. Implementations can have a proprietary "I want the next index from his application" variable to SET and lock so that the next read from the index next variable gets you the next one from the desired application's "bag" of labels. However, I don't think that having an applicationIdNext and an explicit application ID object in the LSR MIB is going to solve this problem or even help it much more than just using an octet string that an implementation can reveal the internal formatting of in its documentation. In fact I think that it is just going to complicate things in the LSR MIB and other MIBs like LDP that use the indexes from the LSR MIB. --Tom > If you are saying - the application index is embedded in the > inSegementIndex - I say this doesn't work because there is no > way of communicating the requirements to the getNext object > on a GET command. > Adrian > > ----- Original Message ----- > From: "Thomas D. Nadeau" > To: "'Wijnen, Bert (Bert)'" ; "'MPLS WG'" > > Sent: Tuesday, June 10, 2003 3:59 PM > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Tuesday, June 10, 2003 3:46 PM > > > To: tnadeau@cisco.com; 'MPLS WG' > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > So if you have 3 application managing Label Space as > > > in the following example. > > > > > > > > Application Incoming Labels Owned by Application > > > > LDP { 15, 29, 45 } > > > > VPN { 30, 31, 32 } > > > > TE { 16, 17, 18 } > > > > > > > And then you have the object mplsInSegmentIndexNext > > > > > > How does that IndexNext object provide me with a proper > > > new index value that I can use. Cause it does not know > > > if I (as an application) want to create a new InSegment > > > for LPD, VPN or TE... or does it? If it does, then I > > > do not understand how. Maybe I missed the explanation in > some text > > > in the MIB document... if so, pls point me to it. > > > > It knows because it knows which device it is > > provisioning and thus knows what the application ID > > values need to be (from its agent cap statement or > > other documentation). I don't see this as a problem since > there is a > > whole slew of non-standard things that a provisioning > system needs to > > know about devices it manages. In fact, I would bet that > %100 of the > > implementations out there will require some bit of proprietary MIB > > support to facilitate provisioning of static LSPs via SNMP (if > > they even will allow this). IMHO the fact that we have %90 > > of what most people need is not too bad. > > > > --Tom > > > > > > > From owner-mpls@UU.NET Wed Jun 11 05:50:10 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00911 for ; Wed, 11 Jun 2003 05:50:10 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospj27620 for ; Wed, 11 Jun 2003 09:50:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQospj27492; Wed, 11 Jun 2003 09:50:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQosoa10971 for mpls-outgoing; Wed, 11 Jun 2003 01:08:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosoa10964 for ; Wed, 11 Jun 2003 01:08:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosoa23242 for ; Wed, 11 Jun 2003 01:07:33 GMT From: jcucchiara@mindspring.com Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosoa10722 for ; Wed, 11 Jun 2003 01:07:31 GMT Received: from mclean.mail.mindspring.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mclean.mail.mindspring.net [207.69.200.57]) id QQosoa10644 for ; Wed, 11 Jun 2003 01:07:28 GMT Received: from dialup-67.75.23.218.dial1.boston1.level3.net ([67.75.23.218] helo=jluciani-laptop) by mclean.mail.mindspring.net with smtp (Exim 3.33 #1) id 19Pu52-0004rt-00; Tue, 10 Jun 2003 21:07:12 -0400 Message-Id: <3.0.1.32.20030610210802.0073f4d0@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 10 Jun 2003 21:08:02 -0400 To: Len Nieman , ccamp@ops.ietf.org Subject: Re: LMP-MIB Module Compile Test Cc: mpls@UU.NET In-Reply-To: <0HGA00165E8W93@pmismtp04.wcomnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Len, This issue is discussed from time to time on the "mibs" email list and you may want to take a look at those email archives, or post the question to that list. Here's more info about the "mibs" IETF email list: "A special mailing list has been created for generic/common MIB related discussions, mibs@ops.ietf.org. To subscribe, send email to mibs-request@ops.ietf.org with the word subscribe in the body. The mailing lists archives will be at ftp://ftp.psg.com/pub/lists/mibs* " I agree with you that there are extra steps (as you point out) to get the MIB to compile once it is abstracted from the draft. On the other hand, there are potential pitfalls with putting a sub-Id in the MIB draft. One of the issues is that the MIB, even though a draft document, gets coded it up this temporary sub-id even when you have a BIG disclaimer comment around the sub-Id, so this is one of the reasons that the XXX appears. -Joan At 06:23 PM 6/10/03 -0400, Len Nieman wrote: >For anyone interested, I ran a test compile of the LMP-MIB module >extracted from draft-ietf-ccamp-lmp-mib-06.txt. > >For the TE-LINK-STD-MIB "IMPORT" I used the module extracted from >draft-ietf-mpls-telink-mib-02.txt > >The tests were run using the MG-Soft compiler, version 4.0, build 459. > >There were only two minor problems due to "xxx" being used for values >with assignments pending from IANA. > >In the LMP-MIB module I had to manually change the "mib-2 xxx" to "mib-2 >113" here: > > DESCRIPTION > "Initial version published as RFC xxxx (to be assigned by RFC > Editor)" > ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can > -- be used in the interim) > >And in the TE-LINK-STD-MIB module I had to make a similar change of >"transmission xxx" to "transmission 114" here: > > DESCRIPTION > "Initial version published as RFC xxxx (to be assigned by RFC > Editor)" > ::= { transmission xxx } -- To be assigned by IANA (experimental 114 > -- can be used in the interim) > >With the "xxx"s out of the way, both modules compiled completed with no >errors or warnings. > >After looking through a number of other drafts, I see this "xxx" place >holder for numeric values is used quite a bit. > >It would be helpful, and cut down on the manual intervention needed to >run compile tests, if a numeric value (999?) were specifically defined as >"Pending assignment by IANA ("whatever ###" can be used in the interim)" >for use in draft documents. Any thoughts on that? > >Len Nieman > > > From owner-mpls@UU.NET Wed Jun 11 05:53:46 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00980 for ; Wed, 11 Jun 2003 05:53:46 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospj03856 for ; Wed, 11 Jun 2003 09:53:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQospj03599; Wed, 11 Jun 2003 09:53:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQosnp05261 for mpls-outgoing; Tue, 10 Jun 2003 22:26:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosnp05256 for ; Tue, 10 Jun 2003 22:26:29 GMT Received: from imr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosnp04334 for ; Tue, 10 Jun 2003 22:24:33 GMT Received: from pmismtp04.wcomnet.com by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp04.mcilink.com [166.38.62.39]) id QQosnp04324 for ; Tue, 10 Jun 2003 22:24:33 GMT Received: from CONVERSION-DAEMON.pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) id <0HGA00101E5G95@pmismtp04.wcomnet.com> for mpls@UU.NET; Tue, 10 Jun 2003 22:24:33 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGA00101E5G9E@pmismtp04.wcomnet.com> for mpls@UU.NET; Tue, 10 Jun 2003 22:24:33 +0000 (GMT) Received: from localHost ([166.34.21.45]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGA00164E8W93@pmismtp04.wcomnet.com>; Tue, 10 Jun 2003 22:24:32 +0000 (GMT) Date: Tue, 10 Jun 2003 18:23 -0400 (EDT) From: Len Nieman Subject: LMP-MIB Module Compile Test To: ccamp@ops.ietf.org Cc: mpls@UU.NET Message-id: <0HGA00165E8W93@pmismtp04.wcomnet.com> Organization: MCI X-Mailer: MailRoom for Internet v3.0d (www.SierraSol.com) Sender: owner-mpls@UU.NET Precedence: bulk For anyone interested, I ran a test compile of the LMP-MIB module extracted from draft-ietf-ccamp-lmp-mib-06.txt. For the TE-LINK-STD-MIB "IMPORT" I used the module extracted from draft-ietf-mpls-telink-mib-02.txt The tests were run using the MG-Soft compiler, version 4.0, build 459. There were only two minor problems due to "xxx" being used for values with assignments pending from IANA. In the LMP-MIB module I had to manually change the "mib-2 xxx" to "mib-2 113" here: DESCRIPTION "Initial version published as RFC xxxx (to be assigned by RFC Editor)" ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can -- be used in the interim) And in the TE-LINK-STD-MIB module I had to make a similar change of "transmission xxx" to "transmission 114" here: DESCRIPTION "Initial version published as RFC xxxx (to be assigned by RFC Editor)" ::= { transmission xxx } -- To be assigned by IANA (experimental 114 -- can be used in the interim) With the "xxx"s out of the way, both modules compiled completed with no errors or warnings. After looking through a number of other drafts, I see this "xxx" place holder for numeric values is used quite a bit. It would be helpful, and cut down on the manual intervention needed to run compile tests, if a numeric value (999?) were specifically defined as "Pending assignment by IANA ("whatever ###" can be used in the interim)" for use in draft documents. Any thoughts on that? Len Nieman From owner-mpls@UU.NET Wed Jun 11 07:17:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02588 for ; Wed, 11 Jun 2003 07:17:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospp25979 for ; Wed, 11 Jun 2003 11:17:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQospp25831; Wed, 11 Jun 2003 11:17:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQosnp04810 for mpls-outgoing; Tue, 10 Jun 2003 22:16:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosnp04803 for ; Tue, 10 Jun 2003 22:16:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosnp24907 for ; Tue, 10 Jun 2003 22:15:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosnp07701 for ; Tue, 10 Jun 2003 22:15:45 GMT Received: from auemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQosnp07674 for ; Tue, 10 Jun 2003 22:15:44 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5AMFfk13627 for ; Tue, 10 Jun 2003 17:15:42 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10RMKS>; Wed, 11 Jun 2003 00:15:40 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2E7A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: tnadeau@cisco.com, "'Adrian Farrel'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Wed, 11 Jun 2003 00:15:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk So Adrian understands the problem the same way I do it. And your solution that this NEEDS some proprietary MIB object or other mechanism to FIRST tell the agent that my next GET for the mplsInSegmentIndexNext is gonna be for a VPN segment is NOT ACCEPTABLE, at least not to me. I would be really surprised if other WG members buy such a (non-)solution. Thanks, Bert > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: dinsdag 10 juni 2003 22:56 > To: 'Adrian Farrel'; 'Wijnen, Bert (Bert)'; 'MPLS WG' > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > Tom, > > > > This comes close to my question a little while back. > > The issue is not "How does the management application know > > what it is provisioning?", but "How does the device know what > > is being provisioned?" > > Simple, it knows the format of the index based on > local information. This IMHO is no better than having > an explicit application ID because the NMS still needs to > know how that is encoded. The benefit of just having > an opaque value again is that it is a LOCAL decision as > to how to encode the application ID. If I only have 2 applications, > I can just use 1 bit instead of 32, for instance, and > reduce the over-all length of the indexes. > > > If you are saying - it knows it through some proprietary MIB > > field that people will add to the their own MIBs - this is > > fine, but I say let's add an explicit applicationIndex field > > that implementations can interpret freely. > > Yes, this is what I was thinking sans the extra index. > Implementations can have a proprietary "I want the next index from > his application" variable to SET and lock so that the next read from > the index next variable gets you the next one from the desired > application's "bag" of labels. However, I don't think that having > an applicationIdNext and an explicit application ID object in the LSR > MIB is going to solve this problem or even help it much more than > just using an octet string that an implementation can reveal the > internal formatting of in its documentation. In fact I think that it > is just going to complicate things in the LSR MIB and other > MIBs like LDP that use the indexes from the LSR MIB. > > --Tom > > > > If you are saying - the application index is embedded in the > > inSegementIndex - I say this doesn't work because there is no > > way of communicating the requirements to the getNext object > > on a GET command. > > > > > > Adrian > > > > ----- Original Message ----- > > From: "Thomas D. Nadeau" > > To: "'Wijnen, Bert (Bert)'" ; "'MPLS WG'" > > > > Sent: Tuesday, June 10, 2003 3:59 PM > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Tuesday, June 10, 2003 3:46 PM > > > > To: tnadeau@cisco.com; 'MPLS WG' > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > So if you have 3 application managing Label Space as > > > > in the following example. > > > > > > > > > > Application Incoming Labels Owned by Application > > > > > LDP { 15, 29, 45 } > > > > > VPN { 30, 31, 32 } > > > > > TE { 16, 17, 18 } > > > > > > > > > And then you have the object mplsInSegmentIndexNext > > > > > > > > How does that IndexNext object provide me with a proper > > > > new index value that I can use. Cause it does not know > > > > if I (as an application) want to create a new InSegment > > > > for LPD, VPN or TE... or does it? If it does, then I > > > > do not understand how. Maybe I missed the explanation in > > some text > > > > in the MIB document... if so, pls point me to it. > > > > > > It knows because it knows which device it is > > > provisioning and thus knows what the application ID > > > values need to be (from its agent cap statement or > > > other documentation). I don't see this as a problem since > > there is a > > > whole slew of non-standard things that a provisioning > > system needs to > > > know about devices it manages. In fact, I would bet that > > %100 of the > > > implementations out there will require some bit of > proprietary MIB > > > support to facilitate provisioning of static LSPs via SNMP (if > > > they even will allow this). IMHO the fact that we have %90 > > > of what most people need is not too bad. > > > > > > --Tom > > > > > > > > > > > > > > From owner-mpls@UU.NET Wed Jun 11 08:52:12 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07101 for ; Wed, 11 Jun 2003 08:52:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospv21570 for ; Wed, 11 Jun 2003 12:52:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQospv21416; Wed, 11 Jun 2003 12:52:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQospj16118 for mpls-outgoing; Wed, 11 Jun 2003 09:57:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQospj16113 for ; Wed, 11 Jun 2003 09:57:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQospj09397 for ; Wed, 11 Jun 2003 09:56:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospj16929 for ; Wed, 11 Jun 2003 09:56:50 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQospj16904 for ; Wed, 11 Jun 2003 09:56:49 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5B9ukt04258 for ; Wed, 11 Jun 2003 04:56:46 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10R4NS>; Wed, 11 Jun 2003 11:56:45 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501CD041F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Len Nieman , ccamp@ops.ietf.org Cc: mpls@UU.NET Subject: RE: LMP-MIB Module Compile Test Date: Wed, 11 Jun 2003 11:56:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Inline > -----Original Message----- > From: Len Nieman [mailto:Len.Nieman@mci.com] > Sent: woensdag 11 juni 2003 0:23 > To: ccamp@ops.ietf.org > Cc: mpls@UU.NET > Subject: LMP-MIB Module Compile Test > > > For anyone interested, I ran a test compile of the LMP-MIB module > extracted from draft-ietf-ccamp-lmp-mib-06.txt. > > For the TE-LINK-STD-MIB "IMPORT" I used the module extracted from > draft-ietf-mpls-telink-mib-02.txt > > The tests were run using the MG-Soft compiler, version 4.0, build 459. > > There were only two minor problems due to "xxx" being used for values > with assignments pending from IANA. > > In the LMP-MIB module I had to manually change the "mib-2 > xxx" to "mib-2 > 113" here: > > DESCRIPTION > "Initial version published as RFC xxxx (to be assigned by RFC > Editor)" > ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can > -- be used in the interim) > > And in the TE-LINK-STD-MIB module I had to make a similar change of > "transmission xxx" to "transmission 114" here: > > DESCRIPTION > "Initial version published as RFC xxxx (to be assigned by RFC > Editor)" > ::= { transmission xxx } -- To be assigned by IANA (experimental 114 > -- can be used in the interim) > > With the "xxx"s out of the way, both modules compiled > completed with no errors or warnings. > > After looking through a number of other drafts, I see this "xxx" place > holder for numeric values is used quite a bit. > Right... and that is what we WANT people to do!! > It would be helpful, and cut down on the manual intervention needed to > run compile tests, if a numeric value (999?) were specifically defined as > "Pending assignment by IANA ("whatever ###" can be used in the interim)" > for use in draft documents. Any thoughts on that? > Has been discussed a number of times... apparently there is no consensus on it... so we keep the manual tweaking that is needed. Not fun, but not that bad either, is it? Bert > Len Nieman > > > From owner-mpls@UU.NET Wed Jun 11 15:07:30 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22394 for ; Wed, 11 Jun 2003 15:07:28 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqu16446 for ; Wed, 11 Jun 2003 19:07:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosqu16305; Wed, 11 Jun 2003 19:07:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQosps19826 for mpls-outgoing; Wed, 11 Jun 2003 12:05:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosps19814 for ; Wed, 11 Jun 2003 12:05:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosps22559 for ; Wed, 11 Jun 2003 12:04:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosps06382 for ; Wed, 11 Jun 2003 12:04:06 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosps06365 for ; Wed, 11 Jun 2003 12:04:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5BC43pi027688 for ; Wed, 11 Jun 2003 08:04:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id IAA27194 for ; Wed, 11 Jun 2003 08:04:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5BC42106008 for mpls@uu.net; Wed, 11 Jun 2003 08:04:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQospr01221 for ; Wed, 11 Jun 2003 11:55:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQospr03451 for ; Wed, 11 Jun 2003 11:54:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospr19569 for ; Wed, 11 Jun 2003 11:54:49 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQospr19548 for ; Wed, 11 Jun 2003 11:54:48 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03858; Wed, 11 Jun 2003 07:54:47 -0400 (EDT) Message-Id: <200306111154.HAA03858@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-mib-11.txt Date: Wed, 11 Jun 2003 07:54:47 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani Filename : draft-ietf-mpls-ldp-mib-11.txt Pages : 132 Date : 2003-6-10 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-11.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: <2003-6-10111030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-10111030.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jun 11 19:27:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09225 for ; Wed, 11 Jun 2003 19:27:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosrl09337 for ; Wed, 11 Jun 2003 23:27:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosrl09201; Wed, 11 Jun 2003 23:26:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQosqe20953 for mpls-outgoing; Wed, 11 Jun 2003 15:02:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosqe20928 for ; Wed, 11 Jun 2003 15:01:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosqe08633 for ; Wed, 11 Jun 2003 15:00:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqe02765 for ; Wed, 11 Jun 2003 15:00:17 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosqe02690 for ; Wed, 11 Jun 2003 15:00:13 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BF0ALU008228 for ; Wed, 11 Jun 2003 11:00:10 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA14434 for ; Wed, 11 Jun 2003 11:00:09 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5BF09V14949 for mpls@uu.net; Wed, 11 Jun 2003 11:00:09 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosqc08549 for ; Wed, 11 Jun 2003 14:36:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosqc20731 for ; Wed, 11 Jun 2003 14:35:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqc28559 for ; Wed, 11 Jun 2003 14:35:01 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosqc28536 for ; Wed, 11 Jun 2003 14:35:00 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BEYvLU000377; Wed, 11 Jun 2003 10:34:57 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-153.cisco.com [10.86.242.153]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAA24571; Wed, 11 Jun 2003 10:34:56 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Choudhury, Sanjaya'" , Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTable] Date: Wed, 11 Jun 2003 10:34:47 -0400 Organization: Cisco Systems Message-ID: <00a801c33026$9ef78d20$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <313680C9A886D511A06000204840E1CF8F54CC@whq-msgusr-02.pit.comms.marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Choudhury, Sanjaya > Sent: Tuesday, June 10, 2003 12:06 PM > To: 'mpls@UU.NET' > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTable] > > > Hi! Few comments in-line regarding the indexing of the > mplsInSegmentTable > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Saturday, June 07, 2003 9:13 AM > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > Of Wijnen, Bert (Bert) > > > Sent: Friday, June 06, 2003 11:14 AM > > > To: MPLS WG > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > Application Incoming Labels Owned by Application > > LDP { 15, 29, 45 } > > VPN { 30, 31, 32 } > > TE { 16, 17, 18 } > > > > Using the original indexing of (ifIndex, mplsLabel) > > worked for the above example, but as VERY inefficient > > for a GetNext operation. Think about what happens when > > the manager issues a GetNext(14). In this case, I first > > have to visit each application and ask it if it has a > > label that is greater than 14. This costs O(N)* num appliations > > in the worse case. > > > Comments on the indexing of the mplsInSegmentTable: > > 1. O(N)*num-applications cost for a getNext() on > mplsInSegmentTable, appears to be an artifact > of specific agent implementations. [when the > underlying container is distributed.] > > 2. Description for the mplsInSegmentTable, points out > that the new indexing structure is designed to > handle multiple implementations. > > I think this is not a good idea to design MIB tables > to fit individual implementations. In my personal > opinion the original indexing for the > mplsInSegmentTable was more natural and appropriate. The problem with designing in the ideal is that real implementations will have issues with it. The IETF generally considers implementation and deployment experience highly over the ideal. I have provided some real world feedback that indicates that a single Unsigned32 index is insufficient. I also have about 300 customers that have provided me with the same feedback. I think that it has little to do with my specific style of implementation either (see below). > 3. It is true that there is always a memory and speed > tread-off in real world designs. However, this > tread-off should be a choice of the individual > implementations. Boxes with higher amount of > memory might choose an implementation approach > that provides relatively efficient GetNext(), even > with the original indexing (ifIndex,label) It is not that easy. If you look at a distributed label management versus one with single label mamanagement you will see that even in your ideal picture there are issues of finding labels based on a single, simple Unsigned32 when you consider how many operations it will take to find the labels. In the non-distributed method, implementations must either provide some hash function that maps the Unsigned32 to the internal data structure, use the actual label as the index (which doesn't work in the outsegment case), use a memory address or assign some other arbitrary GUID value to the entry. In all of these cases, GetNext operations will be at best O(N) and can multiples worse. This means that MIB Walks will be O(N^2) when you finally add things up. On a P router with 150k TFIB entries, this is a serious amount of time! Now consider the distributed approach. The analysis is much worse for distributed label management with a single Unsigned32. When doing a GetNext you need to make sure that each "bag" of labels doesn't have a better label than the one you currently have. This is probably an N^2 search when it is all said and done. This results in N^3 MIB Walks too, which is even worse. This has little to do with my specific implementation. Now consider using a larger opaque index such as the one I have proposed. This allows implementations to use the above indexing as I just described. If they want to use just 4 bytes, you get the EXACT same result and if your implementation can somehow do better than the results I showed above, then more power to it. Other implementations are however free to use more bytes to index if they need them to make the searches more efficient. I see real benefit in this -- like making the MIB useful versus useless. --Tom From owner-mpls@UU.NET Wed Jun 11 20:43:51 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10671 for ; Wed, 11 Jun 2003 20:43:50 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosrq03508 for ; Thu, 12 Jun 2003 00:43:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosrq03342; Thu, 12 Jun 2003 00:43:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQosqb08057 for mpls-outgoing; Wed, 11 Jun 2003 14:28:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosqb08052 for ; Wed, 11 Jun 2003 14:28:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosqb16471 for ; Wed, 11 Jun 2003 14:27:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqb20202 for ; Wed, 11 Jun 2003 14:27:08 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosqb20189 for ; Wed, 11 Jun 2003 14:27:08 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BER5LU027745 for ; Wed, 11 Jun 2003 10:27:05 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id KAA07415 for ; Wed, 11 Jun 2003 10:27:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5BER4G13393 for mpls@uu.net; Wed, 11 Jun 2003 10:27:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosqa03025 for ; Wed, 11 Jun 2003 14:04:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosqa01987 for ; Wed, 11 Jun 2003 14:02:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqa22602 for ; Wed, 11 Jun 2003 14:02:11 GMT Received: from sj-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-1.cisco.com [171.71.177.237]) id QQosqa22591 for ; Wed, 11 Jun 2003 14:02:10 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BE1lms009114; Wed, 11 Jun 2003 07:01:47 -0700 (PDT) Received: from tnadeauw2k (che-vpn-cluster-2-153.cisco.com [10.86.242.153]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAA23783; Wed, 11 Jun 2003 10:01:45 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , "'Adrian Farrel'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Wed, 11 Jun 2003 10:01:36 -0400 Organization: Cisco Systems Message-ID: <009901c33021$fcc44100$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC2E7A@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bert, Unless we standardize the formatting of the application ID index, you still have the same problem with Adrian's approach. In essence, you still need to know a) how the app IDs are assigned, and b) you need to tell the agent which app ID you want to get an index from BEFORE you do the row creation. Since we are spinning around in the mud on this, let me make a proposal that would make this problem go away. Lets make the LSR MIB entirely read-only. This way we can give it fast indexing for retrieval based on a single opaque octet string which not only gets you O(1) individual searches, but also O(1) MIB walks, and then let application-specific MIBs be created that are specific to the applications being provisioned, and provide the correct indexing for each application to do that provisioning there. We could then provide a mapping from there to the index used in the LSR MIB so that once a new label was provisioned, it can be associated with the opaque index used in the LSR MIB. We did this in the PWE3 WG for those MIBs, and it seems to make a lot of sense. In summary, let me give a quick example: LSR-MIB's inSegmentTable is indexed by the single octet string. If I want to provision a static label for a static LSP, I go to the MPLS-Static-Label-Prov MIB and create an entry based on ifIndex of 5, and IP destination prefix of 1.2.3.4. That entry once created, will be indexed by those items. It will also have an object (not an index) called MplsLsrInSegmentIndex that is populated by the agent, say to 0x050501020304 which can be used to cross-reference entries in the LSR MIB's mplsInSegmentTable. --Tom > So Adrian understands the problem the same way I do it. > And your solution that this NEEDS some proprietary > MIB object or other mechanism to FIRST tell the agent > that my next GET for the mplsInSegmentIndexNext is > gonna be for a VPN segment is NOT ACCEPTABLE, at least > not to me. I would be really surprised if other WG > members buy such a (non-)solution. > > Thanks, > Bert > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: dinsdag 10 juni 2003 22:56 > > To: 'Adrian Farrel'; 'Wijnen, Bert (Bert)'; 'MPLS WG' > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > Tom, > > > > > > This comes close to my question a little while back. > > > The issue is not "How does the management application know > > > what it is provisioning?", but "How does the device know what > > > is being provisioned?" > > > > Simple, it knows the format of the index based on > > local information. This IMHO is no better than having > > an explicit application ID because the NMS still needs to know how > > that is encoded. The benefit of just having an opaque value > again is > > that it is a LOCAL decision as to how to encode the > application ID. If > > I only have 2 applications, I can just use 1 bit instead of 32, for > > instance, and reduce the over-all length of the indexes. > > > > > If you are saying - it knows it through some proprietary MIB > > > field that people will add to the their own MIBs - this is > > > fine, but I say let's add an explicit applicationIndex field > > > that implementations can interpret freely. > > > > Yes, this is what I was thinking sans the extra index. > > Implementations can have a proprietary "I want the next index from > > his application" variable to SET and lock so that the next > read from > > the index next variable gets you the next one from the desired > > application's "bag" of labels. However, I don't think that having > > an applicationIdNext and an explicit application ID object > in the LSR > > MIB is going to solve this problem or even help it much more than > > just using an octet string that an implementation can reveal the > > internal formatting of in its documentation. In fact I > think that it > > is just going to complicate things in the LSR MIB and other > > MIBs like LDP that use the indexes from the LSR MIB. > > > > --Tom > > > > > > > If you are saying - the application index is embedded in the > > > inSegementIndex - I say this doesn't work because there is no > > > way of communicating the requirements to the getNext object > > > on a GET command. > > > > > > > > > > > Adrian > > > > > > ----- Original Message ----- > > > From: "Thomas D. Nadeau" > > > To: "'Wijnen, Bert (Bert)'" ; "'MPLS WG'" > > > > > > Sent: Tuesday, June 10, 2003 3:59 PM > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > Sent: Tuesday, June 10, 2003 3:46 PM > > > > > To: tnadeau@cisco.com; 'MPLS WG' > > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > > > So if you have 3 application managing Label Space as > > > > > in the following example. > > > > > > > > > > > > Application Incoming Labels Owned by Application > > > > > > LDP { 15, 29, 45 } > > > > > > VPN { 30, 31, 32 } > > > > > > TE { 16, 17, 18 } > > > > > > > > > > > And then you have the object mplsInSegmentIndexNext > > > > > > > > > > How does that IndexNext object provide me with a proper new > > > > > index value that I can use. Cause it does not know if > I (as an > > > > > application) want to create a new InSegment for LPD, VPN or > > > > > TE... or does it? If it does, then I do not understand how. > > > > > Maybe I missed the explanation in > > > some text > > > > > in the MIB document... if so, pls point me to it. > > > > > > > > It knows because it knows which device it is > > > > provisioning and thus knows what the application ID > values need to > > > > be (from its agent cap statement or other > documentation). I don't > > > > see this as a problem since > > > there is a > > > > whole slew of non-standard things that a provisioning > > > system needs to > > > > know about devices it manages. In fact, I would bet that > > > %100 of the > > > > implementations out there will require some bit of > > proprietary MIB > > > > support to facilitate provisioning of static LSPs via SNMP (if > > > > they even will allow this). IMHO the fact that we have > %90 of what > > > > most people need is not too bad. > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Wed Jun 11 20:45:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10716 for ; Wed, 11 Jun 2003 20:45:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosrr01173 for ; Thu, 12 Jun 2003 00:45:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosrr00936; Thu, 12 Jun 2003 00:45:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQosqd09281 for mpls-outgoing; Wed, 11 Jun 2003 14:45:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosqd09163 for ; Wed, 11 Jun 2003 14:45:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosqd19551 for ; Wed, 11 Jun 2003 14:45:01 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqc15319 for ; Wed, 11 Jun 2003 14:44:59 GMT Received: from jera.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQosqc15306 for ; Wed, 11 Jun 2003 14:44:59 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 7F2D116D2; Wed, 11 Jun 2003 10:44:58 -0400 (EDT) Message-ID: <035a01c33028$07732e80$681810ac@movaz.com> From: "Adrian Farrel" To: , "'Wijnen, Bert (Bert)'" , "'MPLS WG'" References: <009901c33021$fcc44100$6401a8c0@amer.cisco.com> Subject: Re: prequeal to WG lat call om the LSR mib module Date: Wed, 11 Jun 2003 10:44:57 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Tom wrote... > Since we are spinning around in the mud > on this, let me make a proposal that would > make this problem go away. Lets make > the LSR MIB entirely read-only. Yeah, right. Let's remove half the utrility of this MIB! There is valuable utility to write-access in the LSR MIB. Manually provisioned LSPs (PVC-style) are important in all networks, but especially in ATM and FR. If you talk to your transport people, they'll tell you that support for this function in the GMPLS/TDM/optical world is essential. This is a non-starter. We discussed the need for this MIB to have write access at least three years ago, and added it then. Adrian From owner-mpls@UU.NET Wed Jun 11 20:45:38 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10737 for ; Wed, 11 Jun 2003 20:45:38 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosrr01802 for ; Thu, 12 Jun 2003 00:45:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosrr01757; Thu, 12 Jun 2003 00:45:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQosqf00856 for mpls-outgoing; Wed, 11 Jun 2003 15:28:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosqf00850 for ; Wed, 11 Jun 2003 15:27:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosqf24573 for ; Wed, 11 Jun 2003 15:26:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqf13723 for ; Wed, 11 Jun 2003 15:26:40 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosqf08249 for ; Wed, 11 Jun 2003 15:24:12 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BFO3LU015830 for ; Wed, 11 Jun 2003 11:24:04 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA17691 for ; Wed, 11 Jun 2003 11:24:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5BFO3M16265 for mpls@uu.net; Wed, 11 Jun 2003 11:24:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQospy15922 for ; Wed, 11 Jun 2003 13:41:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQospy20107 for ; Wed, 11 Jun 2003 13:41:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQospy26804 for ; Wed, 11 Jun 2003 13:41:02 GMT Received: from avsmail.artel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.89.227.228]) id QQospy26781 for ; Wed, 11 Jun 2003 13:41:01 GMT Received: by AVSMAIL with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jun 2003 09:40:01 -0400 Message-ID: From: Joan Cucchiara x302 To: "'mpls@uu.net'" Cc: "'jcucchiara@mindspring.com'" , Joan Cucchiara x302 Subject: RE: I-D ACTION:draft-ietf-mpls-ldp-mib-11.txt Date: Wed, 11 Jun 2003 09:39:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Folks, The difference between this Version 11 and the prior draft is that STD is used. This should compile cleanly with the latest MPLS-TC-STD-MIB (draft-ietf-mpls-tc-mib-07.txt). Also, this version has also been updated with MOST of the comments from the last AD MIB review (see email posted to the MPLS WG on Friday, May 9th from Bert Wijnen, entitled "AD review of draft-ietf-mpls-ldp-mib-10.txt".) The exception is that comment #3 and the NIT regarding mplsLdpPeerTransportAddrType and mplsLdpPeerTransportAddr have not been addressed in Version 11. We would like to incorporate these as part of this last call. For your convenience, these are quoted here from that email: "3 I see: mplsFecAddrPrefixLength InetAddressPrefixLength, mplsFecAddrFamily InetAddressType, mplsFecAddr InetAddress, I believe that RFC3291 suggests to put InetAddressType BEFORE any objects that are to be intepreted within the context of the specific addressType. so the sequence should probaly be: mplsFecAddrFamily InetAddressType, mplsFecAddrPrefixLength InetAddressPrefixLength, mplsFecAddr InetAddress, I would also check the DESCRIPTION clauses with RFC3291. I am not so sure it is all in sync with prescriptions of RFC3291 I am specifically worried about the reference to RFC1700 (which is obsolete anyway, probably you better refer to http://www.iana.org/assignments/address-family-numbers if that is what you want). But is it not just IPv4 and IPv6 addresses that you support (at least that is what compliance seems to state? In the DESCRIPTION of PrefixLength I would change "If the value of the 'mplsFecType' is 'hostAddress(2)' then this object is undefined. Into either: "If the value of the 'mplsFecType' is 'hostAddress(2)' then the value of object is irrelevant and ignored. Or (maybe better, not sure): "If the value of the 'mplsFecType' is 'hostAddress(2)' then the value should be equal to the length of the address in mplsFecAddr. Also in that same DESCRIPTION clause: prefix matches all addresses. In this case the prefix MUST also be zero (i.e. 'mplsFecAddr' will have the value of zero.)" What is a "value of zero"? I think you mean zero length. But in order for that to be valid for mplsFecAddr, the mplsFecAddrFamily value should be zero (i.e. unknown). ... AND "I think that the DESCRIPTION for InetAddress object MUST contain the explanation how it is interpreted. The example in RFC3291 is so explicit and clear (or so I think). I also think that it is in fact an Internet address and not a transport address (the latter needs a port number too, does it not? see RFC3419) <...> If you do change this, pls check all your InetAddress objects" So, we will address these 2 issues as part of this last call. Thanks, -Joan > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > Title : Definitions of Managed > Objects for the Multiprotocol > Label Switching, Label Distribution Protocol > (LDP) > Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani > Filename : draft-ietf-mpls-ldp-mib-11.txt > Pages : 132 > Date : 2003-6-10 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes managed objects for the Multiprotocol > Label Switching, Label Distribution Protocol (LDP). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-11.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mpls-ldp-mib-11.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-11.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. > From owner-mpls@UU.NET Wed Jun 11 21:13:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11236 for ; Wed, 11 Jun 2003 21:13:18 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosrs22930 for ; Thu, 12 Jun 2003 01:13:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosrs22733; Thu, 12 Jun 2003 01:13:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQosqf00705 for mpls-outgoing; Wed, 11 Jun 2003 15:22:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosqf00700 for ; Wed, 11 Jun 2003 15:22:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosqf16667 for ; Wed, 11 Jun 2003 15:22:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqf03681 for ; Wed, 11 Jun 2003 15:22:13 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosqf03668 for ; Wed, 11 Jun 2003 15:22:07 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BFM3LU015193 for ; Wed, 11 Jun 2003 11:22:04 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA17547 for ; Wed, 11 Jun 2003 11:22:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5BFM3H16102 for mpls@uu.net; Wed, 11 Jun 2003 11:22:03 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosqd10210 for ; Wed, 11 Jun 2003 14:59:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosqd12655 for ; Wed, 11 Jun 2003 14:59:40 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqd01924 for ; Wed, 11 Jun 2003 14:59:39 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosqd01916 for ; Wed, 11 Jun 2003 14:59:39 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BExULU007851; Wed, 11 Jun 2003 10:59:30 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-153.cisco.com [10.86.242.153]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAA25136; Wed, 11 Jun 2003 10:59:29 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Adrian Farrel'" , "'Wijnen, Bert \(Bert\)'" , "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Wed, 11 Jun 2003 10:59:14 -0400 Organization: Cisco Systems Message-ID: <00ba01c3302a$0eeb57d0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <035a01c33028$07732e80$681810ac@movaz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Adrian Farrel [mailto:afarrel@movaz.com] > Sent: Wednesday, June 11, 2003 10:45 AM > To: tnadeau@cisco.com; 'Wijnen, Bert (Bert)'; 'MPLS WG' > Subject: Re: prequeal to WG lat call om the LSR mib module > > > Tom wrote... > > > Since we are spinning around in the mud > > on this, let me make a proposal that would > > make this problem go away. Lets make > > the LSR MIB entirely read-only. > > Yeah, right. > Let's remove half the utrility of this MIB! I disagree that half of its utility is in read-write access. Is anyone really using it for provisioning anyway? In the nearly 4 years that I have been working on this MIB I have been made aware of precisely 0 implementations that used it in a writable mode. If you have been, please stand up and be heard! > There is valuable utility to write-access in the LSR MIB. > Manually provisioned LSPs (PVC-style) are important in all > networks, but especially in ATM and FR. If you talk to your > transport people, they'll tell you that support for this > function in the GMPLS/TDM/optical world is essential. > > This is a non-starter. We discussed the need for this MIB to > have write access at least three years ago, and added it then. I am not disputing that provisioning functions are essential, but they are not possible in the LSR MIB without lots of other changes. Your proposal will not fix the provisioning issue you raised. Why don't we just punt on provisioning and re-visit the issue with a provisioning-specific MIB in the future that allows for specific per-application provisioning semantics? This is indeed at the heart of the issue you raise. This is perfectly acceptable too. The AD stated at a recent IETF meeting that it was indeed okay for WGs to produce read-only MIBs if there was consensus to do so. --Tom From owner-mpls@UU.NET Wed Jun 11 21:17:32 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11291 for ; Wed, 11 Jun 2003 21:17:32 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosrt00652 for ; Thu, 12 Jun 2003 01:17:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosrt00607; Thu, 12 Jun 2003 01:17:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQosqz24105 for mpls-outgoing; Wed, 11 Jun 2003 20:23:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosqy14640 for ; Wed, 11 Jun 2003 20:02:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosqy13423 for ; Wed, 11 Jun 2003 20:02:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosqy18835 for ; Wed, 11 Jun 2003 20:02:05 GMT Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQosqy18824 for ; Wed, 11 Jun 2003 20:02:04 GMT Received: from md6370exch004u.wins.lucent.com (h135-114-172-12.lucent.com [135.114.172.12]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5BK21A18071 for ; Wed, 11 Jun 2003 15:02:01 -0500 (CDT) Received: by md6370exch004u.nse.lucent.com with Internet Mail Service (5.5.2653.19) id <1HDZXXSZ>; Wed, 11 Jun 2003 16:02:00 -0400 Message-ID: <305D2EAC01C45448A7F3ECC487666F6C076569D7@md6370exch004u.nse.lucent.com> From: "Natale, Robert C (Bob)" To: tnadeau@cisco.com Cc: "'MPLS WG'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Wed, 11 Jun 2003 16:01:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, I appreciate your extensive implementation experience and your willingness to share your analysis with the group. However, I strongly support Adrian's position on the issue of read-write objects in this (and most other) MIB. The question "Is anyone really using it for provisioning anyway?" appears to be of the chicken/egg quandary type. Well, now we have a "chicken" (so to speak!) in SNMPv3...let's have it give birth to lots of useful agents and applications. The concept of producing a separate "Provisioning MIB" has its own merits when one means by that a higher-order MIB that would focus more on logical or service kinds of entities rather than specific transport level atomic objects. However, such an endeavor should not, IMHO, obviate the need for and value of Set-ability of appropriate objects in lower-order MIBs. Cheers, BobN -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, June 11, 2003 10:59 AM > -----Original Message----- > From: Adrian Farrel [mailto:afarrel@movaz.com] > Sent: Wednesday, June 11, 2003 10:45 AM > > Tom wrote... > > > Since we are spinning around in the mud > > on this, let me make a proposal that would > > make this problem go away. Lets make > > the LSR MIB entirely read-only. > > Yeah, right. > Let's remove half the utrility of this MIB! I disagree that half of its utility is in read-write access. Is anyone really using it for provisioning anyway? In the nearly 4 years that I have been working on this MIB I have been made aware of precisely 0 implementations that used it in a writable mode. If you have been, please stand up and be heard! > There is valuable utility to write-access in the LSR MIB. > Manually provisioned LSPs (PVC-style) are important in all > networks, but especially in ATM and FR. If you talk to your > transport people, they'll tell you that support for this > function in the GMPLS/TDM/optical world is essential. > > This is a non-starter. We discussed the need for this MIB to > have write access at least three years ago, and added it then. I am not disputing that provisioning functions are essential, but they are not possible in the LSR MIB without lots of other changes. Your proposal will not fix the provisioning issue you raised. Why don't we just punt on provisioning and re-visit the issue with a provisioning-specific MIB in the future that allows for specific per-application provisioning semantics? This is indeed at the heart of the issue you raise. This is perfectly acceptable too. The AD stated at a recent IETF meeting that it was indeed okay for WGs to produce read-only MIBs if there was consensus to do so. --Tom From owner-mpls@UU.NET Thu Jun 12 02:19:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27734 for ; Thu, 12 Jun 2003 02:19:50 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQossn08167 for ; Thu, 12 Jun 2003 06:19:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQossn08002; Thu, 12 Jun 2003 06:19:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQosry08765 for mpls-outgoing; Thu, 12 Jun 2003 02:37:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosry08760 for ; Thu, 12 Jun 2003 02:37:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosry08757 for ; Thu, 12 Jun 2003 02:37:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosry16326 for ; Thu, 12 Jun 2003 02:37:05 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosry16310 for ; Thu, 12 Jun 2003 02:37:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5C2b2pi006541 for ; Wed, 11 Jun 2003 22:37:02 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id WAA08782 for ; Wed, 11 Jun 2003 22:37:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5C2b1N28672 for mpls@uu.net; Wed, 11 Jun 2003 22:37:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosry08735 for ; Thu, 12 Jun 2003 02:36:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosry05777 for ; Thu, 12 Jun 2003 02:35:34 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosry01353 for ; Thu, 12 Jun 2003 02:35:34 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQosry01323 for ; Thu, 12 Jun 2003 02:35:33 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA14199; Wed, 11 Jun 2003 22:35:09 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200306120235.WAA14199@workhorse.fictitious.org> To: "Natale, Robert C (Bob)" cc: tnadeau@cisco.com, "'MPLS WG'" Reply-To: curtis@fictitious.org Subject: Re: prequeal to WG lat call om the LSR mib module In-reply-to: Your message of "Wed, 11 Jun 2003 16:01:59 EDT." <305D2EAC01C45448A7F3ECC487666F6C076569D7@md6370exch004u.nse.lucent.com> Date: Wed, 11 Jun 2003 22:35:09 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <305D2EAC01C45448A7F3ECC487666F6C076569D7@md6370exch004u.nse.lucent. com>, "Natale, Robert C (Bob)" writes: > Hi Tom, > > I appreciate your extensive implementation > experience and your willingness to share > your analysis with the group. However, I > strongly support Adrian's position on the > issue of read-write objects in this (and > most other) MIB. > > The question "Is anyone really using it > for provisioning anyway?" appears to be > of the chicken/egg quandary type. Well, > now we have a "chicken" (so to speak!) > in SNMPv3...let's have it give birth to > lots of useful agents and applications. > > The concept of producing a separate > "Provisioning MIB" has its own merits > when one means by that a higher-order > MIB that would focus more on logical > or service kinds of entities rather > than specific transport level atomic > objects. However, such an endeavor > should not, IMHO, obviate the need > for and value of Set-ability of > appropriate objects in lower-order MIBs. > > Cheers, > > BobN Bob, I've been on the provider side of this and quite a long time ago Bay networks made every aspect of their provisioning available in the MIB and we found that completely *unacceptable* for various technical reasons, some of which go away with SNMPv3, others which may not. Router configurations can be huge and changes need to be atomic. The old way to do this was to do sets, then gets to verify the sets. This was excruciatingly slow and was not atomic. Bulk sets may go a long way toward solving this. Even so, MIB dumps are barely human readable. There needs to be ways to generate configurations but also ways for operators to read and eaily understand the configuration and change them if needed. A read-write MIB is poorly suited for this. At this point I'm on the provider side of things and I'm not hearing anyone that is running a network saying they want to configure their network with SNMP. All our MIBs are read-only and no customer considers that a problem. Given that situation we don't care if the IETF is defining MIBs to be read-write or read-only. We are implementing them read-only, advising customers of that and not a single customer is complaining about it. If they complain, we'll change but they haven't. Curtis From owner-mpls@UU.NET Thu Jun 12 04:56:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01095 for ; Thu, 12 Jun 2003 04:56:35 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQossx11581 for ; Thu, 12 Jun 2003 08:56:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQossx11483; Thu, 12 Jun 2003 08:56:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQossw16014 for mpls-outgoing; Thu, 12 Jun 2003 08:30:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQossw16004 for ; Thu, 12 Jun 2003 08:30:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQossv29398 for ; Thu, 12 Jun 2003 08:29:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQossv15471 for ; Thu, 12 Jun 2003 08:29:07 GMT Received: from maild.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maild.telia.com [194.22.190.101]) id QQossv15447 for ; Thu, 12 Jun 2003 08:29:06 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maild.telia.com (8.12.9/8.12.9) with ESMTP id h5C8T5p4000685 for ; Thu, 12 Jun 2003 10:29:05 +0200 (CEST) X-Original-Recipient: Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h5C8T5c22579 for ; Thu, 12 Jun 2003 10:29:05 +0200 (CEST) Message-ID: <3EE838B7.5010302@pi.se> Date: Thu, 12 Jun 2003 10:24:23 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG Subject: WG lat call on LSR and LDP MIB modules - setting dates Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, the time for this wg call has been extended to June 24th noon CET. /Loa -------- Original Message -------- Subject: Re: WG lat call on LSR and LDP MIB modules - CORRECTION! Date: Tue, 10 Jun 2003 08:12:00 +0200 From: Loa Andersson To: MPLS WG CC: Loa Andersson , Bert Wijnen , Alex Zinin References: <3EE4F226.4030104@pi.se> All, a missundertanding between me and the authors resulted in that the wrong version of the LDP mib module was sent to this wg last call. THe correct version is this has just been sent for publication (and with a copy to the mailing list). My take is that we continue the wg last call as planned, but as soon as I see the LDP mib being published I will extend the last call period. This way will get both a head start and the required period of time. /Loa Loa Andersson wrote: > All, > > this is to initiate a two week wg last call on > > Multiprotocol Label Switching (MPLS) Label Switching > Router (LSR) Management Information Base > > > and > Definitions of Managed Objects for the Multiprotocol Label > Switching, Label Distribution Protocol (LDP) > > > this wg last call ends June 22nd, and is limited to the changes in the > IDs since the previous wg last call, as well as interdepencies between > the two mib modules and the mib modules listed below. > > For the LSR MIB please re-read the mail I sent to the list June 6 called > "prequeal to WG lat call om the LSR mib module" > (OK - my spelling, but admit that it is charming :) ) > > A usual silence will be understood as support, but this would not > necessarily stop you from giving positive comments. Please do. > > There are more MIB modules coming up for wg last call and that have been > through wg last call, all of those will have interdependencies. > > 1. the TC mib module are wg last called and updated, but waiting for the > others to be ready for IESG review > > 2. the TE link MIB module is in wg last call (to end June 13) > > 3. the management overview has been through wg lst call and has been > uppdated > > > Two other MIB modules are in the pipe and new version will be released > shortly > > 5. The TE mib module > 6. The FTN mib module > > It is important that we complete this process of reviewing and updtating > before the ID cut off date (June 30) for the Vienna meeting. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Thu Jun 12 08:03:05 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05357 for ; Thu, 12 Jun 2003 08:03:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQostk17793 for ; Thu, 12 Jun 2003 12:03:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQostk17703; Thu, 12 Jun 2003 12:03:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQosth20465 for mpls-outgoing; Thu, 12 Jun 2003 11:25:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosth20444 for ; Thu, 12 Jun 2003 11:24:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosth29682 for ; Thu, 12 Jun 2003 11:23:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosth07770 for ; Thu, 12 Jun 2003 11:23:06 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQosth07763 for ; Thu, 12 Jun 2003 11:23:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5CBN2pi023834 for ; Thu, 12 Jun 2003 07:23:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id HAA05122 for ; Thu, 12 Jun 2003 07:23:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5CBN2423128 for mpls@uu.net; Thu, 12 Jun 2003 07:23:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosth20373 for ; Thu, 12 Jun 2003 11:21:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosth26927 for ; Thu, 12 Jun 2003 11:19:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosth01970 for ; Thu, 12 Jun 2003 11:19:37 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQosth01956 for ; Thu, 12 Jun 2003 11:19:36 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03655; Thu, 12 Jun 2003 07:19:35 -0400 (EDT) Message-Id: <200306121119.HAA03655@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-restart-applic-01.txt Date: Thu, 12 Jun 2003 07:19:35 -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 Restart Mechanisms for the Label Distribution Protocol Author(s) : A. Farrel Filename : draft-ietf-mpls-ldp-restart-applic-01.txt Pages : 14 Date : 2003-6-11 Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to a minimum. Similarly, where MPLS is at the network edges (for example, in Provider Edge routers) system downtime must also be kept as small as possible. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including the switching hardware and the TCP stack are implementation specific. How the software module itself chooses to implement FT for the state created by the Label Distribution Protocol (LDP) is also implementation specific but there are several issues in the LDP specification in RFC 3036 'LDP Specification' that make it difficult to implement an FT LSR using the LDP protocols without some extensions to those protocols. Proposals have been made in 'Fault Tolerance for the Label Distribution Protocol (LDP)' [LDP-FT] and A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-applic-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-restart-applic-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-restart-applic-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: <2003-6-11134815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-restart-applic-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-restart-applic-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-11134815.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jun 12 14:52:16 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22790 for ; Thu, 12 Jun 2003 14:52:16 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosul07599 for ; Thu, 12 Jun 2003 18:52:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosul07472; Thu, 12 Jun 2003 18:52:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQostq06444 for mpls-outgoing; Thu, 12 Jun 2003 13:42:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQostq06435 for ; Thu, 12 Jun 2003 13:42:36 GMT Received: from imr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQostq14222 for ; Thu, 12 Jun 2003 13:40:46 GMT Received: from pmismtp05.wcomnet.com by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp05.mcilink.com [166.38.62.53]) id QQostq14198 for ; Thu, 12 Jun 2003 13:40:46 GMT Received: from CONVERSION-DAEMON.pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) id <0HGD00D01F6QNX@pmismtp05.wcomnet.com> for mpls@UU.NET; Thu, 12 Jun 2003 13:40:46 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGD00E01FBXDN@pmismtp05.wcomnet.com> for mpls@UU.NET; Thu, 12 Jun 2003 13:40:45 +0000 (GMT) Received: from localHost ([166.34.21.45]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGD00E03FBXBX@pmismtp05.wcomnet.com>; Thu, 12 Jun 2003 13:40:45 +0000 (GMT) Date: Thu, 12 Jun 2003 09:39 -0400 (EDT) From: Len Nieman Subject: Re: prequeal to WG lat call om the LSR mib module To: Curtis Villamizar Cc: "Natale, Robert C (Bob)" , tnadeau@cisco.com, Adrian Farrel , "'MPLS WG'" Message-id: <0HGD00E04FBXBX@pmismtp05.wcomnet.com> Organization: MCI X-Mailer: MailRoom for Internet v3.0d (www.SierraSol.com) Sender: owner-mpls@UU.NET Precedence: bulk Response 'in-line' >Date: Wed, 11 Jun 2003 22:35 -0400 (EDT) >From: Curtis Villamizar >To: "Natale, Robert C (Bob)" >CC: tnadeau@cisco.com, > 'MPLS WG' >Sender: owner-mpls@UU.NET >Reply-to: curtis@fictitious.org >Subject: Re: prequeal to WG lat call om the LSR mib module > > >In message <305D2EAC01C45448A7F3ECC487666F6C076569D7@md6370exch004u.nse.lucent. >com>, "Natale, Robert C (Bob)" writes: >> Hi Tom, >> >> I appreciate your extensive implementation >> experience and your willingness to share >> your analysis with the group. However, I >> strongly support Adrian's position on the >> issue of read-write objects in this (and >> most other) MIB. >> >> The question "Is anyone really using it >> for provisioning anyway?" appears to be >> of the chicken/egg quandary type. Well, >> now we have a "chicken" (so to speak!) >> in SNMPv3...let's have it give birth to >> lots of useful agents and applications. >> >> The concept of producing a separate >> "Provisioning MIB" has its own merits >> when one means by that a higher-order >> MIB that would focus more on logical >> or service kinds of entities rather >> than specific transport level atomic >> objects. However, such an endeavor >> should not, IMHO, obviate the need >> for and value of Set-ability of >> appropriate objects in lower-order MIBs. >> >> Cheers, >> >> BobN > > >Bob, > >I've been on the provider side of this and quite a long time ago Bay >networks made every aspect of their provisioning available in the MIB >and we found that completely *unacceptable* for various technical >reasons, some of which go away with SNMPv3, others which may not. > >Router configurations can be huge and changes need to be atomic. The >old way to do this was to do sets, then gets to verify the sets. This >was excruciatingly slow and was not atomic. Bulk sets may go a long >way toward solving this. Even so, MIB dumps are barely human >readable. There needs to be ways to generate configurations but also >ways for operators to read and eaily understand the configuration and >change them if needed. A read-write MIB is poorly suited for this. > >At this point I'm on the provider side of things and I'm not hearing >anyone that is running a network saying they want to configure their >network with SNMP. All our MIBs are read-only and no customer >considers that a problem. > >Given that situation we don't care if the IETF is defining MIBs to be >read-write or read-only. We are implementing them read-only, advising >customers of that and not a single customer is complaining about it. >If they complain, we'll change but they haven't. > >Curtis > Curtis, I'm on the 'transport side', as Adrian put it, and started in Frame Relay "back when" provisioning Bay BSN's by manually typing in 'set' commands. Even so, I have to agree with Adrian and Bob on this one. When all MIBs are only available as read-only, the network management solutions end up being vendor proprietory. Which means in a large multivendor network, the network management folks end up 'swivel chairing' between systems. This means additional training costs getting people up to speed on each system, additional development and licensing costs for proprietary APIs needed to build interfaces from order entry/automatic provisioning systems, and possibly additional hardware costs for the servers that the vendors solution has to reside on. Most of this can be avoided when MIBs are read-write. Using the MIBs allows a standard 'front end' to be built for the network managers, while vendor specific idiosyncrasies are handled in the background by the system. Actually, you seem to have provided the 'solution' in your last paragraph. Let the MIBs be read-write and if a provider wants to disable the write capability in their implementation, let them as long as they're up front with their customers about it. Len Nieman From owner-mpls@UU.NET Thu Jun 12 23:05:28 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06337 for ; Thu, 12 Jun 2003 23:05:26 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosvs09278 for ; Fri, 13 Jun 2003 03:05:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosvs09137; Fri, 13 Jun 2003 03:05:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQostr16008 for mpls-outgoing; Thu, 12 Jun 2003 13:53:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQostr14486 for ; Thu, 12 Jun 2003 13:53:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQostr01185 for ; Thu, 12 Jun 2003 13:52:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQostr21185 for ; Thu, 12 Jun 2003 13:52:45 GMT Received: from jera.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQostr21166 for ; Thu, 12 Jun 2003 13:52:44 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 9BFC314F8; Thu, 12 Jun 2003 09:52:43 -0400 (EDT) Message-ID: <03df01c330e9$e5c9d9b0$681810ac@movaz.com> From: "Adrian Farrel" To: "'mpls@uu.net'" Cc: "Joan Cucchiara x302" Subject: LDP MIB Nits Date: Thu, 12 Jun 2003 09:52:43 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Hi Joan, Good job with the LDP MIB. Here are a few very picky nits. Typos and some very trivial point. Cheers, Adrian Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are This reference is missing 3. Structure of the MIB This section describes the structure of the LDP MIB. # "module" 3.1. Overview [SNIP] The MPLS-LDP-MIB Module MUST be implemented and at least one of the Layer 2 MIB Modules MUST be implemented. # 'MUST be implemented' by whom? [SNIP] There are 2 Compliance statements for each MIB Module. One which is for FULL Compliance which includes configuration and monitoring via < SNMP. The other is a READ-ONLY Compliance which is only monitoring > SNMP. The other is a READ-ONLY Compliance which is only for monitoring ^^^ 3.4. Differences from the LDP Specification Currently, there are 3 differences between this specification and the LDP Specification. # give reference As previously mentioned, # Where? I don't find it. this MIB is almost entirely based on the LDP specification. The differences are < documented here in the hope to avoid any confusion between the two > documented here to avoid any confusion between the two documents. The first difference is that the LDP Entity Table contains some DEFVAL clauses which are not specified explicitly in the LDP Specification. These values, although not documented in the LDP Specification are widely used by existing LDP MIB implementations and thus, have been adopted within this MIB. # "module" Please note, they can < certainly be changed during row creation or a subsequent set request. > certainly be changed during row creation or a subsequent SET request. ^^^ 3.5. The MPLS-LDP-MIB Module This MIB Module contains objects which are common to all LDP implementations. This MIB Module MUST always be implemented along with one or more of the Layer 2 MIB Modules. NOTE, this table allows the Label Edge Router (LER) or the Label < Switching router (LSR) to initiate and/or receive requests to > Switching Router (LSR) to initiate and/or receive requests to ^ establish LDP sessions. As the LDP protocol distributes labels and establishes sessions with Peers most of the tables in this MIB are # "module" 3.5.1. The LDP Entity Table The MPLS-LDP-MIB provides objects to configure/set-up potential LDP sessions on a specific LSR. The mplsLdpEntityTable is used to configure potential LDP Sessions, where each row in the table represents a potential LDP Session. Each entry/row in this table represents a single LDP Entity. There is no maximum number of LDP Entities specified. However, there is an mplsLdpEntityIndexNext object which should be retrieved by the command generator prior to creating an LDP Entity. If the mplsLdpEntityIndexNext object is zero, this indicates that the LSR is not able to create another LDP Entity at that time. # There seems to be a contratiction between the last sentence of the 1st # paragraph and the first of the 2nd. Perhaps you could clarify. 3.5.1.1. Changing Values After Session Establishment [SNIP] and Session statistics (i.e. releveant row in the mplsLdpSesTable). Also, if the LSR MIB is implemented and the optional Mapping Table # "module" # give reference objects are implemented, then all information related to the LSPs in this session should be removed from these MIBs. [For more information # "module" 3.5.2. The LDP Entity Statistics Table The mplsLpdEntityStatsTable is a read-only table which contains statistical information related to failed attempts to establish sessions. Each row in this table is related to a single LDP entity < and this table AUGMENTS an mplsLdpEntityEntry. This table could be > and each mplsLpdEntityStatsEntry AUGMENTS an mplsLdpEntityEntry. This table could be # the table doesn't augment an entry # either the table augments a table, or an entry augments an entry 3.5.3. The LDP Peer Table [SNIP] The Peer Table information was placed in a separate table from the < Session information to allow for a more comprehensive and coherent > Session information to allow for a more comprehensive and coherent ^ 3.5.5. The LDP Session Statistics Table The MPLS LDP Session Stats Table is a read-only table which contains statistical information on sessions. # Say what it augments <3.5.6. The LDP Hello Adjacencies Table >3.5.6. The LDP Hello Adjacency Table ^ This is a table of all adjacencies between all LDP Entities and all LDP Peers. A Session may have one or more adjacencies. A session should not have zero adjacencies, because this indicates that the session has lost contact with the Peer. A session which has zero Hello Adjacencies should be eventually removed. # I don't think you should be allowed to say "eventually". # Can you qualify it? 3.5.7. The LDP LSP Table # In this section (and possibly elsewhere in the draft?) you use # "ingress label" and "egress label". This makes me nervous wrt LSPs # where ingress and egress are different things. Could you say # "incoming" and "outgoing" or 2input" and "output"? 3.5.9. The LDP Session Peer Address Table # Do you need 3.5.10 to discuss global objects? 3.6. LDP Notifications # I think this section would be enhanced by a note on control of # Notifications. I think Tom had some Boiler Plate (TM) about how # control is based within this MIB module, but I am really interested # in how I stop these Notifications (especially since it is not # a global object that you use. mplsLdpEntityIndex OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index is used as a secondary index to uniquely identify this row. Before creating a row in this table, the 'mplsLdpEntityIndexNext' object should be retrieved. That value should be used for the value of this index < when creating a row in this table. (NOTE: if a value > when creating a row in this table. NOTE: if a value ^ of zero (0) is retrieved, that indicates that no rows can be created in this table at this time. A secondary index (this object) is meaningful to some but not all, LDP implementations. For example < in an LDP implementation which uses PPP would > an LDP implementation which uses PPP would ^ mplsLdpEntityOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), enabled(2), disabled(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this LDP Entity." ::= { mplsLdpEntityEntry 5 } # I think one sentence explaining the meaning of unknown mplsLdpEntityInitSesThreshold OBJECT-TYPE SYNTAX Integer32(0..100) MAX-ACCESS read-create STATUS current DESCRIPTION "When attempting to establish a session with a given Peer, the given LDP Entity should send out the SNMP notification, 'mplsLdpInitSesThresholdExceeded', when the number of Session Initialization messages sent exceeds this threshold. The notification is used to notify an operator when this Entity and its Peer are possibily engaged in an endless sequence of messages as each NAKs the other's Initialization messages with Error Notification messages. Setting this threshold which triggers the notification is one way to notify the operator. A value of 0 (zero) for this object indicates that the threshold is infinity, thus the SNMP notification will never be generated." # Should the local count be reset when the Notification is sent? # In other words, one Notification per N attempts, or one for each # attempt after N? mplsLdpEntityLabelType OBJECT-TYPE SYNTAX MplsLdpLabelType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the optional parameters for the LDP Initialization Message. If the value is generic(1) then no optional parameters will be sent in the LDP Initialization message associated with this Entity. If the value is atmParameters(2) then a row must be created in the mplsLdpEntityAtmParms Table, which corresponds to this entry. If the value is frameRelayParameters(3) then < a row must be created in the mplsLdpEntityFrameRelayParms < Table, which corresponds to this entry." > a row must be created in the mplsLdpEntityFrameRelayTable, > which corresponds to this entry." mplsLdpEntityDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this entity's counters suffered a discontinuity. The relevant counters are the specific instances associated with this entity of < any Counter32, or Counter64 object contained > any Counter32 object contained # there are not 64 bit counters in the 'mplsLdpEntityStatsTable'. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { mplsLdpEntityEntry 21 } # Any reason why the discontinuity timer is here and not in the # augmentation? If so, perhaps state it? mplsLdpEntityStatsEntry OBJECT-TYPE SYNTAX MplsLdpEntityStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table contains statistical information about an LDP Entity. Some counters contained in a row are for fatal errors received during a former LDP Session associated with this entry. For example, < an Ldp Pdu received on a TCP connection during an > an LDP PDU received on a TCP connection during an ^^ ^^ LDP Session contains a fatal error. That error is counted here, because the session is terminated. < If the error is NOT fatal (i.e. and the Session > If the error is NOT fatal (i.e. the Session remains), then the error is counted in the mplsLdpSesStatsEntry." AUGMENTS { mplsLdpEntityEntry } ::= { mplsLdpEntityStatsTable 1 } mplsLdpEntityStatsSesAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total attempted sessions for this LDP Entity. # Is this a count of the total attempts (including success) or # the failures only? Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." ::= { mplsLdpEntityStatsEntry 1 } mplsLdpEntityStatsSesRejectedNoHelloErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the Session Rejected/No Hello Error Notification Messages sent or received by this LDP Entity. # Is there merit in bundling 'sent or received' together? # You do it for a bunch of errors and then after the errors # which can only be local detection of receipts, you have a # separate sent and receive counter for shutdown Notifications Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." ::= { mplsLdpEntityStatsEntry 2 } mplsLdpEntityStatsBadPduLengthErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION < "This object counts the number of Bad Pdu Length > "This object counts the number of Bad PDU Length ^^ mplsLdpPeerTransportAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address advertized by the peer < in the hello message or the Hello source address." > in the Hello Message or the Hello source address." ^ ^ REFERENCE "[RFC3036], LDP Specification, Section 2.5.2 Transport Connection Establishment and Section 3.5.2.1 Hello Message Procedures." ::= { mplsLdpPeerEntry 5 } -- -- The MPLS LDP Sessions Table -- mplsLdpSesTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpSesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Sessions between the LDP Entities and LDP Peers. Each row represents a single session." # Please comment that this augments the peer table ::= { mplsLdpSesObjects 3 } mplsLdpSesEntry OBJECT-TYPE SYNTAX MplsLdpSesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a single session between an LDP Entity and LDP Peer. The information contained in a row is read-only. Please note: the Path Vector Limit for the Session is the value which is configured in the corresponding mplsLdpEntityEntry. The Peer's Path Vector Limit is in noted in the mplsLdpPeerTable. Values which may differ from those configured are noted in the objects of this table, the mplsLdpAtmSesTable and the mplsLdpFrameRelaySesTable. A value will differ if it was negotiated between the Entity and the Peer. Values may or may not be negotiated. For example, if the values are the same then no negotiation takes place. If they are negotiated, then they may differ." AUGMENTS { mplsLdpPeerEntry } mplsLdpSesDiscontinuityTime OBJECT-TYPE # ditto the placement in the parent not the augment table mplsLdpSesStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpSesStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of statistics for Sessions between LDP Entities and LDP Peers." # plase say this augments (whatever it augments!) mplsLdpSesStatsUnkMesTypeErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Unknown Message Type < Errors detected during this session. > Errors detected by this LSR during this session. ^^^^^^^^^^^ Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpSesDiscontinuityTime." ::= { mplsLdpSesStatsEntry 1 } mplsLdpSesStatsUnkTlvErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Unknown TLV Errors < detected during this session. > detected by this LSR during this session. ^^^^^^^^^^^ Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpSessionDiscontinuityTime." ::= { mplsLdpSesStatsEntry 2 } mplsLdpHelloAdjacencyEntry OBJECT-TYPE SYNTAX MplsLdpHelloAdjacencyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row represents a single LDP Hello Adjacency. < An LDP Session can have one or more Hello adjacencies." > An LDP Session can have one or more Hello Adjacencies." ^ mplsLdpHelloAdjacencyHoldTimeRem OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining for this Hello Adjacency. This interval will change when the 'next' < Hello message which corresponds to this > Hello Message which corresponds to this ^ Hello Adjacency is received." ::= { mplsLdpHelloAdjacencyEntry 2 } mplsLdpHelloAdjacencyHoldTime OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Hello hold time which is negotiated between the Entity and the Peer. A value of 0 means the default, which is 15 seconds for Link Hellos and 45 seconds for Targeted Hellos. A value of 0xffff indicates an infinite hold time." # I may be wrong, but I think you need 0xffffffff, or should this be a # uint16? Or perhaps you need unit32 but values above 0xffff are not # valid? mplsInSegmentLdpLspTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsInSegmentLdpLspEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of LDP LSP's which map to the InSegment Table in the the LSR MIB's." # The LSR MIB's what? mplsInSegmentLdpLspEntry OBJECT-TYPE # Tom's new indexing scheme (if I don't kill him first!) mplsInSegmentLdpLspIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value associated with this LSP which has the same value as the mplsInSegmentIfIndex in the MPLS-LSR-MIB's mplsInSegmentTable." # Add note about the meaning of zero? mplsOutSegmentLdpLspTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsOutSegmentLdpLspEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of LDP LSP's which map to the InSegment Table in the the LSR MIB's." # The LSR MIB's what? mplsOutSegmentLdpLspEntry OBJECT-TYPE # Shouldn't be surprised if this indexing isn't broken, too mplsFecAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is the an address where the address type is specified by the 'mplsFecAddrFamily' object. This address is then used as either an address prefix, or as the host address as indicated by the 'mplsFecType' object. In other words, the FEC element is populated according to the Prefix FEC Element value encoding, or the Host Address FEC Element encoding." # Either this should default to zero (because prefix length defaults to # zero and you have stated a rule) or FecType should default to 'host' mplsFecStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' MAY allow write-access to any columnar objects in the row, except for setting the 'mplsFecRowStatus' to 'destroy(6)'." # indentation is wrong DEFVAL { nonVolatile } ::= { mplsFecEntry 6 } # I have an issue with your use of storage type, which differs from Tom's. # I have assumed that 'peranent' means that if I restart the agent, master # agent or LDP software, this configuration inforation should be restored. # You have made 'permanent' mean undeletable. # # I guess both are acceptable meanings, but probably only one is standard # usage within MIBs. One of you needs to conform with the other! # # This comment applies to every instance of storage type mplsFecRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. If the value of this object is 'active(1)', then none of the writable objects of this entry can be modified, except to set this object to 'destroy(6)'. # Why am I not allowed to transition a row to 'notInService'? # This comment applies to every instance of row status mplsLdpLspFecIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index is either the mplsInSegmentLdpLspIfIndex or the mplsOutSegmentLdpLspIfIndex as indicated by the mplsLdpLspFecSegment." # Comment special meaning of zero mplsLdpLspFecOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), inUse(2), notInUse(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the operational status of the FEC associated with LDP LSP. unknown(1) - this is a temporary state which may indicate the LSP-FEC association is in a state of transition. inUse(2) - the FEC associated with the LSP is currently being applied. notInUse(3) - the FEC associated with the LSP is not being applied. Eventually, this entry may be aged out." # There you go with "eventually" again :-) # But also, please say how you arrive at 'notInUse'. What does it mean? mplsLdpLspFecRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. If the value of this object is 'active(1)', then none of the writable objects of this entry can be modified. # The folowing text is confusing (to me). # I thought the relationship for FEC<-->LSP and LSP<-->Session # I'm not clear about how you describe FEC to session # If I've missed something, just ignore me (there really is no need # to explain LDP to me at this stage in my life :-) The Agent should delete this row when the Session ceases to exist. If an operator wants to associate the session with a different FEC, the recommended procedure is (as described in detail in the section entitled, 'Changing Values After Session Establishment', and again described in the DESCRIPTION clause of the mplsLdpEntityAdminStatus object) is to set the mplsLdpEntityAdminStatus to down, thereby explicitly causing a session to be torn down. This will also cause this entry to be deleted. Then, set the mplsLdpEntityAdminStatus to enable which enables a NEW session to be initiated. Once the session is initiated, an entry may be added to this table to associate the new session with a FEC." ::= { mplsLdpLspFecEntry 8 } mplsLdpPathVectorLimitMismatch NOTIFICATION-TYPE OBJECTS { mplsLdpEntityPathVectorLimit, mplsLdpPeerPathVectorLimit } STATUS current DESCRIPTION < "If this notification is enabled to generated, > "If this notification is enabled to be generated, ^^ # Please also say how it is enabled. # Same changes in all subsequent notifications 4.1. The MPLS-LDP-ATM-MIB Module This MIB Module MUST be supported if LDP uses ATM as the Layer 2 < media. There are three tables in this MIB Module. Two tables are > medium. There are three tables in this MIB Module. Two tables are ^^ for configuring LDP to use ATM. These tables are the mplsLdpEntityAtmParmsTable and the mplsLdpEntityAtmLabelRangeTable. The mplsLdpEntityAtmParmsTable provides a way to configure information which would be contained in the "Optional Parameter" portion of an LDP PDU Initialization Message. The mplsLdpEntityAtmLabelRangeTable provides a way to configure information which would be contained in the "ATM Label Range Components" portion of an LDP PDU Intialization Message, see [RFC3035] and [RFC3036]. # And the third table is...? mplsLdpEntityAtmTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpEntityAtmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION < "This table contains information about the < ATM specific information which could be used < in the 'Optional Parameters' and other ATM specific < information. > "This table contains ATM specific information which > could be used in the 'Optional Parameters' and other > ATM specific information. This table 'extends' the mplsLdpEntityTable when < ATM as the Layer 2 media." > ATM as the Layer 2 medium." ^^ mplsLdpEntityAtmIfIndexOrZero OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This value represents either the InterfaceIndex of the 'ifLayer' where the ATM Labels 'owned' by this entry were created, or 0 (zero). The value of zero means that the InterfaceIndex is not known. For example, if the InterfaceIndex is created subsequent to the ATM Label's creation, then it would not be known. # huh? Do you mean "subsequent to the creation of the ATM Labels"? mplsLdpEntityAtmRowStatus OBJECT-TYPE [SNIP] NOTE: This RowStatus object should have the same value of the 'mplsLdpEntityRowStatus' related to this entry." # upper case SHOULD # but, why have it? # alternatively make it a firm requirement that "agents that # change the setting of this object must make the identical change # the the value of mplsLdpEntityRowStatus" and place a similar # comment in the definition of mplsLdpEntityRowStatus ::= { mplsLdpEntityAtmEntry 11 } -- -- The MPLS LDP Entity ATM Label Range Table -- # Somewhere around here I got confused! # We have a count of AtmLRComponents which is SETable # So now I can have # - not enough corresponding entries in AtmSesTable # - enough objects in AtmSesTable, but the corresponding # objects in mplsLdpEntityAtmLRTable have rowSatuts # not active (or even don't exist!) # # I would suggest AtmLRComponents should be read-only # That probably covers it since you have dire warnings in # the rowStatus objects mplsLdpEntityAtmLREntry OBJECT-TYPE SYNTAX MplsLdpEntityAtmLREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the LDP Entity ATM Label Range Table. One entry in this table contains information on a single range of labels represented by the configured Upper and Lower Bounds VPI/VCI pairs. These are the same data used in the Initialization Message. NOTE: The ranges for a specific LDP Entity are UNIQUE and non-overlapping. For example, for a specific LDP Entity index, there could be one entry having LowerBound vpi/vci == 0/32, and UpperBound vpi/vci == 0/100, and a second entry for this same interface with LowerBound vpi/vci == 0/101 and UpperBound vpi/vci == 0/200. However, there could not be a third entry with LowerBound vpi/vci == 0/200 and UpperBound vpi/vci == 0/300 because this label range overlaps with the second entry (i.e. both entries now have 0/200). A row will not be created unless a unique and non-overlapping range is specified. Thus, row creation implies a one-shot row creation of LDP EntityID and LowerBound vpi/vci and UpperBound vpi/vci. At least one label range entry for a specific LDP Entity MUST include the default VPI/VCI values denoted in the LDP Entity Table." # One-shot always worries me because I spent too long living with # HP OpenView at a time when it could only touch one object at a # time. So... # What is wrong with allowing notReady row creation and # preventing overlap only at the time of setting rowStatus to # active? # Similarly, if I wanted to change a range, I could set it # notInService, cahnge the objects one at a time (during which time # it might overlap another rrange) and set it back to active when # I'm done. 4.2. The MPLS-LDP-FRAME-RELAY-MIB Module This MIB Module MUST be supported if LDP uses FRAME RELAY as the < Layer 2 media. There are three tables in this MIB Module. Two > Layer 2 medium. There are three tables in this MIB Module. Two ^^ tables are to configure LDP for using Frame Relay. These tables are < the mplsLdpEntityFrameRelayParmsTable and the < mplsLdpEntityFrameRelayLabelRangeTable. > the mplsLdpEntityFrameRelayTable and the > mplsLdpEntityFrameRelayLRTable. < The mplsLdpEntityFrameRelayParmsTable provides a way to configure > The mplsLdpEntityFrameRelayTable provides a way to configure information which would be contained in the "Optional Parameter" portion of an LDP PDU Initialization Message. < The mplsLdpEntityFrameRelayLabelRangeTable provides a way to > The mplsLdpEntityFrameRelayLRTable provides a way to configure information which would be contained in the "Frame Relay Label Range Components" portion of an LDP PDU Intialization Message, see [RFC3034] and [RFC3036]. # And the third table is...? 4.3. The MPLS-LDP-GENERIC-MIB Module This MIB Module MUST be supported if LDP uses a Per Platform Label Space. This MIB Module contains a Label Range (LR) table for < configuring Mpls Generic Label Ranges. This table is > configuring MPLS Generic Label Ranges. This table is ^^^^ < mplsLdpEntityGenericLabelRangeTable. Although the LDP Specification > mplsLdpEntityGenericLRTable. Although the LDP Specification does not provide a way for configuring Label Ranges for Generic Labels, the MIB does provide a way to reserve a range of generic labels because this was thought to be useful by the working group. mplsLdpEntityGenericIfIndexOrZero OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This value represents either the InterfaceIndex of the 'ifLayer' where these Generic Label would be created, or 0 (zero). The value of zero means that the InterfaceIndex is not known. For example, if the InterfaceIndex is created subsequent to the Generic Label's creation, then it would not be # as for previous tables known. However, if the InterfaceIndex is known, then it must be represented by this value. If an InterfaceIndex becomes known, then the network management entity (e.g. SNMP agent) responsible for this object MUST change the value from 0 (zero) to the value of the InterfaceIndex." ::= { mplsLdpEntityGenericLREntry 4 } 8. Informative References [SNIP] # I think this is normative for ifIndex [RFC2863] McCloghrie, K., F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2863, June 2000. [MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", draft-ietf- < mpls-mgmt-overview-03.txt, February 2003. > mpls-mgmt-overview-04.txt, April 2003. 9.1. Security Considerations for MPLS-LDP-MIB [SNIP] < Some of the readable objects in this MIB module "i.e., objects with a > Some of the readable objects in this MIB module i.e., "objects with a ^ ^ From owner-mpls@UU.NET Thu Jun 12 23:52:19 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07127 for ; Thu, 12 Jun 2003 23:52:18 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosvv26535 for ; Fri, 13 Jun 2003 03:52:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosvv26360; Fri, 13 Jun 2003 03:52:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQostr16446 for mpls-outgoing; Thu, 12 Jun 2003 13:55:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQostr16441 for ; Thu, 12 Jun 2003 13:55:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQostr05261 for ; Thu, 12 Jun 2003 13:54:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQostr06330 for ; Thu, 12 Jun 2003 13:54:51 GMT Received: from jera.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQostr06316 for ; Thu, 12 Jun 2003 13:54:51 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 3C705AF95 for ; Thu, 12 Jun 2003 09:54:51 -0400 (EDT) Message-ID: <03e501c330ea$31d48e40$681810ac@movaz.com> From: "Adrian Farrel" To: References: <200306121119.HAA03655@ietf.org> Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-restart-applic-01.txt Date: Thu, 12 Jun 2003 09:54:51 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk This revision addresses two nits from the AD prior to going to the IESG. 1. References and citations cleaned up. 2. IPR section modified. No change to the substance. Adrian ----- Original Message ----- From: Subject: I-D ACTION:draft-ietf-mpls-ldp-restart-applic-01.txt > 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. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-applic-01.txt From owner-mpls@UU.NET Thu Jun 12 23:55:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07236 for ; Thu, 12 Jun 2003 23:55:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosvv02789 for ; Fri, 13 Jun 2003 03:55:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosvv02623; Fri, 13 Jun 2003 03:55:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQosub05480 for mpls-outgoing; Thu, 12 Jun 2003 16:25:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosub05475 for ; Thu, 12 Jun 2003 16:25:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosub06714 for ; Thu, 12 Jun 2003 16:23:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosub06405 for ; Thu, 12 Jun 2003 16:23:23 GMT Received: from jera.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQosub06363 for ; Thu, 12 Jun 2003 16:23:22 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id B602287D8; Thu, 12 Jun 2003 12:23:21 -0400 (EDT) Message-ID: <041e01c330fe$f0eb6150$681810ac@movaz.com> From: "Adrian Farrel" To: "'mpls@uu.net'" Cc: "Thomas D. Nadeau" , "Wijnen, Bert (Bert)" Subject: Re: prequeal to WG lat call om the LSR mib module Date: Thu, 12 Jun 2003 12:23:21 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Talking with Tom about this off-line we arrived at the following (startling?) conclusion. > It would, however, appear that we have reached the nub of the matter. The > problem with the unformatted octet string aproach is in providing write access, > and (I'm guessing) the reason why this has become a hot debate is that I have > been looking to provide write access and you have not been very bothered by > whether that function works or not. > > > So, there's an easy answer... > People who use complex formatting of the octet string don't care about write > access. > People who use write access don't care about complex formatting of the octet > string. The suggestion we have is to add text (somewhere) to highlight this point. For example... > In systems that provide write access to the LSR MIB, the mplsIndexType > SHOULD be used as a simple multi-digit integer encoded as an octet string. > No further overloading of the meaning of an index SHOULD be made. The > mplsGetNextInSegmentIndex and similar objects should provide a > monotonic increasing value of indexes. > > In systems that do not offer write access to the LSR MIB, the > mplsIndexType may contain implicit formatting that is specific to the > implementation to convey additional information such as interface index, > physical card or device, or application id. The interpretation of this > additional formatting is implementation dependent and not covered in this > document. Such formatting MUST NOT impact the basic functionality of > read-only access to the LSR MIB by management applications that are > not aware of the formatting rules. This would address all of the issues about formating of the "index string". Adrian From owner-mpls@UU.NET Fri Jun 13 01:00:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08897 for ; Fri, 13 Jun 2003 01:00:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswa23598 for ; Fri, 13 Jun 2003 05:00:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoswa23425; Fri, 13 Jun 2003 05:00:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQosue26235 for mpls-outgoing; Thu, 12 Jun 2003 17:06:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosue26217 for ; Thu, 12 Jun 2003 17:06:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosue19107 for ; Thu, 12 Jun 2003 17:06:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosue12126 for ; Thu, 12 Jun 2003 17:06:05 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosue12113 for ; Thu, 12 Jun 2003 17:06:05 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5CH62LU021591 for ; Thu, 12 Jun 2003 13:06:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAA58076; Thu, 12 Jun 2003 13:06:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5CH62d10421 for mpls@uu.net; Thu, 12 Jun 2003 13:06:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosue20274 for ; Thu, 12 Jun 2003 17:03:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosue04825 for ; Thu, 12 Jun 2003 17:02:53 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosue29185 for ; Thu, 12 Jun 2003 17:02:52 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQosue29111 for ; Thu, 12 Jun 2003 17:02:50 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA19569; Thu, 12 Jun 2003 13:01:59 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200306121701.NAA19569@workhorse.fictitious.org> To: Len Nieman cc: Curtis Villamizar , "Natale, Robert C (Bob)" , tnadeau@cisco.com, Adrian Farrel , "'MPLS WG'" Reply-To: curtis@fictitious.org Subject: Re: prequeal to WG lat call om the LSR mib module In-reply-to: Your message of "Thu, 12 Jun 2003 09:39:00 EDT." <0HGD00E04FBXBX@pmismtp05.wcomnet.com> Date: Thu, 12 Jun 2003 13:01:59 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0HGD00E04FBXBX@pmismtp05.wcomnet.com>, Len Nieman writes: > Response 'in-line' > > >Date: Wed, 11 Jun 2003 22:35 -0400 (EDT) > >From: Curtis Villamizar > >To: "Natale, Robert C (Bob)" > >CC: tnadeau@cisco.com, > > 'MPLS WG' > >Sender: owner-mpls@UU.NET > >Reply-to: curtis@fictitious.org > >Subject: Re: prequeal to WG lat call om the LSR mib module > > > > > >In message <305D2EAC01C45448A7F3ECC487666F6C076569D7@md6370exch004u.nse.luce > nt. > >com>, "Natale, Robert C (Bob)" writes: > >> Hi Tom, > >> > >> I appreciate your extensive implementation > >> experience and your willingness to share > >> your analysis with the group. However, I > >> strongly support Adrian's position on the > >> issue of read-write objects in this (and > >> most other) MIB. > >> > >> The question "Is anyone really using it > >> for provisioning anyway?" appears to be > >> of the chicken/egg quandary type. Well, > >> now we have a "chicken" (so to speak!) > >> in SNMPv3...let's have it give birth to > >> lots of useful agents and applications. > >> > >> The concept of producing a separate > >> "Provisioning MIB" has its own merits > >> when one means by that a higher-order > >> MIB that would focus more on logical > >> or service kinds of entities rather > >> than specific transport level atomic > >> objects. However, such an endeavor > >> should not, IMHO, obviate the need > >> for and value of Set-ability of > >> appropriate objects in lower-order MIBs. > >> > >> Cheers, > >> > >> BobN > > > > > >Bob, > > > >I've been on the provider side of this and quite a long time ago Bay > >networks made every aspect of their provisioning available in the MIB > >and we found that completely *unacceptable* for various technical > >reasons, some of which go away with SNMPv3, others which may not. > > > >Router configurations can be huge and changes need to be atomic. The > >old way to do this was to do sets, then gets to verify the sets. This > >was excruciatingly slow and was not atomic. Bulk sets may go a long > >way toward solving this. Even so, MIB dumps are barely human > >readable. There needs to be ways to generate configurations but also > >ways for operators to read and eaily understand the configuration and > >change them if needed. A read-write MIB is poorly suited for this. > > > >At this point I'm on the provider side of things and I'm not hearing > >anyone that is running a network saying they want to configure their > >network with SNMP. All our MIBs are read-only and no customer > >considers that a problem. > > > >Given that situation we don't care if the IETF is defining MIBs to be > >read-write or read-only. We are implementing them read-only, advising > >customers of that and not a single customer is complaining about it. > >If they complain, we'll change but they haven't. > > > >Curtis > > > > Curtis, > > I'm on the 'transport side', as Adrian put it, and started in Frame > Relay "back when" provisioning Bay BSN's by manually typing in 'set' > commands. Even so, I have to agree with Adrian and Bob on this one. > > When all MIBs are only available as read-only, the network management > solutions end up being vendor proprietory. Which means in a large > multivendor network, the network management folks end up 'swivel > chairing' between systems. > > This means additional training costs getting people up to speed on each > system, additional development and licensing costs for proprietary APIs > needed to build interfaces from order entry/automatic provisioning > systems, and possibly additional hardware costs for the servers that the > vendors solution has to reside on. We were generating configs for gated, cisco and bay and it was far preferable to write a backend for three human readable config syntax than one MIB beside the problems with distributing MIB sets. I wrote this sort of code for a provider and the rtconfig tool set is such an example of a free tool for RPSL to various config syntax (Cisco, Juniper). In the router world the config syntax have not been that big and more than one is undesireable but preferable to MIBs. If anything I've seen more interest in the idea of configuring using XML, though no requests so far, than in configuring with MIBs. > Most of this can be avoided when MIBs are read-write. Using the MIBs > allows a standard 'front end' to be built for the network managers, > while vendor specific idiosyncrasies are handled in the background by > the system. > > Actually, you seem to have provided the 'solution' in your last paragraph. > Let the MIBs be read-write and if a provider wants to disable the write > capability in their implementation, let them as long as they're up front > with their customers about it. > > Len Nieman To be honest with you, I see by your signature that you're with MCI and there are other people in Worldcom that don't share your opinion on this. That is for Worldcom/MCI/UUNET to resolve. We speak here in the IETF as individuals and your opinion counts as much as anyone's. There seems to be two approaches to configuring ATM and FR service. One is to have an offline NMS set the low level switch mappings. Many providers with legacy ATM and FR switches seem to have done this. The preference among ISPs using MPLS has been to use dynamic routing and configure only the MPLS LSP requirements (constraints) at the ingress. Where we are now is providers want to offer ATM and FR service over MPLS and there are clearly two groups in many providers that are starting to do this. One group wants to set inseg/outseg with the MIB arguing that it is what they've always done. The other wants setup on the ingress and points out that ATM and FR will be a small minority of traffic and configuring the ingress has proven more reliable. Maybe you are right. The IETF can't decide that internal argument for the providers. For now the MIB needs to be read-write. Providers need to resolve this internally and tell their vendors whether they need read-write or read-only. This argument may go on as long as the cells vs packets argument that raged almost a decade ago. If it resolves as many of of think it will, we can go with read-only but at this point it is not resolved. Curtis From owner-mpls@UU.NET Fri Jun 13 01:20:16 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09331 for ; Fri, 13 Jun 2003 01:20:16 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswb19223 for ; Fri, 13 Jun 2003 05:20:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoswb19023; Fri, 13 Jun 2003 05:20:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQosts19562 for mpls-outgoing; Thu, 12 Jun 2003 14:12:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosts19557 for ; Thu, 12 Jun 2003 14:12:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosts18047 for ; Thu, 12 Jun 2003 14:11:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosts27647 for ; Thu, 12 Jun 2003 14:11:50 GMT Received: from peter.aprisma.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [207.3.151.142]) id QQosts27640 for ; Thu, 12 Jun 2003 14:11:49 GMT Received: from 192.168.11.57 by peter.aprisma.com (InterScan E-Mail VirusWall NT); Thu, 12 Jun 2003 10:10:04 -0400 Received: by amt-exc4.aprisma.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 10:11:03 -0400 Message-ID: From: "Shevenell, Michael (Mike)" To: "'tnadeau@cisco.com'" , "'Choudhury, Sanjaya'" , mpls@UU.NET Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Thu, 12 Jun 2003 10:11:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk As a provider of management solutions... We'd "prefer" to have a simple solution but we MUST have a working solution. Although the proposed change makes the instancing a bit more complex, the getnext performance of the current mplsXCTable is so slow that its practically unreadable in any reasonably sized network. Mike Shevenell Aprisma Management Technologies -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, June 11, 2003 10:35 AM To: 'Choudhury, Sanjaya'; mpls@UU.NET Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTable] > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Choudhury, Sanjaya > Sent: Tuesday, June 10, 2003 12:06 PM > To: 'mpls@UU.NET' > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTable] > > > Hi! Few comments in-line regarding the indexing of the > mplsInSegmentTable > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Saturday, June 07, 2003 9:13 AM > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > Of Wijnen, Bert (Bert) > > > Sent: Friday, June 06, 2003 11:14 AM > > > To: MPLS WG > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > stuff deleted... The problem with designing in the ideal is that real implementations will have issues with it. The IETF generally considers implementation and deployment experience highly over the ideal. I have provided some real world feedback that indicates that a single Unsigned32 index is insufficient. I also have about 300 customers that have provided me with the same feedback. I think that it has little to do with my specific style of implementation either (see below). more stuff deleted.. --Tom From owner-mpls@UU.NET Fri Jun 13 02:08:30 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18820 for ; Fri, 13 Jun 2003 02:08:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswe20247 for ; Fri, 13 Jun 2003 06:08:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoswe20109; Fri, 13 Jun 2003 06:08:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQosuh00135 for mpls-outgoing; Thu, 12 Jun 2003 17:48:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosuh00130 for ; Thu, 12 Jun 2003 17:48:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosuh21708 for ; Thu, 12 Jun 2003 17:48:11 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosuh06493 for ; Thu, 12 Jun 2003 17:48:11 GMT Received: from jera.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQosuh06482 for ; Thu, 12 Jun 2003 17:48:10 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 1837A174E; Thu, 12 Jun 2003 13:48:10 -0400 (EDT) Message-ID: <043401c3310a$c9c9b7a0$681810ac@movaz.com> From: "Adrian Farrel" To: "Shevenell, Michael (Mike)" Cc: "'mpls@uu.net'" References: Subject: Re: prequeal to WG lat call om the LSR mib module[mplsInSegmentTable] Date: Thu, 12 Jun 2003 13:48:09 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk > In our experience the getnext performance is > beyond slow. In some cases the response to the > first getnext doesn't return even after several > minutes (with the CPU at 100%). That is quite a few instructions (even on an 8086 clocked at 4 MHz :-) Sounds to me like it might be a bug. > My understanding > from following parts of this discussion was that > the poor performance was due to the indexing mechanism > in previous versions of the LSR MIB. Bad indexing can certainly make things worse. > So I'm in favor of "something" which > would make the reading feasible in our situation. Draft 10 proposed an > approach to improving this so I'm interested. > I can't personally comment on the comparison to ATM... Adrian From owner-mpls@UU.NET Fri Jun 13 02:09:17 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19607 for ; Fri, 13 Jun 2003 02:09:16 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswe21824 for ; Fri, 13 Jun 2003 06:09:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoswe21600; Fri, 13 Jun 2003 06:09:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQosub05745 for mpls-outgoing; Thu, 12 Jun 2003 16:29:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosub05737 for ; Thu, 12 Jun 2003 16:29:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosub28697 for ; Thu, 12 Jun 2003 16:29:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosub03759 for ; Thu, 12 Jun 2003 16:29:05 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQosub03742 for ; Thu, 12 Jun 2003 16:29:05 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 8DA1C152D; Thu, 12 Jun 2003 12:29:04 -0400 (EDT) Message-ID: <042401c330ff$bd4204c0$681810ac@movaz.com> From: "Adrian Farrel" To: "Shevenell, Michael (Mike)" Cc: "'mpls@uu.net'" References: Subject: Re: prequeal to WG lat call om the LSR mib module[mplsInSegmentTable] Date: Thu, 12 Jun 2003 12:29:04 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Hi Mike, > As a provider of management solutions... We'd "prefer" > to have a simple solution but we MUST have a working > solution. Although the proposed change makes the > instancing a bit more complex, the getnext performance > of the current mplsXCTable is so slow that its practically > unreadable in any reasonably sized network. Not sure what you're saying here with regard to the getnext performance. It is of the nature of a complex network (or more precisely, a busy switch) that it has a lot of cross-connect information. You want to read all of the information, but there is a lot of information. It would, presumably, be possible to aggregate the information so that it can be read in one block not row by row. Is this what you're talking about? How does this compare with your experience of using MIB modules to manage ATM equipment? Adrian From owner-mpls@UU.NET Fri Jun 13 02:17:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21968 for ; Fri, 13 Jun 2003 02:17:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswf06788 for ; Fri, 13 Jun 2003 06:17:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoswf06693; Fri, 13 Jun 2003 06:17:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQosuf28014 for mpls-outgoing; Thu, 12 Jun 2003 17:18:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosuf28005 for ; Thu, 12 Jun 2003 17:18:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosuf07237 for ; Thu, 12 Jun 2003 17:18:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosuf23364 for ; Thu, 12 Jun 2003 17:18:23 GMT Received: from peter.aprisma.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [207.3.151.142]) id QQosuf23326 for ; Thu, 12 Jun 2003 17:18:22 GMT Received: from 192.168.11.57 by peter.aprisma.com (InterScan E-Mail VirusWall NT); Thu, 12 Jun 2003 13:16:50 -0400 Received: by amt-exc4.aprisma.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 13:17:49 -0400 Message-ID: From: "Shevenell, Michael (Mike)" To: "'Adrian Farrel'" , "Shevenell, Michael (Mike)" Cc: "'mpls@uu.net'" Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Thu, 12 Jun 2003 13:17:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Adrian, In our experience the getnext performance is beyond slow. In some cases the response to the first getnext doesn't return even after several minutes (with the CPU at 100%). My understanding from following parts of this discussion was that the poor performance was due to the indexing mechanism in previous versions of the LSR MIB. So I'm in favor of "something" which would make the reading feasible in our situation. Draft 10 proposed an approach to improving this so I'm interested. I can't personally comment on the comparison to ATM... Mike -----Original Message----- From: Adrian Farrel [mailto:afarrel@movaz.com] Sent: Thursday, June 12, 2003 12:29 PM To: Shevenell, Michael (Mike) Cc: 'mpls@uu.net' Subject: Re: prequeal to WG lat call om the LSR mib module[mplsInSegmentTable] Hi Mike, > As a provider of management solutions... We'd "prefer" > to have a simple solution but we MUST have a working > solution. Although the proposed change makes the > instancing a bit more complex, the getnext performance > of the current mplsXCTable is so slow that its practically > unreadable in any reasonably sized network. Not sure what you're saying here with regard to the getnext performance. It is of the nature of a complex network (or more precisely, a busy switch) that it has a lot of cross-connect information. You want to read all of the information, but there is a lot of information. It would, presumably, be possible to aggregate the information so that it can be read in one block not row by row. Is this what you're talking about? How does this compare with your experience of using MIB modules to manage ATM equipment? Adrian From owner-mpls@UU.NET Fri Jun 13 02:19:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22252 for ; Fri, 13 Jun 2003 02:19:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswf13046 for ; Fri, 13 Jun 2003 06:19:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoswf12616; Fri, 13 Jun 2003 06:19:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQosul23477 for mpls-outgoing; Thu, 12 Jun 2003 18:53:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosul23470 for ; Thu, 12 Jun 2003 18:52:53 GMT Received: from imr3.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosul05075 for ; Thu, 12 Jun 2003 18:52:30 GMT Received: from pmismtp05.wcomnet.com by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp05.mcilink.com [166.38.62.53]) id QQosul05056 for ; Thu, 12 Jun 2003 18:52:30 GMT Received: from CONVERSION-DAEMON.pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) id <0HGD00201TKMVY@pmismtp05.wcomnet.com> for mpls@UU.NET; Thu, 12 Jun 2003 18:52:30 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGD00301TOPO2@pmismtp05.wcomnet.com> for mpls@UU.NET; Thu, 12 Jun 2003 18:52:30 +0000 (GMT) Received: from localHost ([166.34.21.45]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGD001HBTRFOO@pmismtp05.wcomnet.com>; Thu, 12 Jun 2003 18:52:28 +0000 (GMT) Date: Thu, 12 Jun 2003 14:50 -0400 (EDT) From: Len Nieman Subject: Re: prequeal to WG lat call om the LSR mib module To: Curtis Villamizar Cc: "Natale, Robert C (Bob)" , tnadeau@cisco.com, Adrian Farrel , "'MPLS WG'" Message-id: <0HGD001HCTRFOO@pmismtp05.wcomnet.com> Organization: MCI X-Mailer: MailRoom for Internet v3.0d (www.SierraSol.com) Sender: owner-mpls@UU.NET Precedence: bulk Inline: >Date: Thu, 12 Jun 2003 13:01 -0400 (EDT) >From: Curtis Villamizar >To: Len Nieman >CC: Curtis Villamizar , > "Natale, Robert C (Bob)" , > tnadeau@cisco.com, > Adrian Farrel , > 'MPLS WG' >Reply-to: curtis@fictitious.org >Original-recipient: rfc822;len.nieman@mci.com >Subject: Re: prequeal to WG lat call om the LSR mib module > >To be honest with you, I see by your signature that you're with MCI >and there are other people in Worldcom that don't share your opinion >on this. That is for Worldcom/MCI/UUNET to resolve. I'm very aware of that, and when I'm responding to a WG list I'm speaking strictly for myself. >We speak here in the IETF as individuals and your opinion counts as >much as anyone's. Thank you. Maybe I need to start including a "The opinions expressed are my own" disclaimer. >There seems to be two approaches to configuring ATM and FR service. >One is to have an offline NMS set the low level switch mappings. Many >providers with legacy ATM and FR switches seem to have done this. The >preference among ISPs using MPLS has been to use dynamic routing and >configure only the MPLS LSP requirements (constraints) at the ingress. >Where we are now is providers want to offer ATM and FR service over >MPLS and there are clearly two groups in many providers that are >starting to do this. One group wants to set inseg/outseg with the MIB >arguing that it is what they've always done. The other wants setup on >the ingress and points out that ATM and FR will be a small minority of >traffic and configuring the ingress has proven more reliable. It may sound weird, but I actually agree with both sides on this. At some point FR and ATM will become a small minority of traffic. But my opinion is that right now, across the board, there is a lot of customer and carrier capital money tied up in both. No one is going to just toss that investment out the window, it will attrit away over time as it becomes depreciated. Until then, there will still be a lot of FR and ATM being used to access MPLS networks. >Maybe you are right. And maybe not, it's just my opinion. >The IETF can't decide that internal argument for the providers. >For now the MIB needs to be read-write. Providers need to resolve >this internally and tell their vendors whether they need read-write >or read-only. Agreed. >This argument may go on as long as the cells vs packets argument >that raged almost a decade ago. I hope not! >If it resolves as many of us think it will, we can go with read-only, >but at this point it is not resolved. > >Curtis Time will tell. Len From owner-mpls@UU.NET Fri Jun 13 02:20:48 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22317 for ; Fri, 13 Jun 2003 02:20:47 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswf15119 for ; Fri, 13 Jun 2003 06:20:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoswf14838; Fri, 13 Jun 2003 06:20:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQosul23468 for mpls-outgoing; Thu, 12 Jun 2003 18:52:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosul23463 for ; Thu, 12 Jun 2003 18:52:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosul04222 for ; Thu, 12 Jun 2003 18:52:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosul14496 for ; Thu, 12 Jun 2003 18:52:17 GMT Received: from almso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQosul14482 for ; Thu, 12 Jun 2003 18:52:17 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5CIpV0Z016869 for ; Thu, 12 Jun 2003 14:52:13 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3EDE22A40031605C; Thu, 12 Jun 2003 14:52:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG lat call on LSR and LDP MIB modules - setting dates Date: Thu, 12 Jun 2003 13:52:14 -0500 Message-ID: <7AFE40EF30EE754DA967D1B5968457CA1370E8@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG lat call on LSR and LDP MIB modules - setting dates Thread-Index: AcMwvo69ayfmybo0R6SDCEKbpC4cTAANNqBQ From: "Lai, Wai S (Waisum), ALABS" To: "Loa Andersson" , "MPLS WG" Cc: "Chung, Li-Jin W, ALABS" , "Ash, Gerald R (Jerry), ALABS" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA22317 I would like to bring to your attention, once again, the requirements in http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt For the LDP and possibly the LSR MIBs, requirements are specified in the above I-D, which include, for example, requirements for performance and fault management so as to lessen dependence on the NMS. Such capabilities should be considered based on the requirements, and if appropriate, should be included in the appropriate MIBs. Thanks, Wai Sum -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, June 12, 2003 4:24 AM To: MPLS WG Subject: WG lat call on LSR and LDP MIB modules - setting dates Folks, the time for this wg call has been extended to June 24th noon CET. /Loa -------- Original Message -------- Subject: Re: WG lat call on LSR and LDP MIB modules - CORRECTION! Date: Tue, 10 Jun 2003 08:12:00 +0200 From: Loa Andersson To: MPLS WG CC: Loa Andersson , Bert Wijnen , Alex Zinin References: <3EE4F226.4030104@pi.se> All, a missundertanding between me and the authors resulted in that the wrong version of the LDP mib module was sent to this wg last call. THe correct version is this has just been sent for publication (and with a copy to the mailing list). My take is that we continue the wg last call as planned, but as soon as I see the LDP mib being published I will extend the last call period. This way will get both a head start and the required period of time. /Loa Loa Andersson wrote: > All, > > this is to initiate a two week wg last call on > > Multiprotocol Label Switching (MPLS) Label Switching > Router (LSR) Management Information Base > > > and > Definitions of Managed Objects for the Multiprotocol Label > Switching, Label Distribution Protocol (LDP) > > > this wg last call ends June 22nd, and is limited to the changes in the > IDs since the previous wg last call, as well as interdepencies between > the two mib modules and the mib modules listed below. > > For the LSR MIB please re-read the mail I sent to the list June 6 called > "prequeal to WG lat call om the LSR mib module" > (OK - my spelling, but admit that it is charming :) ) > > A usual silence will be understood as support, but this would not > necessarily stop you from giving positive comments. Please do. > > There are more MIB modules coming up for wg last call and that have been > through wg last call, all of those will have interdependencies. > > 1. the TC mib module are wg last called and updated, but waiting for the > others to be ready for IESG review > > 2. the TE link MIB module is in wg last call (to end June 13) > > 3. the management overview has been through wg lst call and has been > uppdated > > > Two other MIB modules are in the pipe and new version will be released > shortly > > 5. The TE mib module > 6. The FTN mib module > > It is important that we complete this process of reviewing and updtating > before the ID cut off date (June 30) for the Vienna meeting. > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Fri Jun 13 02:27:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22433 for ; Fri, 13 Jun 2003 02:27:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswf26693 for ; Fri, 13 Jun 2003 06:27:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoswf26651; Fri, 13 Jun 2003 06:27:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQosuy13066 for mpls-outgoing; Thu, 12 Jun 2003 22:01:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosuy11475 for ; Thu, 12 Jun 2003 22:01:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosuy25716 for ; Thu, 12 Jun 2003 22:00:48 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosuy14974 for ; Thu, 12 Jun 2003 22:00:47 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQosuy14964 for ; Thu, 12 Jun 2003 22:00:47 GMT Received: from md6370exch004u.wins.lucent.com (h135-114-172-12.lucent.com [135.114.172.12]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5CM0it05933 for ; Thu, 12 Jun 2003 17:00:44 -0500 (CDT) Received: by md6370exch004u.nse.lucent.com with Internet Mail Service (5.5.2653.19) id <1HDZYF2N>; Thu, 12 Jun 2003 18:00:43 -0400 Message-ID: <305D2EAC01C45448A7F3ECC487666F6C076AC74D@md6370exch004u.nse.lucent.com> From: "Natale, Robert C (Bob)" To: "Shevenell, Michael (Mike)" Cc: "'mpls@uu.net'" Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Thu, 12 Jun 2003 18:00:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Mike, I might taken this too far in the direction of issues for the "MIBs list" rather than this list...if so, let me know. Speaking w/o reference to any particular instance of anything: 1. A given MIB design may be less efficient than it could be, overall or wrt specific managed objects. That's true. 2. A given implementation of a MIB (aka, an agent) may be less efficient than it could be, overall or wrt specific managed objects and/or specific management operations. That's true much more frequently than #1 (in my judgment). 3. A given management application may be more or less efficient in its use of a MIB and/or SNMP, and/or may offer a UI that limits (or drives) its users to inefficient use of the tool. This is very frequently true, although there are notable examples of well-designed SNMP management applications too (and maybe a growing number of them). 4. As Adrian pointed out, even where all of the above factors may be highly efficient, external factors may impair perceived performance. While we would need to apply standard experimental controls to determine the cause of poor performance in a given case, I believe there is a prima facie case for saying that #2 and #3 are often the source of inefficient performance where SNMP and/or MIBs are (mistakenly) identified as the cause. Be that as it may, of course, I am all in favor of better designed MIBs and, more importantly (IMHO), MIBs that expose higher-order management capabilities to applications. The downside of that preference is that agent implementation will become even more critical. Cheers, BobN -----Original Message----- From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com] Sent: Thursday, June 12, 2003 1:18 PM Hi Adrian, In our experience the getnext performance is beyond slow. In some cases the response to the first getnext doesn't return even after several minutes (with the CPU at 100%). My understanding from following parts of this discussion was that the poor performance was due to the indexing mechanism in previous versions of the LSR MIB. So I'm in favor of "something" which would make the reading feasible in our situation. Draft 10 proposed an approach to improving this so I'm interested. I can't personally comment on the comparison to ATM... Mike -----Original Message----- From: Adrian Farrel [mailto:afarrel@movaz.com] Sent: Thursday, June 12, 2003 12:29 PM To: Shevenell, Michael (Mike) Cc: 'mpls@uu.net' Subject: Re: prequeal to WG lat call om the LSR mib module[mplsInSegmentTable] Hi Mike, > As a provider of management solutions... We'd "prefer" > to have a simple solution but we MUST have a working > solution. Although the proposed change makes the > instancing a bit more complex, the getnext performance > of the current mplsXCTable is so slow that its practically > unreadable in any reasonably sized network. Not sure what you're saying here with regard to the getnext performance. It is of the nature of a complex network (or more precisely, a busy switch) that it has a lot of cross-connect information. You want to read all of the information, but there is a lot of information. It would, presumably, be possible to aggregate the information so that it can be read in one block not row by row. Is this what you're talking about? How does this compare with your experience of using MIB modules to manage ATM equipment? Adrian From owner-mpls@UU.NET Fri Jun 13 15:56:39 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21239 for ; Fri, 13 Jun 2003 15:56:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosyh23309 for ; Fri, 13 Jun 2003 19:56:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosyh22999; Fri, 13 Jun 2003 19:56:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQoswn11825 for mpls-outgoing; Fri, 13 Jun 2003 08:23:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoswn11820 for ; Fri, 13 Jun 2003 08:23:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoswn22226 for ; Fri, 13 Jun 2003 08:21:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswn21044 for ; Fri, 13 Jun 2003 08:21:10 GMT Received: from sj-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-2.cisco.com [171.71.177.254]) id QQoswn21019 for ; Fri, 13 Jun 2003 08:21:09 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5D8L63p017796 for ; Fri, 13 Jun 2003 01:21:07 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAA85357; Fri, 13 Jun 2003 04:21:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5D8L5d25739 for mpls@uu.net; Fri, 13 Jun 2003 04:21:05 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoswm09749 for ; Fri, 13 Jun 2003 08:05:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoswm28112 for ; Fri, 13 Jun 2003 08:05:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoswm27314 for ; Fri, 13 Jun 2003 08:05:13 GMT Received: from albatross.tn.sw.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.49]) id QQoswm27303 for ; Fri, 13 Jun 2003 08:05:13 GMT Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5D85CG5025195 for ; Fri, 13 Jun 2003 10:05:12 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 13 Jun 2003 10:05:02 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F93D8DE@ESEALNT442.al.sw.ericsson.se> From: =?iso-8859-1?Q?Lars_Ernstr=F6m_=28EAB=29?= To: "'mpls@uu.net'" Date: Fri, 13 Jun 2003 10:04:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk unsubscribe From owner-mpls@UU.NET Fri Jun 13 17:25:09 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23709 for ; Fri, 13 Jun 2003 17:25:09 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosyn21899 for ; Fri, 13 Jun 2003 21:25:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQosyn21791; Fri, 13 Jun 2003 21:25:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQosxg11961 for mpls-outgoing; Fri, 13 Jun 2003 13:07:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosxg11954 for ; Fri, 13 Jun 2003 13:07:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosxg06854 for ; Fri, 13 Jun 2003 13:07:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosxg05184 for ; Fri, 13 Jun 2003 13:07:30 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQosxg05175 for ; Fri, 13 Jun 2003 13:07:29 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14820 for ; Fri, 13 Jun 2003 09:07:28 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA19983 for ; Fri, 13 Jun 2003 09:07:29 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 09:07:28 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0742CCE1@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: mpls@UU.NET Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Fri, 13 Jun 2003 09:07:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi! I am open to all changes that will make the MIB efficient for users, but I think it is not a bad idea to examine the alternative solutions. Here are some thoughts: Some of the cases, where NMS might use a GetNext() on mplsInSegment table: ------------------------------------------------- Case-1:: If the aim of the NMS is to get the next 'best/free' label, to configure the next mplsInSegment, then he may encounter a (potential) O(n) search of the mplsInSegmentTable. We can resolve this issue, by adding a new table: mplsNextFreeLabelTable [indexed by ifIndex] If ifIndex == 0 : the row indicates the next free platform-label-space label If ifIndex !=0 : the row indicates the next free interface-label-space label for the specified interface. This solution, will address the efficiency issue, without compromising the natural indexing of the mplsInSegmentTable. Case-2: If the aim of the NMS is to show/list all the incoming-mpls-segments, on a per-interface basis, the GetNext() works perfectly with the original indexing (ifIndex,label) Case-3: If the aim of the NMS is to show ALL the incoming segments or access ALL the incoming segments, he will need to walk the whole table and indexing does not matter. Thanks, sanjay > -----Original Message----- > From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com] > Sent: Thursday, June 12, 2003 10:11 AM > To: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTa ble] > > > As a provider of management solutions... We'd "prefer" > to have a simple solution but we MUST have a working > solution. Although the proposed change makes the > instancing a bit more complex, the getnext performance > of the current mplsXCTable is so slow that its practically > unreadable in any reasonably sized network. > > Mike Shevenell > Aprisma Management Technologies > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, June 11, 2003 10:35 AM > To: 'Choudhury, Sanjaya'; mpls@UU.NET > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTable] > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > Of Choudhury, Sanjaya > > Sent: Tuesday, June 10, 2003 12:06 PM > > To: 'mpls@UU.NET' > > Subject: RE: prequeal to WG lat call om the LSR mib > > module[mplsInSegmentTable] > > > > > > Hi! Few comments in-line regarding the indexing of the > > mplsInSegmentTable > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Saturday, June 07, 2003 9:13 AM > > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > -----Original Message----- > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > > Of Wijnen, Bert (Bert) > > > > Sent: Friday, June 06, 2003 11:14 AM > > > > To: MPLS WG > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > stuff deleted... > > The problem with designing in the ideal is that > real implementations will have issues with it. The > IETF generally considers implementation and deployment > experience highly over the ideal. I have provided some > real world feedback that indicates that a single Unsigned32 > index is insufficient. I also have about 300 customers > that have provided me with the same feedback. I think that > it has little to do with my specific style of implementation > either (see below). > more stuff deleted.. > > --Tom > > From owner-mpls@UU.NET Fri Jun 13 20:54:28 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00245 for ; Fri, 13 Jun 2003 20:54:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoszb00583 for ; Sat, 14 Jun 2003 00:54:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoszb00170; Sat, 14 Jun 2003 00:54:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQosxp04405 for mpls-outgoing; Fri, 13 Jun 2003 15:25:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosxp04398 for ; Fri, 13 Jun 2003 15:25:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosxp03551 for ; Fri, 13 Jun 2003 15:24:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosxp26018 for ; Fri, 13 Jun 2003 15:24:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQosxp26007 for ; Fri, 13 Jun 2003 15:24:06 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5DFO3LU001368 for ; Fri, 13 Jun 2003 11:24:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB00227; Fri, 13 Jun 2003 11:24:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5DFO2H15276 for mpls@uu.net; Fri, 13 Jun 2003 11:24:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQosxp04147 for ; Fri, 13 Jun 2003 15:19:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosxp29204 for ; Fri, 13 Jun 2003 15:18:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosxp00266 for ; Fri, 13 Jun 2003 15:18:08 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQosxp00219 for ; Fri, 13 Jun 2003 15:18:07 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA25614; Fri, 13 Jun 2003 11:17:14 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200306131517.LAA25614@workhorse.fictitious.org> To: "Shevenell, Michael (Mike)" cc: "'tnadeau@cisco.com'" , "'Choudhury, Sanjaya'" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] In-reply-to: Your message of "Thu, 12 Jun 2003 10:11:02 EDT." Date: Fri, 13 Jun 2003 11:17:14 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Shev enell, Michael (Mike)" writes: > As a provider of management solutions... We'd "prefer" > to have a simple solution but we MUST have a working > solution. Although the proposed change makes the > instancing a bit more complex, the getnext performance > of the current mplsXCTable is so slow that its practically > unreadable in any reasonably sized network. > > Mike Shevenell > Aprisma Management Technologies It may be that the only practical way to use the mplsInSegmentTable is in network verification tool in which an SNMP trace of a specific LSP is done. A reasonable strategy would be to trigger this form of traceroute (plus MPLS-ping if you wanted to verify forwarding too) any time a trap indicates the LSP may have rerouted, plus periodically. This assures that a low background of sanity checking is going on and that changes are checked promptly. I'm not sure that dumping the mplsXCTable makes a whole lot of sense in any practical context except if you are explicitly setting up inseg and outseg with the MIB which no one seems to be doing. If changes to the indexing of mplsInSegmentTable make it more difficult to do this form of traceroute, then we may need to go back to the Unsigned32 index. For the traceroute capabiility to work, there has to be a way to take the outgoing label out of the mplsOutSegmentTopLabel on the previous LSR and find the MplsInSegmentEntry on the next LSR. Have we broken this? If so that would be a problem. Curtis > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, June 11, 2003 10:35 AM > To: 'Choudhury, Sanjaya'; mpls@UU.NET > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTable] > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > Of Choudhury, Sanjaya > > Sent: Tuesday, June 10, 2003 12:06 PM > > To: 'mpls@UU.NET' > > Subject: RE: prequeal to WG lat call om the LSR mib > > module[mplsInSegmentTable] > > > > > > Hi! Few comments in-line regarding the indexing of the > > mplsInSegmentTable > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Saturday, June 07, 2003 9:13 AM > > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > -----Original Message----- > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > > Of Wijnen, Bert (Bert) > > > > Sent: Friday, June 06, 2003 11:14 AM > > > > To: MPLS WG > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > stuff deleted... > > The problem with designing in the ideal is that > real implementations will have issues with it. The > IETF generally considers implementation and deployment > experience highly over the ideal. I have provided some > real world feedback that indicates that a single Unsigned32 > index is insufficient. I also have about 300 customers > that have provided me with the same feedback. I think that > it has little to do with my specific style of implementation > either (see below). > more stuff deleted.. > > --Tom > > From owner-mpls@UU.NET Fri Jun 13 20:55:13 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00268 for ; Fri, 13 Jun 2003 20:55:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoszb02123 for ; Sat, 14 Jun 2003 00:55:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoszb02001; Sat, 14 Jun 2003 00:55:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQosxf13801 for mpls-outgoing; Fri, 13 Jun 2003 12:45:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQosxd12493 for ; Fri, 13 Jun 2003 12:24:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosxd05505 for ; Fri, 13 Jun 2003 12:23:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosxd05269 for ; Fri, 13 Jun 2003 12:23:09 GMT Received: from sj-core-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-5.cisco.com [171.71.177.238]) id QQosxd05241 for ; Fri, 13 Jun 2003 12:23:06 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5DCN2jc017734 for ; Fri, 13 Jun 2003 05:23:03 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAA89856; Fri, 13 Jun 2003 08:23:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5DCN1L06499 for mpls@uu.net; Fri, 13 Jun 2003 08:23:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosxb21844 for ; Fri, 13 Jun 2003 11:52:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosxb01208 for ; Fri, 13 Jun 2003 11:51:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosxb11236 for ; Fri, 13 Jun 2003 11:51:23 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQosxb10843 for ; Fri, 13 Jun 2003 11:51:16 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29062; Fri, 13 Jun 2003 07:51:14 -0400 (EDT) Message-Id: <200306131151.HAA29062@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-query-07.txt Date: Fri, 13 Jun 2003 07:51:14 -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 : Multi Protocol Label Switching Label Distribution Protocol Query Message Description Author(s) : P. Ashwood-Smith, A. Paraschiv Filename : draft-ietf-mpls-lsp-query-07.txt Pages : 19 Date : 2003-6-12 This document describes the encoding and procedures for three new Label Distribution Protocol (LDP) messages: Query Message, Query- Reply Message and Partial Query-Reply Message. A Label Edge Router (LER) sends a Query message when it needs to find out information about an established Label Switched Path (LSP). The Query message can be used for LDP LSPs as well as for Constraint-Based Label Switched Paths (CR-LSPs). The queried data is encoded into the Query-Reply messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-query-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-query-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-12132312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-query-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-query-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Jun 13 22:15:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02297 for ; Fri, 13 Jun 2003 22:15:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoszh27791 for ; Sat, 14 Jun 2003 02:15:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoszg27491; Sat, 14 Jun 2003 02:14:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQosye26468 for mpls-outgoing; Fri, 13 Jun 2003 19:03:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQosye26459 for ; Fri, 13 Jun 2003 19:03:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQosye18773 for ; Fri, 13 Jun 2003 19:02:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosye01502 for ; Fri, 13 Jun 2003 19:02:10 GMT Received: from sj-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-2.cisco.com [171.71.177.254]) id QQosye01471 for ; Fri, 13 Jun 2003 19:02:06 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5DJ233p029379 for ; Fri, 13 Jun 2003 12:02:04 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB12310; Fri, 13 Jun 2003 15:02:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5DJ22d26195 for mpls@uu.net; Fri, 13 Jun 2003 15:02:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosyc13875 for ; Fri, 13 Jun 2003 18:39:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQosyc20014 for ; Fri, 13 Jun 2003 18:38:29 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosyc06521 for ; Fri, 13 Jun 2003 18:38:28 GMT Received: from asgard.ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: asgard.ietf.org [132.151.6.40]) id QQosyc06473 for ; Fri, 13 Jun 2003 18:38:26 GMT Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19Qspn-0000Rd-3H for mpls@uu.net; Fri, 13 Jun 2003 13:59:31 -0400 To: IETF-Announce:; Dcc: all-ietf Cc: mpls@UU.NET From: The IESG Subject: Last Call: LDP DoD Graceful Restart to Draft Standard Reply-to: iesg@ietf.org Message-Id: Date: Fri, 13 Jun 2003 13:59:31 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --------------- The IESG has received a request from Multiprotocol Label Switching to consider the following Internet-Draft(s) as Draft Standard. o Multiprotocol Label Switching (MPLS): LDP DoD Graceful Restart Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by . Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.txt From owner-mpls@UU.NET Fri Jun 13 22:21:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02421 for ; Fri, 13 Jun 2003 22:21:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoszh08153 for ; Sat, 14 Jun 2003 02:21:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoszh08023; Sat, 14 Jun 2003 02:21:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQosyn22345 for mpls-outgoing; Fri, 13 Jun 2003 21:24:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQosyn22338 for ; Fri, 13 Jun 2003 21:24:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQosyn09847 for ; Fri, 13 Jun 2003 21:23:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQosyn18366 for ; Fri, 13 Jun 2003 21:23:16 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQosyn18326 for ; Fri, 13 Jun 2003 21:23:15 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 89E02178B; Fri, 13 Jun 2003 17:23:14 -0400 (EDT) Message-ID: <07b701c331f1$ffeeb820$681810ac@movaz.com> From: "Adrian Farrel" To: , Cc: References: Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard Date: Fri, 13 Jun 2003 17:23:14 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk With respect, this draft doesn't appear to have been through WG last call (unless I was sleeping, but I can't find any reference in the mail archive). It was only published as a WG draft on 5/7/2003 (despite carrying a date of February 2003). While I support the draft, I would like to see it discussed on the mailing list and go through WG last call. Thanks, Adrian ----- Original Message ----- From: "The IESG" To: Cc: Sent: Friday, June 13, 2003 1:59 PM Subject: Last Call: LDP DoD Graceful Restart to Draft Standard > --------------- > The IESG has received a request from Multiprotocol Label Switching to > consider the following Internet-Draft(s) as Draft Standard. > o Multiprotocol Label Switching (MPLS): LDP DoD Graceful Restart > > Draft Standard > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by . > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.txt > From owner-mpls@UU.NET Sat Jun 14 19:04:12 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07251 for ; Sat, 14 Jun 2003 19:04:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotcm29137 for ; Sat, 14 Jun 2003 23:04:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotcm29020; Sat, 14 Jun 2003 23:04:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQotcc16028 for mpls-outgoing; Sat, 14 Jun 2003 20:35:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotcc16010 for ; Sat, 14 Jun 2003 20:35:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotcc22382 for ; Sat, 14 Jun 2003 20:34:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotcc00652 for ; Sat, 14 Jun 2003 20:34:15 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQotcc00625 for ; Sat, 14 Jun 2003 20:34:14 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h5EKYDu58638; Sat, 14 Jun 2003 13:34:13 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h5EKYDV61548; Sat, 14 Jun 2003 13:34:13 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Sat, 14 Jun 2003 13:34:13 -0700 (PDT) From: Kireeti Kompella To: iesg@ietf.org cc: mpls@UU.NET Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard In-Reply-To: Message-ID: <20030614130420.V61438@kummer.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 13 Jun 2003, The IESG wrote: > The IESG has received a request from Multiprotocol Label Switching to > consider the following Internet-Draft(s) as Draft Standard. > o Multiprotocol Label Switching (MPLS): LDP DoD Graceful Restart > > Draft Standard Draft Standard? Or Proposed Standard? (It has already been pointed out that an MPLS WG Last Call for this doc has been skipped, but going straight to Draft Standard is a bit much.) > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by . "by ." ??? Kireeti. From owner-mpls@UU.NET Tue Jun 17 03:45:52 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02200 for ; Tue, 17 Jun 2003 03:45:51 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotlf17307 for ; Tue, 17 Jun 2003 07:45:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotlf16662; Tue, 17 Jun 2003 07:45:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQotij08423 for mpls-outgoing; Mon, 16 Jun 2003 13:27:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotij08416 for ; Mon, 16 Jun 2003 13:27:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotij18269 for ; Mon, 16 Jun 2003 13:26:34 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotij01491 for ; Mon, 16 Jun 2003 13:26:33 GMT Received: from tokyo.ccrle.nec.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQotij01470 for ; Mon, 16 Jun 2003 13:26:32 GMT Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5GDPlVI053180; Mon, 16 Jun 2003 15:25:49 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D2754A7802; Mon, 16 Jun 2003 15:11:48 +0200 (CEST) Date: Mon, 16 Jun 2003 15:25:45 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: "Choudhury, Sanjaya" , mpls@UU.NET Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Message-ID: <19790617.1055777145@[10.1.1.130]> In-Reply-To: <313680C9A886D511A06000204840E1CF0742CCE1@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0742CCE1@whq-msgusr-02.pit.comm s.marconi.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Case-2: If the aim of the NMS is to show/list all > the incoming-mpls-segments, on a per-interface basis, > the GetNext() works perfectly with the original indexing > (ifIndex,label) With the currently proposed Indexing this seams not be easily possible to do anymore (and it has nothing to do with provisioning). Sure you can read the full table. > > Case-3: If the aim of the NMS is to show ALL the > incoming segments or access ALL the incoming > segments, he will need to walk the whole table > and indexing does not matter. Exactly. Marcus > > Thanks, > sanjay > > > >> -----Original Message----- >> From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com] >> Sent: Thursday, June 12, 2003 10:11 AM >> To: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET >> Subject: RE: prequeal to WG lat call om the LSR mib >> module[mplsInSegmentTa ble] >> >> >> As a provider of management solutions... We'd "prefer" >> to have a simple solution but we MUST have a working >> solution. Although the proposed change makes the >> instancing a bit more complex, the getnext performance >> of the current mplsXCTable is so slow that its practically >> unreadable in any reasonably sized network. >> >> Mike Shevenell >> Aprisma Management Technologies >> >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Wednesday, June 11, 2003 10:35 AM >> To: 'Choudhury, Sanjaya'; mpls@UU.NET >> Subject: RE: prequeal to WG lat call om the LSR mib >> module[mplsInSegmentTable] >> >> > -----Original Message----- >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf >> > Of Choudhury, Sanjaya >> > Sent: Tuesday, June 10, 2003 12:06 PM >> > To: 'mpls@UU.NET' >> > Subject: RE: prequeal to WG lat call om the LSR mib >> > module[mplsInSegmentTable] >> > >> > >> > Hi! Few comments in-line regarding the indexing of the >> > mplsInSegmentTable >> > >> > > -----Original Message----- >> > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> > > Sent: Saturday, June 07, 2003 9:13 AM >> > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' >> > > Subject: RE: prequeal to WG lat call om the LSR mib module >> > > > -----Original Message----- >> > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf >> > > > Of Wijnen, Bert (Bert) >> > > > Sent: Friday, June 06, 2003 11:14 AM >> > > > To: MPLS WG >> > > > Subject: RE: prequeal to WG lat call om the LSR mib module >> > > > >> > > >> > >> > >> > stuff deleted... >> >> The problem with designing in the ideal is that >> real implementations will have issues with it. The >> IETF generally considers implementation and deployment >> experience highly over the ideal. I have provided some >> real world feedback that indicates that a single Unsigned32 >> index is insufficient. I also have about 300 customers >> that have provided me with the same feedback. I think that >> it has little to do with my specific style of implementation >> either (see below). >> more stuff deleted.. >> >> --Tom >> >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From owner-mpls@UU.NET Tue Jun 17 03:50:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02275 for ; Tue, 17 Jun 2003 03:50:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotlf28867 for ; Tue, 17 Jun 2003 07:50:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotlf28135; Tue, 17 Jun 2003 07:49:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQotil09337 for mpls-outgoing; Mon, 16 Jun 2003 13:48:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotil09323 for ; Mon, 16 Jun 2003 13:48:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotil29141 for ; Mon, 16 Jun 2003 13:46:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotil14824 for ; Mon, 16 Jun 2003 13:46:55 GMT Received: from tokyo.ccrle.nec.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQotil14799 for ; Mon, 16 Jun 2003 13:46:54 GMT Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5GDbWVI053810; Mon, 16 Jun 2003 15:37:33 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 48CB4A70A1; Mon, 16 Jun 2003 15:23:34 +0200 (CEST) Date: Mon, 16 Jun 2003 15:37:31 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Loa Andersson , MPLS WG Cc: "Thomas D. Nadeau" , Bert Wijnen Subject: Re: prequeal to WG lat call om the LSR mib module Message-ID: <20496282.1055777851@[10.1.1.130]> In-Reply-To: <3EE03D0E.3000809@pi.se> References: <3EE03D0E.3000809@pi.se> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > The items are: > > 1) The indexing of the in/out/XC > tables has changed from Unsigned32s > to Octet Strings of up to 24 bytes > in length. > I find the 24 byte octet string as index really wired. The Unsigned32 was exactly the right thing for me. So I can not support the change. > The reason this was done was to facilitate > LSRs that support multiple applications of > MPLS in a distribute fashion. Use of a > flat 32 bit indexing space on these platforms > ends up with VERY slot N^2+ GetNext searches > due to the fact that labels are distributed > among different applications. The GetNext > routine must then query each application's > "bag" of labels to determine the next index. > This sounds like a problem of information management on the box and has IMHO nothing to do with a MIB design to be useful for Management Applications. Indexing always has implications on sorting in the management application. If the sorting based on different applications is needed I would favor the approach with an app index. I assume the app index will be coded into the 24 octet string anyway so why not making it explicit? > This change is compatible with implementations > that wish to remain with the 4 byte indexing; > they just use a 4 byte octet string, while others > are free to use the more specific indexing. Sounds like an offer for incompatible implementations. > 2) The addition of a RowPointer to the in/out/label > stack tables to support "long" or GMPLS-style > labels. The RowPointer is normally set to zeroDotZero > except when the MIB needs to refer to an external > table that defines labels that exceed the 32bits > of space alloted in the tables today. This > in essence, future-proofs the MIB and makes > it compatible immediately with the GMPLS MIBs > defined in CCAMP. I like this approach the most from the three listed by Adrian some time ago. All have some problems, but this one works for me. Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From owner-mpls@UU.NET Tue Jun 17 03:59:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02595 for ; Tue, 17 Jun 2003 03:59:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotlf26474 for ; Tue, 17 Jun 2003 07:59:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotlf26083; Tue, 17 Jun 2003 07:59:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQotil09273 for mpls-outgoing; Mon, 16 Jun 2003 13:46:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotil09186 for ; Mon, 16 Jun 2003 13:45:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotik21958 for ; Mon, 16 Jun 2003 13:43:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotik07659 for ; Mon, 16 Jun 2003 13:43:35 GMT Received: from tokyo.ccrle.nec.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQotik07612 for ; Mon, 16 Jun 2003 13:43:33 GMT Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5GDhLVI054218; Mon, 16 Jun 2003 15:43:22 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 706EFAA9FF; Mon, 16 Jun 2003 15:29:23 +0200 (CEST) Date: Mon, 16 Jun 2003 15:43:20 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Loa Andersson , MPLS WG , Bert Wijnen , Alex Zinin Subject: Re: WG lat call on LSR and LDP MIB moduels Message-ID: <20845434.1055778200@[10.1.1.130]> In-Reply-To: <3EE4F226.4030104@pi.se> References: <3EE4F226.4030104@pi.se> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit --On Montag, 9. Juni 2003 22:46 +0200 Loa Andersson wrote: > All, > > this is to initiate a two week wg last call on > > Multiprotocol Label Switching (MPLS) Label Switching > Router (LSR) Management Information Base > I think it is just a nit. The question is why we need mplsXCInSegmentIndex and mplsXCOutSegmentIndex we can easily reuse mplsInSegmentIndex mplsOutSegmentIndex or do I miss something. Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From owner-mpls@UU.NET Tue Jun 17 06:19:03 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05764 for ; Tue, 17 Jun 2003 06:19:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotlp15254 for ; Tue, 17 Jun 2003 10:19:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotlp14686; Tue, 17 Jun 2003 10:18:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQotjd00098 for mpls-outgoing; Mon, 16 Jun 2003 18:20:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotjd00085 for ; Mon, 16 Jun 2003 18:20:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotjd09559 for ; Mon, 16 Jun 2003 18:20:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotjd22442 for ; Mon, 16 Jun 2003 18:20:07 GMT Received: from sj-core-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-5.cisco.com [171.71.177.238]) id QQotjd22423 for ; Mon, 16 Jun 2003 18:20:06 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5GIK3Um026155 for ; Mon, 16 Jun 2003 11:20:03 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB78388; Mon, 16 Jun 2003 14:20:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5GIK2D05120 for mpls@uu.net; Mon, 16 Jun 2003 14:20:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotjc28622 for ; Mon, 16 Jun 2003 18:08:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotjc05491 for ; Mon, 16 Jun 2003 18:05:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotjc16507 for ; Mon, 16 Jun 2003 18:05:35 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotjc16488 for ; Mon, 16 Jun 2003 18:05:35 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5GI5VwH020332; Mon, 16 Jun 2003 14:05:31 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-97.cisco.com [10.86.242.97]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB77661; Mon, 16 Jun 2003 14:05:30 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Choudhury, Sanjaya'" , Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Mon, 16 Jun 2003 14:05:20 -0400 Organization: Cisco Systems Message-ID: <022401c33431$dd748a30$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <313680C9A886D511A06000204840E1CF0742CCE1@whq-msgusr-02.pit.comms.marconi.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Choudhury, Sanjaya > Sent: Friday, June 13, 2003 9:07 AM > To: mpls@UU.NET > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTa ble] > > > Hi! I am open to all changes that will make the MIB > efficient for users, but I think it is not a bad > idea to examine the alternative solutions. Here > are some thoughts: > > Some of the cases, where NMS might use a GetNext() > on mplsInSegment table: > ------------------------------------------------- > > Case-1:: If the aim of the NMS is to get the next > 'best/free' label, to configure the next mplsInSegment, > then he may encounter a (potential) O(n) search of > the mplsInSegmentTable. > > We can resolve this issue, by adding a new table: > mplsNextFreeLabelTable [indexed by ifIndex] > > If ifIndex == 0 : the row indicates the > next free platform-label-space label > > If ifIndex !=0 : the row indicates the > next free interface-label-space label for > the specified interface. > This solution, will address the efficiency > issue, without compromising the natural > indexing of the mplsInSegmentTable. I disagree. It seems that you consider the old indexing efficient, which I clearly do not. > Case-2: If the aim of the NMS is to show/list all > the incoming-mpls-segments, on a per-interface basis, > the GetNext() works perfectly with the original indexing > (ifIndex,label) Only for a non-distributed implementation. Please see prior threads as to why this works at best O(N), and is more likely O(N^2) on distributed implementations. > Case-3: If the aim of the NMS is to show ALL the > incoming segments or access ALL the incoming > segments, he will need to walk the whole table > and indexing does not matter. Indexing always matters! If I care about this case and can walk the entire table in 1 hour versus 2-4 minutes, that makes a BIG difference. The compromise that Adrian and I sent out addresses all of these concerns AND is efficient. --Tom > Thanks, > sanjay > > > > > -----Original Message----- > > From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com] > > Sent: Thursday, June 12, 2003 10:11 AM > > To: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET > > Subject: RE: prequeal to WG lat call om the LSR mib > > module[mplsInSegmentTa ble] > > > > > > As a provider of management solutions... We'd "prefer" > > to have a simple solution but we MUST have a working solution. > > Although the proposed change makes the instancing a bit > more complex, > > the getnext performance of the current mplsXCTable is so > slow that its > > practically unreadable in any reasonably sized network. > > > > Mike Shevenell > > Aprisma Management Technologies > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Wednesday, June 11, 2003 10:35 AM > > To: 'Choudhury, Sanjaya'; mpls@UU.NET > > Subject: RE: prequeal to WG lat call om the LSR mib > > module[mplsInSegmentTable] > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > Of Choudhury, Sanjaya > > > Sent: Tuesday, June 10, 2003 12:06 PM > > > To: 'mpls@UU.NET' > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > module[mplsInSegmentTable] > > > > > > > > > Hi! Few comments in-line regarding the indexing of the > > > mplsInSegmentTable > > > > > > > -----Original Message----- > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > Sent: Saturday, June 07, 2003 9:13 AM > > > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > -----Original Message----- > > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On > Behalf Of > > > > > Wijnen, Bert (Bert) > > > > > Sent: Friday, June 06, 2003 11:14 AM > > > > > To: MPLS WG > > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > > > > > > stuff deleted... > > > > The problem with designing in the ideal is that > > real implementations will have issues with it. The > > IETF generally considers implementation and deployment > > experience highly over the ideal. I have provided some > > real world feedback that indicates that a single Unsigned32 > > index is insufficient. I also have about 300 customers > > that have provided me with the same feedback. I think that > > it has little to do with my specific style of implementation > > either (see below). > > more stuff deleted.. > > > > --Tom > > > > > From owner-mpls@UU.NET Tue Jun 17 06:21:44 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05791 for ; Tue, 17 Jun 2003 06:21:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotlp21798 for ; Tue, 17 Jun 2003 10:21:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotlp21164; Tue, 17 Jun 2003 10:21:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQotjc17958 for mpls-outgoing; Mon, 16 Jun 2003 18:02:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotjc17781 for ; Mon, 16 Jun 2003 18:01:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotjc00651 for ; Mon, 16 Jun 2003 18:01:21 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotjc05325 for ; Mon, 16 Jun 2003 18:01:20 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotjc05098 for ; Mon, 16 Jun 2003 18:01:15 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5GI1BwH019111 for ; Mon, 16 Jun 2003 14:01:11 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB77470; Mon, 16 Jun 2003 14:01:09 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5GI19q04226 for mpls@uu.net; Mon, 16 Jun 2003 14:01:09 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotja08690 for ; Mon, 16 Jun 2003 17:38:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotja06521 for ; Mon, 16 Jun 2003 17:38:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotja09267 for ; Mon, 16 Jun 2003 17:38:30 GMT Received: from sj-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-1.cisco.com [171.71.177.237]) id QQotja08023 for ; Mon, 16 Jun 2003 17:38:05 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5GHbaTa025159; Mon, 16 Jun 2003 10:37:37 -0700 (PDT) Received: from tnadeauw2k (che-vpn-cluster-2-97.cisco.com [10.86.242.97]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB76343; Mon, 16 Jun 2003 13:37:35 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: , "'Shevenell, Michael \(Mike\)'" Cc: "'Choudhury, Sanjaya'" , Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Mon, 16 Jun 2003 13:37:26 -0400 Organization: Cisco Systems Message-ID: <021c01c3342d$f774b760$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200306131517.LAA25614@workhorse.fictitious.org> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Friday, June 13, 2003 11:17 AM > To: Shevenell, Michael (Mike) > Cc: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET > Subject: Re: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTa ble] > > > > In message > , > "Shev enell, Michael (Mike)" writes: > > As a provider of management solutions... We'd "prefer" > > to have a simple solution but we MUST have a working solution. > > Although the proposed change makes the instancing a bit > more complex, > > the getnext performance of the current mplsXCTable is so > slow that its > > practically unreadable in any reasonably sized network. > > > > Mike Shevenell > > Aprisma Management Technologies > > > It may be that the only practical way to use the > mplsInSegmentTable is in network verification tool in which > an SNMP trace of a specific LSP is done. A reasonable > strategy would be to trigger this form of traceroute (plus > MPLS-ping if you wanted to verify forwarding too) any time a > trap indicates the LSP may have rerouted, plus periodically. > This assures that a low background of sanity checking is > going on and that changes are checked promptly. Indeed many people are using my implementation for just this reason due to the size of the information contained therein. > I'm not sure that dumping the mplsXCTable makes a whole lot > of sense in any practical context except if you are > explicitly setting up inseg and outseg with the MIB which no > one seems to be doing. The XCtable in a fully populated "P" router gets quite large. Remember, the TFIB in many cases, is a direct reflection of the FIB in size. > If changes to the indexing of mplsInSegmentTable make it more > difficult to do this form of traceroute, then we may need to > go back to the Unsigned32 index. Changing the index to a string gives you the same semantics as the Unsigned32, but with possibly (much) faster performance. BTW, I don't think that Mike was in favor of returning to the Unsigned32; rather he was in favor of the new octet string indexing. > For the traceroute capabiility to work, there has to be a way > to take the outgoing label out of the mplsOutSegmentTopLabel > on the previous LSR and find the MplsInSegmentEntry on the > next LSR. Have we broken this? If so that would be a problem. No, this still works the same way with an octet string. Remember, an octet string is just a series of bytes. If you make it 4 bytes, then it behaves the same as the unsigned32 did, if you make it more you have the same interactions. --Tom > > Curtis > > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Wednesday, June 11, 2003 10:35 AM > > To: 'Choudhury, Sanjaya'; mpls@UU.NET > > Subject: RE: prequeal to WG lat call om the LSR mib > > module[mplsInSegmentTable] > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > Of Choudhury, Sanjaya > > > Sent: Tuesday, June 10, 2003 12:06 PM > > > To: 'mpls@UU.NET' > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > module[mplsInSegmentTable] > > > > > > > > > Hi! Few comments in-line regarding the indexing of the > > > mplsInSegmentTable > > > > > > > -----Original Message----- > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > Sent: Saturday, June 07, 2003 9:13 AM > > > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > -----Original Message----- > > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On > Behalf Of > > > > > Wijnen, Bert (Bert) > > > > > Sent: Friday, June 06, 2003 11:14 AM > > > > > To: MPLS WG > > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > > > > > > stuff deleted... > > > > The problem with designing in the ideal is that > > real implementations will have issues with it. The > > IETF generally considers implementation and deployment > > experience highly over the ideal. I have provided some > > real world feedback that indicates that a single Unsigned32 > > index is insufficient. I also have about 300 customers > > that have provided me with the same feedback. I think that > > it has little to do with my specific style of implementation > > either (see below). > > more stuff deleted.. > > > > --Tom > > > > > From owner-mpls@UU.NET Tue Jun 17 06:23:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05838 for ; Tue, 17 Jun 2003 06:23:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotlp24975 for ; Tue, 17 Jun 2003 10:23:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotlp24400; Tue, 17 Jun 2003 10:22:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQotjh23878 for mpls-outgoing; Mon, 16 Jun 2003 19:26:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotjh23873 for ; Mon, 16 Jun 2003 19:26:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotjh18425 for ; Mon, 16 Jun 2003 19:21:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotjh22605 for ; Mon, 16 Jun 2003 19:21:15 GMT Received: from sj-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-2.cisco.com [171.71.177.254]) id QQotjh22562 for ; Mon, 16 Jun 2003 19:21:14 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5GJLApa010517 for ; Mon, 16 Jun 2003 12:21:11 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB81320; Mon, 16 Jun 2003 15:21:10 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5GJLA007814 for mpls@uu.net; Mon, 16 Jun 2003 15:21:10 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotje01221 for ; Mon, 16 Jun 2003 18:37:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotje12202 for ; Mon, 16 Jun 2003 18:37:30 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotje00685 for ; Mon, 16 Jun 2003 18:37:29 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotje00667 for ; Mon, 16 Jun 2003 18:37:29 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5GIbCwH000193; Mon, 16 Jun 2003 14:37:12 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-97.cisco.com [10.86.242.97]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB79329; Mon, 16 Jun 2003 14:37:11 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Marcus Brunner'" , "'Loa Andersson'" , "'MPLS WG'" Cc: "'Bert Wijnen'" Subject: RE: prequeal to WG lat call om the LSR mib module Date: Mon, 16 Jun 2003 14:37:01 -0400 Organization: Cisco Systems Message-ID: <022d01c33436$4ac3cc50$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20496282.1055777851@[10.1.1.130]> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Monday, June 16, 2003 9:38 AM > To: Loa Andersson; MPLS WG > Cc: Thomas D. Nadeau; Bert Wijnen > Subject: Re: prequeal to WG lat call om the LSR mib module > > > > > The items are: > > > > 1) The indexing of the in/out/XC > > tables has changed from Unsigned32s > > to Octet Strings of up to 24 bytes > > in length. > > > > I find the 24 byte octet string as index really wired. The > Unsigned32 was > exactly the right thing for me. So I can not support the change. > > > The reason this was done was to facilitate > > LSRs that support multiple applications of > > MPLS in a distribute fashion. Use of a > > flat 32 bit indexing space on these platforms > > ends up with VERY slot N^2+ GetNext searches > > due to the fact that labels are distributed > > among different applications. The GetNext > > routine must then query each application's > > "bag" of labels to determine the next index. > > > > This sounds like a problem of information management on the > box and has IMHO nothing to do with a MIB design to be useful for Management > Applications. Do you have an implementation of this MIB and is it distributed that you would care to return implementation experience on? > Indexing always has implications on sorting in the management > application. Generally negative ones when the indexing is created to be ideal. > If the sorting based on different applications is needed I > would favor the > approach with an app index. I assume the app index will be > coded into the 24 octet string anyway so why not making > it explicit? Becuause it adds another index to the indexes. This has the unfortunate side-effect of making other MIBs that might reference these indexes (i.e.: LDP/TE/FTN) more complex. If you implement MIBs then you understand that the addition of indexes often leads to more work on the agent's part and thus a slower implementation. If you can achieve the same things with a single index, this seems like the right thing to do. > > This change is compatible with implementations > > that wish to remain with the 4 byte indexing; > > they just use a 4 byte octet string, while others > > are free to use the more specific indexing. > > Sounds like an offer for incompatible implementations. You need to be more specific about what you mean by that, because I did not imply that this lead to incompatabilities. It seems pretty clear to me that whether you encode 4 bytes as an Unsigned32 or an octet string, you get the same semantic meaning. --Tom > > 2) The addition of a RowPointer to the in/out/label > > stack tables to support "long" or GMPLS-style > > labels. The RowPointer is normally set to zeroDotZero > > except when the MIB needs to refer to an external > > table that defines labels that exceed the 32bits > > of space alloted in the tables today. This > > in essence, future-proofs the MIB and makes > > it compatible immediately with the GMPLS MIBs > > defined in CCAMP. > > I like this approach the most from the three listed by Adrian > some time > ago. All have some problems, but this one works for me. > > Marcus > -------------------------------------- > Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > > From owner-mpls@UU.NET Tue Jun 17 11:54:40 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23797 for ; Tue, 17 Jun 2003 11:54:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotml23722 for ; Tue, 17 Jun 2003 15:54:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotml22331; Tue, 17 Jun 2003 15:53:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQotju02946 for mpls-outgoing; Mon, 16 Jun 2003 22:36:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotju02898 for ; Mon, 16 Jun 2003 22:35:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotju29929 for ; Mon, 16 Jun 2003 22:35:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotju21404 for ; Mon, 16 Jun 2003 22:35:04 GMT Received: from sj-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-2.cisco.com [171.71.177.254]) id QQotju21332 for ; Mon, 16 Jun 2003 22:35:02 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5GMYspa005226 for ; Mon, 16 Jun 2003 15:34:54 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAB89262; Mon, 16 Jun 2003 18:34:52 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5GMYqW18687 for mpls@uu.net; Mon, 16 Jun 2003 18:34:52 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotjo07944 for ; Mon, 16 Jun 2003 21:11:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotjo23956 for ; Mon, 16 Jun 2003 21:09:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotjo11852 for ; Mon, 16 Jun 2003 21:09:30 GMT Received: from web21512.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21512.mail.yahoo.com [66.163.169.51]) id QQotjo11808 for ; Mon, 16 Jun 2003 21:09:29 GMT Message-ID: <20030616210928.17598.qmail@web21512.mail.yahoo.com> Received: from [64.95.122.60] by web21512.mail.yahoo.com via HTTP; Mon, 16 Jun 2003 14:09:28 PDT Date: Mon, 16 Jun 2003 14:09:28 -0700 (PDT) From: jiri prekow Subject: Merging SE style reservations for make-before-break To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a confgiuration as follows- R1========R2==========R3 \ / \ / \ / \R4/ lsp1 takes the path R1-R2-R3 with a reservation of 1M At this time you do a make-before-break for lsp1 with a lower bandwidth of say 500K, and it takes the path R1-R4-R2-R3. When you get the resv at R2 it will have a flow descriptor of 1M followed by 2 filter specs. When R2 sends out a resv to R4 for the new make-before-break lsp should the flow descriptor contain a value of 500K or should it be 1M. Thanks Jiri __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From owner-mpls@UU.NET Tue Jun 17 18:45:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15260 for ; Tue, 17 Jun 2003 18:45:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotnn07858 for ; Tue, 17 Jun 2003 22:45:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotnm07275; Tue, 17 Jun 2003 22:44:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQotll29412 for mpls-outgoing; Tue, 17 Jun 2003 09:24:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotll29407 for ; Tue, 17 Jun 2003 09:24:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotll11443 for ; Tue, 17 Jun 2003 09:24:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotll14723 for ; Tue, 17 Jun 2003 09:24:06 GMT Received: from maile.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maile.telia.com [194.22.190.16]) id QQotll14696 for ; Tue, 17 Jun 2003 09:24:05 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maile.telia.com (8.12.9/8.12.9) with ESMTP id h5H9Nrvm011978; Tue, 17 Jun 2003 11:23:53 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h5H9Nrc27003; Tue, 17 Jun 2003 11:23:53 +0200 (CEST) Message-ID: <3EEEDD02.3040609@pi.se> Date: Tue, 17 Jun 2003 11:18:58 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG CC: Alex Zinin , Bert Wijnen , George Swallow Subject: mpls wg at IETF 57 in Vienna Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, the 57th IETF meeting to be held in Vienna is appraoching ever faster, (OK I admit that that is a subjective point of virew, nevertheless...) it is time to set the agenda for the mpls working group. Note that to get a time slot, you MUST have submitted a draft by the draft deadline (June 30, 9:00AM ET). Furthermore, these time slots are for discussing and resolving issues raised on the mailing list, or for first time drafts, a *very* brief overview of the idea, why it's relevant, and how it fits into the mpls charter. No presentations! If you request a time slot, please follow up and start an email discussion on the ppvpn list. Thanks, Loa and George. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Tue Jun 17 23:04:50 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20506 for ; Tue, 17 Jun 2003 23:04:50 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotoe05754 for ; Wed, 18 Jun 2003 03:04:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotoe05646; Wed, 18 Jun 2003 03:04:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQotjw23267 for mpls-outgoing; Mon, 16 Jun 2003 23:11:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotjw23165 for ; Mon, 16 Jun 2003 23:10:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotjw07582 for ; Mon, 16 Jun 2003 23:09:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotjw03016 for ; Mon, 16 Jun 2003 23:09:58 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQotjw03004 for ; Mon, 16 Jun 2003 23:09:57 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA23518 for ; Mon, 16 Jun 2003 19:09:50 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA02952 for ; Mon, 16 Jun 2003 19:09:51 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 19:09:51 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0742CCF1@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: mpls@UU.NET Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Mon, 16 Jun 2003 19:09:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Comments in-line. > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, June 16, 2003 2:05 PM > To: 'Choudhury, Sanjaya'; mpls@UU.NET > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTa ble] > > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > Of Choudhury, Sanjaya > > Sent: Friday, June 13, 2003 9:07 AM > > To: mpls@UU.NET > > Subject: RE: prequeal to WG lat call om the LSR mib > > module[mplsInSegmentTa ble] > > > > > > Hi! I am open to all changes that will make the MIB > > efficient for users, but I think it is not a bad > > idea to examine the alternative solutions. Here > > are some thoughts: > > > > Some of the cases, where NMS might use a GetNext() > > on mplsInSegment table: > > ------------------------------------------------- > > > > Case-1:: If the aim of the NMS is to get the next > > 'best/free' label, to configure the next mplsInSegment, > > then he may encounter a (potential) O(n) search of > > the mplsInSegmentTable. > > > > We can resolve this issue, by adding a new table: > > mplsNextFreeLabelTable [indexed by ifIndex] > > > > If ifIndex == 0 : the row indicates the > > next free platform-label-space label > > > > If ifIndex !=0 : the row indicates the > > next free interface-label-space label for > > the specified interface. > > > This solution, will address the efficiency > > issue, without compromising the natural > > indexing of the mplsInSegmentTable. > > I disagree. It seems that you consider > the old indexing efficient, which I clearly do not. Here I was just trying find an alternative solution to the proposed index change for the mplsInSegmentTable. [Note: Here we are talking about case-1 as described above.] o Do you agree that the solution I proposed provides the users of mplsInSegmentTable with an efficient solution for looking up the next free/best label [O(C)] ? o With the solution proposed in the latest version of LSR-MIB, user for case-1 might get the similar efficiency (as the one I proposed); BUT it depends on the vendor implementations. Unless, everybody implement the mplsInSegmentIndex the same way, user will face the same inefficiencies. o I think the solution I proposed has the following advantages: (i) the solution does leaves the index as is [ifIndex,label], which is natural for the mplsInSegmentTable (ii) the solution is implementation independent [does not depend on the way a vendor implements the new mplsInSegmentIndex] > > > Case-2: If the aim of the NMS is to show/list all > > the incoming-mpls-segments, on a per-interface basis, > > the GetNext() works perfectly with the original indexing > > (ifIndex,label) > > Only for a non-distributed implementation. > Please see prior threads as to why this works at > best O(N), and is more likely O(N^2) on distributed > implementations. > Note that the case-2, is addressing the case where the NMS is trying to display the insegments on a *per-interface* basis. o When NMS is trying to display/query insegments on a per-interface basis, don't you think a (ifIndex,label) index is perfect ?? o The worst case here is for a node that supports only per-platform labels i.e O(n). But this worst case number is same for both the solutions (proposed in LSR-MIB-v10 and in this e-mail) o In distributed cases, it may be O(n) * num-app in the worst case. > > Case-3: If the aim of the NMS is to show ALL the > > incoming segments or access ALL the incoming > > segments, he will need to walk the whole table > > and indexing does not matter. > > Indexing always matters! If I care about this > case and can walk the entire table in 1 hour versus > 2-4 minutes, that makes a BIG difference. The > compromise that Adrian and I sent out addresses > all of these concerns AND is efficient. > Please note: Case-3 captures the case where the user is NMS is trying to show _ALL_ the insegments. o If a table has n rows and one wants to query all the n rows, the cost will be O(n). Correct ? o How can I query _ALL_ the n rows from a table more efficiently by the choice of indexing?? [i.e better than O(n)] Thanks, sanjay > --Tom > > > > Thanks, > > sanjay > > > > > > > > > -----Original Message----- > > > From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com] > > > Sent: Thursday, June 12, 2003 10:11 AM > > > To: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > module[mplsInSegmentTa ble] > > > > > > > > > As a provider of management solutions... We'd "prefer" > > > to have a simple solution but we MUST have a working solution. > > > Although the proposed change makes the instancing a bit > > more complex, > > > the getnext performance of the current mplsXCTable is so > > slow that its > > > practically unreadable in any reasonably sized network. > > > > > > Mike Shevenell > > > Aprisma Management Technologies > > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Wednesday, June 11, 2003 10:35 AM > > > To: 'Choudhury, Sanjaya'; mpls@UU.NET > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > module[mplsInSegmentTable] > > > > > > > -----Original Message----- > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > > Of Choudhury, Sanjaya > > > > Sent: Tuesday, June 10, 2003 12:06 PM > > > > To: 'mpls@UU.NET' > > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > > module[mplsInSegmentTable] > > > > > > > > > > > > Hi! Few comments in-line regarding the indexing of the > > > > mplsInSegmentTable > > > > > > > > > -----Original Message----- > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > Sent: Saturday, June 07, 2003 9:13 AM > > > > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > -----Original Message----- > > > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On > > Behalf Of > > > > > > Wijnen, Bert (Bert) > > > > > > Sent: Friday, June 06, 2003 11:14 AM > > > > > > To: MPLS WG > > > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > > > > > > > > > > > stuff deleted... > > > > > > The problem with designing in the ideal is that > > > real implementations will have issues with it. The > > > IETF generally considers implementation and deployment > > > experience highly over the ideal. I have provided some > > > real world feedback that indicates that a single Unsigned32 > > > index is insufficient. I also have about 300 customers > > > that have provided me with the same feedback. I think that > > > it has little to do with my specific style of implementation > > > either (see below). > > > more stuff deleted.. > > > > > > --Tom > > > > > > > > > > From owner-mpls@UU.NET Tue Jun 17 23:24:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20941 for ; Tue, 17 Jun 2003 23:24:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotof26269 for ; Wed, 18 Jun 2003 03:24:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotof26045; Wed, 18 Jun 2003 03:24:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQotme18363 for mpls-outgoing; Tue, 17 Jun 2003 14:04:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotme18260 for ; Tue, 17 Jun 2003 14:03:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotme06165 for ; Tue, 17 Jun 2003 14:02:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotme29311 for ; Tue, 17 Jun 2003 14:02:40 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQotme29295 for ; Tue, 17 Jun 2003 14:02:40 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07103 for ; Tue, 17 Jun 2003 10:02:38 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08467 for ; Tue, 17 Jun 2003 10:02:39 -0400 (EDT) Message-ID: <3EEF1F5A.7060802@marconi.com> Date: Tue, 17 Jun 2003 10:02:02 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030603 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Merging SE style reservations for make-before-break References: <20030616210928.17598.qmail@web21512.mail.yahoo.com> In-Reply-To: <20030616210928.17598.qmail@web21512.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jiri prekow wrote: > > I have a confgiuration as follows- > > > R1========R2==========R3 > \ / > \ / > \ / > \R4/ > > lsp1 takes the path R1-R2-R3 with a reservation of 1M > At this time you do a make-before-break for lsp1 with > a lower bandwidth of say 500K, and it takes the path > R1-R4-R2-R3. When you get the resv at R2 it will have a > flow descriptor of 1M followed by 2 filter specs. When > R2 sends out a resv to R4 for the new > make-before-break lsp should the flow descriptor > contain a value of 500K or should it be 1M. 1M. The RSVP merging rules are pretty explicit. For classical RSVP, where all reservations are made on the egress interface, you take the least upper bound of the incoming reservations (with is 1M in this case), reserve that and transmit that upstream towards your PHOP. With MPLS, it's functionally the same. You're not reserving only on the egress interface, so your internal reservations (ingress bandwidth, fabric bandwidth, egress bandwidth, connection, etc.) will be on a per-LSP basis with appropriate sharing where possible, but the Resv you send out will still be the least upper bound of its compponents. After the original LSP is torn down (the "break" step of "make before break") then router R2 will re-sent its Resv message with a bandwidth of 500K, since there is now only one LSP to merge. R3 will see this and will change its reservation for the group at that time. -- David From owner-mpls@UU.NET Tue Jun 17 23:42:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21366 for ; Tue, 17 Jun 2003 23:42:51 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotog24523 for ; Wed, 18 Jun 2003 03:42:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotog24288; Wed, 18 Jun 2003 03:42:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQotlw22654 for mpls-outgoing; Tue, 17 Jun 2003 12:01:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotlw21911 for ; Tue, 17 Jun 2003 12:01:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotlw14931 for ; Tue, 17 Jun 2003 12:01:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotlw23863 for ; Tue, 17 Jun 2003 12:01:06 GMT Received: from sj-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-2.cisco.com [171.71.177.254]) id QQotlw23826 for ; Tue, 17 Jun 2003 12:01:06 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5HC13pa018771 for ; Tue, 17 Jun 2003 05:01:03 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC03339; Tue, 17 Jun 2003 08:01:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5HC12010047 for mpls@uu.net; Tue, 17 Jun 2003 08:01:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotlv14142 for ; Tue, 17 Jun 2003 11:56:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotlv02636 for ; Tue, 17 Jun 2003 11:56:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotlv10808 for ; Tue, 17 Jun 2003 11:56:05 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQotlv10775 for ; Tue, 17 Jun 2003 11:56:04 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08200; Tue, 17 Jun 2003 07:56:03 -0400 (EDT) Message-Id: <200306171156.HAA08200@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-iwata-mpls-crankback-06.txt Date: Tue, 17 Jun 2003 07:56:03 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Signaling Extensions for MPLS Signaling Author(s) : A. Farrel, A. Iwata et al. Filename : draft-iwata-mpls-crankback-06.txt Pages : 30 Date : 2003-6-16 Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for use in Multi-Protocol Label Switching (MPLS) signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-iwata-mpls-crankback-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iwata-mpls-crankback-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-crankback-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075212.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jun 17 23:44:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21406 for ; Tue, 17 Jun 2003 23:44:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotog28173 for ; Wed, 18 Jun 2003 03:44:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotog27433; Wed, 18 Jun 2003 03:44:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQotly05787 for mpls-outgoing; Tue, 17 Jun 2003 12:40:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotly05772 for ; Tue, 17 Jun 2003 12:40:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotly21094 for ; Tue, 17 Jun 2003 12:40:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotly15553 for ; Tue, 17 Jun 2003 12:40:09 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotly15544 for ; Tue, 17 Jun 2003 12:40:08 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5HCe5wH017547 for ; Tue, 17 Jun 2003 08:40:05 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC04222; Tue, 17 Jun 2003 08:40:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5HCe4H11804 for mpls@uu.net; Tue, 17 Jun 2003 08:40:04 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotly05682 for ; Tue, 17 Jun 2003 12:37:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotly12753 for ; Tue, 17 Jun 2003 12:36:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotly09394 for ; Tue, 17 Jun 2003 12:36:51 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotly09369 for ; Tue, 17 Jun 2003 12:36:45 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5HCaZwH016771; Tue, 17 Jun 2003 08:36:35 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-97.cisco.com [10.86.242.97]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC04133; Tue, 17 Jun 2003 08:36:34 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Marcus Brunner'" , "'Choudhury, Sanjaya'" , Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Tue, 17 Jun 2003 08:36:25 -0400 Organization: Cisco Systems Message-ID: <02e201c334cd$14456ca0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <19790617.1055777145@[10.1.1.130]> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA21406 > > Case-2: If the aim of the NMS is to show/list all > > the incoming-mpls-segments, on a per-interface basis, > > the GetNext() works perfectly with the original indexing > > (ifIndex,label) > > With the currently proposed Indexing this seams not be easily > possible to do anymore (and it has nothing to do with provisioning). Sure > you can read the full table. If you still think this is a problem you are free to encode the first 4 bytes as an ifIndex. However, it has been my experience that this is not as useful as you might think. More often than not insegments of deployments use the per-platform label space. This means that it is likely that an implementation will accept all labels from the per-platform label range on all interfaces using that label range, thus it is more efficient to use the ifIndex=0 scheme as is specified in the older versions of the MIB to handle the majority of cases. This amounts to (ifIndex=0, insegmentIndex = *), which is in effect the same as just using insegmentIndex and first looking at the interfaces in that label range in the InterfaceTable. > > Case-3: If the aim of the NMS is to show ALL the > > incoming segments or access ALL the incoming > > segments, he will need to walk the whole table > > and indexing does not matter. See above. --Tom > Exactly. > > Marcus > > > > > Thanks, > > sanjay > > > > > > > >> -----Original Message----- > >> From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com] > >> Sent: Thursday, June 12, 2003 10:11 AM > >> To: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET > >> Subject: RE: prequeal to WG lat call om the LSR mib > >> module[mplsInSegmentTa ble] > >> > >> > >> As a provider of management solutions... We'd "prefer" > >> to have a simple solution but we MUST have a working solution. > >> Although the proposed change makes the instancing a bit > more complex, > >> the getnext performance of the current mplsXCTable is so slow that > >> its practically unreadable in any reasonably sized network. > >> > >> Mike Shevenell > >> Aprisma Management Technologies > >> > >> -----Original Message----- > >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> Sent: Wednesday, June 11, 2003 10:35 AM > >> To: 'Choudhury, Sanjaya'; mpls@UU.NET > >> Subject: RE: prequeal to WG lat call om the LSR mib > >> module[mplsInSegmentTable] > >> > >> > -----Original Message----- > >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of > >> > Choudhury, Sanjaya > >> > Sent: Tuesday, June 10, 2003 12:06 PM > >> > To: 'mpls@UU.NET' > >> > Subject: RE: prequeal to WG lat call om the LSR mib > >> > module[mplsInSegmentTable] > >> > > >> > > >> > Hi! Few comments in-line regarding the indexing of the > >> > mplsInSegmentTable > >> > > >> > > -----Original Message----- > >> > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> > > Sent: Saturday, June 07, 2003 9:13 AM > >> > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > >> > > Subject: RE: prequeal to WG lat call om the LSR mib module > >> > > > -----Original Message----- > >> > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] > On Behalf Of > >> > > > Wijnen, Bert (Bert) > >> > > > Sent: Friday, June 06, 2003 11:14 AM > >> > > > To: MPLS WG > >> > > > Subject: RE: prequeal to WG lat call om the LSR mib module > >> > > > > >> > > > >> > > >> > > >> > stuff deleted... > >> > >> The problem with designing in the ideal is that > >> real implementations will have issues with it. The > >> IETF generally considers implementation and deployment experience > >> highly over the ideal. I have provided some real world > feedback that > >> indicates that a single Unsigned32 index is insufficient. > I also have > >> about 300 customers that have provided me with the same > feedback. I > >> think that it has little to do with my specific style of > >> implementation either (see below). > >> more stuff deleted.. > >> > >> --Tom > >> > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > > From owner-mpls@UU.NET Tue Jun 17 23:47:47 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21507 for ; Tue, 17 Jun 2003 23:47:47 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotoh13574 for ; Wed, 18 Jun 2003 03:47:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotoh13260; Wed, 18 Jun 2003 03:47:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQotly05777 for mpls-outgoing; Tue, 17 Jun 2003 12:40:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotly05766 for ; Tue, 17 Jun 2003 12:40:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotly21036 for ; Tue, 17 Jun 2003 12:40:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotly15540 for ; Tue, 17 Jun 2003 12:40:08 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotly15516 for ; Tue, 17 Jun 2003 12:40:07 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5HCe4wH017542 for ; Tue, 17 Jun 2003 08:40:04 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC04221; Tue, 17 Jun 2003 08:40:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5HCe3q11788 for mpls@uu.net; Tue, 17 Jun 2003 08:40:03 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotly05675 for ; Tue, 17 Jun 2003 12:37:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotly13961 for ; Tue, 17 Jun 2003 12:35:26 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotly06441 for ; Tue, 17 Jun 2003 12:35:23 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotly06436 for ; Tue, 17 Jun 2003 12:35:21 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5HCZ5wH016478; Tue, 17 Jun 2003 08:35:05 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-97.cisco.com [10.86.242.97]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC04096; Tue, 17 Jun 2003 08:35:04 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Marcus Brunner'" , "'Loa Andersson'" , "'MPLS WG'" , "'Bert Wijnen'" , "'Alex Zinin'" Subject: RE: WG lat call on LSR and LDP MIB moduels Date: Tue, 17 Jun 2003 08:34:54 -0400 Organization: Cisco Systems Message-ID: <02e101c334cc$de596880$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20845434.1055778200@[10.1.1.130]> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Marcus Brunner > Sent: Monday, June 16, 2003 9:43 AM > To: Loa Andersson; MPLS WG; Bert Wijnen; Alex Zinin > Subject: Re: WG lat call on LSR and LDP MIB moduels > > > > > --On Montag, 9. Juni 2003 22:46 +0200 Loa Andersson wrote: > > > All, > > > > this is to initiate a two week wg last call on > > > > Multiprotocol Label Switching (MPLS) Label Switching > > Router (LSR) Management Information Base > > > > I think it is just a nit. The question is why we need > mplsXCInSegmentIndex and mplsXCOutSegmentIndex we can easily > reuse mplsInSegmentIndex mplsOutSegmentIndex or do I miss > something. As I recall, there was some issue with the compiler that required us to do this, but I cannot remember the specific isue. Perhaps Bert remembers? --Tom > Marcus > > -------------------------------------- > Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > > From owner-mpls@UU.NET Wed Jun 18 03:14:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22232 for ; Wed, 18 Jun 2003 03:14:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotou02633 for ; Wed, 18 Jun 2003 07:14:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotou02437; Wed, 18 Jun 2003 07:14:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQotmz15871 for mpls-outgoing; Tue, 17 Jun 2003 19:26:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotmz15834 for ; Tue, 17 Jun 2003 19:25:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotmz26044 for ; Tue, 17 Jun 2003 19:24:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotmz12752 for ; Tue, 17 Jun 2003 19:24:36 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQotmz12741 for ; Tue, 17 Jun 2003 19:24:36 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HJKYw05470; Tue, 17 Jun 2003 15:20:55 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 15:12:55 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75405F5A454@zcard0k6.ca.nortel.com> From: "Darek Skalecki" To: jiri prekow , mpls@UU.NET Subject: RE: Merging SE style reservations for make-before-break Date: Tue, 17 Jun 2003 15:12:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33504.72F22900" 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_01C33504.72F22900 Content-Type: text/plain Since you are doing make-before-break for lsp1, I think it should contain 1M until the old route (R1-R2-R3) of lsp1 is terminated, i.e. traffic of lsp1 is switched from old route to new route and old route terminated. Subsequently, it should contain 500K. Darek -----Original Message----- From: jiri prekow [mailto:jiri_prekow@yahoo.com] Sent: June 16, 2003 5:09 PM To: mpls@UU.NET Subject: Merging SE style reservations for make-before-break Hi, I have a confgiuration as follows- R1========R2==========R3 \ / \ / \ / \R4/ lsp1 takes the path R1-R2-R3 with a reservation of 1M At this time you do a make-before-break for lsp1 with a lower bandwidth of say 500K, and it takes the path R1-R4-R2-R3. When you get the resv at R2 it will have a flow descriptor of 1M followed by 2 filter specs. When R2 sends out a resv to R4 for the new make-before-break lsp should the flow descriptor contain a value of 500K or should it be 1M. Thanks Jiri __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------_=_NextPart_001_01C33504.72F22900 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Merging SE style reservations for make-before-break

Since you are doing make-before-break for lsp1, I = think it should contain 1M until the old route (R1-R2-R3) of lsp1 is = terminated, i.e. traffic of lsp1 is switched from old route to new = route and old route terminated. Subsequently, it should contain = 500K.

Darek

-----Original Message-----
From: jiri prekow [mailto:jiri_prekow@yahoo.com] =
Sent: June 16, 2003 5:09 PM
To: mpls@UU.NET
Subject: Merging SE style reservations for = make-before-break


Hi,

I have a confgiuration as follows-

 
R1=3D=3D=3D=3D=3D=3D=3D=3DR2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DR3
\        /
 \      /
  \    /
   \R4/

lsp1 takes the path R1-R2-R3 with a reservation of = 1M
At this time you do a make-before-break for lsp1 = with
a lower bandwidth of say 500K, and it takes the path = R1-R4-R2-R3. When you get the resv at R2 it will have a 
flow descriptor of 1M followed by 2 filter specs. = When
R2 sends out a resv to R4 for the new
make-before-break lsp should the flow = descriptor
contain a value of 500K or should it be 1M.

Thanks
Jiri

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

------_=_NextPart_001_01C33504.72F22900-- From owner-mpls@UU.NET Wed Jun 18 05:54:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25442 for ; Wed, 18 Jun 2003 05:54:18 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpf08614 for ; Wed, 18 Jun 2003 09:54:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotpf08223; Wed, 18 Jun 2003 09:54:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQotno16758 for mpls-outgoing; Tue, 17 Jun 2003 23:07:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotno16751 for ; Tue, 17 Jun 2003 23:07:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotno05132 for ; Tue, 17 Jun 2003 23:06:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotno22246 for ; Tue, 17 Jun 2003 23:06:25 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQotno22222 for ; Tue, 17 Jun 2003 23:06:25 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h5HN6Au91890; Tue, 17 Jun 2003 16:06:10 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h5HN6Ag74673; Tue, 17 Jun 2003 16:06:10 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 17 Jun 2003 16:06:10 -0700 (PDT) From: Kireeti Kompella To: Loa Andersson cc: MPLS WG , Alex Zinin , Bert Wijnen , George Swallow Subject: Re: mpls wg at IETF 57 in Vienna In-Reply-To: <3EEEDD02.3040609@pi.se> Message-ID: <20030617160501.Q74667@kummer.juniper.net> References: <3EEEDD02.3040609@pi.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 17 Jun 2003, Loa Andersson wrote: > If you request a time slot, please follow up and start an email > discussion on the ppvpn list. And, for grins, on the MPLS list as well. Or vice versa :-) Kireeti. From owner-mpls@UU.NET Wed Jun 18 07:23:38 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27161 for ; Wed, 18 Jun 2003 07:23:37 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpl20314 for ; Wed, 18 Jun 2003 11:23:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotpl20008; Wed, 18 Jun 2003 11:23:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQotny05562 for mpls-outgoing; Wed, 18 Jun 2003 01:36:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotny05557 for ; Wed, 18 Jun 2003 01:36:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotny18754 for ; Wed, 18 Jun 2003 01:36:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotny17684 for ; Wed, 18 Jun 2003 01:36:17 GMT Received: from smtp102.mail.sc5.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp102.mail.sc5.yahoo.com [216.136.174.140]) id QQotny17659 for ; Wed, 18 Jun 2003 01:36:17 GMT Received: from 12-234-100-254.client.attbi.com (HELO METANOIA) (vsharma87@12.234.100.254 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jun 2003 01:36:16 -0000 Reply-To: From: "Vishal Sharma" To: "Loa Andersson" , "MPLS WG" Cc: "Alex Zinin" , "Bert Wijnen" , "George Swallow" Subject: RE: mpls wg at IETF 57 in Vienna Date: Tue, 17 Jun 2003 18:35:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3EEEDD02.3040609@pi.se> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Loa, > If you request a time slot, please follow up and start an email > discussion on the ppvpn list. I suppose you mean MPLS mailing list :-) (I guess the burden of the Chair who chairs multiple WGs!) -Vishal > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa > Andersson > Sent: Tuesday, June 17, 2003 2:19 AM > To: MPLS WG > Cc: Alex Zinin; Bert Wijnen; George Swallow > Subject: mpls wg at IETF 57 in Vienna > > > All, > > the 57th IETF meeting to be held in Vienna is appraoching ever faster, > (OK I admit that that is a subjective point of virew, nevertheless...) > it is time to set the agenda for the mpls working group. > > Note that to get a time slot, you MUST have submitted a draft by > the draft deadline (June 30, 9:00AM ET). Furthermore, these time > slots are for discussing and resolving issues raised on the mailing > list, or for first time drafts, a *very* brief overview of the idea, > why it's relevant, and how it fits into the mpls charter. > > No presentations! > > If you request a time slot, please follow up and start an email > discussion on the ppvpn list. > > Thanks, > > Loa and George. > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se From owner-mpls@UU.NET Wed Jun 18 07:28:11 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27258 for ; Wed, 18 Jun 2003 07:28:11 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpl29149 for ; Wed, 18 Jun 2003 11:28:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotpl28696; Wed, 18 Jun 2003 11:27:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQotoe19546 for mpls-outgoing; Wed, 18 Jun 2003 03:08:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotoe19512 for ; Wed, 18 Jun 2003 03:08:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotoe07296 for ; Wed, 18 Jun 2003 03:08:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotoe09923 for ; Wed, 18 Jun 2003 03:08:11 GMT Received: from ckmso1.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQotoe09913 for ; Wed, 18 Jun 2003 03:08:11 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5I36bLM010470 for ; Tue, 17 Jun 2003 23:08:10 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C001C4E16 for mpls@uu.net; Tue, 17 Jun 2003 23:08:07 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: prequeal to WG lat call om the LSR mib module Date: Tue, 17 Jun 2003 22:08:10 -0500 Message-ID: <3D536751F6C50347AD038FF5D7AD987801A356AF@KCCLUST06EVS1.ugd.att.com> Thread-Topic: prequeal to WG lat call om the LSR mib module Thread-Index: AcMs9A1YX85e1SSSRF+Ig4fLqQWX+QERi+7A From: "Van der Linde, Harmen, ALABS" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA27258 Bert et al, Regarding your comments on the LSR MIB: > As soon as you get to see the MIB module, you can all check > for yourself. Here is why I have a serious concern with using > 24-octet index objects. Specifically for the mplsXCTable, where > 3 of such 24-octet objects are used as index. > > My comments below are based on a pre-relase version of the > doc I got to see/check, so if things have changed since then, > it may not be 100% accurate. > > Take the mplsXCTable. It has 3 of these objects as index onjects. > > It has 7 columns of which 5 are read-create. The read-create > objects are all pretty small in size. Like 3 integer based that > would contain some 9 octets on the wire together, then an LSPID > (4 or 8 octets on the wire), and another index type, possibly 26 > octets on the wire. So the actual DATA values on the > wire to create (or read) such a row consists of max 43 octets. > > The OID for the mplsXCEntry is: 1.3.6.1.2.1.10.166.2.1.9.1 > > So if each of the indices is 24 octets, then it adds 3*25 or > 75 octets to each OID. So the OID for each column is 87 octets. > > So to transport the 5 objects (containing max 43 octets of > real data) you potentially have to send 435 + 43 or 478 octets. > Add to that the overhead for SNMP header and PDU header data, > and it does not even fit in a 484 SNMP packet anymore and so a > createAndGo may not be working in some implementations anymore. > > When you had 3 Unsigned32 as index. the OID for each column > would have been max 29 octets or so. So the total would have > been 145 + 23 is some 168 or so octets (the data for the > mplsXCLabelStackIndex would also be reduced from 26 to 6). The issues you raise are valid and mostly directed towards SNMP packet size overhead as a result of the 24-octet indexing scheme. The problems caused by this overhead is that CreateAndGo may not work anymore, in addition to extra SNMP traffic load. When considering this problem, however, I think that you need consider other factors like usability in production environments as well. First off, it is not likely LSPs will be created and deleted with a high frequency, certainly not in a provider network. As such, additional overhead caused by the 24-octet indexing scheme is not a major issue (i.e., using CreateAndWait instead of CreatAndGo). The MPLS LSR MIB will most likely primarily being used for MPLS topology discovery (i.e., LSP path discovery). So, the emphasize is more on reading the MIB information as opposed to creation of new MIB information. In some earlier email exchange I read that a string-based indexing scheme has the benefit of providing more efficient table read capabilities. This efficiency is very appealing and beneficial to implement efficient MPLS topology discovery capabilities. My concern is that we spend too much time discussion a MIB SMI optimization (i.e., using a Unsigned32 index) that doesn't have substantial value and, in fact, seem to have a negative impact on MIB read capabilities. We need to get this MPLS MIB module, together with the MPLS LDP and MPLS VPN modules, standardized ASAP. There is a critical need for these MPLS MIB modules for management of MPLS-enabled networks, which are currently being deployed by many service providers. regards, Harmen From owner-mpls@UU.NET Wed Jun 18 07:28:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27305 for ; Wed, 18 Jun 2003 07:28:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpl00332 for ; Wed, 18 Jun 2003 11:28:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotpl29967; Wed, 18 Jun 2003 11:28:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQotod00604 for mpls-outgoing; Wed, 18 Jun 2003 02:58:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotod00599 for ; Wed, 18 Jun 2003 02:57:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotod03820 for ; Wed, 18 Jun 2003 02:56:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotod25377 for ; Wed, 18 Jun 2003 02:56:23 GMT Received: from mta0.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQotod25216 for ; Wed, 18 Jun 2003 02:56:17 GMT Received: from l04955 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HGN00DV6PF2X2@mta0.huawei.com> for mpls@UU.NET; Wed, 18 Jun 2003 10:54:41 +0800 (CST) Date: Wed, 18 Jun 2003 10:54:54 +0800 From: lidefeng Subject: Re: mpls wg at IETF 57 in Vienna To: Loa Andersson , MPLS WG Cc: Alex Zinin , Bert Wijnen , George Swallow Message-id: <003401c33544$ff71c440$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3EEEDD02.3040609@pi.se> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT > If you request a time slot, please follow up and start an email > discussion on the ppvpn list. Why should we follow up and start an email discussion on the ppvpn list when request a time slot in the MPLS wg?If so, In,the 57th IETF meeting.I Would like to give a brief overview of: a) draft-libin-hierarchy-pe-bgp-mpls-vpn-02.txt b) draft-sheng-ppvpn-isis-bgp-mpls-01.txt They are both l3vpn topics. draft-libin-hierarchy-pe-bgp-mpls-vpn-02 is about the problem of scalability of PE in 2547VPN and the access to the different layer BGP/MPLS VPN customer,which is not addressed in 2547bis; and draft-sheng-ppvpn-isis-bgp-mpls-01.txt address the issue of IS-IS as the PE-CE routing protocol mechanism for 2547 including the consideration of wide metric situation. Regards Defeng Li ----- Original Message ----- From: "Loa Andersson" To: "MPLS WG" Cc: "Alex Zinin" ; "Bert Wijnen" ; "George Swallow" Sent: Tuesday, June 17, 2003 5:18 PM Subject: mpls wg at IETF 57 in Vienna > All, > > the 57th IETF meeting to be held in Vienna is appraoching ever faster, > (OK I admit that that is a subjective point of virew, nevertheless...) > it is time to set the agenda for the mpls working group. > > Note that to get a time slot, you MUST have submitted a draft by > the draft deadline (June 30, 9:00AM ET). Furthermore, these time > slots are for discussing and resolving issues raised on the mailing > list, or for first time drafts, a *very* brief overview of the idea, > why it's relevant, and how it fits into the mpls charter. > > No presentations! > > If you request a time slot, please follow up and start an email > discussion on the ppvpn list. > > Thanks, > > Loa and George. > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > From owner-mpls@UU.NET Wed Jun 18 07:29:34 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27324 for ; Wed, 18 Jun 2003 07:29:34 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpl23636 for ; Wed, 18 Jun 2003 11:29:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotpl23449; Wed, 18 Jun 2003 11:29:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQotoe20599 for mpls-outgoing; Wed, 18 Jun 2003 03:14:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotoe20594 for ; Wed, 18 Jun 2003 03:14:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotoe19752 for ; Wed, 18 Jun 2003 03:14:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotoe05328 for ; Wed, 18 Jun 2003 03:14:31 GMT Received: from heian.fujitsu.com.cn by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.106.154.132]) id QQotoe05200 for ; Wed, 18 Jun 2003 03:14:24 GMT Received: from edo.cn.fujitsu.com (edo.cn.fujitsu.com [10.167.33.5]) by heian.fujitsu.com.cn (8.12.9/8.12.9) with ESMTP id h5I3E3r3023464 for ; Wed, 18 Jun 2003 11:14:03 +0800 (CST) Received: from fcc.fujitsu.com.cn (localhost [127.0.0.1]) by edo.cn.fujitsu.com (8.12.9/8.12.9) with ESMTP id h5I3EIYt004337 for ; Wed, 18 Jun 2003 11:14:18 +0800 (CST) X-Authentication-Warning: edo.cn.fujitsu.com: iscan owned process doing -bs Received: from luhouqin ([10.167.34.198]) by fcc.fujitsu.com.cn (8.11.6/8.11.6) with SMTP id h5I3BrR27826 for ; Wed, 18 Jun 2003 11:11:53 +0800 Message-ID: <030201c33548$2cb85060$c622a70a@luhouqin> From: "Jack Lu" To: "MPLS WG" References: Subject: test Date: Wed, 18 Jun 2003 11:17:39 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit test From owner-mpls@UU.NET Wed Jun 18 07:45:09 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27670 for ; Wed, 18 Jun 2003 07:45:09 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpn08985 for ; Wed, 18 Jun 2003 11:45:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotpm08525; Wed, 18 Jun 2003 11:44:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQotol16128 for mpls-outgoing; Wed, 18 Jun 2003 04:50:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotol16114 for ; Wed, 18 Jun 2003 04:50:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotol29060 for ; Wed, 18 Jun 2003 04:48:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotol27883 for ; Wed, 18 Jun 2003 04:48:35 GMT Received: from heian.fujitsu.com.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.106.154.132]) id QQotol27843 for ; Wed, 18 Jun 2003 04:48:33 GMT Received: from edo.cn.fujitsu.com (edo.cn.fujitsu.com [10.167.33.5]) by heian.fujitsu.com.cn (8.12.9/8.12.9) with ESMTP id h5I4lfr3024125 for ; Wed, 18 Jun 2003 12:48:02 +0800 (CST) Received: from fcc.fujitsu.com.cn (localhost [127.0.0.1]) by edo.cn.fujitsu.com (8.12.9/8.12.9) with ESMTP id h5I4lvrh004984 for ; Wed, 18 Jun 2003 12:47:57 +0800 (CST) X-Authentication-Warning: edo.cn.fujitsu.com: iscan owned process doing -bs Received: from luhouqin ([10.167.34.198]) by fcc.fujitsu.com.cn (8.11.6/8.11.6) with SMTP id h5I4jWR28989 for ; Wed, 18 Jun 2003 12:45:32 +0800 Message-ID: <033501c33555$41494900$c622a70a@luhouqin> From: "Jack Lu" To: "MPLS WG" References: <030201c33548$2cb85060$c622a70a@luhouqin> Subject: a question about VPLS/TLS Date: Wed, 18 Jun 2003 12:51:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I think that VPLS or TLS looks like draft-martini of l2 mpls vpn service. Is it right? There are another new concept " vMAN", which could provide VPLS in a MAN through layer-2 VPLS-enabled switches, no routers. Thus, one problem puzzled me, how can L2 switches setup LSPs without routers' supports? ldp/cr-ldp or rsvp-te enable? rely on only L2 forwarding table? pls give some comments. TIA Jack From owner-mpls@UU.NET Wed Jun 18 08:14:23 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29246 for ; Wed, 18 Jun 2003 08:14:23 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpo27876 for ; Wed, 18 Jun 2003 12:14:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotpo27756; Wed, 18 Jun 2003 12:14:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQotpk15656 for mpls-outgoing; Wed, 18 Jun 2003 11:01:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotpk14099 for ; Wed, 18 Jun 2003 11:01:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotpj11593 for ; Wed, 18 Jun 2003 10:59:25 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpj24730 for ; Wed, 18 Jun 2003 10:59:25 GMT Received: from maile.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maile.telia.com [194.22.190.16]) id QQotpj24702 for ; Wed, 18 Jun 2003 10:59:24 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maile.telia.com (8.12.9/8.12.9) with ESMTP id h5IAx66R003390; Wed, 18 Jun 2003 12:59:06 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h5IAx6c26353; Wed, 18 Jun 2003 12:59:06 +0200 (CEST) Message-ID: <3EF044D0.9060803@pi.se> Date: Wed, 18 Jun 2003 12:54:08 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kireeti Kompella CC: MPLS WG , Alex Zinin , Bert Wijnen , George Swallow Subject: Re: mpls wg at IETF 57 in Vienna References: <3EEEDD02.3040609@pi.se> <20030617160501.Q74667@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit OK - I confess - I thought that I sent both the ppvpn and mpls agenda mails at the same time, but found that I hadn't :( so it is (for once not a typo - it a cut and paste error) I think we not should follow Kireetis advice and double post the requests for time slots - risk is that I'll give you a slot on the wrong agenda :) (typos you know ;) ) /Loa Kireeti Kompella wrote: > On Tue, 17 Jun 2003, Loa Andersson wrote: > > >>If you request a time slot, please follow up and start an email >>discussion on the ppvpn list. > > > And, for grins, on the MPLS list as well. > > Or vice versa :-) > > Kireeti. > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Wed Jun 18 14:27:44 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19904 for ; Wed, 18 Jun 2003 14:27:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotqn28116 for ; Wed, 18 Jun 2003 18:27:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotqn26566; Wed, 18 Jun 2003 18:27:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQotpx05930 for mpls-outgoing; Wed, 18 Jun 2003 14:22:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotpx05893 for ; Wed, 18 Jun 2003 14:22:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotpx08440 for ; Wed, 18 Jun 2003 14:21:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpx22519 for ; Wed, 18 Jun 2003 14:21:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotpx22512 for ; Wed, 18 Jun 2003 14:21:06 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5IEL3wH007538 for ; Wed, 18 Jun 2003 10:21:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC52089; Wed, 18 Jun 2003 10:21:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5IEL2i27504 for mpls@uu.net; Wed, 18 Jun 2003 10:21:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotpx05760 for ; Wed, 18 Jun 2003 14:19:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotpx25740 for ; Wed, 18 Jun 2003 14:16:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotpx17184 for ; Wed, 18 Jun 2003 14:16:51 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotpx17182 for ; Wed, 18 Jun 2003 14:16:50 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5IEGkwH006093; Wed, 18 Jun 2003 10:16:47 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-1-37.cisco.com [10.86.240.37]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC51922; Wed, 18 Jun 2003 10:16:45 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Choudhury, Sanjaya'" , Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Wed, 18 Jun 2003 10:16:37 -0400 Organization: Cisco Systems Message-ID: <016401c335a4$3e879f10$ed472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <313680C9A886D511A06000204840E1CF0742CCF1@whq-msgusr-02.pit.comms.marconi.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Choudhury, Sanjaya > Sent: Monday, June 16, 2003 7:10 PM > To: mpls@UU.NET > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTa ble] > > > Comments in-line. > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Monday, June 16, 2003 2:05 PM > > To: 'Choudhury, Sanjaya'; mpls@UU.NET > > Subject: RE: prequeal to WG lat call om the LSR mib > > module[mplsInSegmentTa ble] > > > > > > > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > Of Choudhury, Sanjaya > > > Sent: Friday, June 13, 2003 9:07 AM > > > To: mpls@UU.NET > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > module[mplsInSegmentTa ble] > > > > > > > > > Hi! I am open to all changes that will make the MIB > > > efficient for users, but I think it is not a bad > > > idea to examine the alternative solutions. Here > > > are some thoughts: > > > > > > Some of the cases, where NMS might use a GetNext() > > > on mplsInSegment table: > > > ------------------------------------------------- > > > > > > Case-1:: If the aim of the NMS is to get the next > > > 'best/free' label, to configure the next mplsInSegment, > > > then he may encounter a (potential) O(n) search of > > > the mplsInSegmentTable. > > > > > > We can resolve this issue, by adding a new table: > > > mplsNextFreeLabelTable [indexed by ifIndex] > > > > > > If ifIndex == 0 : the row indicates the > > > next free platform-label-space label > > > > > > If ifIndex !=0 : the row indicates the > > > next free interface-label-space label for > > > the specified interface. > > > > > This solution, will address the efficiency > > > issue, without compromising the natural > > > indexing of the mplsInSegmentTable. > > > > I disagree. It seems that you consider > > the old indexing efficient, which I clearly do not. > > Here I was just trying find an alternative solution > to the proposed index change for the > mplsInSegmentTable. > > [Note: Here we are talking about case-1 as described above.] > > o Do you agree that the solution I proposed > provides the users of mplsInSegmentTable > with an efficient solution for looking up > the next free/best label [O(C)] ? Yes, this solution will indeed work with the proposed indexing changes. > o With the solution proposed in the latest > version of LSR-MIB, user for case-1 might > get the similar efficiency (as the one > I proposed); BUT it depends on the vendor > implementations. > Unless, everybody implement the mplsInSegmentIndex > the same way, user will face the same inefficiencies. > > o I think the solution I proposed has the > following advantages: > (i) the solution does leaves the index > as is [ifIndex,label], which is natural > for the mplsInSegmentTable > (ii) the solution is implementation > independent [does not depend on the way > a vendor implements the new mplsInSegmentIndex] But this is at the crux of the problem. There have been several NMS vendors that have chimed in already stating that they are okay with the new proposed indexing of a single octet string. They have stated that they don't care about "natural" indexing; rather, they want fast, efficient retrieval from this MIB because it can potentially contain hundreds of thousands of entries. > > > Case-2: If the aim of the NMS is to show/list all > > > the incoming-mpls-segments, on a per-interface basis, > > > the GetNext() works perfectly with the original indexing > > > (ifIndex,label) > > > > Only for a non-distributed implementation. > > Please see prior threads as to why this works at > > best O(N), and is more likely O(N^2) on distributed implementations. > > > Note that the case-2, is addressing the case > where the NMS is trying to display the insegments > on a *per-interface* basis. The NMS can do this using the new indexing, but it has been my experience that this is rarely done if ever due to the size of the LSR MIB and the rate at which entries change therein. It is more likely that the NMS will want to display entries from the MIB for trouble-shooting based on information it gathered elsewhere (i.e.: PPPVPN-MPLS-VPN MIB) and then use this to "walk" the LSP, or look at counters for the IGP label. > o When NMS is trying to display/query insegments > on a per-interface basis, don't you think a > (ifIndex,label) index is perfect ?? No. It is not something that I have seen as being anything adventageous in the 4 years I have had an implementation. As a matter of fact, it has been a problem because it makes returning the entire table less efficient due to the fact that the implementation has to a) do more work to return entries in this way, and b) returns redundant entries. For example, when using LDP DoD unordered, you often distribute the same labels to all LDP neighbors for the same FEC. This means that you can receive traffic from that FEC's label on any per-platform interface. Thus, the MIB needs to return numIfs * numLabels things, while it really should just return ifIndex=0 * numLabels things. > o The worst case here is for a node that supports > only per-platform labels i.e O(n). But this > worst case number is same for both the solutions > (proposed in LSR-MIB-v10 and in this e-mail) > o In distributed cases, it may be O(n) * num-app > in the worst case. Yup, and this is significant on a box that contains LDP labels for each of the internet routes, plus VPNv4, VPNv6, TE, and PWE3 labels. In this case N = 2-300,000. You must surely consider O(N) the to be be pretty big. This is why I am advocating a longer index so that appliations are free to return items in O(1). O(1) is SIGNIFICANTLY faster than O(N) time for real LSR implementations! > > > Case-3: If the aim of the NMS is to show ALL the > > > incoming segments or access ALL the incoming > > > segments, he will need to walk the whole table > > > and indexing does not matter. > > > > Indexing always matters! If I care about this > > case and can walk the entire table in 1 hour versus > > 2-4 minutes, that makes a BIG difference. The > > compromise that Adrian and I sent out addresses > > all of these concerns AND is efficient. > > > > Please note: Case-3 captures the case where the > user is NMS is trying to show _ALL_ the insegments. > > o If a table has n rows and one wants to > query all the n rows, the cost will be > O(n). Correct ? > > o How can I query _ALL_ the n rows from a table > more efficiently by the choice of indexing?? > [i.e better than O(n)] Because if each query is O(1), then your mib walk will take O(1) * O(N). If your MIB walk takes O(N) * num applications, then your MIB walks will take you O(N) * O(N) -> O(N^2). Now remember how big N gets for a large implementation like mine. Then you will quickly realize why I (and the NMS vendors who have chimed in) want me to return my entires in O(1) time! --Tom > > Thanks, > sanjay > > > > > --Tom > > > > > > > Thanks, > > > sanjay > > > > > > > > > > > > > -----Original Message----- > > > > From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com] > > > > Sent: Thursday, June 12, 2003 10:11 AM > > > > To: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET > > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > > module[mplsInSegmentTa ble] > > > > > > > > > > > > As a provider of management solutions... We'd "prefer" > > > > to have a simple solution but we MUST have a working solution. > > > > Although the proposed change makes the instancing a bit > > > more complex, > > > > the getnext performance of the current mplsXCTable is so > > > slow that its > > > > practically unreadable in any reasonably sized network. > > > > > > > > Mike Shevenell > > > > Aprisma Management Technologies > > > > > > > > -----Original Message----- > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > Sent: Wednesday, June 11, 2003 10:35 AM > > > > To: 'Choudhury, Sanjaya'; mpls@UU.NET > > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > > module[mplsInSegmentTable] > > > > > > > > > -----Original Message----- > > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > > > Of Choudhury, Sanjaya > > > > > Sent: Tuesday, June 10, 2003 12:06 PM > > > > > To: 'mpls@UU.NET' > > > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > > > module[mplsInSegmentTable] > > > > > > > > > > > > > > > Hi! Few comments in-line regarding the indexing of the > > > > > mplsInSegmentTable > > > > > > > > > > > -----Original Message----- > > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > Sent: Saturday, June 07, 2003 9:13 AM > > > > > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > -----Original Message----- > > > > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On > > > Behalf Of > > > > > > > Wijnen, Bert (Bert) > > > > > > > Sent: Friday, June 06, 2003 11:14 AM > > > > > > > To: MPLS WG > > > > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > > > > > > > > > > > > > > > > > > > > > stuff deleted... > > > > > > > > The problem with designing in the ideal is that > > > > real implementations will have issues with it. The > > > > IETF generally considers implementation and deployment > > > > experience highly over the ideal. I have provided some > > > > real world feedback that indicates that a single Unsigned32 > > > > index is insufficient. I also have about 300 customers > > > > that have provided me with the same feedback. I think that > > > > it has little to do with my specific style of implementation > > > > either (see below). > > > > more stuff deleted.. > > > > > > > > --Tom > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Jun 19 07:13:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08645 for ; Thu, 19 Jun 2003 07:13:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottc24085 for ; Thu, 19 Jun 2003 11:13:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQottc23484; Thu, 19 Jun 2003 11:13:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQotqi14003 for mpls-outgoing; Wed, 18 Jun 2003 17:08:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotqi13955 for ; Wed, 18 Jun 2003 17:07:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotqi09966 for ; Wed, 18 Jun 2003 17:06:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotqi05031 for ; Wed, 18 Jun 2003 17:06:59 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQotqi05011 for ; Wed, 18 Jun 2003 17:06:58 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5IH6mn13551; Wed, 18 Jun 2003 13:06:49 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 13:06:49 -0400 Message-ID: From: "Hamid Ould-Brahim" To: Loa Andersson , Kireeti Kompella Cc: MPLS WG , Alex Zinin , Bert Wijnen , George Swallow Subject: RE: mpls wg at IETF 57 in Vienna Date: Wed, 18 Jun 2003 13:06:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C335BC.0105CA0A" 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_01C335BC.0105CA0A Content-Type: text/plain; charset="iso-8859-1" Loa, I like your typos. At least they are entertaining ;-). Hamid. > > > OK - I confess - I thought that I sent both the ppvpn and mpls > agenda mails at the same time, but found that I hadn't :( > > so it is (for once not a typo - it a cut and paste error) > > I think we not should follow Kireetis advice and double post the > requests for time slots - risk is that I'll give you a slot on > the wrong agenda :) (typos you know ;) ) > > /Loa > > Kireeti Kompella wrote: > > On Tue, 17 Jun 2003, Loa Andersson wrote: > > > > > >>If you request a time slot, please follow up and start an email > >>discussion on the ppvpn list. > > > > > > And, for grins, on the MPLS list as well. > > > > Or vice versa :-) > > > > Kireeti. > > > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > > ------_=_NextPart_001_01C335BC.0105CA0A Content-Type: text/html; charset="iso-8859-1"

Loa,

I like your typos. At least they are entertaining ;-).

Hamid.


>
>
> OK - I confess - I thought that I sent both the ppvpn and mpls
> agenda mails at the same time, but found that I hadn't :(
>
> so it is (for once not a typo - it a cut and paste error)
>
> I think we not should follow Kireetis advice and double post the
> requests for time slots - risk is that I'll give you a slot on
> the wrong agenda :) (typos you know ;) )
>
> /Loa
>
> Kireeti Kompella wrote:
> > On Tue, 17 Jun 2003, Loa Andersson wrote:
> >
> >
> >>If you request a time slot, please follow up and start an email
> >>discussion on the ppvpn list.
> >
> >
> > And, for grins, on the MPLS list as well.
> >
> > Or vice versa :-)
> >
> > Kireeti.
> >
> >
>
>
> --
> /Loa
>
> mobile + 46 739 81 21 64
> email: loa@pi.se
>
>

------_=_NextPart_001_01C335BC.0105CA0A-- From owner-mpls@UU.NET Thu Jun 19 07:16:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08716 for ; Thu, 19 Jun 2003 07:16:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottd28767 for ; Thu, 19 Jun 2003 11:16:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQottd28203; Thu, 19 Jun 2003 11:15:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQotql17623 for mpls-outgoing; Wed, 18 Jun 2003 17:47:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotql17618 for ; Wed, 18 Jun 2003 17:47:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotqk24609 for ; Wed, 18 Jun 2003 17:42:34 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotqk26514 for ; Wed, 18 Jun 2003 17:42:34 GMT Received: from kcmso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso1.att.com [192.128.133.69]) id QQotqk26508 for ; Wed, 18 Jun 2003 17:42:33 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5IHda6v021135 for ; Wed, 18 Jun 2003 12:42:33 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C001F40EE; Wed, 18 Jun 2003 13:42:29 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Wed, 18 Jun 2003 12:42:33 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA011BEA31@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG lat call on LSR and LDP MIB modules - setting dates Thread-Index: AcMwvo69ayfmybo0R6SDCEKbpC4cTAANNqBQATAhrUA= From: "Ash, Gerald R (Jerry), ALABS" To: "Wijnen, Bert (Bert)" , "Loa Andersson" , "MPLS WG" Cc: "Ash, Gerald R (Jerry), ALABS" , "Lai, Wai S (Waisum), ALABS" , "Chung, Li-Jin W, ALABS" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA08716 Bert, Loa, All, I'd like to follow up on Wai Sum's comments below, and encourage that high-priority MPLS-MIB problems/requirements identified through extensive testing be addressed in the MPLS MIB modules. The MPLS MIB problems/requirements are identified in http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, and are critical operator requirements stemming from detailed lab testing by Li Chung and others at AT&T. MPLS-VPNs aren't going to operate as well as needed until and unless these requirements are met. It is expected that operators wishing to use the same MPLS MIBs would have similar concerns. The I-D does not propose specific MIB extensions based on the requirements. Rather, such extensions are left to the MIB designers, in order to avoid past discussions of why specific extensions won't work. But so far there is no help or response from MIB designers on how to meet the requirements, even though the problems have been identified on email lists for more than one year. Here is a summary of requirements (R1,R2,R3 LDP related; R4,R5 VPN related): R1. It is required to capture the signaling usage/performance of the LDP Entities, as well as the traffic usage/performance of the LDP Sessions. R2. It is required to ensure persistency of information in the LDP-MIB Entity Table and Entity Statistics Table, whenever an LDP Entity is disabled and then re-enabled. R3. It is required that a count be reported of mplsNumVrfRouteMaxThreshExceeded notification when the operator-defined VRF maximum route threshold is exceeded. R4. It is required to have an explicit mapping between VRF, RD, and RT in the mplsVpnVrfRouteTargetTable table. R5. It is required to track the number of BGP prefixes on the PE-CE link, and that the BGP neighbor maximum-prefix limit on the PE-CE link be used to limit the number of eBGP routes injected in the VRF. I agree with Harmen Van der Linde, "We need to get this MPLS MIB module, together with the MPLS LDP and MPLS VPN modules, standardized ASAP. There is a critical need for these MPLS MIB modules for management of MPLS-enabled networks, which are currently being deployed by many service providers." Bert threatened at IETF-56 to start over on MPLS MIBs if not finished by IETF-57. We need the MPLS MIB designers to meet critical requirements and complete ASAP. Thanks, Jerry -----Original Message----- From: Lai, Wai S (Waisum), ALABS Sent: Thursday, June 12, 2003 2:52 PM To: Loa Andersson; MPLS WG Cc: Chung, Li-Jin W, ALABS; Ash, Gerald R (Jerry), ALABS Subject: RE: WG last call on LSR and LDP MIB modules - setting dates I would like to bring to your attention, once again, the requirements in http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt For the LDP and possibly the LSR MIBs, requirements are specified in the above I-D, which include, for example, requirements for performance and fault management so as to lessen dependence on the NMS. Such capabilities should be considered based on the requirements, and if appropriate, should be included in the appropriate MIBs. Thanks, Wai Sum -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, June 12, 2003 4:24 AM To: MPLS WG Subject: WG last call on LSR and LDP MIB modules - setting dates Folks, the time for this wg call has been extended to June 24th noon CET. /Loa -------- Original Message -------- Subject: Re: WG last call on LSR and LDP MIB modules - CORRECTION! Date: Tue, 10 Jun 2003 08:12:00 +0200 From: Loa Andersson To: MPLS WG CC: Loa Andersson , Bert Wijnen , Alex Zinin All, a misunderstanding between me and the authors resulted in that the wrong version of the LDP mib module was sent to this wg last call. The correct version is this has just been sent for publication (and with a copy to the mailing list). My take is that we continue the wg last call as planned, but as soon as I see the LDP mib being published I will extend the last call period. This way will get both a head start and the required period of time. /Loa Loa Andersson wrote: > All, > > this is to initiate a two week wg last call on > > Multiprotocol Label Switching (MPLS) Label Switching > Router (LSR) Management Information Base > > > and > Definitions of Managed Objects for the Multiprotocol Label > Switching, Label Distribution Protocol (LDP) > > > this wg last call ends June 22nd, and is limited to the changes in the > IDs since the previous wg last call, as well as interdependencies between > the two mib modules and the mib modules listed below. > > For the LSR MIB please re-read the mail I sent to the list June 6 called > "prequeal to WG last call on the LSR mib module" > > A usual silence will be understood as support, but this would not > necessarily stop you from giving positive comments. Please do. > > There are more MIB modules coming up for wg last call and that have been > through wg last call, all of those will have interdependencies. > > 1. the TC mib module are wg last called and updated, but waiting for the > others to be ready for IESG review > > 2. the TE link MIB module is in wg last call (to end June 13) > > 3. the management overview has been through wg last call and has been > updated > > > Two other MIB modules are in the pipe and new version will be released > shortly > > 5. The TE mib module > 6. The FTN mib module > > It is important that we complete this process of reviewing and updating > before the ID cut off date (June 30) for the Vienna meeting. From owner-mpls@UU.NET Thu Jun 19 07:17:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08742 for ; Thu, 19 Jun 2003 07:17:55 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottd01870 for ; Thu, 19 Jun 2003 11:17:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQottd00941; Thu, 19 Jun 2003 11:17:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQotqm06390 for mpls-outgoing; Wed, 18 Jun 2003 18:06:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotqm06087 for ; Wed, 18 Jun 2003 18:06:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotqm04481 for ; Wed, 18 Jun 2003 18:06:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotqm06379 for ; Wed, 18 Jun 2003 18:06:07 GMT Received: from sj-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-1.cisco.com [171.71.177.237]) id QQotqm06366 for ; Wed, 18 Jun 2003 18:06:07 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5II63Ta014781 for ; Wed, 18 Jun 2003 11:06:03 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC63436; Wed, 18 Jun 2003 14:06:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5II62G08579 for mpls@uu.net; Wed, 18 Jun 2003 14:06:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotqm29539 for ; Wed, 18 Jun 2003 18:04:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotqm25976 for ; Wed, 18 Jun 2003 18:04:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotqm02124 for ; Wed, 18 Jun 2003 18:04:12 GMT Received: from sj-core-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-5.cisco.com [171.71.177.238]) id QQotqm02081 for ; Wed, 18 Jun 2003 18:04:12 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5II3mUm024175; Wed, 18 Jun 2003 11:03:49 -0700 (PDT) Received: from tnadeauw2k (che-vpn-cluster-1-37.cisco.com [10.86.240.37]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC63326; Wed, 18 Jun 2003 14:03:47 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Wijnen, Bert \(Bert\)'" , "'Loa Andersson'" , "'MPLS WG'" Cc: "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" , , "'Van der Linde, Harmen, ALABS'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Wed, 18 Jun 2003 14:03:33 -0400 Organization: Cisco Systems Message-ID: <01bf01c335c3$f2fb82d0$ed472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA011BEA31@KCCLUST06EVS1.ugd.att.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jerry, I do fully agree with Harmen's statement that the MIBs need to be wrapped up ASAP and appreciate his feedback as an operator. I think that we are well on this track. To address your statement about requirements, as discussed previously offline with yourself and the MIB co-authors, many of the requirements you listed below require changes to the LDP protocol itself. Given this, I suggest that you consult with other SPs in the WG on these requirements to make sure that they are consistent. I personally have not been hearing any of these requirements from other SPs that participate in the MPLS WG. In addition, I suggest that you direct your requirements to the authors of the LDP specifications and propose extensions/additions there first because the MIBs cannot manage what the protocols will not provide. The remaining requirements you listed below apply specifically to the PPVPN-MPLS-VPN MIB and not to the base MPLS MIBs which are in WG last call presently. --Tom > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: Wednesday, June 18, 2003 1:43 PM > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > Bert, Loa, All, > > I'd like to follow up on Wai Sum's comments below, and > encourage that high-priority MPLS-MIB problems/requirements > identified through extensive testing be addressed in the MPLS > MIB modules. > > The MPLS MIB problems/requirements are identified in > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.tx > t, and are critical operator requirements stemming from > detailed lab testing by Li Chung and others at AT&T. > MPLS-VPNs aren't going to operate as well as needed until and > unless these requirements are met. It is expected that > operators wishing to use the same MPLS MIBs would have > similar concerns. > > The I-D does not propose specific MIB extensions based on the > requirements. Rather, such extensions are left to the MIB > designers, in order to avoid past discussions of why specific > extensions won't work. But so far there is no help or > response from MIB designers on how to meet the requirements, > even though the problems have been identified on email lists > for more than one year. > > Here is a summary of requirements (R1,R2,R3 LDP related; > R4,R5 VPN related): > > R1. It is required to capture the signaling usage/performance > of the LDP Entities, as well as the traffic usage/performance > of the LDP Sessions. R2. It is required to ensure persistency > of information in the LDP-MIB Entity Table and Entity > Statistics Table, whenever an LDP Entity is disabled and then > re-enabled. R3. It is required that a count be reported of > mplsNumVrfRouteMaxThreshExceeded notification when the > operator-defined VRF maximum route threshold is exceeded. R4. > It is required to have an explicit mapping between VRF, RD, > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is > required to track the number of BGP prefixes on the PE-CE > link, and that the BGP neighbor maximum-prefix limit on the > PE-CE link be used to limit the number of eBGP routes > injected in the VRF. > > I agree with Harmen Van der Linde, "We need to get this MPLS > MIB module, together with the MPLS LDP and MPLS VPN modules, > standardized ASAP. There is a critical need for these MPLS > MIB modules for management of MPLS-enabled networks, which > are currently being deployed by many service providers." > > Bert threatened at IETF-56 to start over on MPLS MIBs if not > finished by IETF-57. > > We need the MPLS MIB designers to meet critical requirements > and complete ASAP. > > Thanks, > Jerry > > -----Original Message----- > From: Lai, Wai S (Waisum), ALABS > Sent: Thursday, June 12, 2003 2:52 PM > To: Loa Andersson; MPLS WG > Cc: Chung, Li-Jin W, ALABS; Ash, Gerald R (Jerry), ALABS > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > I would like to bring to your attention, once again, the > requirements in > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt > > For the LDP and possibly the LSR MIBs, requirements are > specified in the above I-D, which include, for example, > requirements for performance and fault management so as to > lessen dependence on the NMS. Such capabilities should be > considered based on the requirements, and if appropriate, > should be included in the appropriate MIBs. > > Thanks, Wai Sum > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Thursday, June 12, 2003 4:24 AM > To: MPLS WG > Subject: WG last call on LSR and LDP MIB modules - setting dates > > Folks, > > the time for this wg call has been extended to June 24th noon CET. > > /Loa > > -------- Original Message -------- > Subject: Re: WG last call on LSR and LDP MIB modules - CORRECTION! > Date: Tue, 10 Jun 2003 08:12:00 +0200 > From: Loa Andersson > To: MPLS WG > CC: Loa Andersson , Bert Wijnen , Alex > Zinin > > All, > > a misunderstanding between me and the authors resulted in > that the wrong version of the LDP mib module was sent to this > wg last call. > > The correct version is > > > > this has just been sent for publication (and with a copy to > the mailing list). > > My take is that we continue the wg last call as planned, but > as soon as I see the LDP mib being published I will extend > the last call period. This way will get both a head start and > the required period of time. > > /Loa > > Loa Andersson wrote: > > > All, > > > > this is to initiate a two week wg last call on > > > > Multiprotocol Label Switching (MPLS) Label Switching > > Router (LSR) Management Information Base > > > > > > and > > Definitions of Managed Objects for the Multiprotocol Label > > Switching, Label Distribution Protocol (LDP) > > > > > > this wg last call ends June 22nd, and is limited to the > changes in the > IDs since the previous wg last call, as > well as interdependencies between > the two mib modules and > the mib modules listed below. > > For the LSR MIB please > re-read the mail I sent to the list June 6 called > > "prequeal to WG last call on the LSR mib module" > > A > usual silence will be understood as support, but this would > not > necessarily stop you from giving positive comments. > Please do. > > There are more MIB modules coming up for wg > last call and that have been > through wg last call, all of > those will have interdependencies. > > 1. the TC mib module > are wg last called and updated, but waiting for the > > others to be ready for IESG review > > > > 2. the TE link MIB module is in wg last call (to end June 13) > > > > 3. the management overview has been through wg last call > and has been > > updated > > > > > > Two other MIB modules are in the pipe and new version will > be released > shortly > > 5. The TE mib module > > 6. The FTN mib module > > > It is important that > we complete this process of reviewing and updating > before > the ID cut off date (June 30) for the Vienna meeting. > > > From owner-mpls@UU.NET Thu Jun 19 07:22:44 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08838 for ; Thu, 19 Jun 2003 07:22:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottd12102 for ; Thu, 19 Jun 2003 11:22:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQottd11567; Thu, 19 Jun 2003 11:22:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQotqy07389 for mpls-outgoing; Wed, 18 Jun 2003 21:01:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotqy05419 for ; Wed, 18 Jun 2003 21:01:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotqy19708 for ; Wed, 18 Jun 2003 21:01:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotqy29344 for ; Wed, 18 Jun 2003 21:00:57 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQotqy29321 for ; Wed, 18 Jun 2003 21:00:51 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h5IL0ou79488; Wed, 18 Jun 2003 14:00:50 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h5IL0oe79652; Wed, 18 Jun 2003 14:00:50 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 18 Jun 2003 14:00:50 -0700 (PDT) From: Kireeti Kompella To: Adrian Farrel cc: iesg@ietf.org, "" Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard In-Reply-To: <0aa001c335cb$610e5bb0$681810ac@movaz.com> Message-ID: <20030618124901.I79256@kummer.juniper.net> References: <07b701c331f1$ffeeb820$681810ac@movaz.com> <0aa001c335cb$610e5bb0$681810ac@movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 18 Jun 2003, Adrian Farrel wrote: > Did anyone decide there was an error here, or is this draft really in IETF last > call? Harald is looking into it, which is pretty cool. I'm hoping he'll let us know what he learns when he does. Meanwhile, I'm assuming there isn't an IETF-wide Last Call. Haven't seen any mail on the IETF list (although I could easily have missed it among the myths, CLOSE ASRGs and WG Reviews ...) Kireeti. From owner-mpls@UU.NET Thu Jun 19 07:23:13 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08862 for ; Thu, 19 Jun 2003 07:23:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottd13210 for ; Thu, 19 Jun 2003 11:23:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQottd12793; Thu, 19 Jun 2003 11:23:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQotqp11481 for mpls-outgoing; Wed, 18 Jun 2003 18:57:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotqp11459 for ; Wed, 18 Jun 2003 18:57:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotqp13840 for ; Wed, 18 Jun 2003 18:56:53 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotqp00153 for ; Wed, 18 Jun 2003 18:56:52 GMT Received: from jera.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQotqp00136 for ; Wed, 18 Jun 2003 18:56:52 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id D5EB517D2; Wed, 18 Jun 2003 14:56:51 -0400 (EDT) Message-ID: <0aa001c335cb$610e5bb0$681810ac@movaz.com> From: "Adrian Farrel" To: , Cc: References: <07b701c331f1$ffeeb820$681810ac@movaz.com> Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard Date: Wed, 18 Jun 2003 14:56:51 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Did anyone decide there was an error here, or is this draft really in IETF last call? Thanks Adrian ----- Original Message ----- From: "Adrian Farrel" To: ; Cc: Sent: Friday, June 13, 2003 5:23 PM Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard > With respect, this draft doesn't appear to have been through WG last call > (unless I was sleeping, but I can't find any reference in the mail archive). > > It was only published as a WG draft on 5/7/2003 (despite carrying a date of > February 2003). > > While I support the draft, I would like to see it discussed on the mailing list > and go through WG last call. > > Thanks, > Adrian > > ----- Original Message ----- > From: "The IESG" > To: > Cc: > Sent: Friday, June 13, 2003 1:59 PM > Subject: Last Call: LDP DoD Graceful Restart to Draft Standard > > > > --------------- > > The IESG has received a request from Multiprotocol Label Switching to > > consider the following Internet-Draft(s) as Draft Standard. > > o Multiprotocol Label Switching (MPLS): LDP DoD Graceful Restart > > > > Draft Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by . > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.txt > > > > From owner-mpls@UU.NET Thu Jun 19 07:29:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08939 for ; Thu, 19 Jun 2003 07:29:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottd25669 for ; Thu, 19 Jun 2003 11:29:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQottd25424; Thu, 19 Jun 2003 11:28:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQotqq29337 for mpls-outgoing; Wed, 18 Jun 2003 19:03:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotqq27381 for ; Wed, 18 Jun 2003 19:03:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotqq11639 for ; Wed, 18 Jun 2003 19:02:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotqq28046 for ; Wed, 18 Jun 2003 19:02:16 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQotqq28041 for ; Wed, 18 Jun 2003 19:02:15 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16946 for ; Wed, 18 Jun 2003 15:02:13 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04506 for ; Wed, 18 Jun 2003 15:02:15 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 15:02:14 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0742CCF9@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: mpls@UU.NET Subject: RE: prequeal to WG lat call om the LSR mib module[mplsInSegmentTa ble] Date: Wed, 18 Jun 2003 15:02:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, June 18, 2003 10:17 AM > To: 'Choudhury, Sanjaya'; mpls@UU.NET > Subject: RE: prequeal to WG lat call om the LSR mib > module[mplsInSegmentTa ble] > > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > Of Choudhury, Sanjaya > > Sent: Monday, June 16, 2003 7:10 PM > > To: mpls@UU.NET > > Subject: RE: prequeal to WG lat call om the LSR mib > > module[mplsInSegmentTa ble] > > > > > > Comments in-line. > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Monday, June 16, 2003 2:05 PM > > > To: 'Choudhury, Sanjaya'; mpls@UU.NET > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > module[mplsInSegmentTa ble] > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > > Of Choudhury, Sanjaya > > > > Sent: Friday, June 13, 2003 9:07 AM > > > > To: mpls@UU.NET > > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > > module[mplsInSegmentTa ble] > > > > > > > > > > > > Hi! I am open to all changes that will make the MIB > > > > efficient for users, but I think it is not a bad > > > > idea to examine the alternative solutions. Here > > > > are some thoughts: > > > > > > > > Some of the cases, where NMS might use a GetNext() > > > > on mplsInSegment table: > > > > ------------------------------------------------- > > > > > > > > Case-1:: If the aim of the NMS is to get the next > > > > 'best/free' label, to configure the next mplsInSegment, > > > > then he may encounter a (potential) O(n) search of > > > > the mplsInSegmentTable. > > > > > > > > We can resolve this issue, by adding a new table: > > > > mplsNextFreeLabelTable [indexed by ifIndex] > > > > > > > > If ifIndex == 0 : the row indicates the > > > > next free platform-label-space label > > > > > > > > If ifIndex !=0 : the row indicates the > > > > next free interface-label-space label for > > > > the specified interface. > > > > > > > This solution, will address the efficiency > > > > issue, without compromising the natural > > > > indexing of the mplsInSegmentTable. > > > > > > I disagree. It seems that you consider > > > the old indexing efficient, which I clearly do not. > > > > Here I was just trying find an alternative solution > > to the proposed index change for the > > mplsInSegmentTable. > > > > [Note: Here we are talking about case-1 as described above.] > > > > o Do you agree that the solution I proposed > > provides the users of mplsInSegmentTable > > with an efficient solution for looking up > > the next free/best label [O(C)] ? > > Yes, this solution will indeed work with > the proposed indexing changes. > > > o With the solution proposed in the latest > > version of LSR-MIB, user for case-1 might > > get the similar efficiency (as the one > > I proposed); BUT it depends on the vendor > > implementations. > > Unless, everybody implement the mplsInSegmentIndex > > the same way, user will face the same inefficiencies. > > > > o I think the solution I proposed has the > > following advantages: > > (i) the solution does leaves the index > > as is [ifIndex,label], which is natural > > for the mplsInSegmentTable > > (ii) the solution is implementation > > independent [does not depend on the way > > a vendor implements the new mplsInSegmentIndex] > > But this is at the crux of the problem. There have > been several NMS vendors that have chimed in already > stating that they are okay with the new proposed > indexing of a single octet string. They have stated > that they don't care about "natural" indexing; rather, > they want fast, efficient retrieval from this MIB because > it can potentially contain hundreds of thousands of entries. The solution I proposed, is as fast and as efficient as the octet-string indexing solution [for getting the next free label] In addition to being efficient, this solution (i) does NOT depend on vendor's implementation of the octet-string index.[ Which is good for NMS vendors.] (ii) leaves the MIB table design clean (iii) and changes to the existing MIB and NMS implementations are incremental > > > > > Case-2: If the aim of the NMS is to show/list all > > > > the incoming-mpls-segments, on a per-interface basis, > > > > the GetNext() works perfectly with the original indexing > > > > (ifIndex,label) > > > > > > Only for a non-distributed implementation. > > > Please see prior threads as to why this works at > > > best O(N), and is more likely O(N^2) on distributed > implementations. > > > > > Note that the case-2, is addressing the case > > where the NMS is trying to display the insegments > > on a *per-interface* basis. > > The NMS can do this using the new indexing, but > it has been my experience that this is rarely done if > ever due to the size of the LSR MIB and the rate > at which entries change therein. It is more likely > that the NMS will want to display entries from the > MIB for trouble-shooting based on information > it gathered elsewhere (i.e.: PPPVPN-MPLS-VPN MIB) > and then use this to "walk" the LSP, or look at > counters for the IGP label. > > > o When NMS is trying to display/query insegments > > on a per-interface basis, don't you think a > > (ifIndex,label) index is perfect ?? > > No. It is not something that I have seen > as being anything adventageous in the 4 years I have > had an implementation. As a matter of fact, it has > been a problem because it makes returning the > entire table less efficient due to the fact that > the implementation has to a) do more work to return > entries in this way, and b) returns redundant entries. > For example, when using LDP DoD unordered, you often > distribute the same labels to all LDP neighbors > for the same FEC. This means that you can receive > traffic from that FEC's label on any per-platform > interface. Thus, the MIB needs to return numIfs * numLabels > things, while it really should just return ifIndex=0 * > numLabels things. > > > o The worst case here is for a node that supports > > only per-platform labels i.e O(n). But this > > worst case number is same for both the solutions > > (proposed in LSR-MIB-v10 and in this e-mail) > > > o In distributed cases, it may be O(n) * num-app > > in the worst case. > > Yup, and this is significant on a box that > contains LDP labels for each of the internet routes, > plus VPNv4, VPNv6, TE, and PWE3 labels. In this case > N = 2-300,000. You must surely consider O(N) the > to be be pretty big. This is why I > am advocating a longer index so that appliations > are free to return items in O(1). O(1) is SIGNIFICANTLY > faster than O(N) time for real LSR implementations! Of course O(1) is better than O(n) ! But, I think we are talking about two different things here. In this case [case-2, bullet2], there are n entries in the the table and user wants to retrieve all the n entries. [See my next response below] > > > > > Case-3: If the aim of the NMS is to show ALL the > > > > incoming segments or access ALL the incoming > > > > segments, he will need to walk the whole table > > > > and indexing does not matter. > > > > > > Indexing always matters! If I care about this > > > case and can walk the entire table in 1 hour versus > > > 2-4 minutes, that makes a BIG difference. The > > > compromise that Adrian and I sent out addresses > > > all of these concerns AND is efficient. > > > > > > > Please note: Case-3 captures the case where the > > user is NMS is trying to show _ALL_ the insegments. > > > > o If a table has n rows and one wants to > > query all the n rows, the cost will be > > O(n). Correct ? > > > > o How can I query _ALL_ the n rows from a table > > more efficiently by the choice of indexing?? > > [i.e better than O(n)] > > Because if each query is O(1), then your > mib walk will take O(1) * O(N). If your MIB > walk takes O(N) * num applications, then > your MIB walks will take you O(N) * O(N) -> O(N^2). > Now remember how big N gets for a large implementation > like mine. Then you will quickly realize why I > (and the NMS vendors who have chimed in) want > me to return my entires in O(1) time! -If the MIB table has n entries and user wants to retrieve _all_ n entries then the *LOWER* BOUND is O(n) and NOT O(1) -MIB walk of mplsInSegmentTable[LSR-MIB09] is a problem with complexity O(n). There are implementations out there that can perform the operation in O(n) and few can't. In this case, don't you think we should address the performance issue in individual implementations, rather than changing the table itself [And changing all the implementations]. In my opinion, we should change the MIB, only if the problem is with the MIB. -Getting the next free label was indeed a problem with the existing MIB, and can be addressed as described above [see case-1 above. cost O(1)] Anyway, these were all of my comments on the indexing of the mplsInSegmentTable in LSR-MIB-10. Hope it was helpful. Thanks, sanjay > --Tom > > > > > > Thanks, > > sanjay > > > > > > > > > --Tom > > > > > > > > > > Thanks, > > > > sanjay > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com] > > > > > Sent: Thursday, June 12, 2003 10:11 AM > > > > > To: 'tnadeau@cisco.com'; 'Choudhury, Sanjaya'; mpls@UU.NET > > > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > > > module[mplsInSegmentTa ble] > > > > > > > > > > > > > > > As a provider of management solutions... We'd "prefer" > > > > > to have a simple solution but we MUST have a working > solution. > > > > > Although the proposed change makes the instancing a bit > > > > more complex, > > > > > the getnext performance of the current mplsXCTable is so > > > > slow that its > > > > > practically unreadable in any reasonably sized network. > > > > > > > > > > Mike Shevenell > > > > > Aprisma Management Technologies > > > > > > > > > > -----Original Message----- > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > Sent: Wednesday, June 11, 2003 10:35 AM > > > > > To: 'Choudhury, Sanjaya'; mpls@UU.NET > > > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > > > module[mplsInSegmentTable] > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > > > > > > Of Choudhury, Sanjaya > > > > > > Sent: Tuesday, June 10, 2003 12:06 PM > > > > > > To: 'mpls@UU.NET' > > > > > > Subject: RE: prequeal to WG lat call om the LSR mib > > > > > > module[mplsInSegmentTable] > > > > > > > > > > > > > > > > > > Hi! Few comments in-line regarding the indexing of the > > > > > > mplsInSegmentTable > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > > Sent: Saturday, June 07, 2003 9:13 AM > > > > > > > To: 'Wijnen, Bert (Bert)'; 'MPLS WG' > > > > > > > Subject: RE: prequeal to WG lat call om the LSR mib module > > > > > > > > -----Original Message----- > > > > > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On > > > > Behalf Of > > > > > > > > Wijnen, Bert (Bert) > > > > > > > > Sent: Friday, June 06, 2003 11:14 AM > > > > > > > > To: MPLS WG > > > > > > > > Subject: RE: prequeal to WG lat call om the LSR > mib module > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > stuff deleted... > > > > > > > > > > The problem with designing in the ideal is that > > > > > real implementations will have issues with it. The > > > > > IETF generally considers implementation and deployment > > > > > experience highly over the ideal. I have provided some > > > > > real world feedback that indicates that a single Unsigned32 > > > > > index is insufficient. I also have about 300 customers > > > > > that have provided me with the same feedback. I think that > > > > > it has little to do with my specific style of implementation > > > > > either (see below). > > > > > more stuff deleted.. > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Jun 19 07:29:35 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08974 for ; Thu, 19 Jun 2003 07:29:35 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottd26567 for ; Thu, 19 Jun 2003 11:29:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQottd26341; Thu, 19 Jun 2003 11:29:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQotrk25096 for mpls-outgoing; Thu, 19 Jun 2003 00:09:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotrk25059 for ; Thu, 19 Jun 2003 00:08:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotrk08199 for ; Thu, 19 Jun 2003 00:08:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotrk02189 for ; Thu, 19 Jun 2003 00:08:45 GMT Received: from psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: psg.com [147.28.0.62]) id QQotrk02175 for ; Thu, 19 Jun 2003 00:08:45 GMT Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19Smyq-000EI6-1j; Thu, 19 Jun 2003 00:08:44 +0000 Date: Wed, 18 Jun 2003 17:03:32 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14915584869.20030618170332@psg.com> To: "Adrian Farrel" CC: iesg@ietf.org, ietf@ietf.org, mpls@UU.NET Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard In-Reply-To: <0aa001c335cb$610e5bb0$681810ac@movaz.com> References: <07b701c331f1$ffeeb820$681810ac@movaz.com> <0aa001c335cb$610e5bb0$681810ac@movaz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Adrian, folks- I opened a ticket with the secretariat about this error a couple of days ago: [iesg-secretary #8150] Wrong Document Action: draft-ietf-mpls-ldp-dod-restart-00.txt I will ping them again. -- Alex http://www.psg.com/~zinin/ Wednesday, June 18, 2003, 11:56:51 AM, Adrian Farrel wrote: > Did anyone decide there was an error here, or is this draft really in IETF last > call? > Thanks > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: ; > Cc: > Sent: Friday, June 13, 2003 5:23 PM > Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard >> With respect, this draft doesn't appear to have been through WG last call >> (unless I was sleeping, but I can't find any reference in the mail archive). >> >> It was only published as a WG draft on 5/7/2003 (despite carrying a date of >> February 2003). >> >> While I support the draft, I would like to see it discussed on the mailing > list >> and go through WG last call. >> >> Thanks, >> Adrian >> >> ----- Original Message ----- >> From: "The IESG" >> To: >> Cc: >> Sent: Friday, June 13, 2003 1:59 PM >> Subject: Last Call: LDP DoD Graceful Restart to Draft Standard >> >> >> > --------------- >> > The IESG has received a request from Multiprotocol Label Switching to >> > consider the following Internet-Draft(s) as Draft Standard. >> > o Multiprotocol Label Switching (MPLS): LDP DoD Graceful Restart >> > >> > Draft Standard >> > >> > >> > The IESG plans to make a decision in the next few weeks, and solicits >> > final comments on this action. Please send any comments to the >> > iesg@ietf.org or ietf@ietf.org mailing lists by . >> > >> > Files can be obtained via >> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.txt >> > >> >> From owner-mpls@UU.NET Thu Jun 19 09:47:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17832 for ; Thu, 19 Jun 2003 09:47:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottn27827 for ; Thu, 19 Jun 2003 13:47:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQottn27670; Thu, 19 Jun 2003 13:47:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQotti03942 for mpls-outgoing; Thu, 19 Jun 2003 12:37:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotti03933 for ; Thu, 19 Jun 2003 12:37:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotti18349 for ; Thu, 19 Jun 2003 12:37:21 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotti06249 for ; Thu, 19 Jun 2003 12:37:21 GMT Received: from tisch.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tisch.mail.mindspring.net [207.69.200.157]) id QQotti06238 for ; Thu, 19 Jun 2003 12:37:20 GMT Received: from dialup-67.75.25.34.dial1.boston1.level3.net ([67.75.25.34] helo=jluciani-laptop) by tisch.mail.mindspring.net with smtp (Exim 3.33 #1) id 19Syep-0005dm-00; Thu, 19 Jun 2003 08:36:51 -0400 Message-Id: <3.0.1.32.20030619083652.018448d4@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 19 Jun 2003 08:36:52 -0400 To: , "'Ash, Gerald R \(Jerry\), ALABS'" , "'Wijnen, Bert \(Bert\)'" , "'Loa Andersson'" , "'MPLS WG'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Cc: "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" , , "'Van der Linde, Harmen, ALABS'" In-Reply-To: <01bf01c335c3$f2fb82d0$ed472ca1@amer.cisco.com> References: <9473683187ADC049A855ED2DA739ABCA011BEA31@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 02:03 PM 6/18/03 -0400, Thomas D. Nadeau wrote: > > Jerry, > > I do fully agree with Harmen's statement >that the MIBs need to be wrapped up ASAP and >appreciate his feedback as an operator. I think >that we are well on this track. Agreed. > > To address your statement about requirements, >as discussed previously offline with yourself >and the MIB co-authors, many of the requirements >you listed below require changes to the LDP protocol >itself. Given this, I suggest that you consult with >other SPs in the WG on these requirements to make sure >that they are consistent. I personally have not been hearing >any of these requirements from other SPs that participate >in the MPLS WG. In addition, I suggest that you >direct your requirements to the authors of the LDP >specifications and propose extensions/additions there >first because the MIBs cannot manage what the protocols >will not provide. The remaining requirements you listed My read of the draft is that the authors are indeed requesting changes to the LDP protocol. One example is the discussion on sessions being enabled/disabled. As Tom points out, this is not in the MIB because it is not in the protocol. Additionally, there are several claims made about the NMS but these are not given in any context. For example, is not clear how many nodes are on the network, how many nodes an NMS is monitoring, if an out-of-band management network is being used, what other MIBs are supported on the device and being polled for by the NMS? etc. Context would be helpful to better understand what the problem is that is trying to be solved. Why does the NMS have problems with the LDP-MIB and not with the polling for other MIBs? That does not make sense to me. A question was made privately to one of the authors at the Atlanta IETF that perhaps a MIB which stores LDP counter information in a history table (such as is done in SONET) could be useful to them? I did not receive any response to this question. So I am asking again, why wouldn't a history table solve some of the issues? If history tables would be thought useful, this could be proposed to the working group in a separate MIB module, but would be outside the scope of the present LDP-MIB. -Joan >below apply specifically to the PPVPN-MPLS-VPN MIB and not >to the base MPLS MIBs which are in WG last call presently. > > --Tom > > >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: Wednesday, June 18, 2003 1:43 PM >> To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG >> Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; >> Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com >> Subject: RE: WG last call on LSR and LDP MIB modules - setting dates >> >> >> Bert, Loa, All, >> >> I'd like to follow up on Wai Sum's comments below, and >> encourage that high-priority MPLS-MIB problems/requirements >> identified through extensive testing be addressed in the MPLS >> MIB modules. >> >> The MPLS MIB problems/requirements are identified in >> http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.tx >> t, and are critical operator requirements stemming from >> detailed lab testing by Li Chung and others at AT&T. >> MPLS-VPNs aren't going to operate as well as needed until and >> unless these requirements are met. It is expected that >> operators wishing to use the same MPLS MIBs would have >> similar concerns. >> >> The I-D does not propose specific MIB extensions based on the >> requirements. Rather, such extensions are left to the MIB >> designers, in order to avoid past discussions of why specific >> extensions won't work. But so far there is no help or >> response from MIB designers on how to meet the requirements, >> even though the problems have been identified on email lists >> for more than one year. >> >> Here is a summary of requirements (R1,R2,R3 LDP related; >> R4,R5 VPN related): >> >> R1. It is required to capture the signaling usage/performance >> of the LDP Entities, as well as the traffic usage/performance >> of the LDP Sessions. R2. It is required to ensure persistency >> of information in the LDP-MIB Entity Table and Entity >> Statistics Table, whenever an LDP Entity is disabled and then >> re-enabled. R3. It is required that a count be reported of >> mplsNumVrfRouteMaxThreshExceeded notification when the >> operator-defined VRF maximum route threshold is exceeded. R4. >> It is required to have an explicit mapping between VRF, RD, >> and RT in the mplsVpnVrfRouteTargetTable table. R5. It is >> required to track the number of BGP prefixes on the PE-CE >> link, and that the BGP neighbor maximum-prefix limit on the >> PE-CE link be used to limit the number of eBGP routes >> injected in the VRF. >> >> I agree with Harmen Van der Linde, "We need to get this MPLS >> MIB module, together with the MPLS LDP and MPLS VPN modules, >> standardized ASAP. There is a critical need for these MPLS >> MIB modules for management of MPLS-enabled networks, which >> are currently being deployed by many service providers." >> >> Bert threatened at IETF-56 to start over on MPLS MIBs if not >> finished by IETF-57. >> >> We need the MPLS MIB designers to meet critical requirements >> and complete ASAP. >> >> Thanks, >> Jerry >> >> -----Original Message----- >> From: Lai, Wai S (Waisum), ALABS >> Sent: Thursday, June 12, 2003 2:52 PM >> To: Loa Andersson; MPLS WG >> Cc: Chung, Li-Jin W, ALABS; Ash, Gerald R (Jerry), ALABS >> Subject: RE: WG last call on LSR and LDP MIB modules - setting dates >> >> I would like to bring to your attention, once again, the >> requirements in >> http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt >> >> For the LDP and possibly the LSR MIBs, requirements are >> specified in the above I-D, which include, for example, >> requirements for performance and fault management so as to >> lessen dependence on the NMS. Such capabilities should be >> considered based on the requirements, and if appropriate, >> should be included in the appropriate MIBs. >> >> Thanks, Wai Sum >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.se] >> Sent: Thursday, June 12, 2003 4:24 AM >> To: MPLS WG >> Subject: WG last call on LSR and LDP MIB modules - setting dates >> >> Folks, >> >> the time for this wg call has been extended to June 24th noon CET. >> >> /Loa >> >> -------- Original Message -------- >> Subject: Re: WG last call on LSR and LDP MIB modules - CORRECTION! >> Date: Tue, 10 Jun 2003 08:12:00 +0200 >> From: Loa Andersson >> To: MPLS WG >> CC: Loa Andersson , Bert Wijnen , Alex >> Zinin >> >> All, >> >> a misunderstanding between me and the authors resulted in >> that the wrong version of the LDP mib module was sent to this >> wg last call. >> >> The correct version is >> >> >> >> this has just been sent for publication (and with a copy to >> the mailing list). >> >> My take is that we continue the wg last call as planned, but >> as soon as I see the LDP mib being published I will extend >> the last call period. This way will get both a head start and >> the required period of time. >> >> /Loa >> >> Loa Andersson wrote: >> >> > All, >> > >> > this is to initiate a two week wg last call on >> > >> > Multiprotocol Label Switching (MPLS) Label Switching >> > Router (LSR) Management Information Base >> > >> > >> > and >> > Definitions of Managed Objects for the Multiprotocol Label >> > Switching, Label Distribution Protocol (LDP) >> > >> > >> > this wg last call ends June 22nd, and is limited to the >> changes in the > IDs since the previous wg last call, as >> well as interdependencies between > the two mib modules and >> the mib modules listed below. > > For the LSR MIB please >> re-read the mail I sent to the list June 6 called > >> "prequeal to WG last call on the LSR mib module" > > A >> usual silence will be understood as support, but this would >> not > necessarily stop you from giving positive comments. >> Please do. > > There are more MIB modules coming up for wg >> last call and that have been > through wg last call, all of >> those will have interdependencies. > > 1. the TC mib module >> are wg last called and updated, but waiting for the >> > others to be ready for IESG review >> > >> > 2. the TE link MIB module is in wg last call (to end June 13) >> > >> > 3. the management overview has been through wg last call >> and has been >> > updated >> > >> > >> > Two other MIB modules are in the pipe and new version will >> be released > shortly > > 5. The TE mib module >> > 6. The FTN mib module >> > > It is important that >> we complete this process of reviewing and updating > before >> the ID cut off date (June 30) for the Vienna meeting. >> >> >> > > From owner-mpls@UU.NET Thu Jun 19 16:13:30 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16249 for ; Thu, 19 Jun 2003 16:13:29 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotum23051 for ; Thu, 19 Jun 2003 20:13:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotum22089; Thu, 19 Jun 2003 20:13:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQottq20807 for mpls-outgoing; Thu, 19 Jun 2003 14:31:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQottq20746 for ; Thu, 19 Jun 2003 14:31:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQottq04728 for ; Thu, 19 Jun 2003 14:30:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottq24140 for ; Thu, 19 Jun 2003 14:30:09 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQottq24126 for ; Thu, 19 Jun 2003 14:30:09 GMT Received: from md6370exch004u.wins.lucent.com (h135-114-172-12.lucent.com [135.114.172.12]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5JEU5t07272 for ; Thu, 19 Jun 2003 09:30:06 -0500 (CDT) Received: by md6370exch004u.nse.lucent.com with Internet Mail Service (5.5.2653.19) id <1HDZ52HZ>; Thu, 19 Jun 2003 10:30:05 -0400 Message-ID: <305D2EAC01C45448A7F3ECC487666F6C0781D184@md6370exch004u.nse.lucent.com> From: "Natale, Robert C (Bob)" To: jcucchiara@mindspring.com Cc: "'MPLS WG'" , tnadeau@cisco.com, "'Ash, Gerald R (Jerry), ALABS'" , "Wijnen, Bert (Bert)" , "'Loa Andersson'" , "'Lai, Wai S (Waisum), ALABS'" , "'Chung, Li-Jin W, ALABS'" , ppvpn@nortelnetworks.com, "'Van der Linde, Harmen, ALABS'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Thu, 19 Jun 2003 10:30:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Apologies for keeping the long cc: list.... > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Thursday, June 19, 2003 8:37 AM > > ... > My read of the draft is that the authors are indeed requesting > changes to the LDP protocol. One example is the > discussion on sessions being enabled/disabled. As Tom points out, > this is not in the MIB because it is not in the protocol. Yes, and we all understand (I hope) the futility of that. However, these exchanges do raise several very good points: E.g., - Isn't it a good idea to have a fuller understanding of how a technology should be managed *before and/or during* protocol development? - If so, perhaps: - Each protocol development WG should have a Mgmt & Ops advisor? (The "MIB Doctors" service is valuable but seems to tend to focus on SMI compliance (and similar issues) to the exclusion of MIB sufficiency relative to the management requirements of using the technology at hand.) - The Mgmt & Ops Area should publish a set of critical generic management requirements for all protocol development WGs to refer to as they do their core work. (Yes, everyone knows how important management and operations are :-], but everyone also knows how much that is just given "lip service" in the segments of the real world that don't include real users.) > ... > A question was made privately to one of the authors at the > Atlanta IETF that perhaps a MIB which stores LDP counter information > in a history table (such as is done in SONET) could be useful to them? This is a good example of the kind of generic feature and "re-use" that I am talking about above. Cheers, BobN From owner-mpls@UU.NET Thu Jun 19 18:20:40 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23241 for ; Thu, 19 Jun 2003 18:20:40 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotuv02545 for ; Thu, 19 Jun 2003 22:20:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotuv02250; Thu, 19 Jun 2003 22:20:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQottt13496 for mpls-outgoing; Thu, 19 Jun 2003 15:22:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQottt13491 for ; Thu, 19 Jun 2003 15:22:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQottt04985 for ; Thu, 19 Jun 2003 15:21:13 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottt17392 for ; Thu, 19 Jun 2003 15:21:12 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQottt17376 for ; Thu, 19 Jun 2003 15:21:11 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JFL4O1014139 for ; Thu, 19 Jun 2003 11:21:05 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC98893; Thu, 19 Jun 2003 11:21:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5JFL4h09658 for mpls@uu.net; Thu, 19 Jun 2003 11:21:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotts11264 for ; Thu, 19 Jun 2003 15:05:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotts02929 for ; Thu, 19 Jun 2003 15:04:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotts24015 for ; Thu, 19 Jun 2003 15:04:31 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotts24002 for ; Thu, 19 Jun 2003 15:04:31 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JF47O1008128; Thu, 19 Jun 2003 11:04:08 -0400 (EDT) Received: from tnadeauw2k ([161.44.71.237]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAC98023; Thu, 19 Jun 2003 11:04:06 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Natale, Robert C \(Bob\)'" , Cc: "'MPLS WG'" , "'Ash, Gerald R \(Jerry\), ALABS'" , "'Wijnen, Bert \(Bert\)'" , "'Loa Andersson'" , "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" , , "'Van der Linde, Harmen, ALABS'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Thu, 19 Jun 2003 11:03:56 -0400 Organization: Cisco Systems Message-ID: <02b001c33674$057d2660$ed472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <305D2EAC01C45448A7F3ECC487666F6C0781D184@md6370exch004u.nse.lucent.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Natale, Robert C (Bob) [mailto:bnatale@lucent.com] > Sent: Thursday, June 19, 2003 10:30 AM > To: jcucchiara@mindspring.com > Cc: 'MPLS WG'; tnadeau@cisco.com; 'Ash, Gerald R (Jerry), > ALABS'; Wijnen, Bert (Bert); 'Loa Andersson'; 'Lai, Wai S > (Waisum), ALABS'; 'Chung, Li-Jin W, ALABS'; > ppvpn@nortelnetworks.com; 'Van der Linde, Harmen, ALABS' > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > Hi, > > Apologies for keeping the long cc: list.... > > > -----Original Message----- > > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > > Sent: Thursday, June 19, 2003 8:37 AM > > > > ... > > My read of the draft is that the authors are indeed requesting > > changes to the LDP protocol. One example is the > > discussion on sessions being enabled/disabled. As Tom points out, > > this is not in the MIB because it is not in the protocol. > > Yes, and we all understand (I hope) the futility of that. > > However, these exchanges do raise several very good points: E.g., > > - Isn't it a good idea to have a fuller understanding of > how a technology should be managed *before and/or during* > protocol development? Yes. > - If so, perhaps: > > - Each protocol development WG should have a Mgmt & Ops advisor? > > (The "MIB Doctors" service is valuable but seems to tend to > focus on SMI compliance (and similar issues) to the exclusion > of MIB sufficiency relative to the management requirements of > using the technology at hand.) Yes, I agree. > - The Mgmt & Ops Area should publish a set of critical generic > management requirements for all protocol development WGs to > refer to as they do their core work. BUT, those requirements should be used hand-in-hand with those produced by the WG. Also, the WG may have a good reason to not use some of those requirements and should be free to do so if there is consensus to do so. --Tom > (Yes, everyone knows how important management and operations > are :-], but everyone also knows how much that is just given > "lip service" in the segments of the real world that don't > include real users.) > > > ... > > A question was made privately to one of the authors at the > > Atlanta IETF that perhaps a MIB which stores LDP counter information > > in a history table (such as is done in SONET) could be > useful to them? > > This is a good example of the kind of generic feature and > "re-use" that I am talking about above. > > Cheers, > > BobN > From owner-mpls@UU.NET Thu Jun 19 18:47:38 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24079 for ; Thu, 19 Jun 2003 18:47:38 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotux16413 for ; Thu, 19 Jun 2003 22:47:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotux16092; Thu, 19 Jun 2003 22:47:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQottw04450 for mpls-outgoing; Thu, 19 Jun 2003 16:06:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQottw04434 for ; Thu, 19 Jun 2003 16:06:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQottv13913 for ; Thu, 19 Jun 2003 15:59:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottv17964 for ; Thu, 19 Jun 2003 15:59:02 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQottv17956 for ; Thu, 19 Jun 2003 15:59:01 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JFw2O3028140 for ; Thu, 19 Jun 2003 11:58:08 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD00710; Thu, 19 Jun 2003 11:58:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5JFw1C11293 for mpls@uu.net; Thu, 19 Jun 2003 11:58:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQottv15177 for ; Thu, 19 Jun 2003 15:50:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQottv24058 for ; Thu, 19 Jun 2003 15:49:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottv23395 for ; Thu, 19 Jun 2003 15:49:58 GMT Received: from sj-core-5.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-5.cisco.com [171.71.177.238]) id QQottv23383 for ; Thu, 19 Jun 2003 15:49:57 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5JFntFh026534 for ; Thu, 19 Jun 2003 08:49:55 -0700 (PDT) Received: from tnadeauw2k ([161.44.71.237]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD00317; Thu, 19 Jun 2003 11:49:54 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'MPLS WG'" Subject: RE: draft-ietf-mpls-lsr-mib-10.txt Date: Thu, 19 Jun 2003 11:49:45 -0400 Organization: Cisco Systems Message-ID: <02cd01c3367a$6b234750$ed472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200306181504.LAA45510@workhorse.fictitious.org> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Someone pointed out to me offline that I had misinterpreted a question posed the other day. Here is a snipped from the thread. > > > For the traceroute capabiility to work, there has to be a way to > > > take the outgoing label out of the mplsOutSegmentTopLabel on the > > > previous LSR and find the MplsInSegmentEntry on the next LSR. > > > Have we broken this? If so that would be a problem. > > > > No, this still works the same way with an octet string. > Remember, an > > octet string is just a series of bytes. If you make it 4 > bytes, then > > it behaves the same as the unsigned32 did, if you make it more you > > have the same interactions. > > > > --Tom > > > If I wanted to find a specific interface and label (that I > got from the outsegment on the prior router) I'd use: > > We don't know the mplsInSegmentIndex. We just know the > mplsInSegmentLabel and mplsInSegmentInterface. It may be a > per platform label or per interface label (we don't know)> > > What do we put in a get or getnext to quickly get the > mplsInSegmentEntry? Walking the table won't do. Reading the original question again, I see that I missed the question's point in my response. So to answer the original question, yes, the tracing capability is altered and broken by the new indexing, and now I see that we may have gone overboard with the octet string as an index in the InSegment table. It seems that for only the inSegmentTable, it will be useful to use (ifIndex, inSegmentLabel). The big issue for me personally is to be able to have extended indexing available for originating segments, which is why I feel strongly that we still need the octet string index on the XC and outSegment tables. I have discussed this in private with the co-authors and a few others and they agree that the following indexing should now handle all fo the cases. MplsInSegmentTable INDEX { mplsInterfaceIndex, -- InterfaceIndexOrZero mplsInSegmentLabel -- MplsLabel } MplsXCTable INDEX { mplsXCIndex, -- MplsIndexType mplsInterfaceIndex, -- InterfaceIndexOrZero mplsInSegmentLabel, -- MplsLabel mplsOutSegmentIndex -- MplsIndexType } MplsOutSegmentTable INDEX { mplsOutSegmentIndex -- MplsIndexType } --tom From owner-mpls@UU.NET Thu Jun 19 22:32:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00226 for ; Thu, 19 Jun 2003 22:32:18 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotvm00305 for ; Fri, 20 Jun 2003 02:32:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotvm29588; Fri, 20 Jun 2003 02:32:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQotud02453 for mpls-outgoing; Thu, 19 Jun 2003 17:57:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotud02440 for ; Thu, 19 Jun 2003 17:57:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotud27373 for ; Thu, 19 Jun 2003 17:56:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotud00375 for ; Thu, 19 Jun 2003 17:56:19 GMT Received: from ckmso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 75.209.219.209.transedge.com [209.219.209.75]) id QQotud00372 for ; Thu, 19 Jun 2003 17:56:18 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5JHRZt0002194 for ; Thu, 19 Jun 2003 13:56:18 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C00265844; Thu, 19 Jun 2003 13:56:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Thu, 19 Jun 2003 12:56:17 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA011BEA45@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG last call on LSR and LDP MIB modules - setting dates Thread-Index: AcM1xAEariWgGK9QRWG+X54QX0ySqAAvQrWQ From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" , , "Wijnen, Bert (Bert)" , "Loa Andersson" , "MPLS WG" , "Lai, Wai S (Waisum), ALABS" , "Chung, Li-Jin W, ALABS" , , "Van der Linde, Harmen, ALABS" , "Adrian Farrel" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA00226 Tom, > the MIBs need to be wrapped up ASAP and ... > we are well on this track. Good, hopefully by IETF-57, in order to avoid 'sending them to the dust-bin' as Bert has suggested. > To address your statement about requirements, > as discussed previously offline with yourself > and the MIB co-authors, There is about a one-year history/archive of posts to the lists regarding these requirements. > many of the requirements you listed below require > changes to the LDP protocol itself. Which of the 3 LDP requirements constitute 'many' that need LDP changes? Obviously we're not proposing LDP protocol changes. Also, the requirements I-D does not propose specific MIB extensions, *in order to avoid past discussions of why specific extensions won't work*. Step-1 is to make sure the requirements are understood, and then step-2 is to decide how to meet them. Joan has suggested (I believe for requirements R1 and R2) 'a MIB which stores LDP counter information in a history table'. That's a step-2 in the right direction. Furthermore, Adrian has suggested that 'instances of entities' is a concept that has been handled in MIBs before and could be added in an optional way so that implementations did not have to maintain persistent information, but can choose to. As to R3, it should be clear, a MIB should be straightforward. > I suggest that you consult with > other SPs in the WG on these requirements to make sure > that they are consistent. I personally have not been hearing > any of these requirements from other SPs that participate > in the MPLS WG. So that signifies the death-knell pronouncement from the self-appointed OAM/MIB-czar? Perhaps the famous 25 pro-VCCV SPs you often quote (but who never speak for themselves) can attest to the MPLS-MIBs perfection/no-more-requirements-needed? There has been no opposition to the requirements R1-R5 we've been stating for a long time (except, consistently, from you). > I suggest that you direct your requirements to the > authors of the LDP specifications and propose > extensions/additions there first because the MIBs > cannot manage what the protocols will not provide. We're not proposing any changes to LDP. As above, Joan is suggesting approaches to R1 & R2. R3 clearly requires no protocol changes. > The remaining requirements you listed > below apply specifically to the PPVPN-MPLS-VPN MIB and not > to the base MPLS MIBs which are in WG last call presently. R3 and R4 need to be addressed, have been there a long time, and do not have to wait until last call to be discussed/progressed. Jerry > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: Wednesday, June 18, 2003 1:43 PM > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > Bert, Loa, All, > > I'd like to follow up on Wai Sum's comments below, and > encourage that high-priority MPLS-MIB problems/requirements > identified through extensive testing be addressed in the MPLS > MIB modules. > > The MPLS MIB problems/requirements are identified in > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, > and are critical operator requirements stemming from > detailed lab testing by Li Chung and others at AT&T. > MPLS-VPNs aren't going to operate as well as needed until and > unless these requirements are met. It is expected that > operators wishing to use the same MPLS MIBs would have > similar concerns. > > The I-D does not propose specific MIB extensions based on the > requirements. Rather, such extensions are left to the MIB > designers, in order to avoid past discussions of why specific > extensions won't work. But so far there is no help or > response from MIB designers on how to meet the requirements, > even though the problems have been identified on email lists > for more than one year. > > Here is a summary of requirements (R1,R2,R3 LDP related; > R4,R5 VPN related): > > R1. It is required to capture the signaling usage/performance > of the LDP Entities, as well as the traffic usage/performance > of the LDP Sessions. R2. It is required to ensure persistency > of information in the LDP-MIB Entity Table and Entity > Statistics Table, whenever an LDP Entity is disabled and then > re-enabled. R3. It is required that a count be reported of > mplsNumVrfRouteMaxThreshExceeded notification when the > operator-defined VRF maximum route threshold is exceeded. R4. > It is required to have an explicit mapping between VRF, RD, > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is > required to track the number of BGP prefixes on the PE-CE > link, and that the BGP neighbor maximum-prefix limit on the > PE-CE link be used to limit the number of eBGP routes > injected in the VRF. > > I agree with Harmen Van der Linde, "We need to get this MPLS > MIB module, together with the MPLS LDP and MPLS VPN modules, > standardized ASAP. There is a critical need for these MPLS > MIB modules for management of MPLS-enabled networks, which > are currently being deployed by many service providers." > > Bert threatened at IETF-56 to start over on MPLS MIBs if not > finished by IETF-57. > > We need the MPLS MIB designers to meet critical requirements > and complete ASAP. > > Thanks, > Jerry From owner-mpls@UU.NET Thu Jun 19 23:36:03 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02139 for ; Thu, 19 Jun 2003 23:35:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotvq27448 for ; Fri, 20 Jun 2003 03:35:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotvq27135; Fri, 20 Jun 2003 03:35:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQotui04757 for mpls-outgoing; Thu, 19 Jun 2003 19:01:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotui03143 for ; Thu, 19 Jun 2003 19:01:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotui08409 for ; Thu, 19 Jun 2003 19:01:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotui24006 for ; Thu, 19 Jun 2003 19:01:09 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotui23995 for ; Thu, 19 Jun 2003 19:01:08 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JJ16O1008804 for ; Thu, 19 Jun 2003 15:01:06 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD09944; Thu, 19 Jun 2003 15:01:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5JJ15J23318 for mpls@uu.net; Thu, 19 Jun 2003 15:01:05 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotug24064 for ; Thu, 19 Jun 2003 18:38:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotug09419 for ; Thu, 19 Jun 2003 18:38:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotug06531 for ; Thu, 19 Jun 2003 18:38:03 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQotug06469 for ; Thu, 19 Jun 2003 18:37:57 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA59544; Thu, 19 Jun 2003 14:38:08 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200306191838.OAA59544@workhorse.fictitious.org> To: tnadeau@cisco.com cc: curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: draft-ietf-mpls-lsr-mib-10.txt In-reply-to: Your message of "Thu, 19 Jun 2003 14:08:38 EDT." <02e701c3368d$d23408e0$ed472ca1@amer.cisco.com> Date: Thu, 19 Jun 2003 14:38:08 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk See below. A new table is proposed to make it efficient to do an SNMP traceroute using the LSR MIB. What is needed is a way to find the index (mplsInSegmentIndex) for a given interface and label that is determined from the outsegment on the prior LSR. The interface MIB on both routers may be needed to get the ifindex of the other router. Note that even with this change the LSR MIB does not have enough information by itself to do the traceroute. Curtis In message <02e701c3368d$d23408e0$ed472ca1@amer.cisco.com>, "Thomas D. Nadeau" writes: > > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Thursday, June 19, 2003 12:00 PM > > To: tnadeau@cisco.com > > Cc: curtis@fictitious.org > > Subject: Re: draft-ietf-mpls-lsr-mib-10.txt > > > > > > > > In message <02cc01c33679$e3834700$ed472ca1@amer.cisco.com>, > > "Thomas D. Nadeau" > > writes: > > > > > > > > > > -----Original Message----- > > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > > Sent: Wednesday, June 18, 2003 11:05 AM > > > > To: tnadeau@cisco.com > > > > Cc: curtis@fictitious.org > > > > Subject: draft-ietf-mpls-lsr-mib-10.txt > > > > > > > > > > > > > > > > In message <021c01c3342d$f774b760$6401a8c0@amer.cisco.com>, > > > > "Thomas D. Nadeau" > > > > writes: > > > > > > > > > > > > > > > > For the traceroute capabiility to work, there has to > > be a way to > > > > > > take the outgoing label out of the > > mplsOutSegmentTopLabel on the > > > > > > previous LSR and find the MplsInSegmentEntry on the > > next LSR. > > > > > > Have we broken this? If so that would be a problem. > > > > > > > > > > No, this still works the same way with an octet string. > > > > Remember, an > > > > > octet string is just a series of bytes. If you make it 4 > > > > bytes, then > > > > > it behaves the same as the unsigned32 did, if you make > > it more you > > > > > have the same interactions. > > > > > > > > > > --Tom > > > > > > > > > > > > If I wanted to find a specific interface and label (that I > > > > got from the outsegment on the prior router) I'd use: > > > > > > > > We don't know the mplsInSegmentIndex. We just know the > > > > mplsInSegmentLabel and mplsInSegmentInterface. It may be a > > > > per platform label or per interface label (we don't know)> > > > > > > > > What do we put in a get or getnext to quickly get the > > > > mplsInSegmentEntry? Walking the table won't do. > > > > > > Reading the original question again, I see that I > > > missed the question's point in my response. Thanks Curtis. > > > So to answer the original question, yes, the tracing capability > > > is altered and broken by the new indexing, and now I see that we > > > may have gone overboard with the octet string as an index in the > > > InSegment table. It seems that for only the inSegmentTable, it > > > will be useful to use (ifIndex, inSegmentLabel). The big issue > > > for me personally is to be able to have extended indexing > > > available for originating segments, which is why I feel > > > strongly that we still need the octet string index on the > > > XC and outSegment tables. I have discussed this in private > > > with the co-authors and a few others and they agree that > > > the following indexing should now handle all fo the > > > cases. > > > > > > MplsInSegmentTable > > > INDEX { mplsInterfaceIndex, -- InterfaceIndexOrZero > > > mplsInSegmentLabel -- MplsLabel > > > } > > > > > > MplsXCTable > > > INDEX { mplsXCIndex, -- MplsIndexType > > > mplsInterfaceIndex, -- InterfaceIndexOrZero > > > mplsInSegmentLabel, -- MplsLabel > > > mplsOutSegmentIndex -- MplsIndexType > > > } > > > > > > MplsOutSegmentTable > > > INDEX { mplsOutSegmentIndex -- MplsIndexType > > > } > > > > > > --tom > > > > > > Tom, > > > > I suggest you keep the index as you now have it and add a table: > > > > mplsInSegmentLocate > > SYNTAX MplsInSegmentLocate > > [...] > > INDEX { mplsInterfaceLocate, -- InterfaceIndexOrZero > > mplsInSegLabelLocate -- MplsLabel > > } > > ::= [...] > > > > MplsInSegmentLocate ::= SEQUENCE { > > mplsInterfaceLocate InterfaceIndexOrZero, > > mplsInSegLabelLocate MplsLabel, > > mplsInSegmentLocate MplsIndexType > > } > > > > This table would just return the mplsInSegmentIndex. > > I am okay with this, as it keeps things simpler > from my perspective at least. Please reply to my posting > to the MPLS mailing list and propose that. > > --Tom > > > > > Curtis From owner-mpls@UU.NET Thu Jun 19 23:38:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02213 for ; Thu, 19 Jun 2003 23:38:10 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotvq21181 for ; Fri, 20 Jun 2003 03:38:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotvq21069; Fri, 20 Jun 2003 03:38:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQotui15509 for mpls-outgoing; Thu, 19 Jun 2003 19:13:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotui15472 for ; Thu, 19 Jun 2003 19:13:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotui10721 for ; Thu, 19 Jun 2003 19:12:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotui23750 for ; Thu, 19 Jun 2003 19:12:51 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQotui23739 for ; Thu, 19 Jun 2003 19:12:50 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h5JJCou70940; Thu, 19 Jun 2003 12:12:50 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h5JJCn785724; Thu, 19 Jun 2003 12:12:50 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 19 Jun 2003 12:12:49 -0700 (PDT) From: Kireeti Kompella To: Harald Tveit Alvestrand cc: Adrian Farrel , "" , "" Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard In-Reply-To: <610910000.1056014658@askvoll.hjemme.alvestrand.no> Message-ID: <20030619120938.L85637@kummer.juniper.net> References: <07b701c331f1$ffeeb820$681810ac@movaz.com> <0aa001c335cb$610e5bb0$681810ac@movaz.com> <20030618124901.I79256@kummer.juniper.net> <610910000.1056014658@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Harald, On Thu, 19 Jun 2003, Harald Tveit Alvestrand wrote: > it was a test that escaped. The developer has promised to send an apology > to the MPLS list - I'm surprised he hasn't done so yet. Nice to track it down. No apology needed ... > The copy that went to ietf-announce WAS caught in time, fortunately! I guess it would be good if the MPLS chairs just state that the previous email was in error. Kireeti. From owner-mpls@UU.NET Thu Jun 19 23:44:43 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02367 for ; Thu, 19 Jun 2003 23:44:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotvq11767 for ; Fri, 20 Jun 2003 03:44:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotvq11581; Fri, 20 Jun 2003 03:44:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQotum08403 for mpls-outgoing; Thu, 19 Jun 2003 20:13:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotum08354 for ; Thu, 19 Jun 2003 20:13:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotum24959 for ; Thu, 19 Jun 2003 20:13:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotum02679 for ; Thu, 19 Jun 2003 20:13:09 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotum02434 for ; Thu, 19 Jun 2003 20:13:05 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JKD2O1011228 for ; Thu, 19 Jun 2003 16:13:02 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD14065; Thu, 19 Jun 2003 16:13:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5JKD1427030 for mpls@uu.net; Thu, 19 Jun 2003 16:13:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotum23848 for ; Thu, 19 Jun 2003 20:00:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotul29527 for ; Thu, 19 Jun 2003 19:58:29 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotul08901 for ; Thu, 19 Jun 2003 19:58:28 GMT Received: from sj-core-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-5.cisco.com [171.71.177.238]) id QQotul08882 for ; Thu, 19 Jun 2003 19:58:28 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5JJwHFh014437; Thu, 19 Jun 2003 12:58:18 -0700 (PDT) Received: from tnadeauw2k (che-vpn-cluster-2-18.cisco.com [10.86.242.18]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD12925; Thu, 19 Jun 2003 15:58:16 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: Cc: Subject: RE: draft-ietf-mpls-lsr-mib-10.txt Date: Thu, 19 Jun 2003 15:58:05 -0400 Organization: Cisco Systems Message-ID: <030401c3369d$1c6df740$ed472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200306191838.OAA59544@workhorse.fictitious.org> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > See below. A new table is proposed to make it efficient to > do an SNMP traceroute using the LSR MIB. What is needed is a > way to find the index (mplsInSegmentIndex) for a given > interface and label that is determined from the outsegment on > the prior LSR. The interface MIB on both routers may be > needed to get the ifindex of the other router. Being one who advocated the original change to the indexing, I can live with the addition of a mapping table and the indexing currently in v10 of the MIB. > Note that even with this change the LSR MIB does not have > enough information by itself to do the traceroute. Yes, there is a need to use the application- specific MIBs to know where to start (i.e.: VPN, or FTN). --Tom > Curtis > > > In message <02e701c3368d$d23408e0$ed472ca1@amer.cisco.com>, > "Thomas D. Nadeau" > writes: > > > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Thursday, June 19, 2003 12:00 PM > > > To: tnadeau@cisco.com > > > Cc: curtis@fictitious.org > > > Subject: Re: draft-ietf-mpls-lsr-mib-10.txt > > > > > > > > > > > > In message <02cc01c33679$e3834700$ed472ca1@amer.cisco.com>, > > > "Thomas D. Nadeau" > > > writes: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > > > Sent: Wednesday, June 18, 2003 11:05 AM > > > > > To: tnadeau@cisco.com > > > > > Cc: curtis@fictitious.org > > > > > Subject: draft-ietf-mpls-lsr-mib-10.txt > > > > > > > > > > > > > > > > > > > > In message <021c01c3342d$f774b760$6401a8c0@amer.cisco.com>, > > > > > "Thomas D. Nadeau" > > > > > writes: > > > > > > > > > > > > > > > > > > > For the traceroute capabiility to work, there has to > > > be a way to > > > > > > > take the outgoing label out of the > > > mplsOutSegmentTopLabel on the > > > > > > > previous LSR and find the MplsInSegmentEntry on the > > > next LSR. > > > > > > > Have we broken this? If so that would be a problem. > > > > > > > > > > > > No, this still works the same way with an octet string. > > > > > Remember, an > > > > > > octet string is just a series of bytes. If you make it 4 > > > > > bytes, then > > > > > > it behaves the same as the unsigned32 did, if you make > > > it more you > > > > > > have the same interactions. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > If I wanted to find a specific interface and label > (that I got > > > > > from the outsegment on the prior router) I'd use: > > > > > > > > > > We don't know the mplsInSegmentIndex. We just know the > > > > > mplsInSegmentLabel and mplsInSegmentInterface. It > may be a per > > > > > platform label or per interface label (we don't know)> > > > > > > > > > > What do we put in a get or getnext to quickly get the > > > > > mplsInSegmentEntry? Walking the table won't do. > > > > > > > > Reading the original question again, I see that I > > > > missed the question's point in my response. Thanks > Curtis. So to > > > > answer the original question, yes, the tracing capability is > > > > altered and broken by the new indexing, and now I see > that we may > > > > have gone overboard with the octet string as an index in the > > > > InSegment table. It seems that for only the inSegmentTable, it > > > > will be useful to use (ifIndex, inSegmentLabel). The > big issue for > > > > me personally is to be able to have extended indexing available > > > > for originating segments, which is why I feel strongly that we > > > > still need the octet string index on the XC and > outSegment tables. > > > > I have discussed this in private with the co-authors and a few > > > > others and they agree that the following indexing should now > > > > handle all fo the cases. > > > > > > > > MplsInSegmentTable > > > > INDEX { mplsInterfaceIndex, -- > InterfaceIndexOrZero > > > > mplsInSegmentLabel -- MplsLabel > > > > } > > > > > > > > MplsXCTable > > > > INDEX { mplsXCIndex, -- MplsIndexType > > > > mplsInterfaceIndex, -- > InterfaceIndexOrZero > > > > mplsInSegmentLabel, -- MplsLabel > > > > mplsOutSegmentIndex -- MplsIndexType > > > > } > > > > > > > > MplsOutSegmentTable > > > > INDEX { mplsOutSegmentIndex -- MplsIndexType > > > > } > > > > > > > > --tom > > > > > > > > > Tom, > > > > > > I suggest you keep the index as you now have it and add a table: > > > > > > mplsInSegmentLocate > > > SYNTAX MplsInSegmentLocate > > > [...] > > > INDEX { mplsInterfaceLocate, -- InterfaceIndexOrZero > > > mplsInSegLabelLocate -- MplsLabel > > > } > > > ::= [...] > > > > > > MplsInSegmentLocate ::= SEQUENCE { > > > mplsInterfaceLocate InterfaceIndexOrZero, > > > mplsInSegLabelLocate MplsLabel, > > > mplsInSegmentLocate MplsIndexType > > > } > > > > > > This table would just return the mplsInSegmentIndex. > > > > I am okay with this, as it keeps things simpler > > from my perspective at least. Please reply to my posting > > to the MPLS mailing list and propose that. > > > > --Tom > > > > > > > > Curtis > From owner-mpls@UU.NET Thu Jun 19 23:52:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02546 for ; Thu, 19 Jun 2003 23:52:40 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotvr26058 for ; Fri, 20 Jun 2003 03:52:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotvr25698; Fri, 20 Jun 2003 03:52:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQotui14281 for mpls-outgoing; Thu, 19 Jun 2003 19:05:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotui14259 for ; Thu, 19 Jun 2003 19:05:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotui12889 for ; Thu, 19 Jun 2003 19:01:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotui24101 for ; Thu, 19 Jun 2003 19:01:12 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotui24083 for ; Thu, 19 Jun 2003 19:01:11 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JJ16O3008804 for ; Thu, 19 Jun 2003 15:01:08 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD09945; Thu, 19 Jun 2003 15:01:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5JJ15823327 for mpls@uu.net; Thu, 19 Jun 2003 15:01:05 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotug23854 for ; Thu, 19 Jun 2003 18:35:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotug29408 for ; Thu, 19 Jun 2003 18:35:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotug23340 for ; Thu, 19 Jun 2003 18:35:03 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotug23333 for ; Thu, 19 Jun 2003 18:35:02 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JIY6O1028793; Thu, 19 Jun 2003 14:34:07 -0400 (EDT) Received: from tnadeauw2k ([161.44.71.237]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD08549; Thu, 19 Jun 2003 14:34:06 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Ash, Gerald R \(Jerry\), ALABS'" Cc: , "'Wijnen, Bert \(Bert\)'" , "'Loa Andersson'" , "'MPLS WG'" , "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" , , "'Van der Linde, Harmen, ALABS'" , "'Adrian Farrel'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Thu, 19 Jun 2003 14:34:02 -0400 Organization: Cisco Systems Message-ID: <02f301c33691$5ba16ed0$ed472ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA011BEA45@KCCLUST06EVS1.ugd.att.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Tom, > > > the MIBs need to be wrapped up ASAP and ... > > we are well on this track. > > Good, hopefully by IETF-57, in order to avoid 'sending them > to the dust-bin' as Bert has suggested. > > > To address your statement about requirements, > > as discussed previously offline with yourself > > and the MIB co-authors, > > There is about a one-year history/archive of posts to the > lists regarding these requirements. > > > many of the requirements you listed below require > > changes to the LDP protocol itself. > > Which of the 3 LDP requirements constitute 'many' that need > LDP changes? All of the requirements you listed below with the exception of the ones pertaining to VPN. > Obviously we're not proposing LDP protocol changes. Also, > the requirements I-D does not propose specific MIB > extensions, *in order to avoid past discussions of why > specific extensions won't work*. Step-1 is to make sure the > requirements are understood, and then step-2 is to decide how > to meet them. Of course you aren't proposing specific changes to anything. What we are saying is that is what you need to do in order to accomplish what you want in this case. The LDP MIB is not a place for redefining how LDP works. > Joan has suggested (I believe for requirements R1 and R2) 'a > MIB which stores LDP counter information in a history table'. > That's a step-2 in the right direction. Furthermore, Adrian > has suggested that 'instances of entities' is a concept that > has been handled in MIBs before and could be added in an > optional way so that implementations did not have to maintain > persistent information, but can choose to. This is not something that should go into the existing LDP MIB because the LDP protocol does not support the counters/concepts required to count these things regardless of what has been suggested. If you look at the specific details of what is being proposed in the draft (which I and others have done numerous times now) they CANNOT be achieved with the current standard LDP. > As to R3, it should be clear, a MIB should be straightforward. > > > I suggest that you consult with > > other SPs in the WG on these requirements to make sure > > that they are consistent. I personally have not been hearing > > any of these requirements from other SPs that participate > > in the MPLS WG. > > So that signifies the death-knell pronouncement from the > self-appointed OAM/MIB-czar? Perhaps the famous 25 pro-VCCV > SPs you often quote (but who never speak for themselves) can > attest to the MPLS-MIBs perfection/no-more-requirements-needed? > > There has been no opposition to the requirements R1-R5 we've > been stating for a long time (except, consistently, from you). I have not read any emails that claimed support for or acknowledged these requirements either. > > I suggest that you direct your requirements to the > > authors of the LDP specifications and propose > > extensions/additions there first because the MIBs > > cannot manage what the protocols will not provide. > > We're not proposing any changes to LDP. As above, Joan is > suggesting approaches to R1 & R2. R3 clearly requires no > protocol changes. So then go ahead and propose a MIB based on those changes. There is nothing preventing you or anyone else on the co-author list of the draft in question from doing this. > > The remaining requirements you listed > > below apply specifically to the PPVPN-MPLS-VPN MIB and not > > to the base MPLS MIBs which are in WG last call presently. > > R3 and R4 need to be addressed, have been there a long time, > and do not have to wait until last call to be discussed/progressed. And these will be addressed in the PPVPN MPLS VPN MIB when Harmen and I get around to editing the MIB, assuming there is consensus to make these additions. And as you can see, I have been a little busy with the base MIBs for the last few months. *) --Apparently self-appointed OAM/MIB-czar > Jerry > > > -----Original Message----- > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > Sent: Wednesday, June 18, 2003 1:43 PM > > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG > > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; > > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com > > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > > > > Bert, Loa, All, > > > > I'd like to follow up on Wai Sum's comments below, and > > encourage that high-priority MPLS-MIB problems/requirements > > identified through extensive testing be addressed in the MPLS > > MIB modules. > > > > The MPLS MIB problems/requirements are identified in > > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, > > and are critical operator requirements stemming from > > detailed lab testing by Li Chung and others at AT&T. > > MPLS-VPNs aren't going to operate as well as needed until and > > unless these requirements are met. It is expected that > > operators wishing to use the same MPLS MIBs would have > > similar concerns. > > > > The I-D does not propose specific MIB extensions based on the > > requirements. Rather, such extensions are left to the MIB > > designers, in order to avoid past discussions of why specific > > extensions won't work. But so far there is no help or > > response from MIB designers on how to meet the requirements, > > even though the problems have been identified on email lists > > for more than one year. > > > > Here is a summary of requirements (R1,R2,R3 LDP related; > > R4,R5 VPN related): > > > > R1. It is required to capture the signaling usage/performance > > of the LDP Entities, as well as the traffic usage/performance > > of the LDP Sessions. R2. It is required to ensure persistency > > of information in the LDP-MIB Entity Table and Entity > > Statistics Table, whenever an LDP Entity is disabled and then > > re-enabled. R3. It is required that a count be reported of > > mplsNumVrfRouteMaxThreshExceeded notification when the > > operator-defined VRF maximum route threshold is exceeded. R4. > > It is required to have an explicit mapping between VRF, RD, > > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is > > required to track the number of BGP prefixes on the PE-CE > > link, and that the BGP neighbor maximum-prefix limit on the > > PE-CE link be used to limit the number of eBGP routes > > injected in the VRF. > > > > I agree with Harmen Van der Linde, "We need to get this MPLS > > MIB module, together with the MPLS LDP and MPLS VPN modules, > > standardized ASAP. There is a critical need for these MPLS > > MIB modules for management of MPLS-enabled networks, which > > are currently being deployed by many service providers." > > > > Bert threatened at IETF-56 to start over on MPLS MIBs if not > > finished by IETF-57. > > > > We need the MPLS MIB designers to meet critical requirements > > and complete ASAP. > > > > Thanks, > > Jerry > From owner-mpls@UU.NET Fri Jun 20 14:30:54 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24242 for ; Fri, 20 Jun 2003 14:30:53 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotxy04613 for ; Fri, 20 Jun 2003 18:30:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotxy04089; Fri, 20 Jun 2003 18:30:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQotxb22442 for mpls-outgoing; Fri, 20 Jun 2003 12:45:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotxb22424 for ; Fri, 20 Jun 2003 12:45:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotxa00897 for ; Fri, 20 Jun 2003 12:44:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotxa01978 for ; Fri, 20 Jun 2003 12:44:39 GMT Received: from tokyo.ccrle.nec.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQotxa01925 for ; Fri, 20 Jun 2003 12:44:38 GMT Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5KCiiVI052766; Fri, 20 Jun 2003 14:44:45 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4FC9EC264; Fri, 20 Jun 2003 14:29:49 +0200 (CEST) Date: Fri, 20 Jun 2003 14:44:27 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: "Van der Linde, Harmen, ALABS" Cc: mpls@UU.NET Subject: RE: prequeal to WG lat call om the LSR mib module Message-ID: <18163387.1056120267@[10.1.1.130]> In-Reply-To: <3D536751F6C50347AD038FF5D7AD987801A356AF@KCCLUST06EVS1.ugd.att.com> References: <3D536751F6C50347AD038FF5D7AD987801A356AF@KCCLUST06EVS1.ugd.att. com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Harmen, > The MPLS LSR MIB will most likely primarily being used for MPLS > topology discovery (i.e., LSP path discovery). So, the emphasize > is more on reading the MIB information as opposed to creation > of new MIB information. In some earlier email exchange I read > that a string-based indexing scheme has the benefit of providing > more efficient table read capabilities. This efficiency is very > appealing and beneficial to implement efficient MPLS topology > discovery capabilities. The efficiency depends on what you want to read. 1) The whole table, 2) only entries belonging to a certain interface, 3) or one single entry. For 1 both schemes are identical for 2 the scheme in -09 (the older one) is much more efficient for 3 it seams to be less efficient in Toms implementation. > My concern is that we spend too much time discussion a MIB SMI > optimization (i.e., using a Unsigned32 index) that doesn't have > substantial value and, in fact, seem to have a negative impact > on MIB read capabilities. We need to get this MPLS MIB module, > together with the MPLS LDP and MPLS VPN modules, standardized > ASAP. There is a critical need for these MPLS MIB modules for > management of MPLS-enabled networks, which are currently being > deployed by many service providers. I agree, but I do not want an optimization of a single implementation being standardized. Regrads, Marcus > > regards, > > Harmen > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus From owner-mpls@UU.NET Fri Jun 20 14:32:33 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24585 for ; Fri, 20 Jun 2003 14:32:32 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotxy15485 for ; Fri, 20 Jun 2003 18:32:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotxy14926; Fri, 20 Jun 2003 18:31:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQotxd14420 for mpls-outgoing; Fri, 20 Jun 2003 13:26:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQotxd14415 for ; Fri, 20 Jun 2003 13:26:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotxd26074 for ; Fri, 20 Jun 2003 13:26:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotxd21892 for ; Fri, 20 Jun 2003 13:26:02 GMT Received: from ckmso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQotxd21874 for ; Fri, 20 Jun 2003 13:26:01 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5KD75O1020889 for ; Fri, 20 Jun 2003 09:26:01 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C002B7EBC; Fri, 20 Jun 2003 09:25:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Fri, 20 Jun 2003 08:25:59 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A6850@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG last call on LSR and LDP MIB modules - setting dates Thread-Index: AcM2X4WKW+jeT5SERXGkmdqAulyqRQAzPG7A From: "Ash, Gerald R (Jerry), ALABS" To: , "MPLS WG" Cc: "Ash, Gerald R (Jerry), ALABS" , "Lai, Wai S (Waisum), ALABS" , "Chung, Li-Jin W, ALABS" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA24585 Joan, > perhaps a MIB which stores LDP counter information in a > history table (such as is done in SONET) could be useful... > why wouldn't a history table solve some of the issues? > If history tables would be thought useful, this could be > proposed to the working group in a separate MIB module, > but would be outside the scope of the present LDP-MIB. Thanks for your suggestion. I presume this is regarding requirements R1 and R2 below, correct? If so, it does appear useful and we'd like to work with you to define details and progress. Thanks, Jerry P.S. Correction to requirements below, R3 is a VPN requirements, not an LDP requirement. >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: Wednesday, June 18, 2003 1:43 PM >> To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG >> Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; >> Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com >> Subject: RE: WG last call on LSR and LDP MIB modules - setting dates >> >> Bert, Loa, All, >> >> I'd like to follow up on Wai Sum's comments below, and >> encourage that high-priority MPLS-MIB problems/requirements >> identified through extensive testing be addressed in the MPLS >> MIB modules. >> >> The MPLS MIB problems/requirements are identified in >> http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.tx >> t, and are critical operator requirements stemming from >> detailed lab testing by Li Chung and others at AT&T. >> MPLS-VPNs aren't going to operate as well as needed until and >> unless these requirements are met. It is expected that >> operators wishing to use the same MPLS MIBs would have >> similar concerns. >> >> The I-D does not propose specific MIB extensions based on the >> requirements. Rather, such extensions are left to the MIB >> designers, in order to avoid past discussions of why specific >> extensions won't work. But so far there is no help or >> response from MIB designers on how to meet the requirements, >> even though the problems have been identified on email lists >> for more than one year. >> >> Here is a summary of requirements (R1,R2,R3 LDP related; >> R4,R5 VPN related): >> >> R1. It is required to capture the signaling usage/performance >> of the LDP Entities, as well as the traffic usage/performance >> of the LDP Sessions. >> R2. It is required to ensure persistency >> of information in the LDP-MIB Entity Table and Entity >> Statistics Table, whenever an LDP Entity is disabled and then >> re-enabled. >> R3. It is required that a count be reported of >> mplsNumVrfRouteMaxThreshExceeded notification when the >> operator-defined VRF maximum route threshold is exceeded. >> R4. It is required to have an explicit mapping between VRF, RD, >> and RT in the mplsVpnVrfRouteTargetTable table. >> R5. It is >> required to track the number of BGP prefixes on the PE-CE >> link, and that the BGP neighbor maximum-prefix limit on the >> PE-CE link be used to limit the number of eBGP routes >> injected in the VRF. >> >> I agree with Harmen Van der Linde, "We need to get this MPLS >> MIB module, together with the MPLS LDP and MPLS VPN modules, >> standardized ASAP. There is a critical need for these MPLS >> MIB modules for management of MPLS-enabled networks, which >> are currently being deployed by many service providers." >> >> Bert threatened at IETF-56 to start over on MPLS MIBs if not >> finished by IETF-57. >> >> We need the MPLS MIB designers to meet critical requirements >> and complete ASAP. >> >> Thanks, >> Jerry From owner-mpls@UU.NET Fri Jun 20 14:55:47 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27583 for ; Fri, 20 Jun 2003 14:55:47 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotxz05444 for ; Fri, 20 Jun 2003 18:55:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotxz05312; Fri, 20 Jun 2003 18:55:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQotxv18295 for mpls-outgoing; Fri, 20 Jun 2003 17:53:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotxv18290 for ; Fri, 20 Jun 2003 17:53:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotxv21050 for ; Fri, 20 Jun 2003 17:52:46 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotxv29569 for ; Fri, 20 Jun 2003 17:52:45 GMT Received: from host19.ipowerweb.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host19.ipowerweb.com [12.129.211.119]) id QQotxv29533 for ; Fri, 20 Jun 2003 17:52:45 GMT Received: from [65.211.67.100] (helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 19TQ3L-00015Q-00; Fri, 20 Jun 2003 10:51:59 -0700 Message-ID: <3EF348C8.46EF6EBB@GraIyMage.com> Date: Fri, 20 Jun 2003 13:47:52 -0400 From: Eric Gray Reply-To: ewgray@GraIyMage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: tnadeau@cisco.com CC: "'Ash, Gerald R (Jerry), ALABS'" , jcucchiara@mindspring.com, "'Wijnen, Bert (Bert)'" , "'Loa Andersson'" , "'MPLS WG'" , ppvpn@nortelnetworks.com, ewgray@GraIyMage.com Subject: Re: WG last call on LSR and LDP MIB modules - setting dates References: <02f301c33691$5ba16ed0$ed472ca1@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - uu.net X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom and others, This discussion seems skewed a bit because of different perspectives that people are speaking from. First of all, it is not the case that a protocol specification must necessarily define counters and knobs for every detail of how the protocol should be managed. It is often the case that people would prefer this to be the case, however, requiring it to be the case would be a sure fire way to delay specification of protocol standards well beyond some window of utility for a standard - meaning that placing too many barriers in the way of defining standards leads to de facto standards. For example, in this discussion, what exactly is it that LDP _should_ have defined to support the requirements that Jerry points out? I do not think that the protocol should be involved in the business of keeping track of the enabled status of potential protocol peers - it should be sufficient from a protocol perspective to know whether a protocol peer is currently visible. Also, the protocol specification should not specify what happens to protocol management data (counters and knobs) during the period in which the protocol itself is not active - except to the extent that proper protocol behavior absolutely depends on such specification. My sense is that it is perfectly within the purview of a management specification to make statements about this kind of behavior as long as such statements are not actually incompatible with underlying protocol specifications. It would then be up to implementers to determine whether or not their implementation supports these capabilities. And it is equally reasonable to assert that specifying required behaviors may be the task of some subsequent management specification. In the same way that requiring full manageability of a protocol can unnecessarily delay the protocol specification process, requiring complete satisfaction of evolving management requirements in current management specifications can unnecessarily delay the management specification process. My 2 cents worth... -- Eric Gray "Thomas D. Nadeau" wrote: > > > Tom, > > > > > the MIBs need to be wrapped up ASAP and ... > > > we are well on this track. > > > > Good, hopefully by IETF-57, in order to avoid 'sending them > > to the dust-bin' as Bert has suggested. > > > > > To address your statement about requirements, > > > as discussed previously offline with yourself > > > and the MIB co-authors, > > > > There is about a one-year history/archive of posts to the > > lists regarding these requirements. > > > > > many of the requirements you listed below require > > > changes to the LDP protocol itself. > > > > Which of the 3 LDP requirements constitute 'many' that need > > LDP changes? > > All of the requirements you listed below with > the exception of the ones pertaining to VPN. > > > Obviously we're not proposing LDP protocol changes. Also, > > the requirements I-D does not propose specific MIB > > extensions, *in order to avoid past discussions of why > > specific extensions won't work*. Step-1 is to make sure the > > requirements are understood, and then step-2 is to decide how > > to meet them. > > Of course you aren't proposing specific changes to > anything. What we are saying is that is what you need to > do in order to accomplish what you want in this case. The > LDP MIB is not a place for redefining how LDP works. > > > Joan has suggested (I believe for requirements R1 and R2) 'a > > MIB which stores LDP counter information in a history table'. > > That's a step-2 in the right direction. Furthermore, Adrian > > has suggested that 'instances of entities' is a concept that > > has been handled in MIBs before and could be added in an > > optional way so that implementations did not have to maintain > > persistent information, but can choose to. > > This is not something that should go into the existing > LDP MIB because the LDP protocol does not support the > counters/concepts required to count these things regardless > of what has been suggested. If you look at the specific details > of what is being proposed in the draft (which I and others have > done numerous times now) they CANNOT be achieved with > the current standard LDP. > > > As to R3, it should be clear, a MIB should be straightforward. > > > > > I suggest that you consult with > > > other SPs in the WG on these requirements to make sure > > > that they are consistent. I personally have not been hearing > > > any of these requirements from other SPs that participate > > > in the MPLS WG. > > > > So that signifies the death-knell pronouncement from the > > self-appointed OAM/MIB-czar? Perhaps the famous 25 pro-VCCV > > SPs you often quote (but who never speak for themselves) can > > attest to the MPLS-MIBs perfection/no-more-requirements-needed? > > > > There has been no opposition to the requirements R1-R5 we've > > been stating for a long time (except, consistently, from you). > > I have not read any emails that claimed support for > or acknowledged these requirements either. > > > > I suggest that you direct your requirements to the > > > authors of the LDP specifications and propose > > > extensions/additions there first because the MIBs > > > cannot manage what the protocols will not provide. > > > > We're not proposing any changes to LDP. As above, Joan is > > suggesting approaches to R1 & R2. R3 clearly requires no > > protocol changes. > > So then go ahead and propose a MIB based on those > changes. There is nothing preventing you or anyone else > on the co-author list of the draft in question from doing > this. > > > > The remaining requirements you listed > > > below apply specifically to the PPVPN-MPLS-VPN MIB and not > > > to the base MPLS MIBs which are in WG last call presently. > > > > R3 and R4 need to be addressed, have been there a long time, > > and do not have to wait until last call to be discussed/progressed. > > And these will be addressed in the PPVPN MPLS VPN MIB > when Harmen and I get around to editing the MIB, assuming there > is consensus to make these additions. And as you can see, I > have been a little busy with the base MIBs for the last > few months. *) > > --Apparently self-appointed OAM/MIB-czar > > > > Jerry > > > > > -----Original Message----- > > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > > Sent: Wednesday, June 18, 2003 1:43 PM > > > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG > > > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; > > > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com > > > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > > > > > > > Bert, Loa, All, > > > > > > I'd like to follow up on Wai Sum's comments below, and > > > encourage that high-priority MPLS-MIB problems/requirements > > > identified through extensive testing be addressed in the MPLS > > > MIB modules. > > > > > > The MPLS MIB problems/requirements are identified in > > > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, > > > and are critical operator requirements stemming from > > > detailed lab testing by Li Chung and others at AT&T. > > > MPLS-VPNs aren't going to operate as well as needed until and > > > unless these requirements are met. It is expected that > > > operators wishing to use the same MPLS MIBs would have > > > similar concerns. > > > > > > The I-D does not propose specific MIB extensions based on the > > > requirements. Rather, such extensions are left to the MIB > > > designers, in order to avoid past discussions of why specific > > > extensions won't work. But so far there is no help or > > > response from MIB designers on how to meet the requirements, > > > even though the problems have been identified on email lists > > > for more than one year. > > > > > > Here is a summary of requirements (R1,R2,R3 LDP related; > > > R4,R5 VPN related): > > > > > > R1. It is required to capture the signaling usage/performance > > > of the LDP Entities, as well as the traffic usage/performance > > > of the LDP Sessions. R2. It is required to ensure persistency > > > of information in the LDP-MIB Entity Table and Entity > > > Statistics Table, whenever an LDP Entity is disabled and then > > > re-enabled. R3. It is required that a count be reported of > > > mplsNumVrfRouteMaxThreshExceeded notification when the > > > operator-defined VRF maximum route threshold is exceeded. R4. > > > It is required to have an explicit mapping between VRF, RD, > > > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is > > > required to track the number of BGP prefixes on the PE-CE > > > link, and that the BGP neighbor maximum-prefix limit on the > > > PE-CE link be used to limit the number of eBGP routes > > > injected in the VRF. > > > > > > I agree with Harmen Van der Linde, "We need to get this MPLS > > > MIB module, together with the MPLS LDP and MPLS VPN modules, > > > standardized ASAP. There is a critical need for these MPLS > > > MIB modules for management of MPLS-enabled networks, which > > > are currently being deployed by many service providers." > > > > > > Bert threatened at IETF-56 to start over on MPLS MIBs if not > > > finished by IETF-57. > > > > > > We need the MPLS MIB designers to meet critical requirements > > > and complete ASAP. > > > > > > Thanks, > > > Jerry > > From owner-mpls@UU.NET Fri Jun 20 22:42:47 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17646 for ; Fri, 20 Jun 2003 22:42:46 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotze27063 for ; Sat, 21 Jun 2003 02:42:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQotze26899; Sat, 21 Jun 2003 02:42:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQotyl20253 for mpls-outgoing; Fri, 20 Jun 2003 21:46:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotyl20248 for ; Fri, 20 Jun 2003 21:46:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQotyl07792 for ; Fri, 20 Jun 2003 21:45:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotyl08404 for ; Fri, 20 Jun 2003 21:45:08 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQotyl08395 for ; Fri, 20 Jun 2003 21:45:07 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15089 for ; Fri, 20 Jun 2003 17:45:05 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20495 for ; Fri, 20 Jun 2003 17:45:07 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 17:45:06 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0742CD09@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'MPLS WG'" Subject: RE: draft-ietf-mpls-lsr-mib-10.txt Date: Fri, 20 Jun 2003 17:45:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, June 19, 2003 11:50 AM > To: 'MPLS WG' > Subject: RE: draft-ietf-mpls-lsr-mib-10.txt > > > > Someone pointed out to me offline > that I had misinterpreted a question posed > the other day. Here is a snipped from the > thread. > > > > > For the traceroute capabiility to work, there has to be > a way to > > > > take the outgoing label out of the > mplsOutSegmentTopLabel on the > > > > previous LSR and find the MplsInSegmentEntry on the next LSR. > > > > Have we broken this? If so that would be a problem. > > > > > > No, this still works the same way with an octet string. > > Remember, an > > > octet string is just a series of bytes. If you make it 4 > > bytes, then > > > it behaves the same as the unsigned32 did, if you make it more you > > > have the same interactions. > > > > > > --Tom > > > > > > If I wanted to find a specific interface and label (that I > > got from the outsegment on the prior router) I'd use: > > > > We don't know the mplsInSegmentIndex. We just know the > > mplsInSegmentLabel and mplsInSegmentInterface. It may be a > > per platform label or per interface label (we don't know)> > > > > What do we put in a get or getnext to quickly get the > > mplsInSegmentEntry? Walking the table won't do. > > Reading the original question again, I see that I > missed the question's point in my response. > So to answer the original question, yes, the tracing capability > is altered and broken by the new indexing, and now I see that we > may have gone overboard with the octet string as an index in the > InSegment table. It seems that for only the inSegmentTable, it > will be useful to use (ifIndex, inSegmentLabel). The big issue > for me personally is to be able to have extended indexing > available for originating segments, which is why I feel strongly > that we still need the octet string index on the XC and outSegment > tables. I have discussed this in private with the co-authors and > a few others and they agree that the following indexing should > now handle all fo the cases. > > MplsInSegmentTable > INDEX { mplsInterfaceIndex, -- InterfaceIndexOrZero > mplsInSegmentLabel -- MplsLabel > } > I agree that it is a good idea to leave the indexing of the mplsInSegmentTable as defined above. > MplsXCTable > INDEX { mplsXCIndex, -- MplsIndexType > mplsInterfaceIndex, -- InterfaceIndexOrZero > mplsInSegmentLabel, -- MplsLabel > mplsOutSegmentIndex -- MplsIndexType > } > Since the mplsXCIndex was already an opaque index, personally I don't see any problems with this change. > MplsOutSegmentTable > INDEX { mplsOutSegmentIndex -- MplsIndexType > } > Since the mplsOutSegmentIndex was already an opaque index, I don't see any problems in this change. However, I do have the following suggestion: Seems that the primary reasons for changing the outsegment index, was to do with finding the next best label for the output side (search through the input table and then the output table). Here again, I will suggest that you consider adding a NextFreeLabelTable (that indicates the next free ingress/ egress label). This will eliminate the need for the index change and allows provisioning applications to determine the next free label in O(1) operations -No MIB walks necessary. Thanks, sanjay > --tom > From owner-mpls@UU.NET Sat Jun 21 06:20:22 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05335 for ; Sat, 21 Jun 2003 06:20:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouaj12849 for ; Sat, 21 Jun 2003 10:20:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouaj12534; Sat, 21 Jun 2003 10:20:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQotzu16780 for mpls-outgoing; Sat, 21 Jun 2003 06:30:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQotzu16775 for ; Sat, 21 Jun 2003 06:30:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotzu20385 for ; Sat, 21 Jun 2003 06:30:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotzu22522 for ; Sat, 21 Jun 2003 06:30:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotzu22518 for ; Sat, 21 Jun 2003 06:30:05 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5L6U2ai005827 for ; Sat, 21 Jun 2003 02:30:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD79916; Sat, 21 Jun 2003 02:30:00 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5L6U0816176 for mpls@uu.net; Sat, 21 Jun 2003 02:30:00 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotxf16171 for ; Fri, 20 Jun 2003 13:53:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQotxf28848 for ; Fri, 20 Jun 2003 13:52:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotxf13523 for ; Fri, 20 Jun 2003 13:52:50 GMT Received: from laptoy770.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [209.150.1.238]) id QQotxf13502 for ; Fri, 20 Jun 2003 13:52:48 GMT Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.12.3/8.12.3) with ESMTP id h5KDr7Mn013467; Fri, 20 Jun 2003 09:53:07 -0400 (EDT) (envelope-from curtis@laptoy770.fictitious.org) Message-Id: <200306201353.h5KDr7Mn013467@laptoy770.fictitious.org> To: tnadeau@cisco.com cc: curtis@fictitious.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: draft-ietf-mpls-lsr-mib-10.txt In-reply-to: Your message of "Thu, 19 Jun 2003 15:58:05 EDT." <030401c3369d$1c6df740$ed472ca1@amer.cisco.com> Date: Fri, 20 Jun 2003 09:53:07 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <030401c3369d$1c6df740$ed472ca1@amer.cisco.com>, "Thomas D. Nadeau" writes: > > > See below. A new table is proposed to make it efficient to > > do an SNMP traceroute using the LSR MIB. What is needed is a > > way to find the index (mplsInSegmentIndex) for a given > > interface and label that is determined from the outsegment on > > the prior LSR. The interface MIB on both routers may be > > needed to get the ifindex of the other router. > > Being one who advocated the original change > to the indexing, I can live with the addition of a > mapping table and the indexing currently in v10 of > the MIB. > > > Note that even with this change the LSR MIB does not have > > enough information by itself to do the traceroute. > > Yes, there is a need to use the application- > specific MIBs to know where to start (i.e.: VPN, > or FTN). > > --Tom Tom, I wasn't clear in my second comment. The LSR MIB is used for RSVP/TE as well as LDP. For both getting the ifindex of the next hop interface requires using the interface MIB. For TE you'd want to trace an LSP from ingress to egress starting with the outgoing interface, label, and any other information available at the ingress. One peice of information that is not available to the ingress is the ifindex of the next-hop interface (unless the interface is unnumbered). The NMS can't get from the ingress any information the ingress does not have. It can get the IP address of the next hop and all next hops from the RRO (via the MIB). Using the interface addresses the ifindex can be determined. If you are tracing a given FEC I think the same is true, the ifindex is not normally known by the downstream node but the interface IP address is. The outsegment ifindex in the LDP MIB is for the current LSR just as the LSR MIB outsegment ifindex is for the current LSR. There is no direct way to get the ifindex of the next-hop other than looking at the mplsLdpPeerTransportAddr and looking that up that address in the interface MIB on the peer. I don't percieve this as a serious problem, however it is worth noting and a possible manageability improvement for either RSVP/TE or LDP would be to provide the ifindex in the signaling just for management purposes. For example, an optional suboject in the RRO could contain the ifindex of the prior IPv4 or IPv6 address subobject or new subobjects could be introduced which give both the address and ifindex. A similar change could be made to LDP. The other side ifindex could then be populated in the LSR MIB if known and the LSR MIB alone could support a traceroute. It is also worth noting that it is impossible to trace an LSP backwards but it could be a worthwhile capability. For example, if inseg on a given LSR had a consistent zero traffic and no apparent purpose it might be worth bein able to trace it back to see if it was the remnant of a software problem (or errant MIB set if someone were foolish enough to configure routers with MIB sets :^). Curtis [...trimmed...] > > > > I suggest you keep the index as you now have it and add a table: > > > > > > > > mplsInSegmentLocate > > > > SYNTAX MplsInSegmentLocate > > > > [...] > > > > INDEX { mplsInterfaceLocate, -- InterfaceIndexOrZero > > > > mplsInSegLabelLocate -- MplsLabel > > > > } > > > > ::= [...] > > > > > > > > MplsInSegmentLocate ::= SEQUENCE { > > > > mplsInterfaceLocate InterfaceIndexOrZero, > > > > mplsInSegLabelLocate MplsLabel, > > > > mplsInSegmentLocate MplsIndexType > > > > } > > > > > > > > This table would just return the mplsInSegmentIndex. From owner-mpls@UU.NET Sat Jun 21 06:20:59 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05354 for ; Sat, 21 Jun 2003 06:20:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouaj14150 for ; Sat, 21 Jun 2003 10:21:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouaj13953; Sat, 21 Jun 2003 10:20:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQotzu16937 for mpls-outgoing; Sat, 21 Jun 2003 06:31:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQotzu16932 for ; Sat, 21 Jun 2003 06:31:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotzu22785 for ; Sat, 21 Jun 2003 06:30:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotzu23027 for ; Sat, 21 Jun 2003 06:30:31 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotzu23014 for ; Sat, 21 Jun 2003 06:30:30 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5L6USai007623 for ; Sat, 21 Jun 2003 02:30:28 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD79926; Sat, 21 Jun 2003 02:30:27 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5L6URa16386 for mpls@uu.net; Sat, 21 Jun 2003 02:30:27 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQottv15226 for ; Thu, 19 Jun 2003 15:51:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQottv26307 for ; Thu, 19 Jun 2003 15:50:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQottv08356 for ; Thu, 19 Jun 2003 15:50:54 GMT Received: from ns.cnri.reston.va.us by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.CNRI.Reston.VA.US [132.151.1.1]) id QQottv08316 for ; Thu, 19 Jun 2003 15:50:50 GMT Received: from cnri-7-49.cnri.reston.va.us ([132.151.7.49] helo=ietfweb.cnri.reston.va.us) by ns.cnri.reston.va.us with esmtp (Exim 4.12) id 19T1gX-0006Qg-00; Thu, 19 Jun 2003 11:50:49 -0400 Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard From: Michael Lee Reply-To: mlee@foretec.com To: mpls@UU.NET Cc: Harald Tveit Alvestrand , "Barbara B. Fuller" , Alex Zinin Content-Type: text/plain Organization: Foretec Message-Id: <1056037780.23620.40.camel@ietfweb.cnri.reston.va.us> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 19 Jun 2003 11:49:40 -0400 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS, Last Monday, I have sent a message apologizing for the Last Call Announcement that was accidentally sent out during a new procedure test. Apparently, some people didn't get the message and I'm sending it again. If you have already seen this message, please discard this message. Last Friday, June 13th, we sent out a Last Call Announcement on draft-ietf-mpls-ldp-dod-restart. We were testing a new web application and mistakenly sent out this Last Call. We are sorry if this caused any confusion. Regards, Michael Lee Developer, IETF Secretariat From owner-mpls@UU.NET Sat Jun 21 06:26:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05532 for ; Sat, 21 Jun 2003 06:26:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouaj28384 for ; Sat, 21 Jun 2003 10:26:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouaj27735; Sat, 21 Jun 2003 10:26:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQotzu17020 for mpls-outgoing; Sat, 21 Jun 2003 06:34:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotzu17006 for ; Sat, 21 Jun 2003 06:33:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotzu02615 for ; Sat, 21 Jun 2003 06:30:19 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotzu22780 for ; Sat, 21 Jun 2003 06:30:18 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQotzu22764 for ; Sat, 21 Jun 2003 06:30:17 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5L6UEai007614 for ; Sat, 21 Jun 2003 02:30:15 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAD79923; Sat, 21 Jun 2003 02:30:14 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5L6UEx16341 for mpls@uu.net; Sat, 21 Jun 2003 02:30:14 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQotsv23823 for ; Thu, 19 Jun 2003 09:25:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQotsv26326 for ; Thu, 19 Jun 2003 09:24:36 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQotsv26581 for ; Thu, 19 Jun 2003 09:24:35 GMT Received: from eikenes.alvestrand.no by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nat.alvestrand.no [217.13.28.204]) id QQotsv26535 for ; Thu, 19 Jun 2003 09:24:34 GMT Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DCD96256C; Thu, 19 Jun 2003 11:24:18 +0200 (CEST) Date: Thu, 19 Jun 2003 11:24:18 +0200 From: Harald Tveit Alvestrand To: Kireeti Kompella , Adrian Farrel Cc: iesg@ietf.org, mpls@UU.NET Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard Message-ID: <610910000.1056014658@askvoll.hjemme.alvestrand.no> In-Reply-To: <20030618124901.I79256@kummer.juniper.net> References: <07b701c331f1$ffeeb820$681810ac@movaz.com> <0aa001c335cb$610e5bb0$681810ac@movaz.com> <20030618124901.I79256@kummer.juniper.net> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, it was a test that escaped. The developer has promised to send an apology to the MPLS list - I'm surprised he hasn't done so yet. The copy that went to ietf-announce WAS caught in time, fortunately! Harald --On onsdag, juni 18, 2003 14:00:50 -0700 Kireeti Kompella wrote: > > On Wed, 18 Jun 2003, Adrian Farrel wrote: > >> Did anyone decide there was an error here, or is this draft really in >> IETF last call? > > Harald is looking into it, which is pretty cool. I'm hoping he'll > let us know what he learns when he does. > > Meanwhile, I'm assuming there isn't an IETF-wide Last Call. Haven't > seen any mail on the IETF list (although I could easily have missed > it among the myths, CLOSE ASRGs and WG Reviews ...) > > Kireeti. > > From owner-mpls@UU.NET Tue Jun 24 01:29:49 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21897 for ; Tue, 24 Jun 2003 01:29:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoukr23620 for ; Tue, 24 Jun 2003 05:29:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoukr23523; Tue, 24 Jun 2003 05:29:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQouje09244 for mpls-outgoing; Mon, 23 Jun 2003 19:36:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQouje09224 for ; Mon, 23 Jun 2003 19:36:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoujc28731 for ; Mon, 23 Jun 2003 19:01:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoujc21425 for ; Mon, 23 Jun 2003 19:01:47 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQoujc21413 for ; Mon, 23 Jun 2003 19:01:47 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id B8DB256E5; Mon, 23 Jun 2003 15:01:46 -0400 (EDT) Message-ID: <009801c339b9$e4e14f50$681810ac@movaz.com> From: "Adrian Farrel" To: , References: <200306171156.HAA08200@ietf.org> Subject: Re: I-D ACTION:draft-iwata-mpls-crankback-06.txt Date: Mon, 23 Jun 2003 15:01:46 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Hi, This poor old draft is still looking for a home. It looks increasingly that the interest is in CCAMP since - that is where the ASON work is going on - the draft now uses protocol extensions from RFC3471/3 In summary, we have moved crankback over to use the IF_ID Error Spec rather than special new objects. The draft as currently structured provides a problem statement and a solution. We would welcome opinions about either half (or both). Adrian ----- Original Message ----- From: To: Cc: ; Sent: Tuesday, June 17, 2003 7:56 AM Subject: I-D ACTION:draft-iwata-mpls-crankback-06.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Crankback Signaling Extensions for MPLS Signaling > Author(s) : A. Farrel, A. Iwata et al. > Filename : draft-iwata-mpls-crankback-06.txt > Pages : 30 > Date : 2003-6-16 > > Recently, several routing protocol extensions for > advertising resource information in addition to topology > information have been proposed for use in distributed > constraint-based routing. In such a distributed routing > environment, however, the information used to compute a > constraint-based path may be out of date. This means > that LSP setup requests may be blocked by links or nodes > without sufficient resources. > This draft specifies crankback routing extensions for use > in Multi-Protocol Label Switching (MPLS) signaling using > RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for > LSP Tunnels', RFC3209, so that the LSP setup request can > be retried on an alternate path that detours around the > blocked link or node upon a setup failure. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-iwata-mpls-crankback-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-iwata-mpls-crankback-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mpls@UU.NET Tue Jun 24 03:24:13 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06058 for ; Tue, 24 Jun 2003 03:23:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoujd26510 for ; Mon, 23 Jun 2003 19:24:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoujd26211; Mon, 23 Jun 2003 19:24:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQouir28640 for mpls-outgoing; Mon, 23 Jun 2003 16:24:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQouir28635 for ; Mon, 23 Jun 2003 16:24:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQouir28621 for ; Mon, 23 Jun 2003 16:23:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouir19658 for ; Mon, 23 Jun 2003 16:23:39 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQouir19476 for ; Mon, 23 Jun 2003 16:23:28 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NGNJam024294 for ; Mon, 23 Jun 2003 12:23:24 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAE28012; Mon, 23 Jun 2003 12:23:19 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5NGNJQ20043 for mpls@uu.net; Mon, 23 Jun 2003 12:23:19 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQouir28591 for ; Mon, 23 Jun 2003 16:22:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQouir24984 for ; Mon, 23 Jun 2003 16:21:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouir15987 for ; Mon, 23 Jun 2003 16:21:33 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQouir15756 for ; Mon, 23 Jun 2003 16:21:25 GMT Received: from esalahudw2k01 ([161.44.69.112]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NGLKai023573 for ; Mon, 23 Jun 2003 12:21:21 -0400 (EDT) Reply-To: From: "Esa Salahuddin" To: "'mpls@uu.net'" Subject: unsubscribe Date: Mon, 23 Jun 2003 12:21:20 -0400 Organization: Cisco Systems Inc. Message-ID: <000001c339a3$7b5f4700$70452ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F93D8DE@ESEALNT442.al.sw.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit unsubscribe From owner-mpls@UU.NET Tue Jun 24 04:17:33 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06929 for ; Tue, 24 Jun 2003 04:16:29 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoukr21834 for ; Tue, 24 Jun 2003 05:28:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoukr21099; Tue, 24 Jun 2003 05:28:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQoujd08424 for mpls-outgoing; Mon, 23 Jun 2003 19:24:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoujd08419 for ; Mon, 23 Jun 2003 19:24:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoujd24205 for ; Mon, 23 Jun 2003 19:23:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoujd25425 for ; Mon, 23 Jun 2003 19:23:37 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQoujd25416 for ; Mon, 23 Jun 2003 19:23:36 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03222 for ; Mon, 23 Jun 2003 15:23:34 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA18415 for ; Mon, 23 Jun 2003 15:23:36 -0400 (EDT) Message-ID: <3EF7538B.9070405@marconi.com> Date: Mon, 23 Jun 2003 15:22:51 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030603 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Merging SE style reservations for make-before-break References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I wasn't 100% correct in my message. R4 won't reserve 1M. It will receive a reservation for 500K, and that is what it will reserve. R1 and R2 will reserve 1M on all shared components, but R4 will only reserve 500K. This is what should happen: 1: R1 sends a Path message with a TSPEC of 1M to R2 2: R2 records this and sends a Path message with a TSPEC of 1M to R3 3: R3 reserves 1M and sends a Resv with a FLOWSPEC of 1M to R2 4: R2 reserves 1M and sends a Resv with a FLOWSPEC of 1M to R1 5: R1 reserves 1M At this point, the first LSP is established. 6: R1 sends a Path in the same session to R4 with a TSPEC of 500K 7: R4 sends a Path to R2 with a TSPEC of 500K 8: R2 sends a Path to R3 with a TSPEC of 500K 9: R3 applies merging rules and sends a Resv with a FLOWSPEC of 1M (for both senders) to R2. It leaves the existing 1M reservation in place (but adds a new sender to it.) 10: R2 reserves 1M on its outbound interface and on any hardware components that the two LSPs share. For those components that are only used by the second LSP (the one requested in step 6), it is free to clip the reservation to the request size of 500K. The Resv that it sends to R4 will have a FLOWSPEC of 500K. (See RFC 2209 - note the behavior of the "UPDATE TRAFFIC CONTROL" section, the Path_Te and Fwd_Flowspec values. Also note the TC_AddFlowspec function in RFC 2205). 11: R4 reserves 500K and sends a Resv with a FLOWSPEC of 500K to R1. 12: R1 will apply the merging rules (yielding 1M) for the two FLOWSPECs received. For those components that are shared between the two LSPs, 1M will be reserved. For those components that are only used by the R1-R4-R2-R3 LSP, it is free to only reserve 500K. At this point, the second LSP is established - the "make" part of make before break. Now the first LSP will be torn down: 13: R1 tears the connection for the first LSP. The reservation is freed for those components that only service the first LSP (for example, the reservation on the interface that connects to R2). For those components that are shared between the two LSPs, the reservation is modified to 500K. R1 sends a PathTear to R2. 14: R2 receives the PathTear. As with R1, it frees the reservation for those components that only service the first LSP (for example, the reservation on the interface that connects to R1). For those components that are shared between the two LSPs, the reservation is modified to 500K. R2 sends a PathTear to R3. 15: R3 receives a PathTear. Since all components are shared in this router, it modifies all reservations in the session to 500K. 16: R3 sends out a Resv message with a FLOWSPEC of 500K (and the only remaining sender on the FILTERSPEC list) to R2. 17: R2 needs to do nothing, because the reservation matches what's already in place. Since the Resv that would be sent to R4 is that same as the Resv that's already being refreshed, it doesn't have to do anything more at this point. I hope this helps out a bit. Pay close attention to the reservation merging rules as defined in RFC 2205. They are a bit tricky to understand. RFC 2209 will also help explain it - just keep in mind that RFC 2209 is an informational RFC, not a standard - it's meant to clearly illustrate the concepts using a hypothetical router architecture. You don't have to build your internal implementation to match it if your architecture doesn't match. -- David Sundara Murugan wrote: > If R4 doesn't have 1M then the MBB lsp will fail. That doesn't sound correct. > > -sundara > > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: Tuesday, June 17, 2003 7:02 AM > To: mpls@UU.NET > Subject: Re: Merging SE style reservations for make-before-break > > > jiri prekow wrote: > >>I have a confgiuration as follows- >> >> >>R1========R2==========R3 >>\ / >> \ / >> \ / >> \R4/ >> >>lsp1 takes the path R1-R2-R3 with a reservation of 1M >>At this time you do a make-before-break for lsp1 with >>a lower bandwidth of say 500K, and it takes the path >>R1-R4-R2-R3. When you get the resv at R2 it will have a >>flow descriptor of 1M followed by 2 filter specs. When >>R2 sends out a resv to R4 for the new >>make-before-break lsp should the flow descriptor >>contain a value of 500K or should it be 1M. > > > 1M. > > The RSVP merging rules are pretty explicit. For classical RSVP, where > all reservations are made on the egress interface, you take the least > upper bound of the incoming reservations (with is 1M in this case), > reserve that and transmit that upstream towards your PHOP. > > With MPLS, it's functionally the same. You're not reserving only on the > egress interface, so your internal reservations (ingress bandwidth, > fabric bandwidth, egress bandwidth, connection, etc.) will be on a > per-LSP basis with appropriate sharing where possible, but the Resv you > send out will still be the least upper bound of its compponents. > > After the original LSP is torn down (the "break" step of "make before > break") then router R2 will re-sent its Resv message with a bandwidth of > 500K, since there is now only one LSP to merge. R3 will see this and > will change its reservation for the group at that time. > > -- David > From owner-mpls@UU.NET Tue Jun 24 08:00:52 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12772 for ; Tue, 24 Jun 2003 07:59:47 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoujp23133 for ; Mon, 23 Jun 2003 22:20:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoujp22981; Mon, 23 Jun 2003 22:20:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQoujb17141 for mpls-outgoing; Mon, 23 Jun 2003 18:52:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoujb17119 for ; Mon, 23 Jun 2003 18:52:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoujb23429 for ; Mon, 23 Jun 2003 18:46:53 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoujb01530 for ; Mon, 23 Jun 2003 18:46:53 GMT Received: from RS-SC-EXC6.rs.riverstonenet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host13.riverstonenet.com [64.95.122.13] (may be forged)) id QQoujb01508 for ; Mon, 23 Jun 2003 18:46:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Merging SE style reservations for make-before-break Date: Mon, 23 Jun 2003 11:46:49 -0700 Message-ID: Thread-Topic: Merging SE style reservations for make-before-break Thread-Index: AcM1DUUrg8lDyqpvT+qdoCwLuLD27AEqg+TA From: "Sundara Murugan" To: "David Charlap" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable If R4 doesn't have 1M then the MBB lsp will fail. That doesn't sound = correct. -sundara -----Original Message----- From: David Charlap [mailto:David.Charlap@marconi.com] Sent: Tuesday, June 17, 2003 7:02 AM To: mpls@UU.NET Subject: Re: Merging SE style reservations for make-before-break jiri prekow wrote: >=20 > I have a confgiuration as follows- >=20 > =20 > R1=3D=3D=3D=3D=3D=3D=3D=3DR2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DR3 > \ / > \ / > \ / > \R4/ >=20 > lsp1 takes the path R1-R2-R3 with a reservation of 1M > At this time you do a make-before-break for lsp1 with > a lower bandwidth of say 500K, and it takes the path > R1-R4-R2-R3. When you get the resv at R2 it will have a =20 > flow descriptor of 1M followed by 2 filter specs. When > R2 sends out a resv to R4 for the new > make-before-break lsp should the flow descriptor > contain a value of 500K or should it be 1M. 1M. The RSVP merging rules are pretty explicit. For classical RSVP, where=20 all reservations are made on the egress interface, you take the least=20 upper bound of the incoming reservations (with is 1M in this case),=20 reserve that and transmit that upstream towards your PHOP. With MPLS, it's functionally the same. You're not reserving only on the = egress interface, so your internal reservations (ingress bandwidth,=20 fabric bandwidth, egress bandwidth, connection, etc.) will be on a=20 per-LSP basis with appropriate sharing where possible, but the Resv you=20 send out will still be the least upper bound of its compponents. After the original LSP is torn down (the "break" step of "make before=20 break") then router R2 will re-sent its Resv message with a bandwidth of = 500K, since there is now only one LSP to merge. R3 will see this and=20 will change its reservation for the group at that time. -- David From owner-mpls@UU.NET Wed Jun 25 05:03:41 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05203 for ; Wed, 25 Jun 2003 05:02:36 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouov23753 for ; Wed, 25 Jun 2003 08:15:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouov23481; Wed, 25 Jun 2003 08:15:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQounf16448 for mpls-outgoing; Tue, 24 Jun 2003 21:56:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQounf16331 for ; Tue, 24 Jun 2003 21:55:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQounf19586 for ; Tue, 24 Jun 2003 21:53:42 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQounf14641 for ; Tue, 24 Jun 2003 21:53:41 GMT Received: from maildev.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQounf14624 for ; Tue, 24 Jun 2003 21:53:40 GMT Received: from avici.com (swdev108.avici.com [10.2.21.108]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h5OLrc322324; Tue, 24 Jun 2003 17:53:38 -0400 (EDT) Message-Id: <200306242153.h5OLrc322324@maildev.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: mpls@UU.NET Cc: David Charlap Subject: Re: Merging SE style reservations for make-before-break In-reply-to: Your message of "Mon, 23 Jun 2003 15:22:51 EDT." <3EF7538B.9070405@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Jun 2003 17:53:37 -0400 Sender: owner-mpls@UU.NET Precedence: bulk David, > R4 won't reserve 1M. It will receive a reservation for 500K, and that > is what it will reserve. R1 and R2 will reserve 1M on all shared > components, but R4 will only reserve 500K. I believe this is a valid implementation but based on reading RFC2205, I'd expect a somewhat different behavior. See below... [...] > At this point, the first LSP is established. > > 6: R1 sends a Path in the same session to R4 with a TSPEC of 500K > 7: R4 sends a Path to R2 with a TSPEC of 500K > 8: R2 sends a Path to R3 with a TSPEC of 500K > > 9: R3 applies merging rules and sends a Resv with a FLOWSPEC of 1M (for > both senders) to R2. It leaves the existing 1M reservation in place > (but adds a new sender to it.) > > 10: R2 reserves 1M on its outbound interface and on any hardware > components that the two LSPs share. For those components that are only > used by the second LSP (the one requested in step 6), it is free to clip > the reservation to the request size of 500K. The Resv that it sends to > R4 will have a FLOWSPEC of 500K. (See RFC 2209 - note the behavior of > the "UPDATE TRAFFIC CONTROL" section, the Path_Te and Fwd_Flowspec > values. Also note the TC_AddFlowspec function in RFC 2205). According to the spec, R2 could do that but there is nothing in the spec that really suggests it should be done. Instead, I would expect R2 to also send the 1M Resv to R4. R4 can base its admission control decision on the 1M flowspec from R2 and the 500K tspec from R1. It has both values and can thus figure out that the Resv is admissible. The following paragraph in section 2.1 of RFC2205 hints at this behavior: Sender Tspec A Path message is required to carry a Sender Tspec, which defines the traffic characteristics of the data flow that the sender will generate. This Tspec is used by traffic control to prevent over-reservation, and perhaps unnecessary Admission Control failures. An RSVP-TE implementation typically makes admission control decisions on receipt of the Path message based on the tspec. I would strongly suggest that it then accepts any Resv with a flowspec >= the Path tspec to cover this scenario. Markus >Sundara Murugan wrote: >> If R4 doesn't have 1M then the MBB lsp will fail. That doesn't sound correct. >> >> -sundara >> >> -----Original Message----- >> From: David Charlap [mailto:David.Charlap@marconi.com] >> Sent: Tuesday, June 17, 2003 7:02 AM >> To: mpls@UU.NET >> Subject: Re: Merging SE style reservations for make-before-break >> >> >> jiri prekow wrote: >> >>>I have a confgiuration as follows- >>> >>> >>>R1========R2==========R3 >>>\ / >>> \ / >>> \ / >>> \R4/ >>> [...] From owner-mpls@UU.NET Wed Jun 25 07:31:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07017 for ; Wed, 25 Jun 2003 07:31:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQounl03257 for ; Tue, 24 Jun 2003 23:29:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQounl02891; Tue, 24 Jun 2003 23:28:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQoums06374 for mpls-outgoing; Tue, 24 Jun 2003 18:36:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoums06367 for ; Tue, 24 Jun 2003 18:36:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoums10605 for ; Tue, 24 Jun 2003 18:36:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoums06299 for ; Tue, 24 Jun 2003 18:36:20 GMT Received: from maila.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maila.telia.com [194.22.194.231]) id QQoums06287 for ; Tue, 24 Jun 2003 18:36:19 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maila.telia.com (8.12.9/8.12.9) with ESMTP id h5OIaITJ014756 for ; Tue, 24 Jun 2003 20:36:18 +0200 (CEST) X-Original-Recipient: Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h5OIaIc16149 for ; Tue, 24 Jun 2003 20:36:18 +0200 (CEST) Message-ID: <3EF898E7.3000608@pi.se> Date: Tue, 24 Jun 2003 20:31:03 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG Subject: end of wg last call Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, this ends the wg last call on -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Wed Jun 25 15:07:01 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26196 for ; Wed, 25 Jun 2003 15:07:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoupi23690 for ; Wed, 25 Jun 2003 11:32:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoupi23567; Wed, 25 Jun 2003 11:32:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQouno09351 for mpls-outgoing; Wed, 25 Jun 2003 00:01:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouno06921 for ; Wed, 25 Jun 2003 00:00:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouno09968 for ; Wed, 25 Jun 2003 00:00:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouno18546 for ; Wed, 25 Jun 2003 00:00:17 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQouno18535 for ; Wed, 25 Jun 2003 00:00:16 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16505 for ; Tue, 24 Jun 2003 20:00:14 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA01701 for ; Tue, 24 Jun 2003 20:00:15 -0400 (EDT) Message-ID: <3EF8E5E8.7060506@marconi.com> Date: Tue, 24 Jun 2003 19:59:36 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030603 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Merging SE style reservations for make-before-break References: <200306242153.h5OLrc322324@maildev.avici.com> In-Reply-To: <200306242153.h5OLrc322324@maildev.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Markus Jork wrote: >> >> 10: R2 reserves 1M on its outbound interface and on any hardware >> components that the two LSPs share. For those components that are only >> used by the second LSP (the one requested in step 6), it is free to clip >> the reservation to the request size of 500K. The Resv that it sends to >> R4 will have a FLOWSPEC of 500K. (See RFC 2209 - note the behavior of >> the "UPDATE TRAFFIC CONTROL" section, the Path_Te and Fwd_Flowspec >> values. Also note the TC_AddFlowspec function in RFC 2205). > > According to the spec, R2 could do that but there is nothing in the > spec that really suggests it should be done. Instead, I would expect > R2 to also send the 1M Resv to R4. Look again. RFC 2205: o Make a Reservation Call: TC_AddFlowspec( Interface, TC_Flowspec, TC_Tspec, TC_Adspec, Police_Flags ) -> RHandle [, Fwd_Flowspec] The TC_Flowspec parameter defines the desired effective QoS to admission control; its value is computed as the maximum over the flowspecs of different next hops (see the Compare_Flowspecs call below). The TC_Tspec parameter defines the effective sender Tspec Path_Te (see Section 2.2). The TC_Adspec parameter defines the effective Adspec. The Police_Flags parameter carries the three flags E_Police_Flag, M_Police_Flag, and B_Police_Flag; see Section 3.8. If this call is successful, it establishes a new reservation channel corresponding to RHandle; otherwise, it returns an error code. The opaque number RHandle is used by the caller for subsequent references to this reservation. If the traffic control service updates the flowspec, the call will also return the updated object as Fwd_Flowspec. Note the last paragraph - if the traffic control service updates the flowspec, the call will also return the updated object as Fwd_Flowspec. Since FLOWSPECs are always clipped to TSPECs when they're installed in the forwarder by traffic control, Fwd_Flowspec will never be greater than TC_Tspec when this function returns. (It may be less, depending on merging/blockading rules, but RSVP-TE doesn't normally implement those rules.) The Fwd_Flowspec returned is the value that is used in the outgoing Resv message. See RFC 2209: UPDATE TRAFFIC CONTROL ... 6. Compute Path_Te as the sum of the SENDER_TSPEC objects in this set of PSBs. ... o If TCSB is new: 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the police flags into TCSB. 2. Turn the Resv_Refresh_Needed flag on and make the traffic control call: TC_AddFlowspec( OI, TC_Flowspec, Path_Te, police_flags) -> Rhandle, Fwd_Flowspec 3. If this call fails ... 4. Otherwise (call succeeds), record Rhandle and Fwd_Flowspec in the TCSB. ... Then, in the RESV REFRESH sequence: ... o Select each sender PSB whose PHOP has address PH. Set the local flag B_Merge off and execute the following steps. 1. Select all TCSB's whose Filter_spec_list's match the SENDER_TEMPLATE object in the PSB and whose OI appears in the OutInterface_list of the PSB. ... 4. Merge the flowspecs from this set of TCSB's, as follows: - If B_Merge flag is off, compute the LUB over the flowspec objects. From each TCSB, use the Fwd_Flowspec object if present, else use the normal Flowspec object. ... Putting all this together, this is what is supposed to happen: 1: For a given outbound interface, you merge all the received FLOWSPECs together. 2: Then for each of the corresponding senders, you merge the TSPECs together. 3: You submit the merged FLOWSPEC and the merged TSPEC to traffic control to add/modify the flowspec. The actual resources that end up being reserved are returned in the Fwd_Flowspec object. This will never be greater than the merged TSPEC. It might be smaller. 4: When generating an outbound Resv, you merge the Fwd_Flowspec parameters from all of the different TCSB objects that have a reservation on the interface you're about to send your Resv message out on. (This will be only one TCSB for unicast connections. It could be more if there's a multicast connection.) The result of that merge is what's sent to the PHOP. > R4 can base its admission control decision on the 1M flowspec from R2 > and the 500K tspec from R1. It has both values and can thus figure > out that the Resv is admissible. The following paragraph in section 2.1 > of RFC2205 hints at this behavior: > > Sender Tspec > > A Path message is required to carry a Sender Tspec, which > defines the traffic characteristics of the data flow that the > sender will generate. This Tspec is used by traffic control > to prevent over-reservation, and perhaps unnecessary > Admission Control failures. This supports what I said - FLOWSPECs are clipped to TSPECs in traffic control to prevent wasted reservations. > An RSVP-TE implementation typically makes admission control decisions > on receipt of the Path message based on the tspec. I would strongly > suggest that it then accepts any Resv with a flowspec >= the Path tspec > to cover this scenario. First off, the assumption that an RSVP-TE implementation makes its reservations during Path processing is unwarranted. While there are some implementations that do, it is wrong to assume that everybody does, and it is wrong to assume that implementations are supposed to. As for accepting a Resv that's too large, that's always been acceptible. No implementation should reject such a message with or without -TE. But when it actually installs that reservation, it will get clipped to the TSPEC, and the Resv it sends upstream should be the clipped value that was installed, not the original value received. -- David From owner-mpls@UU.NET Wed Jun 25 21:10:43 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16516 for ; Wed, 25 Jun 2003 21:09:38 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoupk08670 for ; Wed, 25 Jun 2003 12:00:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoupk08522; Wed, 25 Jun 2003 12:00:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQounm01040 for mpls-outgoing; Tue, 24 Jun 2003 23:34:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQounm01032 for ; Tue, 24 Jun 2003 23:34:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQounm01816 for ; Tue, 24 Jun 2003 23:33:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQounm08499 for ; Tue, 24 Jun 2003 23:33:48 GMT Received: from mailb.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailb.telia.com [194.22.194.6]) id QQounm08472 for ; Tue, 24 Jun 2003 23:33:47 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailb.telia.com (8.12.9/8.12.9) with ESMTP id h5ONXVJh003772; Wed, 25 Jun 2003 01:33:35 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h5ONXVc22032; Wed, 25 Jun 2003 01:33:31 +0200 (CEST) Message-ID: <3EF8DE90.90408@pi.se> Date: Wed, 25 Jun 2003 01:28:16 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG CC: George Swallow , Bert Wijnen , Alex Zinin Subject: WG last call on the FTN mib module and the TE mib module Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, this mail starts a working group last call on Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base This ID has just been sent to the Internet-Drafts for publication and will show up shortly, in the mean time it will be found at: http://urax.utfors.net/~loa/draft-ietf-mpls-te-mib-10.txt This mail also the starts a working group last call on Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base draft-ietf-mpls-ftn-mib-07.txt for this mib module the wg last call is limited to the changes since the previous version version This ID has just been sent to the Internet-Drafts for publication and will show up shortly, in the mean time it will be found at: http://urax.utfors.net/~loa/draft-ietf-mpls-ftn-mib-07.txt The last call will en June 29th 09.00 ET. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Thu Jun 26 02:08:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05294 for ; Thu, 26 Jun 2003 02:07:48 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouro04412; Thu, 26 Jun 2003 02:14:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQouql20716 for mpls-outgoing; Wed, 25 Jun 2003 18:59:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouql20709 for ; Wed, 25 Jun 2003 18:59:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouql26000 for ; Wed, 25 Jun 2003 18:59:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouql14632 for ; Wed, 25 Jun 2003 18:59:02 GMT Received: from maildev.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQouql14618 for ; Wed, 25 Jun 2003 18:59:01 GMT Received: from avici.com (swdev108.avici.com [10.2.21.108]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h5PIwx329470 for ; Wed, 25 Jun 2003 14:58:59 -0400 (EDT) Message-Id: <200306251858.h5PIwx329470@maildev.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: mpls@UU.NET Subject: Re: Merging SE style reservations for make-before-break In-reply-to: Your message of "Tue, 24 Jun 2003 19:59:36 EDT." <3EF8E5E8.7060506@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jun 2003 14:58:59 -0400 Sender: owner-mpls@UU.NET Precedence: bulk David, see my response at the end... > Markus Jork wrote: > >> > >> 10: R2 reserves 1M on its outbound interface and on any hardware > >> components that the two LSPs share. For those components that are only > >> used by the second LSP (the one requested in step 6), it is free to clip > >> the reservation to the request size of 500K. The Resv that it sends to > >> R4 will have a FLOWSPEC of 500K. (See RFC 2209 - note the behavior of > >> the "UPDATE TRAFFIC CONTROL" section, the Path_Te and Fwd_Flowspec > >> values. Also note the TC_AddFlowspec function in RFC 2205). > > > > According to the spec, R2 could do that but there is nothing in the > > spec that really suggests it should be done. Instead, I would expect > > R2 to also send the 1M Resv to R4. > > Look again. > > RFC 2205: > > o Make a Reservation > > Call: TC_AddFlowspec( Interface, TC_Flowspec, > TC_Tspec, TC_Adspec, Police_Flags ) > -> RHandle [, Fwd_Flowspec] > > The TC_Flowspec parameter defines the desired effective QoS > to admission control; its value is computed as the maximum > over the flowspecs of different next hops (see the > Compare_Flowspecs call below). The TC_Tspec parameter > defines the effective sender Tspec Path_Te (see Section > 2.2). The TC_Adspec parameter defines the effective Adspec. > The Police_Flags parameter carries the three flags > E_Police_Flag, M_Police_Flag, and B_Police_Flag; see Section > 3.8. > > If this call is successful, it establishes a new reservation > channel corresponding to RHandle; otherwise, it returns an > error code. The opaque number RHandle is used by the caller > for subsequent references to this reservation. If the > traffic control service updates the flowspec, the call will > also return the updated object as Fwd_Flowspec. > > Note the last paragraph - if the traffic control service updates the > flowspec, the call will also return the updated object as Fwd_Flowspec. > Since FLOWSPECs are always clipped to TSPECs when they're installed in > the forwarder by traffic control, Fwd_Flowspec will never be greater > than TC_Tspec when this function returns. (It may be less, depending on > merging/blockading rules, but RSVP-TE doesn't normally implement those > rules.) > > The Fwd_Flowspec returned is the value that is used in the outgoing Resv > message. See RFC 2209: > > UPDATE TRAFFIC CONTROL > ... > > 6. Compute Path_Te as the sum of the SENDER_TSPEC objects > in this set of PSBs. > > ... > > o If TCSB is new: > > 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the > police flags into TCSB. > > 2. Turn the Resv_Refresh_Needed flag on and make the > traffic control call: > > TC_AddFlowspec( OI, TC_Flowspec, > Path_Te, police_flags) > -> Rhandle, Fwd_Flowspec > > 3. If this call fails ... > > 4. Otherwise (call succeeds), record Rhandle and > Fwd_Flowspec in the TCSB. ... > > Then, in the RESV REFRESH sequence: > > ... > > o Select each sender PSB whose PHOP has address PH. Set the > local flag B_Merge off and execute the following steps. > > 1. Select all TCSB's whose Filter_spec_list's match the > SENDER_TEMPLATE object in the PSB and whose OI appears > in the OutInterface_list of the PSB. > > ... > > 4. Merge the flowspecs from this set of TCSB's, as follows: > > - If B_Merge flag is off, compute the LUB over the > flowspec objects. From each TCSB, use the > Fwd_Flowspec object if present, else use the > normal Flowspec object. > > ... > > Putting all this together, this is what is supposed to happen: > > 1: For a given outbound interface, you merge all the received > FLOWSPECs together. > > 2: Then for each of the corresponding senders, you merge the > TSPECs together. > > 3: You submit the merged FLOWSPEC and the merged TSPEC to traffic > control to add/modify the flowspec. The actual resources that end > up being reserved are returned in the Fwd_Flowspec object. This > will never be greater than the merged TSPEC. It might be smaller. > > 4: When generating an outbound Resv, you merge the Fwd_Flowspec > parameters from all of the different TCSB objects that have a > reservation on the interface you're about to send your Resv > message out on. (This will be only one TCSB for unicast > connections. It could be more if there's a multicast connection.) > The result of that merge is what's sent to the PHOP. > > > R4 can base its admission control decision on the 1M flowspec from R2 > > and the 500K tspec from R1. It has both values and can thus figure > > out that the Resv is admissible. The following paragraph in section 2.1 > > of RFC2205 hints at this behavior: > > > > Sender Tspec > > > > A Path message is required to carry a Sender Tspec, which > > defines the traffic characteristics of the data flow that the > > sender will generate. This Tspec is used by traffic control > > to prevent over-reservation, and perhaps unnecessary > > Admission Control failures. > > This supports what I said - FLOWSPECs are clipped to TSPECs in traffic > control to prevent wasted reservations. > > > An RSVP-TE implementation typically makes admission control decisions > > on receipt of the Path message based on the tspec. I would strongly > > suggest that it then accepts any Resv with a flowspec >= the Path tspec > > to cover this scenario. > > First off, the assumption that an RSVP-TE implementation makes its > reservations during Path processing is unwarranted. While there are > some implementations that do, it is wrong to assume that everybody does, > and it is wrong to assume that implementations are supposed to. > > As for accepting a Resv that's too large, that's always been acceptible. > No implementation should reject such a message with or without -TE. Good. That was really the main point I was trying to make in response to the original question and what's important for interoperability: an implementation can receive a flowspec that is larger than the tspec and needs to be clipped to the tspec for admission control. So in the scenario of the original question, it's best for R4 to not make any assumption about whether it's supposed to get a 500K or 1M reservation but instead look at the 500K tspec for admission control. This is guaranteed to give interoperability. > But when it actually installs that reservation, it will get clipped to > the TSPEC, and the Resv it sends upstream should be the clipped value > that was installed, not the original value received. We just seem to be interpreting one sentence in the spec differently where it defines the TC_AddFlowspec semantics: If the traffic control service updates the flowspec, the call will also return the updated object as Fwd_Flowspec. It all depends on what "If" means :-) My interpretation was that a modified 'Fwd_Flowspec' *may* be computed and if so, it gets sent upstream. The spec doesn't say you *should* compute a Fwd_Flowspec and in what way. But I guess that's outside the realm of the RSVP spec anyway and an intserv issue. Though even in the intserv specs I don't see anything authoritative on this. I also understand your interpretation and you may be completely right... I don't know. Markus From owner-mpls@UU.NET Thu Jun 26 20:51:13 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29229 for ; Thu, 26 Jun 2003 20:50:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouvb13731 for ; Fri, 27 Jun 2003 00:50:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouvb13553; Fri, 27 Jun 2003 00:50:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQouty00067 for mpls-outgoing; Thu, 26 Jun 2003 17:37:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouty29979 for ; Thu, 26 Jun 2003 17:36:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouty18532 for ; Thu, 26 Jun 2003 17:36:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouty01037 for ; Thu, 26 Jun 2003 17:36:52 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQouty01031 for ; Thu, 26 Jun 2003 17:36:52 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04447 for ; Thu, 26 Jun 2003 13:36:47 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03430 for ; Thu, 26 Jun 2003 13:36:47 -0400 (EDT) Message-ID: <3EFB2F0E.2030200@marconi.com> Date: Thu, 26 Jun 2003 13:36:14 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030603 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Merging SE style reservations for make-before-break References: <200306251858.h5PIwx329470@maildev.avici.com> In-Reply-To: <200306251858.h5PIwx329470@maildev.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Markus Jork wrote: > > We just seem to be interpreting one sentence in the spec > differently where it defines the TC_AddFlowspec semantics: > > If the > traffic control service updates the flowspec, the call will > also return the updated object as Fwd_Flowspec. > > It all depends on what "If" means :-) > My interpretation was that a modified 'Fwd_Flowspec' *may* be computed > and if so, it gets sent upstream. The spec doesn't say you *should* > compute a Fwd_Flowspec and in what way. If traffic control updates the FLOWSPEC is the important condition. I think section 2.2 (the merging rules) of RFC 2205 explains when this happens: ... 3. (Re, Resv_Te) and Path_Te are passed to traffic control. Traffic control will compute the effective flowspec as the "minimum" of Path_Te and Resv_Te, in a service-dependent manner. I would assume that traffic control will update the flowspec if the minimum computed in step 3 is different from the requested flowspec. But you're right that we're probably splitting hairs here. If an implementation chooses not to do this, and forwards the full-size FLOWSPEC, I don't think it will break anything - the PHOP should clip his reservation anyway. But it may lead to inefficient behavior in a multicast scenario. My effective TSPEC (Path_Te) may be different from my upstream neighbor's (due to having different senders on different PHOP interfaces.) If my upstream neighbor has a larger effective TSPEC than I do, he will clip my outbound FLOWSPEC to a larger value than I have installed in my hardware - which may result in lost packets. If I always send out a FLOWSPEC that corresponds to what I have installed in my hardware (the clipped value), then this won't happen, because the upstream node won't install a reservation larger than requested. In a unicast scenario, I don't think this can happen, but I'm not 100% sure of that. -- David From owner-mpls@UU.NET Thu Jun 26 22:15:54 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01203 for ; Thu, 26 Jun 2003 22:14:49 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouvg18887 for ; Fri, 27 Jun 2003 02:14:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouvg18527; Fri, 27 Jun 2003 02:14:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQouum03678 for mpls-outgoing; Thu, 26 Jun 2003 21:14:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQouum03631 for ; Thu, 26 Jun 2003 21:13:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouum09456 for ; Thu, 26 Jun 2003 21:12:58 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouum10671 for ; Thu, 26 Jun 2003 21:12:58 GMT Received: from mx1out.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.25.10]) id QQouum10659 for ; Thu, 26 Jun 2003 21:12:57 GMT Received: from linux1.gl.umbc.edu (linux1.gl.umbc.edu [130.85.60.38]) by mx1out.umbc.edu (8.12.8/8.12.8/UMBC-Central 1.11 mxout 1.2.2.3 $) with ESMTP id h5QLCmvf001732; Thu, 26 Jun 2003 17:12:49 -0400 (EDT) Received: from localhost (arun@localhost) by linux1.gl.umbc.edu (8.12.8/8.12.8) with ESMTP id h5QLCmev005482; Thu, 26 Jun 2003 17:12:48 -0400 X-Authentication-Warning: linux1.gl.umbc.edu: arun owned process doing -bs Date: Thu, 26 Jun 2003 17:12:48 -0400 (EDT) From: Arun Satyanarayana Reply-To: arun@umbc.edu To: mpls@UU.NET cc: Arun Satyanarayana Subject: Re: WG last call on the FTN mib module and the TE mib module Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-AvMilter-Key: 1056662270:e4213618247268fe72c6b5da9da60e5f X-Avmilter: Message Skipped, too small X-Processed-By: MilterMonkey Version 0.9 -- http://www.membrain.com/miltermonkey Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom and co., Regarding draft-ietf-mpls-te-mib-10.txt, please make some clarifications on how the configured parameters map to signalling: mplsTunnelIndex Please add to the description to say how this maps to signaled objects. Something like... "For tunnel LSPs signaled using RSVP-TE, this value should correspond to the Tunnel Id used for the RSVP-TE session." mplsTunnelInstance Description says... "For tunnel LSPs signaled using RSVP, this value should correspond to the RSVP source port used for the RSVP-TE session." There is no such field in RFC3209. Please change to say... "For tunnel LSPs signaled using RSVP-TE, this value should correspond to the LSP-ID used for the RSVP-TE sender." mplsTunnelIngressLSRId Surely this should be the source of the tunnel not the extended tunnel id. The description starts off right but goes wrong when it says... "When the MPLS signalling protocol is rsvp(2) this value SHOULD mimic the Extended Tunnel Id field in the SESSION object." Please change this to say... "When the MPLS signalling protocol is rsvp(2) this value should correspond to the Tunnel Sender Address in Sender Template." mplsTunnelIngressLSRId and mplsTunnelEgressLSRId Why is there no support for IPv6 source and destinations? mplsTunnelDescr Since this attribute cannot be signaled, please add a note to explain that the value of this object at transit and egress nodes will be automatically generated (or blank) according to the implementation and may not match the value at the ingress. mplsTunnelSessionAttributes It would be helpful if these bits more closely matched the signaled Session Attribute flags from RFC3209 and so on. It is also helpful to have flags for triggering separate qualities of the tunnel. So... fastReroute (0) is useful but should be split into fastRerouteNodeProt and fastRerouteBWProt. recordRoute(4) is useful but we also need recordRouteLabels. Please state how each flag maps to a flag in the Session Attribute object. Thanks, _arun_ ============================================================ From: "Loa Andersson" To: "MPLS WG" Cc: "George Swallow" ; "Bert Wijnen" ; "Alex Zinin" Sent: Tuesday, June 24, 2003 7:28 PM Subject: WG last call on the FTN mib module and the TE mib module > All, > > this mail starts a working group last call on > > Multiprotocol Label Switching (MPLS) Traffic Engineering > Management Information Base > > > > This ID has just been sent to the Internet-Drafts for publication and > will show up shortly, in the mean time it will be found at: > > http://urax.utfors.net/~loa/draft-ietf-mpls-te-mib-10.txt > > This mail also the starts a working group last call on > > Multiprotocol Label Switching (MPLS) Forwarding Equivalence > Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) > Management Information Base > > draft-ietf-mpls-ftn-mib-07.txt > > for this mib module the wg last call is limited to the changes since the > previous version version > > This ID has just been sent to the Internet-Drafts for publication and > will show up shortly, in the mean time it will be found at: > > http://urax.utfors.net/~loa/draft-ietf-mpls-ftn-mib-07.txt > > The last call will en June 29th 09.00 ET. > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se From owner-mpls@UU.NET Thu Jun 26 22:18:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01297 for ; Thu, 26 Jun 2003 22:18:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouvh27168 for ; Fri, 27 Jun 2003 02:18:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouvh26696; Fri, 27 Jun 2003 02:17:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQouup07485 for mpls-outgoing; Thu, 26 Jun 2003 21:59:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQouup07470 for ; Thu, 26 Jun 2003 21:59:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouup11458 for ; Thu, 26 Jun 2003 21:58:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouup06071 for ; Thu, 26 Jun 2003 21:58:51 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQouup06066 for ; Thu, 26 Jun 2003 21:58:51 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 6076956E5; Thu, 26 Jun 2003 17:58:50 -0400 (EDT) Message-ID: <042f01c33c2e$205d3f50$681810ac@movaz.com> From: "Adrian Farrel" To: "MPLS WG" Cc: , "Thomas D. Nadeau" , "Cheenu Srinivasan" , "'Arun Viswanathan'" References: <3EF8DE90.90408@pi.se> Subject: Re: WG last call on the FTN mib module and the TE mib module Date: Thu, 26 Jun 2003 17:58:50 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_042C_01C33C0C.990E6F40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_042C_01C33C0C.990E6F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am working my way through draft-ietf-mpls-te-mib-10.txt and thought I = would send comments as I find them, rather than allowing them to pile = up. Very many appologies that these comments come so late in the day. My = excuse is that I last implemented this draft about three years ago. Much = has changed but many of my gripes then have not been answered. I have = not been focused on the review of this draft in the intervening years. Adrian 1) Section 2. An explicitly routed LSP (ERLSP) is referred to as an MPLS tunnel. It consists of one in-segment and/or one out- < segment at the ingress/egress LSRs, each segment being > segment at the egress/ingress LSRs, each segment being associated with one MPLS interface. These are also referred to as tunnel segments. 2) LER or LSR? Throughout, you use (e.g.) "ingress LSR". Architecture would=20 have us say "ingress LER". 3) Section 2 (and several other places) An explicitly routed LSP (ERLSP) is referred to as an MPLS tunnel. It consists of one in-segment and/or one out- segment at the ingress/egress LSRs, each segment being associated with one MPLS interface. These are also referred to as tunnel segments. Additionally, at an intermediate LSR, we model a connection as consisting of one or more in-segments and/or one or more out-segments. The binding or interconnection between in-segments and out- segments in performed using a cross-connect. These objects are defined in the MPLS Label Switch Router MIB [LSRMIB]. Your implication here (and explicit statement elsewhere) is=20 that an ingress may have just one out-segment and that an=20 egress may have just one in-segment. This is an unnecessary restriction: - there is nothing to prevent multiple segements in this=20 MIB module - there is nothing to prevent multiple segements in the LSR MIB module - there is nothing to prevent multiple segements in the signaling protocols - it is quite feasible (especially at the egress) that multiple segments will exist. Simply remove the text. 4) Section 5 < These actions may need to be accompanied with corresponding > These actions may need to be accompanied by corresponding actions using [LSRMIB] to establish and configure tunnel segments, if this is done manually. 5) Section 5 Also, the in-segment and out-segment performance tables, mplsInSegmentPerfTable and mplsOutSegmentPerfTable [LSRMIB], should be used to determine performance of the tunnels and tunnel segments. Don't forget the mplsTunnelPerfTable. 6) Section 5.1 Don't forget the mplsTunnelPerfTable. 7) Section 6.1 This table talks about segments. There are no segments in the=20 TE-MIB module. Are you worried about support of p2mp and mp2p tunnels? If so: i) The non-support of such tunnels should be made clear earlier in the document ii) You will need to clarify why you talk about support of multiple in/out segments (yes, I understand there are reasons appart from p2mp/mp2p, but you will need to=20 state them). iii) You will not need to worry about the distinction=20 between Source LSR Id and Extended Tunnel Id. 8) Section 6.3, 6.4 and 6.5 Please state the meaning of the HopTable, ARHopTable and=20 CHopTable at transit and egress LSRs. 9) Section 6.4 and 6.5 Please qualify further by pointing out that ARHopTable and CHopTable are only relevant if signaling is used. 10) Section 6.7 Please add something like... The mplsTunnelCRLDPResTable does not need to be supported=20 by implementations that do not support the CR-LDP=20 signaling protocol. 11) Section 9 Since you're using createAndGo, I think you need to put the dependent tables first. Otherwise your C&G on the tunnelTable will fail. 12) Section 9 HopTable The following denotes the beginning of the network, or the first hop. We have used the fictitious LSR identified by "192.168.100.1" as our example head-end router. and The following denotes the end of the network, or the last hop in our example. We have used the fictitious LSR identified by "192.168.101.1" as our end router. Who can truly say where a network begins and ends? 13) Section 9 First entry in HopTable mplsTunnelHopType =3D loose (2), I think you'll want to make this strict. 14) Section 9 mplsTunnelHopPathOptionName The way I read the description of mplsTunnelHopPathOptionName the name applies to the entire path option identified by mplsTunnelHopPathOptionIndex. That means that in your example you should either change the mplsTunnelHopPathOptionIndex for the two hops, or not change the mplsTunnelHopPathOptionName. 16) MIB Revision history DESCRIPTION < "Initial draft version issues as part of RFC XXXX." > "Initial draft version issued as part of RFC XXXX." 17) mplsTunnelIndexNext Please add text to explain that this object is only used at ingress LSRs. At transit and egress LSRs for manually provisioned tunnels, the value of mplsTunnelIndex should be copied from tunnelTable at the ingress. For signaled tunnels, the value of mplsTunnelIndex should be filled in by the signaling protocol. 18) mplsTunnelEntry Desription A tunnel entry needs to be uniquely identified across a MPLS network. Indices mplsTunnelIndex and < mplsTunnelInstance uniquely identify a tunnel on an > mplsTunnelInstance uniquely identify a tunnel on the LSR originating the tunnel. To uniquely identify a < tunnel across a MPLS network requires index > tunnel across an MPLS network requires index < mplsTunnelIngressLSRId. Last index > mplsTunnelIngressLSRId. The last index mplsTunnelEgressLSRId is useful in identifying all instances of a tunnel that terminate on the same egress LSR." 19) mplsTunnelEntry indexing I believe the order of indexes is wrong. Since tunnelIndex is in the context of the ingress it should follow the ingressLSRid.=20 This will allow you to easily find all locally originated tunnels. Since the tunnel index is part of the Session object and is technically subsidiary to the destination address it makes sense to make the index ordering INDEX { mplsTunnelIngressLSRId, mplsTunnelEgressLSRId, mplsTunnelIndex, mplsTunnelInstance } I believe this makes the table more easily searchable, but I would also understand INDEX { mplsTunnelIngressLSRId, mplsTunnelIndex, mplsTunnelInstance, mplsTunnelEgressLSRId } =20 20) mplsTunnelIndex If you refer to FRR here you should add a reference - to the object definition - to the informational references section 21) mplsTunnelIngressLSRId Twice you say "mimic". What had you in mind? Heavy sarcasm or a cartoon character? :-) If you mean "be equal to" please say so, but see the next point. 22) mplsTunnelIngressLSRId and mplsTunnelEgressLSRId I am very uneasy about the syntax of these objects and the description of mplsTunnelIngressLSRId. i) By allowing them to be of type MplsExtendedTunnelId you are allowing a user to configure a non-IP address. What would this mean? ii) By saying that the ingress and extended tunnel id fields SHOULD be the same you are opening up confusion! Can we keep the two separate concepts in separate objects please? That is, have an object called=20 mplsTunnelIngressLSRId and one called mplsTunnelExtTunnelId. I would understand if the second were read-only although I=20 think you should give the option of write access with some default behavior. iii) Could you please describe how these objects map to=20 signaling. I suspect that doing so will help resolve the two previous points. 23) mplsTunnelIsIf I think a note explaining that at transit LSRs this MUST be set to false would be good. Maybe section 8 should talk about mapping tunnels to interfaces at egress LSRs. ------=_NextPart_000_042C_01C33C0C.990E6F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I am working my way = through=20 draft-ietf-mpls-te-mib-10.txt and thought I would send comments as I = find them,=20 rather than allowing them to pile up.
 
Very many appologies that these = comments come so=20 late in the day. My excuse is that I last implemented this draft about = three=20 years ago. Much has changed but many of my gripes then have not been = answered. I=20 have not been focused on the review of this draft in the intervening=20 years.
 
Adrian

 
1) Section=20 2.

   An explicitly routed LSP (ERLSP) is referred to = as an=20 MPLS
   tunnel.  It consists of one in-segment and/or = one=20 out-
<  segment at the ingress/egress LSRs, each segment=20 being
>  segment at the egress/ingress LSRs, each segment=20 being
   associated with one MPLS interface.  These = are=20 also
   referred to as tunnel segments.
 
2) LER or LSR?
Throughout, you use (e.g.) "ingress = LSR".=20 Architecture would
have us say "ingress = LER".
 
3) Section 2 (and several other=20 places)
 
   An explicitly routed LSP = (ERLSP) is=20 referred to as an MPLS
   tunnel.  It consists of one=20 in-segment and/or one out-
   segment at the ingress/egress = LSRs,=20 each segment being
   associated with one MPLS = interface. =20 These are also
   referred to as tunnel segments. =20 Additionally, at an
   intermediate LSR, we model a = connection as=20 consisting of
   one or more in-segments and/or one or more = out-segments.
   The binding or interconnection between = in-segments=20 and out-
   segments in performed using a cross-connect. = These=20 objects
   are defined in the MPLS Label Switch Router MIB=20 [LSRMIB].
Your implication here (and explicit = statement=20 elsewhere) is
that an ingress may have just one = out-segment and=20 that an
egress may have just one in-segment. = This is an=20 unnecessary
restriction:
- there is nothing to prevent = multiple segements=20 in this
  MIB module
- there is nothing to prevent = multiple segements=20 in the
  LSR MIB = module
- there is nothing to prevent = multiple segements=20 in the
  signaling = protocols
- it is quite feasible (especially at = the egress)=20 that
  multiple segments will = exist.
 
Simply remove the text.
 
4) Section 5
 
<  These actions may need to = be=20 accompanied with corresponding
>  These=20 actions may need to be accompanied by = corresponding
  =20 actions using [LSRMIB] to establish and configure tunnel
   = segments, if this is done manually.
 
5) Section 5
 
   Also, the = in-segment
  =20 and out-segment performance tables, = mplsInSegmentPerfTable
   and=20 mplsOutSegmentPerfTable [LSRMIB], should be used to
   = determine=20 performance of the tunnels and tunnel segments.
Don't forget the=20 mplsTunnelPerfTable.
 
6) Section 5.1
 
Don't forget the=20 mplsTunnelPerfTable.
 
7) Section 6.1
 
This table talks about segments. There are no segments in the =
TE-MIB module.
 
Are you worried about support of p2mp and mp2p tunnels? If = so:
i)   The non-support of such tunnels should be made = clear
     earlier in the document
ii)  You will need to clarify why you talk about support = of
     multiple in/out segments (yes, I = understand there=20 are
     reasons appart from p2mp/mp2p, but you = will need=20 to
     state them).
iii) You will not need to worry about the distinction
     between Source LSR Id and Extended Tunnel=20 Id.
 
8) Section 6.3, 6.4 and 6.5
 
Please state the meaning of the HopTable, ARHopTable and
CHopTable at transit and egress LSRs.
 
9) Section 6.4 and 6.5
 
Please qualify further by pointing out that ARHopTable and
CHopTable are only relevant if signaling is used.
 
10) Section 6.7
 
Please add something like...
 
The mplsTunnelCRLDPResTable does not need to be supported
by implementations that do not support the CR-LDP
signaling protocol.
 
11) Section 9
 
Since you're using createAndGo, I = think you need=20 to put the
dependent tables first. Otherwise = your C&G on=20 the tunnelTable
will fail.
 
12) Section 9 HopTable
 
   The following denotes = the beginning=20 of the network, or the
   first hop. We have used the = fictitious=20 LSR identified by
   "192.168.100.1" as our example = head-end=20 router.
 
and
 
   The following denotes = the end of the=20 network, or the last
   hop in our example. We have used = the=20 fictitious LSR
   identified by "192.168.101.1" as our end=20 router.
 
Who can truly say where a network = begins and=20 ends?
 
13) Section 9 First entry in=20 HopTable
 
    =20 mplsTunnelHopType         &n= bsp;    =20 =3D loose (2),
 
I think you'll want to make this=20 strict.
 
14) Section=20 9 mplsTunnelHopPathOptionName
 
The way I read the description of=20 mplsTunnelHopPathOptionName
the name applies to the entire path = option=20 identified
by = mplsTunnelHopPathOptionIndex.
 
That means that in your example you = should either=20 change
the mplsTunnelHopPathOptionIndex for = the two=20 hops, or not
change the=20 mplsTunnelHopPathOptionName.
 
16) MIB Revision history
 
  =20 DESCRIPTION
<       "Initial draft = version=20 issues as part of RFC XXXX."
>       = "Initial draft version issued as part of RFC XXXX."
 
17) mplsTunnelIndexNext
 
Please add text to explain that this = object is=20 only used
at ingress LSRs. At transit and = egress LSRs for=20 manually
provisioned tunnels, the value of = mplsTunnelIndex=20 should
be copied from tunnelTable at the = ingress. For=20 signaled
tunnels, the value of mplsTunnelIndex = should be=20 filled in
by the signaling = protocol.
 
18) mplsTunnelEntry = Desription
 
        A=20 tunnel entry needs to be uniquely identified=20 across
          a MPLS = network.=20 Indices mplsTunnelIndex=20 and
<         = mplsTunnelInstance=20 uniquely identify a tunnel on=20 an
>         = mplsTunnelInstance=20 uniquely identify a tunnel=20 on the
          = LSR=20 originating the tunnel.  To uniquely identify=20 a
<         tunnel across = a MPLS=20 network requires = index
>        =20 tunnel across an MPLS network requires=20 index
<        =20 mplsTunnelIngressLSRId.  Last=20 index
>        =20 mplsTunnelIngressLSRId.  The last=20 index
         =20 mplsTunnelEgressLSRId is useful in identifying=20 all
          instances = of a=20 tunnel that terminate on the=20 same
          egress=20 LSR."
 
19) mplsTunnelEntry = indexing
 
I believe the order of indexes is = wrong. Since=20 tunnelIndex is in
the context of the ingress it should = follow the=20 ingressLSRid.
This will allow you to easily find = all locally=20 originated tunnels.
 
Since the tunnel index is part of the = Session=20 object and is
technically subsidiary to the = destination address=20 it makes sense
to make the index = ordering
 
   INDEX=20 {
     =20 mplsTunnelIngressLSRId,
     =20 mplsTunnelEgressLSRId,
     =20 mplsTunnelIndex,
     =20 mplsTunnelInstance
   }
 
I believe this makes the table more = easily=20 searchable, but I would
also understand
 
   INDEX=20 {
      = mplsTunnelIngressLSRId,
      = mplsTunnelIndex,
=20       mplsTunnelInstance,
     =20 mplsTunnelEgressLSRId
   }
 
 
20) mplsTunnelIndex
 
If you refer to FRR here you should = add a=20 reference
- to the object = definition
- to the informational references=20 section
 
21) = mplsTunnelIngressLSRId
 
Twice you say "mimic". What had you = in mind?=20 Heavy sarcasm or
a cartoon character? :-)
 
If you mean "be equal to" please say = so, but see=20 the next point.
 
22) mplsTunnelIngressLSRId and=20 mplsTunnelEgressLSRId
 
I am very uneasy about the syntax of = these=20 objects and the
description of=20 mplsTunnelIngressLSRId.
 
i)   By allowing them to be = of type=20 MplsExtendedTunnelId you
     are allowing = a user to=20 configure a non-IP address. What
     would this=20 mean?
ii)  By saying that the ingress = and extended=20 tunnel id fields
     SHOULD be = the same you=20 are opening up confusion!
     Can we = keep the two=20 separate concepts in separate objects
     = please?  That is,=20 have an object called
     = mplsTunnelIngressLSRId=20 and one called mplsTunnelExtTunnelId.
     I would = understand if=20 the second were read-only although I
     think you = should give=20 the option of write access with some
     default=20 behavior.
iii) Could you please describe how = these objects=20 map to
     signaling. I = suspect=20 that doing so will help resolve the
     two previous = points.
 
23) mplsTunnelIsIf
 
I think a note explaining that at = transit LSRs=20 this MUST be
set to false would be good. Maybe = section 8=20 should talk about
mapping tunnels to interfaces at = egress=20 LSRs.
 
------=_NextPart_000_042C_01C33C0C.990E6F40-- From owner-mpls@UU.NET Fri Jun 27 08:49:00 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26295 for ; Fri, 27 Jun 2003 08:47:55 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouvg18278 for ; Fri, 27 Jun 2003 02:14:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouvg18140; Fri, 27 Jun 2003 02:14:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQouun05266 for mpls-outgoing; Thu, 26 Jun 2003 21:28:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouun05244 for ; Thu, 26 Jun 2003 21:27:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQouun22415 for ; Thu, 26 Jun 2003 21:27:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouun28424 for ; Thu, 26 Jun 2003 21:27:41 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQouun28413 for ; Thu, 26 Jun 2003 21:27:40 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5QLRcai014251 for ; Thu, 26 Jun 2003 17:27:38 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAG35601; Thu, 26 Jun 2003 17:27:37 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5QLRbm11987 for mpls@uu.net; Thu, 26 Jun 2003 17:27:37 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouum02888 for ; Thu, 26 Jun 2003 21:07:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQouum01309 for ; Thu, 26 Jun 2003 21:07:25 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouum03252 for ; Thu, 26 Jun 2003 21:07:25 GMT Received: from jera.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQouum03245 for ; Thu, 26 Jun 2003 21:07:24 GMT Received: from dcserver.movaz.com (dcserver.movaz.com [172.16.24.4]) by jera.movaz.com (Postfix) with ESMTP id 62494C610 for ; Thu, 26 Jun 2003 17:07:24 -0400 (EDT) Date: Thu, 26 Jun 2003 17:07:24 -0400 (EDT) From: Arun Satyanarayana Reply-To: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk subscribe aruns@movaz.com From owner-mpls@UU.NET Fri Jun 27 10:24:39 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29999 for ; Fri, 27 Jun 2003 10:24:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQourf26587 for ; Wed, 25 Jun 2003 23:46:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQourf26337; Wed, 25 Jun 2003 23:46:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQouqc02644 for mpls-outgoing; Wed, 25 Jun 2003 16:32:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQouqc02639 for ; Wed, 25 Jun 2003 16:32:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQouqc08545 for ; Wed, 25 Jun 2003 16:32:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouqc04297 for ; Wed, 25 Jun 2003 16:32:38 GMT Received: from mailb.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailb.telia.com [194.22.194.6]) id QQouqc04277 for ; Wed, 25 Jun 2003 16:32:37 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailb.telia.com (8.12.9/8.12.9) with ESMTP id h5PGVsjP006987; Wed, 25 Jun 2003 18:31:54 +0200 (CEST) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2p2/8.10.1) with ESMTP id h5PGVsc19573; Wed, 25 Jun 2003 18:31:54 +0200 (CEST) Message-ID: <3EF9CD3D.5020005@pi.se> Date: Wed, 25 Jun 2003 18:26:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG CC: George Swallow , "Lai, Wai S (Waisum), ALABS" , "Ash, Gerald R (Jerry), ALABS" Subject: comment on the LDP MIB requirment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I had to read back a bit to understand the impact of the input from Wai Sum and Jerry. The working group last call has ended bu I would nevertheless like to make this comment: - the draft-lai-mpls-mib-rqmts-00.txt includes requirements that will make changes to the LDP necessary - the LDP MIB is based on the current LDP spec, thus it is my take that the draft is outside the scope of the current last call, and the authors are advided to take these comments into consideration only to the extent they don't involve changes that is not reflected the currect LDP version - on the other hand this discussion is within wg charter, and my suggestion is we continue the discussion on the mailing list and in Vienna to see if there is support for this draft. - IF there is interest we adopt the requirment spec as wg doc, and decide how we proceed with the extensions and changes necessary in the base documents -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Fri Jun 27 16:21:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19098 for ; Fri, 27 Jun 2003 16:20:28 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouya23374 for ; Fri, 27 Jun 2003 20:13:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouya22993; Fri, 27 Jun 2003 20:13:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQouxd17625 for mpls-outgoing; Fri, 27 Jun 2003 14:16:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQouxd17620 for ; Fri, 27 Jun 2003 14:16:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQouxd17966 for ; Fri, 27 Jun 2003 14:16:38 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxd03570 for ; Fri, 27 Jun 2003 14:16:37 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQouxd03547 for ; Fri, 27 Jun 2003 14:16:36 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5REGUai005690 for ; Fri, 27 Jun 2003 10:16:30 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAG67541; Fri, 27 Jun 2003 10:16:29 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5REGTS20849 for mpls@uu.net; Fri, 27 Jun 2003 10:16:29 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouxd17408 for ; Fri, 27 Jun 2003 14:15:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouxd25244 for ; Fri, 27 Jun 2003 14:15:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxd18267 for ; Fri, 27 Jun 2003 14:15:31 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQouxd18231 for ; Fri, 27 Jun 2003 14:15:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28769; Fri, 27 Jun 2003 10:15:27 -0400 (EDT) Message-Id: <200306271415.KAA28769@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-ftn-mib-07.txt Date: Fri, 27 Jun 2003 10:14:22 -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 : Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information Base Author(s) : T. Nadeau, C. Srinivasan, A. Viswanathan Filename : draft-ietf-mpls-ftn-mib-07.txt Pages : 36 Date : 2003-6-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring and monitoring Forwarding Equivalent Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ftn-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ftn-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27090938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ftn-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ftn-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27090938.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Jun 27 19:58:22 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26946 for ; Fri, 27 Jun 2003 19:58:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouyp12430 for ; Fri, 27 Jun 2003 23:58:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouyp12143; Fri, 27 Jun 2003 23:58:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQouxk05845 for mpls-outgoing; Fri, 27 Jun 2003 16:11:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouxk05765 for ; Fri, 27 Jun 2003 16:11:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouxk20744 for ; Fri, 27 Jun 2003 16:11:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxk22432 for ; Fri, 27 Jun 2003 16:11:01 GMT Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQouxk22184 for ; Fri, 27 Jun 2003 16:10:54 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5RGAeMO022804 for ; Fri, 27 Jun 2003 09:10:41 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAG76730; Fri, 27 Jun 2003 12:10:39 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5RGAdt22750 for mpls@uu.net; Fri, 27 Jun 2003 12:10:39 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouxk28463 for ; Fri, 27 Jun 2003 16:03:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouxk20600 for ; Fri, 27 Jun 2003 16:03:01 GMT From: virus-fighters-bot@cisco.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxk02430 for ; Fri, 27 Jun 2003 16:03:01 GMT Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70]) id QQouxk02397 for ; Fri, 27 Jun 2003 16:03:00 GMT Received: from cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2003 09:04:47 -0800 Received: from localhost (root@localhost) by sj-core-1.cisco.com (8.12.9/8.12.6) with SMTP id h5RG2xs3016436 for ; Fri, 27 Jun 2003 09:02:59 -0700 (PDT) Date: Fri, 27 Jun 2003 09:02:59 -0700 (PDT) Message-Id: <200306271602.h5RG2xs3016436@sj-core-1.cisco.com> To: Subject: Virus Alert 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 *** THIS IS AN AUTOMATED MESSAGE *** A mail message sent from this account to a Cisco employee had an attachment called your_details.zip. The file your_details.zip contained a virus. Please contact your local System Administrator for further assistance. From owner-mpls@UU.NET Fri Jun 27 19:58:10 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26914 for ; Fri, 27 Jun 2003 19:57:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouyp09707 for ; Fri, 27 Jun 2003 23:57:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouyp09115; Fri, 27 Jun 2003 23:56:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQouxk21696 for mpls-outgoing; Fri, 27 Jun 2003 16:00:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQouxk20268 for ; Fri, 27 Jun 2003 16:00:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQouxk09914 for ; Fri, 27 Jun 2003 16:00:13 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxk11245 for ; Fri, 27 Jun 2003 16:00:12 GMT Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72]) id QQouxk11131 for ; Fri, 27 Jun 2003 16:00:08 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5RG02Ou015060 for ; Fri, 27 Jun 2003 09:00:04 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAG76048; Fri, 27 Jun 2003 12:00:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5RG01m22596 for mpls@uu.net; Fri, 27 Jun 2003 12:00:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQouxj15718 for ; Fri, 27 Jun 2003 15:52:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQouxj10109 for ; Fri, 27 Jun 2003 15:51:17 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxj26212 for ; Fri, 27 Jun 2003 15:51:17 GMT Received: from EXCH-SJC-IMS2.force10networks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: corp.force10networks.com [206.54.51.125]) id QQouxj26171 for ; Fri, 27 Jun 2003 15:51:16 GMT Received: from EXCH-CLUSTER-02.force10networks.com ([10.11.0.52]) by EXCH-SJC-IMS2.force10networks.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 27 Jun 2003 08:51:14 -0700 Subject: RE: WG last call on the FTN mib module and the TE mib module Date: Fri, 27 Jun 2003 08:51:14 -0700 Message-ID: <19EAA7B606CB68489BDF1A74AB1C012368BD7B@EXCH-CLUSTER-02.force10networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: WG last call on the FTN mib module and the TE mib module Thread-Index: AcM8rLFY58Fa1+SpTqiPZPHYKo3c1wAFiImw From: "Arun Viswanathan" To: "Edward Harrison" , "MPLS WG" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Cc: "Cisco - Thomas Nadeau" , "Cheenu Srinivasan" X-OriginalArrivalTime: 27 Jun 2003 15:51:14.0825 (UTC) FILETIME=[F0882790:01C33CC3] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable Its done now. Thanks for reminding one more time. -arun =20 > -----Original Message----- > From: Edward Harrison [mailto:eph@dataconnection.com]=20 > Sent: Friday, June 27, 2003 2:25 AM > To: MPLS WG > Cc: Cisco - Thomas Nadeau; Cheenu Srinivasan; Arun Viswanathan > Subject: RE: WG last call on the FTN mib module and the TE mib module >=20 >=20 > Hi, >=20 > One thing I immediately notice in=20 > draft-ietf-mpls-te-mib-10.txt is that the > mplsTunnelEntry still includes an=20 > mplsTunnelExcludeAllAffinity object as > opposed to an mplsTunnelExcludeAnyAffinity (which is what is=20 > used in RFC > 3209). >=20 > Each time I've raised this in the past it has been agreed (by=20 > Tom at the > very least) that the object should be "Exclude-any", but the=20 > mark-up keeps > getting lost by the time the next version appears. >=20 > Any chance of fixing it before the draft goes to RFC? >=20 > Regards, >=20 > Ed >=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: 25 June 2003 00:28 > To: MPLS WG > Cc: George Swallow; Bert Wijnen; Alex Zinin > Subject: WG last call on the FTN mib module and the TE mib module >=20 >=20 > All, >=20 > this mail starts a working group last call on >=20 > Multiprotocol Label Switching (MPLS) Traffic Engineering > Management Information Base >=20 > >=20 > This ID has just been sent to the Internet-Drafts for publication and > will show up shortly, in the mean time it will be found at: >=20 http://urax.utfors.net/~loa/draft-ietf-mpls-te-mib-10.txt This mail also the starts a working group last call on Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base draft-ietf-mpls-ftn-mib-07.txt for this mib module the wg last call is limited to the changes since the previous version version This ID has just been sent to the Internet-Drafts for publication and will show up shortly, in the mean time it will be found at: http://urax.utfors.net/~loa/draft-ietf-mpls-ftn-mib-07.txt The last call will en June 29th 09.00 ET. --=20 /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Fri Jun 27 21:12:02 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28831 for ; Fri, 27 Jun 2003 21:10:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouuz01057 for ; Fri, 27 Jun 2003 00:23:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouuz00579; Fri, 27 Jun 2003 00:22:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQoutu06077 for mpls-outgoing; Thu, 26 Jun 2003 16:42:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoutu06029 for ; Thu, 26 Jun 2003 16:41:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoutu25818 for ; Thu, 26 Jun 2003 16:41:32 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoutu00329 for ; Thu, 26 Jun 2003 16:41:31 GMT Received: from kcmso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQoutu00312 for ; Thu, 26 Jun 2003 16:41:31 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5QGctnR015713 for ; Thu, 26 Jun 2003 11:41:30 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C0052B8F4; Thu, 26 Jun 2003 12:41:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on the LDP MIB requirement Date: Thu, 26 Jun 2003 11:41:22 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA011BEAA4@KCCLUST06EVS1.ugd.att.com> Thread-Topic: comment on the LDP MIB requirment Thread-Index: AcM7N2N/aQi5JcXgTsuMglS33neAbwAuvI8Q From: "Ash, Gerald R (Jerry), ALABS" To: "Loa Andersson" , "MPLS WG" Cc: "Ash, Gerald R (Jerry), ALABS" , "George Swallow" , "Lai, Wai S (Waisum), ALABS" , "Chung, Li-Jin W, ALABS" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable Loa, All, > I had to read back a bit to understand the impact of the input from > Wai Sum and Jerry. The working group last call has ended but I would > nevertheless like to make this comment: >=20 > - the draft-lai-mpls-mib-rqmts-00.txt includes requirements that > will make changes to the LDP necessary Loa, I'm surprised that you would just parrot this claim without = technical backup. This is merely an unsubstantiated assertion by 2 of = the MPLS MIB authors, to deflect the requirements in yet one more = creative way. No response was made to Eric Gray's post requesting = specifics to back this up = http://cell.onecall.net/mhonarc/mpls/current/msg00130.html. Various posts over the past year have requested specific MPLS MIB = extensions to meet identified gaps (see below). When the specifics were = rejected, then a different approach was tried to request designers to = propose enhancements to meet requirements = http://cell.onecall.net/mhonarc/mpls/2003-May/msg00006.html, again = without any forward motion. =20 Despite all this effort to meet a few critical SP requirements, no = attempt has been made to address the requirements or the specific MIB = enhancement proposals: Li Chung initially posted specific enhancements/needs to the MPLS list = on June 27, 2002 = http://cell.onecall.net/mhonarc/mpls/2002-Jun/msg00159.html. Go back = and review the thread, the specific extensions were not addressed. Wai Sum Lai initially posted to the ppvpn list on August 19, 2002 = (message attached below, ppvpn archives don't go back that far). The = specific extensions were not addressed, Tom requested and got = substantiation of the needs, but that was the end of the discussion. > - the LDP MIB is based on the current LDP spec, thus it is my take > that the draft is outside the scope of the current last call No changes to the LDP spec are proposed or needed. Therefore the = requirements and proposed extensions, made for one year on the list, are = well within the LDP MIB discussion window. They merely haven't been = seriously addressed. > the authors are advised to take these comments into consideration > only to the extent they don't involve changes that is not reflected > the current LDP version Since none of the requirements propose (or intend) changes to the LDP = spec, the authors of the LDP MIB should therefore take into full = consideration all of the requirements. =20 > - on the other hand this discussion is within wg charter, and my > suggestion is we continue the discussion on the mailing list and > in Vienna to see if there is support for this draft. >=20 > - IF there is interest we adopt the requirement spec as wg doc, > and decide how we proceed with the extensions and changes necessary > in the base documents The requirements spec is the latest attempt to get high-priority MPLS = MIB requirements into the MPLS MIBs. Again, these = gaps/needs/requirements are based on extensive testing of MPLS MIBs by a = large carrier with a very large MPLS deployment, wherein a quality = implementation of these MIBs, and MPLS OAM in general, are absolutely = required to meet critical operational needs going forward. Jerry > -----Original Message----- > From: Lai, Wai S (Waisum), ALASO=20 > Sent: Monday, August 19, 2002 5:16 PM > To: ppvpn@ppvpn.francetelecom.com > Subject: Proposal for MPLS-VPN-MIB enhancements >=20 > I would like to propose the following enhancements for consideration = in > draft-ietf-ppvpn-mpls-vpn-mib-04: >=20 > (1) Currently, there is the mplsNumVrfRouteMaxThreshExceeded = notification > when the VRF maximum route threshold is exceeded. It is suggested to = add > a counter for the number of routes dropped due to such threshold being > exceeded. The reporting of such a count is useful for capacity = planning > and for threshold tuning purposes. >=20 > (2) In the mplsVpnVrfRouteTargetTable table, it appears that there is = no > explicit mapping between the route targets (RT) and their associated = Route > Distinguisher (RD). It is suggested to add such association between = VRF, > RD, and RT in this table. >=20 > Comments are welcome. > Thanks, Wai Sum. From owner-mpls@UU.NET Sat Jun 28 11:28:41 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25253 for ; Sat, 28 Jun 2003 11:27:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouzh05083 for ; Sat, 28 Jun 2003 04:23:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouzh03936; Sat, 28 Jun 2003 04:22:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQouxo29171 for mpls-outgoing; Fri, 27 Jun 2003 17:05:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQouxo29083 for ; Fri, 27 Jun 2003 17:05:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQouxo20844 for ; Fri, 27 Jun 2003 17:04:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxo17910 for ; Fri, 27 Jun 2003 17:04:11 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQouxo17886 for ; Fri, 27 Jun 2003 17:04:10 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id 8894C17FE; Fri, 27 Jun 2003 13:04:09 -0400 (EDT) Message-ID: <04cc01c33cce$202e2350$681810ac@movaz.com> From: "Adrian Farrel" To: "MPLS WG" Cc: , "Thomas D. Nadeau" , "Cheenu Srinivasan" , "'Arun Viswanathan'" References: <3EF8DE90.90408@pi.se> <042f01c33c2e$205d3f50$681810ac@movaz.com> Subject: Re: WG last call on the FTN mib module and the TE mib module Date: Fri, 27 Jun 2003 13:04:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C9_01C33CAC.98ED35F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_04C9_01C33CAC.98ED35F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As promised, here is the continuation of my review of this draft. This concludes my comments. I'm afraid I don't have the stamina to work on the conformance statement. Adrian =3D=3D=3D=3D=3D=3D=3D=3D=3D 24) mplsTunnelResourcePointer Description This refers to "segment" twice. But we are not dealing=20 in segments in this MIB table. We are dealing in=20 tunnel instances (or if you must, LSPs). 25) mplsTunnelPrimaryInstance It is very unclear what you mean in this case by=20 "primary". I think the description needs to be enhanced. For example, do you mean the tunnel instance that is=20 actually established and active at the moment? No, it can't be that because in mplsTunnelInstancePriority allows two instances to be active at once. Does it mean "preferred"? Wouldn't that be covered by the instance with the highest priority? Perhaps it means the instance that carries the full=20 configuration? No this is the definition of the row with tunnel instance zero. 26) mplsTunnelTable Given that I have a tunnel with many instances defined, how do I find which instance(s) are currently active? Do I have to read each of them and collect the ones with operStatus up? 27) mplsTunnelInstancePriority "This value indicates which priority, in descending order, with 0 indicating the lowest priority, within a group of tunnel instances. A group of < tunnel instances is defined as a set of tunnels > tunnel instances is defined as a set of LSPs with the same mplsTunnelIndex in this table, but < with a different mplsTunnelInstance. Tunnel group > with a different mplsTunnelInstance. Tunnel instance priorities are used to denote the priority at which 28) mplsTunnelRole (out of order, sorry) SYNTAX INTEGER { head(1), transit(2), tail(3) } I believe you need BITS not INTEGER since a tunnel may be set up between interfaces on a single LSR making it both ingress and egress. You could alternatively add: head_tail(4) but I think that is less useful. 29) mplsTunnelExcludeAllAfinity As Ed says, this should read "Any". Also in the description. 30) mplsTunnelPrimaryUpTime This description is inadequate. What is meant be "active"? See point 25) for questions about what a primary instance is. Is this value present in the row for every instance that is not a primary instance? If so, why? 31) mplsTunnelPathChanges < "Specifies the number of times the paths has changed > "Specifies the number of times the path has changed for this tunnel since its creation." 32) mplsTunnelPathChanges and mplsTunnelLastPathChange Do you mean "for this tunnel instance" or are you trying=20 to capture the case where a tunnel has changed path by any means including a change of instance? What do you mean by "path change"? Hop, CHop or ARHop? 33) mplsTunnelCreationTime Please be more specific. What does "came into existence" mean? 34) mplsTunnelStateTransisitions Please say which "state" you are refering to. 35) mplsTunnelOperStatus (and probably all operStatus objects) At the MIB Meeting (TM) we took an action that "unknown"=20 would always have value (1) unless there was good reason in which case it must be stated in the MIB modules. 36) mplsTunnelRowStatus "This variable is used to create, modify, and/or < delete a row in this tabole. When a row in this > delete a row in this table. =20 37) mplsTunnelRowStatus When a row in this table is in active(1) state, no objects in that row can be modified except mplsTunnelRowStatus and mplsTunnelStorageType." Can be modified by whom/what? Presumably a dynamic signaling protocol could modifiy this table regardless of the rowStatus. Can a user not change the adminStatus when rowStatus is active? 38) mplsTunnelStorageType (and all similar fields). The text here is confusing. "This variable indicates the storage type for this object. If this variable is set to readOnly(5), and the corresponding entry is removed, then the agent must remove this row shortly thereafter [RFC2579]. What is the difference between an "entry" and a "row"? Where you say "entry", do you mean "the managed object represented by this entry in the table"? Setting this object to permanent(4) indicates that this object should be restored automatically after failures. What do you mean by "this object"? Do you mean the "managed object represented by this entry in the table"? 39) mplsTunnelHopListIndexNext Shouldn't the syntax be MplsPathIndexOrZero? 40) All IndexNext objects I recall an email discussion with Bert about how these=20 objects should be managed and described. The concern is with producing unnecessary lacunae in the table. I think the position "agreed" upon was to cut over to using the IndexInteger and IndexIntegerNextFree TCs=20 from RFC3289. 41) mplsTunnelHopTable Please explicitly state the meaning of this table for LSRs that are not the ingress of the tunnel instance. This text should also be placed in the description of mplsTunnelHopTableIndex. 41) mplsTunnelHopTable "The mplsTunnelHopTable is used to indicate the hops, < strict or loose, for an MPLS tunnel defined in < mplsTunnelTable, > strict or loose, for an instance of an MPLS tunnel > defined in mplsTunnelTable, 42) mplsTunnelHopTable when it is established via signalling, for the outgoing direction of the tunnel. =20 What does this mean?=20 i) Why is it limited to signaling? This is a convenient place to record the path of a manula tunnel instance=20 if it is known. ii) Are you trying to say that the only hops present are the downstream hops? Thus in RSVP-TE terms, at=20 transit LSRs, this matches the received ERO. If so, please say so. 43) mplsTunnelHopTable The first row in the table is the first hop after the origination point of the tunnel. =20 In which case your example in section 9 is broken. 44) mplsTunnelHopAddressType mplsTunnelHopAddrUnnum should be referred to. If the object is set to lspid(5), then all but the mplsTunnelHopLspId should be referred to. Note that lspid(5) is a valid option only for tunnels signaled via CRLDP" What do you mean by "all but the mplsTunnelHopLspId should be referred to"? 45) mplsTunnelHopAddress I am confused by this object and the associated textual=20 convention. i) Why are 32 octets required to carry a hop address? ii) Is there not already a standard TC for carrying IP addresses? iii) If you are going to use a "free-form" octet string (not my favorite) then why is it necessary to=20 have a separate object and TC for AS number? 46) mplsTunnelHopAddrUnnum If this only holds the interface id, where is the=20 router id? 47) mplsTunnelHopType and mplsTunnelHopInclude I believe you should combine these since strict/loose has no meaning for exclusion. This gives... mplsTunnelHopType OBJECT-TYPE SYNTAX INTEGER { strict(1), loose(2), exclude(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether this tunnel hop is routed in a strict or loose fashion, or is to be excluded from the computed and actual paths." ::=3D { mplsTunnelHopEntry 10 } 48) mplsTunnelHopPathOptionName Must this be present for every hop with the same mplsTunnelHopListIndex and mplsTunnelHopPathOptionIndex? If so, must it be identical? 49) mplsTunnelHopEntryPathComp So many questions! i) This is not a per hop piece of information. This and point 48) suggest that you need a PathOption table. ii) How is this useful? It seems you are mixing two issues. a) the need to control whether CSPF or simple next-hop routing should be invoked at the ingress, b) whether the user is allowed to=20 specify other than the ingress and egress addresses. iii) Note that the user cannot specify the ingress since the source is not in the hop table! 50) mplsTunnelHopRowStatus "tabole" 51) mplsTunnelResourceTable An old chestnut, this one... Does this table hold the requested values or the actual=20 values? In other words, what effect does Admisssion=20 Control and Resv have on the objects in this table? What does the table betoken at non-ingress nodes? The values received on the setup request? When you say the values are copied into LSR MIB module objects, are you implying that the two objects always contain the same values? 52) mplsTunnelResourceExBurstSize,=20 mplsTunnelResourceFrequency and=20 mplsTunnelResourceWeight These seem to be duplicated by... mplsTunnelCRLDPResExBurstSize,=20 mplsTunnelCRLDPResFrequency and=20 mplsTunnelCRLDPResWeight Must I use both? 53) mplsTunnelResourceRowStatus "tabole" 54) mplsTunnelARHopTable Need a description of the menaing of this table at=20 non-ingress nodes. The question is whether this reflects the RRO from the Resv, or the splice of the RRO from the Path=20 and the Resv. 55) mplsTunnelARHopTable "The mplsTunnelARHopTable is used to indicate the hops, strict or loose, for an MPLS tunnel defined How can there be a loose hop in the ARHopTable? Fortunately you don't have an object for this. 56) mplsTunnelARHopTable Please note that since the information necessary to < build entries within this table are not provided by > build entries within this table is not provided by 56) mplsTunnelARHopTable I believe it is important to add a note to point out that the contents of this table may change while you are walking it. This may lead to the NMS perceiving a path which appears to include loops. You should mention that the mplsTunnelLastPathChange object can be used to verify that the AR read is valid. 57) mplsTunnelARHopEntry "An entry in this table represents a tunnel hop. An entry is created by a network administrator for signaled ERLSP set up by an MPLS signalling protocol." Huh? Surely it is created by the signaling protocol. 58) mplsTunnelARHopAddrUnnum (and all unnum addresses) I just noticed the TC for this is an OctetString. Why? What is wrong with putting 32 bit values in 32 bit objects? 59) mplsTunnelARHopIpPrefixLen How would this ever be other than a full prefix? In other words, this object is redundant. 60) mplsTunnelARHopAsNumber How do you expect this to be present in the AR? There is no way to signal it. 61) mplsTunnelARHopTable What about labels and local protection flags (both in the RRO in RFC3209)? Are we defering these only to the GMPLS MIB? 62) mplsTunnelCHopTable "The mplsTunnelCHopTable is used to indicate the hops, strict or loose, for an MPLS tunnel defined in mplsTunnelTable, as computed by a constraint- based routing protocol, based on the mplsTunnelHopTable for the outgoing direction of the tunnel. Each row in this table is indexed by What do you mean by the "outgoing direction of the tunnel"? Are you trying to say that this table only holds information for LSRs downstream of this LSR (which would make it=20 behave as the mplsTunnelHopTable, so seems reasonable) please use standard terms. This ties to the question: what is the menaing of this table at non-ingress LSRs? It clearly could have value everywhere=20 except the egress. 63) mplsTunnelCHopTable table is optional. Furthermore, since the information in this table is actually provided by routing protocol after the path has been computed, the entries in this table are provided only for observation, and hence, all variables in this table are accessible exclusively as read-only." I think this could be reworded. Furthermore, since the information in this table describes the path computed by the CSPF engine the entries in this table are read-only." 64) mplsTunnelCHopEntry "An entry in this table represents a tunnel hop. An entry in this table is created by a constraint- based routing protocol based on the hops specified in the corresponding mplsTunnelHopTable." Hmmm. A new and wonderful use for a routing protocol! Reword... "An entry in this table represents a tunnel hop. An entry in this table is created by a path computation engine using CSPF techniques applied to the=20 information collected routing protocols and the hops specified in the corresponding mplsTunnelHopTable." 65) mplsTunnelPerfTable < "This table provides per-tunnel MPLS performance < information." > "This table provides per-tunnel instance MPLS=20 > performance information." 66) mplsTunnelPerfTable Should we not also measure the signaling protocol? 67) mplsTunnelPerfTable What about packets dropped because of local resource constraints? Such packets are received successfully and are not packets with errors, but may be discarded through queuing precidence or whatever. 68) mplsTunnelCRLDPResMeanBurstSize Isn't this a duplicate of mplsTunnelResourceMeanBurstSize which is not specifc to CR-LDP? 69) mplsTunnelCRLDPResEntry Please state rules to prevent one of these entries being orphaned. 70) mplsTunnelCRLDPResRowStatus and mplsTunnelCRLDPResStorageType Why not inherrit from mplsTunnelResourceEntry? 71) mplsTunnelDown mplsTunnelRowStatus is needed too since it may explain why operStatus has gone down even though adminStatus is up. 72) mplsTunnelRerouted "This notification is generated when a tunnel is rerouted. If the actual path is used, then this tunnel's entry MAY contain the new path for this tunnel some time after this trap is issued by the agent." What is meant by "If the actual path is used"? Are you=20 saying... "This notification is generated when a tunnel is rerouted. If the mplsTunnelARHopTable is used,=20 then this tunnel instance's entry in the=20 mplsTunnelARHopTable will contain the new path=20 for this tunnel some time after this trap is issued by the agent." 73) mplsTunnelReoptimized ditto 74) Section 12 First bullet mplsTunnelARHopTable and mplsTunnelCHopTable are read-only and so should not appear at this point. 75) Section 16 It is no longer 2001 (although it may still feel like it :-) ------=_NextPart_000_04C9_01C33CAC.98ED35F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As promised, here is the continuation = of my=20 review of this draft.
 
This concludes my comments. I'm = afraid I don't=20 have the stamina to
work on the conformance = statement.
 
Adrian
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
24) mplsTunnelResourcePointer=20 Description
 
This refers to "segment" twice. But = we are not=20 dealing
in segments in this MIB table. We are = dealing in=20
tunnel instances (or if you must,=20 LSPs).
 
25) = mplsTunnelPrimaryInstance
 
It is very unclear what you mean in = this case by=20
"primary". I think the description = needs to be=20 enhanced.
 
For example, do you mean the tunnel = instance that=20 is
actually established and active at = the moment?=20 No, it
can't be that because in=20 mplsTunnelInstancePriority
allows two instances to be active at=20 once.
 
Does it mean "preferred"? Wouldn't = that be=20 covered
by the instance with the highest=20 priority?
 
Perhaps it means the instance that = carries the=20 full
configuration? No this is the = definition of the=20 row
with tunnel instance = zero.
 
26) mplsTunnelTable
 
Given that I have a tunnel with many = instances=20 defined,
how do I find which instance(s) are = currently=20 active?
Do I have to read each of them and = collect the=20 ones
with operStatus up?
 
27) = mplsTunnelInstancePriority
 
        "This=20 value indicates which priority, in=20 descending
          = order, with=20 0 indicating the lowest=20 priority,
          = within a=20 group of tunnel instances. A group=20 of
<         tunnel = instances is=20 defined as a set of=20 tunnels
>         tunnel = instances=20 is defined as a set of=20 LSPs
          with the = same=20 mplsTunnelIndex in this table,=20 but
<         with a = different=20 mplsTunnelInstance. Tunnel=20 group
>         with a = different=20 mplsTunnelInstance.=20 Tunnel instance
        &= nbsp;=20 priorities are used to denote the priority at which
28) mplsTunnelRole (out of order, sorry)
 
  =20 SYNTAX        INTEGER { head(1), = transit(2),=20 tail(3) }
 
I believe you need BITS not INTEGER = since a=20 tunnel may
be set up between interfaces on a = single LSR=20 making it
both ingress and egress. You could = alternatively=20 add:
 
   = head_tail(4)
 
but I think that is less = useful.
 
29) = mplsTunnelExcludeAllAfinity
 
As Ed says, this should read "Any". = Also in the=20 description.
 
30) = mplsTunnelPrimaryUpTime
 
This description is = inadequate.
What is meant be = "active"?
See point 25) for questions about = what a primary=20 instance is.
Is this value present in the row for = every=20 instance that is
not a primary instance? If so, = why?
 
31) = mplsTunnelPathChanges
 
<      =20 "Specifies the number of times the paths has changed
>       "Specifies the number = of times=20 the path has=20 changed
          = for=20 this tunnel since its creation."
32) mplsTunnelPathChanges and=20 mplsTunnelLastPathChange
 
Do you mean "for this tunnel = instance" or are you=20 trying
to capture the case where a tunnel = has changed=20 path by
any means including a change of=20 instance?
 
What do you mean by "path change"? = Hop, CHop or=20 ARHop?
 
33) = mplsTunnelCreationTime
 
Please be more specific. What does = "came into=20 existence" mean?
 
34) = mplsTunnelStateTransisitions
 
Please say which "state" you are = refering=20 to.
 
35) mplsTunnelOperStatus (and = probably all=20 operStatus objects)
 
At the MIB Meeting (TM) we took an = action that=20 "unknown"
would always have value (1) unless there was good reason = in
which case it must be stated in the = MIB=20 modules.
 
36)=20 mplsTunnelRowStatus
 
        "This=20 variable is used to create, modify,=20 and/or
<         delete a = row in=20 this tabole.  When a row in=20 this
>         delete a = row in=20 this table. 
 
37)=20 mplsTunnelRowStatus
 
           = When a row=20 in this
          table = is in=20 active(1) state, no objects in that=20 row
          can be = modified=20 except mplsTunnelRowStatus=20 and
         =20 mplsTunnelStorageType."
Can be modified by whom/what? = Presumably a=20 dynamic signaling
protocol could modifiy this table = regardless of=20 the rowStatus.
 
Can a user not change the adminStatus = when=20 rowStatus is
active?
 
38) mplsTunnelStorageType (and all = similar=20 fields).
 
The text here is = confusing.
 
        "This=20 variable indicates the storage type for=20 this
          = object.  If=20 this variable is set to=20 readOnly(5),
          = and the=20 corresponding entry is removed, then=20 the
          agent must = remove=20 this row shortly=20 thereafter
         =20 [RFC2579].
What is the difference between an = "entry" and a=20 "row"?
Where you say "entry", do you mean = "the managed=20 object
represented by this entry in the=20 table"?
 
       =20 Setting this object to permanent(4) indicates=20 that
          this = object=20 should be restored automatically=20 after
         =20 failures.
 
What do you mean by "this = object"?
Do you mean the "managed object = represented by=20 this entry
in the table"?
 
39) = mplsTunnelHopListIndexNext
 
Shouldn't the syntax be=20 MplsPathIndexOrZero?
 
40) All IndexNext = objects
 
I recall an email discussion with = Bert about how=20 these
objects should=20 be managed and described. The concern is
with producing unnecessary lacunae in the table.
 
I think the position "agreed" upon = was to cut=20 over to
using the IndexInteger=20 and IndexIntegerNextFree TCs
from RFC3289.
 
41) mplsTunnelHopTable
 
Please explicitly state the meaning = of this table=20 for
LSRs that are not the ingress of the = tunnel=20 instance.
 
This text should also be placed in = the=20 description of
mplsTunnelHopTableIndex.
 
41) mplsTunnelHopTable
 
        "The=20 mplsTunnelHopTable is used to indicate the=20 hops,
<         strict or = loose,=20 for an MPLS tunnel defined=20 in
<        =20 mplsTunnelTable,
>         strict or = loose, for=20 an instance of an MPLS tunnel
>         defined=20 in mplsTunnelTable,
 
42)=20 mplsTunnelHopTable
 
          &nbs= p;            = ;   =20 when it is established=20 via
          = signalling, for=20 the outgoing direction of=20 the
         =20 tunnel.  
 
What does this mean?
i)  Why is it limited to = signaling? This is=20 a convenient
    place to record = the path of a=20 manula tunnel instance
    if it is = known.
ii) Are you trying to say that the = only hops=20 present are
    the downstream = hops? Thus in=20 RSVP-TE terms, at
    transit LSRs, = this matches the received ERO. If = so,
    please say = so.
 
43)=20 mplsTunnelHopTable
 
           &n= bsp;           &nb= sp;           &nbs= p;            = ;   =20   The
          = first row=20 in the table is the first hop after=20 the
          = origination point=20 of the tunnel.  
 
In which case your example in section 9 is broken.
 
44) mplsTunnelHopAddressType
 
         =20 mplsTunnelHopAddrUnnum should be referred to.=20 If
          the object = is set=20 to lspid(5), then all but=20 the
          = mplsTunnelHopLspId=20 should be referred to. Note=20 that
          lspid(5) = is a=20 valid option only for=20 tunnels
          = signaled via=20 CRLDP"
What do you mean by "all but the mplsTunnelHopLspId should
be referred to"?
 
45) mplsTunnelHopAddress
 
I am confused by this object and the associated textual
convention.
 
i)  Why are 32 octets required to carry a hop address?
ii) Is there not already a standard TC for carrying IP
     addresses?
iii) If you are going to use = a=20 "free-form" octet string
     (not my favorite) then why is it necessary = to=20
     have a separate object and TC for AS = number?
 
46) = mplsTunnelHopAddrUnnum
 
If this only holds the interface id, = where is the=20
router id?
 
47) mplsTunnelHopType and=20 mplsTunnelHopInclude
 
I believe you should combine these = since=20 strict/loose
has no meaning for = exclusion.
 
This gives...
 
mplsTunnelHopType = OBJECT-TYPE
  =20 SYNTAX        INTEGER=20 {
           &n= bsp;         =20 strict(1),
          = ;           =20 loose(2),
          &nbs= p;           exclu= de(3)
          &nbs= p;         =20 }
   MAX-ACCESS    = read-create
  =20 STATUS        current
   = DESCRIPTION
        "Denotes = whether this=20 tunnel hop is routed in=20 a
          strict or = loose=20 fashion, or is to be excluded
          from the = computed=20 and actual paths."
   ::=3D { mplsTunnelHopEntry 10 = }
 
48) = mplsTunnelHopPathOptionName
 
Must this be present for every hop = with the=20 same
mplsTunnelHopListIndex and=20 mplsTunnelHopPathOptionIndex?
 
If so, must it be = identical?
 
49) = mplsTunnelHopEntryPathComp
 
So many questions!
 
i)   This is not a per hop = piece of=20 information. This
     and point = 48) suggest=20 that you need a PathOption
     = table.
ii)  How is this useful? It = seems you are=20 mixing two
     issues. a) = the need to=20 control whether CSPF or
     simple = next-hop routing=20 should be invoked at the
     ingress, b) = whether the=20 user is allowed to
     specify = other than the=20 ingress and egress
     = addresses.
iii) Note that the user cannot = specify the=20 ingress
     since the = source is not=20 in the hop table!
 
50) = mplsTunnelHopRowStatus
 
"tabole"
 
51) = mplsTunnelResourceTable
 
An old chestnut, this = one...
 
Does this table hold the requested = values or the=20 actual
values? In other words, what effect = does=20 Admisssion
Control and Resv have on the objects = in this=20 table?
 
What does the table betoken at = non-ingress nodes?=20 The
values received on the setup=20 request?
 
When you say the values are copied = into LSR MIB=20 module
objects, are you implying that the = two objects=20 always
contain the same values?
 
52) mplsTunnelResourceExBurstSize, =
    = mplsTunnelResourceFrequency=20 and
   =20 mplsTunnelResourceWeight
 
These seem to be duplicated = by...
   =  mplsTunnelCRLDPResExBurstSize,=20
    = mplsTunnelCRLDPResFrequency=20 and
   =20 mplsTunnelCRLDPResWeight
 
Must I use both?
 
53) mplsTunnelResourceRowStatus
 
"tabole"
 
54) mplsTunnelARHopTable
 
Need a description of the menaing of this table at
non-ingress nodes.
 
The question is whether this reflects the RRO from
the Resv, or the splice of the RRO from the Path
and the Resv.
55) mplsTunnelARHopTable
 
        "The = mplsTunnelARHopTable is=20 used to indicate = the
         =20 hops, strict or loose, for an MPLS tunnel defined
How can there be a loose hop in the ARHopTable? Fortunately
you don't have an object for this.
 
56) mplsTunnelARHopTable
 
         Please note that = since the=20 information necessary = to
<        =20 build entries within this table are not provided=20 by
>         build entries = within=20 this table is not provided by
56) mplsTunnelARHopTable
 
I believe it is important to add a note to point out that the
contents of this table may change while you are walking it.
This may lead to the NMS perceiving a path which appears to
include loops.
 
You should mention that the mplsTunnelLastPathChange object
can be used to verify that the AR read is valid.
 
57) mplsTunnelARHopEntry
 
        "An entry in this table=20 represents a tunnel hop. =20 An
          entry is = created by=20 a network administrator=20 for
          signaled = ERLSP set=20 up by an MPLS=20 signalling
         =20 protocol."
Huh? Surely it is created by the signaling protocol.
 
58) mplsTunnelARHopAddrUnnum (and all unnum addresses)
 
I just noticed the TC for this is an OctetString.
Why? What is wrong with putting 32 bit values in 32 bit
objects?
 
59) mplsTunnelARHopIpPrefixLen
 
How would this ever be other than a full prefix?
In other words, this object is redundant.
 
60) mplsTunnelARHopAsNumber
 
How do you expect this to be present in the AR?
There is no way to signal it.
 
61) mplsTunnelARHopTable
 
What about labels and local protection flags (both in
the RRO in RFC3209)? Are we defering these only to the
GMPLS MIB?
 
62) mplsTunnelCHopTable
 
        "The mplsTunnelCHopTable = is used=20 to indicate = the
          hops,=20 strict or loose, for an MPLS tunnel=20 defined
          in=20 mplsTunnelTable, as computed by a=20 constraint-
          = based=20 routing protocol, based on=20 the
          = mplsTunnelHopTable=20 for the outgoing direction=20 of
          the = tunnel. =20 Each row in this table is indexed by
What do you mean by the "outgoing direction of the tunnel"?
Are you trying to say that this table only holds information
for LSRs downstream of this LSR (which would make it
behave as the mplsTunnelHopTable, so seems reasonable) please
use standard terms.
 
This ties to the question: what is the menaing of this table
at non-ingress LSRs? It clearly could have value everywhere
except the egress.
 
63) mplsTunnelCHopTable
 
          table is = optional.=20 Furthermore, since = the
         =20 information in this table is actually provided=20 by
          routing = protocol=20 after the path has been=20 computed,
          the = entries=20 in this table are provided only=20 for
          = observation, and=20 hence, all variables in this=20 table
          are = accessible=20 exclusively as read-only."
I think this could be reworded.
 
          Furtherm= ore,=20 since the information in this table
          describes = the path=20 computed by the CSPF engine
          the entries = in this=20 table are read-only."
64) mplsTunnelCHopEntry
 
        "An entry in this table=20 represents a tunnel hop. =20 An
          entry in = this table=20 is created by a=20 constraint-
          = based=20 routing protocol based on the hops=20 specified
          in = the=20 corresponding mplsTunnelHopTable."
Hmmm. A new and wonderful use for a = routing=20 protocol!
Reword...
 
        "An=20 entry in this table represents a tunnel hop. =20 An
          entry in = this table=20 is created by a path computation
          engine = using CSPF=20 techniques applied to the
          = information=20 collected routing = protocols and the=20 hops
        =20  specified in the corresponding = mplsTunnelHopTable."
 
65) mplsTunnelPerfTable
 
<       "This=20 table provides per-tunnel MPLS=20 performance
<        =20 information."
>       "This table = provides=20 per-tunnel instance MPLS
>        =20 performance information."
66) mplsTunnelPerfTable
 
Should we not also measure the = signaling=20 protocol?
 
67) mplsTunnelPerfTable
 
What about packets dropped because of = local=20 resource
constraints? Such packets are = received=20 successfully and are
not packets with errors, but may be = discarded=20 through queuing
precidence or whatever.
 
68) = mplsTunnelCRLDPResMeanBurstSize
 
Isn't this a duplicate of=20 mplsTunnelResourceMeanBurstSize
which is not=20 specifc to CR-LDP?
 
69) = mplsTunnelCRLDPResEntry
 
Please state rules to prevent one of = these=20 entries being
orphaned.
 
70) mplsTunnelCRLDPResRowStatus = and
  =20  mplsTunnelCRLDPResStorageType
 
Why not inherrit from=20 mplsTunnelResourceEntry?
 
71) mplsTunnelDown
 
mplsTunnelRowStatus is needed too = since it may=20 explain why
operStatus has gone down even though = adminStatus=20 is up.
 
72) mplsTunnelRerouted
 
        "This=20 notification is generated when a tunnel=20 is
          rerouted. = If the=20 actual path is used, then=20 this
          tunnel's = entry=20 MAY contain the new path for=20 this
          tunnel = some time=20 after this trap is issued by=20 the
         =20 agent."
What is meant by "If the actual path = is used"?=20 Are you
saying...
 
        "This=20 notification is generated when a tunnel=20 is
          rerouted. = If the=20 mplsTunnelARHopTable is used,
          then=20 this tunnel instance's entry in the
         =20 mplsTunnelARHopTable will contain = the new path=20
          for=20 this tunnel some time after this trap is
          issu= ed by the=20 agent."
73) = mplsTunnelReoptimized
 
ditto
 
74) Section 12   First bullet
 
mplsTunnelARHopTable and mplsTunnelCHopTable are read-only
and so should not appear at this point.
 
75) Section 16
 
It is no longer 2001 (although it may still feel like it :-)
 
 

------=_NextPart_000_04C9_01C33CAC.98ED35F0-- From owner-mpls@UU.NET Sat Jun 28 18:52:23 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05718 for ; Sat, 28 Jun 2003 18:51:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouwl19980 for ; Fri, 27 Jun 2003 09:56:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouwl19880; Fri, 27 Jun 2003 09:56:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQouwj18992 for mpls-outgoing; Fri, 27 Jun 2003 09:27:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQouwj18987 for ; Fri, 27 Jun 2003 09:27:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQouwj00541 for ; Fri, 27 Jun 2003 09:27:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouwj11161 for ; Fri, 27 Jun 2003 09:27:01 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQouwj11143 for ; Fri, 27 Jun 2003 09:27:00 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 27 Jun 2003 10:26:46 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802628484@baker.datcon.co.uk> From: Edward Harrison To: MPLS WG Cc: Cisco - Thomas Nadeau , Cheenu Srinivasan , "'Arun Viswanathan'" Subject: RE: WG last call on the FTN mib module and the TE mib module Date: Fri, 27 Jun 2003 10:24:54 +0100 Deferred-Delivery: Fri, 27 Jun 2003 10:25:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, One thing I immediately notice in draft-ietf-mpls-te-mib-10.txt is that the mplsTunnelEntry still includes an mplsTunnelExcludeAllAffinity object as opposed to an mplsTunnelExcludeAnyAffinity (which is what is used in RFC 3209). Each time I've raised this in the past it has been agreed (by Tom at the very least) that the object should be "Exclude-any", but the mark-up keeps getting lost by the time the next version appears. Any chance of fixing it before the draft goes to RFC? Regards, Ed -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: 25 June 2003 00:28 To: MPLS WG Cc: George Swallow; Bert Wijnen; Alex Zinin Subject: WG last call on the FTN mib module and the TE mib module All, this mail starts a working group last call on Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base This ID has just been sent to the Internet-Drafts for publication and will show up shortly, in the mean time it will be found at: http://urax.utfors.net/~loa/draft-ietf-mpls-te-mib-10.txt This mail also the starts a working group last call on Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base draft-ietf-mpls-ftn-mib-07.txt for this mib module the wg last call is limited to the changes since the previous version version This ID has just been sent to the Internet-Drafts for publication and will show up shortly, in the mean time it will be found at: http://urax.utfors.net/~loa/draft-ietf-mpls-ftn-mib-07.txt The last call will en June 29th 09.00 ET. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Sun Jun 29 02:26:23 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23327 for ; Sun, 29 Jun 2003 02:25:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovaj05971 for ; Sat, 28 Jun 2003 11:19:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovaj05863; Sat, 28 Jun 2003 11:19:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQouzu29753 for mpls-outgoing; Sat, 28 Jun 2003 07:31:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQouzu29746 for ; Sat, 28 Jun 2003 07:31:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQouzu07345 for ; Sat, 28 Jun 2003 07:30:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouzu10194 for ; Sat, 28 Jun 2003 07:30:38 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bay8-f19.bay8.hotmail.com [64.4.27.19]) id QQouzu10184 for ; Sat, 28 Jun 2003 07:30:38 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 28 Jun 2003 00:30:37 -0700 Received: from 57.250.229.136 by by8fd.bay8.hotmail.msn.com with HTTP; Sat, 28 Jun 2003 07:30:37 GMT X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] From: "M. ELK" To: arun@umbc.edu, mpls@UU.NET Cc: arun@gl.umbc.edu Subject: Re: WG last call on the FTN mib module and the TE mib module Date: Sat, 28 Jun 2003 07:30:37 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2003 07:30:37.0918 (UTC) FILETIME=[2B8D9FE0:01C33D47] Sender: owner-mpls@UU.NET Precedence: bulk Arun Reg mplsTunnelDescr Quote >mplsTunnelDescr >Since this attribute cannot be signaled, please add a note to explain that >the value of this object at transit and egress nodes will be automatically >generated (or blank) according to the implementation and may not match the >value at the ingress. Unquote As an option , why not using "session Name" which is part of session attribute object . this way the mplsTunnelDscr have a common value across all LSR (Set by Headend and reflected at the transit and egress LSR ) . Brgds >From: Arun Satyanarayana >Reply-To: arun@umbc.edu >To: mpls@UU.NET >CC: Arun Satyanarayana >Subject: Re: WG last call on the FTN mib module and the TE mib module >Date: Thu, 26 Jun 2003 17:12:48 -0400 (EDT) > > >Hi Tom and co., > >Regarding draft-ietf-mpls-te-mib-10.txt, please make some clarifications >on how the configured parameters map to signalling: > >mplsTunnelIndex >Please add to the description to say how this maps to signaled objects. >Something like... >"For tunnel LSPs signaled using RSVP-TE, this value should correspond to >the Tunnel Id used for the RSVP-TE session." > >mplsTunnelInstance >Description says... >"For tunnel LSPs signaled using RSVP, this value should correspond to the >RSVP source port used for the RSVP-TE session." >There is no such field in RFC3209. Please change to say... >"For tunnel LSPs signaled using RSVP-TE, this value should correspond to >the LSP-ID used for the RSVP-TE sender." > >mplsTunnelIngressLSRId >Surely this should be the source of the tunnel not the extended tunnel id. >The description starts off right but goes wrong when it says... >"When the MPLS signalling protocol is rsvp(2) this value SHOULD mimic the >Extended Tunnel Id field in the SESSION object." >Please change this to say... >"When the MPLS signalling protocol is rsvp(2) this value should correspond > to the Tunnel Sender Address in Sender Template." > >mplsTunnelIngressLSRId and mplsTunnelEgressLSRId >Why is there no support for IPv6 source and destinations? > >mplsTunnelDescr >Since this attribute cannot be signaled, please add a note to explain that >the value of this object at transit and egress nodes will be automatically >generated (or blank) according to the implementation and may not match the >value at the ingress. > >mplsTunnelSessionAttributes >It would be helpful if these bits more closely matched the signaled >Session Attribute flags from RFC3209 and so on. It is also helpful to have >flags for triggering separate qualities of the tunnel. So... fastReroute >(0) is useful but should be split into fastRerouteNodeProt and >fastRerouteBWProt. recordRoute(4) is useful but we also need >recordRouteLabels. Please state how each flag maps to a flag in the >Session Attribute object. > >Thanks, >_arun_ >============================================================ >From: "Loa Andersson" >To: "MPLS WG" >Cc: "George Swallow" ; "Bert Wijnen" >; >"Alex Zinin" >Sent: Tuesday, June 24, 2003 7:28 PM >Subject: WG last call on the FTN mib module and the TE mib module > > > > All, > > > > this mail starts a working group last call on > > > > Multiprotocol Label Switching (MPLS) Traffic Engineering > > Management Information Base > > > > > > > > This ID has just been sent to the Internet-Drafts for publication and > > will show up shortly, in the mean time it will be found at: > > > > http://urax.utfors.net/~loa/draft-ietf-mpls-te-mib-10.txt > > > > This mail also the starts a working group last call on > > > > Multiprotocol Label Switching (MPLS) Forwarding Equivalence > > Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) > > Management Information Base > > > > draft-ietf-mpls-ftn-mib-07.txt > > > > for this mib module the wg last call is limited to the changes since the > > previous version version > > > > This ID has just been sent to the Internet-Drafts for publication and > > will show up shortly, in the mean time it will be found at: > > > > http://urax.utfors.net/~loa/draft-ietf-mpls-ftn-mib-07.txt > > > > The last call will en June 29th 09.00 ET. > > > > -- > > /Loa > > > > mobile + 46 739 81 21 64 > > email: loa@pi.se > _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From owner-mpls@UU.NET Sun Jun 29 08:13:40 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27097 for ; Sun, 29 Jun 2003 08:13:24 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouzm22168 for ; Sat, 28 Jun 2003 05:35:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQouzm21900; Sat, 28 Jun 2003 05:35:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQouxz20775 for mpls-outgoing; Fri, 27 Jun 2003 19:53:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQouxz20743 for ; Fri, 27 Jun 2003 19:52:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQouxz01581 for ; Fri, 27 Jun 2003 19:52:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQouxz06131 for ; Fri, 27 Jun 2003 19:52:12 GMT Received: from lxmail.xebeo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: gwnj8.utstar.com [65.200.123.8]) id QQouxz06120 for ; Fri, 27 Jun 2003 19:52:12 GMT Received: (qmail 23484 invoked from network); 27 Jun 2003 19:52:11 -0000 Received: from unknown (HELO utstar.com) (172.16.36.114) by lxmail.xebeo.com with SMTP; 27 Jun 2003 19:52:11 -0000 Message-ID: <3EFCA039.3030006@utstar.com> Date: Fri, 27 Jun 2003 15:51:21 -0400 From: Juan Romo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@UU.NET Subject: test Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit test From owner-mpls@UU.NET Sun Jun 29 12:02:17 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01049 for ; Sun, 29 Jun 2003 12:00:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovbt27514 for ; Sat, 28 Jun 2003 20:28:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovbt27245; Sat, 28 Jun 2003 20:28:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQovbr10468 for mpls-outgoing; Sat, 28 Jun 2003 19:49:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovbr10459 for ; Sat, 28 Jun 2003 19:49:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovbr17521 for ; Sat, 28 Jun 2003 19:48:55 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovbr00551 for ; Sat, 28 Jun 2003 19:48:54 GMT Received: from barry.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: barry.mail.mindspring.net [207.69.200.25]) id QQovbr00545 for ; Sat, 28 Jun 2003 19:48:53 GMT Received: from dialup-67.75.27.8.dial1.boston1.level3.net ([67.75.27.8] helo=jluciani-laptop) by barry.mail.mindspring.net with smtp (Exim 3.33 #1) id 19WLgf-0006qq-00; Sat, 28 Jun 2003 15:48:41 -0400 Message-Id: <3.0.1.32.20030628154550.01878088@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 28 Jun 2003 15:45:50 -0400 To: ewgray@GraIyMage.com, tnadeau@cisco.com Subject: Re: WG last call on LSR and LDP MIB modules - setting dates Cc: "'Ash, Gerald R (Jerry), ALABS'" , "'Wijnen, Bert (Bert)'" , "'Loa Andersson'" , "'MPLS WG'" , ppvpn@nortelnetworks.com, ewgray@GraIyMage.com In-Reply-To: <3EF348C8.46EF6EBB@GraIyMage.com> References: <02f301c33691$5ba16ed0$ed472ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, At 01:47 PM 6/20/03 -0400, Eric Gray wrote: >Tom and others, > > This discussion seems skewed a bit because of different perspectives that people >are speaking from. > > First of all, it is not the case that a protocol specification must necessarily define >counters and knobs for every detail of how the protocol should be managed. It is >often the case that people would prefer this to be the case, however, requiring it to >be the case would be a sure fire way to delay specification of protocol standards >well beyond some window of utility for a standard - meaning that placing too many >barriers in the way of defining standards leads to de facto standards. I would have to agree with this sentiment. One aspect of the LDP Specification was the use of TLVs. Using TLVs and defining them so clearly, made writing the LDP-MIB straightforward. Many of the objects come directly from the TLVs. Also, this approach allows the protocol to be extensible which is also good. As new TLVs are added, so to can new MIB Module(s). > > For example, in this discussion, what exactly is it that LDP _should_ have defined >to support the requirements that Jerry points out? I do not think that the protocol >should be involved in the business of keeping track of the enabled status of potential >protocol peers - it should be sufficient from a protocol perspective to know whether a >protocol peer is currently visible. And this is reflected in the mplsLdpPeerTable of the LDP-MIB. Additionally, an NMS (SNMP Manager) can display an LPD Session-based topology by querying each Agent/LSR and then each Peer to build up such a topology. > > Also, the protocol specification should not specify what happens to protocol >management data (counters and knobs) during the period in which the protocol >itself is not active - except to the extent that proper protocol behavior absolutely >depends on such specification. > > My sense is that it is perfectly within the purview of a management specification >to make statements about this kind of behavior as long as such statements are not >actually incompatible with underlying protocol specifications. It would then be up >to implementers to determine whether or not their implementation supports these >capabilities. Agreed. > > And it is equally reasonable to assert that specifying required behaviors may >be the task of some subsequent management specification. In the same way that >requiring full manageability of a protocol can unnecessarily delay the protocol >specification process, requiring complete satisfaction of evolving management >requirements in current management specifications can unnecessarily delay the >management specification process. Very astute statements above. In point of fact, the LDP-MIB's one and only goal is to support the LDP Specification. 4 years, and 4 MIB Modules later (not to mention draft-ietf-mpls-tc-mib-07.txt) and several MIB doctor reviews and 3 working group last calls later, I believe that it does this. Adding additional requirements would indeed delay this MIB, or worse, cause it to be put in the dustbin. MIBs, by their nature, are added to in the form of MIB Modules, and that can certainly be done with additional requirements. -Joan > > My 2 cents worth... > >-- >Eric Gray > >"Thomas D. Nadeau" wrote: > >> >> > Tom, >> > >> > > the MIBs need to be wrapped up ASAP and ... >> > > we are well on this track. >> > >> > Good, hopefully by IETF-57, in order to avoid 'sending them >> > to the dust-bin' as Bert has suggested. >> > >> > > To address your statement about requirements, >> > > as discussed previously offline with yourself >> > > and the MIB co-authors, >> > >> > There is about a one-year history/archive of posts to the >> > lists regarding these requirements. >> > >> > > many of the requirements you listed below require >> > > changes to the LDP protocol itself. >> > >> > Which of the 3 LDP requirements constitute 'many' that need >> > LDP changes? >> >> All of the requirements you listed below with >> the exception of the ones pertaining to VPN. >> >> > Obviously we're not proposing LDP protocol changes. Also, >> > the requirements I-D does not propose specific MIB >> > extensions, *in order to avoid past discussions of why >> > specific extensions won't work*. Step-1 is to make sure the >> > requirements are understood, and then step-2 is to decide how >> > to meet them. >> >> Of course you aren't proposing specific changes to >> anything. What we are saying is that is what you need to >> do in order to accomplish what you want in this case. The >> LDP MIB is not a place for redefining how LDP works. >> >> > Joan has suggested (I believe for requirements R1 and R2) 'a >> > MIB which stores LDP counter information in a history table'. >> > That's a step-2 in the right direction. Furthermore, Adrian >> > has suggested that 'instances of entities' is a concept that >> > has been handled in MIBs before and could be added in an >> > optional way so that implementations did not have to maintain >> > persistent information, but can choose to. >> >> This is not something that should go into the existing >> LDP MIB because the LDP protocol does not support the >> counters/concepts required to count these things regardless >> of what has been suggested. If you look at the specific details >> of what is being proposed in the draft (which I and others have >> done numerous times now) they CANNOT be achieved with >> the current standard LDP. >> >> > As to R3, it should be clear, a MIB should be straightforward. >> > >> > > I suggest that you consult with >> > > other SPs in the WG on these requirements to make sure >> > > that they are consistent. I personally have not been hearing >> > > any of these requirements from other SPs that participate >> > > in the MPLS WG. >> > >> > So that signifies the death-knell pronouncement from the >> > self-appointed OAM/MIB-czar? Perhaps the famous 25 pro-VCCV >> > SPs you often quote (but who never speak for themselves) can >> > attest to the MPLS-MIBs perfection/no-more-requirements-needed? >> > >> > There has been no opposition to the requirements R1-R5 we've >> > been stating for a long time (except, consistently, from you). >> >> I have not read any emails that claimed support for >> or acknowledged these requirements either. >> >> > > I suggest that you direct your requirements to the >> > > authors of the LDP specifications and propose >> > > extensions/additions there first because the MIBs >> > > cannot manage what the protocols will not provide. >> > >> > We're not proposing any changes to LDP. As above, Joan is >> > suggesting approaches to R1 & R2. R3 clearly requires no >> > protocol changes. >> >> So then go ahead and propose a MIB based on those >> changes. There is nothing preventing you or anyone else >> on the co-author list of the draft in question from doing >> this. >> >> > > The remaining requirements you listed >> > > below apply specifically to the PPVPN-MPLS-VPN MIB and not >> > > to the base MPLS MIBs which are in WG last call presently. >> > >> > R3 and R4 need to be addressed, have been there a long time, >> > and do not have to wait until last call to be discussed/progressed. >> >> And these will be addressed in the PPVPN MPLS VPN MIB >> when Harmen and I get around to editing the MIB, assuming there >> is consensus to make these additions. And as you can see, I >> have been a little busy with the base MIBs for the last >> few months. *) >> >> --Apparently self-appointed OAM/MIB-czar >> >> >> > Jerry >> > >> > > -----Original Message----- >> > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> > > Sent: Wednesday, June 18, 2003 1:43 PM >> > > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG >> > > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; >> > > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com >> > > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates >> > > >> > > >> > > Bert, Loa, All, >> > > >> > > I'd like to follow up on Wai Sum's comments below, and >> > > encourage that high-priority MPLS-MIB problems/requirements >> > > identified through extensive testing be addressed in the MPLS >> > > MIB modules. >> > > >> > > The MPLS MIB problems/requirements are identified in >> > > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, >> > > and are critical operator requirements stemming from >> > > detailed lab testing by Li Chung and others at AT&T. >> > > MPLS-VPNs aren't going to operate as well as needed until and >> > > unless these requirements are met. It is expected that >> > > operators wishing to use the same MPLS MIBs would have >> > > similar concerns. >> > > >> > > The I-D does not propose specific MIB extensions based on the >> > > requirements. Rather, such extensions are left to the MIB >> > > designers, in order to avoid past discussions of why specific >> > > extensions won't work. But so far there is no help or >> > > response from MIB designers on how to meet the requirements, >> > > even though the problems have been identified on email lists >> > > for more than one year. >> > > >> > > Here is a summary of requirements (R1,R2,R3 LDP related; >> > > R4,R5 VPN related): >> > > >> > > R1. It is required to capture the signaling usage/performance >> > > of the LDP Entities, as well as the traffic usage/performance >> > > of the LDP Sessions. R2. It is required to ensure persistency >> > > of information in the LDP-MIB Entity Table and Entity >> > > Statistics Table, whenever an LDP Entity is disabled and then >> > > re-enabled. R3. It is required that a count be reported of >> > > mplsNumVrfRouteMaxThreshExceeded notification when the >> > > operator-defined VRF maximum route threshold is exceeded. R4. >> > > It is required to have an explicit mapping between VRF, RD, >> > > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is >> > > required to track the number of BGP prefixes on the PE-CE >> > > link, and that the BGP neighbor maximum-prefix limit on the >> > > PE-CE link be used to limit the number of eBGP routes >> > > injected in the VRF. >> > > >> > > I agree with Harmen Van der Linde, "We need to get this MPLS >> > > MIB module, together with the MPLS LDP and MPLS VPN modules, >> > > standardized ASAP. There is a critical need for these MPLS >> > > MIB modules for management of MPLS-enabled networks, which >> > > are currently being deployed by many service providers." >> > > >> > > Bert threatened at IETF-56 to start over on MPLS MIBs if not >> > > finished by IETF-57. >> > > >> > > We need the MPLS MIB designers to meet critical requirements >> > > and complete ASAP. >> > > >> > > Thanks, >> > > Jerry >> > > > > From owner-mpls@UU.NET Sun Jun 29 20:22:27 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11503 for ; Sun, 29 Jun 2003 20:21:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovgb01689 for ; Mon, 30 Jun 2003 00:21:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovgb01388; Mon, 30 Jun 2003 00:20:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQovfk09130 for mpls-outgoing; Sun, 29 Jun 2003 20:01:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovfk09125 for ; Sun, 29 Jun 2003 20:01:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQovfk15006 for ; Sun, 29 Jun 2003 20:01:53 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovfk14827 for ; Sun, 29 Jun 2003 20:01:52 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovfk14803 for ; Sun, 29 Jun 2003 20:01:51 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5TK1mg5015570 for ; Sun, 29 Jun 2003 16:01:48 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAH47319; Sun, 29 Jun 2003 16:01:46 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5TK1kx17231 for mpls@uu.net; Sun, 29 Jun 2003 16:01:46 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovfk03310 for ; Sun, 29 Jun 2003 20:00:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQovfj29762 for ; Sun, 29 Jun 2003 19:58:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovfj08691 for ; Sun, 29 Jun 2003 19:58:14 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovfj08668 for ; Sun, 29 Jun 2003 19:58:13 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5TJw5g7014114; Sun, 29 Jun 2003 15:58:08 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-2-26.cisco.com [10.86.242.26]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAH47268; Sun, 29 Jun 2003 15:58:04 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Loa Andersson'" , "'MPLS WG'" Cc: "'George Swallow'" , "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" Subject: RE: comment on the LDP MIB requirement Date: Sun, 29 Jun 2003 15:55:39 -0400 Organization: Cisco Systems Message-ID: <001001c33e78$a6b0ad20$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <9473683187ADC049A855ED2DA739ABCA011BEAA4@KCCLUST06EVS1.ugd.att.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Ash, Gerald R (Jerry), ALABS > Sent: Thursday, June 26, 2003 12:41 PM > To: Loa Andersson; MPLS WG > Cc: Ash, Gerald R (Jerry), ALABS; George Swallow; Lai, Wai S > (Waisum), ALABS; Chung, Li-Jin W, ALABS > Subject: RE: comment on the LDP MIB requirement > > > Loa, All, > > > I had to read back a bit to understand the impact of the input from > > Wai Sum and Jerry. The working group last call has ended > but I would > > nevertheless like to make this comment: > > > > - the draft-lai-mpls-mib-rqmts-00.txt includes requirements that > > will make changes to the LDP necessary > > Loa, I'm surprised that you would just parrot this claim > without technical backup. This is merely an unsubstantiated > assertion by 2 of the MPLS MIB authors, to deflect the > requirements in yet one more creative way. No response was > made to Eric Gray's post requesting specifics to back this up > http://cell.onecall.net/mhonarc/mpls/current/msg00130.html. > > Various posts over the past year have requested specific MPLS > MIB extensions to meet identified gaps (see below). When the > specifics were rejected, then a different approach was tried > to request designers to propose enhancements to meet > requirements > http://cell.onecall.net/mhonarc/mpls/2003-May/msg00006.html, > again without any forward motion. > > Despite all this effort to meet a few critical SP > requirements, no attempt has been made to address the > requirements or the specific MIB enhancement proposals: > > Li Chung initially posted specific enhancements/needs to the > MPLS list on June 27, 2002 > http://cell.onecall.net/mhonarc/mpls/2002-Jun/msg00159.html. > Go back and review the thread, the specific extensions were > not addressed. > > Wai Sum Lai initially posted to the ppvpn list on August 19, > 2002 (message attached below, ppvpn archives don't go back > that far). The specific extensions were not addressed, Tom > requested and got substantiation of the needs, but that was > the end of the discussion. > > > - the LDP MIB is based on the current LDP spec, thus it is my take > > that the draft is outside the scope of the current last call > > No changes to the LDP spec are proposed or needed. Therefore > the requirements and proposed extensions, made for one year > on the list, are well within the LDP MIB discussion window. > They merely haven't been seriously addressed. Jerry, Let me parrot the meeting minutes from the MIB doctor review meeting we had in Atlanta last Fall. The things proposed in the document in question were discussed at the MIB Doctor's meeting and it was decided and agreed upon at that time that we would not include any of the changes that Li presented (that now appear in this document) at that time. Instead, they were left for future study and/or inclusion in future I-Ds. We did in fact include one change that Li requested (that is not in the document in question), BTW. --Tom From owner-mpls@UU.NET Sun Jun 29 20:59:24 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12130 for ; Sun, 29 Jun 2003 20:59:24 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovdu07836 for ; Sun, 29 Jun 2003 09:38:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovdu07593; Sun, 29 Jun 2003 09:37:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQovcz08968 for mpls-outgoing; Sun, 29 Jun 2003 04:22:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovcz08963 for ; Sun, 29 Jun 2003 04:22:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovcz15610 for ; Sun, 29 Jun 2003 04:22:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovcz29566 for ; Sun, 29 Jun 2003 04:22:42 GMT Received: from mail1.avantel.net.mx by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.avantel.net.mx [200.33.213.72]) id QQovcz29549 for ; Sun, 29 Jun 2003 04:22:42 GMT Received: by mail1.avantel.net.mx (5.0.048) id 3D15C1590009012F for mpls@UU.NET; Sat, 28 Jun 2003 23:49:16 -0500 Message-ID: <3D15C15C00000342@mail1.avantel.net.mx> Date: Sat, 28 Jun 2003 23:47:16 -0500 In-Reply-To: <030201c33548$2cb85060$c622a70a@luhouqin> From: "Miguel Cruz" Subject: remove To: "MPLS WG" MIME-Version: 1.0 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: quoted-printable remove Miguel Cruz From owner-mpls@UU.NET Mon Jun 30 09:46:44 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23710 for ; Mon, 30 Jun 2003 09:46:42 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovhl02008 for ; Mon, 30 Jun 2003 09:26:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovhl28224; Mon, 30 Jun 2003 09:25:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQovgc21990 for mpls-outgoing; Mon, 30 Jun 2003 00:36:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovgc21983 for ; Mon, 30 Jun 2003 00:36:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovgc20936 for ; Mon, 30 Jun 2003 00:34:55 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovgc25668 for ; Mon, 30 Jun 2003 00:34:55 GMT Received: from hall.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hall.mail.mindspring.net [207.69.200.60]) id QQovgc25660 for ; Mon, 30 Jun 2003 00:34:55 GMT Received: from dialup-67.75.27.121.dial1.boston1.level3.net ([67.75.27.121] helo=jluciani-laptop) by hall.mail.mindspring.net with smtp (Exim 3.33 #1) id 19WmdC-00062v-00; Sun, 29 Jun 2003 20:34:54 -0400 Message-Id: <3.0.1.32.20030629203110.0075a850@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 29 Jun 2003 20:31:10 -0400 To: "Adrian Farrel" , "'mpls@uu.net'" Subject: Re: Nit in draft-ietf-mpls-tc-mib-07.txt In-Reply-To: <04b701c33cc3$2ee7d360$681810ac@movaz.com> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Adrian, Thank you for the typo. We just submitted draft-ietf-mpls-tc-mib-08.txt to fix this. (IT is the ONLY change from version 7). -Joan At 11:45 AM 6/27/03 -0400, Adrian Farrel wrote: >>>> CourierNo change in substance. Just a typo. CourierAdrian Courier TeHopAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a generic Tunnel hop address. Courier A TeHopAddress value is always interpreted within the context of an TeHopAddressType value. Every << usage of the TeHopInetAddress TEXTUAL-CONVENTION > usage of the TeHopAddress TEXTUAL-CONVENTION is required to specify the TeHopAddressType object which provides the context. It is suggested that <<<<<<<< From owner-mpls@UU.NET Mon Jun 30 16:00:35 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14054 for ; Mon, 30 Jun 2003 16:00:35 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjc21598 for ; Mon, 30 Jun 2003 20:00:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovjc21020; Mon, 30 Jun 2003 20:00:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQovhw18026 for mpls-outgoing; Mon, 30 Jun 2003 12:01:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovhw16920 for ; Mon, 30 Jun 2003 12:01:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovhw27958 for ; Mon, 30 Jun 2003 12:01:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovhw08893 for ; Mon, 30 Jun 2003 12:01:01 GMT Received: from sj-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-2.cisco.com [171.71.177.254]) id QQovhw08876 for ; Mon, 30 Jun 2003 12:01:00 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5UC0v2K003856 for ; Mon, 30 Jun 2003 05:00:58 -0700 (PDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAH64595; Mon, 30 Jun 2003 08:00:57 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5UC0vr24842 for mpls@uu.net; Mon, 30 Jun 2003 08:00:57 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQovhv10066 for ; Mon, 30 Jun 2003 11:59:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovhv04625 for ; Mon, 30 Jun 2003 11:58:24 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovhv03385 for ; Mon, 30 Jun 2003 11:58:23 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQovhv03191 for ; Mon, 30 Jun 2003 11:58:17 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12787; Mon, 30 Jun 2003 07:54:12 -0400 (EDT) Message-Id: <200306301154.HAA12787@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-te-mib-10.txt Date: Mon, 30 Jun 2003 07:53:21 -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 : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-te-mib-10.txt Pages : 71 Date : 2003-6-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-te-mib-10.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: <2003-6-27150736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150736.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jun 30 16:08:36 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14212 for ; Mon, 30 Jun 2003 16:08:36 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjc26993 for ; Mon, 30 Jun 2003 20:08:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovjc26678; Mon, 30 Jun 2003 20:08:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQovhv10011 for mpls-outgoing; Mon, 30 Jun 2003 11:57:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovhv09995 for ; Mon, 30 Jun 2003 11:57:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovhv28343 for ; Mon, 30 Jun 2003 11:55:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovhv28133 for ; Mon, 30 Jun 2003 11:55:41 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovhv28121 for ; Mon, 30 Jun 2003 11:55:41 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5UBtdg5015451 for ; Mon, 30 Jun 2003 07:55:39 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAH64420; Mon, 30 Jun 2003 07:55:37 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5UBtbV24684 for mpls@uu.net; Mon, 30 Jun 2003 07:55:37 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovhv09732 for ; Mon, 30 Jun 2003 11:54:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQovhv01845 for ; Mon, 30 Jun 2003 11:54:34 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovhv28385 for ; Mon, 30 Jun 2003 11:54:32 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQovhv28089 for ; Mon, 30 Jun 2003 11:54:24 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12885; Mon, 30 Jun 2003 07:54:22 -0400 (EDT) Message-Id: <200306301154.HAA12885@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-query-08.txt Date: Mon, 30 Jun 2003 07:53:17 -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 : Multi Protocol Label Switching Label Distribution Protocol Query Message Description Author(s) : P. Ashwood-Smith, A. Paraschiv, D. Allan Filename : draft-ietf-mpls-lsp-query-08.txt Pages : 19 Date : 2003-6-27 This document describes the encoding and procedures for three new Label Distribution Protocol (LDP) messages: Query Message, Query- Reply Message and Partial Query-Reply Message. A Label Edge Router (LER) sends a Query message when it needs to find out information about an established Label Switched Path (LSP). The Query message can be used for LDP LSPs as well as for Constraint-Based Label Switched Paths (CR-LSPs). The queried data is encoded into the Query-Reply messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-query-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-query-08.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: <2003-6-27150726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-query-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-query-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150726.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jun 30 16:24:04 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14595 for ; Mon, 30 Jun 2003 16:24:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjd01778 for ; Mon, 30 Jun 2003 20:24:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovjd00998; Mon, 30 Jun 2003 20:23:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQovhv09954 for mpls-outgoing; Mon, 30 Jun 2003 11:56:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQovhv09936 for ; Mon, 30 Jun 2003 11:56:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovhv06349 for ; Mon, 30 Jun 2003 11:55:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovhv28067 for ; Mon, 30 Jun 2003 11:55:39 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovhv28052 for ; Mon, 30 Jun 2003 11:55:39 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5UBtag5015439 for ; Mon, 30 Jun 2003 07:55:37 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAH64418; Mon, 30 Jun 2003 07:55:36 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5UBtZ824668 for mpls@uu.net; Mon, 30 Jun 2003 07:55:35 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovhv09723 for ; Mon, 30 Jun 2003 11:54:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQovhv09675 for ; Mon, 30 Jun 2003 11:54:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovhv15411 for ; Mon, 30 Jun 2003 11:54:27 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQovhv15193 for ; Mon, 30 Jun 2003 11:54:19 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12842; Mon, 30 Jun 2003 07:54:18 -0400 (EDT) Message-Id: <200306301154.HAA12842@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-te-feed-06.txt Date: Mon, 30 Jun 2003 07:53:12 -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 : Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol Author(s) : P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki Filename : draft-ietf-mpls-te-feed-06.txt Pages : 13 Date : 2003-6-27 One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints, which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. A new mechanism is proposed whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This information is most valuable in failure scenarious but is benificial during other path setup functions as well. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy of the overall routing solution by significantly reducing the database discrepancies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-feed-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-te-feed-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27150715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-feed-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-feed-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150715.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jun 30 16:28:03 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14703 for ; Mon, 30 Jun 2003 16:28:02 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjd11262 for ; Mon, 30 Jun 2003 20:28:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovjd10858; Mon, 30 Jun 2003 20:27:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQovhz04326 for mpls-outgoing; Mon, 30 Jun 2003 12:47:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQovhz04305 for ; Mon, 30 Jun 2003 12:47:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQovhz15697 for ; Mon, 30 Jun 2003 12:46:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovhz10004 for ; Mon, 30 Jun 2003 12:46:25 GMT Received: from jera.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.movaz.com [65.205.166.188]) id QQovhz09990 for ; Mon, 30 Jun 2003 12:46:25 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with SMTP id CE6E380F5; Mon, 30 Jun 2003 08:46:24 -0400 (EDT) Message-ID: <057f01c33f05$9dc07cd0$681810ac@movaz.com> From: "Adrian Farrel" To: "M. ELK" , , Cc: References: Subject: Re: WG last call on the FTN mib module and the TE mib module Date: Mon, 30 Jun 2003 08:46:24 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Hi... > Quote > >mplsTunnelDescr > >Since this attribute cannot be signaled, please add a note to explain that > >the value of this object at transit and egress nodes will be automatically > >generated (or blank) according to the implementation and may not match the > >value at the ingress. > Unquote > > As an option , why not using "session Name" which is part of session > attribute object . > this way the mplsTunnelDscr have a common value across all LSR (Set by > Headend and reflected at the transit and egress LSR ) . > Because you need to signal mplsTunnelName in the Session Name field in the signaling protocol. Cheers, Adrian From owner-mpls@UU.NET Mon Jun 30 19:54:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23015 for ; Mon, 30 Jun 2003 19:54:55 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovjr03086 for ; Mon, 30 Jun 2003 23:54:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQovjr02776; Mon, 30 Jun 2003 23:54:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQovio06244 for mpls-outgoing; Mon, 30 Jun 2003 16:34:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQovio06236 for ; Mon, 30 Jun 2003 16:34:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQovio21659 for ; Mon, 30 Jun 2003 16:33:40 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQovio02542 for ; Mon, 30 Jun 2003 16:33:39 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQovio02515 for ; Mon, 30 Jun 2003 16:33:38 GMT Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5UGXZg5001746 for ; Mon, 30 Jun 2003 12:33:35 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAH81905; Mon, 30 Jun 2003 12:33:34 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h5UGXY100164 for mpls@uu.net; Mon, 30 Jun 2003 12:33:34 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQover23098 for ; Sun, 29 Jun 2003 15:27:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQover01735 for ; Sun, 29 Jun 2003 15:27:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQover03211 for ; Sun, 29 Jun 2003 15:27:14 GMT Received: from eri.interia.pl by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: eri.interia.pl [217.74.65.138]) id QQover03187 for ; Sun, 29 Jun 2003 15:27:13 GMT Received: from poczta.interia.pl (egaheer.interia.pl [217.74.65.182]) by eri.interia.pl (Postfix) with ESMTP id 6D5932624C for ; Sun, 29 Jun 2003 17:27:08 +0200 (CEST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by system.wewnetrzny9 (poczta.interia.pl) with SMTP id B531237423C for ; Sun, 29 Jun 2003 17:27:12 +0200 (CEST) Received: by poczta.fm (poczta.fm, from userid 502) id A2A836432C; Sun, 29 Jun 2003 17:27:12 +0200 (CEST) Received: from wilk (pa22.bydgoszcz.sdi.tpnet.pl [213.25.7.22]) by poczta.fm (poczta.fm) with ESMTP id B669D64327 for ; Sun, 29 Jun 2003 17:27:11 +0200 (CEST) Message-ID: <001d01c33e52$e9577850$02ffa8c0@wilk> From: =?iso-8859-2?Q?Rafa=B3_Wilkowski?= To: Subject: ingress LER does not recognize traffic Date: Sun, 29 Jun 2003 17:27:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Does anyone know the reasons why ingress LER cannot recognize traffic - and the traffic, though should be recognized as one belonging to FEC, is IP routed instead of pushed into LSP. What could be the reason of that? As I understand there might be FEC-to-NHLFE map missing... it means that maybe there is no NHLFE...? What actually influences creation of NHLFE? (I believe routing tables must converge first, but what more?) Could anyone provide me with deep details on how router creates NHLFE ? I also heard about the cost of table lookup: single memory access - what does it mean ? Configuration: There are 10 dynamic LSPs going through the router and 2 FECs they are associated with. All the LSPs in fact follow the same shortest route. Assume the traffic is quite heavy in the network. Thanks in advance for help, Rafal