From owner-mpls@UU.NET Thu May 1 08:41: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 IAA06942 for ; Thu, 1 May 2003 08:40: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 QQomuk06626 for ; Thu, 1 May 2003 12:43: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 QQomuk06569; Thu, 1 May 2003 12:43:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQomuh01992 for mpls-outgoing; Thu, 1 May 2003 11:55:27 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 QQomuh01985 for ; Thu, 1 May 2003 11:55: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 QQomuh18765 for ; Thu, 1 May 2003 11:55: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 QQomuh03158 for ; Thu, 1 May 2003 11:55: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 QQomuh03142 for ; Thu, 1 May 2003 11:55:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h41Bt34c022018 for ; Thu, 1 May 2003 07:55:03 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA20714 for ; Thu, 1 May 2003 07:55:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h41Bt2N09376 for mpls@uu.net; Thu, 1 May 2003 07:55: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 QQomuh01949 for ; Thu, 1 May 2003 11:53:56 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 QQomuh03314 for ; Thu, 1 May 2003 11:51:38 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 QQomuh09940 for ; Thu, 1 May 2003 11:51:37 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 QQomuh09930 for ; Thu, 1 May 2003 11:51:37 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05670; Thu, 1 May 2003 07:48:28 -0400 (EDT) Message-Id: <200305011148.HAA05670@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Date: Thu, 01 May 2003 07:48:28 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Management Requirements for MPLS MIBs Author(s) : W. Lai, L. Chung Filename : draft-lai-mpls-mib-rqmts-00.txt Pages : 6 Date : 2003-4-30 In this document, requirements for three MPLS-related MIBs (LDP-MIB, VPN-MIB, and BGP4-MIB) are presented for the support of specific network management needs for fault and performance management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.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-lai-mpls-mib-rqmts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lai-mpls-mib-rqmts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-30150803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lai-mpls-mib-rqmts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lai-mpls-mib-rqmts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-30150803.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 1 08:55: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 IAA07258 for ; Thu, 1 May 2003 08:55: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 QQomul05118 for ; Thu, 1 May 2003 12:58: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 QQomul04793; Thu, 1 May 2003 12:57:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQomuj22987 for mpls-outgoing; Thu, 1 May 2003 12:22:32 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 QQomuj22978 for ; Thu, 1 May 2003 12:22:28 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 QQomuj23376 for ; Thu, 1 May 2003 12:22: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 QQomuj23699 for ; Thu, 1 May 2003 12:22:02 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 QQomuj23629 for ; Thu, 1 May 2003 12:21:59 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 h41CLwXx004018 for ; Thu, 1 May 2003 14:21:58 +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 h41CLwt02399 for ; Thu, 1 May 2003 14:21:58 +0200 (CEST) Message-ID: <3EB110BC.8040909@pi.se> Date: Thu, 01 May 2003 14:19: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: MPLS WG Subject: end MPLS WG Last Call on TC MIB 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 bit late - but the last call on Definitions of Textual for Multiprotocol Label Switching (MPLS) Management draft-ietf-mpls-tc-mib-06.txt has ended! -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Thu May 1 10:09: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 KAA11311 for ; Thu, 1 May 2003 10:08: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 QQomuk14876 for ; Thu, 1 May 2003 12:34: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 QQomuk14667; Thu, 1 May 2003 12:34:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQomuh01965 for mpls-outgoing; Thu, 1 May 2003 11:54:31 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 QQomuh01958 for ; Thu, 1 May 2003 11:54:13 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 QQomuh26691 for ; Thu, 1 May 2003 11:54: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 QQomuh00803 for ; Thu, 1 May 2003 11:54:07 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 QQomuh00773 for ; Thu, 1 May 2003 11:54:07 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h41Bs44c021994 for ; Thu, 1 May 2003 07:54:04 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA20678 for ; Thu, 1 May 2003 07:54:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h41Bs3P09329 for mpls@uu.net; Thu, 1 May 2003 07:54:03 -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 QQomuh01913 for ; Thu, 1 May 2003 11:52: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 QQomuh21042 for ; Thu, 1 May 2003 11:51: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 QQomuh10005 for ; Thu, 1 May 2003 11:51: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 QQomuh09995 for ; Thu, 1 May 2003 11:51:40 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05734; Thu, 1 May 2003 07:48:47 -0400 (EDT) Message-Id: <200305011148.HAA05734@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-telink-mib-01.txt Date: Thu, 01 May 2003 07:48: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 : Traffic Engineering Link Management Information Base Author(s) : M. Dubuc et al. Filename : draft-ietf-mpls-telink-mib-01.txt Pages : 46 Date : 2003-4-30 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 modeling TE links as described in the Link Bundling in MPLS Traffic Engineering document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-telink-mib-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-telink-mib-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-telink-mib-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-4-30150841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-telink-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-telink-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-30150841.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 1 10:17: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 KAA12636 for ; Thu, 1 May 2003 10:17: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 QQomur25644 for ; Thu, 1 May 2003 14:19: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 QQomur25268; Thu, 1 May 2003 14:19:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQomuo17111 for mpls-outgoing; Thu, 1 May 2003 13:37:30 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 QQomuo17106 for ; Thu, 1 May 2003 13:37:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQomuo08694 for ; Thu, 1 May 2003 13:35:37 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 QQomuo20624 for ; Thu, 1 May 2003 13:35:36 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 QQomuo20595 for ; Thu, 1 May 2003 13:35:36 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41DZTWS029292 for ; Thu, 1 May 2003 09:35:33 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA25789 for ; Thu, 1 May 2003 09:35:29 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h41DZS018217 for mpls@uu.net; Thu, 1 May 2003 09:35:28 -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 QQomrv29398 for ; Wed, 30 Apr 2003 19:47:41 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 QQomru00010 for ; Wed, 30 Apr 2003 19:42: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 QQomru15142 for ; Wed, 30 Apr 2003 19:42:05 GMT Received: from fep03-mail.bloor.is.net.cable.rogers.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) id QQomru15125 for ; Wed, 30 Apr 2003 19:42:04 GMT Received: from cr442038a ([24.103.66.219]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030430194151.VDRQ14894.fep03-mail.bloor.is.net.cable.rogers.com@cr442038a> for ; Wed, 30 Apr 2003 15:41:51 -0400 Message-ID: <01dc01c30f50$436fb320$010210ac@flfrd.phub.net.cable.rogers.com> From: "Martin Dubuc" To: Subject: RE: I-D ACTION:draft-ietf-mpls-telink-mib-00.txt Date: Wed, 30 Apr 2003 14:09:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C2_01C30F22.1B81C520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.66.219] using ID at Wed, 30 Apr 2003 15:41:38 -0400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01C2_01C30F22.1B81C520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is my response to Bert's email which explains how I have addressed = Bert's comments in draft-ietf-mpls-telink-mib-01.txt that was submitted = this morining to IETF. My comments are embedded in the original mail = (prefixed with [Martin]). Martin * * * [added Alex and WG chairs] First... as you can see, I have quite a bit of comments. I would think it would be good if the WG sees all that. However, I cannot post it since the document has not been=20 given to the WG yet.... WG chairs, what do you think? Here is my review: - compiles/syntax-checking clean. Good! But..... - linelegth checker: $ /bin/checkpage.awk = , July 2002." Into This MIB module contains managed object definitions for MPLS traffic engineering links as defined in 'Link Bundling in MPLS Traffic Engineering'." [Martin] Fixed. - In DESCRIPTION clause of teLinkENtry you still have a (TBD), while we already know that it is 200, do we not? Also, I do not understand the last sentence of that DESCRIPTION clause (I dare to bet there are others who won't understand it either). SO please clarify in the text [Martin] Have replaced TBD to 200. Last sentence was removed since this = is no longer true (there is a separate field for outgoing interface id). - May I recommend that=20 teLinkIpAddrType InetAddressType, teLinkIpAddr InetAddress, teLinkRemoteIpAddr InetAddress, Be renamed to: teLinkAddressType InetAddressType, teLinkLocalAddress InetAddress, teLinkRemoteAddress InetAddress, First of all, there can be an unnumbered addresstype (unknown), so = then it is not an IpAddress.=20 Second, I think that the first address is the local address (that is = on the device where the instance of the object lives, no?=20 Further I wonder.. if it is an unnumbered link, it has an identifier = somehow does it not. Why would we not put that identifier in the address in = that case and describe what it looks like. In fact I wonder if instead of the InetAddress.... TCs would it not be better to use TeHopAddres... TCs = from the MPLS-TC-MIB? It allows for TeHopAddressUnnum as an address In any event, I would not write: teLinkIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "For IPv4 and IPv6 numbered links, this object represents the IP address type associated with the TE link. For unnumbered links, a value of unknown(0) must be used." But rather something aka: teLinkAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address for the TE link. Only IPv4 and IPv6 and unknown (for unnumbered links) need to be supported." =20 Then forther in the Address itself I would do something aka (not that the first sentence is REQUIRED as per RFC3291): teLinkLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The local Internet address for the TE link. The type of this=20 address is determined by the value of the teLinkAddressType object. For an unnumbered TE link, the address represents an unnumbered interface in this format: octets contents encoding 1-4 unnumbered interface network-byte order " I stole some of the text from MPLS-TC-MIB for now [Martin] I have changed the name teLinkIpAddrType to teLinkAddressType = per your recommendation. However, I have not changed teLinkIpAddr and teLinkRemoteIpAddr because these fields are really meant to be IP = addresses. If address type is unnumbered, then these fields should not be used (the teLinkIncomingIfId and teLinkOutgoingIfId fields should be used = instead). It looks like this is not clear enough in the MIB, so I have added text to clarify this point. - I see in a lot of places something like: REFERENCE "[BUNDLING]" That is not the proper way to reference in a REFERENCE clause. When a=20 MIB module gets extracted from the RFC (and that happens a lot) then = all the references to the reference section are lost. So we normally use something like: REFERENCE "Link Bundling in MPLS Traffic Engineering, RFC aaaa." -- RFC Editor to fill in RFC number that will be assigned to = [BUNDLING] Not that this makes for a normative reference to [BUNDLING] [Martin] Done. Have updated all other references. - I see this coming back a few times: teLinkMuxCapability OBJECT-TYPE SYNTAX INTEGER { packetSwitch1(1), packetSwitch2(2), packetSwitch3(3), packetSwitch4(4), layer2Switch(51), tdm(100), lambdaSwitch(150), fiberSwitch(200) } So that is a good candidate for a TC. That would then also allow you = to say a bit more what packetSwitch1, packetSwitch2, etc in fact means. Any explanation for skipping values? It is recommended (but not = required) that they are contiguous. So explaining in the description why such = is not the case is always wise. It possibly is as simple that these values are already allocated/specified somehwere else (GMPLS-OSPF doc?) and=20 reused here. [Martin] I have defined a TC for this. The reason for skipping values is = that we are using the same values than what is defined is in the GMPLS-OSPF = focument (values used in the messages). I have stated this fact in the = description clause. - Would it make sense to elaborate a bit in the DESCRIPTION clause of teLinkProtectionType and explain what the values exactly mean? Or if they are explained in that GMPLS-OSPF doc that you refernce, = then at least make that statement. [Martin] The values are specified in GMPLS-OSPF, but are actually = described in GMPLS-ROUTING. I have added this statement (and the new reference). - I think all the "priotity" objects have a value from 0-7 (or one that = maps to it). Does that call for a TC, in which you can then also describe a = bit more extensive what it is? [Martin] Moved to TC. Added explanations in the DESCRIPTION clause. - teLinkIncomingIfId and teLinkOutgoingIfId I am unclear if these are only for unnumbered links or also for = numbered ones. Can you make that explicit in the DESCRIPTION clauses? [Martin] This is strictly for unnumbered links. Have added in = DESCRIPTION clause. - The places where you use Priority (1..8) that maps to (0..7), I expect = that you did that because they are INDEX objects and INDEX objects should = not=20 include a zero value. However... that is the RECOMMENDED practice. If = there is a good reason to include value zero in the index range then such = can be done, and here it seems that such is justified. (I am assuming here that the priority is defined in some other doc as being in the range = of 0-7. Maybe it is even a field in some other protocol data structure. [Martin] When specifying these indices I thought that it was forbidden = to use value 0 (should have been more consistent in other places). It does make more = sense to use value 0 to 7 since this is what is used in OSPF protocol data = structure (OSPF traffic engineering extensions). Have added text to state that 0 = is valid and why. - teLinkResourceClass Any reference to a document that explains how that bit-valued field is composed/conbtructed/used? [Martin] Have added reference to [OSPF] where resource class is = described. - In all the places/tables where ifIndex is used as an index, could you specify if a specific ifType is expected (or maybe even required) for such an interface. I have the impression that for some it is a fixed value that is acceprtable, for other multiple values are acceptable, and for some maybe even any value is acceptable. If you specified it, I think that things would be clearer for me (and hopefully for others too). [Martin] You are right. In some places, ifType is fixed, others multiple values are acceptable. I have added such description in all tables that use ifIndex. - At all those places where you use Bandwith of 1000 bits per second. You have it in the DESCRIPTION clause. Better is to put it in a UNITS clause, so that it is machine readable/parsable. It is used at many places. Candidate for a TC ?? [Martin] Have added UNITS clause. But not TC. - I see this multiple times: teLinkEncodingType OBJECT-TYPE SYNTAX INTEGER { packet(1), ethernet(2), ansiEtsiPdh(3), sdhItuSonetAnsi(5), digitalWrapper(7), lambda(8), fiber(9), fiberChannel(11) } Yep... as you guessed: why is it not a TC? [Martin] It is a TC now. - I see a few of these: componentLinkPreferredProtection OBJECT-TYPE SYNTAX INTEGER { primary(1), secondary(2) } Candidate for a TC I'd say [Martin] Done. - I still see in (I believe all of) your RowStatus objects somthing = like: DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. All read-create objects can only be changed when teLinkRowStatus is active." ----------- As I said before, This really weird. Probably/Possibly You mean: All read-create objects can be changed even when xxxRowStatus is active." If so, pls fix, if not, pls explain. You may want to reread first para on page 17 of RFC2579 In any event, when a row is initially created, it cannot be 'active', it can only become active if all columns have proper values, so one must be able to change a row when in notReady or notInservice state. Or when in not-existing state. That is the default. The default is = also that one cannot write (SET) any columns while a row is active, so that = is why a DESCRIPTION clause of a RowStatus object MUST specify which columns can or cannot be written/changed when the row is active. Seems you want to allow all columns to be written-to/changed when a = row is active, so my suggested text replacement above caters for that. [Martin] I meant to say that read-create objects can only be changed = when teLinkRowStatus is not active. I have updated all RowStatus text = accordingly. - WHen I see a table like this: teLinkDescriptorTable TeLinkDescriptorEntry ::=3D SEQUENCE { teLinkDescriptorId Unsigned32, teLinkEncodingType INTEGER, teLinkDescrPriority Unsigned32, teLinkMinReservableBandwidth Unsigned32, teLinkMaxReservableBandwidth Unsigned32, =20 teLinkDescrRowStatus RowStatus, teLinkDescrStorageType StorageType Then I always wonder if we cannot make it easier for people to see = which objects are indeed in that table. The first object name = teLinkDescriptorId clealrly is in this table. Then we have one teLinkEncodingType that is = not so clear. Then we have one that is not as clear as the 1st one, but = still gives some clue. Then we have 2 that give not clue, then we have 2 = more that give some clue. How about naming them: TeLinkDescriptorEntry ::=3D SEQUENCE { teLinkDescriptorId Unsigned32, teLinkDescrEncodingType INTEGER, teLinkDescrPriority Unsigned32, teLinkDescrMinReservableBandwidth Unsigned32, teLinkDescrMaxReservableBandwidth Unsigned32, =20 teLinkDescrRowStatus RowStatus, teLinkDescrStorageType StorageType If you can agree with that, then pls check you other tables. The same=20 issue/concern comes back in a few other tables. In fact our mib guidelines document does discuss this issue. [Martin] Although it is not obvious why some entries do not have the = same table prefix, some others have been shortened because of the 32 character = limit warning for identifiers reported by smilint. I have changed the identifiers so that they have the same prefix but stayed within limit of 32 characters. - Your teLinkNotifEnable would be better named: = teLinkNotificationsEnabled [Martin] Changed. - I worry about the number of notifications that can get generated per = minute or per second? Can you say something about it? Do we need an abject = that=20 lets an NMS configure how many notification an agent can send at most = per minute? [Martin] is only one type of notification in the TE link MIB module. This notification can only occur if the provider uses bundled link and = will be generated only when there is a mismatch in a link bundle. Since link = bundles and TE links are provisioned by users and not on a regular basis, and = since mismatches are not likely to be common, the number of notifications = should be extremely small. I do not think there is a need to throttle these = notifications. - linkBundleMismatch I do not understand the DESCRIPTION clause at all. Specifically, if an = error is found and the notification is sent, then the 1 second later, the = same=20 situation probably still exists. Is another notification sent? Should such a problem not be detected when someone creates an antry in a table and should create operation not be prevented from succeeding? [Martin] I expected that the notification would be sent only when the mismatch was detected. We could prevent a create to succeed if we detect a mismatch, but it may be easier to just flag the error. I don't know how others feel about this. - I do not understand the difference between your ...FullCOmpliance and ...MonCompliance (by the way, in other MIB modules we have named the latter one ...ReadOnlyCompliance). I would think that the = ...FullCOmpliance one should NOT allow for read-only at all. How can you otherwise claim = that it is for monitoring AND configuring. [Martin] I meant for the first compliance to be used by devices that = allowed provisioning and monitoring and the second compliance for devices that only allowed monitoring (no provisioning). I do not know why = read-only were allowed in the first case. This is not supposed to be. I have = changed this. I have renamed MonCompliance to ReadOnlyCompliance. - I also have trouble with: OBJECT teLinkIpAddrType SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "The dns(16) address type need not be supported. The ipv4(1) and ipv6(2) address types need not be supported if numbered links are not supported. The unknown(0) address type need not be supported if unnumbered links are not supported." I would rather do something like: OBJECT teLinkIpAddrType SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Only ipv4(1) and ipv6(2) address types need to be supported for numbered links. For unnumbered links unknown (0) needs to be supported." In the future other types could be added to InetAddressType TC, and so you onbly want to list here what needs to be supported, not=20 (in explicit form) what needs not be supported. [Martin] Fine. Have updated accordingly. I wonder if you do not need ipv4z and/or ipv6z. As long as you have evaluated this (with the WG) and decide that you do not need it, then fine. [Martin] The issue of what to do with ipv4z and ipv6z has not been = raised by the WG or by the 3 implementations that we know of the MIB. - 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=20 notInService may not be needed either. (I am assuming here that I=20 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. - I have trouble with: OBJECT teLinkStorageType SYNTAX INTEGER { other(1) } DESCRIPTION "Only other(1) needs to be supported." I think I could live with a volatile only, but the 'other' value is completely unspecified and seems to make no sense to me at all. What is you intention here? [Martin] I picked this from the LSR MIB. I don't think there is a good reason to limit to one single value. I have removed this conformance statement. - In security considerations... - Do All tables have the same considerations? If so you may want to make that explicit. [Martin] Yes, they all have the same considerations. All info in this MIB module are used for routing purposes. To me, they have the same sensitivity. Except for IP addresses, which may actually be used in some sort of attack if known. This is why I have a separate clause regarding IP addresses. - In general, our security ADs probably want some more specificity. A statement like "all tables ....." sounds as if you are opting for an easy out. [Martin] It may sounds like I am opting for an easy out, but the fact of the matter is, all tables have the same considerations. - On th eread-only objects... are there no issues with bandwith info? Or priorities? On protection?=20 would that not reveal info that people don't want to loose? [Martin] The problem here is where you draw the line. Every MIB object is vulnerable and may reveal info that would be better kept secret. I = have read the security guidelines thoroughly and my interpretation is that we should uncover anything that is sensitive to exposure of end-user personal information or may lead to potential disruption of service. There isn't anything in TE link MIB that relates to end-user personal information. There is potential for disruption of service if someone changes attributes in any table of the MIB because this affects routing (this is my first statement) and there may be disruption of service if = the IP address are used in some form of spoofing or attack (this is my = second statement). I don't know that there is much else to say according to the spirit of the security guidelines. - Sect 13.1 Not sure whre [Assigned] is referenced or if it is needed. is it? Please note that you must make normative references to all RFCs from whihc you IMPORT any objects or TCs or such. =20 [Martin] I have removed [Assigned] reference. I have added RFC3291 as = reference since it is is imported (INET-ADDRESS-MIB). - Sect 13.2 You seem to have kept a lot of old MIB boilerplate references that = seem no longer needed,. [Martin] Fixed. Thanks, Bert=20 ------=_NextPart_000_01C2_01C30F22.1B81C520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is my response to Bert's email which explains how I have = addressed=20 Bert's comments in draft-ietf-mpls-telink-mib-01.txt that was submitted = this=20 morining to IETF. My comments are embedded in the original mail = (prefixed with=20 [Martin]).
 
Martin
 
* * *
 
[added Alex and WG chairs]

First... as you can see, I have = quite a=20 bit of comments.
I would think it would be good if the WG sees all=20 that.
However, I cannot post it since the document has not been =
given to=20 the WG yet.... WG chairs, what do you think?

Here is my = review:

-=20 compiles/syntax-checking clean. Good!

But.....

- linelegth = checker:
   $ /bin/checkpage.awk=20 <home/ietf/drafts/draft-ietf-mpls-telink-mib-01.txt
   = Long line=20 at 770 with 77 chars
   Long line at 771 with 76=20 chars
   Long line at 1268 with 73 chars
   -: = 3 lines=20 longer than 72 characters, max 77

[Martin] Fixed.

- Last = sentence=20 of abstract talks about "draft". I think you want to use
  = "document" or=20 "memo" so that it is still valid when that draft becomes
  an = RFC. Maybe=20 this occurs at other places too, pls check

[Martin] Fixed. = Checked for=20 other references to draft. Was the only reference
to a = draft.

- You=20 seem to be using "MIB" many times where "MIB Module" or "MIB = document"
 =20 would be better. Remember there is only one (Single) MIB, which is=20 composed
  of many (multiple) MIB modules. One or more MIB = modules may=20 be described
  and specified in a MIB document

[Martin]=20 Fixed.

- I have not yet checked sect 7.

- I do not see any = words=20 on the relationship betwen teLinkXxxTables
  and = componetXxxxTables.=20 Would be good to write something about that

[Martin] I have added = text to=20 explain the relationships at end of
section 6.

- I would = suggest that=20 maybe you should replace your 1st figure in sect 8.2
  with the = figire=20 from the overview document (revision 4) section 11.2. That
  = seems=20 clearer to me.

[Martin] Done. I have used similar format for the = second=20 figure.

- I still have the impression that sect 5.1 (summary) and = section=20 6 are
  basically a duplicate of each other. I can live with = it... but=20 ???

[Martin] You are correct, section 5.1 is roughly the same as = section=20 6.
I have deleted section 5.1 and consolidated its non-duplicated=20 content
into section 6.

- sect 8.1 under ifType you refernece=20 [IanaFamily].
  I think the reference should be to the = ianaiftype.mib=20

[Martin] You are right. Fixed.

- for my understanding, = the figure=20 in sect 8.2, can you explain which layers
  in the stack are = bundle(s),=20 telink or component link. In fact it might be
  good to add that = explanantion to the text, so that people can read it = too.

[Martin]=20 Actually the example is not very clear and your comment has = triggered
a=20 flurry of mails between the authors. We have updated the example = to
make it=20 easier for readers to understand. opticalTrans are component = links.
In the=20 example in version 00, the layer on top of opticalTrans was bundled = link.=20 The
component links in this example were actually TE links but this = fact was=20 not
shown. These TE links were implicit. You would have to be a = psychic to=20 see
this. The layer on top of bundled link was also bundled link. = With this,=20 we were
showing that one can bundle bundles. But we feel that this = adds=20 complexity that
is not required. We have streamlined the example and=20 explained it better. We
have removed the second layer of bundling because this is an = advanced
configuration.

- In the CONTACT-INFO, pls add WG mailing = list=20 information

[Martin] Done.

- In DESCRIPTION clause of=20 MODULE-IDENTITY..
  - add year (2003) to copyright = statement
 =20 And I think I would = change:

       =20 This MIB contains managed object definitions=20 for
        MPLS traffic = engineering links=20 as defined in:
        Kompella, = K.,=20 Rekhter, Y., Berger, L.,
        = Link=20 Bundling in MPLS Traffic=20 Engineering
        Internet Draft = <draft-ietf-mpls-bundling-04.txt>,
     = ;  =20 July 2002."

  = Into
       =20 This MIB module contains managed object definitions=20 for
        MPLS traffic = engineering links=20 as defined in 'Link = Bundling
        in=20 MPLS Traffic Engineering'."

[Martin] Fixed.

- In = DESCRIPTION=20 clause of teLinkENtry you still have a (TBD), while
  we already = know=20 that it is 200, do we not?

  Also, I do not understand the = last=20 sentence of that DESCRIPTION clause
  (I dare to bet there are = others=20 who won't understand it either). SO
  please clarify in the=20 text

[Martin] Have replaced TBD to 200. Last sentence was removed = since=20 this is
no longer true (there is a separate field for outgoing = interface=20 id).

- May I recommend that
    =20 teLinkIpAddrType         &nb= sp;  =20 InetAddressType,
    =20 teLinkIpAddr          &= nbsp;     =20 InetAddress,
    =20 teLinkRemoteIpAddr         &= nbsp;=20 InetAddress,
  Be renamed to:
    =20 teLinkAddressType         &n= bsp;  =20 InetAddressType,
    =20 teLinkLocalAddress         &= nbsp; =20 InetAddress,
    =20 teLinkRemoteAddress         =  =20 InetAddress,
  First of all, there can be an unnumbered = addresstype=20 (unknown), so then
  it is not an IpAddress.
  Second, = I think=20 that the first address is the local address (that is on
  the = device=20 where the instance of the object lives, no?

  Further I = wonder.. if=20 it is an unnumbered link, it has an identifier somehow
  does it = not.=20 Why would we not put that identifier in the address in that = case
  and=20 describe what it looks like. In fact I wonder if instead of  = the
 =20 InetAddress.... TCs would it not be better to use TeHopAddres... TCs = from=20 the
  MPLS-TC-MIB? It allows for TeHopAddressUnnum as an=20 address

  In any event, I would not = write:
   =20 teLinkIpAddrType OBJECT-TYPE
     =20 SYNTAX       =20 InetAddressType
      = MAX-ACCESS   =20 read-create
     =20 STATUS       =20 current
     =20 DESCRIPTION
        "For IPv4 and = IPv6=20 numbered links, this object represents=20 the
         IP address type=20 associated with the TE link.=20 For
         unnumbered = links, a=20 value of unknown(0) must be used."
  But rather something=20 aka:
    teLinkAddressType=20 OBJECT-TYPE
     =20 SYNTAX       =20 InetAddressType
      = MAX-ACCESS   =20 read-create
     =20 STATUS       =20 current
     =20 DESCRIPTION
        "The type of = Internet=20 address for the TE link. Only IPv4=20 and
         IPv6 and unknown = (for=20 unnumbered links) need to be supported."
 
  Then = forther in=20 the Address itself I would do something aka (not that
  the = first=20 sentence is REQUIRED as per RFC3291):
    = teLinkLocalAddress=20 OBJECT-TYPE
     =20 SYNTAX       =20 InetAddress
      = MAX-ACCESS   =20 read-create
     =20 STATUS       =20 current
     =20 DESCRIPTION
        "The local = Internet=20 address for the TE link. The type of this=20
         address is = determined by=20 the value of the=20 teLinkAddressType
         = object.=20 For an unnumbered TE link, the address represents=20 an
         unnumbered = interface in=20 this=20 format:

         &nbs= p;   =20 octets  =20 contents           = ;   =20 encoding
          &= nbsp;  =20 1-4      unnumbered interface   = network-byte=20 order
        "
  I stole = some of=20 the text from MPLS-TC-MIB for now

[Martin] I have changed the = name=20 teLinkIpAddrType to teLinkAddressType per
your recommendation. = However, I=20 have not changed teLinkIpAddr and
teLinkRemoteIpAddr because these = fields are=20 really meant to be IP addresses.
If address type is unnumbered, then = these=20 fields should not be used (the
teLinkIncomingIfId and = teLinkOutgoingIfId=20 fields should be used instead).
It looks like this is not clear = enough in the=20 MIB, so
I have added text to clarify this point.

- I see in a = lot of=20 places something like:
      =20 REFERENCE
       "[BUNDLING]"
  = That is=20 not the proper way to reference in a REFERENCE clause. When a
  = MIB=20 module gets extracted from the RFC (and that happens a lot) then = all
 =20 the references to the reference section are lost. So we normally = use
 =20 something like:
      REFERENCE "Link = Bundling in=20 MPLS Traffic Engineering, RFC aaaa."
      = -- RFC=20 Editor to fill in RFC number that will be assigned to = [BUNDLING]

 =20 Not that this makes for a normative reference to = [BUNDLING]

[Martin]=20 Done. Have updated all other references.

- I see this coming back = a few=20 times:
    teLinkMuxCapability=20 OBJECT-TYPE
        = SYNTAX  =20 INTEGER=20 {
           &n= bsp;        =20 packetSwitch1(1),
        &nbs= p;           =20 packetSwitch2(2),
        &nbs= p;           =20 packetSwitch3(3),
        &nbs= p;           =20 packetSwitch4(4),
        &nbs= p;           =20 layer2Switch(51),
        &nbs= p;           =20 tdm(100),
          =           =20 lambdaSwitch(150),
        &nb= sp;           =20 fiberSwitch(200)
         = ;       =20 }
   So that is a good candidate for a TC. That would then = also=20 allow you to
   say a bit more what packetSwitch1, = packetSwitch2,=20 etc in fact means.
   Any explanation for skipping values? = It is=20 recommended (but not required)
   that they are contiguous. = So=20 explaining in the description why such is not
   the case = is always=20 wise. It possibly is as simple that these values
   are = already=20 allocated/specified somehwere else (GMPLS-OSPF doc?) and =
   reused=20 here.

[Martin] I have defined a TC for this. The reason for = skipping=20 values is that
we are using the same values than what is defined is = in the=20 GMPLS-OSPF focument
(values used in the messages). I have stated this = fact in=20 the description clause.

- Would it make sense to elaborate a bit = in the=20 DESCRIPTION clause of
  teLinkProtectionType and explain what = the values=20 exactly mean?
  Or if they are explained in that GMPLS-OSPF doc = that you=20 refernce, then
  at least make that statement.

[Martin] = The=20 values are specified in GMPLS-OSPF, but are actually described=20 in
GMPLS-ROUTING. I have added this statement (and the new=20 reference).

- I think all the "priotity" objects have a value = from 0-7=20 (or one that maps
  to it). Does that call for a TC, in which = you can=20 then also describe a bit
  more extensive what it = is?

[Martin]=20 Moved to TC. Added explanations in the DESCRIPTION clause.

-=20 teLinkIncomingIfId and teLinkOutgoingIfId
  I am unclear if = these are=20 only for unnumbered links or also for numbered
  ones. Can you = make that=20 explicit in the DESCRIPTION clauses?

[Martin] This is strictly = for=20 unnumbered links. Have added in DESCRIPTION clause.

- The places = where=20 you use Priority (1..8) that maps to (0..7), I expect that
  you = did=20 that because they are INDEX objects and INDEX objects should not =
 =20 include a zero value. However... that is the RECOMMENDED practice. If=20 there
  is a good reason to include value zero in the index = range then=20 such can
  be done, and here it seems that such is justified. (I = am=20 assuming here
  that the priority is defined in some other doc = as being=20 in the range of
  0-7. Maybe it is even a field in some other = protocol=20 data structure.

[Martin] When specifying these indices I thought = that it=20 was forbidden to use value 0
(should have been more consistent in = other=20 places). It does make more sense
to use value 0 to 7 since this is = what is=20 used in OSPF protocol data structure
(OSPF traffic engineering = extensions).=20 Have added text to state that 0 is valid and why.

-=20 teLinkResourceClass
  Any reference to a document that explains = how that=20 bit-valued field is
  composed/conbtructed/used?

[Martin] = Have=20 added reference to [OSPF] where resource class is described.

- In = all the=20 places/tables where ifIndex is used as an index, could you
  = specify if=20 a specific ifType is expected (or maybe even required) for
  = such an=20 interface. I have the impression that for some it is a fixed
  = value=20 that is acceprtable, for other multiple values are acceptable,
  = and for=20 some maybe even any value is acceptable. If you specified it,
  = I think=20 that things would be clearer for me (and hopefully for others
 =20 too).

[Martin] You are right. In some places, ifType is fixed, = others=20 multiple
values are acceptable. I have added such description in all=20 tables
that use ifIndex.

- At all those places where you use = Bandwith=20 of 1000 bits per second.
  You have it in the DESCRIPTION = clause. Better=20 is to put it in a UNITS
  clause, so that it is machine=20 readable/parsable.
  It is used at many places. Candidate for a = TC=20 ??

[Martin] Have added UNITS clause. But not TC.

- I see = this=20 multiple times:
     teLinkEncodingType=20 OBJECT-TYPE
       = SYNTAX   =20 INTEGER=20 {
           &n= bsp;        =20 packet(1),
          = ;          =20 ethernet(2),
         &nb= sp;          =20 ansiEtsiPdh(3),
         =            =20 sdhItuSonetAnsi(5),
        &n= bsp;           =20 digitalWrapper(7),
        &nb= sp;           =20 lambda(8),
          = ;          =20 fiber(9),
          =           =20 fiberChannel(11)
         = ;       =20 }
   Yep... as you guessed: why is it not a = TC?

[Martin] It=20 is a TC now.

- I see a few of these:
  =20 componentLinkPreferredProtection = OBJECT-TYPE
     =20 SYNTAX        INTEGER=20 {
           &n= bsp;          =20 primary(1),
         &nbs= p;            = ;=20 secondary(2)
         &nb= sp;        =20 }
  Candidate for a TC I'd say

[Martin]=20 Done.




- I still see in (I believe all of) your = RowStatus=20 objects somthing like:
   =20 DESCRIPTION
       "This variable is = used to=20 create, modify, and/or
        = delete a=20 row in this table. All read-create=20 objects
        can only be = changed when=20 teLinkRowStatus is = active."
       =20 -----------
  As I said before, This really weird. = Probably/Possibly You=20 mean:
        All read-create = objects can=20 be changed even when = xxxRowStatus
       =20 is active."
  If so, pls fix, if not, pls explain.
  You = may=20 want to reread first para on page 17 of RFC2579
  In any event, = when a=20 row is initially created, it cannot be 'active',
  it can only = become=20 active if all columns have proper values, so one
  must be able = to=20 change a row when in notReady or notInservice state.
  Or when = in=20 not-existing state. That is the default. The default is also
  = that one=20 cannot write (SET) any columns while a row is active, so that
  = is why=20 a DESCRIPTION clause of a RowStatus object MUST specify which
  = columns=20 can or cannot be written/changed when the row is active.
  Seems = you=20 want to allow all columns to be written-to/changed when a row
  = is=20 active, so my suggested text replacement above caters for = that.

[Martin]=20 I meant to say that read-create objects can only be changed=20 when
teLinkRowStatus is not active. I have updated all RowStatus text = accordingly.

- WHen I see a table like this:
  =20 teLinkDescriptorTable
   TeLinkDescriptorEntry ::=3D = SEQUENCE=20 {
     =20 teLinkDescriptorId         &= nbsp;=20 Unsigned32,
     =20 teLinkEncodingType         &= nbsp;=20 INTEGER,
     =20 teLinkDescrPriority         = =20 Unsigned32,
      = teLinkMinReservableBandwidth=20 Unsigned32,
      = teLinkMaxReservableBandwidth=20 Unsigned32,  
     =20 teLinkDescrRowStatus        =20 RowStatus,
     =20 teLinkDescrStorageType       = StorageType
 =20 Then I always wonder if we cannot make it easier for people to see=20 which
  objects are indeed in that table. The first object name=20 teLinkDescriptorId
  clealrly is in this table. Then we have one = teLinkEncodingType that is not
  so clear. Then we have one that = is not=20 as clear as the 1st one, but still
  gives some clue. Then we = have 2=20 that give not clue, then we have 2 more
  that give some clue. = How about=20 naming them:
   TeLinkDescriptorEntry ::=3D SEQUENCE=20 {
     =20 teLinkDescriptorId         &= nbsp;     =20 Unsigned32,
     =20 teLinkDescrEncodingType        &n= bsp; =20 INTEGER,
     =20 teLinkDescrPriority         =      =20 Unsigned32,
      = teLinkDescrMinReservableBandwidth=20 Unsigned32,
      = teLinkDescrMaxReservableBandwidth=20 Unsigned32,  
     =20 teLinkDescrRowStatus         = ;    =20 RowStatus,
     =20 teLinkDescrStorageType        &nb= sp;  =20 StorageType
  If you can agree with that, then pls check you = other=20 tables. The same
  issue/concern comes back in a few other=20 tables.
  In fact our mib guidelines document does discuss this=20 issue.

[Martin] Although it is not obvious why some entries do = not have=20 the same table
prefix, some others have been shortened because of the = 32=20 character limit
warning for identifiers reported by smilint. I have = changed=20 the
identifiers so that they have the same prefix but stayed = within
limit=20 of 32 characters.

- Your teLinkNotifEnable would be better named: = teLinkNotificationsEnabled

[Martin] Changed.

- I worry = about the=20 number of notifications that can get generated per minute
  or = per=20 second? Can you say something about it? Do we need an abject that =
 =20 lets an NMS configure how many notification an agent can send at most=20 per
  minute?

[Martin] is only one type of notification = in the TE=20 link MIB module.
This notification can only occur if the provider = uses=20 bundled link and will
be generated only when there is a mismatch in a = link=20 bundle. Since link bundles
and TE links are provisioned by users and = not on a=20 regular basis, and since
mismatches are not likely to be common, the = number=20 of notifications should be
extremely small. I do not think there is a = need to=20 throttle these notifications.

- linkBundleMismatch
  I do = not=20 understand the DESCRIPTION clause at all. Specifically, if an = error
  is=20 found and the notification is sent, then the 1 second later, the same =
 =20 situation probably still exists. Is another notification sent?
  = Should=20 such a problem not be detected when someone creates an antry = in
  a=20 table and should create operation not be prevented from=20 succeeding?

[Martin] I expected that the notification would be = sent only=20 when the
mismatch was detected. We could prevent a create to succeed = if=20 we
detect a mismatch, but it may be easier to just flag the = error.
I don't=20 know how others feel about this.

- I do not understand the = difference=20 between your ...FullCOmpliance and
  ...MonCompliance (by the = way, in=20 other MIB modules we have named the
  latter one = ...ReadOnlyCompliance).=20 I would think that the ...FullCOmpliance
  one should NOT allow = for=20 read-only at all. How can you otherwise claim that
  it is for=20 monitoring AND configuring.

[Martin] I meant for the first = compliance to=20 be used by devices that allowed
provisioning and monitoring and the = second=20 compliance for devices
that only allowed monitoring (no = provisioning). I do=20 not know why read-only
were allowed in the first case. This is not = supposed=20 to be. I have changed this.
I have renamed MonCompliance to=20 ReadOnlyCompliance.

- I also have trouble=20 with:
     OBJECT     =20 teLinkIpAddrType
    =20 SYNTAX      INTEGER { unknown(0), ipv4(1), = ipv6(2)=20 }
     MIN-ACCESS =20 read-only
    =20 DESCRIPTION
         "The = dns(16)=20 address type need not be=20 supported.
          The = ipv4(1)=20 and ipv6(2) address types need not=20 be
          supported = if=20 numbered links are not supported.=20 The
          unknown(0) = address=20 type need not be supported=20 if
          unnumbered = links=20 are not supported."
   I would rather do something=20 like:
     OBJECT     =20 teLinkIpAddrType
    =20 SYNTAX      INTEGER { unknown(0), ipv4(1), = ipv6(2)=20 }
     MIN-ACCESS =20 read-only
    =20 DESCRIPTION
         "Only = ipv4(1)=20 and ipv6(2) address types need to=20 be
          supported = for=20 numbered links. For unnumbered=20 links
          unknown = (0)=20 needs to be supported."
   In the future other types could = be added=20 to InetAddressType TC, and
   so you onbly want to list = here what=20 needs to be supported, not
   (in explicit form) what = needs not be=20 supported.

[Martin] Fine. Have updated = accordingly.

   I=20 wonder if you do not need ipv4z and/or ipv6z.  As long as you=20 have
   evaluated this (with the WG) and decide that you do = not=20 need it, then
   fine.

[Martin] The issue of what to = do with=20 ipv4z and ipv6z has not been raised
by the WG or by the 3 = implementations=20 that we know of the MIB.

- I have trouble=20 with:
      = OBJECT     =20 teLinkRowStatus
     =20 SYNTAX      INTEGER { active(1),=20 notInService(2),
         = ;            =       =20 createAndGo(4), destroy(6) }
     =20 DESCRIPTION
          = "The=20 notReady(3) state need not be supported."

  I think what you = want to=20 specify is that createAndWait is not needed.
  Since you allow = all=20 objects to be changed in 'active' mode, the
  notInService may = not be=20 needed either. (I am assuming here that I
  did understand your = intent... which I am not sure of). In that case
  something like = the=20 following example from RFC3289 would be = better:

    OBJECT=20 diffServClfrStatus
    SYNTAX RowStatus { active(1)=20 }
    WRITE-SYNTAX RowStatus { createAndGo(4), = destroy(6)=20 }
    = DESCRIPTION
      =20 "Support for createAndWait and notInService is not = required."

[Martin]=20 The notInService is required since it is one of the state that
allows = writes=20 (see explanation a few points above). notReady and createAndWait
are = not=20 required. For read-only, only active is required. I have updated = text
in this=20 respect.

- I have trouble with:
      = OBJECT     =20 teLinkStorageType
     =20 SYNTAX      INTEGER { other(1)=20 }
     =20 DESCRIPTION
          = "Only=20 other(1) needs to be supported."

  I think I could live with = a=20 volatile only, but the 'other' value
  is completely unspecified = and=20 seems to make no sense to me at all.
  What is you intention=20 here?

[Martin] I picked this from the LSR MIB. I don't think = there is a=20 good
reason to limit to one single value. I have removed this=20 conformance
statement.

- In security = considerations...
  - Do=20 All tables have the same considerations? If so you may=20 want
    to make that explicit.

[Martin] Yes, = they all=20 have the same considerations. All info in this
MIB module are used = for=20 routing purposes. To me, they have the
same sensitivity. Except for = IP=20 addresses, which may actually be used
in some sort of attack if = known. This=20 is why I have a separate clause
regarding IP addresses.

  = - In=20 general, our security ADs probably want some more=20 specificity.
    A statement like "all tables ....." = sounds as=20 if you are opting for
    an easy out.

[Martin] = It may=20 sounds like I am opting for an easy out, but the fact of
the matter = is, all=20 tables have the same considerations.

  - On th eread-only = objects...=20 are there no issues with bandwith info?
    Or = priorities? On=20 protection?
    would that not reveal info that = people don't=20 want to loose?

[Martin] The problem here is where you draw the = line.=20 Every MIB object
is vulnerable and may reveal info that would be = better kept=20 secret. I have
read the security guidelines thoroughly and my = interpretation=20 is that we
should uncover anything that is sensitive to exposure of=20 end-user
personal information or may lead to potential disruption of=20 service.
There isn't anything in TE link MIB that relates to end-user = personal
information. There is potential for disruption of service if = someone
changes attributes in any table of the MIB because this = affects=20 routing
(this is my first statement) and there may be disruption of = service=20 if the
IP address are used in some form of spoofing or attack (this = is my=20 second
statement). I don't know that there is much else to say = according to=20 the
spirit of the security guidelines.

- Sect 13.1
  = Not sure=20 whre [Assigned] is referenced or if it is needed. is it?
  = Please note=20 that you must make normative references to all RFCs from
  whihc = you=20 IMPORT any objects or TCs or such.
 
[Martin] I have removed=20 [Assigned] reference. I have added RFC3291 as reference
since it is = is=20 imported (INET-ADDRESS-MIB).

- Sect 13.2
  You seem to = have kept=20 a lot of old MIB boilerplate references that seem
  no longer=20 needed,.

[Martin] Fixed.

Thanks,
Bert=20

------=_NextPart_000_01C2_01C30F22.1B81C520-- From owner-mpls@UU.NET Thu May 1 18:30: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 SAA16489 for ; Thu, 1 May 2003 18:29:11 -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 QQomur26142; Thu, 1 May 2003 14:20:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQomuo17410 for mpls-outgoing; Thu, 1 May 2003 13:41: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 QQomuo17393 for ; Thu, 1 May 2003 13:41:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQomuo11451 for ; Thu, 1 May 2003 13:40:56 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 QQomuo28843 for ; Thu, 1 May 2003 13:40:56 GMT Received: from kcmso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQomuo28835 for ; Thu, 1 May 2003 13:40:55 GMT Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h41CuD0N001364 for ; Thu, 1 May 2003 07:59:55 -0500 (CDT) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3E7A3143016EFA93 for mpls@uu.net; Thu, 1 May 2003 08:59:55 -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: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Date: Thu, 1 May 2003 07:59:48 -0500 Message-ID: <7AFE40EF30EE754DA967D1B5968457CA13704C@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Thread-Index: AcMP2C62Vf/xmb2vROSwc7V+gBejzgACQiDw From: "Lai, Wai S (Waisum), 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 SAA16489 Based on our testing of the LDP MIB, we have identified some requirements as described in the following draft. Your comments are welcome. Thanks, Wai Sum -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, May 01, 2003 7:48 AM Cc: mpls@uu.net; ppvpn@nortelnetworks.com Subject: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Management Requirements for MPLS MIBs Author(s) : W. Lai, L. Chung Filename : draft-lai-mpls-mib-rqmts-00.txt Pages : 6 Date : 2003-4-30 In this document, requirements for three MPLS-related MIBs (LDP-MIB, VPN-MIB, and BGP4-MIB) are presented for the support of specific network management needs for fault and performance management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.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-lai-mpls-mib-rqmts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lai-mpls-mib-rqmts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-mpls@UU.NET Thu May 1 19:17: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 TAA17997 for ; Thu, 1 May 2003 19:16:22 -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 QQomvo18989 for ; Thu, 1 May 2003 20:05: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 QQomvo18705; Thu, 1 May 2003 20:05:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQomvm03889 for mpls-outgoing; Thu, 1 May 2003 19:30: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 QQomvm03879 for ; Thu, 1 May 2003 19:30:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQomvm20494 for ; Thu, 1 May 2003 19:30: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 QQomvm17647 for ; Thu, 1 May 2003 19:30: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 QQomvm17628 for ; Thu, 1 May 2003 19:30:09 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41JU7WS019687 for ; Thu, 1 May 2003 15:30:07 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA29227 for ; Thu, 1 May 2003 15:30:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h41JU6006814 for mpls@uu.net; Thu, 1 May 2003 15:30:06 -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 QQomvl03828 for ; Thu, 1 May 2003 19:29:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQomvl18374 for ; Thu, 1 May 2003 19:28:17 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 QQomvl14523 for ; Thu, 1 May 2003 19:28:17 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 QQomvl14483 for ; Thu, 1 May 2003 19:28: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 PAA02641; Thu, 1 May 2003 15:25:21 -0400 (EDT) Message-Id: <200305011925.PAA02641@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-06.txt Date: Thu, 01 May 2003 15:25:20 -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) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base Author(s) : T.Nadeau, C. Srinivasan, A. Viswanathan Filename : draft-ietf-mpls-ftn-mib-06.txt Pages : 34 Date : 2003-5-1 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-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-ftn-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ftn-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-1153626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ftn-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ftn-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153626.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri May 2 06:45: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 GAA10959 for ; Fri, 2 May 2003 06:44: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 QQomvo25839 for ; Thu, 1 May 2003 20:09: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 QQomvo25639; Thu, 1 May 2003 20:09:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQomvm04211 for mpls-outgoing; Thu, 1 May 2003 19:35:46 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 QQomvm04203 for ; Thu, 1 May 2003 19:35:41 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 QQomvm27248 for ; Thu, 1 May 2003 19:32: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 QQomvm20978 for ; Thu, 1 May 2003 19:32:07 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 QQomvm20956 for ; Thu, 1 May 2003 19:32:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h41JW34c017726 for ; Thu, 1 May 2003 15:32:04 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA29382 for ; Thu, 1 May 2003 15:32:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h41JW3S06905 for mpls@uu.net; Thu, 1 May 2003 15:32: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 QQomvm03888 for ; Thu, 1 May 2003 19:30:35 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 QQomvl06207 for ; Thu, 1 May 2003 19:28: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 QQomvl07453 for ; Thu, 1 May 2003 19:28:28 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 QQomvl07382 for ; Thu, 1 May 2003 19:28:25 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02613; Thu, 1 May 2003 15:25:15 -0400 (EDT) Message-Id: <200305011925.PAA02613@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-10.txt Date: Thu, 01 May 2003 15:25:15 -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-10.txt Pages : 132 Date : 2003-5-1 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-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-ldp-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-ldp-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-5-1153617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153617.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Sat May 3 19:31: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 TAA11571 for ; Sat, 3 May 2003 19:30: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 QQomzs14743 for ; Fri, 2 May 2003 23:03: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 QQomzs14383; Fri, 2 May 2003 23:03:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQomzq18216 for mpls-outgoing; Fri, 2 May 2003 22:34: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 QQomzq18208 for ; Fri, 2 May 2003 22:34:55 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 QQomzq09974 for ; Fri, 2 May 2003 22:34: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 QQomzq26555 for ; Fri, 2 May 2003 22:34:08 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 QQomzq26544 for ; Fri, 2 May 2003 22:34:07 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h42MY4WS005128 for ; Fri, 2 May 2003 18:34:05 -0400 (EDT) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA11047 for ; Fri, 2 May 2003 18:34:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h42MY4t22212 for mpls@uu.net; Fri, 2 May 2003 18:34: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 QQomzq18164 for ; Fri, 2 May 2003 22:33:03 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 QQomzq01160 for ; Fri, 2 May 2003 22:32:56 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 QQomzq24762 for ; Fri, 2 May 2003 22:32:55 GMT Received: from yikowyk by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [212.253.129.11]) id QQomzq24711 for ; Fri, 2 May 2003 22:32:53 GMT Message-Id: From: Dalias Braddock To: Subject: It's like a 4 feet antenna mn Date: Fri, 02 May 2003 14:34:16 -0700 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD48dGl0bGU+d2pnanM8L3RpdGxlPjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IiNGRkZGRkYiPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCjxwPjxhIGhyZWY9Imh0dHA6 Ly93d3cubXBsc0B2bGluZy1idXkuY29tL2NsZWFyZGVidC9ydC5waHA/cmQ9MTMmYWZmaWQ9 MTAwMCZlPW1wbHNAdXUubmV0Ij48aW1nIHNyYz0iaHR0cDovLzY2LjE1MS41OS4xNTMvb25s b2FkL2NjLmpwZyIgd2lkdGg9NDY4IGhlaWdodD0zNDAgYm9yZGVyPTA+PC9hPg0KPHA+PGEg aHJlZj0iaHR0cDovL3d3dy5tcGxzQHZsaW5nLWJ1eS5jb20vZGVidC9yZW1vdmUuaHRtbCI+ PGltZyBzcmM9Imh0dHA6Ly82Ni4xNTEuNTkuMTUzL29ubG9hZC9yZS5naWYiIGJvcmRlcj0w IHdpZHRoPTIwOSBoZWlnaHQ9MjA+PC9hPjxicj4NCjxwPiZuYnNwOzwvcD4NCjxwPiZuYnNw OzwvcD4NCjxmb250IGZhY2U9VmVyZGFuYSBzaXplPTE+ImBIZXJlIEkgYW0sIGJyYWluIHRo ZSBzaXplIG9mIGEgcGxhbmV0IGFuZCB0aGV5IGFzayBtZSB0byB0YWtlIHlvdSBkb3duIHRv IHRoZSBicmlkZ2UuIENhbGwgdGhhdCAiam9iIHNhdGlzZmFjdGlvbiI/ICdDb3MgSSBkb24n dC4nIjwvZm9udD4NCjwvZm9udD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K From owner-mpls@UU.NET Tue May 6 17:51: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 RAA10267 for ; Tue, 6 May 2003 17:51: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 QQonoh07156 for ; Tue, 6 May 2003 21:54: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 QQonoh06669; Tue, 6 May 2003 21:54:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQonoe21156 for mpls-outgoing; Tue, 6 May 2003 21:12:36 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 QQonoe21150 for ; Tue, 6 May 2003 21:12:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQonoe26856 for ; Tue, 6 May 2003 21:11: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 QQonoe04066 for ; Tue, 6 May 2003 21:11:58 GMT Received: from mailc.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailc.telia.com [194.22.190.4]) id QQonoe04039 for ; Tue, 6 May 2003 21:11:57 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailc.telia.com (8.12.9/8.12.9) with ESMTP id h46LBji6000756; Tue, 6 May 2003 23:11:45 +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 h46LBft01081; Tue, 6 May 2003 23:11:41 +0200 (CEST) Message-ID: <3EB8244F.3030702@pi.se> Date: Tue, 06 May 2003 23:08:31 +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: "Wijnen, Bert (Bert)" CC: Adrian Farrel , "'mpls@uu.net'" , George Swallow , zinin@psg.com Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt References: <7D5D48D2CAA3D84C813F5B154F43B155017C0CC1@nl0006exch001u.nl.lucent.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 All, I beg to differ - normally at least I keep quite if I don't have any comments, so I regard "no comments" as good news. However since our AD has this opinion I would like to invite also positive comments and support. I recall that I did so once before, (and at that time got good suport) but never mind... Show your habd once more. /Loa Wijnen, Bert (Bert) wrote: > I assume many people will already know that "we did NOT see ANY comments" > is in my view BAD news. We would like people to express that they > read the doc, understood it and find it good and usefull stuff. > > Silence might also mean "nobody gives a shoot" and so that in my view > then translates in "we're wasting cycles, bits, paper... etc" > > Sorry for my rant. > Bert > > >>-----Original Message----- >>From: Adrian Farrel [mailto:afarrel@movaz.com] >>Sent: maandag 28 april 2003 15:06 >>To: 'mpls@uu.net' >>Cc: George Swallow; Loa Andersson; Wijnen, Bert (Bert); zinin@psg.com >>Subject: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt >> >> >>Hi, >>I didn't see any comments on this draft during the last call >>period. Can we move >>it along now please? >> >>Thanks, >>Adrian >> >> >>>This message begins an MPLS Workgroup last call on >>> >>> Applicability Statement for Restart Mechanisms for LDP >>> draft-ietf-mpls-ldp-restart-applic-00.txt >>> >>>The last call closes 4/14 24:00 GMT. >>> >>>...George >> >> >> > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Tue May 6 18: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 SAA13038 for ; Tue, 6 May 2003 18:47: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 QQonol25020 for ; Tue, 6 May 2003 22:50: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 QQonol24650; Tue, 6 May 2003 22:50:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQonoh24685 for mpls-outgoing; Tue, 6 May 2003 21:57: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 QQonoh24655 for ; Tue, 6 May 2003 21:56:45 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 QQonoh13867 for ; Tue, 6 May 2003 21:55:46 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 QQonoh17966 for ; Tue, 6 May 2003 21:55:46 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQonoh17919 for ; Tue, 6 May 2003 21:55:44 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 6 May 2003 14:55:41 -0700 Message-ID: <6B44697BBC676B4F91546F829A472B8A384ECC@po1.vivacenetworks.com> Thread-Topic: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt Thread-Index: AcMUFS3XbspucD1jTUOlHKny/ZM+UAABNCiF From: "Andy Malis" To: "Loa Andersson" , "Wijnen, Bert (Bert)" Cc: "Adrian Farrel" , "mpls@uu.net" , "George Swallow" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA13038 It shouldn't be necessary (since this has already been discussed), but for the record, I reiterate supporting the current contents of this draft. Thanks, Andy -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Tue 5/6/2003 5:08 PM To: Wijnen, Bert (Bert) Cc: Adrian Farrel; 'mpls@uu.net'; George Swallow; zinin@psg.com Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt All, I beg to differ - normally at least I keep quite if I don't have any comments, so I regard "no comments" as good news. However since our AD has this opinion I would like to invite also positive comments and support. I recall that I did so once before, (and at that time got good suport) but never mind... Show your habd once more. /Loa Wijnen, Bert (Bert) wrote: > I assume many people will already know that "we did NOT see ANY comments" > is in my view BAD news. We would like people to express that they > read the doc, understood it and find it good and usefull stuff. > > Silence might also mean "nobody gives a shoot" and so that in my view > then translates in "we're wasting cycles, bits, paper... etc" > > Sorry for my rant. > Bert > > >>-----Original Message----- >>From: Adrian Farrel [mailto:afarrel@movaz.com] >>Sent: maandag 28 april 2003 15:06 >>To: 'mpls@uu.net' >>Cc: George Swallow; Loa Andersson; Wijnen, Bert (Bert); zinin@psg.com >>Subject: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt >> >> >>Hi, >>I didn't see any comments on this draft during the last call >>period. Can we move >>it along now please? >> >>Thanks, >>Adrian >> >> >>>This message begins an MPLS Workgroup last call on >>> >>> Applicability Statement for Restart Mechanisms for LDP >>> draft-ietf-mpls-ldp-restart-applic-00.txt >>> >>>The last call closes 4/14 24:00 GMT. >>> >>>...George >> >> >> > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Tue May 6 19:53: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 TAA14537 for ; Tue, 6 May 2003 19:53: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 QQonop24414 for ; Tue, 6 May 2003 23:56: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 QQonop23923; Tue, 6 May 2003 23:56:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQonon07173 for mpls-outgoing; Tue, 6 May 2003 23:22:36 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 QQonon07168 for ; Tue, 6 May 2003 23:22:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQonon24672 for ; Tue, 6 May 2003 23:22: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 QQonon26075 for ; Tue, 6 May 2003 23:22:17 GMT Received: from psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: psg.com [147.28.0.62]) id QQonon26052 for ; Tue, 6 May 2003 23:22:16 GMT Received: from dpapadimitriou by psg.com with local (Exim 3.36 #1) id 19DBlB-000CKP-00; Tue, 06 May 2003 23:22:09 +0000 Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt To: loa@pi.se (Loa Andersson) Date: Tue, 6 May 2003 23:22:09 +0000 (GMT) Cc: bwijnen@lucent.com ("Wijnen, Bert (Bert)"), afarrel@movaz.com (Adrian Farrel), mpls@UU.NET ('mpls@uu.net'), swallow@cisco.com (George Swallow), zinin@psg.com In-Reply-To: <3EB8244F.3030702@pi.se> from "Loa Andersson" at May 06, 2003 11:08:31 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit loa, all, except updating the references (*) there are imho no issues w/ this document, it covers all aspects of the subject & knowing that keeping people "on hold" may also generate cycle wasting (adrian spends a lot of efforts in helping this community), i think this i-d should now follow its way (*) part of the ietf last process imho (also reduce the length of the abstract might be part of other editorial comments here) ps: loa what "habd" means here ? thanks, - dimitri. > > All, > > I beg to differ - normally at least I keep quite if I don't have any > comments, so I regard "no comments" as good news. > > However since our AD has this opinion I would like to invite also > positive comments and support. I recall that I did so once before, > (and at that time got good suport) but never mind... > > Show your habd once more. > > /Loa > > Wijnen, Bert (Bert) wrote: > > I assume many people will already know that "we did NOT see ANY comments" > > is in my view BAD news. We would like people to express that they > > read the doc, understood it and find it good and usefull stuff. > > > > Silence might also mean "nobody gives a shoot" and so that in my view > > then translates in "we're wasting cycles, bits, paper... etc" > > > > Sorry for my rant. > > Bert > > > > > >>-----Original Message----- > >>From: Adrian Farrel [mailto:afarrel@movaz.com] > >>Sent: maandag 28 april 2003 15:06 > >>To: 'mpls@uu.net' > >>Cc: George Swallow; Loa Andersson; Wijnen, Bert (Bert); zinin@psg.com > >>Subject: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt > >> > >> > >>Hi, > >>I didn't see any comments on this draft during the last call > >>period. Can we move > >>it along now please? > >> > >>Thanks, > >>Adrian > >> > >> > >>>This message begins an MPLS Workgroup last call on > >>> > >>> Applicability Statement for Restart Mechanisms for LDP > >>> draft-ietf-mpls-ldp-restart-applic-00.txt > >>> > >>>The last call closes 4/14 24:00 GMT. > >>> > >>>...George > >> > >> > >> > > > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > > From owner-mpls@UU.NET Tue May 6 23:05: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 XAA18640 for ; Tue, 6 May 2003 23:05: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 QQonpc25851 for ; Wed, 7 May 2003 03:08:55 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 QQonpc25545; Wed, 7 May 2003 03:08:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQonpa16706 for mpls-outgoing; Wed, 7 May 2003 02:31: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 QQonpa16701 for ; Wed, 7 May 2003 02:31: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 QQonpa02221 for ; Wed, 7 May 2003 02:30: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 QQonpa17910 for ; Wed, 7 May 2003 02:30:47 GMT Received: from usilms55.ca.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail9.ca.com [141.202.248.42]) id QQonpa17896 for ; Wed, 7 May 2003 02:30:46 GMT Received: from usilms53.ca.com ([141.202.248.39]) by usilms55.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 May 2003 22:25:21 -0400 Received: from mail pickup service by usilms53.ca.com with Microsoft SMTPSVC; Tue, 6 May 2003 22:25:21 -0400 Received: from usilms44.ca.com ([141.202.248.115]) by usilms54.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 May 2003 17:17:03 -0400 Received: from cmr2.ash.ops.us.uu.net (198.5.241.40) by usilms44.ca.com (141.202.248.115) 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 QQonof11690 for ; Tue, 6 May 2003 21:17: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 QQonof10870; Tue, 6 May 2003 21:16:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQonoe21156 for mpls-outgoing; Tue, 6 May 2003 21:12:36 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 QQonoe21150 for ; Tue, 6 May 2003 21:12:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQonoe26856 for ; Tue, 6 May 2003 21:11: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 QQonoe04066 for ; Tue, 6 May 2003 21:11:58 GMT Received: from mailc.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailc.telia.com [194.22.190.4]) id QQonoe04039 for ; Tue, 6 May 2003 21:11:57 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailc.telia.com (8.12.9/8.12.9) with ESMTP id h46LBji6000756; Tue, 6 May 2003 23:11:45 +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 h46LBft01081; Tue, 6 May 2003 23:11:41 +0200 (CEST) Message-ID: <3EB8244F.3030702@pi.se> Date: Tue, 06 May 2003 23:08:31 +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: "Wijnen, Bert (Bert)" CC: Adrian Farrel , "'mpls@uu.net'" , George Swallow , zinin@psg.com Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt References: <7D5D48D2CAA3D84C813F5B154F43B155017C0CC1@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2003 21:17:03.0935 (UTC) FILETIME=[D73A9CF0:01C31414] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I beg to differ - normally at least I keep quite if I don't have any comments, so I regard "no comments" as good news. However since our AD has this opinion I would like to invite also positive comments and support. I recall that I did so once before, (and at that time got good suport) but never mind... Show your habd once more. /Loa Wijnen, Bert (Bert) wrote: > I assume many people will already know that "we did NOT see ANY comments" > is in my view BAD news. We would like people to express that they > read the doc, understood it and find it good and usefull stuff. > > Silence might also mean "nobody gives a shoot" and so that in my view > then translates in "we're wasting cycles, bits, paper... etc" > > Sorry for my rant. > Bert > > >>-----Original Message----- >>From: Adrian Farrel [mailto:afarrel@movaz.com] >>Sent: maandag 28 april 2003 15:06 >>To: 'mpls@uu.net' >>Cc: George Swallow; Loa Andersson; Wijnen, Bert (Bert); zinin@psg.com >>Subject: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt >> >> >>Hi, >>I didn't see any comments on this draft during the last call >>period. Can we move >>it along now please? >> >>Thanks, >>Adrian >> >> >>>This message begins an MPLS Workgroup last call on >>> >>> Applicability Statement for Restart Mechanisms for LDP >>> draft-ietf-mpls-ldp-restart-applic-00.txt >>> >>>The last call closes 4/14 24:00 GMT. >>> >>>...George >> >> >> > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Tue May 6 23:42: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 XAA19220 for ; Tue, 6 May 2003 23:42: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 QQonpf19057 for ; Wed, 7 May 2003 03:45: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 QQonpf18840; Wed, 7 May 2003 03:45:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQonpc07542 for mpls-outgoing; Wed, 7 May 2003 03:08:23 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 QQonpc07528 for ; Wed, 7 May 2003 03:08:20 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 QQonpc02479 for ; Wed, 7 May 2003 03:05: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 QQonpc20325 for ; Wed, 7 May 2003 03:05:31 GMT Received: from uslims56.ca.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail3.ca.com [208.232.182.10]) id QQonpc20311 for ; Wed, 7 May 2003 03:05:31 GMT Received: from usilms53.ca.com ([141.202.248.39]) by uslims56.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 May 2003 21:31:37 -0500 Received: from mail pickup service by usilms53.ca.com with Microsoft SMTPSVC; Tue, 6 May 2003 22:31:34 -0400 Received: from usilms44.ca.com ([141.202.248.115]) by usilms54.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 May 2003 18:07:34 -0400 Received: from cmr2.ash.ops.us.uu.net (198.5.241.40) by usilms44.ca.com (141.202.248.115) 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 QQonoi26102 for ; Tue, 6 May 2003 22:07: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 QQonoi25683; Tue, 6 May 2003 22:07:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQonoh24685 for mpls-outgoing; Tue, 6 May 2003 21:57: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 QQonoh24655 for ; Tue, 6 May 2003 21:56:45 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 QQonoh13867 for ; Tue, 6 May 2003 21:55:46 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 QQonoh17966 for ; Tue, 6 May 2003 21:55:46 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQonoh17919 for ; Tue, 6 May 2003 21:55:44 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 6 May 2003 14:55:41 -0700 Message-ID: <6B44697BBC676B4F91546F829A472B8A384ECC@po1.vivacenetworks.com> Thread-Topic: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt Thread-Index: AcMUFS3XbspucD1jTUOlHKny/ZM+UAABNCiF From: "Andy Malis" To: "Loa Andersson" , "Wijnen, Bert (Bert)" Cc: "Adrian Farrel" , "mpls@uu.net" , "George Swallow" , X-OriginalArrivalTime: 06 May 2003 22:07:34.0968 (UTC) FILETIME=[E5DD8B80:01C3141B] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA19220 It shouldn't be necessary (since this has already been discussed), but for the record, I reiterate supporting the current contents of this draft. Thanks, Andy -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Tue 5/6/2003 5:08 PM To: Wijnen, Bert (Bert) Cc: Adrian Farrel; 'mpls@uu.net'; George Swallow; zinin@psg.com Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt All, I beg to differ - normally at least I keep quite if I don't have any comments, so I regard "no comments" as good news. However since our AD has this opinion I would like to invite also positive comments and support. I recall that I did so once before, (and at that time got good suport) but never mind... Show your habd once more. /Loa Wijnen, Bert (Bert) wrote: > I assume many people will already know that "we did NOT see ANY comments" > is in my view BAD news. We would like people to express that they > read the doc, understood it and find it good and usefull stuff. > > Silence might also mean "nobody gives a shoot" and so that in my view > then translates in "we're wasting cycles, bits, paper... etc" > > Sorry for my rant. > Bert > > >>-----Original Message----- >>From: Adrian Farrel [mailto:afarrel@movaz.com] >>Sent: maandag 28 april 2003 15:06 >>To: 'mpls@uu.net' >>Cc: George Swallow; Loa Andersson; Wijnen, Bert (Bert); zinin@psg.com >>Subject: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt >> >> >>Hi, >>I didn't see any comments on this draft during the last call >>period. Can we move >>it along now please? >> >>Thanks, >>Adrian >> >> >>>This message begins an MPLS Workgroup last call on >>> >>> Applicability Statement for Restart Mechanisms for LDP >>> draft-ietf-mpls-ldp-restart-applic-00.txt >>> >>>The last call closes 4/14 24:00 GMT. >>> >>>...George >> >> >> > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Wed May 7 09:15:37 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 JAA29426 for ; Wed, 7 May 2003 09:15: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 QQonqr10960 for ; Wed, 7 May 2003 13:18: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 QQonqr10718; Wed, 7 May 2003 13:18:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQonqo05510 for mpls-outgoing; Wed, 7 May 2003 12:36:13 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 QQonqo05313 for ; Wed, 7 May 2003 12:35:52 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 QQonqo04150 for ; Wed, 7 May 2003 12:35: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 QQonqo22459 for ; Wed, 7 May 2003 12:35:16 GMT Received: from lightwave.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQonqo22435 for ; Wed, 7 May 2003 12:35:15 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 05:34:56 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97250A@nimbus> From: John Drake To: "'Loa Andersson'" , "Wijnen, Bert (Bert)" Cc: Adrian Farrel , "'mpls@uu.net'" , George Swallow , zinin@psg.com Subject: RE: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt Date: Wed, 7 May 2003 05:34:56 -0700 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 Bert, How many times do you want us to raise our hands? Isn't redundant e-mail a waste of resources? John > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Tuesday, May 06, 2003 2:09 PM > To: Wijnen, Bert (Bert) > Cc: Adrian Farrel; 'mpls@uu.net'; George Swallow; zinin@psg.com > Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt > > > All, > > I beg to differ - normally at least I keep quite if I don't have any > comments, so I regard "no comments" as good news. > > However since our AD has this opinion I would like to invite also > positive comments and support. I recall that I did so once before, > (and at that time got good suport) but never mind... > > Show your habd once more. > > /Loa > > Wijnen, Bert (Bert) wrote: > > I assume many people will already know that "we did NOT see > ANY comments" > > is in my view BAD news. We would like people to express that they > > read the doc, understood it and find it good and usefull stuff. > > > > Silence might also mean "nobody gives a shoot" and so that > in my view > > then translates in "we're wasting cycles, bits, paper... etc" > > > > Sorry for my rant. > > Bert > > > > > >>-----Original Message----- > >>From: Adrian Farrel [mailto:afarrel@movaz.com] > >>Sent: maandag 28 april 2003 15:06 > >>To: 'mpls@uu.net' > >>Cc: George Swallow; Loa Andersson; Wijnen, Bert (Bert); > zinin@psg.com > >>Subject: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt > >> > >> > >>Hi, > >>I didn't see any comments on this draft during the last call > >>period. Can we move > >>it along now please? > >> > >>Thanks, > >>Adrian > >> > >> > >>>This message begins an MPLS Workgroup last call on > >>> > >>> Applicability Statement for Restart Mechanisms for LDP > >>> draft-ietf-mpls-ldp-restart-applic-00.txt > >>> > >>>The last call closes 4/14 24:00 GMT. > >>> > >>>...George > >> > >> > >> > > > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > From owner-mpls@UU.NET Wed May 7 09:23: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 JAA29643 for ; Wed, 7 May 2003 09:23: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 QQonqr29825 for ; Wed, 7 May 2003 13:26: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 QQonqr29769; Wed, 7 May 2003 13:26:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQonqp06586 for mpls-outgoing; Wed, 7 May 2003 12:47: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 QQonqp06579 for ; Wed, 7 May 2003 12:47: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 QQonqp17878 for ; Wed, 7 May 2003 12:47: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 QQonqp11210 for ; Wed, 7 May 2003 12:47:02 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 QQonqp11189 for ; Wed, 7 May 2003 12:47:01 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.6/Switch-2.2.0) with ESMTP id h47Ckxu24317 for ; Wed, 7 May 2003 08:47:00 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R190B7W>; Wed, 7 May 2003 14:46:58 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B883F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: John Drake , "'Loa Andersson'" Cc: Adrian Farrel , "'mpls@uu.net'" , George Swallow , zinin@psg.com Subject: RE: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt Date: Wed, 7 May 2003 14:46:55 +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 think the WG chairs have in the meantime explained that they had gotten a lot of positive comments onb this doc in a previous WG Last Call or such. That I probably have missed. I have reacted to "we did NOT see ANY comments". Whcih as I explained is NO good. If it had been something aka: "we had a lot of positive comments the previous WG Last Call. But then some issues were raised that have been addressed, and since no one has objected to the resolution of those issues, we think we have WG concensus." Then that would have been much better for me to parse. Now... I am not your primary AD. And so I do not always follow this list as closely as the WG lists for which I AM the primary AD. Not sure if Alex was reading it closely in the past before he became primary AD. If he is happy with the review that has taken place, then fine. Thanks, Bert > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: woensdag 7 mei 2003 14:35 > To: 'Loa Andersson'; Wijnen, Bert (Bert) > Cc: Adrian Farrel; 'mpls@uu.net'; George Swallow; zinin@psg.com > Subject: RE: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt > > > Bert, > > How many times do you want us to raise our hands? Isn't > redundant e-mail a > waste of resources? > > John > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.se] > > Sent: Tuesday, May 06, 2003 2:09 PM > > To: Wijnen, Bert (Bert) > > Cc: Adrian Farrel; 'mpls@uu.net'; George Swallow; zinin@psg.com > > Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt > > > > > > All, > > > > I beg to differ - normally at least I keep quite if I don't have any > > comments, so I regard "no comments" as good news. > > > > However since our AD has this opinion I would like to invite also > > positive comments and support. I recall that I did so once before, > > (and at that time got good suport) but never mind... > > > > Show your habd once more. > > > > /Loa > > > > Wijnen, Bert (Bert) wrote: > > > I assume many people will already know that "we did NOT see > > ANY comments" > > > is in my view BAD news. We would like people to express that they > > > read the doc, understood it and find it good and usefull stuff. > > > > > > Silence might also mean "nobody gives a shoot" and so that > > in my view > > > then translates in "we're wasting cycles, bits, paper... etc" > > > > > > Sorry for my rant. > > > Bert > > > > > > > > >>-----Original Message----- > > >>From: Adrian Farrel [mailto:afarrel@movaz.com] > > >>Sent: maandag 28 april 2003 15:06 > > >>To: 'mpls@uu.net' > > >>Cc: George Swallow; Loa Andersson; Wijnen, Bert (Bert); > > zinin@psg.com > > >>Subject: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt > > >> > > >> > > >>Hi, > > >>I didn't see any comments on this draft during the last call > > >>period. Can we move > > >>it along now please? > > >> > > >>Thanks, > > >>Adrian > > >> > > >> > > >>>This message begins an MPLS Workgroup last call on > > >>> > > >>> Applicability Statement for Restart Mechanisms for LDP > > >>> draft-ietf-mpls-ldp-restart-applic-00.txt > > >>> > > >>>The last call closes 4/14 24:00 GMT. > > >>> > > >>>...George > > >> > > >> > > >> > > > > > > > > > > > > -- > > /Loa > > > > mobile + 46 739 81 21 64 > > email: loa@pi.se > > > From owner-mpls@UU.NET Wed May 7 10:40: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 KAA04244 for ; Wed, 7 May 2003 10:40: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 QQonqw28864 for ; Wed, 7 May 2003 14:43: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 QQonqw28420; Wed, 7 May 2003 14:43:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQonqu18457 for mpls-outgoing; Wed, 7 May 2003 14:06:57 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 QQonqu18441 for ; Wed, 7 May 2003 14:06:42 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 QQonqu19390 for ; Wed, 7 May 2003 14:06: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 QQonqu19431 for ; Wed, 7 May 2003 14:06:28 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 QQonqu19136 for ; Wed, 7 May 2003 14:06:23 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with ESMTP id 684901415; Wed, 7 May 2003 10:06:02 -0400 (EDT) Message-ID: <015001c314a1$d4e9fb20$681810ac@movaz.com> From: "Adrian Farrel" To: "Loa Andersson" , "Wijnen, Bert (Bert)" Cc: "'mpls@uu.net'" , "George Swallow" , References: <7D5D48D2CAA3D84C813F5B154F43B155017C0CC1@nl0006exch001u.nl.lucent.com> <3EB8244F.3030702@pi.se> Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt Date: Wed, 7 May 2003 10:06:18 -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 > Show your habd once more. My habd is up. (Actually both of my habds are up!) Adrian From owner-mpls@UU.NET Wed May 7 12:34:26 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 MAA07684 for ; Wed, 7 May 2003 12:34: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 QQonre17464 for ; Wed, 7 May 2003 16:37: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 QQonre17405; Wed, 7 May 2003 16:37:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQonrc26627 for mpls-outgoing; Wed, 7 May 2003 16:02: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 QQonrc26610 for ; Wed, 7 May 2003 16:02:46 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 QQonrc16491 for ; Wed, 7 May 2003 16:02: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 QQonrc25425 for ; Wed, 7 May 2003 16:02:30 GMT Received: from grouse.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: grouse.mail.pas.earthlink.net [207.217.120.116]) id QQonrc25391 for ; Wed, 7 May 2003 16:02:29 GMT Received: from user-2ivfk2k.dialup.mindspring.com ([165.247.208.84] helo=earthlink.net) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19DRN0-0003Jq-00; Wed, 07 May 2003 09:02:14 -0700 Message-ID: <3EB92E2A.F542217C@earthlink.net> Date: Wed, 07 May 2003 09:02:50 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: "IETF-Announce:;"@earthlink.net, mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-dod-restart-00.txt References: <200304211131.HAA09802@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Suggestion / comment, Should the title expand "DoD" or should "DoD" be specified at the end of the Abstract? Thanks, Mitchell Erblich ----------------- Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : LDP DoD Graceful Restart > Author(s) : B. Thomas, A. Raj > Filename : draft-ietf-mpls-ldp-dod-restart-00.txt > Pages : 18 > Date : 2003-4-18 > > LDP graceful restart is a mechanism that helps reduce the negative > effects on MPLS traffic caused by the restart of a Label Switching > Router's (LSR's) control plane, specifically by the restart of its > Label Distribution Protocol (LDP) component [RFC3036], on LSRs that > are capable of preserving MPLS forwarding state across the restart. > [RFC3478] defines procedures for LDP graceful restart for downstream > unsolicited label distribution but leaves procedures for downstream > on demand label distribution a subject for future study. This > document defines graceful restart procedures for downstream on demand > label distribution. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.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-dod-restart-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <2003-4-18131820.I-D@ietf.org> From owner-mpls@UU.NET Wed May 7 15:40:26 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 PAA14948 for ; Wed, 7 May 2003 15:40: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 QQonrq18104 for ; Wed, 7 May 2003 19:43:24 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 QQonrq17794; Wed, 7 May 2003 19:43:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQonro13122 for mpls-outgoing; Wed, 7 May 2003 19:05: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 QQonro13072 for ; Wed, 7 May 2003 19:04: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 QQonro06972 for ; Wed, 7 May 2003 19:04: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 QQonro26738 for ; Wed, 7 May 2003 19:04:16 GMT Received: from prattle.redback.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prattle.redback.com [155.53.12.9]) id QQonro26722 for ; Wed, 7 May 2003 19:04:15 GMT Received: from u43 (u43.redback.com [155.53.8.143]) by prattle.redback.com (Postfix) with ESMTP id A5062B7446 for ; Wed, 7 May 2003 12:04:14 -0700 (PDT) Date: Wed, 7 May 2003 12:04:14 -0700 (PDT) From: Rahul Aggarwal X-Sender: rahul@u43 To: mpls@UU.NET Subject: New draft on establishing P2MP MPLS TE LSPs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk FYI: We just posted a draft that describes a mechanism for setting up P2MP MPLS TE LSPs. The URL is: http://www.ietf.org/internet-drafts/draft-raggarwa-mpls-p2mp-te-00.txt Comments are very much welcome. Thanks, rahul From owner-mpls@UU.NET Wed May 7 18:07: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 SAA19807 for ; Wed, 7 May 2003 18:07: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 QQonsa09953 for ; Wed, 7 May 2003 22:10: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 QQonsa05248; Wed, 7 May 2003 22:08:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQonrw21271 for mpls-outgoing; Wed, 7 May 2003 21:02: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 QQonrw21266 for ; Wed, 7 May 2003 21: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 QQonrw28342 for ; Wed, 7 May 2003 21:01:35 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 QQonrw17753 for ; Wed, 7 May 2003 21:01:33 GMT Received: from maile.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maile.telia.com [194.22.190.16]) id QQonrw17716 for ; Wed, 7 May 2003 21:01:32 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 h47L1UvC021152; Wed, 7 May 2003 23:01:30 +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 h47L1Ut02405; Wed, 7 May 2003 23:01:30 +0200 (CEST) Message-ID: <3EB9736E.9000308@pi.se> Date: Wed, 07 May 2003 22:58:22 +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: Adrian Farrel CC: "'mpls@uu.net'" Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt References: <7D5D48D2CAA3D84C813F5B154F43B155017C0CC1@nl0006exch001u.nl.lucent.com> <3EB8244F.3030702@pi.se> <015001c314a1$d4e9fb20$681810ac@movaz.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 Adrian, bad spelling is not a requirement to be a wg chair, but sometimes it makes the wg more merry :) /Loa Adrian Farrel wrote: >>Show your habd once more. > > > My habd is up. > > (Actually both of my habds are up!) > > Adrian > > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Wed May 7 18:13: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 SAA20308 for ; Wed, 7 May 2003 18:13:22 -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 QQonsb22347 for ; Wed, 7 May 2003 22:16: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 QQonsa18417; Wed, 7 May 2003 22:14:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQonrw29143 for mpls-outgoing; Wed, 7 May 2003 21:06:27 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 QQonrw29138 for ; Wed, 7 May 2003 21:06:22 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 QQonrw15788 for ; Wed, 7 May 2003 21:06: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 QQonrw27107 for ; Wed, 7 May 2003 21:06: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 QQonrw27075 for ; Wed, 7 May 2003 21:06:08 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h47L67QP025550 for ; Wed, 7 May 2003 17:06: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 RAA09757 for ; Wed, 7 May 2003 17:06:07 -0400 (EDT) From: Eric Rosen Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h47L66705259 for mpls@uu.net; Wed, 7 May 2003 17:06:06 -0400 (EDT) Date: Wed, 7 May 2003 17:06:06 -0400 (EDT) Message-Id: <200305072106.h47L66705259@erosen-u10.cisco.com> To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Wed May 7 18:28: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 SAA21024 for ; Wed, 7 May 2003 18:28: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 QQonsc19352 for ; Wed, 7 May 2003 22:31: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 QQonsb16893; Wed, 7 May 2003 22:29:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQonry02082 for mpls-outgoing; Wed, 7 May 2003 21:40:33 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 QQonry02060 for ; Wed, 7 May 2003 21:40:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQonry09725 for ; Wed, 7 May 2003 21:39: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 QQonry10694 for ; Wed, 7 May 2003 21:39:33 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 QQonry10658 for ; Wed, 7 May 2003 21:39:33 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 h47LdWu33762; Wed, 7 May 2003 14:39:32 -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 h47LdW343602; Wed, 7 May 2003 14:39:32 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 7 May 2003 14:39:32 -0700 (PDT) From: Kireeti Kompella To: Adrian Farrel cc: mpls@UU.NET Subject: Re: Last call : draft-ietf-mpls-ldp-restart-applic-00.txt In-Reply-To: <015001c314a1$d4e9fb20$681810ac@movaz.com> Message-ID: <20030507142905.B43482@kummer.juniper.net> References: <7D5D48D2CAA3D84C813F5B154F43B155017C0CC1@nl0006exch001u.nl.lucent.com> <3EB8244F.3030702@pi.se> <015001c314a1$d4e9fb20$681810ac@movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > > Show your habd once more. > > My habd is up. > > (Actually both of my habds are up!) Adrian: beed a Kleebex? Dimitri: find N on your keyboard; look left. Kireeti. From owner-mpls@UU.NET Thu May 8 06:30: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 GAA19080 for ; Thu, 8 May 2003 06:30:15 -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 QQonty25885 for ; Thu, 8 May 2003 10:33: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 QQonty25548; Thu, 8 May 2003 10:33:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQontv07816 for mpls-outgoing; Thu, 8 May 2003 09:59:27 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 QQontv07809 for ; Thu, 8 May 2003 09:59:09 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 QQontv07411 for ; Thu, 8 May 2003 09:58:39 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 QQontv05340 for ; Thu, 8 May 2003 09:58:38 GMT Received: from mailc.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailc.telia.com [194.22.190.4]) id QQontv05322 for ; Thu, 8 May 2003 09:58:37 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailc.telia.com (8.12.9/8.12.9) with ESMTP id h489wTN1004677; Thu, 8 May 2003 11:58:29 +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 h489wTt08395; Thu, 8 May 2003 11:58:29 +0200 (CEST) Message-ID: <3EBA2989.4020404@pi.se> Date: Thu, 08 May 2003 11:55:21 +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: Erblichs , mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-dod-restart-00.txt References: <200304211131.HAA09802@ietf.org> <3EB92E2A.F542217C@earthlink.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 Erblich, those are the things that wg chairs are supposed to do when we start preparing the draft for iesg-review, it does not hurt if authors do so early, but we will catch if it is not done. Short answer: Yes, it should be expanded in title and if used in abstract, an a specification in the abstract won't let you need /Loa Erblichs wrote: > Suggestion / comment, > > Should the title expand "DoD" or should "DoD" be specified > at the end of the Abstract? > > Thanks, > Mitchell Erblich > ----------------- > > Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. >> >> Title : LDP DoD Graceful Restart >> Author(s) : B. Thomas, A. Raj >> Filename : draft-ietf-mpls-ldp-dod-restart-00.txt >> Pages : 18 >> Date : 2003-4-18 >> >>LDP graceful restart is a mechanism that helps reduce the negative >>effects on MPLS traffic caused by the restart of a Label Switching >>Router's (LSR's) control plane, specifically by the restart of its >>Label Distribution Protocol (LDP) component [RFC3036], on LSRs that >>are capable of preserving MPLS forwarding state across the restart. >>[RFC3478] defines procedures for LDP graceful restart for downstream >>unsolicited label distribution but leaves procedures for downstream >>on demand label distribution a subject for future study. This >>document defines graceful restart procedures for downstream on demand >>label distribution. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.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-dod-restart-00.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >> ------------------------------------------------------------------------ >>Content-Type: text/plain >>Content-ID: <2003-4-18131820.I-D@ietf.org> > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Thu May 8 07:29: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 HAA19941 for ; Thu, 8 May 2003 07:29: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 QQonuc13395 for ; Thu, 8 May 2003 11:32: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 QQonuc13045; Thu, 8 May 2003 11:31:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQontz00571 for mpls-outgoing; Thu, 8 May 2003 10:51: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 QQontz00566 for ; Thu, 8 May 2003 10:51:16 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 QQontz25132 for ; Thu, 8 May 2003 10:50: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 QQontz06912 for ; Thu, 8 May 2003 10:50:58 GMT Received: from web20713.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20713.mail.yahoo.com [66.163.169.154]) id QQontz06893 for ; Thu, 8 May 2003 10:50:57 GMT Message-ID: <20030508105057.26956.qmail@web20713.mail.yahoo.com> Received: from [210.118.108.254] by web20713.mail.yahoo.com via HTTP; Thu, 08 May 2003 11:50:57 BST Date: Thu, 8 May 2003 11:50:57 +0100 (BST) From: "=?iso-8859-1?q?Sugar,=20Sylvia?=" Subject: Role of CE routers in BGP MPLS/VPN Switching? 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 Hi, As per my understanding of 2547bis the BGP CE routers when connect to the BGP PE routers are unaware of anything and all the work needs to be done by the PE router i.e associating routes learnt from this CE BGP speaker with some VRF and then attaching some extended community attributes, etc and announcing to other PE routers (with the label obviously). Finally, when this PE router recieves routes from other PE BGP speakers then it checks which all routes need to be announced to this CE router (by examining the Route Target definitions) and does so. For this CE router this PE router is just another BGP speaking router which is giving it some BGP routes. Now when some data traffic comes from this CE router towards the PE router then it puts the BGP Label associated with the FEC which was advertised to this router by the remote PE router and also puts another IGP label and pushes the packet out. This packet gets switched based on the top-most IGP label. Upon reachiong the final router it will strip off the outermost label (or a router before this will do this), examine the BGP label and will know what this FEC this corresponds to. The idea is that the CE routers are unaware of anything happening .. its just the PE routers which maintain the VRFs, etc. and make the VPN work! Is my understanding correct? I would really appreciate if somebody could just confirm that! Regards, Sylvia __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From owner-mpls@UU.NET Thu May 8 08:27: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 IAA20851 for ; Thu, 8 May 2003 08:27: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 QQonug00833 for ; Thu, 8 May 2003 12:30: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 QQonug00389; Thu, 8 May 2003 12:30:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQonud23018 for mpls-outgoing; Thu, 8 May 2003 11:47: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 QQonud22999 for ; Thu, 8 May 2003 11:47: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 QQonud05709 for ; Thu, 8 May 2003 11:47: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 QQonud20488 for ; Thu, 8 May 2003 11:47:33 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 QQonud20475 for ; Thu, 8 May 2003 11:47:33 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h48Bl4V2029652 for ; Thu, 8 May 2003 07:47: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 HAA25237 for ; Thu, 8 May 2003 07:47:03 -0400 (EDT) From: Eric Rosen Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h48Bl3314268 for mpls@uu.net; Thu, 8 May 2003 07:47:03 -0400 (EDT) Date: Thu, 8 May 2003 07:47:03 -0400 (EDT) Message-Id: <200305081147.h48Bl3314268@erosen-u10.cisco.com> To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Thu May 8 08:47: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 IAA21318 for ; Thu, 8 May 2003 08:47: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 QQonuh20568 for ; Thu, 8 May 2003 12:50: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 QQonuh19893; Thu, 8 May 2003 12:50:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQonuf13751 for mpls-outgoing; Thu, 8 May 2003 12:17:54 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 QQonuf13746 for ; Thu, 8 May 2003 12:17:50 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 QQonuf10138 for ; Thu, 8 May 2003 12:16: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 QQonuf14113 for ; Thu, 8 May 2003 12:16:51 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 QQonuf14081 for ; Thu, 8 May 2003 12:16:37 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h48CGaqr026056 for ; Thu, 8 May 2003 08:16:37 -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 IAA26496 for ; Thu, 8 May 2003 08:13:03 -0400 (EDT) From: Eric Rosen Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h48CD3G15580 for mpls@uu.net; Thu, 8 May 2003 08:13:03 -0400 (EDT) Date: Thu, 8 May 2003 08:13:03 -0400 (EDT) Message-Id: <200305081213.h48CD3G15580@erosen-u10.cisco.com> To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Thu May 8 10:22: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 KAA24767 for ; Thu, 8 May 2003 10:22: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 QQonun01350 for ; Thu, 8 May 2003 14:25: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 QQonun00675; Thu, 8 May 2003 14:25:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQonul08731 for mpls-outgoing; Thu, 8 May 2003 13:45:23 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 QQonul08724 for ; Thu, 8 May 2003 13:45:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQonuk06101 for ; Thu, 8 May 2003 13:43: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 QQonuk10451 for ; Thu, 8 May 2003 13:43:49 GMT Received: from web41604.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web41604.mail.yahoo.com [66.218.93.104]) id QQonuk10427 for ; Thu, 8 May 2003 13:43:48 GMT Message-ID: <20030508134347.61577.qmail@web41604.mail.yahoo.com> Received: from [203.129.237.108] by web41604.mail.yahoo.com via HTTP; Thu, 08 May 2003 06:43:47 PDT Date: Thu, 8 May 2003 06:43:47 -0700 (PDT) From: bhuvan laddha Subject: RRO object To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I would appreciate clarification for the following point in the RFC: 3209: 1. Section 4.4.1.3 states - "The Length contains the total length of the subobject in bytes,including the Type and Length fields." Assume labels represents "set of time-slots".Now,if the set is large (e.g. 100 labels ),then Length of the subobject will be 404 and length field is just one byte and inadequate to carry this value (404) . I would appreciate if someone can indicate how the implemenation should handle this. Thanx, ---Bhuvan. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From owner-mpls@UU.NET Thu May 8 15:55: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 PAA07266 for ; Thu, 8 May 2003 15:55: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 QQonvg10495 for ; Thu, 8 May 2003 19:11: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 QQonvg09558; Thu, 8 May 2003 19:11:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQonvd29411 for mpls-outgoing; Thu, 8 May 2003 18:23:55 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 QQonvd29406 for ; Thu, 8 May 2003 18:23: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 QQonvd07344 for ; Thu, 8 May 2003 18:22:55 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 QQonvd25014 for ; Thu, 8 May 2003 18:22:54 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 QQonvd24995 for ; Thu, 8 May 2003 18:22:54 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h48IMru05402; Thu, 8 May 2003 11:22:53 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 8 May 2003 11:22:53 -0700 (PDT) From: Ina Minei To: bhuvan laddha cc: mpls@UU.NET Subject: Re: RRO object In-Reply-To: <20030508134347.61577.qmail@web41604.mail.yahoo.com> Message-ID: <20030508111023.W38682@garnet.juniper.net> References: <20030508134347.61577.qmail@web41604.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk There isn't much you can do about it, if the rro gets too big, it is dropped. See section 4.4.3 of the rfc. "If the newly added subobject causes the RRO to be too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message and message processing continues as normal. A PathErr (or ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RRO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RRO notification". Ina On Thu, 8 May 2003, bhuvan laddha wrote: > Hi, > > I would appreciate clarification for the following > point in the RFC: 3209: > > 1. Section 4.4.1.3 states - > > "The Length contains the total length of the subobject > in bytes,including the Type and Length fields." > > Assume labels represents "set of time-slots".Now,if > the set is large (e.g. 100 labels ),then Length of the > subobject will be 404 and length field is just one > byte and inadequate to carry this value (404) . > I would appreciate if someone can indicate how the > implemenation should handle this. > > Thanx, > ---Bhuvan. > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > From owner-mpls@UU.NET Thu May 8 16:45: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 QAA10175 for ; Thu, 8 May 2003 16:45:22 -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 QQonvn29042 for ; Thu, 8 May 2003 20:48: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 QQonvn28484; Thu, 8 May 2003 20:48:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQonvk12670 for mpls-outgoing; Thu, 8 May 2003 20:07: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 QQonvk12655 for ; Thu, 8 May 2003 20:07: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 QQonvk19409 for ; Thu, 8 May 2003 20:04: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 QQonvk11942 for ; Thu, 8 May 2003 20:04:06 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 QQonvk11898 for ; Thu, 8 May 2003 20:04:05 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 h48K3tCN020707; Thu, 8 May 2003 22:03:55 +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 h48K3tt13108; Thu, 8 May 2003 22:03:55 +0200 (CEST) Message-ID: <3EBAB76E.4010308@pi.se> Date: Thu, 08 May 2003 22:00: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: Alex Zinin , Bert Wijnen , George Swallow Subject: WG Last call on MIB Module - draft-ietf-mpls-mgmt-overview-04.txt 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 initiates a mpls wg last call on Multiprotocol Label Switching (MPLS) Management Overview The last call ends Monday 26th 9AM CET. This is a bit longer and an odd time to end the WG Last call. The reason is that we are preparing a set of MIB Modules for IESG review, before the meeting in Vienna, my intention is to bring all the MIB Modules out of this set that will go to WG Last Call through the a WG Last Call at this date abd send them all to the IESG review shortly after. I need the six hours head start I've on the US East Coast to prepare this, that monday morning. The Management Overview has strong dependencies to the other MIB Modules, so please look for inconsistencies. Also; as we are going into an IESG review with a very important set of documents, I would request that you don't only register your doubts and concerns, but your support and if you think it is ready for the IESG review as well. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Thu May 8 20:47: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 UAA18081 for ; Thu, 8 May 2003 20:47: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 QQonwd24172 for ; Fri, 9 May 2003 00:50: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 QQonwd22808; Fri, 9 May 2003 00:49:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQonvz24618 for mpls-outgoing; Thu, 8 May 2003 23:54: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 QQonvz24608 for ; Thu, 8 May 2003 23:54:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQonvz20400 for ; Thu, 8 May 2003 23:54:35 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 QQonvz04320 for ; Thu, 8 May 2003 23:54:03 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQonvz04083 for ; Thu, 8 May 2003 23:53:56 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.6/Switch-2.2.0) with ESMTP id h48Nrsu25832 for ; Thu, 8 May 2003 19:53:54 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10ABR9>; Fri, 9 May 2003 01:53:53 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B8AA7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: AD review of draft-ietf-mpls-ldp-mib-10.txt Date: Fri, 9 May 2003 01:53:51 +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 First a few serious things that need fixing (or a acceptable answer): 1. All the documents that contain a MIB module from which you IMPORT anything must be listed as normative references. I think a few are now under informative and a few may even be missing. 2. I see at several place in DESCRIPTION clause of StorageType objects this text: 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 mplsLdpEntityRowStatus to 'destroy(6)'." And that is very weird. It seems to allow to change the storagetype object itself (which is a nono). And the cannot destroy is also already covered by being a permanent entry. The required text from RFC2579 (Storage Type TC) is something aka: "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." Which you have in some other cases, and which I think expresses the same and is correct accoring to RFC2579 requirements. mplsLdpEntityAtmLRStorageType has it specified correctly! 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). 4. How many notifications can be generated per second? I worry based on the description clauses. I see a risk that it could be many if not implemented properly or with a proper throttle? Can you add some text about that? 5. I worry about a statement in a RowStatus DESCRIPTION clause (it is doen several times): NOTE: This RowStatus object should have the same value of the 'mplsLdpEntityRowStatus' related to this entry." I will agree that that is the ideal situation. But the rowStatus should always represent the real status of the row itself. If that is not consistent with some other row in another table, then that is bad, but it should not be a cause for the rowStatus of thos column to take an invalid value. I guess you did not mean to say it should... but that is how people might read it. 6. MPLS-LDP-GENERIC-MIB W: f(mplsldpgen.mi2), (58,17) The first revision should match the last update for MODULE-IDENTITY mplsLdpGenericMIB I think you just mistyped 2002 instead of 2003. Nits (some more serious than otehrs)... would be nice if they can be fixed: - I would not use capitals for FULL, READ-ONLY, NEW and such. There is the risk that someone wants to know if they have special meaning. - sect 3.5 under NOTE: This table My question: which table? - You have in many places a reference aka: REFERENCE "[RFC3036] LDP Specification, Section on LDP Identifiers." Now, once people extract the MIB module from the document (and many people do) then you loose the citation. So I always recommend: REFERENCE "RFC3036, LDP Specification, Section on LDP Identifiers." - I see: mplsLdpPeerTransportAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The object specifies how to interpret the address for the mplsLdpPeerTransportAddr object." .. snip 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." 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) So something aka the next seems better (maybe even rename TransportAddr to IntenetAddr: mplsLdpPeerTransportAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Internet address for the mplsLdpPeerTransportAddr object." .. snip mplsLdpPeerTransportAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet address advertized by the peer in the hello message or the Hello source address. The type of this address is determined by the value of the mplsLdpPeerTransportAddressType object." If you do change this, pls check all your InetAddress objects - mplsLdpSesKeepaliveTime What does value of zero mean? - mplsLdpHelloAdjacencyHoldTimeRem could use a UNITS clause I also wonder, since 0xffff has a special meaning,does that mean that that is also the max value? If so, a range of (0..65535) would make good sense. - I see: 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." s/InSegment/OutSegment/ ?? s/MIB's/MIB/ ?? - I may have said this before. Could the mplsLdpSesUp and mplsLdpSesDown notification not be combined to mplsLdpSesStateChange? The included mplsLdpSesState object will identify if it is an Up or a Down, will it not? - In the DESCRIPTION clauses of your OBJECT-GROUP definitions, you have langauge that talsk about "optional" and/or "required to implement". That is not the goal of the OBJECT-GROUP macro. It is needed to GROUP objects that logically belong together. So the DESCRIPTION should have text to explain why these objects belong in one group. The "optional" and "required" and susch is language that goes in DESCRIPTION clauses of the MODULE-COMPLIANCE GROUP clauses. - Sect 4.1 talks about mplsLdpEntityAtmLabelRangeTable while the actual table name is: mplsLdpEntityAtmLRTable Same for FrameRelay and Generic MIB - mplsLdpEntityAtmTable You talk about "extends". I think what the table does is that it is a "sparse augments". Your indexes are OK though. - mplsLdpEntityAtmLREntry talks about overlaps and such that may (should, can) not occur. But it does not say anything about what sort of error to return if someone tries to SNMP SET (or create) incorrect values. And It seems like 2 errors are possible: - inconcsistentName (if it is part of the (not-accessible) index) - inconsistentValue (if it is a value in read-create column) Not 100% sure... anyway, better to specify what you want to happen than let people guess - mplsLdpEntityAtmLRRowStatus has in DESCRIPTION clause There must exist at least one entry in this table for every LDP Entity that has 'mplsLdpEntityOptionalParameters' object with a value of 'atmSessionParameters'. Does not seem right in RowStatus object. Maybe in the Entry or Table object? I have seen this in multiple RowStatus Objects - mplsLdpAtmSesTable talks about 'mplsLdpSessionTable' In fact many places in the doc talk about it. Seems you renamed the table to mplsLdpSesTable (not sure why, cause I find the full Session better... but that is another subject). - mplsLdpEntityAtmLRRowStatus talks about 'mplsLdpEntityOptionalParameters' and so do some other places, but I cannot find the latter object - I can live with the security considerations section. You might be able to shorten it somewhat if you take the last 3 paragraphs of each 9.x section and state that once in its own 9.x section. Up to you. Thanks, Bert From owner-mpls@UU.NET Fri May 9 08:10: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 IAA13454 for ; Fri, 9 May 2003 08: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 QQonxw10372 for ; Fri, 9 May 2003 12:13:55 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 QQonxw09241; Fri, 9 May 2003 12:13:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQonxs24710 for mpls-outgoing; Fri, 9 May 2003 11:04:04 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 QQonxs24678 for ; Fri, 9 May 2003 11:03:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQonxs05348 for ; Fri, 9 May 2003 11:03: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 QQonxs08984 for ; Fri, 9 May 2003 11:03:30 GMT Received: from mta0 by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQonxs08875 for ; Fri, 9 May 2003 11:03:27 GMT Received: from l04955 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HEM00JP09B5C8@mta0.huawei.com> for mpls@uu.net; Fri, 09 May 2003 19:01:54 +0800 (CST) Date: Fri, 09 May 2003 19:03:31 +0800 From: lidefeng Subject: Draft-ietf-mpls-lsp-ping-02.txt:A doubt about "Downstream Mapping" To: mpls@UU.NET Message-id: <002601c3161a$a0cdaba0$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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Hi,all, In section "3.2. Downstream Mapping" of Draft-ietf-mpls-lsp-ping-02.txt,I have some question concerning the handling of "Downstream Mapping". In page 12,there is a paragraph as following: "The notion of 'downstream router' and 'downstream interface' should be explained. Consider an LSR X. If a packet that was originated with TTL n>1 arrived with outermost label L at LSR X, X must be able to compute which LSRs could receive the packet if it was originated with TTL=n+1, over which interface the request would arrive and what label stack those LSRs would see. (It is outside the scope of this document to specify how this computation is done.) The set of these LSRs/interfaces are the downstream routers/interfaces (and their corresponding labels) for X with respect to L. Each pair of downstream router and interface requires a separate Downstream Mapping to be added to the reply, and is given a unique DS Index " What I am confused is whether LSR X needs to compute all the downstream LSR until the TTL in the packet is decreased to 0,including those not directly connect to LSR X,or only needs to compute those directly downstream LSR of LSR X? If TTL n>1,then the packet can be received by LSR more than one hops away,then, what should be included in the Downstream mapping? Can anyone clarify it to me? Thanks Li Defeng From owner-mpls@UU.NET Fri May 9 10:03: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 KAA16293 for ; Fri, 9 May 2003 10:03: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 QQonye04662 for ; Fri, 9 May 2003 14:06:55 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 QQonye24569; Fri, 9 May 2003 14:03:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQonyb13368 for mpls-outgoing; Fri, 9 May 2003 13:29:34 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 QQonyb13363 for ; Fri, 9 May 2003 13:29:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQonyb08918 for ; Fri, 9 May 2003 13: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 QQonyb17792 for ; Fri, 9 May 2003 13:27:15 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 QQonyb17779 for ; Fri, 9 May 2003 13:27:14 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 h49DR54w000611; Fri, 9 May 2003 15:27:05 +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 h49DR5t26964; Fri, 9 May 2003 15:27:05 +0200 (CEST) Message-ID: <3EBBABEA.7000306@pi.se> Date: Fri, 09 May 2003 15:23:54 +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 , Martin Dubuc , Alex Zinin , George Swallow Subject: WG last call on "draft-ietf-mpls-telink-mib-01.txt" 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 last call on Traffic Engineering Link Management Information Base draft-ietf-mpls-telink-mib-01.txt This MIB module also goes into the effort to have the MPLS MIB modules on the IESG table before Viena. The last call ends Monday May 26th 9AM CET. Also; as we are going into an IESG review with a very important set of documents, I would request that you don't only register your doubts and concerns, but your support and if you think it is ready for the IESG review as well. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From owner-mpls@UU.NET Fri May 9 11:10: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 LAA19471 for ; Fri, 9 May 2003 11:10: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 QQonyi11748 for ; Fri, 9 May 2003 15:13: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 QQonyi10488; Fri, 9 May 2003 15:13:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQonyg06860 for mpls-outgoing; Fri, 9 May 2003 14:36: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 QQonyg06853 for ; Fri, 9 May 2003 14:36:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQonyg29503 for ; Fri, 9 May 2003 14:35:39 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 QQonyg13550 for ; Fri, 9 May 2003 14:35:38 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 QQonyg13533 for ; Fri, 9 May 2003 14:35:38 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.6/Switch-2.2.0) with ESMTP id h49EZaF24539 for ; Fri, 9 May 2003 10:35:36 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10APS4>; Fri, 9 May 2003 16:35:35 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B8C7B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Martin Dubuc , mpls@UU.NET Subject: AD review of: draft-ietf-mpls-telink-mib-01.txt Date: Fri, 9 May 2003 16:35:35 +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 Lots of good changes have been made. This is what I still find. I have now checked the example in section 7. It does start off with a disclaimer that it does not show all nuances of the MIB module. But ... - When you do a createAndGo, then all row objects that do not have a DEFVAL need to be provided. So the way things are described will cause SNMP errors. If you do not want to list all the details, then at least I'd suggest to make a statement aka: appropriate values for all row objects must be passed for every row createAndGo action. - two rows are created with createAndWait. I do not see they ever get activated. Was the assumption that they would get activted automagically, or is this an ommission? May I suggest that you make the names of your TCs start with TeLink or some such? This to show that they are basically local TCs. It will avoid potential future name clashes if someone wants to define a Generic TC for a similar (or even same) concept. Suggesteion: Priority -> TeLinkPriority LinkProtection -> TeLinkProtection SwitchingCapability -> TeLinkSwitchingCapability LinkEncodingType -> TeLinkEncodingType This is also recommended in the draft-ietf-ops-mib-review-guidelines-01.txt On page 33, please remove: -- The mandatory groups have to be implemented -- by all devices supporting TE links. However, they may all -- be supported as read-only objects in the case where automatic -- configuration is supported. This is not correct for the FullCompliance. It is OK on page 36 (for the ReadOnlyCompliance). Further comments inline (removed things where I am happy): > -----Original Message----- > From: Martin Dubuc [mailto:m.dubuc@rogers.com] > Sent: woensdag 30 april 2003 20:09 > To: mpls@UU.NET > Subject: RE: I-D ACTION:draft-ietf-mpls-telink-mib-00.txt > > > This is my response to Bert's email which explains how I have > addressed Bert's comments in draft-ietf-mpls-telink-mib-01.txt > that was submitted this morining to IETF. My comments are > embedded in the original mail (prefixed with [Martin]). > > Martin > > * * * > > Here is my review: > - linelegth checker: > $ /bin/checkpage.awk > Long line at 770 with 77 chars > Long line at 771 with 76 chars > Long line at 1268 with 73 chars > -: 3 lines longer than 72 characters, max 77 > > [Martin] Fixed. > Mmm... I still se: $ /bin/checkpage.awk - I have not yet checked sect 7. > See above > - sect 8.1 under ifType you refernece [IanaFamily]. > I think the reference should be to the ianaiftype.mib > > [Martin] You are right. Fixed. > Well... the reference in the reference section is incorrect. Check the link. It should be http://www.iana.org/assignments/ianaiftype-mib instead of: http://www.iana.org/assignments/ianatype-mib > - for my understanding, the figure in sect 8.2, can you > explain which layers > in the stack are bundle(s), telink or component link. In > fact it might be > good to add that explanantion to the text, so that people > can read it too. > > [Martin] Actually the example is not very clear and your > comment has triggered a flurry of mails between the authors. > We have updated the example to make it easier for readers > to understand. opticalTrans are component links. MUCH MUCH better now. If you added the ifIndex number in the boxes in teh fugures as well, that would improve it even more. and I wonder, if it makes sense to use the same ifIndex numbers in section 7 and then also point to the figure. That allows people to better link between objects and a visual picture of it. Just a thought. > - May I recommend that > teLinkIpAddrType InetAddressType, > teLinkIpAddr InetAddress, > teLinkRemoteIpAddr InetAddress, > Be renamed to: > teLinkAddressType InetAddressType, > teLinkLocalAddress InetAddress, > teLinkRemoteAddress InetAddress, > First of all, there can be an unnumbered addresstype (unknown), so then > it is not an IpAddress. > Second, I think that the first address is the local address (that is on > the device where the instance of the object lives, no? > > Further I wonder.. if it is an unnumbered link, it has an identifier somehow > does it not. Why would we not put that identifier in the address in that case > and describe what it looks like. In fact I wonder if instead of the > InetAddress.... TCs would it not be better to use TeHopAddres... TCs from the > MPLS-TC-MIB? It allows for TeHopAddressUnnum as an address > > In any event, I would not write: > teLinkIpAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "For IPv4 and IPv6 numbered links, this object represents the > IP address type associated with the TE link. For > unnumbered links, a value of unknown(0) must be used." > But rather something aka: > teLinkAddressType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The type of Internet address for the TE link. Only IPv4 and > IPv6 and unknown (for unnumbered links) need to be supported." > > Then forther in the Address itself I would do something aka (not that > the first sentence is REQUIRED as per RFC3291): > teLinkLocalAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The local Internet address for the TE link. The type of this > address is determined by the value of the teLinkAddressType > object. For an unnumbered TE link, the address represents an > unnumbered interface in this format: > > octets contents encoding > 1-4 unnumbered interface network-byte order > " > I stole some of the text from MPLS-TC-MIB for now > > [Martin] I have changed the name teLinkIpAddrType to teLinkAddressType per > your recommendation. However, I have not changed teLinkIpAddr and > teLinkRemoteIpAddr because these fields are really meant to be IP addresses. > If address type is unnumbered, then these fields should not be used (the > teLinkIncomingIfId and teLinkOutgoingIfId fields should be used instead). > It looks like this is not clear enough in the MIB, so > I have added text to clarify this point. > Mmm... I see. So I still would change the definition to something as follows (the 2nd sentence is manadatory according to RFC3291, and it is also important to indicate what the value of this object is (zero length string) in case of unnumberd (i.e. unknown type) link): teLinkLocalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Local Internet Address for numbered links. The type of this address is determined by the value of the teLinkAddressType object. For IPv4 and IPv6 numbered links, this object represents the local IP address associated with the TE link. For an unnumbered link, the local address is of type unknown and this this object is set to the zero length string and the teLinkOutgoingIfId object then identifies the unnumbered 'address'." ::= { teLinkEntry 2 } > - Would it make sense to elaborate a bit in the DESCRIPTION clause of > teLinkProtectionType and explain what the values exactly mean? > Or if they are explained in that GMPLS-OSPF doc that you > refernce, then at least make that statement. > > [Martin] The values are specified in GMPLS-OSPF, but are actually described in > GMPLS-ROUTING. I have added this statement (and the new reference). > Mmm... might have better been added to the TC now that you made it a TC. > - When I see a table like this: > teLinkDescriptorTable > TeLinkDescriptorEntry ::= SEQUENCE { > teLinkDescriptorId Unsigned32, > teLinkEncodingType INTEGER, > teLinkDescrPriority Unsigned32, > teLinkMinReservableBandwidth Unsigned32, > teLinkMaxReservableBandwidth Unsigned32, > teLinkDescrRowStatus RowStatus, > teLinkDescrStorageType StorageType > Then I always wonder if we cannot make it easier for people to see which > objects are indeed in that table. The first object name teLinkDescriptorId > clealrly is in this table. Then we have one teLinkEncodingType that is not > so clear. Then we have one that is not as clear as the 1st one, but still > gives some clue. Then we have 2 that give not clue, then we have 2 more > that give some clue. How about naming them: > TeLinkDescriptorEntry ::= SEQUENCE { > teLinkDescriptorId Unsigned32, > teLinkDescrEncodingType INTEGER, > teLinkDescrPriority Unsigned32, > teLinkDescrMinReservableBandwidth Unsigned32, > teLinkDescrMaxReservableBandwidth Unsigned32, > teLinkDescrRowStatus RowStatus, > teLinkDescrStorageType StorageType > If you can agree with that, then pls check you other tables. The same > issue/concern comes back in a few other tables. > In fact our mib guidelines document does discuss this issue. > > [Martin] Although it is not obvious why some entries do not have the same table > prefix, some others have been shortened because of the 32 character limit > warning for identifiers reported by smilint. I have changed the > identifiers so that they have the same prefix but stayed within > limit of 32 characters. > Mmm... the 32 limit is "recommended", but not a hard limit (that is why smilint gives a warning and not an error). The hard limit is 64. And we have in fact relaxed quite a bit over the last year or so on this. Again, this is clearly described in the mib guidelines document. I would really like the teSrlgTable to have prefixes that start with teSrlg instead of just srlg. That will avoid future possible name conflicts much easier. > - Your teLinkNotifEnable would be better named: > teLinkNotificationsEnabled > > [Martin] Changed. > Thanks > - I worry about the number of notifications that can get generated per minute > or per second? Can you say something about it? Do we need an abject that > lets an NMS configure how many notification an agent can send at most per > minute? > > [Martin] is only one type of notification in the TE link MIB module. > This notification can only occur if the provider uses bundled link and will > be generated only when there is a mismatch in a link bundle. Since link bundles > and TE links are provisioned by users and not on a regular basis, and since > mismatches are not likely to be common, the number of notifications should be > extremely small. I do not think there is a need to throttle > these notifications. > If possible, might want to add some text to DESCRIPTION clause. Will help people understand it better. > - linkBundleMismatch > I do not understand the DESCRIPTION clause at all. Specifically, if an error > is found and the notification is sent, then the 1 second later, the same > situation probably still exists. Is another notification sent? > Should such a problem not be detected when someone creates an antry in > a table and should create operation not be prevented from succeeding? > > [Martin] I expected that the notification would be sent only when the > mismatch was detected. We could prevent a create to succeed if we > detect a mismatch, but it may be easier to just flag the error. > I don't know how others feel about this. > In general it is better to return an error on an SNMP SET when someone tries to do somthing bad instead of letting it pass and generate a notification. Note that the error would go back to the offender, while you have no idea where the notification goes. > I wonder if you do not need ipv4z and/or ipv6z. As long as you have > evaluated this (with the WG) and decide that you do not need it, then > fine. > > [Martin] The issue of what to do with ipv4z and ipv6z has not been raised > by the WG or by the 3 implementations that we know of the MIB. > So maybe the WG SHOULD wonder about this. The question is not so much about if it has already been implemented or not. The question is if Traffic Engineered links can be created over Link Local or Site Local. interfaces/links. (By the way I know that site local is being abandoned by IPv6 WG). > - 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." > - I have trouble with: > OBJECT teLinkStorageType > SYNTAX INTEGER { other(1) } > DESCRIPTION > "Only other(1) needs to be supported." > > I think I could live with a volatile only, but the 'other' value > is completely unspecified and seems to make no sense to me at all. > What is you intention here? > > [Martin] I picked this from the LSR MIB. I don't think there is a good > reason to limit to one single value. I have removed this conformance > statement. > I hope LSR MIB will remove it too!! > - In security considerations... > - Do All tables have the same considerations? If so you may want > to make that explicit. > > [Martin] Yes, they all have the same considerations. All info in this > MIB module are used for routing purposes. To me, they have the > same sensitivity. Except for IP addresses, which may actually be used > in some sort of attack if known. This is why I have a separate clause > regarding IP addresses. > > - In general, our security ADs probably want some more specificity. > A statement like "all tables ....." sounds as if you are > opting for an easy out. > > [Martin] It may sounds like I am opting for an easy out, but the fact of > the matter is, all tables have the same considerations. > If you make an EXPLICIT statement that they ALL have the same security considerations, then you show that you have thought about it and have made a conscious decision (or so I think). E.g. something like "All the tables in this MIB module have routing information in them and so they all have the same security attributes." > - On th eread-only objects... are there no issues with bandwith info? > Or priorities? On protection? > would that not reveal info that people don't want to loose? > > [Martin] The problem here is where you draw the line. Every MIB object > is vulnerable and may reveal info that would be better kept secret. I have > read the security guidelines thoroughly and my interpretation is that we > should uncover anything that is sensitive to exposure of end-user > personal information or may lead to potential disruption of service. > There isn't anything in TE link MIB that relates to end-user personal > information. There is potential for disruption of service if someone > changes attributes in any table of the MIB because this affects routing > (this is my first statement) and there may be disruption of service if the > IP address are used in some form of spoofing or attack (this is my second > statement). I don't know that there is much else to say according to the > spirit of the security guidelines. > I am just trying to help here. I know Security ADs are often picky these days. We'll see what they say when it gets to IESG. You can also send and email to them beforehand and check if they are OK with what you have. Feel free to copy this discussion. Bert From owner-mpls@UU.NET Fri May 9 12:35: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 MAA22206 for ; Fri, 9 May 2003 12:35:31 -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 QQonyo15111 for ; Fri, 9 May 2003 16:38: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 QQonyo14336; Fri, 9 May 2003 16:38:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQonyl01434 for mpls-outgoing; Fri, 9 May 2003 15:59:57 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 QQonyl01424 for ; Fri, 9 May 2003 15:59:38 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 QQonyl25937 for ; Fri, 9 May 2003 15:58: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 QQonyl01291 for ; Fri, 9 May 2003 15:58:58 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQonyl01250 for ; Fri, 9 May 2003 15:58:56 GMT Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.162]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRML23G1; Fri, 9 May 2003 11:58:54 -0400 Message-Id: <5.2.0.9.0.20030509103435.01ea12a8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 09 May 2003 11:56:38 -0400 To: mpls@UU.NET From: Mark Duffy Subject: LDP basic discovery on multipoint NBMA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, RFC 3036 (LDP) defines 2 types of peer discovery: Basic and Extended. Basic cannot be used on non-multicast-capable NBMA interfaces (e.g. non-LC ATM or frame relay). Extended can work on NBMA but unfortunately its semantics are different than Basic discovery: it allows "discovery" of peers that are more than 1 hop away, and it does not bind the Hello adjacency to a particular interface. Both of these differences can be undesirable in a context where one is looking to use LDP to distribute outer labels with adjacent peers on a non-LC NBMA network. Extended discovery appears to be primarily intended for distributing "inner" labels with non-adjacent peers. I have not seen any discussion of this in RFC 3036 or on this list. Are folks out there deploying LDP over non-LC ATM or FR multipoint networks? What type of discovery is being used? It would seem to me that there is a need for a discovery method that is semantically similar to basic discovery, but that can operate on NBMA environments that lack multicast capability. Any opinions on this? Thanks, Mark Duffy From owner-mpls@UU.NET Fri May 9 13:29: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 NAA24000 for ; Fri, 9 May 2003 13:29:14 -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 QQonxi27243; Fri, 9 May 2003 08:42:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQonxg15768 for mpls-outgoing; Fri, 9 May 2003 08:04:43 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 QQonxg15759 for ; Fri, 9 May 2003 08:04: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 QQonxg24121 for ; Fri, 9 May 2003 08:04:27 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 QQonxg13680 for ; Fri, 9 May 2003 08:04:26 GMT Received: from mta0 by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQonxg13492 for ; Fri, 9 May 2003 08:04:22 GMT Received: from l04955 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HEM00J7S10K4X@mta0.huawei.com> for mpls@uu.net; Fri, 09 May 2003 16:02:46 +0800 (CST) Date: Fri, 09 May 2003 16:04:21 +0800 From: lidefeng Subject: Draft-ietf-mpls-lsp-ping-02.txt: How to handle the "Target FEC Stack" ? To: mpls@UU.NET Message-id: <000a01c31601$999eb7c0$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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Hi,all, In Section "3.1. Target FEC Stack " of draft-ietf-mpls-lsp-ping-02.txt,there is an example as following, "If LSR X wanted to verify that a label stack of <1001, 23456> is the right label stack to use to reach an IP VPN prefix of 10/8 in VPN foo on an egress LSR with loopback address 192.168.1.1 (learned via LDP), X has two choices. X can send an MPLS echo request with a FEC Stack TLV with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 with the Route Distinguisher for VPN foo. Alternatively, X can send a FEC Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 in VPN foo. In either case, the MPLS echo request would have a label stack of <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 23456 is the "inner" label.)" I want to know that in the alternative choice,whether to add the Route Distinguisher to the IPV4 with the prefix 10/8 to make the device along the path between the two CE(source and sink CE concerning the prefix 10/8 in the VPN foo ) identify the VPN foo? If that is true,then the first FEC element in the above alternative choice is 192.168.1.1/32(IPV4 type),and its corresponding label is 1001,and the second FEC element is FEC of type VPN IPv4 prefix with a prefix of 10/8 with the Route Distinguisher for VPN foo,the corresponding label is 23456.Right? That is 192.168.1.1/32(FEC) ---->1001(LABEL),and RD:10/8(FEC)--->23456(LABEL),Could you please tell me whether my understanding is right? TIA and Regards! Li Defeng From owner-mpls@UU.NET Fri May 9 17:54:49 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 RAA04038 for ; Fri, 9 May 2003 17:54: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 QQonzj29777 for ; Fri, 9 May 2003 21:57: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 QQonzj29123; Fri, 9 May 2003 21:57:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQonzh16947 for mpls-outgoing; Fri, 9 May 2003 21:17:31 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 QQonzh16942 for ; Fri, 9 May 2003 21:17:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQonzh29466 for ; Fri, 9 May 2003 21:16: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 QQonzh07393 for ; Fri, 9 May 2003 21:16:26 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 QQonzh07366 for ; Fri, 9 May 2003 21:16:25 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h49LGMhM022167 for ; Fri, 9 May 2003 17:16:22 -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 RAA06948 for ; Fri, 9 May 2003 17:16:22 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h49LGMd06800 for mpls@uu.net; Fri, 9 May 2003 17:16:22 -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 QQonzg15250 for ; Fri, 9 May 2003 21:08: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 QQonzg28875 for ; Fri, 9 May 2003 21:07:22 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 QQonyl07796 for ; Fri, 9 May 2003 15:51:36 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h49FpRZC017664; Fri, 9 May 2003 11:51:28 -0400 (EDT) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA10072; Fri, 9 May 2003 11:51:26 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA10657; Fri, 9 May 2003 11:51:26 -0400 (EDT) Message-Id: <200305091551.LAA10657@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: lidefeng cc: mpls@UU.NET, swallow@cisco.com Subject: Re: Draft-ietf-mpls-lsp-ping-02.txt:A doubt about "Downstream Mapping" In-reply-to: Your message of "Fri, 09 May 2003 19:03:31 +0800." <002601c3161a$a0cdaba0$07436e0a@HUAWEI.COM> Date: Fri, 09 May 2003 11:51:26 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Li - > In section "3.2. Downstream Mapping" of Draft-ietf-mpls-lsp-ping-02.txt,I > have some question concerning the handling of "Downstream Mapping". > > In page 12,there is a paragraph as following: > "The notion of 'downstream router' and 'downstream interface' should > be explained. Consider an LSR X. If a packet that was originated > with TTL n>1 arrived with outermost label L at LSR X, X must be able > to compute which LSRs could receive the packet if it was originated > with TTL=n+1, over which interface the request would arrive and what > label stack those LSRs would see. (It is outside the scope of this > document to specify how this computation is done.) The set of these > LSRs/interfaces are the downstream routers/interfaces (and their > corresponding labels) for X with respect to L. Each pair of > downstream router and interface requires a separate Downstream > Mapping to be added to the reply, and is given a unique DS Index " > > What I am confused is whether LSR X needs to compute all the downstream LSR > until the TTL in the packet is decreased to 0,including those not directly > connect to LSR X,or only needs to compute those directly downstream LSR of > LSR X? If TTL n>1,then the packet can be received by LSR more than one hops > away,then, what should be included in the Downstream mapping? > > Can anyone clarify it to me? The 'n' vs 'n+1' means one hop away. So you need to figure out what routers will see the packet if the ttl does not expire at you. Mostly this is just your immediate neighbors. One exception that comes to mind is on TE tunnels. If your tunnel is set up to copy the TTL into the tunnel label, then you want to report the router at the next hop in the tunnel. If, however you are hidding TTL (setting the TTL in the tunnel label to some value that will not expire before the end of the tunnel - usually 255) the you want to report the router at the tail end of the TE tunnel. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-mpls@UU.NET Sat May 10 08:49: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 IAA00327 for ; Sat, 10 May 2003 08:49: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 QQoobr11618 for ; Sat, 10 May 2003 12:52: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 QQoobr11001; Sat, 10 May 2003 12:52:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQoobp00012 for mpls-outgoing; Sat, 10 May 2003 12:21:15 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 QQoobp00007 for ; Sat, 10 May 2003 12:21:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoobp09210 for ; Sat, 10 May 2003 12:19:15 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 QQoobp12771 for ; Sat, 10 May 2003 12:19:14 GMT Received: from smtp10.atl.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp10.atl.mindspring.net [207.69.200.246]) id QQoobp12759 for ; Sat, 10 May 2003 12:19:14 GMT Received: from dialup-67.75.23.227.dial1.boston1.level3.net ([67.75.23.227] helo=jluciani-laptop) by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1) id 19ETJk-0007y5-00; Sat, 10 May 2003 08:19:08 -0400 Message-Id: <3.0.1.32.20030510081805.01742440@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 10 May 2003 08:18:05 -0400 To: "Wijnen, Bert (Bert)" , "Mpls (E-mail)" Subject: Re: AD review of draft-ietf-mpls-ldp-mib-10.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155018B8AA7@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Bert, Thanks for this review! At 01:53 AM 5/9/03 +0200, Wijnen, Bert (Bert) wrote: >First a few serious things that need fixing (or a acceptable >answer): > >1. All the documents that contain a MIB module from which > you IMPORT anything must be listed as normative references. > I think a few are now under informative and a few may even > be missing. okay. > >2. I see at several place in DESCRIPTION clause of StorageType > objects this text: > 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 > mplsLdpEntityRowStatus to 'destroy(6)'." > And that is very weird. It seems to allow to change the storagetype > object itself (which is a nono). And the cannot destroy is also > already covered by being a permanent entry. > The required text from RFC2579 (Storage Type TC) is something aka: > "The storage type for this conceptual row. Conceptual rows > having the value 'permanent(4)' need not allow write-access > to any columnar objects in the row." > Which you have in some other cases, and which I think expresses > the same and is correct accoring to RFC2579 requirements. > mplsLdpEntityAtmLRStorageType has it specified correctly! > Sorry, but am confused by this, if the type is permanent(4), then the agent does not have to support any subsequent sets (modifications) to objects in this row, which includes setting the RowStatus object to destroy, is this correct? So then once a row is permanent(4), then the agent does not need to provide a way to remove/change this row using SNMP, is this correct? We can rephrase this using the text suggested above, but just want to make sure we understand ;) >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? The reference to ADDRESS-FAMILY is because the LDP Spec (3036) uses in a few TLV and they do specify [RFC1700] as the reference. Here is the Specific example from the LDP Spec (rfc3036): "Prefix FEC Element value encoding: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (2) | Address Family | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field." We do not mean to cause confusion in the MIB, BUT, the LDP Spec which is "Standards Track" document refers to the obsoleted document (RFC1700) and the MIB is actually refering to the LDP Spec. In the MIB we are trying to use descriptions based on the LDP Spec so that folks can use this MIB to configure values for the LDP TLVs. If we change this description too much, then the reference back to the LDP Spec is lost. Originally we did use the ADDRESS-FAMILY-NUMBERS TC but changed this for the INET-ADDRESS-MIB which is better for MIB purposes. Please let us know if we can keep the DESCRIPTION as it is or change it? > 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). > >4. How many notifications can be generated per second? Are you asking for a worst case scenario? In a network where LDP is configured on each device (and not being reconfigured) would not expect notifications to be generated once sessions are established. So would not quantify X notifications per second. Maybe another way to ask this question is: how long does the average LDP Session last? Would say most last longer than a second, but would be good to get operator experience here. > I worry based on the description clauses. I see a risk that it > could be many if not implemented properly or with a proper > throttle? Can you add some text about that? There are not huge amounts of LDP sessions on a device and these (one established) are fairly stable unless an operator reconfigures or something goes wrong with the network, but this would fall into a worst case scenario. Certainly, would be good to get some operator experience here, but in my experience, sessions (once established) are fairly stable as long as the network's physical connections are not being changed and LDP is not being reconfigured. > >5. I worry about a statement in a RowStatus DESCRIPTION clause > (it is doen several times): > NOTE: This RowStatus object should > have the same value of the 'mplsLdpEntityRowStatus' > related to this entry." > I will agree that that is the ideal situation. But the rowStatus > should always represent the real status of the row itself. > If that is not consistent with some other row in another table, > then that is bad, but it should not be a cause for the > rowStatus of thos column to take an invalid value. I guess > you did not mean to say it should... but that is how people > might read it. Okay, I understand I think. We have had many issues with folks not understanding the relationship of these tables and essentially, any table that has a configurable row is related to a row in the mplsLdpEntityTable. This is outside of the scope of RowStatus though, so will reword this to remove the "should". > > >6. MPLS-LDP-GENERIC-MIB > W: f(mplsldpgen.mi2), (58,17) The first revision should > match the last update for MODULE-IDENTITY mplsLdpGenericMIB > I think you just mistyped 2002 instead of 2003. yes. typo. > >Nits (some more serious than otehrs)... >would be nice if they can be fixed: > >- I would not use capitals for FULL, READ-ONLY, NEW and such. > There is the risk that someone wants to know if they have > special meaning. >- sect 3.5 under NOTE: This table > My question: which table? >- You have in many places a reference aka: > REFERENCE > "[RFC3036] LDP Specification, Section on LDP Identifiers." > Now, once people extract the MIB module from the document (and many > people do) then you loose the citation. So I always recommend: > REFERENCE > "RFC3036, LDP Specification, Section on LDP Identifiers." >- I see: > mplsLdpPeerTransportAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The object specifies how to interpret the address > for the mplsLdpPeerTransportAddr object." > .. snip > > 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." > > 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) > > So something aka the next seems better (maybe even rename > TransportAddr to IntenetAddr: > > mplsLdpPeerTransportAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of Internet address for the > mplsLdpPeerTransportAddr object." > .. snip > > mplsLdpPeerTransportAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The Internet address advertized by the peer in the hello > message or the Hello source address. > > The type of this address is determined by the value of > the mplsLdpPeerTransportAddressType object." > > If you do change this, pls check all your InetAddress objects okay, thank you for the text. > >- mplsLdpSesKeepaliveTime > What does value of zero mean? The value cannot be zero. This has to be a nonzero, 2 octet value, which represents the amount of seconds between keep alive messages negoatiated between the entity and the peer for that specific session. The mplsLdpEntityKeepAliveHoldTimer is the object which configures this value. This Peer also sends a value and these are negotiated to be the smaller of the 2 values. This object represents the negotiated value. Do we put a range on this even though it is read-only and we already have a range on the configurable counter-part? The range will be the same range as for the mplsLdpEntityKeepAliveHoldTimer object which is configurable. > >- mplsLdpHelloAdjacencyHoldTimeRem > could use a UNITS clause We debated this. If there are special values (in this case for 0 and for 0xffff/65535) then if we have a UNITS "seconds" is it clear that these other values are not seconds?? > I also wonder, since 0xffff has a special meaning,does that mean > that that is also the max value? If so, a range of (0..65535) > would make good sense. The object which is used to configure this value for the entity is mplsLdpEntityHelloHoldTimer which does have a range. SO same question as above, do we put a range on this object even if it is read-only and we already have the range for the configurable counter-part? > >- I see: > 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." > s/InSegment/OutSegment/ ?? > s/MIB's/MIB/ ?? > >- I may have said this before. Could the mplsLdpSesUp and mplsLdpSesDown > notification not be combined to mplsLdpSesStateChange? > The included mplsLdpSesState object will identify if it is an Up or a > Down, will it not? Yes, this came up. We wanted to leave this because we do know NMS apps which do not decode the notifications too much but resolve by saying this notification matches this other notification. So one notification causes an alarm and the other notification clears it. Not sure if it matters too much in this situation so we can change it as suggested above. > >- In the DESCRIPTION clauses of your OBJECT-GROUP definitions, you have > langauge that talsk about "optional" and/or "required to implement". > That is not the goal of the OBJECT-GROUP macro. It is needed to GROUP > objects that logically belong together. So the DESCRIPTION should > have text to explain why these objects belong in one group. > The "optional" and "required" and susch is language that goes > in DESCRIPTION clauses of the MODULE-COMPLIANCE GROUP clauses. Okay, thanks for this info. > >- Sect 4.1 talks about mplsLdpEntityAtmLabelRangeTable while the actual > table name is: mplsLdpEntityAtmLRTable > Same for FrameRelay and Generic MIB Sorry, yes, we changed this and missed the text. > >- mplsLdpEntityAtmTable > You talk about "extends". I think what the table does is that it > is a "sparse augments". Your indexes are OK though. Yes, this is true for the mplsLdpEntityFrameRelayTable also. > >- mplsLdpEntityAtmLREntry talks about overlaps and such that may > (should, can) not occur. But it does not say anything about what > sort of error to return if someone tries to SNMP SET (or create) > incorrect values. And It seems like 2 errors are possible: > - inconcsistentName (if it is part of the (not-accessible) index) > - inconsistentValue (if it is a value in read-create column) > Not 100% sure... anyway, better to specify what you want to > happen than let people guess > Okay we will add to the table description. >- mplsLdpEntityAtmLRRowStatus has in DESCRIPTION clause > There must exist at least one entry in this > table for every LDP Entity that has > 'mplsLdpEntityOptionalParameters' object with > a value of 'atmSessionParameters'. > Does not seem right in RowStatus object. Maybe in the Entry > or Table object? > I have seen this in multiple RowStatus Objects We will check on this. Agree it is better in table/entry description. > >- mplsLdpAtmSesTable talks about 'mplsLdpSessionTable' > In fact many places in the doc talk about it. > Seems you renamed the table to mplsLdpSesTable (not sure why, > cause I find the full Session better... but that is another > subject). Okay, we will check this. Sorry, had a mix and changed to to be shorter, but sounds like you prefer the longer, i.e. session ;) > >- mplsLdpEntityAtmLRRowStatus talks about > 'mplsLdpEntityOptionalParameters' > and so do some other places, but I cannot find the latter object We changed the name of the object to be mplsLdpEntityLabelType, so will update these descriptions. > >- I can live with the security considerations section. > You might be able to shorten it somewhat if you take the last 3 > paragraphs of each 9.x section and state that once in its own > 9.x section. Up to you. Okay, we can do that. Thanks again for the review. -Joan > >Thanks, >Bert > From owner-mpls@UU.NET Sat May 10 15:01:29 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 PAA05627 for ; Sat, 10 May 2003 15:00: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 QQoocl20734 for ; Sat, 10 May 2003 17:46: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 QQoocl20202; Sat, 10 May 2003 17:46:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQooci22085 for mpls-outgoing; Sat, 10 May 2003 17:07:13 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 QQooci22080 for ; Sat, 10 May 2003 17:07:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQooci08211 for ; Sat, 10 May 2003 17:06: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 QQooci25580 for ; Sat, 10 May 2003 17:06:47 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQooci25283 for ; Sat, 10 May 2003 17:06:41 GMT Message-ID: From: Ling Li To: "Mpls (E-mail)" Subject: bandwidth for the backup path in fast reroute Date: Sat, 10 May 2003 13:06:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk in draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt, 6.2 Procedures for Backup Path Computation - The bandwidth to be used is found in the FAST_REROUTE object, if included in the PATH message, and in the SESSION_ATTRIBUTE object otherwise. Local policy may modify the bandwidth to be reserved. Is this a typo "in the SESSION_ATTRIBUTE object"? Should it be " in the SENDER_TSPEC object"? Thanks, Ling Li Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 ======================== From owner-mpls@UU.NET Sat May 10 20:07: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 UAA11597 for ; Sat, 10 May 2003 20:07: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 QQoobu05762 for ; Sat, 10 May 2003 13:43: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 QQoobu05348; Sat, 10 May 2003 13:43:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQoobs21904 for mpls-outgoing; Sat, 10 May 2003 13:12: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 QQoobs21856 for ; Sat, 10 May 2003 13:12:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoobs28825 for ; Sat, 10 May 2003 13:08: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 QQoobs07145 for ; Sat, 10 May 2003 13:08:07 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQoobs07132 for ; Sat, 10 May 2003 13:08:07 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.6/Switch-2.2.0) with ESMTP id h4AD85N15942 for ; Sat, 10 May 2003 09:08:05 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10A525>; Sat, 10 May 2003 15:08:04 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B8D6D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, "Wijnen, Bert (Bert)" , "Mpls (E-mail)" Subject: RE: AD review of draft-ietf-mpls-ldp-mib-10.txt Date: Sat, 10 May 2003 15:08:03 +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 Answers to your questions: > >2. I see at several place in DESCRIPTION clause of StorageType > > objects this text: > > 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 > > mplsLdpEntityRowStatus to 'destroy(6)'." > > And that is very weird. It seems to allow to change the storagetype > > object itself (which is a nono). And the cannot destroy is also > > already covered by being a permanent entry. > > The required text from RFC2579 (Storage Type TC) is something aka: > > "The storage type for this conceptual row. Conceptual rows > > having the value 'permanent(4)' need not allow write-access > > to any columnar objects in the row." > > Which you have in some other cases, and which I think expresses > > the same and is correct accoring to RFC2579 requirements. > > mplsLdpEntityAtmLRStorageType has it specified correctly! > > > > Sorry, but am confused by this, if the type is permanent(4), then > the agent does not have to support any subsequent sets (modifications) > to objects in this row, which includes setting the RowStatus object > to destroy, is this correct? > > So then once a row is permanent(4), then the agent does not need to provide > a way to remove/change this row using SNMP, is this correct? > > We can rephrase this using the text suggested above, but just want to > make sure we understand ;) > The values of StorageType MUST be controled as the prescribed behaviour in the StorageType TC. From RFC2579: StorageType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Describes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted. If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable." So it say that a row which is permanent can be changed but cannot be deleted. So no need for you to repeat that you cannot do a destroy (in fact it may just confuse people). The TC also already prescribes that a row CAN BE CHANGED, so you do not have to repeat that write-access MAY be allowed. The last para in the above description state that you MUST specify if there are any objects that MUST be allowed to be written. In your case, I think there are none. (RFC3414, usmUserTable is an examble where some object MUST allow write access, but most tables don't have such situations). So I think my proposed text is: shorter, more precise, and in-line with all other such similar descriptions in other MIB modules. > >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? > > > The reference to ADDRESS-FAMILY is because the LDP Spec (3036) uses > in a few TLV and they do specify [RFC1700] as the reference. Here > is the Specific example from the LDP Spec (rfc3036): > > > "Prefix FEC Element value encoding: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix (2) | Address Family | PreLen | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Address Family > Two octet quantity containing a value from ADDRESS FAMILY > NUMBERS in [RFC1700] that encodes the address family for the > address prefix in the Prefix field." > > > > We do not mean to cause confusion in the MIB, BUT, the LDP Spec > which is "Standards Track" document refers to the obsoleted document > (RFC1700) and the MIB is actually refering to the LDP Spec. > That is because when RFC3036 was issued, the RFC3232 did not yet exist. For new documents, we want people to use the newer RFC if at all possible. > In the MIB we are trying to use descriptions based on the LDP Spec so that > folks can use this MIB to configure values for the LDP TLVs. > If we change this description too much, then the reference back to the LDP > Spec is lost. > Why would that be lost? I can see it MAY cause some confusion, and I now also am a bit confused. In the MIB module you keep saying that only IPv4 and IPv6 addresses are to be supported (or unnumberd, but that is not part of AddressFamily at all, so that is another confusing factor). The AddressFamily has MANY MORE address types than just IPv4 or IPv6. So... if they all need to be supported, then you have conflicting (or at least confusing) text in the MIB document. If it is only IPv4/v6, then INET-ADDRESS-MIB numbers/values happen to be the same as addressFamily numbers. > Originally we did use the ADDRESS-FAMILY-NUMBERS TC but changed this > for the INET-ADDRESS-MIB which is better for MIB purposes. > Yep, I remember I (strongly) suggested that. Probably I WAS ALREADY confused back then cause you spoke about just IPv4/IPv4 support. So what is the story on that. Does the LDP protocol support all those addresses and did you just limit the MIB support? That would not be correct I think. > Please let us know if we can keep the DESCRIPTION as it is or change > it? > Depends on answers to my above questions back to you. > > > >4. How many notifications can be generated per second? > > Are you asking for a worst case scenario? > > In a network where LDP is configured on each device (and not being > reconfigured) would not expect notifications to be generated once sessions > are established. So would not quantify X notifications per second. > > Maybe another way to ask this question is: how long does the > average LDP Session last? > > Would say most last longer than a second, but > would be good to get operator experience here. > The thing is that we do not want the network and the NMS to be flooded (congested) with notifications. If there is a true story that they will be infrequent, then just add that explanation, and we're OK. Do remember that a NMS may be receiveing such notification from many managed devices. So if you had one a second per managed device, and you had to manage 1000s of devices, then there is potential still for NMS overload/congestion. So some words to make people feel comfortable is goodness. If the evaluation is that there might be too many notifications, then we may need to add a throttle object. > > I worry based on the description clauses. I see a risk that it > > could be many if not implemented properly or with a proper > > throttle? Can you add some text about that? > > There are not huge amounts of LDP sessions on a device and > these (one established) are fairly stable unless an operator > reconfigures or something goes wrong with the network, but this > would fall into a worst case scenario. > > Certainly, would be good to get some operator experience here, but > in my experience, sessions (once established) are fairly stable as > long as the network's physical connections are not being changed and > LDP is not being reconfigured. > OK, so add some text to explain situation is under control (at least theoretically). If implementation/deployment experience tells us later that we were wrong, then we can add a throttle object later. > > > >5. I worry about a statement in a RowStatus DESCRIPTION clause > > (it is doen several times): > > NOTE: This RowStatus object should > > have the same value of the 'mplsLdpEntityRowStatus' > > related to this entry." > > I will agree that that is the ideal situation. But the rowStatus > > should always represent the real status of the row itself. > > If that is not consistent with some other row in another table, > > then that is bad, but it should not be a cause for the > > rowStatus of thos column to take an invalid value. I guess > > you did not mean to say it should... but that is how people > > might read it. > > Okay, I understand I think. We have had many issues with folks not > understanding the relationship of these tables and essentially, any > table that has a configurable row is related to a row in the > mplsLdpEntityTable. This is outside of the scope of RowStatus though, > so will reword this to remove the "should". > Right. It might be better to have some text in the ...Table or ...Entry DESCRIPTION clause that explains the relationships. It might also be good to have some of that text in narative text before the MIB MODULE itself. Let me warn you that experience has told us that if table relationships become too complex and if too many tables have to be in sync all the time, that such has been very troublesome. We often found it easier to tell people that if entry x in table A was not in sycn with entry x in table B, then some operation would not work... but we would not force the agent to make sure that all tables were kept in sync all the time. Just giving you some background info here. > > > >Nits (some more serious than otehrs)... > >would be nice if they can be fixed: > > > > > >- mplsLdpSesKeepaliveTime > > What does value of zero mean? > > The value cannot be zero. This has to be a nonzero, 2 octet > value, which represents the amount of seconds between keep alive > messages negoatiated between the entity and the peer for that > specific session. > > The mplsLdpEntityKeepAliveHoldTimer is the object which > configures this value. This Peer also sends a value and > these are negotiated to be the smaller of the 2 values. > > This object represents the negotiated value. > > Do we put a range on this even though it is read-only and > we already have a range on the configurable counter-part? > I would. That shows management Apps what the expected valid values are. It seems that I would put the same limits(range) as the one that configures it. Interesting explanation by the way. I always wonder why such explanations do not get provided in the object DESCRIPTION clauses. Now things all of a sudden make much more sense to me. Why would you assume that operators (who monitor these things) would easily understand all thise details? > > The range will be the same range as for the > mplsLdpEntityKeepAliveHoldTimer object which is configurable. > > > > >- mplsLdpHelloAdjacencyHoldTimeRem > > could use a UNITS clause > > We debated this. If there are special values (in this case for > 0 and for 0xffff/65535) then if we have a UNITS "seconds" > is it clear that these other values are not seconds?? > Mmm... but you have a SYNTAX of TimeInterval... I think I meant mplsLdpHelloAdjacencyHoldTime and there indeed it has the special values. Sorry.. guess it was late at night. > > > I also wonder, since 0xffff has a special meaning,does that mean > > that that is also the max value? If so, a range of (0..65535) > > would make good sense. > > The object which is used to configure this value for the entity > is mplsLdpEntityHelloHoldTimer which does have a range. > > SO same question as above, do we put a range on this object even if > it is read-only and we already have the range for the configurable > counter-part? > As stated above, I would. If you had done so, I would not have had to ask this question. And I bet I am not the only one who would wonder. Again, you are giving extra explantion that might be helpfull for other/future readers as well. Might want to add that too. > > > > > >- I see: > > 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." > > s/InSegment/OutSegment/ ?? > > s/MIB's/MIB/ ?? > > > >- I may have said this before. Could the mplsLdpSesUp and mplsLdpSesDown > > notification not be combined to mplsLdpSesStateChange? > > The included mplsLdpSesState object will identify if it is an Up or a > > Down, will it not? > > > Yes, this came up. We wanted to leave this because we do know NMS apps which > do not decode the notifications too much but resolve by saying this notification > matches this other notification. So one notification causes > an alarm and the other notification clears it. Not sure if it matters too > much in this situation so we can change it as suggested above. > I am not too worried. I just brought it up to make sure people had thought about it. So up to you and the WG. I could check if the collective set of MIB Doctors has consensus on this (I would not be surprised if they do not). > Thanks again for the review. > You're welcome. And thanks for the speedy follow up. Bert > -Joan From owner-mpls@UU.NET Sun May 11 00:00: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 AAA14904 for ; Sun, 11 May 2003 00:00: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 QQoocp27387 for ; Sat, 10 May 2003 18:50: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 QQoocp26655; Sat, 10 May 2003 18:50:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQoocn16606 for mpls-outgoing; Sat, 10 May 2003 18:17: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 QQoocn16595 for ; Sat, 10 May 2003 18:17:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoocn28822 for ; Sat, 10 May 2003 18:16:40 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 QQoocn19405 for ; Sat, 10 May 2003 18:16:40 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 QQoocn19386 for ; Sat, 10 May 2003 18:16:39 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4AIGZKc011457 for ; Sat, 10 May 2003 14:16:36 -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 OAA25789 for ; Sat, 10 May 2003 14:13:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4AID2v03471 for mpls@uu.net; Sat, 10 May 2003 14:13: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 QQoocm15651 for ; Sat, 10 May 2003 18:11:44 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 QQoocm20401 for ; Sat, 10 May 2003 18:11: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 QQoocm19976 for ; Sat, 10 May 2003 18:11:36 GMT Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQoocm19960 for ; Sat, 10 May 2003 18:11:35 GMT 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 h4AI983m026845; Sat, 10 May 2003 20:09:08 +0200 (MET DST) Received: from jvasseur-w2k01.cisco.com (sjc-vpn1-407.cisco.com [10.21.97.151]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA14296; Sat, 10 May 2003 20:11:00 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030510140833.06efd718@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 10 May 2003 14:10:58 -0400 To: Ling Li From: Jean Philippe Vasseur Subject: Re: bandwidth for the backup path in fast reroute Cc: "Mpls (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Ling, At 01:06 PM 5/10/2003 -0400, Ling Li wrote: >in draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt, >6.2 Procedures for Backup Path Computation > > - The bandwidth to be used is found in the FAST_REROUTE object, > if included in the PATH message, and in the SESSION_ATTRIBUTE > object otherwise. Local policy may modify the bandwidth to be > reserved. > >Is this a typo "in the SESSION_ATTRIBUTE object"? Should it be " in the >SENDER_TSPEC object"? The text above refers the to "bandwidth protection desired" bit of the SESSION-ATTRIBUTE object. When set, this means that the protected TE LSP requires bandwidth protection (with an equivalent bandwidth as the protected LSP). JP. >Thanks, > >Ling Li > >Axiowave Networks, Inc. >200 Nickerson Road >Marlborough, MA 01752 >======================== From owner-mpls@UU.NET Sun May 11 01:36: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 BAA16368 for ; Sun, 11 May 2003 01:36: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 QQooeg12474 for ; Sun, 11 May 2003 05:39: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 QQooeg11499; Sun, 11 May 2003 05:39:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQooee13993 for mpls-outgoing; Sun, 11 May 2003 05:02:26 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 QQooee13978 for ; Sun, 11 May 2003 05:02: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 QQooee04521 for ; Sun, 11 May 2003 05:02: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 QQooee17124 for ; Sun, 11 May 2003 05:02:05 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 QQooee17114 for ; Sun, 11 May 2003 05:02:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4B522n4011728 for ; Sun, 11 May 2003 01:02: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 BAA21084 for ; Sun, 11 May 2003 01:02:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4B522g02692 for mpls@uu.net; Sun, 11 May 2003 01:02: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 QQooee13157 for ; Sun, 11 May 2003 05:01:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQooee27694; Sun, 11 May 2003 05:00: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 QQooee19611; Sun, 11 May 2003 05:00:10 GMT Received: from chello.nl by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [148.246.66.4]) id QQooee19438; Sun, 11 May 2003 05:00:06 GMT Message-ID: From: "Marci Gunn" To: moodym@UU.NET, mpls@UU.NET Subject: please view your status m0kgl82e Date: Sun, 11 May 2003 20:02:09 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Cool
Introducing Gain Pro Penile Pills
NO.1 Penis Enlargement Pill On The Market!

* Gain 3+ Full Inches In Length
* Expand Your Penis Up To 20% Thicker
* Stop Premature Ejaculation!
* Produce Stronger Erections
* 100% Safe To Take, With No Side Effects
* Fast Distribution Worldwide
* Sold Over 1.2 Million Bottles!
* No Pumps! No Surgery! No Exercises!

PROCEED TO ORDER SITE HERE




Cut off future promos. here. From owner-mpls@UU.NET Sun May 11 12: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 MAA08142 for ; Sun, 11 May 2003 12:52: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 QQoofz16751 for ; Sun, 11 May 2003 16: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 QQoofz15884; Sun, 11 May 2003 16:55:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQoofx03537 for mpls-outgoing; Sun, 11 May 2003 16:20:59 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 QQoofx03532 for ; Sun, 11 May 2003 16:20:40 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 QQoofx22244 for ; Sun, 11 May 2003 16:20: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 QQoofx05251 for ; Sun, 11 May 2003 16:20:16 GMT Received: from blueyonder.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pcow035o.blueyonder.co.uk [195.188.53.121]) id QQoofx05222 for ; Sun, 11 May 2003 16:20:16 GMT Received: from mail pickup service by blueyonder.co.uk with Microsoft SMTPSVC; Sun, 11 May 2003 17:20:12 +0100 Received: from exim3 ([195.188.213.38]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.757.75); Sat, 10 May 2003 18:36:00 +0100 Received: from exim by exim3 with relayed (Exim 4.14) id 19EYGL-0001jA-My for shocks@blueyonder.co.uk; Sat, 10 May 2003 18:35:57 +0100 Received: from [212.24.65.71] (helo=mutt.eurobell.net) by exim3 with smtp (Exim 4.14) id 19EYGJ-0001hy-JT for shocks@blueyonder.co.uk; Sat, 10 May 2003 18:35:55 +0100 Received: (qmail 28206 invoked from network); 10 May 2003 17:35:47 -0000 Received: from unknown (HELO cmr2.ash.ops.us.uu.net) (198.5.241.40) by mailq1.blueyonder.co.uk with SMTP; 10 May 2003 17:35:47 -0000 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 QQoock28848 for ; Sat, 10 May 2003 17:35: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 QQoock28098; Sat, 10 May 2003 17:35:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQooci22085 for mpls-outgoing; Sat, 10 May 2003 17:07:13 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 QQooci22080 for ; Sat, 10 May 2003 17:07:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQooci08211 for ; Sat, 10 May 2003 17:06: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 QQooci25580 for ; Sat, 10 May 2003 17:06:47 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQooci25283 for ; Sat, 10 May 2003 17:06:41 GMT Message-ID: From: Ling Li To: "Mpls (E-mail)" Subject: bandwidth for the backup path in fast reroute Date: Sat, 10 May 2003 13:06:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk in draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt, 6.2 Procedures for Backup Path Computation - The bandwidth to be used is found in the FAST_REROUTE object, if included in the PATH message, and in the SESSION_ATTRIBUTE object otherwise. Local policy may modify the bandwidth to be reserved. Is this a typo "in the SESSION_ATTRIBUTE object"? Should it be " in the SENDER_TSPEC object"? Thanks, Ling Li Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 ======================== From owner-mpls@UU.NET Sun May 11 17:14: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 RAA12840 for ; Sun, 11 May 2003 17:14: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 QQoogr16590 for ; Sun, 11 May 2003 21:17: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 QQoogr16120; Sun, 11 May 2003 21:17:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQoogo06309 for mpls-outgoing; Sun, 11 May 2003 20:33: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 QQoogo06302 for ; Sun, 11 May 2003 20:33:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoogo22337 for ; Sun, 11 May 2003 20:31: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 QQoogo25007 for ; Sun, 11 May 2003 20:31: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 QQoogo24970 for ; Sun, 11 May 2003 20:31:06 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4BKV3O1013057 for ; Sun, 11 May 2003 16:31: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 QAA21433 for ; Sun, 11 May 2003 16:31:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4BKV3Q15189 for mpls@uu.net; Sun, 11 May 2003 16:31: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 QQoogn06045 for ; Sun, 11 May 2003 20:29:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoogn19762 for ; Sun, 11 May 2003 20:29:41 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 QQoogn22218 for ; Sun, 11 May 2003 20:29:40 GMT Received: from psi.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [148.84.21.72]) id QQoogn22195 for ; Sun, 11 May 2003 20:29:39 GMT Message-ID: From: "Kristin Patterson" To: mpls@UU.NET Subject: your cooperation is appreciated i y1w7l71 Date: Tue, 22 Apr 2003 09:07:24 +0000 MIME-Version: 1.0 In-Reply-To: <55dd01c30470$1d0b04a7$bec67b9b@hchxw72> Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Cool

Introducing Gain Pro Penile Pills
NO.1 Penis Enlargement Pill On The Market!

* Gain 3+ Full Inches In Length
* Expand Your Penis Up To 20% Thicker
* Stop Premature Ejaculation!
* Produce Stronger Erections
* 100% Safe To Take, With No Side Effects
* Fast Distribution Worldwide
* Sold Over 1.2 Million Bottles!
* No Pumps! No Surgery! No Exercises!

PROCEED TO ORDER SITE HERE




Cut off future promos. here. From owner-mpls@UU.NET Mon May 12 09:18: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 JAA11174 for ; Mon, 12 May 2003 09:18: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 QQoojd20733 for ; Mon, 12 May 2003 13:21: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 QQoojd20445; Mon, 12 May 2003 13:21:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQooiz10915 for mpls-outgoing; Mon, 12 May 2003 12:20: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 QQooiz10908 for ; Mon, 12 May 2003 12:20: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 QQooiz05455 for ; Mon, 12 May 2003 12:20: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 QQooiz11900 for ; Mon, 12 May 2003 12:20: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 QQooiz11880 for ; Mon, 12 May 2003 12:20:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4CCK2tr017447 for ; Mon, 12 May 2003 08:20: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 IAA27128 for ; Mon, 12 May 2003 08:20:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4CCK2N26461 for mpls@uu.net; Mon, 12 May 2003 08:20: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 QQooiz10864 for ; Mon, 12 May 2003 12:18:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQooiz16065 for ; Mon, 12 May 2003 12:18: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 QQooiz09084 for ; Mon, 12 May 2003 12:18:22 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 QQooiz09072 for ; Mon, 12 May 2003 12:18:21 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4CCI8tr016945; Mon, 12 May 2003 08:18:08 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-1-48.cisco.com [10.86.240.48]) by bucket.cisco.com (Mirapoint) with ESMTP id ADC00071; Mon, 12 May 2003 08:18:07 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , , "'Mpls \(E-mail\)'" Subject: RE: AD review of draft-ietf-mpls-ldp-mib-10.txt Date: Mon, 12 May 2003 08:17:58 -0400 Organization: Cisco Systems, Inc. Message-ID: <031a01c31880$89c3fff0$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155018B8D6D@nl0006exch001u.nl.lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > >4. How many notifications can be generated per second? > > > > Are you asking for a worst case scenario? > > > > In a network where LDP is configured on each device (and not being > > reconfigured) would not expect notifications to be generated once > > sessions are established. So would not quantify X > notifications per > > second. > > > > Maybe another way to ask this question is: how long does > the average > > LDP Session last? > > > > Would say most last longer than a second, but > > would be good to get operator experience here. > > > The thing is that we do not want the network and the NMS to be flooded > (congested) with notifications. If there is a true story that they > will be infrequent, then just add that explanation, and we're > OK. Do remember that a NMS may be receiveing such > notification from many managed devices. So if you had one a > second per managed device, and you had to manage 1000s of > devices, then there is potential still for NMS > overload/congestion. So some words to make people feel > comfortable is goodness. If the evaluation is that there > might be too many notifications, then we may need to add a > throttle object. Bert, I don't understand what you are getting at here. How can any one device know what the other devices in the network are doing? Given your description above, you seem to be advocating that every notification have a throttling value associated with it. Although I totally agree that this is something that is often appropriate on a per-box-basis (indeed my boxes do this), having to put this into every new notification seems difficult to implement at best. Imagine if you have accidentally not set these values across sevearal MIBs to be inconsistent? Imagine the fun the agent has to go throught to appropriately throttle each MIB's notifications. --Tom From owner-mpls@UU.NET Mon May 12 10:06:50 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 KAA13076 for ; Mon, 12 May 2003 10:06: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 QQoojg03472 for ; Mon, 12 May 2003 14:09: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 QQoojg03054; Mon, 12 May 2003 14:09:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQoojd04986 for mpls-outgoing; Mon, 12 May 2003 13:29:17 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 QQoojd04979 for ; Mon, 12 May 2003 13:29:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoojd11145 for ; Mon, 12 May 2003 13:26: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 QQoojd24800 for ; Mon, 12 May 2003 13:26:00 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQoojd24773 for ; Mon, 12 May 2003 13:26:00 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.6/Switch-2.2.0) with ESMTP id h4CDPwP09075 for ; Mon, 12 May 2003 09:25:58 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10BSLR>; Mon, 12 May 2003 15:25:57 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B9032@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: tnadeau@cisco.com, "'Wijnen, Bert (Bert)'" , jcucchiara@mindspring.com, "'Mpls (E-mail)'" Subject: RE: AD review of draft-ietf-mpls-ldp-mib-10.txt Date: Mon, 12 May 2003 15:25:54 +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 I am asking to add some text that notifications of this type are not expected to occur more often than X per second or Z per minute or such. Thanks, Bert > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: maandag 12 mei 2003 14:18 > To: 'Wijnen, Bert (Bert)'; jcucchiara@mindspring.com; 'Mpls (E-mail)' > Subject: RE: AD review of draft-ietf-mpls-ldp-mib-10.txt > > > > > > > >4. How many notifications can be generated per second? > > > > > > Are you asking for a worst case scenario? > > > > > > In a network where LDP is configured on each device (and not being > > > reconfigured) would not expect notifications to be generated once > > > sessions are established. So would not quantify X > > notifications per > > > second. > > > > > > Maybe another way to ask this question is: how long does > > the average > > > LDP Session last? > > > > > > Would say most last longer than a second, but > > > would be good to get operator experience here. > > > > > The thing is that we do not want the network and the NMS to > be flooded > > (congested) with notifications. If there is a true story that they > > will be infrequent, then just add that explanation, and we're > > OK. Do remember that a NMS may be receiveing such > > notification from many managed devices. So if you had one a > > second per managed device, and you had to manage 1000s of > > devices, then there is potential still for NMS > > overload/congestion. So some words to make people feel > > comfortable is goodness. If the evaluation is that there > > might be too many notifications, then we may need to add a > > throttle object. > > Bert, > > I don't understand what you are getting at here. > How can any one device know what the other devices in the > network are doing? Given your description above, you seem to > be advocating that every notification have a throttling value > associated with it. Although I totally agree that this is something > that is often appropriate on a per-box-basis (indeed my boxes > do this), > having to put this into every new notification seems difficult to > implement at best. Imagine if you have accidentally not set > these values across sevearal MIBs to be inconsistent? Imagine > the fun the agent has to go throught to appropriately throttle > each MIB's notifications. > > --Tom > > > > From owner-mpls@UU.NET Mon May 12 11:51: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 LAA21741 for ; Mon, 12 May 2003 11:51: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 QQoojn27696 for ; Mon, 12 May 2003 15:54: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 QQoojn27381; Mon, 12 May 2003 15:54:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQoojk18821 for mpls-outgoing; Mon, 12 May 2003 15:09: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 QQoojk18763 for ; Mon, 12 May 2003 15:08: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 QQoojk08301 for ; Mon, 12 May 2003 15:07: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 QQoojk28529 for ; Mon, 12 May 2003 15:07:52 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 QQoojk28508 for ; Mon, 12 May 2003 15:07:52 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4CDa5rS014336 for ; Mon, 12 May 2003 09:36: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 JAA01852 for ; Mon, 12 May 2003 09:36:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4CDa5D03588 for mpls@uu.net; Mon, 12 May 2003 09:36: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 QQooje05307 for ; Mon, 12 May 2003 13:34:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQooje18646 for ; Mon, 12 May 2003 13:33: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 QQooje13786 for ; Mon, 12 May 2003 13:33: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 QQooje13755 for ; Mon, 12 May 2003 13:33:17 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4CDXC9O012913; Mon, 12 May 2003 09:33:13 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-1-48.cisco.com [10.86.240.48]) by bucket.cisco.com (Mirapoint) with ESMTP id ADC01135; Mon, 12 May 2003 09:33:11 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Wijnen, Bert \(Bert\)'" , , "'Mpls \(E-mail\)'" Subject: RE: AD review of draft-ietf-mpls-ldp-mib-10.txt Date: Mon, 12 May 2003 09:33:01 -0400 Organization: Cisco Systems, Inc. Message-ID: <037401c3188b$05ba44c0$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155018B9032@nl0006exch001u.nl.lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am cool with that! --Tom > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, May 12, 2003 9:26 AM > To: tnadeau@cisco.com; 'Wijnen, Bert (Bert)'; > jcucchiara@mindspring.com; 'Mpls (E-mail)' > Subject: RE: AD review of draft-ietf-mpls-ldp-mib-10.txt > > > I am asking to add some text that notifications of this type > are not expected to occur more often than X per second or Z > per minute or such. > > Thanks, > Bert > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: maandag 12 mei 2003 14:18 > > To: 'Wijnen, Bert (Bert)'; jcucchiara@mindspring.com; 'Mpls > (E-mail)' > > Subject: RE: AD review of draft-ietf-mpls-ldp-mib-10.txt > > > > > > > > > > > > >4. How many notifications can be generated per second? > > > > > > > > Are you asking for a worst case scenario? > > > > > > > > In a network where LDP is configured on each device > (and not being > > > > reconfigured) would not expect notifications to be > generated once > > > > sessions are established. So would not quantify X > > > notifications per > > > > second. > > > > > > > > Maybe another way to ask this question is: how long does > > > the average > > > > LDP Session last? > > > > > > > > Would say most last longer than a second, but > > > > would be good to get operator experience here. > > > > > > > The thing is that we do not want the network and the NMS to > > be flooded > > > (congested) with notifications. If there is a true story that they > > > will be infrequent, then just add that explanation, and we're > > > OK. Do remember that a NMS may be receiveing such > > > notification from many managed devices. So if you had one a > > > second per managed device, and you had to manage 1000s of > > > devices, then there is potential still for NMS > > > overload/congestion. So some words to make people feel > > > comfortable is goodness. If the evaluation is that there > > > might be too many notifications, then we may need to add a > > > throttle object. > > > > Bert, > > > > I don't understand what you are getting at here. > > How can any one device know what the other devices in the > network are > > doing? Given your description above, you seem to be advocating that > > every notification have a throttling value associated with it. > > Although I totally agree that this is something that is often > > appropriate on a per-box-basis (indeed my boxes do this), > > having to put this into every new notification seems difficult to > > implement at best. Imagine if you have accidentally not set > > these values across sevearal MIBs to be inconsistent? Imagine > > the fun the agent has to go throught to appropriately throttle > > each MIB's notifications. > > > > --Tom > > > > > > > > > From owner-mpls@UU.NET Mon May 12 12:25: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 MAA23175 for ; Mon, 12 May 2003 12:25: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 QQoojc05763 for ; Mon, 12 May 2003 13:14: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 QQoojc05113; Mon, 12 May 2003 13:14:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQooiz10611 for mpls-outgoing; Mon, 12 May 2003 12:15:46 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 QQooiz10604 for ; Mon, 12 May 2003 12:15: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 QQooiz25216 for ; Mon, 12 May 2003 12:15: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 QQooiz11698 for ; Mon, 12 May 2003 12:15:12 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 QQooiz11624 for ; Mon, 12 May 2003 12:15:10 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4CCF3A7009603 for ; Mon, 12 May 2003 08:15: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 IAA26835 for ; Mon, 12 May 2003 08:15:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4CCF2g26189 for mpls@uu.net; Mon, 12 May 2003 08:15: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 QQooiy10319 for ; Mon, 12 May 2003 12:13: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 QQooiy20324 for ; Mon, 12 May 2003 12:13: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 QQooiy29867 for ; Mon, 12 May 2003 12:13: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 QQooiy29834 for ; Mon, 12 May 2003 12:13:07 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4CCCttr015493; Mon, 12 May 2003 08:12:56 -0400 (EDT) Received: from tnadeauw2k (che-vpn-cluster-1-48.cisco.com [10.86.240.48]) by bucket.cisco.com (Mirapoint) with ESMTP id ADC00017; Mon, 12 May 2003 08:12:55 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: , "'Wijnen, Bert \(Bert\)'" , "'Mpls \(E-mail\)'" Subject: RE: AD review of draft-ietf-mpls-ldp-mib-10.txt Date: Mon, 12 May 2003 08:12:45 -0400 Organization: Cisco Systems, Inc. Message-ID: <031901c3187f$cf651f90$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3.0.1.32.20030510081805.01742440@pop.mindspring.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 jcucchiara@mindspring.com > Sent: Saturday, May 10, 2003 8:18 AM > To: Wijnen, Bert (Bert); Mpls (E-mail) > Subject: Re: AD review of draft-ietf-mpls-ldp-mib-10.txt > > > > Bert, > > Thanks for this review! > > At 01:53 AM 5/9/03 +0200, Wijnen, Bert (Bert) wrote: > >First a few serious things that need fixing (or a acceptable > >answer): > > > >1. All the documents that contain a MIB module from which > > you IMPORT anything must be listed as normative references. > > I think a few are now under informative and a few may even > > be missing. > > okay. > > > > >2. I see at several place in DESCRIPTION clause of StorageType > > objects this text: > > 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 > > mplsLdpEntityRowStatus to 'destroy(6)'." > > And that is very weird. It seems to allow to change the > storagetype > > object itself (which is a nono). And the cannot destroy is also > > already covered by being a permanent entry. > > The required text from RFC2579 (Storage Type TC) is something aka: > > "The storage type for this conceptual row. Conceptual rows > > having the value 'permanent(4)' need not allow write-access > > to any columnar objects in the row." > > Which you have in some other cases, and which I think expresses > > the same and is correct accoring to RFC2579 requirements. > > mplsLdpEntityAtmLRStorageType has it specified correctly! > > > > Sorry, but am confused by this, if the type is permanent(4), > then the agent does not have to support any subsequent sets > (modifications) to objects in this row, which includes > setting the RowStatus object to destroy, is this correct? > > So then once a row is permanent(4), then the agent does not > need to provide a way to remove/change this row using SNMP, > is this correct? > > We can rephrase this using the text suggested above, but just > want to make sure we understand ;) > > >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? > > > The reference to ADDRESS-FAMILY is because the LDP Spec > (3036) uses in a few TLV and they do specify [RFC1700] as the > reference. Here is the Specific example from the LDP Spec (rfc3036): > > > "Prefix FEC Element value encoding: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix (2) | Address Family | > PreLen | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Address Family > Two octet quantity containing a value from ADDRESS FAMILY > NUMBERS in [RFC1700] that encodes the address family for the > address prefix in the Prefix field." > > > > We do not mean to cause confusion in the MIB, BUT, the LDP > Spec which is "Standards Track" document refers to the > obsoleted document (RFC1700) and the MIB is actually refering > to the LDP Spec. > > In the MIB we are trying to use descriptions based on the LDP > Spec so that folks can use this MIB to configure values for > the LDP TLVs. If we change this description too much, then > the reference back to the LDP Spec is lost. > > Originally we did use the ADDRESS-FAMILY-NUMBERS TC but > changed this for the INET-ADDRESS-MIB which is better for MIB > purposes. > > Please let us know if we can keep the DESCRIPTION as it is or > change it? > > > > 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). > > > >4. How many notifications can be generated per second? > > Are you asking for a worst case scenario? > > In a network where LDP is configured on each device (and not being > reconfigured) > would not expect notifications to be generated once sessions > are established. So would not quantify X notifications per second. > > Maybe another way to ask this question is: how long does the > average LDP Session last? > > Would say most last longer than a second, but > would be good to get operator experience here. My experience and customer feedback has been that there are not often more than O(hundreds) of LDP sessions on a box, and it is unlikely that they all run over the same interface so a catestrophic node failure should not often trigger any other box's sessions to all come down simultaneously which seems like the case you are trying to handle. So I disagree that a throttling/per-second notification variable is needed in the case of LDP. --Tom > > > I worry based on the description clauses. I see a risk that it > > could be many if not implemented properly or with a proper > > throttle? Can you add some text about that? > > There are not huge amounts of LDP sessions on a device and > these (one established) are fairly stable unless an operator > reconfigures or something goes wrong with the network, but > this would fall into a worst case scenario. > > Certainly, would be good to get some operator experience here, but > in my experience, sessions (once established) are fairly > stable as long as the network's physical connections are not > being changed and > LDP is not being reconfigured. > > > > >5. I worry about a statement in a RowStatus DESCRIPTION clause > > (it is doen several times): > > NOTE: This RowStatus object should > > have the same value of the 'mplsLdpEntityRowStatus' > > related to this entry." > > I will agree that that is the ideal situation. But the rowStatus > > should always represent the real status of the row itself. > > If that is not consistent with some other row in another table, > > then that is bad, but it should not be a cause for the > > rowStatus of thos column to take an invalid value. I guess > > you did not mean to say it should... but that is how people > > might read it. > > Okay, I understand I think. We have had many issues with > folks not understanding the relationship of these tables and > essentially, any table that has a configurable row is related > to a row in the > mplsLdpEntityTable. This is outside of the scope of > RowStatus though, so will reword this to remove the "should". > > > > > > >6. MPLS-LDP-GENERIC-MIB > > W: f(mplsldpgen.mi2), (58,17) The first revision should > > match the last update for MODULE-IDENTITY mplsLdpGenericMIB > > I think you just mistyped 2002 instead of 2003. > > yes. typo. > > > > >Nits (some more serious than otehrs)... > >would be nice if they can be fixed: > > > >- I would not use capitals for FULL, READ-ONLY, NEW and such. > > There is the risk that someone wants to know if they have > > special meaning. > >- sect 3.5 under NOTE: This table > > My question: which table? > >- You have in many places a reference aka: > > REFERENCE > > "[RFC3036] LDP Specification, Section on LDP Identifiers." > > Now, once people extract the MIB module from the document (and many > > people do) then you loose the citation. So I always recommend: > > REFERENCE > > "RFC3036, LDP Specification, Section on LDP Identifiers." > >- I see: > > mplsLdpPeerTransportAddrType OBJECT-TYPE > > SYNTAX InetAddressType > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The object specifies how to interpret the address > > for the mplsLdpPeerTransportAddr object." > > .. snip > > > > 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." > > > > 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) > > > > So something aka the next seems better (maybe even rename > > TransportAddr to IntenetAddr: > > > > mplsLdpPeerTransportAddrType OBJECT-TYPE > > SYNTAX InetAddressType > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The type of Internet address for the > > mplsLdpPeerTransportAddr object." > > .. snip > > > > mplsLdpPeerTransportAddr OBJECT-TYPE > > SYNTAX InetAddress > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The Internet address advertized by the peer in the hello > > message or the Hello source address. > > > > The type of this address is determined by the value of > > the mplsLdpPeerTransportAddressType object." > > > > If you do change this, pls check all your InetAddress objects > > okay, thank you for the text. > > > > >- mplsLdpSesKeepaliveTime > > What does value of zero mean? > > The value cannot be zero. This has to be a nonzero, 2 octet > value, which represents the amount of seconds between keep > alive messages negoatiated between the entity and the peer > for that specific session. > > The mplsLdpEntityKeepAliveHoldTimer is the object which > configures this value. This Peer also sends a value and > these are negotiated to be the smaller of the 2 values. > > This object represents the negotiated value. > > Do we put a range on this even though it is read-only and > we already have a range on the configurable counter-part? > > > The range will be the same range as for the > mplsLdpEntityKeepAliveHoldTimer object which is configurable. > > > > >- mplsLdpHelloAdjacencyHoldTimeRem > > could use a UNITS clause > > We debated this. If there are special values (in this case > for 0 and for 0xffff/65535) then if we have a UNITS "seconds" > is it clear that these other values are not seconds?? > > > > I also wonder, since 0xffff has a special meaning,does that mean > > that that is also the max value? If so, a range of > (0..65535) would > > make good sense. > > The object which is used to configure this value for the > entity is mplsLdpEntityHelloHoldTimer which does have a range. > > SO same question as above, do we put a range on this object > even if it is read-only and we already have the range for the > configurable counter-part? > > > > > > >- I see: > > 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." > > s/InSegment/OutSegment/ ?? > > s/MIB's/MIB/ ?? > > > >- I may have said this before. Could the mplsLdpSesUp and > >mplsLdpSesDown > > notification not be combined to mplsLdpSesStateChange? > > The included mplsLdpSesState object will identify if it is > an Up or a > > Down, will it not? > > > Yes, this came up. We wanted to leave this because we do > know NMS apps which do not decode the notifications too much > but resolve by saying this notification matches this other > notification. So one notification causes an alarm and the > other notification clears it. Not sure if it matters too > much in this situation so we can change it as suggested above. > > > > > >- In the DESCRIPTION clauses of your OBJECT-GROUP > definitions, you have > > langauge that talsk about "optional" and/or "required to > implement". > > That is not the goal of the OBJECT-GROUP macro. It is > needed to GROUP > > objects that logically belong together. So the DESCRIPTION should > > have text to explain why these objects belong in one group. > > The "optional" and "required" and susch is language that goes > > in DESCRIPTION clauses of the MODULE-COMPLIANCE GROUP clauses. > > Okay, thanks for this info. > > > > >- Sect 4.1 talks about mplsLdpEntityAtmLabelRangeTable while > the actual > > table name is: mplsLdpEntityAtmLRTable > > Same for FrameRelay and Generic MIB > > Sorry, yes, we changed this and missed the text. > > > > >- mplsLdpEntityAtmTable > > You talk about "extends". I think what the table does is that it > > is a "sparse augments". Your indexes are OK though. > > > Yes, this is true for the mplsLdpEntityFrameRelayTable also. > > > > >- mplsLdpEntityAtmLREntry talks about overlaps and such that may > > (should, can) not occur. But it does not say anything about what > > sort of error to return if someone tries to SNMP SET (or create) > > incorrect values. And It seems like 2 errors are possible: > > - inconcsistentName (if it is part of the (not-accessible) index) > > - inconsistentValue (if it is a value in read-create column) > > Not 100% sure... anyway, better to specify what you want to > > happen than let people guess > > > > Okay we will add to the table description. > > > >- mplsLdpEntityAtmLRRowStatus has in DESCRIPTION clause > > There must exist at least one entry in this > > table for every LDP Entity that has > > 'mplsLdpEntityOptionalParameters' object with > > a value of 'atmSessionParameters'. > > Does not seem right in RowStatus object. Maybe in the Entry > > or Table object? > > I have seen this in multiple RowStatus Objects > > We will check on this. Agree it is better in table/entry description. > > > > >- mplsLdpAtmSesTable talks about 'mplsLdpSessionTable' > > In fact many places in the doc talk about it. > > Seems you renamed the table to mplsLdpSesTable (not sure why, > > cause I find the full Session better... but that is another > > subject). > > Okay, we will check this. Sorry, had a mix and changed to to > be shorter, but sounds like you prefer the longer, i.e. session ;) > > > > >- mplsLdpEntityAtmLRRowStatus talks about > > 'mplsLdpEntityOptionalParameters' > > and so do some other places, but I cannot find the latter object > > We changed the name of the object to be mplsLdpEntityLabelType, so > will update these descriptions. > > > > >- I can live with the security considerations section. > > You might be able to shorten it somewhat if you take the last 3 > > paragraphs of each 9.x section and state that once in its own > > 9.x section. Up to you. > > Okay, we can do that. > > Thanks again for the review. > > -Joan > > > > > >Thanks, > >Bert > > > > From owner-mpls@UU.NET Mon May 12 18:27: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 SAA06982 for ; Mon, 12 May 2003 18:27:06 -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 QQooko02283 for ; Mon, 12 May 2003 22:30: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 QQookn01959; Mon, 12 May 2003 22:29:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQookl10227 for mpls-outgoing; Mon, 12 May 2003 21:48:20 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 QQookl10222 for ; Mon, 12 May 2003 21:48:19 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 QQookl21843 for ; Mon, 12 May 2003 21:46: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 QQookl24791 for ; Mon, 12 May 2003 21:46:45 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQookl24783 for ; Mon, 12 May 2003 21:46:44 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.6/Switch-2.2.0) with ESMTP id h4CLkgY06474 for ; Mon, 12 May 2003 17:46:43 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10B5S8>; Mon, 12 May 2003 23:46:41 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B9204@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: MPLS-TC-MIB revision 6 Date: Mon, 12 May 2003 23:46:32 +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 If you are going to make any more changes, then pls do consider this (which I think got lost between the cracks): > > >Bert> > >We are discussing similar change for RFC3291bis. > > > > > >For TeHopAddress you have: > > > > > > When this TEXTUAL-CONVENTION is used as the syntax of an > > > index object, there may be issues which the limit of 128 > > > sub-identifiers specified in SMIv2, STD 58. In this case, > > > the object definition MUST include a 'SIZE' clause to > > > limit the number of potential instance sub-identifiers." > > > SYNTAX OCTET STRING (SIZE (0..255)) > > > > > >The MIST include a 'SIZE' might be better rephrased as: > > > > > > When this TEXTUAL-CONVENTION is used as the syntax of an > > > index object, there may be issues with the limit of 128 > > > sub-identifiers specified in SMIv2, STD 58. In this case, > > > the object definition MUST include a 'SIZE' clause to > > > limit the number of potential instance sub-identifiers > > > or else the applicable constraints MUST be stated in the > > > appropriate conceptual row DESCRIPTION clauses or in the > > > surrounding documentation if there is no single DESCRIPTION > > > clause that is appropriate." > > > SYNTAX OCTET STRING (SIZE (0..255)) > > > > > >I wonder if SIZE(0..255) is not too generous. The TeHopAddressTypes defined > > >sofar all fit within 16 octets I believe. What sort of (longer) address types > > >do we expect in the future? DNS names? The DNS names is the reason for 255 > > >in RFC3291. If we never expect to use them... maybe the 255 is a bit too > > >much? > > > > > >Thanks, > > >Bert Thanks, Bert From owner-mpls@UU.NET Mon May 12 23:59: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 XAA13702 for ; Mon, 12 May 2003 23:59: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 QQoolk06790 for ; Tue, 13 May 2003 04:02: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 QQoolk06481; Tue, 13 May 2003 04:02:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQooli26756 for mpls-outgoing; Tue, 13 May 2003 03:32:00 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 QQooli26748 for ; Tue, 13 May 2003 03:31:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQooli21948 for ; Tue, 13 May 2003 03:31:24 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 QQooli10877 for ; Tue, 13 May 2003 03:31:23 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 QQooli10868 for ; Tue, 13 May 2003 03:31:23 GMT Received: from dialup-67.75.27.5.dial1.boston1.level3.net ([67.75.27.5] helo=jluciani-laptop) by tisch.mail.mindspring.net with smtp (Exim 3.33 #1) id 19FQVc-0004nW-00; Mon, 12 May 2003 23:31:21 -0400 Message-Id: <3.0.1.32.20030512232906.0185e5f8@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 12 May 2003 23:29:06 -0400 To: "Wijnen, Bert (Bert)" , "Mpls (E-mail)" Subject: Re: MPLS-TC-MIB revision 6 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155018B9204@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 11:46 PM 5/12/03 +0200, Wijnen, Bert (Bert) wrote: >If you are going to make any more changes, then pls do >consider this (which I think got lost between the cracks): Hi Bert, Yes, we'll be updating this one. We have the nits on the line length and can add the suggested text below also. -Thanks, Joan > >> > >Bert> > >We are discussing similar change for RFC3291bis. >> > > >> > >For TeHopAddress you have: >> > > >> > > When this TEXTUAL-CONVENTION is used as the syntax of an >> > > index object, there may be issues which the limit of 128 >> > > sub-identifiers specified in SMIv2, STD 58. In this case, >> > > the object definition MUST include a 'SIZE' clause to >> > > limit the number of potential instance sub-identifiers." >> > > SYNTAX OCTET STRING (SIZE (0..255)) >> > > >> > >The MIST include a 'SIZE' might be better rephrased as: >> > > >> > > When this TEXTUAL-CONVENTION is used as the syntax of an >> > > index object, there may be issues with the limit of 128 >> > > sub-identifiers specified in SMIv2, STD 58. In this case, >> > > the object definition MUST include a 'SIZE' clause to >> > > limit the number of potential instance sub-identifiers >> > > or else the applicable constraints MUST be stated in the >> > > appropriate conceptual row DESCRIPTION clauses or in the >> > > surrounding documentation if there is no single DESCRIPTION >> > > clause that is appropriate." >> > > SYNTAX OCTET STRING (SIZE (0..255)) >> > > >> > >I wonder if SIZE(0..255) is not too generous. The TeHopAddressTypes defined >> > >sofar all fit within 16 octets I believe. What sort of (longer) address types >> > >do we expect in the future? DNS names? The DNS names is the reason for 255 >> > >in RFC3291. If we never expect to use them... maybe the 255 is a bit too >> > >much? >> > > >> > >Thanks, >> > >Bert >Thanks, >Bert > From owner-mpls@UU.NET Tue May 13 00:51: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 AAA14711 for ; Tue, 13 May 2003 00:51: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 QQooln11728 for ; Tue, 13 May 2003 04:54: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 QQooln11633; Tue, 13 May 2003 04:54:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQooll18983 for mpls-outgoing; Tue, 13 May 2003 04:21: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 QQooll18969 for ; Tue, 13 May 2003 04:21:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQooll23755 for ; Tue, 13 May 2003 04:21: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 QQooll13763 for ; Tue, 13 May 2003 04:21:05 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 QQooll13752 for ; Tue, 13 May 2003 04:21:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4D4L2aC029685 for ; Tue, 13 May 2003 00:21: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 AAA11305 for ; Tue, 13 May 2003 00:21:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4D4L2X17217 for mpls@uu.net; Tue, 13 May 2003 00:21: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 QQooll18761 for ; Tue, 13 May 2003 04:19: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 QQooll00317 for ; Tue, 13 May 2003 04:19: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 QQooll07620 for ; Tue, 13 May 2003 04:19:00 GMT Received: from sj-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-1.cisco.com [171.71.177.237]) id QQooll07589 for ; Tue, 13 May 2003 04:19:00 GMT Received: from mutkrishw2k ([10.77.7.246]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4D4IumJ002642 for ; Mon, 12 May 2003 21:18:57 -0700 (PDT) Reply-To: From: "Muthu Krishnan \(mutkrish\)" To: Date: Tue, 13 May 2003 09:48:55 +0530 Message-ID: <001c01c31906$c61096e0$f6074d0a@apac.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C31934.DFC8D2E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C31934.DFC8D2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit subscribe ------=_NextPart_000_001D_01C31934.DFC8D2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

subscribe
------=_NextPart_000_001D_01C31934.DFC8D2E0-- From owner-mpls@UU.NET Tue May 13 05:29: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 FAA01858 for ; Tue, 13 May 2003 05:29: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 QQoomg19669 for ; Tue, 13 May 2003 09:32: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 QQoomg18841; Tue, 13 May 2003 09:32:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQoomd23032 for mpls-outgoing; Tue, 13 May 2003 08:49:09 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 QQoomd23021 for ; Tue, 13 May 2003 08:48: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 QQoomd20875 for ; Tue, 13 May 2003 08:48: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 QQoomd05475 for ; Tue, 13 May 2003 08:48: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 QQoomd05459 for ; Tue, 13 May 2003 08:48:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4D8m2mu021686 for ; Tue, 13 May 2003 04: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 EAA22788 for ; Tue, 13 May 2003 04:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4D8m2900633 for mpls@uu.net; Tue, 13 May 2003 04:48: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 QQoomd22873 for ; Tue, 13 May 2003 08:46:44 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 QQoomd11869 for ; Tue, 13 May 2003 08:46: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 QQoomd00116 for ; Tue, 13 May 2003 08:46:30 GMT Received: from hoemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQoomd00108 for ; Tue, 13 May 2003 08:46:30 GMT Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4D8kSB17002 for ; Tue, 13 May 2003 04:46:28 -0400 (EDT) Received: from new-wopr.eng.ascend.com by horh1.emsr.lucent.com (8.11.6+Sun/EMS-1.5 Solaris/emsr) id h4D8kRt18283 for ; Tue, 13 May 2003 04:46:27 -0400 (EDT) Received: from comet.eng.ascend.com (comet.eng.ascend.com [135.140.53.43]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id h4D8kQS23744 for ; Tue, 13 May 2003 01:46:26 -0700 (PDT) Received: from lucent.com (apache.india.ascend.com [135.254.196.31]) by comet.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id BAA18381 for ; Tue, 13 May 2003 01:46:25 -0700 (PDT) Message-ID: <3EC0B2BD.33BCA7BA@lucent.com> Date: Tue, 13 May 2003 14:24:21 +0530 From: Saravana Prasad X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit auth ebc1fdfd subscribe mpls psaravan@lucent.com From owner-mpls@UU.NET Tue May 13 05:54: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 FAA02294 for ; Tue, 13 May 2003 05:54: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 QQoomh10549 for ; Tue, 13 May 2003 09:58: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 QQoomh10381; Tue, 13 May 2003 09:57:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQoomf14237 for mpls-outgoing; Tue, 13 May 2003 09:22: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 QQoomf14213 for ; Tue, 13 May 2003 09:21:58 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 QQoomf21986 for ; Tue, 13 May 2003 09: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 QQoomf28894 for ; Tue, 13 May 2003 09:21: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 QQoomf28881 for ; Tue, 13 May 2003 09:21:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4D9L2mq009945 for ; Tue, 13 May 2003 05:21: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 FAA24055 for ; Tue, 13 May 2003 05:21:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4D9L2v03631 for mpls@uu.net; Tue, 13 May 2003 05:21: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 QQoomf13997 for ; Tue, 13 May 2003 09:19: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 QQoomf17817 for ; Tue, 13 May 2003 09:18:56 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 QQoomf24706 for ; Tue, 13 May 2003 09:18:55 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQoomf24698 for ; Tue, 13 May 2003 09:18:55 GMT Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4D9IrI28931 for ; Tue, 13 May 2003 05:18:53 -0400 (EDT) Received: from new-wopr.eng.ascend.com by horh1.emsr.lucent.com (8.11.6+Sun/EMS-1.5 Solaris/emsr) id h4D9Iqt11353 for ; Tue, 13 May 2003 05:18:52 -0400 (EDT) Received: from comet.eng.ascend.com (comet.eng.ascend.com [135.140.53.43]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id h4D9IpS24651 for ; Tue, 13 May 2003 02:18:51 -0700 (PDT) Received: from lucent.com (apache.india.ascend.com [135.254.196.31]) by comet.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id CAA20209 for ; Tue, 13 May 2003 02:18:50 -0700 (PDT) Message-ID: <3EC0BA56.E20B70D0@lucent.com> Date: Tue, 13 May 2003 14:56:46 +0530 From: Saravana Prasad X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: auth ebc1fdfd subscribe mpls psaravan@lucent.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit auth ebc1fdfd subscribe mpls psaravan@lucent.com From owner-mpls@UU.NET Tue May 13 15:53:26 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 PAA27430 for ; Tue, 13 May 2003 15:53: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 QQoonv05278 for ; Tue, 13 May 2003 19:56: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 QQoonv05132; Tue, 13 May 2003 19:56:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQoont05269 for mpls-outgoing; Tue, 13 May 2003 19:24:40 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 QQoont05262 for ; Tue, 13 May 2003 19:24:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoont29951 for ; Tue, 13 May 2003 19: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 QQoont26699 for ; Tue, 13 May 2003 19:23:22 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQoont26661 for ; Tue, 13 May 2003 19:23:19 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.6/Switch-2.2.0) with ESMTP id h4DJNHd07930 for ; Tue, 13 May 2003 15:23:18 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10CRKZ>; Tue, 13 May 2003 21:23:17 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B951F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Loa Andersson (E-mail)" Cc: "Mpls (E-mail)" , "Mike MacFaden (E-mail)" Subject: MIB document status (from AD viewpoint) Date: Tue, 13 May 2003 21:23:15 +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 This is where I think we are. I am using the revisions of the documents as I have them. Sorry Loa... I saw that you wanted to push various docs to IESG... but authors are still working on them... so? These are the ones I assume we need to get done: transmission -- RFC 2578 [RFC2578] | +- mplsStdMIB -- MPLS-TC-STD-MIB | | | +- mplsTCStdMIB -- MPLS-TC-STD-MIB | | | +- mplsLsrStdMIB -- MPLS-LSR-STD-MIB | | | +- mplsTeStdMIB -- MPLS-TE-STD-MIB | | | +- mplsLdpStdMIB -- MPLS-LDP-STD-MIB | | | +- mplsLdpAtmStdMIB -- MPLS-LDP-ATM-STD-MIB | | | +- mplsLdpFrameRelayStdMIB -- MPLS-LDP-FRAME-RELAY-STD-MIB | | | +- mplsLdpGenericStdMIB -- MPLS-LDP-GENERIC-STD-MIB | | | +- mplsFTNStdMIB -- MPLS-FTN-STD-MIB | +- teLinkStdMIB -- TE-LINK-STD-MIB I believe most (if not all) docs still need to adapt to the new naming scheme presented above (by Cheenu). That means changing the MIB Module names and such, but also make sure that cross-references etc are updated. - draft-ietf-mpls-tc-mib-06.txt Pretty good shape. We saw a few nits, and Joan has promised a revision 7. - draft-ietf-mpls-lsr-mib-10-preview.txt I got a preview from tom. I have commented... I expect to see a WG version posted to internet-drafts rsn. I still need to do detailed review. - draft-ietf-mpls-te-mib-10-preview.txt I got a preview from Arun, but in a word document. My mib checking tools do not work on WORD documents. I did a quick check. But this one seems to be FAR FROM ready. And many of the "issues/concerns" we have discussed for the whole set of MIB documents still return in this one. - draft-ietf-mpls-ldp-mib-10.txt Contains 4 mib modules. I did a review and posted comments to the MPLS WG list a few days back. Joan will probably do another rev. - draft-ietf-mpls-ftn-mib-06.txt I believe Cheenu already found a number of issues to be resolved. I have send additional comments - draft-ietf-mpls-telink-mib-01.txt I have send a list of comments. Martin promised a new revision Thanks, Bert From owner-mpls@UU.NET Wed May 14 10:44:26 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 KAA20408 for ; Wed, 14 May 2003 10:44: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 QQooqt23418 for ; Wed, 14 May 2003 14:47: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 QQooqt23335; Wed, 14 May 2003 14:47:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQooqq19808 for mpls-outgoing; Wed, 14 May 2003 14:08: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 QQooqq19777 for ; Wed, 14 May 2003 14:08:40 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 QQooqq29811 for ; Wed, 14 May 2003 14:06: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 QQooqq28445 for ; Wed, 14 May 2003 14:06:42 GMT Received: from web20710.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20710.mail.yahoo.com [216.136.226.183]) id QQooqq28431 for ; Wed, 14 May 2003 14:06:41 GMT Message-ID: <20030514140640.62067.qmail@web20710.mail.yahoo.com> Received: from [210.118.108.254] by web20710.mail.yahoo.com via HTTP; Wed, 14 May 2003 15:06:40 BST Date: Wed, 14 May 2003 15:06:40 +0100 (BST) From: "=?iso-8859-1?q?Sugar,=20Sylvia?=" Subject: Advertising Routes learnt from PE to PE 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 Hi, WIll a PE router ever advertise a route it learns from another PE router to some other PE router. I dont think it will ever do that as all the PE routers are IBGP peers and would generally be in full mesh. Is there any case when this might happen .. i.e. a PE router advertises a Route learnt from one PE to another PE. How can one do that .. because IMHO the label that will be advertised by the former PE router will be for the PE router to which he sends the UPDATE. How can this PE router advertise another PE router the same label? Moreover, if for some reason he has to .. does he assign a new label and then advertise? ANy comments on this would be very helpful! Silviya Sugar __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From owner-mpls@UU.NET Wed May 14 10:55: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 KAA20584 for ; Wed, 14 May 2003 10:54: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 QQooqt12271 for ; Wed, 14 May 2003 14: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 QQooqt12104; Wed, 14 May 2003 14:57:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQooqr21586 for mpls-outgoing; Wed, 14 May 2003 14:19: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 QQooqr21571 for ; Wed, 14 May 2003 14:19: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 QQooqr28595 for ; Wed, 14 May 2003 14:19: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 QQooqr11090 for ; Wed, 14 May 2003 14:19:22 GMT Received: from mx.pccwbtn.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx.pccwbtn.com [63.216.0.99]) id QQooqr11073 for ; Wed, 14 May 2003 14:19:22 GMT Received: from laptop ([207.226.249.243]) (authenticated bits=0) by mx.pccwbtn.com (8.12.3/8.12.3) with ESMTP id h4EEJLtn047366; Wed, 14 May 2003 10:19:21 -0400 (EDT) (envelope-from rmartin@btnusa.com) Reply-To: From: "Rod Martin" To: "Sugar, Sylvia" , Cc: Subject: RE: Advertising Routes learnt from PE to PE Date: Wed, 14 May 2003 10:19:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20030514140640.62067.qmail@web20710.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Sylvia, In this scenario, this would be a RR, speaking to terminating PE, in which you would use the BGP statement under the vpn4 family: Next-hop-unchanged. Rod ROD L. MARTIN CCDP, CFE, JNCIS, CFOE (OFFICE) 703-621-1646 (MOBILE) 703-967-9503 rmartin@btnaccess.com http://www.mplsvpn.net http://www.mplscon.com http://www.vpnc.org -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Sugar, Sylvia Sent: Wednesday, May 14, 2003 10:07 AM To: mpls-ops@mplsrc.com Cc: mpls@UU.NET Subject: Advertising Routes learnt from PE to PE Hi, WIll a PE router ever advertise a route it learns from another PE router to some other PE router. I dont think it will ever do that as all the PE routers are IBGP peers and would generally be in full mesh. Is there any case when this might happen .. i.e. a PE router advertises a Route learnt from one PE to another PE. How can one do that .. because IMHO the label that will be advertised by the former PE router will be for the PE router to which he sends the UPDATE. How can this PE router advertise another PE router the same label? Moreover, if for some reason he has to .. does he assign a new label and then advertise? ANy comments on this would be very helpful! Silviya Sugar __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.481 / Virus Database: 277 - Release Date: 5/13/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.481 / Virus Database: 277 - Release Date: 5/13/2003 From owner-mpls@UU.NET Wed May 14 11:28:26 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 LAA21772 for ; Wed, 14 May 2003 11:28: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 QQooqw14262 for ; Wed, 14 May 2003 15:31: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 QQooqw14233; Wed, 14 May 2003 15:31:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQooqt24248 for mpls-outgoing; Wed, 14 May 2003 14:52: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 QQooqt24226 for ; Wed, 14 May 2003 14:52:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQooqt25838 for ; Wed, 14 May 2003 14:52: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 QQooqt24439 for ; Wed, 14 May 2003 14:52:04 GMT Received: from mta1.wss.scd.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mta1.wss.scd.yahoo.com [66.218.85.32]) id QQooqt24415 for ; Wed, 14 May 2003 14:52:03 GMT Received: from ISOVAIO001 (65.213.193.34) by mta1.wss.scd.yahoo.com (7.0.015.1) (authenticated as ferit@isocore.com) id 3EBA91C1003A90B6; Wed, 14 May 2003 07:52:02 -0700 Reply-To: From: "Ferit Yegenoglu" To: "'Sugar, Sylvia'" , Cc: Subject: RE: Advertising Routes learnt from PE to PE Date: Wed, 14 May 2003 10:51:58 -0400 Organization: Isocore Message-ID: <000901c31a28$6298f030$22c1d541@ISOVAIO001> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20030514140640.62067.qmail@web20710.mail.yahoo.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sylvia, One possible scenario where this could happen is the hub-spoke BGP/MPLS VPN. In this case the spoke PEs advertise their routes with a Route Target value "Hub". The hub PE imports these routes and advertises them to the CE router in the hub site. These routes are advertised across the hub site and eventually back to the PE hub router via a different interface. The PE hub router then readvertises these routes to the spoke PEs with a Route Target value "Spoke" and a different VPN label. Ferit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar, > Sylvia > Sent: Wednesday, May 14, 2003 10:07 AM > To: mpls-ops@mplsrc.com > Cc: mpls@UU.NET > Subject: Advertising Routes learnt from PE to PE > > Hi, > WIll a PE router ever advertise a route it learns from another PE router > to some other PE router. > I dont think it will ever do that as all the PE routers are IBGP peers and > would generally be in > full mesh. > > Is there any case when this might happen .. i.e. a PE router advertises a > Route learnt from one PE > to another PE. How can one do that .. because IMHO the label that will be > advertised by the former > PE router will be for the PE router to which he sends the UPDATE. How can > this PE router advertise > another PE router the same label? > > Moreover, if for some reason he has to .. does he assign a new label and > then advertise? > > ANy comments on this would be very helpful! > > Silviya Sugar > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer From owner-mpls@UU.NET Wed May 14 15:42: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 PAA02920 for ; Wed, 14 May 2003 15:42: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 QQoorn18667 for ; Wed, 14 May 2003 19:45: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 QQoorn18242; Wed, 14 May 2003 19:45:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQoorj23748 for mpls-outgoing; Wed, 14 May 2003 18:50:26 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 QQoorj23731 for ; Wed, 14 May 2003 18:50:22 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 QQoorj13134 for ; Wed, 14 May 2003 18:50: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 QQoorj26116 for ; Wed, 14 May 2003 18:50:17 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 QQoorj25972 for ; Wed, 14 May 2003 18:50:11 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4EIo5uT009759 for ; Wed, 14 May 2003 14:50: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 OAA14256 for ; Wed, 14 May 2003 14:50:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4EIo4j05638 for mpls@uu.net; Wed, 14 May 2003 14:50:04 -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 QQoorj23589 for ; Wed, 14 May 2003 18: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 QQoori21362 for ; Wed, 14 May 2003 18:44: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 QQoori16916 for ; Wed, 14 May 2003 18:44: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 QQoori16899 for ; Wed, 14 May 2003 18:44:29 GMT Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4EIiGfK001658; Wed, 14 May 2003 11:44:17 -0700 (PDT) Received: from [10.1.1.9] (sjc-vpn3-751.cisco.com [10.21.66.239]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAZ04262; Wed, 14 May 2003 11:44:13 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 14 May 2003 14:44:12 -0400 Subject: Re: [MPLS-OPS]: Re: Advertising Routes learnt from PE to PE From: Aamer Akhter To: Spice Sylvia , , CC: Message-ID: In-Reply-To: <20030514175846.73641.qmail@web20701.mail.yahoo.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 On 5/14/03 1:58 PM, "Spice Sylvia" wrote: > Hello Aamer, > > Why would the "rd" have changed? |--------1 HUBCE HUBPE |--------2 Suppose the sites prefixes are sent to the HUBPE, which advertises to HUBCE over link 2 (lets' call this vrf2), the HUBCE advertises this back to the HUBPE over link 1 (vrf1). vrf2 and vrf1 will have different rd's because they are different vrfs. > > Is this a new feature? > > How does changing RD help? > > > Aamer Akhter wrote: > On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote: > >> >> Sylvia, >> >> One possible scenario where this could happen is the hub-spoke BGP/MPLS >> VPN. In this case the spoke PEs advertise their routes with a Route >> Target value "Hub". The hub PE imports these routes and advertises them >> to the CE router in the hub site. These routes are advertised across the >> hub site and eventually back to the PE hub router via a different >> interface. The PE hub router then readvertises these routes to the spoke >> PEs with a Route Target value "Spoke" and a different VPN label. > > But to BGP, these "readvertised" prefixes are not the same. The rd will have > changed. > >> >> Ferit >> >> >> >>> -----Original Message----- >>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar, >>> Sylvia >>> Sent: Wednesday, May 14, 2003 10:07 AM >>> To: mpls-ops@mplsrc.com >>> Cc: mpls@UU.NET >>> Subject: Advertising Routes learnt from PE to PE >>> >>> Hi, >>> WIll a PE router ever advertise a route it learns from another PE >> router >>> to some other PE router. >>> I dont think it will ever do that as all the PE routers are IBGP peers >> and >>> would generally be in >>> full mesh. >>> >>> Is there any case when this might happen .. i.e. a PE router >> advertises a >>> Route learnt from one PE >>> to another PE. How can one do that .. because IMHO the label that will >> be >>> advertised by the former >>> PE router will be for the PE router to which he sends the UPDATE. How >> can >>> this PE router advertise >>> another PE router the same label? >>> >>> Moreover, if for some reason he has to .. does he assign a new label >> and >>> then advertise? >>> >>> ANy comments on this would be very helpful! >>> >>> Silviya Sugar >>> >>> __________________________________________________ >>> Yahoo! Plus >>> For a better Internet experience >>> http://www.yahoo.co.uk/btoffer >> -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems From owner-mpls@UU.NET Wed May 14 15:43:29 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 PAA03006 for ; Wed, 14 May 2003 15:43:29 -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 QQoorn20818 for ; Wed, 14 May 2003 19:46:32 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 QQoorn20724; Wed, 14 May 2003 19:46:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQoork27625 for mpls-outgoing; Wed, 14 May 2003 19:00: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 QQoork25975 for ; Wed, 14 May 2003 19:00:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoorj07075 for ; Wed, 14 May 2003 18:56: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 QQoorj07050 for ; Wed, 14 May 2003 18:56: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 QQoorj07012 for ; Wed, 14 May 2003 18:56:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4EIu2uT011842 for ; Wed, 14 May 2003 14:56: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 OAA14871 for ; Wed, 14 May 2003 14:56:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4EIu2205960 for mpls@uu.net; Wed, 14 May 2003 14:56: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 QQooqw16072 for ; Wed, 14 May 2003 15:40:55 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 QQooqw23259 for ; Wed, 14 May 2003 15:40:12 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 QQooqw09389 for ; Wed, 14 May 2003 15:40:12 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 QQooqw09355 for ; Wed, 14 May 2003 15:40:11 GMT Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4EFdIWM025112; Wed, 14 May 2003 08:39:18 -0700 (PDT) Received: from [10.1.1.9] (sjc-vpn3-751.cisco.com [10.21.66.239]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAY89432; Wed, 14 May 2003 08:39:16 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 14 May 2003 11:39:15 -0400 Subject: Re: Advertising Routes learnt from PE to PE From: Aamer Akhter To: , "'Sugar, Sylvia'" , CC: Message-ID: In-Reply-To: <000901c31a28$6298f030$22c1d541@ISOVAIO001> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote: > > Sylvia, > > One possible scenario where this could happen is the hub-spoke BGP/MPLS > VPN. In this case the spoke PEs advertise their routes with a Route > Target value "Hub". The hub PE imports these routes and advertises them > to the CE router in the hub site. These routes are advertised across the > hub site and eventually back to the PE hub router via a different > interface. The PE hub router then readvertises these routes to the spoke > PEs with a Route Target value "Spoke" and a different VPN label. But to BGP, these "readvertised" prefixes are not the same. The rd will have changed. > > Ferit > > > >> -----Original Message----- >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar, >> Sylvia >> Sent: Wednesday, May 14, 2003 10:07 AM >> To: mpls-ops@mplsrc.com >> Cc: mpls@UU.NET >> Subject: Advertising Routes learnt from PE to PE >> >> Hi, >> WIll a PE router ever advertise a route it learns from another PE > router >> to some other PE router. >> I dont think it will ever do that as all the PE routers are IBGP peers > and >> would generally be in >> full mesh. >> >> Is there any case when this might happen .. i.e. a PE router > advertises a >> Route learnt from one PE >> to another PE. How can one do that .. because IMHO the label that will > be >> advertised by the former >> PE router will be for the PE router to which he sends the UPDATE. How > can >> this PE router advertise >> another PE router the same label? >> >> Moreover, if for some reason he has to .. does he assign a new label > and >> then advertise? >> >> ANy comments on this would be very helpful! >> >> Silviya Sugar >> >> __________________________________________________ >> Yahoo! Plus >> For a better Internet experience >> http://www.yahoo.co.uk/btoffer > -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems From owner-mpls@UU.NET Wed May 14 16:26: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 QAA04192 for ; Wed, 14 May 2003 16:26: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 QQoorp05988 for ; Wed, 14 May 2003 20:29: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 QQoorp05871; Wed, 14 May 2003 20:29:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQoorn17211 for mpls-outgoing; Wed, 14 May 2003 19:47: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 QQoorn17200 for ; Wed, 14 May 2003 19:47:02 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 QQoorn08888 for ; Wed, 14 May 2003 19:45: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 QQoorn17864 for ; Wed, 14 May 2003 19:45:26 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 QQoorn17851 for ; Wed, 14 May 2003 19:45:25 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4EJDE1M021158 for ; Wed, 14 May 2003 15:13:14 -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 PAA16606 for ; Wed, 14 May 2003 15:13:14 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4EJDEP07775 for mpls@uu.net; Wed, 14 May 2003 15:13: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 QQoork13435 for ; Wed, 14 May 2003 19:10:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoork25064 for ; Wed, 14 May 2003 19:10:21 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 QQoork29268 for ; Wed, 14 May 2003 19:10:21 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 QQoork29255 for ; Wed, 14 May 2003 19:10:20 GMT Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4EJA1fK010041; Wed, 14 May 2003 12:10:02 -0700 (PDT) Received: from [10.1.1.9] (sjc-vpn3-751.cisco.com [10.21.66.239]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAZ06442; Wed, 14 May 2003 12:09:59 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 14 May 2003 15:09:57 -0400 Subject: Re: [MPLS-OPS]: Re: Advertising Routes learnt from PE to PE From: Aamer Akhter To: Spice Sylvia , , CC: Message-ID: In-Reply-To: <20030514190205.80264.qmail@web20707.mail.yahoo.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 On 5/14/03 3:02 PM, "Spice Sylvia" wrote: > Pardon me if I am not clear, > > Why would RD have changed? The prefix is no longer is the same vrf. > > Same IP route to same prefix but why different RD? > > Why would one not give both to same vrf1 in hub and spoke? Both what? Once vrf2 learns the routes from a spoke PE, it's not going to readvertise that prefix to other spokes because of ibgp behavior. To get around this you have to advertise the prefix to the hub PE which advertises the prefix back to you in ANOTHER vrf. At this point, it's not the same vpnv4 prefix, so you can export and advertise to the spoke PEs. > > > Aamer Akhter wrote: > On 5/14/03 1:58 PM, "Spice Sylvia" wrote: > >> Hello Aamer, >> >> Why would the "rd" have changed? > > |--------1 > HUBCE HUBPE > |--------2 > > Suppose the sites prefixes are sent to the HUBPE, which advertises to HUBCE > over link 2 (lets' call this vrf2), the HUBCE advertises this back to the > HUBPE over link 1 (vrf1). vrf2 and vrf1 will have different rd's because > they are different vrfs. > >> >> Is this a new feature? >> >> How does changing RD help? >> >> >> Aamer Akhter wrote: >> On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote: >> >>> >>> Sylvia, >>> >>> One possible scenario where this could happen is the hub-spoke BGP/MPLS >>> VPN. In this case the spoke PEs advertise their routes with a Route >>> Target value "Hub". The hub PE imports these routes and advertises them >>> to the CE router in the hub site. These routes are advertised across the >>> hub site and eventually back to the PE hub router via a different >>> interface. The PE hub router then readvertises these routes to the spoke >>> PEs with a Route Target value "Spoke" and a different VPN label. >> >> But to BGP, these "readvertised" prefixes are not the same. The rd will have >> changed. >> >>> >>> Ferit >>> >>> >>> >>>> -----Original Message----- >>>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar, >>>> Sylvia >>>> Sent: Wednesday, May 14, 2003 10:07 AM >>>> To: mpls-ops@mplsrc.com >>>> Cc: mpls@UU.NET >>>> Subject: Advertising Routes learnt from PE to PE >>>> >>>> Hi, >>>> WIll a PE router ever advertise a route it learns from another PE >>> router >>>> to some other PE router. >>>> I dont think it will ever do that as all the PE routers are IBGP peers >>> and >>>> would generally be in >>>> full mesh. >>>> >>>> Is there any case when this might happen .. i.e. a PE router >>> advertises a >>>> Route learnt from one PE >>>> to another PE. How can one do that .. because IMHO the label that will >>> be >>>> advertised by the former >>>> PE router will be for the PE router to which he sends the UPDATE. How >>> can >>>> this PE router advertise >>>> another PE router the same label? >>>> >>>> Moreover, if for some reason he has to .. does he assign a new label >>> and >>>> then advertise? >>>> >>>> ANy comments on this would be very helpful! >>>> >>>> Silviya Sugar >>>> >>>> __________________________________________________ >>>> Yahoo! Plus >>>> For a better Internet experience >>>> http://www.yahoo.co.uk/btoffer >>> -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems From owner-mpls@UU.NET Wed May 14 17:33: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 RAA06771 for ; Wed, 14 May 2003 17:33: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 QQooru28664 for ; Wed, 14 May 2003 21:36: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 QQooru28621; Wed, 14 May 2003 21:36:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQoorq09787 for mpls-outgoing; Wed, 14 May 2003 20:38:47 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 QQoorq09778 for ; Wed, 14 May 2003 20:38:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoorq12544 for ; Wed, 14 May 2003 20:36: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 QQoorq19663 for ; Wed, 14 May 2003 20:36: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 QQoorq19637 for ; Wed, 14 May 2003 20:36:37 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4EKaY1M025937 for ; Wed, 14 May 2003 16:36:35 -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 QAA24620 for ; Wed, 14 May 2003 16:36:34 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4EKaYW17084 for mpls@uu.net; Wed, 14 May 2003 16:36: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 QQoork05435 for ; Wed, 14 May 2003 19:03: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 QQoork24678 for ; Wed, 14 May 2003 19:02: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 QQoork15526 for ; Wed, 14 May 2003 19:02:07 GMT Received: from web20707.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20707.mail.yahoo.com [216.136.226.180]) id QQoork15508 for ; Wed, 14 May 2003 19:02:06 GMT Message-ID: <20030514190205.80264.qmail@web20707.mail.yahoo.com> Received: from [219.65.132.16] by web20707.mail.yahoo.com via HTTP; Wed, 14 May 2003 20:02:05 BST Date: Wed, 14 May 2003 20:02:05 +0100 (BST) From: =?iso-8859-1?q?Spice=20Sylvia?= Subject: Re: [MPLS-OPS]: Re: Advertising Routes learnt from PE to PE To: Aamer Akhter , ferit@isocore.com, mpls-ops@mplsrc.com Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1577394287-1052938925=:79163" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk --0-1577394287-1052938925=:79163 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Pardon me if I am not clear, Why would RD have changed? Same IP route to same prefix but why different RD? Why would one not give both to same vrf1 in hub and spoke? Aamer Akhter wrote: On 5/14/03 1:58 PM, "Spice Sylvia" wrote: > Hello Aamer, > > Why would the "rd" have changed? |--------1 HUBCE HUBPE |--------2 Suppose the sites prefixes are sent to the HUBPE, which advertises to HUBCE over link 2 (lets' call this vrf2), the HUBCE advertises this back to the HUBPE over link 1 (vrf1). vrf2 and vrf1 will have different rd's because they are different vrfs. > > Is this a new feature? > > How does changing RD help? > > > Aamer Akhter wrote: > On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote: > >> >> Sylvia, >> >> One possible scenario where this could happen is the hub-spoke BGP/MPLS >> VPN. In this case the spoke PEs advertise their routes with a Route >> Target value "Hub". The hub PE imports these routes and advertises them >> to the CE router in the hub site. These routes are advertised across the >> hub site and eventually back to the PE hub router via a different >> interface. The PE hub router then readvertises these routes to the spoke >> PEs with a Route Target value "Spoke" and a different VPN label. > > But to BGP, these "readvertised" prefixes are not the same. The rd will have > changed. > >> >> Ferit >> >> >> >>> -----Original Message----- >>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar, >>> Sylvia >>> Sent: Wednesday, May 14, 2003 10:07 AM >>> To: mpls-ops@mplsrc.com >>> Cc: mpls@UU.NET >>> Subject: Advertising Routes learnt from PE to PE >>> >>> Hi, >>> WIll a PE router ever advertise a route it learns from another PE >> router >>> to some other PE router. >>> I dont think it will ever do that as all the PE routers are IBGP peers >> and >>> would generally be in >>> full mesh. >>> >>> Is there any case when this might happen .. i.e. a PE router >> advertises a >>> Route learnt from one PE >>> to another PE. How can one do that .. because IMHO the label that will >> be >>> advertised by the former >>> PE router will be for the PE router to which he sends the UPDATE. How >> can >>> this PE router advertise >>> another PE router the same label? >>> >>> Moreover, if for some reason he has to .. does he assign a new label >> and >>> then advertise? >>> >>> ANy comments on this would be very helpful! >>> >>> Silviya Sugar >>> >>> __________________________________________________ >>> Yahoo! Plus >>> For a better Internet experience >>> http://www.yahoo.co.uk/btoffer >> -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml --------------------------------- Yahoo! Plus - For a better Internet experience --0-1577394287-1052938925=:79163 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Pardon me if I am not clear,
 
Why would RD have changed?
 
Same IP route to same prefix but why different RD?
 
Why would one not give both to same vrf1 in hub and spoke?


Aamer Akhter <aakhter@cisco.com> wrote:
On 5/14/03 1:58 PM, "Spice Sylvia" wrote:

> Hello Aamer,
>
> Why would the "rd" have changed?

|--------1
HUBCE HUBPE
|--------2

Suppose the sites prefixes are sent to the HUBPE, which advertises to HUBCE
over link 2 (lets' call this vrf2), the HUBCE advertises this back to the
HUBPE over link 1 (vrf1). vrf2 and vrf1 will have different rd's because
they are different vrfs.

>
> Is this a new feature?
>
> How does changing RD help?
>
>
> Aamer Akhter wrote:
> On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote:
>
>>
>> Sylvia,
>>
>> One possible scenario where this could happen is the hub-spoke BGP/MPLS
>> VPN. In this case the spoke PEs advertise their routes with a Route
>> Target val! ue "Hub". The hub PE imports these routes and advertises them
>> to the CE router in the hub site. These routes are advertised across the
>> hub site and eventually back to the PE hub router via a different
>> interface. The PE hub router then readvertises these routes to the spoke
>> PEs with a Route Target value "Spoke" and a different VPN label.
>
> But to BGP, these "readvertised" prefixes are not the same. The rd will have
> changed.
>
>>
>> Ferit
>>
>>
>>
>>> -----Original Message-----
>>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar,
>>> Sylvia
>>> Sent: Wednesday, May 14, 2003 10:07 AM
>>> To: mpls-ops@mplsrc.com
>>> Cc: mpls@UU.NET
>>> Subject: Advertising Routes learnt from PE to PE
>>>
>>> Hi,
>>> WIll a PE rou! ter ever advertise a route it learns from another PE
>> route r
>>> to some other PE router.
>>> I dont think it will ever do that as all the PE routers are IBGP peers
>> and
>>> would generally be in
>>> full mesh.
>>>
>>> Is there any case when this might happen .. i.e. a PE router
>> advertises a
>>> Route learnt from one PE
>>> to another PE. How can one do that .. because IMHO the label that will
>> be
>>> advertised by the former
>>> PE router will be for the PE router to which he sends the UPDATE. How
>> can
>>> this PE router advertise
>>> another PE router the same label?
>>>
>>> Moreover, if for some reason he has to .. does he assign a new label
>> and
>>> then advertise?
>>>
>>> ANy comments on this would be very helpful!
>>>
>>> Silviya Sugar
>&! gt;>
>>> __________________________________________________
>>> Yahoo! Plus
>>> For a better Internet experience
>>> http://www.yahoo.co.uk/btoffer
>>

--
Aamer Akhter / aa@cisco.com
NSITE - cisco Systems


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


Yahoo! Plus - For a better Internet experience
--0-1577394287-1052938925=:79163-- From owner-mpls@UU.NET Wed May 14 17:33:49 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 RAA06786 for ; Wed, 14 May 2003 17:33: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 QQooru28916 for ; Wed, 14 May 2003 21:36: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 QQooru28650; Wed, 14 May 2003 21:36:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQoorq09772 for mpls-outgoing; Wed, 14 May 2003 20:38:22 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 QQoorq09750 for ; Wed, 14 May 2003 20:37:50 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 QQoorq09819 for ; Wed, 14 May 2003 20:36: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 QQoorq20037 for ; Wed, 14 May 2003 20:36:49 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 QQoorq20013 for ; Wed, 14 May 2003 20:36:48 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4EKakuT010371 for ; Wed, 14 May 2003 16:36:46 -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 QAA24636 for ; Wed, 14 May 2003 16:36:46 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4EKakC17089 for mpls@uu.net; Wed, 14 May 2003 16:36:46 -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 QQoorl15424 for ; Wed, 14 May 2003 19:26:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoorl07874 for ; Wed, 14 May 2003 19:24: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 QQoorl26970 for ; Wed, 14 May 2003 19:24:48 GMT Received: from web20708.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20708.mail.yahoo.com [216.136.226.181]) id QQoorl26917 for ; Wed, 14 May 2003 19:24:47 GMT Message-ID: <20030514192418.47426.qmail@web20708.mail.yahoo.com> Received: from [219.65.132.16] by web20708.mail.yahoo.com via HTTP; Wed, 14 May 2003 20:24:18 BST Date: Wed, 14 May 2003 20:24:18 +0100 (BST) From: =?iso-8859-1?q?Spice=20Sylvia?= Subject: Re: [MPLS-OPS]: Re: Advertising Routes learnt from PE to PE To: Aamer Akhter , ferit@isocore.com, mpls-ops@mplsrc.com Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1489768003-1052940258=:45893" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk --0-1489768003-1052940258=:45893 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Perhaps am not clear, 1. Why would hub and spoke put things in 2 different VRFs. What does this achieve which prefix filter/Route Target filter cannot achieve? Hub and spoke is a central site and remote side model. How does 2 VRF help? 2. How exciting if we had hub and spoke on the other side too? and put routes learnt from BGP-MPLS back into IGP and then those from IGP back into BGP from vrf2 and so on. We have prefix1:rd1 from vrf1 then one from prefix1:rd2, then one from prefix1:rd3 then one from prefix1:rd4 and so on. I wonder what would be the next -hop too. -S.F. Aamer Akhter wrote: On 5/14/03 3:02 PM, "Spice Sylvia" wrote: > Pardon me if I am not clear, > > Why would RD have changed? The prefix is no longer is the same vrf. > > Same IP route to same prefix but why different RD? > > Why would one not give both to same vrf1 in hub and spoke? Both what? Once vrf2 learns the routes from a spoke PE, it's not going to readvertise that prefix to other spokes because of ibgp behavior. To get around this you have to advertise the prefix to the hub PE which advertises the prefix back to you in ANOTHER vrf. At this point, it's not the same vpnv4 prefix, so you can export and advertise to the spoke PEs. > > > Aamer Akhter wrote: > On 5/14/03 1:58 PM, "Spice Sylvia" wrote: > >> Hello Aamer, >> >> Why would the "rd" have changed? > > |--------1 > HUBCE HUBPE > |--------2 > > Suppose the sites prefixes are sent to the HUBPE, which advertises to HUBCE > over link 2 (lets' call this vrf2), the HUBCE advertises this back to the > HUBPE over link 1 (vrf1). vrf2 and vrf1 will have different rd's because > they are different vrfs. > >> >> Is this a new feature? >> >> How does changing RD help? >> >> >> Aamer Akhter wrote: >> On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote: >> >>> >>> Sylvia, >>> >>> One possible scenario where this could happen is the hub-spoke BGP/MPLS >>> VPN. In this case the spoke PEs advertise their routes with a Route >>> Target value "Hub". The hub PE imports these routes and advertises them >>> to the CE router in the hub site. These routes are advertised across the >>> hub site and eventually back to the PE hub router via a different >>> interface. The PE hub router then readvertises these routes to the spoke >>> PEs with a Route Target value "Spoke" and a different VPN label. >> >> But to BGP, these "readvertised" prefixes are not the same. The rd will have >> changed. >> >>> >>> Ferit >>> >>> >>> >>>> -----Original Message----- >>>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar, >>>> Sylvia >>>> Sent: Wednesday, May 14, 2003 10:07 AM >>>> To: mpls-ops@mplsrc.com >>>> Cc: mpls@UU.NET >>>> Subject: Advertising Routes learnt from PE to PE >>>> >>>> Hi, >>>> WIll a PE router ever advertise a route it learns from another PE >>> router >>>> to some other PE router. >>>> I dont think it will ever do that as all the PE routers are IBGP peers >>> and >>>> would generally be in >>>> full mesh. >>>> >>>> Is there any case when this might happen .. i.e. a PE router >>> advertises a >>>> Route learnt from one PE >>>> to another PE. How can one do that .. because IMHO the label that will >>> be >>>> advertised by the former >>>> PE router will be for the PE router to which he sends the UPDATE. How >>> can >>>> this PE router advertise >>>> another PE router the same label? >>>> >>>> Moreover, if for some reason he has to .. does he assign a new label >>> and >>>> then advertise? >>>> >>>> ANy comments on this would be very helpful! >>>> >>>> Silviya Sugar >>>> >>>> __________________________________________________ >>>> Yahoo! Plus >>>> For a better Internet experience >>>> http://www.yahoo.co.uk/btoffer >>> -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems --------------------------------- Yahoo! Plus - For a better Internet experience --0-1489768003-1052940258=:45893 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Perhaps am not clear,
 
1. Why would hub and spoke put things in 2 different VRFs. What does this achieve which prefix filter/Route Target filter cannot achieve?
Hub and spoke is a central site and remote side model. How does 2 VRF help?
 
2. How exciting if we had hub and spoke on the other side too?
and put routes learnt from BGP-MPLS back into IGP and then those from IGP back into BGP from vrf2 and so on.
 
We  have prefix1:rd1 from vrf1 then one from prefix1:rd2, then one from prefix1:rd3 then one from prefix1:rd4 and so on. I wonder what would be the next -hop too.
 
-S.F. 
 
Aamer Akhter <aakhter@cisco.com> wrote:
On 5/14/03 3:02 PM, "Spice Sylvia" wrote:

> Pardon me if I am not clear,
>
> Why would RD have changed?

The prefix is no longer is the same vrf.

>
> Same IP route to same prefix but why different RD?
>
> Why would one not give both to same vrf1 in hub and spoke?

Both what? Once vrf2 learns the routes from a spoke PE, it's not going to
readvertise that prefix to other spokes because of ibgp behavior. To get
around this you have to advertise the prefix to the hub PE which advertises
the prefix back to you in ANOTHER vrf. At this point, it's not the same
vpnv4 prefix, so you can export and advertise to the spoke PEs.



>
>
> Aamer Akhter wrote:
> On 5/14/03 1:58 PM, "Spice Sylvia" wrote:
>
>> Hello Aamer,
>> >> Why would the "rd" have changed?
>
> |--------1
> HUBCE HUBPE
> |--------2
>
> Suppose the sites prefixes are sent to the HUBPE, which advertises to HUBCE
> over link 2 (lets' call this vrf2), the HUBCE advertises this back to the
> HUBPE over link 1 (vrf1). vrf2 and vrf1 will have different rd's because
> they are different vrfs.
>
>>
>> Is this a new feature?
>>
>> How does changing RD help?
>>
>>
>> Aamer Akhter wrote:
>> On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote:
>>
>>>
>>> Sylvia,
>>>
>>> One possible scenario where this could happen is the hub-spoke BGP/MPLS
>>> VPN. In this case the spoke PEs advertise their routes with a Route
>>> Target value "Hub". The hub PE imports these routes and advertises them
>>> to the CE router! in the hub site. These routes are advertised across the
>>&g t; hub site and eventually back to the PE hub router via a different
>>> interface. The PE hub router then readvertises these routes to the spoke
>>> PEs with a Route Target value "Spoke" and a different VPN label.
>>
>> But to BGP, these "readvertised" prefixes are not the same. The rd will have
>> changed.
>>
>>>
>>> Ferit
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar,
>>>> Sylvia
>>>> Sent: Wednesday, May 14, 2003 10:07 AM
>>>> To: mpls-ops@mplsrc.com
>>>> Cc: mpls@UU.NET
>>>> Subject: Advertising Routes learnt from PE to PE
>>>>
>>>> Hi,
>>>> WIll a PE router ever advertise a route it learns from another PE
>>> rout! er
>>>> to some other PE router.
>>>> I dont think it will ever do that as all the PE routers are IBGP peers
>>> and
>>>> would generally be in
>>>> full mesh.
>>>>
>>>> Is there any case when this might happen .. i.e. a PE router
>>> advertises a
>>>> Route learnt from one PE
>>>> to another PE. How can one do that .. because IMHO the label that will
>>> be
>>>> advertised by the former
>>>> PE router will be for the PE router to which he sends the UPDATE. How
>>> can
>>>> this PE router advertise
>>>> another PE router the same label?
>>>>
>>>> Moreover, if for some reason he has to .. does he assign a new label
>>> and
>>>> then advertise?
>>>>
>>>> ANy comme! nts on this would be very helpful!
>>>>
>>> ;> Silviya Sugar
>>>>
>>>> __________________________________________________
>>>> Yahoo! Plus
>>>> For a better Internet experience
>>>> http://www.yahoo.co.uk/btoffer
>>>

--
Aamer Akhter / aa@cisco.com
NSITE - cisco Systems


Yahoo! Plus - For a better Internet experience
--0-1489768003-1052940258=:45893-- From owner-mpls@UU.NET Wed May 14 17:34: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 RAA06840 for ; Wed, 14 May 2003 17:34: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 QQooru01065 for ; Wed, 14 May 2003 21:37: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 QQooru01038; Wed, 14 May 2003 21:37:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQoorq09742 for mpls-outgoing; Wed, 14 May 2003 20:37:10 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 QQoorq09730 for ; Wed, 14 May 2003 20:37:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoorq10204 for ; Wed, 14 May 2003 20:36: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 QQoorq19558 for ; Wed, 14 May 2003 20:36:32 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 QQoorq19538 for ; Wed, 14 May 2003 20:36:32 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4EKaQ1M025931 for ; Wed, 14 May 2003 16:36:26 -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 QAA24602 for ; Wed, 14 May 2003 16:36:26 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4EKaQQ17080 for mpls@uu.net; Wed, 14 May 2003 16:36:26 -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 QQoorf02517 for ; Wed, 14 May 2003 17:59:41 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 QQoorf12219 for ; Wed, 14 May 2003 17:58: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 QQoorf11758 for ; Wed, 14 May 2003 17:58:48 GMT Received: from web20701.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20701.mail.yahoo.com [216.136.226.174]) id QQoorf11745 for ; Wed, 14 May 2003 17:58:47 GMT Message-ID: <20030514175846.73641.qmail@web20701.mail.yahoo.com> Received: from [219.65.132.16] by web20701.mail.yahoo.com via HTTP; Wed, 14 May 2003 18:58:46 BST Date: Wed, 14 May 2003 18:58:46 +0100 (BST) From: =?iso-8859-1?q?Spice=20Sylvia?= Subject: Re: [MPLS-OPS]: Re: Advertising Routes learnt from PE to PE To: Aamer Akhter , ferit@isocore.com, mpls-ops@mplsrc.com Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2124919976-1052935126=:72353" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk --0-2124919976-1052935126=:72353 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Aamer, Why would the "rd" have changed? Is this a new feature? How does changing RD help? Aamer Akhter wrote: On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote: > > Sylvia, > > One possible scenario where this could happen is the hub-spoke BGP/MPLS > VPN. In this case the spoke PEs advertise their routes with a Route > Target value "Hub". The hub PE imports these routes and advertises them > to the CE router in the hub site. These routes are advertised across the > hub site and eventually back to the PE hub router via a different > interface. The PE hub router then readvertises these routes to the spoke > PEs with a Route Target value "Spoke" and a different VPN label. But to BGP, these "readvertised" prefixes are not the same. The rd will have changed. > > Ferit > > > >> -----Original Message----- >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar, >> Sylvia >> Sent: Wednesday, May 14, 2003 10:07 AM >> To: mpls-ops@mplsrc.com >> Cc: mpls@UU.NET >> Subject: Advertising Routes learnt from PE to PE >> >> Hi, >> WIll a PE router ever advertise a route it learns from another PE > router >> to some other PE router. >> I dont think it will ever do that as all the PE routers are IBGP peers > and >> would generally be in >> full mesh. >> >> Is there any case when this might happen .. i.e. a PE router > advertises a >> Route learnt from one PE >> to another PE. How can one do that .. because IMHO the label that will > be >> advertised by the former >> PE router will be for the PE router to which he sends the UPDATE. How > can >> this PE router advertise >> another PE router the same label? >> >> Moreover, if for some reason he has to .. does he assign a new label > and >> then advertise? >> >> ANy comments on this would be very helpful! >> >> Silviya Sugar >> >> __________________________________________________ >> Yahoo! Plus >> For a better Internet experience >> http://www.yahoo.co.uk/btoffer > -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml --------------------------------- Yahoo! Plus - For a better Internet experience --0-2124919976-1052935126=:72353 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello Aamer,
 
Why would the "rd" have changed?
 
Is this a new feature?
 
How does changing RD help?


Aamer Akhter <aakhter@cisco.com> wrote:
On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote:

>
> Sylvia,
>
> One possible scenario where this could happen is the hub-spoke BGP/MPLS
> VPN. In this case the spoke PEs advertise their routes with a Route
> Target value "Hub". The hub PE imports these routes and advertises them
> to the CE router in the hub site. These routes are advertised across the
> hub site and eventually back to the PE hub router via a different
> interface. The PE hub router then readvertises these routes to the spoke
> PEs with a Route Target value "Spoke" and a different VPN label.

But to BGP, these "readvertised" prefixes are not the same. The rd will have
changed.

>
> Ferit
>
>
>
>> -----Original Message-----
>> From: owner-mpls@! UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar,
>> Sylvia
>> Sent: Wednesday, May 14, 2003 10:07 AM
>> To: mpls-ops@mplsrc.com
>> Cc: mpls@UU.NET
>> Subject: Advertising Routes learnt from PE to PE
>>
>> Hi,
>> WIll a PE router ever advertise a route it learns from another PE
> router
>> to some other PE router.
>> I dont think it will ever do that as all the PE routers are IBGP peers
> and
>> would generally be in
>> full mesh.
>>
>> Is there any case when this might happen .. i.e. a PE router
> advertises a
>> Route learnt from one PE
>> to another PE. How can one do that .. because IMHO the label that will
> be
>> advertised by the former
>> PE router will be for th! e PE router to which he sends the UPDATE. How
> can
>> this PE router advertise
>> another PE router the same label?
>>
>> Moreover, if for some reason he has to .. does he assign a new label
> and
>> then advertise?
>>
>> ANy comments on this would be very helpful!
>>
>> Silviya Sugar
>>
>> __________________________________________________
>> Yahoo! Plus
>> For a better Internet experience
>> http://www.yahoo.co.uk/btoffer
>

--
Aamer Akhter / aa@cisco.com
NSITE - cisco Systems


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


Yahoo! Plus - For a better Internet experience
--0-2124919976-1052935126=:72353-- From owner-mpls@UU.NET Thu May 15 10:22: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 KAA10619 for ; Thu, 15 May 2003 10:22: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 QQoouj13968 for ; Thu, 15 May 2003 14:25: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 QQoouj13836; Thu, 15 May 2003 14:25:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQoouh13017 for mpls-outgoing; Thu, 15 May 2003 13:52:07 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 QQoouh12921 for ; Thu, 15 May 2003 13:51:51 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 QQoouh20801 for ; Thu, 15 May 2003 13:50: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 QQoouh00008 for ; Thu, 15 May 2003 13:50:30 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 QQoouh29949 for ; Thu, 15 May 2003 13:50:28 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FDoPci020969 for ; Thu, 15 May 2003 09:50:25 -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 JAA22571 for ; Thu, 15 May 2003 09:50:24 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4FDoOF06879 for mpls@uu.net; Thu, 15 May 2003 09:50:24 -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 QQoosy16575 for ; Thu, 15 May 2003 05:00:01 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 QQoosx25678 for ; Thu, 15 May 2003 04:59: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 QQoosx01574 for ; Thu, 15 May 2003 04:59:51 GMT Received: from amidala.in.spectranet.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: amidala.in.spectranet.com [203.122.63.90]) id QQoosx01498 for ; Thu, 15 May 2003 04:59:49 GMT Received: (qmail 31040 invoked from network); 15 May 2003 05:11:02 -0000 Received: from unknown (HELO host) (203.122.63.70) by amidala.in.spectranet.com with SMTP; 15 May 2003 05:11:02 -0000 Message-ID: <004401c31a9d$7d9f85e0$72010f0a@host> Reply-To: "jgrewal" From: "jgrewal" To: "Sugar, Sylvia" , Cc: References: <20030514140640.62067.qmail@web20710.mail.yahoo.com> Subject: Re: [MPLS-OPS]: Advertising Routes learnt from PE to PE Date: Thu, 15 May 2003 10:19:55 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 Hi, As far i know IBGP dont advertise routes learned from its IBGP peer. J.Grewal ----- Original Message ----- From: "Sugar, Sylvia" To: Cc: Sent: Wednesday, May 14, 2003 7:36 PM Subject: [MPLS-OPS]: Advertising Routes learnt from PE to PE > Hi, > WIll a PE router ever advertise a route it learns from another PE router to some other PE router. > I dont think it will ever do that as all the PE routers are IBGP peers and would generally be in > full mesh. > > Is there any case when this might happen .. i.e. a PE router advertises a Route learnt from one PE > to another PE. How can one do that .. because IMHO the label that will be advertised by the former > PE router will be for the PE router to which he sends the UPDATE. How can this PE router advertise > another PE router the same label? > > Moreover, if for some reason he has to .. does he assign a new label and then advertise? > > ANy comments on this would be very helpful! > > Silviya Sugar > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer > > ------- > 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 Thu May 15 16:15: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 QAA21747 for ; Thu, 15 May 2003 16:15:06 -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 QQoovh07721 for ; Thu, 15 May 2003 20:18: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 QQoovh07669; Thu, 15 May 2003 20:18:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQoove29634 for mpls-outgoing; Thu, 15 May 2003 19:38: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 QQoove29627 for ; Thu, 15 May 2003 19:38:05 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 QQoove02977 for ; Thu, 15 May 2003 19:37: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 QQoove28835 for ; Thu, 15 May 2003 19:37: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 QQoove28825 for ; Thu, 15 May 2003 19:37:10 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FJb3cm002496 for ; Thu, 15 May 2003 15:37: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 PAA25084 for ; Thu, 15 May 2003 15:37:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4FJb3T24509 for mpls@uu.net; Thu, 15 May 2003 15:37: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 QQoove29351 for ; Thu, 15 May 2003 19:35: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 QQoove10725 for ; Thu, 15 May 2003 19:35:14 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 QQoove21561 for ; Thu, 15 May 2003 19:35:13 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 QQoove21546 for ; Thu, 15 May 2003 19:35:13 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 h4FJYtI29027 for ; Thu, 15 May 2003 15:34:56 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF4VMK; Thu, 15 May 2003 15:34:55 -0400 Received: from americasm01.nt.com (wcars1v1.ca.nortel.com [47.128.182.235]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KLLRGBFD; Thu, 15 May 2003 15:34:56 -0400 Message-ID: <3EC3EBDD.7AFA1B63@americasm01.nt.com> Date: Thu, 15 May 2003 15:34:53 -0400 From: "Ling Yan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Question regarding null padding session name in RSVP-TE Att obj Content-Type: multipart/alternative; boundary="------------6E07B750D80A9AED6AA56B6E" Sender: owner-mpls@UU.NET Precedence: bulk --------------6E07B750D80A9AED6AA56B6E Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit I have a simple question regarding null padding to the session name to make it to be a multiple of 4 and at least 8 in RSVP-TE attribute object. It is really appreciated if someone can help to clarify it. Thanks in advance. If the string length is exactly a multiple of 4 and greater than 8 without counting null padding or null terminate character, -- 1) is it required to add at least null terminated char to indicate the string termination? 2) is it required to check at the receiver whether the session name is null terminated or not? The contents of the Session Name field are a string, typically of display-able characters. The Length MUST always be a multiple of 4 and MUST be at least 8. For an object length that is not a multiple of 4, the object is padded with trailing NULL characters. The Name Length field contains the actual string length. Regards, -- Ling Yan --------------6E07B750D80A9AED6AA56B6E Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 7bit     I have a simple question regarding null padding to the session name to make it to be a multiple of 4 and at least 8 in RSVP-TE attribute object. It is really appreciated if someone can help to clarify it. Thanks in advance.

If the string length is exactly a multiple of 4 and greater than 8 without counting null padding or null terminate character, --
1) is it required to add at least null terminated char to indicate the string termination?
2) is it required to check at the receiver whether the session name is null terminated or not?

The contents of the Session Name field are a string, typically of display-able characters.  The Length MUST always be a multiple of 4 and MUST be at least 8.  For an object length that is not a multiple of 4, the object is padded with trailing NULL characters.  The Name Length field contains the actual string length.


Regards, 

-- 
Ling Yan 
  --------------6E07B750D80A9AED6AA56B6E-- From owner-mpls@UU.NET Thu May 15 16:19: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 QAA21957 for ; Thu, 15 May 2003 16:19: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 QQoovh15715 for ; Thu, 15 May 2003 20:22: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 QQoovh15519; Thu, 15 May 2003 20:22:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQoove00013 for mpls-outgoing; Thu, 15 May 2003 19:44: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 QQoove29966 for ; Thu, 15 May 2003 19:43:58 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 QQoove15785 for ; Thu, 15 May 2003 19:43: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 QQoove08378 for ; Thu, 15 May 2003 19:43:32 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 QQoove08257 for ; Thu, 15 May 2003 19:43:26 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4FJhO3C018165 for ; Thu, 15 May 2003 15:43:24 -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 PAA25598 for ; Thu, 15 May 2003 15:43:23 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4FJhNM24955 for mpls@uu.net; Thu, 15 May 2003 15:43:23 -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 QQoout22762 for ; Thu, 15 May 2003 16:48: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 QQoout25679 for ; Thu, 15 May 2003 16:47: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 QQoout14654 for ; Thu, 15 May 2003 16:47:04 GMT Received: from web20710.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20710.mail.yahoo.com [216.136.226.183]) id QQoout14647 for ; Thu, 15 May 2003 16:47:03 GMT Message-ID: <20030515164702.28748.qmail@web20710.mail.yahoo.com> Received: from [203.124.140.97] by web20710.mail.yahoo.com via HTTP; Thu, 15 May 2003 17:47:02 BST Date: Thu, 15 May 2003 17:47:02 +0100 (BST) From: =?iso-8859-1?q?Spice=20Sylvia?= Subject: Re: [MPLS-OPS]: Re: Advertising Routes learnt from PE to PE To: Aamer Akhter , ferit@isocore.com, mpls-ops@mplsrc.com Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1943450333-1053017222=:27424" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk --0-1943450333-1053017222=:27424 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Aamer, no reply? I would also like to know the cutomer base cisco has on MPLS VPN after reading your mail. or is there none? -S.F. Aamer Akhter wrote: On 5/14/03 3:02 PM, "Spice Sylvia" wrote: > Pardon me if I am not clear, > > Why would RD have changed? The prefix is no longer is the same vrf. > > Same IP route to same prefix but why different RD? > > Why would one not give both to same vrf1 in hub and spoke? Both what? Once vrf2 learns the routes from a spoke PE, it's not going to readvertise that prefix to other spokes because of ibgp behavior. To get around this you have to advertise the prefix to the hub PE which advertises the prefix back to you in ANOTHER vrf. At this point, it's not the same vpnv4 prefix, so you can export and advertise to the spoke PEs. > > > Aamer Akhter wrote: > On 5/14/03 1:58 PM, "Spice Sylvia" wrote: > >> Hello Aamer, >> >> Why would the "rd" have changed? > > |--------1 > HUBCE HUBPE > |--------2 > > Suppose the sites prefixes are sent to the HUBPE, which advertises to HUBCE > over link 2 (lets' call this vrf2), the HUBCE advertises this back to the > HUBPE over link 1 (vrf1). vrf2 and vrf1 will have different rd's because > they are different vrfs. > >> >> Is this a new feature? >> >> How does changing RD help? >> >> >> Aamer Akhter wrote: >> On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote: >> >>> >>> Sylvia, >>> >>> One possible scenario where this could happen is the hub-spoke BGP/MPLS >>> VPN. In this case the spoke PEs advertise their routes with a Route >>> Target value "Hub". The hub PE imports these routes and advertises them >>> to the CE router in the hub site. These routes are advertised across the >>> hub site and eventually back to the PE hub router via a different >>> interface. The PE hub router then readvertises these routes to the spoke >>> PEs with a Route Target value "Spoke" and a different VPN label. >> >> But to BGP, these "readvertised" prefixes are not the same. The rd will have >> changed. >> >>> >>> Ferit >>> >>> >>> >>>> -----Original Message----- >>>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar, >>>> Sylvia >>>> Sent: Wednesday, May 14, 2003 10:07 AM >>>> To: mpls-ops@mplsrc.com >>>> Cc: mpls@UU.NET >>>> Subject: Advertising Routes learnt from PE to PE >>>> >>>> Hi, >>>> WIll a PE router ever advertise a route it learns from another PE >>> router >>>> to some other PE router. >>>> I dont think it will ever do that as all the PE routers are IBGP peers >>> and >>>> would generally be in >>>> full mesh. >>>> >>>> Is there any case when this might happen .. i.e. a PE router >>> advertises a >>>> Route learnt from one PE >>>> to another PE. How can one do that .. because IMHO the label that will >>> be >>>> advertised by the former >>>> PE router will be for the PE router to which he sends the UPDATE. How >>> can >>>> this PE router advertise >>>> another PE router the same label? >>>> >>>> Moreover, if for some reason he has to .. does he assign a new label >>> and >>>> then advertise? >>>> >>>> ANy comments on this would be very helpful! >>>> >>>> Silviya Sugar >>>> >>>> __________________________________________________ >>>> Yahoo! Plus >>>> For a better Internet experience >>>> http://www.yahoo.co.uk/btoffer >>> -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml --------------------------------- Yahoo! Plus - For a better Internet experience --0-1943450333-1053017222=:27424 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Aamer,
 
no reply?
 
I would also like to know the cutomer base cisco has on MPLS VPN after reading your mail.
 
or is there none?
 
-S.F.

Aamer Akhter <aakhter@cisco.com> wrote:
On 5/14/03 3:02 PM, "Spice Sylvia" wrote:

> Pardon me if I am not clear,
>
> Why would RD have changed?

The prefix is no longer is the same vrf.

>
> Same IP route to same prefix but why different RD?
>
> Why would one not give both to same vrf1 in hub and spoke?

Both what? Once vrf2 learns the routes from a spoke PE, it's not going to
readvertise that prefix to other spokes because of ibgp behavior. To get
around this you have to advertise the prefix to the hub PE which advertises
the prefix back to you in ANOTHER vrf. At this point, it's not the same
vpnv4 prefix, so you can export and advertise to the spoke PEs.



>
>
> Aamer Akhter wrote:
> On 5/14/03 1:58 PM, "Spice Sylvia" wrote:
>
>> Hello Aamer,
>> >> Why would the "rd" have changed?
>
> |--------1
> HUBCE HUBPE
> |--------2
>
> Suppose the sites prefixes are sent to the HUBPE, which advertises to HUBCE
> over link 2 (lets' call this vrf2), the HUBCE advertises this back to the
> HUBPE over link 1 (vrf1). vrf2 and vrf1 will have different rd's because
> they are different vrfs.
>
>>
>> Is this a new feature?
>>
>> How does changing RD help?
>>
>>
>> Aamer Akhter wrote:
>> On 5/14/03 10:51 AM, "Ferit Yegenoglu" wrote:
>>
>>>
>>> Sylvia,
>>>
>>> One possible scenario where this could happen is the hub-spoke BGP/MPLS
>>> VPN. In this case the spoke PEs advertise their routes with a Route
>>> Target value "Hub". The hub PE imports these routes and advertises them
>>> to the CE router! in the hub site. These routes are advertised across the
>>&g t; hub site and eventually back to the PE hub router via a different
>>> interface. The PE hub router then readvertises these routes to the spoke
>>> PEs with a Route Target value "Spoke" and a different VPN label.
>>
>> But to BGP, these "readvertised" prefixes are not the same. The rd will have
>> changed.
>>
>>>
>>> Ferit
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Sugar,
>>>> Sylvia
>>>> Sent: Wednesday, May 14, 2003 10:07 AM
>>>> To: mpls-ops@mplsrc.com
>>>> Cc: mpls@UU.NET
>>>> Subject: Advertising Routes learnt from PE to PE
>>>>
>>>> Hi,
>>>> WIll a PE router ever advertise a route it learns from another PE
>>> rout! er
>>>> to some other PE router.
>>>> I dont think it will ever do that as all the PE routers are IBGP peers
>>> and
>>>> would generally be in
>>>> full mesh.
>>>>
>>>> Is there any case when this might happen .. i.e. a PE router
>>> advertises a
>>>> Route learnt from one PE
>>>> to another PE. How can one do that .. because IMHO the label that will
>>> be
>>>> advertised by the former
>>>> PE router will be for the PE router to which he sends the UPDATE. How
>>> can
>>>> this PE router advertise
>>>> another PE router the same label?
>>>>
>>>> Moreover, if for some reason he has to .. does he assign a new label
>>> and
>>>> then advertise?
>>>>
>>>> ANy comme! nts on this would be very helpful!
>>>>
>>> ;> Silviya Sugar
>>>>
>>>> __________________________________________________
>>>> Yahoo! Plus
>>>> For a better Internet experience
>>>> http://www.yahoo.co.uk/btoffer
>>>

--
Aamer Akhter / aa@cisco.com
NSITE - cisco Systems


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


Yahoo! Plus - For a better Internet experience
--0-1943450333-1053017222=:27424-- From owner-mpls@UU.NET Fri May 16 09:23: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 JAA22891 for ; Fri, 16 May 2003 09:23: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 QQooxx00499 for ; Fri, 16 May 2003 13:26: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 QQooxx00435; Fri, 16 May 2003 13:26:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQooxv00564 for mpls-outgoing; Fri, 16 May 2003 12:52:33 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 QQooxv00557 for ; Fri, 16 May 2003 12:52:12 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 QQooxv14567 for ; Fri, 16 May 2003 12:51: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 QQooxv04112 for ; Fri, 16 May 2003 12:51:47 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 QQooxv04090 for ; Fri, 16 May 2003 12:51:46 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GCpjH08264 for ; Fri, 16 May 2003 08:51:45 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 May 2003 08:51:44 -0400 Message-ID: From: "Jiang, Donghua (Jane)" To: "'George Swallow'" , Ling Yan Cc: mpls@UU.NET Subject: RE: Question regarding null padding session name in RSVP-TE Att o bj Date: Fri, 16 May 2003 08:51:42 -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 George, 2) Should we use the Name Length to decide where the end of the Session Name is, rather than checking on whether the character is printable or not? Thanks, Jane -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] Sent: Thursday, May 15, 2003 5:22 PM To: Ling Yan Cc: mpls@UU.NET; swallow@cisco.com Subject: Re: Question regarding null padding session name in RSVP-TE Att obj > I have a simple question regarding null padding to the session name > to make it to be a multiple of 4 and at least 8 in RSVP-TE attribute > object. It is really appreciated if someone can help to clarify it. > Thanks in advance. > > If the string length is exactly a multiple of 4 and greater than 8 > without counting null padding or null terminate character, -- > 1) is it required to add at least null terminated char to indicate the > string termination? No. But it would not be illegal to add a multiple of 4 nulls. But optimally you should only add 0-3 nulls. > 2) is it required to check at the receiver whether the session name is > null terminated or not? Only to find the end of the string. I.e. if the last char is printable it should pass. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-mpls@UU.NET Fri May 16 11:11: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 LAA28621 for ; Fri, 16 May 2003 11:11: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 QQooye22427 for ; Fri, 16 May 2003 15:14: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 QQooye22344; Fri, 16 May 2003 15:14:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQooyc15270 for mpls-outgoing; Fri, 16 May 2003 14:42: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 QQooyc15258 for ; Fri, 16 May 2003 14:42:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQooyc29313 for ; Fri, 16 May 2003 14:42: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 QQooyc01988 for ; Fri, 16 May 2003 14:42:05 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 QQooyc01982 for ; Fri, 16 May 2003 14:42: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 h4GEg2Jh014971 for ; Fri, 16 May 2003 10:42: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 KAA02212 for ; Fri, 16 May 2003 10:42:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4GEg2X22793 for mpls@uu.net; Fri, 16 May 2003 10:42: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 QQooyc15076 for ; Fri, 16 May 2003 14:40:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQooyc20305 for ; Fri, 16 May 2003 14:40:22 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 QQooyc13731 for ; Fri, 16 May 2003 14:40:21 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 QQooyc13716 for ; Fri, 16 May 2003 14:40:21 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 h4GEdtkL014401; Fri, 16 May 2003 10:39:56 -0400 (EDT) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id KAA02036; Fri, 16 May 2003 10:39:55 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA16863; Fri, 16 May 2003 10:39:55 -0400 (EDT) Message-Id: <200305161439.KAA16863@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "Jiang, Donghua (Jane)" cc: "'George Swallow'" , Ling Yan , mpls@UU.NET, swallow@cisco.com Subject: Re: Question regarding null padding session name in RSVP-TE Att o bj In-reply-to: Your message of "Fri, 16 May 2003 08:51:42 EDT." Date: Fri, 16 May 2003 10:39:55 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Jane - > 2) Should we use the Name Length to decide where the end of the > Session Name is, rather than checking on whether the character is > printable or not? Yes, though either should work if the sender is playing by the rules. (and if you're really worried about being defensive then both are necessary). But all of this is what we call "implementation detail", i.e not specified. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-mpls@UU.NET Fri May 16 14:51:50 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 OAA06609 for ; Fri, 16 May 2003 14:51: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 QQooyt19169 for ; Fri, 16 May 2003 18:54:55 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 QQooyt15880; Fri, 16 May 2003 18:53:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQooyr16218 for mpls-outgoing; Fri, 16 May 2003 18:23: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 QQooyr16211 for ; Fri, 16 May 2003 18:22:56 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 QQooyr01363 for ; Fri, 16 May 2003 18:22:20 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 QQooyr22566 for ; Fri, 16 May 2003 18:22:20 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 QQooyr22554 for ; Fri, 16 May 2003 18:22:19 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25973 for ; Fri, 16 May 2003 14:22:17 -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 OAA21979 for ; Fri, 16 May 2003 14:22:19 -0400 (EDT) Message-ID: <3EC52C72.4040907@marconi.com> Date: Fri, 16 May 2003 14:22:42 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030430 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Question regarding null padding session name in RSVP-TE Att o bj 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 Jiang, Donghua (Jane) wrote: > > 2) Should we use the Name Length to decide where the end of the Session Name is, rather than checking on whether the character is printable or not? Yes, you absolutely must. The RFC says that the object is NULL padded, it does not say that the string is NULL terminated. This means that if the name is an exact multiple of 4 bytes, there may not be any trailing NULL. If you use a function that expects a NULL-terminated string (like the C language strcpy function), it may overrun the end fo the string, resulting in undefined behavior. Also note that the RFC doesn't specify ASCII (or any other encoding) for the name. If the encoding is something that permits zero-byte values (e.g. Unicode), a function designed for NULL-terminated strings may get a short count of bytes. In other words, this is a counted string and should be treated as such. If use use the C language, you should not use string functions on it. Instead, track the length and use functions like memcpy to copy its value. If you absolutely must pass it to a function that uses null-terminated strings, make sure to append your own NULL character to guarantee that the function doesn't overrun the end of the string. -- David From owner-mpls@UU.NET Fri May 16 16:09: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 QAA09728 for ; Fri, 16 May 2003 16:09: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 QQooyy01950 for ; Fri, 16 May 2003 20:12: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 QQooyy29502; Fri, 16 May 2003 20:10:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQooyw09911 for mpls-outgoing; Fri, 16 May 2003 19:40: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 QQooyw09905 for ; Fri, 16 May 2003 19:40:56 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 QQooyw20910 for ; Fri, 16 May 2003 19:40: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 QQooyw26661 for ; Fri, 16 May 2003 19:40: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 QQooyw26647 for ; Fri, 16 May 2003 19:40: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 h4GJe3kL004664 for ; Fri, 16 May 2003 15:40: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 PAA01100 for ; Fri, 16 May 2003 15:40:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4GJe2V09291 for mpls@uu.net; Fri, 16 May 2003 15:40: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 QQooyw09836 for ; Fri, 16 May 2003 19:38:35 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 QQooyw27997 for ; Fri, 16 May 2003 19:37: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 QQooyw14940 for ; Fri, 16 May 2003 19:37:55 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 QQooyw14878 for ; Fri, 16 May 2003 19:37:51 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 PAA11979; Fri, 16 May 2003 15:35:53 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200305161935.PAA11979@workhorse.fictitious.org> To: David Charlap cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Question regarding null padding session name in RSVP-TE Att o bj In-reply-to: Your message of "Fri, 16 May 2003 14:22:42 EDT." <3EC52C72.4040907@marconi.com> Date: Fri, 16 May 2003 15:35:53 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3EC52C72.4040907@marconi.com>, David Charlap writes: > Jiang, Donghua (Jane) wrote: > > > > 2) Should we use the Name Length to decide where the end of the Session Nam > e is, rather than checking on whether the character is printable or not? > > Yes, you absolutely must. > > The RFC says that the object is NULL padded, it does not say that the > string is NULL terminated. This means that if the name is an exact > multiple of 4 bytes, there may not be any trailing NULL. If you use a > function that expects a NULL-terminated string (like the C language > strcpy function), it may overrun the end fo the string, resulting in > undefined behavior. > > Also note that the RFC doesn't specify ASCII (or any other encoding) for > the name. If the encoding is something that permits zero-byte values > (e.g. Unicode), a function designed for NULL-terminated strings may get > a short count of bytes. > > In other words, this is a counted string and should be treated as such. > If use use the C language, you should not use string functions on it. > Instead, track the length and use functions like memcpy to copy its > value. If you absolutely must pass it to a function that uses > null-terminated strings, make sure to append your own NULL character to > guarantee that the function doesn't overrun the end of the string. > > -- David David, Interesting advice. Not necessarily all good advice. You are right about one thing. If the string fits in an exact multiple of 4 bytes, the string can be (and generally is) sent without a terminating null and on reception if the name is specified as having an exact multiple of 4 bytes the terminating null must be added. As far as the string being ascii, there I think you are wrong. If we still beleive in running code, then I know you are wrong because there are numberous implementations that have shown up at interoperability bake-offs. In draft-ietf-mpls-te-mib- and elsewhere mplsTunnelName is defined as DisplayString. You can look in the lsr mib for the session name. I'm confident it is the same. In rfc3209 it is described as: Session Name (NULL padded display string) rfc2579 defines DisplayString as: DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length." SYNTAX OCTET STRING (SIZE (0..255)) (I left out the blank lines). If you stick unicode in the SESSION_ATTRIBUTE in the session name, expect interoperability problems, the least of which may be display problems. If necessary next iteration of rfc3209 can be more clear about a display string being as defined in rfc2579. If there is a null in string most implementations will interpret this as the end of the string. Curtis From owner-mpls@UU.NET Fri May 16 19:00: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 TAA14137 for ; Fri, 16 May 2003 19:00: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 QQoovo07335 for ; Thu, 15 May 2003 22:00: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 QQoovn07004; Thu, 15 May 2003 21:59:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQoovl15832 for mpls-outgoing; Thu, 15 May 2003 21:29:09 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 QQoovl15825 for ; Thu, 15 May 2003 21:29:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoovl14073 for ; Thu, 15 May 2003 21:27: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 QQoovl11841 for ; Thu, 15 May 2003 21:27:05 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 QQoovl11817 for ; Thu, 15 May 2003 21:27:05 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4FLR214013781 for ; Thu, 15 May 2003 17:27: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 RAA04714 for ; Thu, 15 May 2003 17:27:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4FLR2J05638 for mpls@uu.net; Thu, 15 May 2003 17:27: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 QQoovl15661 for ; Thu, 15 May 2003 21:26:02 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 QQoovl06388 for ; Thu, 15 May 2003 21:24:00 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 QQoovl06980 for ; Thu, 15 May 2003 21:24:00 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 QQoovl06969 for ; Thu, 15 May 2003 21:23:59 GMT Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4FLMC14012555; Thu, 15 May 2003 17:22:12 -0400 (EDT) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id RAA04296; Thu, 15 May 2003 17:22:11 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA07043; Thu, 15 May 2003 17:22:11 -0400 (EDT) Message-Id: <200305152122.RAA07043@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "Ling Yan" cc: mpls@UU.NET, swallow@cisco.com Subject: Re: Question regarding null padding session name in RSVP-TE Att obj In-reply-to: Your message of "Thu, 15 May 2003 15:34:53 EDT." <3EC3EBDD.7AFA1B63@americasm01.nt.com> Date: Thu, 15 May 2003 17:22:11 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > I have a simple question regarding null padding to the session name > to make it to be a multiple of 4 and at least 8 in RSVP-TE attribute > object. It is really appreciated if someone can help to clarify it. > Thanks in advance. > > If the string length is exactly a multiple of 4 and greater than 8 > without counting null padding or null terminate character, -- > 1) is it required to add at least null terminated char to indicate the > string termination? No. But it would not be illegal to add a multiple of 4 nulls. But optimally you should only add 0-3 nulls. > 2) is it required to check at the receiver whether the session name is > null terminated or not? Only to find the end of the string. I.e. if the last char is printable it should pass. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From owner-mpls@UU.NET Fri May 16 19:22: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 TAA14423 for ; Fri, 16 May 2003 19:22: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 QQoozl25063 for ; Fri, 16 May 2003 23:25:26 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 QQoozl21633; Fri, 16 May 2003 23:23:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQoozi18019 for mpls-outgoing; Fri, 16 May 2003 22:43:02 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 QQoozi18012 for ; Fri, 16 May 2003 22:42:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoozi24839 for ; Fri, 16 May 2003 22:42:20 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 QQoozi12160 for ; Fri, 16 May 2003 22:42:20 GMT Received: from ix.eng.level3.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQoozi12154 for ; Fri, 16 May 2003 22:42:19 GMT Received: from level3.net (localhost.eng.level3.com [127.0.0.1]) by ix.eng.level3.com (8.11.0/8.11.0) with ESMTP id h4GMcF429092 for ; Fri, 16 May 2003 16:38:15 -0600 Message-ID: <3EC56856.2070402@level3.net> Date: Fri, 16 May 2003 16:38:14 -0600 From: Luca Martini Organization: Level3 Communications LLC. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- MIME-Version: 1.0 To: mpls@UU.NET Subject: Call for Presenations at MPLS 2003, October 26-28, Washington DC Content-Type: text/plain; charset=windows-1252; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA14423 The MPLS 2003 Conference will be held in Washington D.C. from October 26 through October 28. This year’s conference will include but not limited to topics such as: - MPLS as a convergence technology - MPLS network management and operational issues - Provisioning and migration strategies - MPLS in multi-AS networks - L2 VPNs (pseudo-wire, VPLS, and other) - L3 VPNs (BGP/MPLS, IPSec interworking, virtual routers, and other) - Scalability and performance - Traffic engineering and QoS - Network processor architectures for next generation applications - Testing MPLS applications and performance - Network security - Disaster recovery - Reliability and graceful restart techniques - Optical Integration and challenges The Program Committee of MPLS 2003 is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution please send a one page long proposal, including speaker’s contact details to the attention of the Technical Program Committee at TPC@mpls2003.com by June 27, 2003. See www.mpls2003.com for more details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations from the vendor, service provider and user community are solicited on new technologies and operational experience. From owner-mpls@UU.NET Fri May 16 21:49: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 VAA16810 for ; Fri, 16 May 2003 21:49:30 -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 QQoozr05403; Sat, 17 May 2003 00:46:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQoozo21367 for mpls-outgoing; Sat, 17 May 2003 00:02: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 QQoozo20025 for ; Sat, 17 May 2003 00:02:32 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 QQoozo19867 for ; Sat, 17 May 2003 00:01: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 QQoozo13700 for ; Sat, 17 May 2003 00:01:58 GMT Received: from dog.tcb.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dog.tcb.net [64.78.150.133]) id QQoozo13682 for ; Sat, 17 May 2003 00:01:58 GMT Received: from [192.168.1.33] (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id CDC4820298 for ; Fri, 16 May 2003 18:06:51 -0600 (MDT) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Fri, 16 May 2003 18:01:44 -0600 Subject: FW: CW & MPLS "PID" From: Danny McPherson To: Message-ID: In-Reply-To: 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 unquestionably germane to the MPLS WG. Please provide comments here or on the pwe3@ietf.org mailing list. Thanks! -danny ------ Forwarded Message From: Danny McPherson Date: Fri, 16 May 2003 17:59:59 -0600 To: Subject: CW & MPLS "PID" The second issue gating progress with the PWE3, and the architecture draft specifically, that needs to be resolved relates to the design of the Control Word and its relationship to any MPLS protocol identification mechanism. Please provide feedback (of all sorts) to the following summary on the list within the next week if you've got something to say. We intend to move forward shortly. Thanks, Stewart/Danny ================== Section 5.4.3 of the current WG Architecture document mandates that if the CW is used the encoding MUST be as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID | Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The draft suggests the use of the value 0, to distinguish it from IP which uses the values 4 and 6. After the San Francisco meeting proposals were made to the list specifying a more general MPLS PID mechanism that used a value of 1 in bits 0..3 to indicate that the rest of the longword contained a protocol identifier drawn from a registry that allowed the following payload to be identified. The purpose of the identifier was to support the transport of OAM messages and to allow any PW payload that could not, for some reason, conform to the requirement that bits 0..3 = 0 to operate correctly over an ECMP MPLS network. There is some concern from the MPLS WG as to the extent to which they will support an MPLS PID, and it is suggested that the PWE3 work needs to be self contained. This needs to be future investigated. For all the payload design groups EXCLUDING the SONET and TDM groups there seems to be some consensus for the following wording: >5.4.3. PW over MPLS Generic Control Word > > To allow accurate packet inspection in an MPLS PSN, and to operate > correctly over MPLS PSNs that have deployed equal-cost multiple-path > load-balancing a PW packet MUST NOT alias an IP packet. IP packets > are carried in MPLS label stacks without any protocol identifier. > Historic values of the IP version number [RFC791] [RFC1881] are > therefore used to distinguish between IP and non-IP MPLS payloads. > > To disambiguate the PW from an IP flow the PW SHOULD employ either > the generic PW control word shown in Figure 12, or an MPLS payload > type identifier. Note that an MPLS payload with bits 0..3 = 4 is an > IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Specified by PW Encapsulation | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: Generic PW Control Word > > > The PW set-up protocol determines whether a PW uses a control word. > When a control word is used, it SHOULD have the following preferred > form: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Flags |FRG| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: MPLS Preferred Control Word > and >5.4.4. MPLS Payload Identifier > > If technical considerations result in a PW control word that may > alias an IP packet, the control word SHOULD be preceded by an MPLS > payload type identifier. > > For reference the MPLS payload type identifier [TBD] is defined as > follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved | PPP DLL Protocol Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | As defined by PPP DLL protocol definition | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: MPLS Payload Type Identifier This is the proposal put forward by George Swallow and is a subset of Dave Alan's proposal except for the sense of one bit. Figure 12 allows CWs that followed the Martini design to be grandfathered and due to the values found in a practical network, the Single ATM VCC Cell Encapsulation conforms to Figure 11. Figure 14 specifies a MPLS Payload identifier that is sufficient for PWE3 purposes (including the support of OAM messages), and yet is sufficiently general that other groups can likely make any extensions that they find necessary. The questions are: EXCLUDING any TDM/SONET specific issues is this CW design agreeable to the PWE3 WG? Is the MPLS payload identifier design acceptable to the group proposing OAM/VCCP mechanisms, and if not, what constraints does it place on future related work? Is the MPLS payload identifier design acceptable to the MPLS WG as the basis of a future mechanism should that be required? If so, is it acceptable to the MPLS WG that PWE3 incorporate this design within its normative documents in order to make progress? [Note that this message will be forwarded to the MPLS WG mailing list.] ------ End of Forwarded Message From owner-mpls@UU.NET Sat May 17 10: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 KAA09039 for ; Sat, 17 May 2003 10: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 QQopbt26066 for ; Sat, 17 May 2003 14:26: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 QQopbt24860; Sat, 17 May 2003 14:25:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQopbr26169 for mpls-outgoing; Sat, 17 May 2003 13:48: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 QQopbr26162 for ; Sat, 17 May 2003 13:48:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQopbr02360 for ; Sat, 17 May 2003 13:48: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 QQopah13908 for ; Sat, 17 May 2003 04:49: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 h4H4n2kL015882 for ; Sat, 17 May 2003 00:49: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 AAA04186 for ; Sat, 17 May 2003 00:49:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4H4n2005018 for mpls@uu.net; Sat, 17 May 2003 00:49: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 QQopah01682 for ; Sat, 17 May 2003 04:48: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 QQopah00954 for ; Sat, 17 May 2003 04:47: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 QQopah16521 for ; Sat, 17 May 2003 04:47:38 GMT Received: from sj-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-core-1.cisco.com [171.71.177.237]) id QQopah16507 for ; Sat, 17 May 2003 04:47:37 GMT Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4EFGPxG015295; Wed, 14 May 2003 08:16:25 -0700 (PDT) Received: from [10.1.1.9] (sjc-vpn3-751.cisco.com [10.21.66.239]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAY87645; Wed, 14 May 2003 08:16:21 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 14 May 2003 11:16:20 -0400 Subject: Re: [MPLS-OPS]: Advertising Routes learnt from PE to PE From: Aamer Akhter To: "Sugar, Sylvia" , CC: Message-ID: In-Reply-To: <20030514140640.62067.qmail@web20710.mail.yahoo.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 On 5/14/03 10:06 AM, "Sugar, Sylvia" wrote: > Hi, > WIll a PE router ever advertise a route it learns from another PE router to > some other PE router. > I dont think it will ever do that as all the PE routers are IBGP peers and > would generally be in > full mesh. You're correct. The exception would a route-reflector / confederation. But as you know by default, these bgp nodes don't change the next-hop. > > Is there any case when this might happen .. i.e. a PE router advertises a > Route learnt from one PE > to another PE. How can one do that .. because IMHO the label that will be > advertised by the former > PE router will be for the PE router to which he sends the UPDATE. How can this > PE router advertise > another PE router the same label? > > Moreover, if for some reason he has to .. does he assign a new label and then > advertise? A RR will allocate a label (locally) if the next-hop changes. Of course this doens't mean much unless the next-hop is the RR itself. ;-) > > ANy comments on this would be very helpful! > > Silviya Sugar > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems From owner-mpls@UU.NET Sat May 17 20:05: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 UAA17992 for ; Sat, 17 May 2003 20:05: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 QQopdg17404 for ; Sun, 18 May 2003 00:07: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 QQopdg17350; Sun, 18 May 2003 00:07:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQopde13341 for mpls-outgoing; Sat, 17 May 2003 23:32:18 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 QQopde13336 for ; Sat, 17 May 2003 23:32: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 QQopde21916 for ; Sat, 17 May 2003 23:31: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 QQopde10759 for ; Sat, 17 May 2003 23:31:05 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 QQopde10740 for ; Sat, 17 May 2003 23:31: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 h4HNV2Jh014847 for ; Sat, 17 May 2003 19:31: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 TAA11474 for ; Sat, 17 May 2003 19:31:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4HNV2521253 for mpls@uu.net; Sat, 17 May 2003 19:31: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 QQopde13158 for ; Sat, 17 May 2003 23:30: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 QQopdd16617 for ; Sat, 17 May 2003 23:29: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 QQopdd08952 for ; Sat, 17 May 2003 23:29:59 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 QQopdd08934 for ; Sat, 17 May 2003 23:29:59 GMT Received: from zaliw2k01 (rtp-vpn1-458.cisco.com [10.82.225.202]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4HNTskL018007; Sat, 17 May 2003 19:29:55 -0400 (EDT) From: "zafar ali" To: , Cc: "'Anca Zamfir'" Subject: A new draft for Explicit Resource Control over GMPLS Link Bundles is available for your comments Date: Sat, 17 May 2003 19:29:54 -0400 Message-ID: <003701c31ccc$396e6c70$91053918@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C31CAA.B25CCC70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C31CAA.B25CCC70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Fellows, A new draft for Explicit Resource Control over GMPLS Link Bundles is available for your comments and suggestions. Please find the draft at the IETF Web site, http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-contr ol-bundle-01.txt Abstract Explicit label/ resource control using the Label ERO and Label RRO subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE links are bundled, identification of label resource is not enough for the purpose of explicit resource control. Specifically, when link bundling [GMPLS-BUNDLE] is used, resource identification requires mechanisms to specify the component link identifier, along the TE link identifier and Label. This draft defines the extensions to RSVP- TE [RFC2119, RFC3209] to specify component link identifiers for explicit resource control and recording over GMPLS link bundles. Revision History Version 00 was posted on March 4, 2003, but we just missed the cut-off time for the 56th IETF meeting in San Francisco. Since then we have made some minor changes. Your input will be much appreciated, as usual. Thanks Regards... Anca & Zafar ------=_NextPart_000_0038_01C31CAA.B25CCC70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Dear=20 Fellows,
 
A new=20 draft for Explicit Resource Control over GMPLS Link Bundles is available = for=20 your comments and suggestions. Please find the draft at the IETF Web = site,=20
 
http://www.ietf.org/internet-drafts/draft-zamfir= -explicit-resource-control-bundle-01.txt
 
Abstract
    =
  =20 Explicit label/ resource control using the Label ERO and Label RRO=20
   subobjects is defined in [RFC 3471] and [RFC 3473]. = However,=20 when TE
   links are bundled, identification of label = resource is=20 not enough for
   the purpose of explicit resource = control.=20 Specifically, when link
   bundling [GMPLS-BUNDLE] is = used,=20 resource identification requires
   mechanisms to specify = the=20 component link identifier, along the TE
   link identifier = and=20 Label. This draft defines the extensions to RSVP-
   TE = [RFC2119,=20 RFC3209] to specify component link identifiers for
   = explicit=20 resource control and recording over GMPLS link bundles. =
 
Revision History
 
Version 00 was posted on March 4, 2003, but = we=20 just missed the cut-off time for the 56th IETF meeting in = San=20 Francisco. Since then we have made some minor changes.=20
 
Your input will be much appreciated, as usual.

Thanks
 
Regards...=20 Anca & Zafar=20
------=_NextPart_000_0038_01C31CAA.B25CCC70-- From owner-mpls@UU.NET Mon May 19 05:46: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 FAA13256 for ; Mon, 19 May 2003 05:46: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 QQopil25906 for ; Mon, 19 May 2003 09:49: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 QQopil25662; Mon, 19 May 2003 09:49:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQopii21420 for mpls-outgoing; Mon, 19 May 2003 09:10:35 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 QQopii21341 for ; Mon, 19 May 2003 09:10:16 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 QQopii26519 for ; Mon, 19 May 2003 09:08: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 QQopii25158 for ; Mon, 19 May 2003 09:08:55 GMT Received: from mta0.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQopii24854 for ; Mon, 19 May 2003 09:08:49 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 <0HF400BGIMIGTE@mta0.huawei.com> for mpls@UU.NET; Mon, 19 May 2003 17:03:55 +0800 (CST) Date: Mon, 19 May 2003 17:05:33 +0800 From: lidefeng Subject: Doubt about RFC 3107 To: mpls@UU.NET Message-id: <000f01c31de5$ce2a49a0$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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT It is stated in section 6 of RFC 3107 that "This is true any time labels are distributed between non-adjacent LSRs, whether that distribution is done by BGP or by some othermethod." What does it mean?Maybe it is totally wrong at all? Who can explain it? Regards Li Defeng Huawei technologies From owner-mpls@UU.NET Mon May 19 20:47:37 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 UAA11764 for ; Mon, 19 May 2003 20:47: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 QQopkt25118 for ; Tue, 20 May 2003 00:50: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 QQopkt24850; Tue, 20 May 2003 00:50:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQopkq05791 for mpls-outgoing; Tue, 20 May 2003 00: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 QQopkq05783 for ; Tue, 20 May 2003 00:14:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQopkq29227 for ; Tue, 20 May 2003 00:13: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 QQopkq01853 for ; Tue, 20 May 2003 00:13:47 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 QQopkq01814 for ; Tue, 20 May 2003 00:13:46 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with ESMTP id CE19C1644; Mon, 19 May 2003 20:13:43 -0400 (EDT) Message-ID: <017501c31e64$aafbfdf0$681810ac@movaz.com> From: "Adrian Farrel" To: , , Cc: "'mpls@uu.net'" Subject: draft-ietf-mpls-soft-preemption-00 Date: Mon, 19 May 2003 20:13:40 -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, I still have a concern about this draft. My understanding of the existing RFCs is that the soft-preemption behavior that you want is what is already specified. There is, perhaps, an issue that the error code used for preemption is not well specified in RFC3209. I'd appreciate your thoughts. Thanks, Adrian ========= In the Abstract you say "Under present RSVP-TE signaling methods, LSPs are immediately displaced upon preemption." and in section 2, Motivation, you have "Present MPLS RSVP-TE implementations only support a method of TE LSP preemption which immediately tears down TE LSPs, disregarding the preempted in-transit traffic, in an effort to make way for a higher priority TE LSP if not enough bandwidth is available on the link to accommodate the newly signaled high priority TE LSPs. This process nearly guarantees preempted traffic will be discarded, if only briefly, until the RSVP Path Error message reaches and is processed by the head-end (HE) and a new forwarding path can be established." I disagree with your interpretation of RFC3209. Section 4.7.3 has " When preemption is supported, each preempted reservation triggers a TC_Preempt() upcall to local clients, passing a subcode that indicates the reason. A ResvErr and/or PathErr with the code "Policy Control failure" SHOULD be sent toward the downstream receivers and upstream senders." I'm inclined to agree with what George said in SF: this is a hole in RFC3209. If we turn to RFC2205 for a definition of Policy Control Failure we find in Appendix B... " o Error Code = 02: Policy Control failure Reservation or path message has been rejected for administrative reasons, for example, required credentials not submitted, insufficient quota or balance, or administrative preemption. This Error Code may appear in a PathErr or ResvErr message. Contents of the Error Value field are to be determined in the future." Nowhere here do I see anything that says that the LSP is torn down, but rather that the traffic becomes best effort (which is what you want in your draft). Perhaps the main issue is that nearly all the references to PathErr in RFC3209 relate to errors during the LSP setup procedure. But surely PathErr messages that happen after the LSP has been established inherit their behavior from RFC2205 if there is nothing else described in RFC3209. Section 3.5 or RFC2205 says " There are two RSVP error messages, ResvErr and PathErr. PathErr messages are very simple; they are simply sent upstream to the sender that created the error, and they do not change path state in the nodes though which they pass. There are only a few possible causes of path errors." Note that there is already a suitable error code defined in RFC 2205. " o Error Code = 12: Service preempted The service request defined by the STYLE object and the flow descriptor has been administratively preempted. For this Error Code, the 16 bits of the Error Value field are: ssur cccc cccc cccc Here the high-order bits ssur are as defined under Error Code 01. The globally-defined sub-codes that may appear in the low- order 12 bits when ssur = 0000 are to be defined in the future." This tends to imply that the Error Code is only available for use on a ResvErr (since that is where the flow descriptor is). Alternatively, you could either define a new Error Value for the "Policy Control failure" Error Code, or perhaps you would rather move the condition to the "Notify" Error Code. For consistency, one might assign the new Error Value using the ssur cccc cccc cccc format, setting the u-bit to 1 to show that this represents a state update that should be passed onwards, although RFC3209 doesn't bother with the u-bit and says " For the Notify Error Code, the 16 bits of the Error Value field are: ss00 cccc cccc cccc" From owner-mpls@UU.NET Mon May 19 21:43: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 VAA12578 for ; Mon, 19 May 2003 21:43: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 QQopkx12024 for ; Tue, 20 May 2003 01:46: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 QQopkx11516; Tue, 20 May 2003 01:46:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQopku29914 for mpls-outgoing; Tue, 20 May 2003 01: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 QQopku29907 for ; Tue, 20 May 2003 01:14:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQopku07290 for ; Tue, 20 May 2003 01:14: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 QQopku20483 for ; Tue, 20 May 2003 01:14:08 GMT Received: from mta0.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQopku20358 for ; Tue, 20 May 2003 01:14:03 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 <0HF500FXGVCSOD@mta0.huawei.com> for mpls@UU.NET; Tue, 20 May 2003 09:12:30 +0800 (CST) Date: Tue, 20 May 2003 09:14:10 +0800 From: lidefeng Subject: Questions in draft-ietf-mpls-lsp-ping-02.txt To: mpls@UU.NET Message-id: <000b01c31e6d$1ea98300$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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT In section "5.3. Procedures at the ingress LSR" of draft-ietf-mpls-lsp-ping-02.txt,it states that"To test an LSP that carries non-IP traffic, before injecting ICMP and MPLS ping messages into the LSP, the IPv4 Explicit NULL label should be prepended to such messages. The ingress and egress LSR's must follow the procedures defined in [LABEL-STACK]." While in RFC 3032(section 2.1. Encoding the Label Stack),the definition of IPv4 Explicit NULL label is as following: i. A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header. It is explicitly stated that " This label value is only legal at the bottom of the label stack." ,while in draft-ietf-mpls-lsp-ping-02.txt,it states that this "IPv4 Explicit NULL label should be prepended to such messages",Is it inconsistent with each other? Another question is that why shouls this IPv4 Explicit NULL label should be prepended to such messages? TIA Defeng Li Huawei technologies From owner-mpls@UU.NET Mon May 19 22:30: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 WAA13470 for ; Mon, 19 May 2003 22:30: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 QQopla15120 for ; Tue, 20 May 2003 02:33: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 QQopla14672; Tue, 20 May 2003 02:33:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQopky17479 for mpls-outgoing; Tue, 20 May 2003 02:03:02 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 QQopky16817 for ; Tue, 20 May 2003 02:02:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQopky02432 for ; Tue, 20 May 2003 02:01: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 QQopky29150 for ; Tue, 20 May 2003 02:01:50 GMT Received: from mta0.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQopky29053 for ; Tue, 20 May 2003 02:01:48 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 <0HF500FI7XKBOD@mta0.huawei.com> for mpls@UU.NET; Tue, 20 May 2003 10:00:12 +0800 (CST) Date: Tue, 20 May 2003 10:01:52 +0800 From: lidefeng Subject: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt To: ppvpn@nortelnetworks.com Cc: mpls@UU.NET, pwe3@ietf.org Message-id: <001601c31e73$c8a5fea0$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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Some questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt In 8.1.1 Hierarchical L2 Circuit FEC Stack Sub-Type ,there are "Encapsulation Type" field and " L2 specific Sub-TLV (Optional)" field in the proposed Hierarchical L2 Circuit,while,in the "L2 specific Sub-TLV (Optional)" field, there is "Type (0x000B)" field in it,I want to know what's the difference between the "Encapsulation Type" in the Hierarchical L2 Circuit and the "Type" in "L2 specific Sub-TLV (Optional)" ? If they are both used,isn't one of them is redundant? Isn't reasonable use only one of them? The relevant format is copied to the following. Hierarchical L2 Circuit: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encapsulation Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 specific Sub-TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 specific Sub-TLV : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x000B) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Ethernet MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 802.1Q Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Ethernet MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 802.1Q Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From owner-mpls@UU.NET Tue May 20 03:33: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 DAA01999 for ; Tue, 20 May 2003 03:33: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 QQoplu18361 for ; Tue, 20 May 2003 07:36: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 QQoplu17813; Tue, 20 May 2003 07:36:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQopls23161 for mpls-outgoing; Tue, 20 May 2003 07:05: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 QQopls23156 for ; Tue, 20 May 2003 07:05: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 QQopls16198 for ; Tue, 20 May 2003 07:04: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 QQopls05869 for ; Tue, 20 May 2003 07:04:26 GMT Received: from mta1.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQopls05799 for ; Tue, 20 May 2003 07:04:22 GMT Received: from l04955 (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0HF6000PPBETLH@mta1.huawei.com> for mpls@UU.NET; Tue, 20 May 2003 14:59:19 +0800 (CST) Date: Tue, 20 May 2003 15:04:13 +0800 From: lidefeng Subject: Doubt about LC-ATM interfce To: mpls@UU.NET Message-id: <003601c31e9e$0a9af7a0$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=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT "An ATM-LSR domain is a set of ATM-LSRs which are mutually interconnected by LC-ATM interfaces. The Edge Set of an ATM-LSR domain is the set of frame-based LSRs which are connected to members of the domain by LC-ATM interfaces. A frame-based LSR which is a member of an Edge Set of an ATM-LSR domain may be called an Edge LSR." In the LC-ATM interface which connect the frame-based LSR and the ATM-LSR in the ATM-LSR domain,which format was carried,cell format or frame format? From owner-mpls@UU.NET Tue May 20 07:16: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 HAA05840 for ; Tue, 20 May 2003 07:16: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 QQopjb13876 for ; Mon, 19 May 2003 13:57:32 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 QQopjb13810; Mon, 19 May 2003 13:57:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQopiz22914 for mpls-outgoing; Mon, 19 May 2003 13:17:14 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 QQopiz22909 for ; Mon, 19 May 2003 13:17:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQopiz14637 for ; Mon, 19 May 2003 13:16: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 QQopiz23946 for ; Mon, 19 May 2003 13:16:15 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bay8-f121.bay8.hotmail.com [64.4.27.121]) id QQopiz23703 for ; Mon, 19 May 2003 13:16:09 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 May 2003 06:16:08 -0700 Received: from 57.250.229.136 by by8fd.bay8.hotmail.msn.com with HTTP; Mon, 19 May 2003 13:16:08 GMT X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] From: "M. ELK" To: lidefeng@huawei.com, mpls@UU.NET Subject: Re: Doubt about RFC 3107 Date: Mon, 19 May 2003 13:16:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 May 2003 13:16:08.0274 (UTC) FILETIME=[CF48EB20:01C31E08] Sender: owner-mpls@UU.NET Precedence: bulk Li AFAIK , it i simply mean that if U have A-B-C-D and "A" and "D" are having a label distribution session (using BGP or Targeted LDP) ,if "D" distribute label "L1" to "A" so "A" can not use "L1" unless their is an LSP from A to D . ie: we need a tunnel (lsp) from A to D . The catch that "A" have no mean to find out that such LSP exist if "independent" label assignement are used . Ex: "D" advertise a label "L5" to "C" for it's loopback address . "C" have been configured (say by mistake) to not advertise label for "D" loopback address or simply link B-C is not mpls link . "B" will advertise label "L10" for FEC "D loopback address" to "A" . "D" advertise to "A" (through BGP or targeted LDP) label "L1" say for fec 10./8 Now "A" is under the impression that an LSP exist toward D and if it want to transmit pavket to 10./8 it will create a label stack with {L10,L1} and send to "B" . B pop the top label ("L10" ,with cisco terminology the action is Untag) and expect to see plain IP packet but it is not the case so it will drop the packet . If the label assignement is "ordered" such pblm do not exist . ie"B" will never advertised a label for "D" loopback address unless "B" recieved a label for same . Brgds >From: lidefeng >To: mpls@UU.NET >Subject: Doubt about RFC 3107 >Date: Mon, 19 May 2003 17:05:33 +0800 > >It is stated in section 6 of RFC 3107 that "This is true any time labels >are >distributed between non-adjacent LSRs, whether that distribution is done by >BGP or by some othermethod." > >What does it mean?Maybe it is totally wrong at all? > >Who can explain it? > >Regards > >Li Defeng > >Huawei technologies > > _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-mpls@UU.NET Tue May 20 08:10: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 IAA08249 for ; Tue, 20 May 2003 08:10: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 QQopmm17462 for ; Tue, 20 May 2003 12:13: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 QQopmm16292; Tue, 20 May 2003 12:13:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQopmk29102 for mpls-outgoing; Tue, 20 May 2003 11:32:15 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 QQopmk29095 for ; Tue, 20 May 2003 11:32:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQopmk21840 for ; Tue, 20 May 2003 11:31: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 QQopmk02662 for ; Tue, 20 May 2003 11:31: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 QQopmk02637 for ; Tue, 20 May 2003 11:31: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 h4KBV2kL008574 for ; Tue, 20 May 2003 07:31: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 HAA07482 for ; Tue, 20 May 2003 07:31:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4KBV2P21935 for mpls@uu.net; Tue, 20 May 2003 07:31: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 QQopmk28903 for ; Tue, 20 May 2003 11:30: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 QQopmk28199 for ; Tue, 20 May 2003 11:30: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 QQopmk11043 for ; Tue, 20 May 2003 11:30:07 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 QQopmk11019 for ; Tue, 20 May 2003 11:30:07 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06306; Tue, 20 May 2003 07:26:59 -0400 (EDT) Message-Id: <200305201126.HAA06306@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-nodeid-subobject-01.txt Date: Tue, 20 May 2003 07:26:59 -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 : Definition of an RRO node-id subobject Author(s) : J. Vasseur et al. Filename : draft-ietf-mpls-nodeid-subobject-01.txt Pages : 8 Date : 2003-5-19 In the context of MPLS TE Fast Reroute ([FAST-REROUTE]), the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering LSP on a downstream LSR. However, existing protocol mechanisms are not sufficient to find an MP address in multi-areas or multi-domain routing networks. Hence, the current MPLS Fast Reroute mechanism cannot be used to protect inter-area or inter-AS TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. This document specifies the use of existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to define the node-id subobject in order to solve this issue. Note that the MPLS Fast reroute mechanism mentioned in this draft refers to the 'Facility backup' MPLS TE Fast Reroute method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-nodeid-subobject-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-nodeid-subobject-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-nodeid-subobject-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-5-19142122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-nodeid-subobject-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-nodeid-subobject-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-19142122.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue May 20 15:40: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 PAA27787 for ; Tue, 20 May 2003 15:40: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 QQopnq00356 for ; Tue, 20 May 2003 19:40: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 QQopnq00119; Tue, 20 May 2003 19:40:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQopno03474 for mpls-outgoing; Tue, 20 May 2003 19:11: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 QQopno03296 for ; Tue, 20 May 2003 19:10:58 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 QQopno03561 for ; Tue, 20 May 2003 19:09: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 QQopno03419 for ; Tue, 20 May 2003 19:09:22 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 QQopno03403 for ; Tue, 20 May 2003 19:09:21 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 h4KJ9IkL020224 for ; Tue, 20 May 2003 15:09: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 PAA16634 for ; Tue, 20 May 2003 15:09:18 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4KJ9Ip24428 for mpls@uu.net; Tue, 20 May 2003 15:09: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 QQopnn13960 for ; Tue, 20 May 2003 18:54:48 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 QQopnn18873 for ; Tue, 20 May 2003 18:54:45 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 QQopnn16417 for ; Tue, 20 May 2003 18:54:45 GMT Received: from fep01-mail.bloor.is.net.cable.rogers.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) id QQopnn16388 for ; Tue, 20 May 2003 18:54:40 GMT Received: from dune ([24.103.66.219]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030520185427.OKIH9289.fep01-mail.bloor.is.net.cable.rogers.com@dune> for ; Tue, 20 May 2003 14:54:27 -0400 Message-ID: <005001c31f01$0b6e1d20$2202a8c0@flfrd.phub.net.cable.rogers.com> From: "Martin Dubuc" To: Subject: IP Addresses for TE links Date: Tue, 20 May 2003 14:53:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C31EDF.83E6FF00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.103.66.219] using ID at Tue, 20 May 2003 14:54:27 -0400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C31EDF.83E6FF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable During the TE link MIB review, a question was raised regarding the types = of IP address that can be assigned to a TE link. Can traffic engineering = links be created over link local or site local interfaces/links? RFC = 3291 now specifies new address types, i.e. non-global IPv4/IPv6 = addresses that include a zone index. Are these new address types = applicable to TE links? Martin ------=_NextPart_000_004D_01C31EDF.83E6FF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
During the TE link MIB review, a question was raised = regarding=20 the types of IP address that can be assigned to a TE link. Can traffic=20 engineering links be created over link local or site local = interfaces/links? RFC=20 3291 now specifies new address types, i.e. non-global IPv4/IPv6=20 addresses that include a zone index. Are these new address types = applicable=20 to TE links?
 
Martin
------=_NextPart_000_004D_01C31EDF.83E6FF00-- From owner-mpls@UU.NET Tue May 20 18:37: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 SAA03992 for ; Tue, 20 May 2003 18:37: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 QQopoc04728 for ; Tue, 20 May 2003 22:37: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 QQopoc04275; Tue, 20 May 2003 22:37:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQopnz24353 for mpls-outgoing; Tue, 20 May 2003 21:52: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 QQopnz24268 for ; Tue, 20 May 2003 21:52: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 QQopnz19952 for ; Tue, 20 May 2003 21:51: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 QQopnz28931 for ; Tue, 20 May 2003 21:51:18 GMT Received: from mail3.extremenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sc-f100-01.extremenetworks.com [63.251.106.30]) id QQopnz28909 for ; Tue, 20 May 2003 21:51:17 GMT Received: by mail3.extremenetworks.com with Internet Mail Service (5.5.2655.55) id ; Tue, 20 May 2003 14:48:59 -0700 Message-ID: <82F679A6A377F84B8F665D8F90D12B8DD8F35A@sc-msexch-05.extremenetworks.com> From: Olen Stokes To: "'lidefeng'" , ppvpn@nortelnetworks.com Cc: mpls@UU.NET, pwe3@ietf.org Subject: RE: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt Date: Tue, 20 May 2003 14:47:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="gb2312" Sender: owner-mpls@UU.NET Precedence: bulk It was simply set up that way to allow for future flexibility. Cheers, Olen > -----Original Message----- > From: lidefeng [mailto:lidefeng@huawei.com] > Sent: Monday, May 19, 2003 10:02 PM > To: ppvpn@nortelnetworks.com > Cc: mpls@UU.NET; pwe3@ietf.org > Subject: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > > Some questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > In 8.1.1 Hierarchical L2 Circuit FEC Stack Sub-Type ,there are > "Encapsulation Type" field and " L2 specific Sub-TLV > (Optional)" field in > the proposed Hierarchical L2 Circuit,while,in the "L2 > specific Sub-TLV > (Optional)" field, there is "Type (0x000B)" field in it,I want to know > what's the difference between the "Encapsulation Type" in the > Hierarchical > L2 Circuit and the "Type" in "L2 specific Sub-TLV (Optional)" > ? If they are > both used,isn't one of them is redundant? Isn't reasonable > use only one of > them? > > The relevant format is copied to the following. > > Hierarchical L2 Circuit: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VC ID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Encapsulation Type | Must Be Zero > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | L2 specific Sub-TLV (Optional) > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > L2 specific Sub-TLV : > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (0x000B) | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Target Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sender Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > From owner-mpls@UU.NET Tue May 20 19:05: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 TAA04925 for ; Tue, 20 May 2003 19:05: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 QQopoe22124 for ; Tue, 20 May 2003 23:05: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 QQopoe21107; Tue, 20 May 2003 23:04:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQopob15151 for mpls-outgoing; Tue, 20 May 2003 22:21:55 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 QQopob15143 for ; Tue, 20 May 2003 22:21:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQopob03839 for ; Tue, 20 May 2003 22:20:41 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 QQopob20932 for ; Tue, 20 May 2003 22:20:41 GMT Received: from db1.contentcatcher.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.19.188.18]) id QQopob20917 for ; Tue, 20 May 2003 22:20:40 GMT Received: from CC1 ([192.168.200.2]) by db1.contentcatcher.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 May 2003 18:17:01 -0400 x-sender: owner-mpls@UU.NET x-receiver: spamtrap@spam.clearnetwork.com Received: from pf2.contentcatcher.com ([192.168.100.3]) by CC1 with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 May 2003 18:20:54 -0400 Received: by pf2.contentcatcher.com (Postfix, from userid 500) id 9C7529F103; Tue, 20 May 2003 18:08:37 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by pf2.contentcatcher.com (Postfix) with SMTP id 912E39F103 for ; Tue, 20 May 2003 18: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 QQopob06543 for ; Tue, 20 May 2003 22:20: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 QQopob06355; Tue, 20 May 2003 22:20:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQopnz24353 for mpls-outgoing; Tue, 20 May 2003 21:52: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 QQopnz24268 for ; Tue, 20 May 2003 21:52: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 QQopnz19952 for ; Tue, 20 May 2003 21:51: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 QQopnz28931 for ; Tue, 20 May 2003 21:51:18 GMT Received: from mail3.extremenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sc-f100-01.extremenetworks.com [63.251.106.30]) id QQopnz28909 for ; Tue, 20 May 2003 21:51:17 GMT Received: by mail3.extremenetworks.com with Internet Mail Service (5.5.2655.55) id ; Tue, 20 May 2003 14:48:59 -0700 Message-ID: <82F679A6A377F84B8F665D8F90D12B8DD8F35A@sc-msexch-05.extremenetworks.com> Date: Tue, 20 May 2003 14:47:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain;charset="gb2312" X-Spam-Status: Yes, hits=9.0 required=5.0tests=BAYES_90,CC_Bulk_Header_1version=2.53-contentcatcher X-Spam-Level: ********* X-Spam-Checker-Version: SpamAssassin 2.53-contentcatcher (1.174.2.15-2003-03-30-exp) X-Spam-Report: ---- Start SpamAssassin results9.00 points, 5 required;* 5.0 -- Mail has precedence set to bulk* 4.0 -- BODY: Bayesian classifier says spam probability is 90 to 99%[score: 0.9880]---- End of SpamAssassin results X-Spam-Flag: YES X-VIRUS-FOUND: NO X-GHOST-SENDER: owner-mpls@UU.NET X-GHOST-RECEIVER: BRaja@tellium.com X-OriginalArrivalTime: 20 May 2003 22:20:54.0046 (UTC) FILETIME=[13EFABE0:01C31F1E] x-contentCatcher: ContentCatcher build 0407021738 Cc: mpls@UU.NET, pwe3@ietf.org To: BRaja@tellium.com From: "Olen Stokes" Subject: RE: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt [owner-mpls@UU.NET in Pass-Through List] ['from' in Pass-Through List] Sender: owner-mpls@UU.NET Precedence: bulk It was simply set up that way to allow for future flexibility. Cheers, Olen > -----Original Message----- > From: lidefeng [mailto:lidefeng@huawei.com] > Sent: Monday, May 19, 2003 10:02 PM > To: ppvpn@nortelnetworks.com > Cc: mpls@UU.NET; pwe3@ietf.org > Subject: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > > Some questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > In 8.1.1 Hierarchical L2 Circuit FEC Stack Sub-Type ,there are > "Encapsulation Type" field and " L2 specific Sub-TLV > (Optional)" field in > the proposed Hierarchical L2 Circuit,while,in the "L2 > specific Sub-TLV > (Optional)" field, there is "Type (0x000B)" field in it,I want to know > what's the difference between the "Encapsulation Type" in the > Hierarchical > L2 Circuit and the "Type" in "L2 specific Sub-TLV (Optional)" > ? If they are > both used,isn't one of them is redundant? Isn't reasonable > use only one of > them? > > The relevant format is copied to the following. > > Hierarchical L2 Circuit: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VC ID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Encapsulation Type | Must Be Zero > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | L2 specific Sub-TLV (Optional) > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > L2 specific Sub-TLV : > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (0x000B) | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Target Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sender Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > From owner-mpls@UU.NET Tue May 20 19:09: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 TAA05097 for ; Tue, 20 May 2003 19:09: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 QQopoe00390 for ; Tue, 20 May 2003 23:09:26 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 QQopoe29913; Tue, 20 May 2003 23:09:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQopob15354 for mpls-outgoing; Tue, 20 May 2003 22:23:36 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 QQopob15345 for ; Tue, 20 May 2003 22:23: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 QQopob13242 for ; Tue, 20 May 2003 22:23: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 QQopob24486 for ; Tue, 20 May 2003 22:23:25 GMT Received: from db1.contentcatcher.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.19.188.18]) id QQopob24476 for ; Tue, 20 May 2003 22:23:25 GMT Received: from CC1 ([192.168.200.2]) by db1.contentcatcher.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 May 2003 18:19:51 -0400 x-sender: owner-mpls@UU.NET x-receiver: spamtrap@spam.clearnetwork.com Received: from pf2.contentcatcher.com ([192.168.100.3]) by CC1 with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 May 2003 18:23:43 -0400 Received: by pf2.contentcatcher.com (Postfix, from userid 500) id 55C4B9F103; Tue, 20 May 2003 18:11:27 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by pf2.contentcatcher.com (Postfix) with SMTP id 5C4679F112 for ; Tue, 20 May 2003 18:11:20 -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 QQopob11130 for ; Tue, 20 May 2003 22: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 QQopob10627; Tue, 20 May 2003 22:23:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQopnz24353 for mpls-outgoing; Tue, 20 May 2003 21:52: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 QQopnz24268 for ; Tue, 20 May 2003 21:52: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 QQopnz19952 for ; Tue, 20 May 2003 21:51: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 QQopnz28931 for ; Tue, 20 May 2003 21:51:18 GMT Received: from mail3.extremenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sc-f100-01.extremenetworks.com [63.251.106.30]) id QQopnz28909 for ; Tue, 20 May 2003 21:51:17 GMT Received: by mail3.extremenetworks.com with Internet Mail Service (5.5.2655.55) id ; Tue, 20 May 2003 14:48:59 -0700 Message-ID: <82F679A6A377F84B8F665D8F90D12B8DD8F35A@sc-msexch-05.extremenetworks.com> Date: Tue, 20 May 2003 14:47:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain;charset="gb2312" X-Spam-Status: Yes, hits=9.0 required=5.0tests=BAYES_90,CC_Bulk_Header_1version=2.53-contentcatcher X-Spam-Level: ********* X-Spam-Checker-Version: SpamAssassin 2.53-contentcatcher (1.174.2.15-2003-03-30-exp) X-Spam-Report: ---- Start SpamAssassin results9.00 points, 5 required;* 5.0 -- Mail has precedence set to bulk* 4.0 -- BODY: Bayesian classifier says spam probability is 90 to 99%[score: 0.9881]---- End of SpamAssassin results X-Spam-Flag: YES X-VIRUS-FOUND: NO X-GHOST-SENDER: owner-mpls@UU.NET X-GHOST-RECEIVER: rkalathur@tellium.com X-OriginalArrivalTime: 20 May 2003 22:23:43.0781 (UTC) FILETIME=[791B2D50:01C31F1E] x-contentCatcher: ContentCatcher build 0407021738 Cc: mpls@UU.NET, pwe3@ietf.org To: rkalathur@tellium.com From: "Olen Stokes" Subject: RE: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt [owner-mpls@UU.NET in Pass-Through List] Sender: owner-mpls@UU.NET Precedence: bulk It was simply set up that way to allow for future flexibility. Cheers, Olen > -----Original Message----- > From: lidefeng [mailto:lidefeng@huawei.com] > Sent: Monday, May 19, 2003 10:02 PM > To: ppvpn@nortelnetworks.com > Cc: mpls@UU.NET; pwe3@ietf.org > Subject: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > > Some questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > In 8.1.1 Hierarchical L2 Circuit FEC Stack Sub-Type ,there are > "Encapsulation Type" field and " L2 specific Sub-TLV > (Optional)" field in > the proposed Hierarchical L2 Circuit,while,in the "L2 > specific Sub-TLV > (Optional)" field, there is "Type (0x000B)" field in it,I want to know > what's the difference between the "Encapsulation Type" in the > Hierarchical > L2 Circuit and the "Type" in "L2 specific Sub-TLV (Optional)" > ? If they are > both used,isn't one of them is redundant? Isn't reasonable > use only one of > them? > > The relevant format is copied to the following. > > Hierarchical L2 Circuit: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VC ID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Encapsulation Type | Must Be Zero > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | L2 specific Sub-TLV (Optional) > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > L2 specific Sub-TLV : > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (0x000B) | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Target Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sender Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > From owner-mpls@UU.NET Thu May 22 14:30:50 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 OAA23799 for ; Thu, 22 May 2003 14:30: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 QQopuw06223 for ; Thu, 22 May 2003 18:30: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 QQopuw05604; Thu, 22 May 2003 18:30:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQoput21451 for mpls-outgoing; Thu, 22 May 2003 17:52: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 QQoput21440 for ; Thu, 22 May 2003 17:52:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoput26603 for ; Thu, 22 May 2003 17:49:56 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 QQoput17948 for ; Thu, 22 May 2003 17:49:56 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 QQoput17924 for ; Thu, 22 May 2003 17:49:55 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4MHnlu04350; Thu, 22 May 2003 10:49:48 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 22 May 2003 10:49:47 -0700 (PDT) From: Ina Minei To: Adrian Farrel cc: mrm@gblx.net, "" , "" , "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-soft-preemption-00 In-Reply-To: <017501c31e64$aafbfdf0$681810ac@movaz.com> Message-ID: <20030521152520.Q56705@garnet.juniper.net> References: <017501c31e64$aafbfdf0$681810ac@movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello Adrian, As far as I can see, the two issues raised are: 1) the need for the soft-preemption draft 2) the use of the rro mechanism rather than a path error for the notifications. I will address them separately below. 1) The need for soft-preemption I agree that 3209 doesn't explicitly specify that the preempted lsp should be torn down. However, rfc 2702, when discussing the preemption attribute makes it clear that preemption is there to accomodate the case where there are not enough resources to share, and overbooking is not mentioned. Thinking of the goal that preemption is trying to achieve, it seems reasonable that immediate teardown would be performed. In any case, I think a specification is necessary for soft-preemption. I also believe there is value in allowing the user to specify whether soft preemption is desired or not on a per-lsp basis and how long the overbooking may be maintained. 2) The use of rro vs path error The original proposal for this draft was to use a path-error message (and allocate a new notify-error subcode), just like you propose. A few private and public discussions on this topic took place. There are pros/cons to both approaches, and the authors decided to pick the rro solution. Ina On Mon, 19 May 2003, Adrian Farrel wrote: > Hi, > > I still have a concern about this draft. My understanding of the existing RFCs > is that the soft-preemption behavior that you want is what is already specified. > There is, perhaps, an issue that the error code used for preemption is not well > specified in RFC3209. > > I'd appreciate your thoughts. > Thanks, > Adrian > > ========= > > In the Abstract you say > "Under present RSVP-TE signaling methods, LSPs are immediately displaced upon > preemption." > > and in section 2, Motivation, you have > "Present MPLS RSVP-TE implementations only support a method of TE LSP > preemption which immediately tears down TE LSPs, disregarding the > preempted in-transit traffic, in an effort to make way for a higher > priority TE LSP if not enough bandwidth is available on the link to > accommodate the newly signaled high priority TE LSPs. This process > nearly guarantees preempted traffic will be discarded, if only briefly, > until the RSVP Path Error message reaches and is processed by the > head-end (HE) and a new forwarding path can be established." > > I disagree with your interpretation of RFC3209. > > Section 4.7.3 has > " When preemption is supported, each preempted reservation triggers a > TC_Preempt() upcall to local clients, passing a subcode that > indicates the reason. A ResvErr and/or PathErr with the code "Policy > Control failure" SHOULD be sent toward the downstream receivers and > upstream senders." > > I'm inclined to agree with what George said in SF: this is a hole in RFC3209. > If we turn to RFC2205 for a definition of Policy Control Failure we find in > Appendix B... > " o Error Code = 02: Policy Control failure > > Reservation or path message has been rejected for administrative > reasons, for example, required credentials not submitted, > insufficient quota or balance, or administrative preemption. > This Error Code may appear in a PathErr or ResvErr message. > > Contents of the Error Value field are to be determined in the > future." > > Nowhere here do I see anything that says that the LSP is torn down, but rather > that the traffic becomes best effort (which is what you want in your draft). > Perhaps the main issue is that nearly all the references to PathErr in RFC3209 > relate to errors during the LSP setup procedure. But surely PathErr messages > that happen after the LSP has been established inherit their behavior from > RFC2205 if there is nothing else described in RFC3209. > > Section 3.5 or RFC2205 says > " There are two RSVP error messages, ResvErr and PathErr. PathErr > messages are very simple; they are simply sent upstream to the > sender that created the error, and they do not change path state > in the nodes though which they pass. There are only a few > possible causes of path errors." > > > Note that there is already a suitable error code defined in RFC 2205. > > " o Error Code = 12: Service preempted > > The service request defined by the STYLE object and the flow > descriptor has been administratively preempted. > > For this Error Code, the 16 bits of the Error Value field are: > ssur cccc cccc cccc > > Here the high-order bits ssur are as defined under Error Code > 01. The globally-defined sub-codes that may appear in the low- > order 12 bits when ssur = 0000 are to be defined in the future." > > This tends to imply that the Error Code is only available for use on a ResvErr > (since that is where the flow descriptor is). > > Alternatively, you could either define a new Error Value for the "Policy Control > failure" Error Code, or perhaps you would rather move the condition to the > "Notify" Error Code. For consistency, one might assign the new Error Value > using the ssur cccc cccc cccc format, setting the u-bit to 1 to show that this > represents a state update that should be passed onwards, although RFC3209 > doesn't bother with the u-bit and says > " For the Notify Error Code, the 16 bits of the Error Value field are: > ss00 cccc cccc cccc" > > > From owner-mpls@UU.NET Thu May 22 15:06: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 PAA25447 for ; Thu, 22 May 2003 15:06: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 QQopuy24781 for ; Thu, 22 May 2003 19:06: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 QQopuy23653; Thu, 22 May 2003 19:05:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQopuv12186 for mpls-outgoing; Thu, 22 May 2003 18:18: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 QQopuv12169 for ; Thu, 22 May 2003 18:17:57 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 QQopuv01280 for ; Thu, 22 May 2003 18:15: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 QQopuv03764 for ; Thu, 22 May 2003 18:15:52 GMT Received: from db1.contentcatcher.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.19.188.18]) id QQopuv03741 for ; Thu, 22 May 2003 18:15:52 GMT Received: from CC2 ([192.168.200.3]) by db1.contentcatcher.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 14:12:17 -0400 x-sender: owner-mpls@UU.NET x-receiver: spamtrap@spam.clearnetwork.com Received: from pf2.contentcatcher.com ([192.168.100.3]) by CC2 with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 14:16:39 -0400 Received: by pf2.contentcatcher.com (Postfix, from userid 500) id DA6B59F103; Thu, 22 May 2003 14:03:26 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by pf2.contentcatcher.com (Postfix) with SMTP id DA74E9F103 for ; Thu, 22 May 2003 14:03: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 QQopuv08028 for ; Thu, 22 May 2003 18:15: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 QQopuv07814; Thu, 22 May 2003 18:15:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQoput21451 for mpls-outgoing; Thu, 22 May 2003 17:52: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 QQoput21440 for ; Thu, 22 May 2003 17:52:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoput26603 for ; Thu, 22 May 2003 17:49:56 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 QQoput17948 for ; Thu, 22 May 2003 17:49:56 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 QQoput17924 for ; Thu, 22 May 2003 17:49:55 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4MHnlu04350; Thu, 22 May 2003 10:49:48 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 22 May 2003 10:49:47 -0700 (PDT) In-Reply-To: <017501c31e64$aafbfdf0$681810ac@movaz.com> Message-ID: <20030521152520.Q56705@garnet.juniper.net> References: <017501c31e64$aafbfdf0$681810ac@movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: Yes, hits=5.0 required=5.0tests=BAYES_90,CC_Bulk_Header_1,IN_REP_TO,RCVD_IN_DSBL,REFERENCESversion=2.53-contentcatcher X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53-contentcatcher (1.174.2.15-2003-03-30-exp) X-Spam-Report: ---- Start SpamAssassin results5.00 points, 5 required;* -1.0 -- Has a In-Reply-To header* 5.0 -- Mail has precedence set to bulk* -4.0 -- Has a valid-looking References header* 4.0 -- BODY: Bayesian classifier says spam probability is 90 to 99%[score: 0.9458]* 1.0 -- RBL: Received via a relay in list.dsbl.org[RBL check: found 39.241.5.198.list.dsbl.org.]---- End of SpamAssassin results X-Spam-Flag: YES X-VIRUS-FOUND: NO X-GHOST-SENDER: owner-mpls@UU.NET X-GHOST-RECEIVER: BRaja@tellium.com X-OriginalArrivalTime: 22 May 2003 18:16:39.0312 (UTC) FILETIME=[49DC3900:01C3208E] x-contentCatcher: ContentCatcher build 0407021738 Cc: mrm@gblx.net, denver@gblx.net, jpv@cisco.com, "mpls@uu.net" To: BRaja@tellium.com From: "Ina Minei" Subject: Re: draft-ietf-mpls-soft-preemption-00 [owner-mpls@UU.NET in Pass-Through List] ['from' in Pass-Through List] Sender: owner-mpls@UU.NET Precedence: bulk Hello Adrian, As far as I can see, the two issues raised are: 1) the need for the soft-preemption draft 2) the use of the rro mechanism rather than a path error for the notifications. I will address them separately below. 1) The need for soft-preemption I agree that 3209 doesn't explicitly specify that the preempted lsp should be torn down. However, rfc 2702, when discussing the preemption attribute makes it clear that preemption is there to accomodate the case where there are not enough resources to share, and overbooking is not mentioned. Thinking of the goal that preemption is trying to achieve, it seems reasonable that immediate teardown would be performed. In any case, I think a specification is necessary for soft-preemption. I also believe there is value in allowing the user to specify whether soft preemption is desired or not on a per-lsp basis and how long the overbooking may be maintained. 2) The use of rro vs path error The original proposal for this draft was to use a path-error message (and allocate a new notify-error subcode), just like you propose. A few private and public discussions on this topic took place. There are pros/cons to both approaches, and the authors decided to pick the rro solution. Ina On Mon, 19 May 2003, Adrian Farrel wrote: > Hi, > > I still have a concern about this draft. My understanding of the existing RFCs > is that the soft-preemption behavior that you want is what is already specified. > There is, perhaps, an issue that the error code used for preemption is not well > specified in RFC3209. > > I'd appreciate your thoughts. > Thanks, > Adrian > > ========= > > In the Abstract you say > "Under present RSVP-TE signaling methods, LSPs are immediately displaced upon > preemption." > > and in section 2, Motivation, you have > "Present MPLS RSVP-TE implementations only support a method of TE LSP > preemption which immediately tears down TE LSPs, disregarding the > preempted in-transit traffic, in an effort to make way for a higher > priority TE LSP if not enough bandwidth is available on the link to > accommodate the newly signaled high priority TE LSPs. This process > nearly guarantees preempted traffic will be discarded, if only briefly, > until the RSVP Path Error message reaches and is processed by the > head-end (HE) and a new forwarding path can be established." > > I disagree with your interpretation of RFC3209. > > Section 4.7.3 has > " When preemption is supported, each preempted reservation triggers a > TC_Preempt() upcall to local clients, passing a subcode that > indicates the reason. A ResvErr and/or PathErr with the code "Policy > Control failure" SHOULD be sent toward the downstream receivers and > upstream senders." > > I'm inclined to agree with what George said in SF: this is a hole in RFC3209. > If we turn to RFC2205 for a definition of Policy Control Failure we find in > Appendix B... > " o Error Code = 02: Policy Control failure > > Reservation or path message has been rejected for administrative > reasons, for example, required credentials not submitted, > insufficient quota or balance, or administrative preemption. > This Error Code may appear in a PathErr or ResvErr message. > > Contents of the Error Value field are to be determined in the > future." > > Nowhere here do I see anything that says that the LSP is torn down, but rather > that the traffic becomes best effort (which is what you want in your draft). > Perhaps the main issue is that nearly all the references to PathErr in RFC3209 > relate to errors during the LSP setup procedure. But surely PathErr messages > that happen after the LSP has been established inherit their behavior from > RFC2205 if there is nothing else described in RFC3209. > > Section 3.5 or RFC2205 says > " There are two RSVP error messages, ResvErr and PathErr. PathErr > messages are very simple; they are simply sent upstream to the > sender that created the error, and they do not change path state > in the nodes though which they pass. There are only a few > possible causes of path errors." > > > Note that there is already a suitable error code defined in RFC 2205. > > " o Error Code = 12: Service preempted > > The service request defined by the STYLE object and the flow > descriptor has been administratively preempted. > > For this Error Code, the 16 bits of the Error Value field are: > ssur cccc cccc cccc > > Here the high-order bits ssur are as defined under Error Code > 01. The globally-defined sub-codes that may appear in the low- > order 12 bits when ssur = 0000 are to be defined in the future." > > This tends to imply that the Error Code is only available for use on a ResvErr > (since that is where the flow descriptor is). > > Alternatively, you could either define a new Error Value for the "Policy Control > failure" Error Code, or perhaps you would rather move the condition to the > "Notify" Error Code. For consistency, one might assign the new Error Value > using the ssur cccc cccc cccc format, setting the u-bit to 1 to show that this > represents a state update that should be passed onwards, although RFC3209 > doesn't bother with the u-bit and says > " For the Notify Error Code, the 16 bits of the Error Value field are: > ss00 cccc cccc cccc" > > > From owner-mpls@UU.NET Thu May 22 15:13: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 PAA26348 for ; Thu, 22 May 2003 15:13: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 QQopuy11105 for ; Thu, 22 May 2003 19:13: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 QQopuy09767; Thu, 22 May 2003 19:13:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQopuv12671 for mpls-outgoing; Thu, 22 May 2003 18:25: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 QQopuv12638 for ; Thu, 22 May 2003 18:25: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 QQopuv11518 for ; Thu, 22 May 2003 18:18:41 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 QQopuv07903 for ; Thu, 22 May 2003 18:18:40 GMT Received: from db1.contentcatcher.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.19.188.18]) id QQopuv07887 for ; Thu, 22 May 2003 18:18:39 GMT Received: from CC1 ([192.168.200.2]) by db1.contentcatcher.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 14:15:06 -0400 x-sender: owner-mpls@UU.NET x-receiver: spamtrap@spam.clearnetwork.com Received: from pf2.contentcatcher.com ([192.168.100.3]) by CC1 with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 14:18:58 -0400 Received: by pf2.contentcatcher.com (Postfix, from userid 500) id 77ABF9F103; Thu, 22 May 2003 14:06:15 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by pf2.contentcatcher.com (Postfix) with SMTP id A11989F103 for ; Thu, 22 May 2003 14:06: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 QQopuv12683 for ; Thu, 22 May 2003 18:18: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 QQopuv12463; Thu, 22 May 2003 18:18:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQoput21451 for mpls-outgoing; Thu, 22 May 2003 17:52: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 QQoput21440 for ; Thu, 22 May 2003 17:52:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoput26603 for ; Thu, 22 May 2003 17:49:56 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 QQoput17948 for ; Thu, 22 May 2003 17:49:56 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 QQoput17924 for ; Thu, 22 May 2003 17:49:55 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4MHnlu04350; Thu, 22 May 2003 10:49:48 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 22 May 2003 10:49:47 -0700 (PDT) In-Reply-To: <017501c31e64$aafbfdf0$681810ac@movaz.com> Message-ID: <20030521152520.Q56705@garnet.juniper.net> References: <017501c31e64$aafbfdf0$681810ac@movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: Yes, hits=5.0 required=5.0tests=BAYES_90,CC_Bulk_Header_1,IN_REP_TO,RCVD_IN_DSBL,REFERENCESversion=2.53-contentcatcher X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53-contentcatcher (1.174.2.15-2003-03-30-exp) X-Spam-Report: ---- Start SpamAssassin results5.00 points, 5 required;* -1.0 -- Has a In-Reply-To header* 5.0 -- Mail has precedence set to bulk* -4.0 -- Has a valid-looking References header* 4.0 -- BODY: Bayesian classifier says spam probability is 90 to 99%[score: 0.9458]* 1.0 -- RBL: Received via a relay in list.dsbl.org[RBL check: found 39.241.5.198.list.dsbl.org.]---- End of SpamAssassin results X-Spam-Flag: YES X-VIRUS-FOUND: NO X-GHOST-SENDER: owner-mpls@UU.NET X-GHOST-RECEIVER: rkalathur@tellium.com X-OriginalArrivalTime: 22 May 2003 18:18:59.0000 (UTC) FILETIME=[9D1EEB80:01C3208E] x-contentCatcher: ContentCatcher build 0407021738 Cc: mrm@gblx.net, denver@gblx.net, jpv@cisco.com, "mpls@uu.net" To: rkalathur@tellium.com From: "Ina Minei" Subject: Re: draft-ietf-mpls-soft-preemption-00 [owner-mpls@UU.NET in Pass-Through List] Sender: owner-mpls@UU.NET Precedence: bulk Hello Adrian, As far as I can see, the two issues raised are: 1) the need for the soft-preemption draft 2) the use of the rro mechanism rather than a path error for the notifications. I will address them separately below. 1) The need for soft-preemption I agree that 3209 doesn't explicitly specify that the preempted lsp should be torn down. However, rfc 2702, when discussing the preemption attribute makes it clear that preemption is there to accomodate the case where there are not enough resources to share, and overbooking is not mentioned. Thinking of the goal that preemption is trying to achieve, it seems reasonable that immediate teardown would be performed. In any case, I think a specification is necessary for soft-preemption. I also believe there is value in allowing the user to specify whether soft preemption is desired or not on a per-lsp basis and how long the overbooking may be maintained. 2) The use of rro vs path error The original proposal for this draft was to use a path-error message (and allocate a new notify-error subcode), just like you propose. A few private and public discussions on this topic took place. There are pros/cons to both approaches, and the authors decided to pick the rro solution. Ina On Mon, 19 May 2003, Adrian Farrel wrote: > Hi, > > I still have a concern about this draft. My understanding of the existing RFCs > is that the soft-preemption behavior that you want is what is already specified. > There is, perhaps, an issue that the error code used for preemption is not well > specified in RFC3209. > > I'd appreciate your thoughts. > Thanks, > Adrian > > ========= > > In the Abstract you say > "Under present RSVP-TE signaling methods, LSPs are immediately displaced upon > preemption." > > and in section 2, Motivation, you have > "Present MPLS RSVP-TE implementations only support a method of TE LSP > preemption which immediately tears down TE LSPs, disregarding the > preempted in-transit traffic, in an effort to make way for a higher > priority TE LSP if not enough bandwidth is available on the link to > accommodate the newly signaled high priority TE LSPs. This process > nearly guarantees preempted traffic will be discarded, if only briefly, > until the RSVP Path Error message reaches and is processed by the > head-end (HE) and a new forwarding path can be established." > > I disagree with your interpretation of RFC3209. > > Section 4.7.3 has > " When preemption is supported, each preempted reservation triggers a > TC_Preempt() upcall to local clients, passing a subcode that > indicates the reason. A ResvErr and/or PathErr with the code "Policy > Control failure" SHOULD be sent toward the downstream receivers and > upstream senders." > > I'm inclined to agree with what George said in SF: this is a hole in RFC3209. > If we turn to RFC2205 for a definition of Policy Control Failure we find in > Appendix B... > " o Error Code = 02: Policy Control failure > > Reservation or path message has been rejected for administrative > reasons, for example, required credentials not submitted, > insufficient quota or balance, or administrative preemption. > This Error Code may appear in a PathErr or ResvErr message. > > Contents of the Error Value field are to be determined in the > future." > > Nowhere here do I see anything that says that the LSP is torn down, but rather > that the traffic becomes best effort (which is what you want in your draft). > Perhaps the main issue is that nearly all the references to PathErr in RFC3209 > relate to errors during the LSP setup procedure. But surely PathErr messages > that happen after the LSP has been established inherit their behavior from > RFC2205 if there is nothing else described in RFC3209. > > Section 3.5 or RFC2205 says > " There are two RSVP error messages, ResvErr and PathErr. PathErr > messages are very simple; they are simply sent upstream to the > sender that created the error, and they do not change path state > in the nodes though which they pass. There are only a few > possible causes of path errors." > > > Note that there is already a suitable error code defined in RFC 2205. > > " o Error Code = 12: Service preempted > > The service request defined by the STYLE object and the flow > descriptor has been administratively preempted. > > For this Error Code, the 16 bits of the Error Value field are: > ssur cccc cccc cccc > > Here the high-order bits ssur are as defined under Error Code > 01. The globally-defined sub-codes that may appear in the low- > order 12 bits when ssur = 0000 are to be defined in the future." > > This tends to imply that the Error Code is only available for use on a ResvErr > (since that is where the flow descriptor is). > > Alternatively, you could either define a new Error Value for the "Policy Control > failure" Error Code, or perhaps you would rather move the condition to the > "Notify" Error Code. For consistency, one might assign the new Error Value > using the ssur cccc cccc cccc format, setting the u-bit to 1 to show that this > represents a state update that should be passed onwards, although RFC3209 > doesn't bother with the u-bit and says > " For the Notify Error Code, the 16 bits of the Error Value field are: > ss00 cccc cccc cccc" > > > From owner-mpls@UU.NET Thu May 22 17:22: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 RAA29187 for ; Thu, 22 May 2003 17:22: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 QQopvh29054 for ; Thu, 22 May 2003 21:22: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 QQopvh28543; Thu, 22 May 2003 21:22:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQopve29992 for mpls-outgoing; Thu, 22 May 2003 20:44: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 QQopve29980 for ; Thu, 22 May 2003 20:43:47 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 QQopve22735 for ; Thu, 22 May 2003 20:43:39 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 QQopve18363 for ; Thu, 22 May 2003 20:43:38 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 QQopve18347 for ; Thu, 22 May 2003 20:43:38 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4MKhSu18812; Thu, 22 May 2003 13:43:32 -0700 (PDT) (envelope-from ina@juniper.net) Date: Thu, 22 May 2003 13:43:28 -0700 (PDT) From: Ina Minei To: lidefeng cc: mpls@UU.NET Subject: Re: Questions in draft-ietf-mpls-lsp-ping-02.txt In-Reply-To: <000b01c31e6d$1ea98300$07436e0a@HUAWEI.COM> Message-ID: <20030519192501.F74631@garnet.juniper.net> References: <000b01c31e6d$1ea98300$07436e0a@HUAWEI.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk "label 0 is prepended" means label 0 is added to the bottom of the stack, so there is no conflict with 3032. The authors wanted to ensure that the lsping probe arrives at the endpoint of the tunnel as a labeled packet with label 0 rather than an ip packet. Ina On Tue, 20 May 2003, lidefeng wrote: > In section "5.3. Procedures at the ingress LSR" of > draft-ietf-mpls-lsp-ping-02.txt,it states that"To test an LSP that carries > non-IP traffic, before injecting ICMP and MPLS ping messages into the LSP, > the IPv4 Explicit NULL label should be prepended to such messages. The > ingress and egress LSR's must follow the procedures defined in > [LABEL-STACK]." > > While in RFC 3032(section 2.1. Encoding the Label Stack),the definition of > IPv4 Explicit NULL label is as following: > > i. A value of 0 represents the "IPv4 Explicit NULL Label". > This label value is only legal at the bottom of the label > stack. It indicates that the label stack must be popped, > and the forwarding of the packet must then be based on the > IPv4 header. > > It is explicitly stated that " This label value is only legal at the bottom > of the label stack." ,while in draft-ietf-mpls-lsp-ping-02.txt,it states > that this "IPv4 Explicit NULL label should be prepended to such messages",Is > it inconsistent with each other? > > Another question is that why shouls this IPv4 Explicit NULL label should be > prepended to such messages? > > TIA > > Defeng Li > > Huawei technologies > From owner-mpls@UU.NET Fri May 23 10:53: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 KAA08250 for ; Fri, 23 May 2003 10:53: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 QQopxz09887 for ; Fri, 23 May 2003 14:53:26 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 QQopxz09518; Fri, 23 May 2003 14:53:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQopxx23100 for mpls-outgoing; Fri, 23 May 2003 14:15:47 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 QQopxx23095 for ; Fri, 23 May 2003 14:15:44 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 QQopxx16485 for ; Fri, 23 May 2003 14:15: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 QQopxx06206 for ; Fri, 23 May 2003 14:15:38 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 QQopxx06174 for ; Fri, 23 May 2003 14:15: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 h4NEFYXg028339 for ; Fri, 23 May 2003 10:15: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 KAA26629 for ; Fri, 23 May 2003 10:15:34 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4NEFY501136 for mpls@uu.net; Fri, 23 May 2003 10:15:34 -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 QQopxw22695 for ; Fri, 23 May 2003 14:13:44 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 QQopxw12098 for ; Fri, 23 May 2003 14:12:43 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 QQopxw28808 for ; Fri, 23 May 2003 14:12:42 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 QQopxw28756 for ; Fri, 23 May 2003 14:12:40 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06418; Fri, 23 May 2003 10:12:37 -0400 (EDT) Message-Id: <200305231412.KAA06418@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-telink-mib-02.txt Date: Fri, 23 May 2003 10:12:37 -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 : Traffic Engineering Link Management Information Base Author(s) : M. Dubuc, S. Dharanikota, T. Nadeau, J. Lang Filename : draft-ietf-mpls-telink-mib-02.txt Pages : 46 Date : 2003-5-22 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 modeling TE links as described in the Link Bundling in MPLS Traffic Engineering document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-telink-mib-02.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-telink-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-telink-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-22134219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-telink-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-telink-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-22134219.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri May 23 11:16: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 LAA09427 for ; Fri, 23 May 2003 11:16: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 QQopyb02703 for ; Fri, 23 May 2003 15:16: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 QQopyb01517; Fri, 23 May 2003 15:16:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQopxy24729 for mpls-outgoing; Fri, 23 May 2003 14:35:56 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 QQopxy24713 for ; Fri, 23 May 2003 14:35:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQopxy01822 for ; Fri, 23 May 2003 14:34: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 QQopxy08654 for ; Fri, 23 May 2003 14:34:40 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 QQopxy08635 for ; Fri, 23 May 2003 14:34:39 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with ESMTP id DE5A1163C; Fri, 23 May 2003 10:34:41 -0400 (EDT) Message-ID: <001701c32138$75c2ed20$681810ac@movaz.com> From: "Adrian Farrel" To: "Ina Minei" Cc: , , , "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-soft-preemption-00 Date: Fri, 23 May 2003 10:34: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 Re-send: Doesn't appear to have hit the list. Adrian ----- Original Message ----- From: "Adrian Farrel" To: "Ina Minei" Cc: ; ; ; "'mpls@uu.net'" Sent: Thursday, May 22, 2003 3:23 PM Subject: Re: draft-ietf-mpls-soft-preemption-00 > Hi Ina, > > Thanks for engaging. > > > As far as I can see, the two issues raised are: > > 1) the need for the soft-preemption draft > > 2) the use of the rro mechanism rather than a path error for the > > notifications. > > > > I will address them separately below. > > That's fine. > I am trying to discuss only issue 1). > I have strong feelings about the use of the RRO for this proposal, but I don't > want to get into them at this stage. > > > 1) The need for soft-preemption > > I agree that 3209 doesn't explicitly specify that the > > preempted lsp should be torn down. However, rfc 2702, when discussing the > > preemption attribute makes it clear that preemption is there to accomodate > > the case where there are not enough resources to share, and overbooking is > > not mentioned. Thinking of the goal that preemption is trying to achieve, > > it seems reasonable that immediate teardown would be performed. > > I think this depends radically on the network type. In an optical network, for > example, it is wholly reasonable to say that preemption of a resource at a > particular node breaks the LSP. That is, if I take the laser and use it for > something else, then traffic on the old LSP stops flowing. This also probably > causes alarms. > > Depending on the way that this intercepted resource is used, the downstream LSP > may need to be torn (to prevent data being sent to the wrong place). > If the LSP is bidirectional, the upstream LSP may also need to be torn. > There is a facility for both of these options (PathTear and PathErr with state > removal). > > On the other hand in some optical networks, it will be highly desirable to avoid > resource churn by leaving the most of the LPS in place and treating the > preemption just like an alarm or a resource failure. The ingress (or some other > repair point) can use make before break to repair around the error without > deprovisioning and reprovisioning at all of the other nodes. > > Now, in a packet network, we can add to this list the facility for > over-provisioniing and handling traffic as best effort. In these cases the most > that happens is that the LSP is degraded. The level of this degradation is on a > scale from total (as in the optical network) to none, when the traffic on other > resource users is low. If there is ever the cahnce of passing traffic, it seems > best to do so. This will show less impact for the customer. > > > In any case, I think a specification is necessary for > > soft-preemption. I also believe there is value in allowing the user to > > specify whether soft preemption is desired or not on a per-lsp basis > > I have no issue with this. The change, however, is one of semantics. That is, if > you want *hard* preemption to occur at the preempting node (i.e. LSP teardown to > begin at the preempting node) this will require a new session attribute. As I > hope I made clear, my opinion is that preemption is already soft by default. > > > and > > how long the overbooking may be maintained. > > This is not an issue for the preempting node to manage on behalf of the ingress. > Rather, it is an issue for the ingress to manage for the LSP, and the preempting > node to manage on its own behalf. > > You would be better to have the preempted node report the time for which it will > continue to allow over subscription when it reports the preemption. > > > Anyway, nothing I have been shown, RFC2702 notwithstanding, suggests to me other > than the current correct behavior of upstream nodes receiving a PathErr > reporting preemption is to keep the LSP in place. This is why the state removal > flag was introduced to the PathErr. > > > Cheers, > Adrian > > > > > > 2) The use of rro vs path error > > The original proposal for this draft was to use a path-error > > message (and allocate a new notify-error subcode), just like you propose. > > A few private and public discussions on this topic took place. There are > > pros/cons to both approaches, and the authors decided to pick the rro > > solution. > > > > Ina > > > > On Mon, 19 May 2003, Adrian Farrel wrote: > > > > > Hi, > > > > > > I still have a concern about this draft. My understanding of the existing > RFCs > > > is that the soft-preemption behavior that you want is what is already > specified. > > > There is, perhaps, an issue that the error code used for preemption is not > well > > > specified in RFC3209. > > > > > > I'd appreciate your thoughts. > > > Thanks, > > > Adrian > > > > > > ========= > > > > > > In the Abstract you say > > > "Under present RSVP-TE signaling methods, LSPs are immediately displaced > upon > > > preemption." > > > > > > and in section 2, Motivation, you have > > > "Present MPLS RSVP-TE implementations only support a method of TE LSP > > > preemption which immediately tears down TE LSPs, disregarding the > > > preempted in-transit traffic, in an effort to make way for a higher > > > priority TE LSP if not enough bandwidth is available on the link to > > > accommodate the newly signaled high priority TE LSPs. This process > > > nearly guarantees preempted traffic will be discarded, if only briefly, > > > until the RSVP Path Error message reaches and is processed by the > > > head-end (HE) and a new forwarding path can be established." > > > > > > I disagree with your interpretation of RFC3209. > > > > > > Section 4.7.3 has > > > " When preemption is supported, each preempted reservation triggers a > > > TC_Preempt() upcall to local clients, passing a subcode that > > > indicates the reason. A ResvErr and/or PathErr with the code "Policy > > > Control failure" SHOULD be sent toward the downstream receivers and > > > upstream senders." > > > > > > I'm inclined to agree with what George said in SF: this is a hole in > RFC3209. > > > If we turn to RFC2205 for a definition of Policy Control Failure we find in > > > Appendix B... > > > " o Error Code = 02: Policy Control failure > > > > > > Reservation or path message has been rejected for administrative > > > reasons, for example, required credentials not submitted, > > > insufficient quota or balance, or administrative preemption. > > > This Error Code may appear in a PathErr or ResvErr message. > > > > > > Contents of the Error Value field are to be determined in the > > > future." > > > > > > Nowhere here do I see anything that says that the LSP is torn down, but > rather > > > that the traffic becomes best effort (which is what you want in your draft). > > > Perhaps the main issue is that nearly all the references to PathErr in > RFC3209 > > > relate to errors during the LSP setup procedure. But surely PathErr messages > > > that happen after the LSP has been established inherit their behavior from > > > RFC2205 if there is nothing else described in RFC3209. > > > > > > Section 3.5 or RFC2205 says > > > " There are two RSVP error messages, ResvErr and PathErr. PathErr > > > messages are very simple; they are simply sent upstream to the > > > sender that created the error, and they do not change path state > > > in the nodes though which they pass. There are only a few > > > possible causes of path errors." > > > > > > > > > Note that there is already a suitable error code defined in RFC 2205. > > > > > > " o Error Code = 12: Service preempted > > > > > > The service request defined by the STYLE object and the flow > > > descriptor has been administratively preempted. > > > > > > For this Error Code, the 16 bits of the Error Value field are: > > > ssur cccc cccc cccc > > > > > > Here the high-order bits ssur are as defined under Error Code > > > 01. The globally-defined sub-codes that may appear in the low- > > > order 12 bits when ssur = 0000 are to be defined in the future." > > > > > > This tends to imply that the Error Code is only available for use on a > ResvErr > > > (since that is where the flow descriptor is). > > > > > > Alternatively, you could either define a new Error Value for the "Policy > Control > > > failure" Error Code, or perhaps you would rather move the condition to the > > > "Notify" Error Code. For consistency, one might assign the new Error Value > > > using the ssur cccc cccc cccc format, setting the u-bit to 1 to show that > this > > > represents a state update that should be passed onwards, although RFC3209 > > > doesn't bother with the u-bit and says > > > " For the Notify Error Code, the 16 bits of the Error Value field are: > > > ss00 cccc cccc cccc" > > From owner-mpls@UU.NET Fri May 23 13:00: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 NAA13486 for ; Fri, 23 May 2003 13:00: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 QQopyi07480 for ; Fri, 23 May 2003 17:00: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 QQopyi07097; Fri, 23 May 2003 17:00:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQopyf10438 for mpls-outgoing; Fri, 23 May 2003 16:26: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 QQopyf10433 for ; Fri, 23 May 2003 16:26:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQopyf11744 for ; Fri, 23 May 2003 16:22:16 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 QQopuz18751 for ; Thu, 22 May 2003 19:23:15 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with ESMTP id BA2BF164E; Thu, 22 May 2003 15:23:16 -0400 (EDT) Message-ID: <02d401c32097$967ada10$681810ac@movaz.com> From: "Adrian Farrel" To: "Ina Minei" Cc: , , , "'mpls@uu.net'" References: <017501c31e64$aafbfdf0$681810ac@movaz.com> <20030521152520.Q56705@garnet.juniper.net> Subject: Re: draft-ietf-mpls-soft-preemption-00 Date: Thu, 22 May 2003 15:23:13 -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 Ina, Thanks for engaging. > As far as I can see, the two issues raised are: > 1) the need for the soft-preemption draft > 2) the use of the rro mechanism rather than a path error for the > notifications. > > I will address them separately below. That's fine. I am trying to discuss only issue 1). I have strong feelings about the use of the RRO for this proposal, but I don't want to get into them at this stage. > 1) The need for soft-preemption > I agree that 3209 doesn't explicitly specify that the > preempted lsp should be torn down. However, rfc 2702, when discussing the > preemption attribute makes it clear that preemption is there to accomodate > the case where there are not enough resources to share, and overbooking is > not mentioned. Thinking of the goal that preemption is trying to achieve, > it seems reasonable that immediate teardown would be performed. I think this depends radically on the network type. In an optical network, for example, it is wholly reasonable to say that preemption of a resource at a particular node breaks the LSP. That is, if I take the laser and use it for something else, then traffic on the old LSP stops flowing. This also probably causes alarms. Depending on the way that this intercepted resource is used, the downstream LSP may need to be torn (to prevent data being sent to the wrong place). If the LSP is bidirectional, the upstream LSP may also need to be torn. There is a facility for both of these options (PathTear and PathErr with state removal). On the other hand in some optical networks, it will be highly desirable to avoid resource churn by leaving the most of the LPS in place and treating the preemption just like an alarm or a resource failure. The ingress (or some other repair point) can use make before break to repair around the error without deprovisioning and reprovisioning at all of the other nodes. Now, in a packet network, we can add to this list the facility for over-provisioniing and handling traffic as best effort. In these cases the most that happens is that the LSP is degraded. The level of this degradation is on a scale from total (as in the optical network) to none, when the traffic on other resource users is low. If there is ever the cahnce of passing traffic, it seems best to do so. This will show less impact for the customer. > In any case, I think a specification is necessary for > soft-preemption. I also believe there is value in allowing the user to > specify whether soft preemption is desired or not on a per-lsp basis I have no issue with this. The change, however, is one of semantics. That is, if you want *hard* preemption to occur at the preempting node (i.e. LSP teardown to begin at the preempting node) this will require a new session attribute. As I hope I made clear, my opinion is that preemption is already soft by default. > and > how long the overbooking may be maintained. This is not an issue for the preempting node to manage on behalf of the ingress. Rather, it is an issue for the ingress to manage for the LSP, and the preempting node to manage on its own behalf. You would be better to have the preempted node report the time for which it will continue to allow over subscription when it reports the preemption. Anyway, nothing I have been shown, RFC2702 notwithstanding, suggests to me other than the current correct behavior of upstream nodes receiving a PathErr reporting preemption is to keep the LSP in place. This is why the state removal flag was introduced to the PathErr. Cheers, Adrian > > 2) The use of rro vs path error > The original proposal for this draft was to use a path-error > message (and allocate a new notify-error subcode), just like you propose. > A few private and public discussions on this topic took place. There are > pros/cons to both approaches, and the authors decided to pick the rro > solution. > > Ina > > On Mon, 19 May 2003, Adrian Farrel wrote: > > > Hi, > > > > I still have a concern about this draft. My understanding of the existing RFCs > > is that the soft-preemption behavior that you want is what is already specified. > > There is, perhaps, an issue that the error code used for preemption is not well > > specified in RFC3209. > > > > I'd appreciate your thoughts. > > Thanks, > > Adrian > > > > ========= > > > > In the Abstract you say > > "Under present RSVP-TE signaling methods, LSPs are immediately displaced upon > > preemption." > > > > and in section 2, Motivation, you have > > "Present MPLS RSVP-TE implementations only support a method of TE LSP > > preemption which immediately tears down TE LSPs, disregarding the > > preempted in-transit traffic, in an effort to make way for a higher > > priority TE LSP if not enough bandwidth is available on the link to > > accommodate the newly signaled high priority TE LSPs. This process > > nearly guarantees preempted traffic will be discarded, if only briefly, > > until the RSVP Path Error message reaches and is processed by the > > head-end (HE) and a new forwarding path can be established." > > > > I disagree with your interpretation of RFC3209. > > > > Section 4.7.3 has > > " When preemption is supported, each preempted reservation triggers a > > TC_Preempt() upcall to local clients, passing a subcode that > > indicates the reason. A ResvErr and/or PathErr with the code "Policy > > Control failure" SHOULD be sent toward the downstream receivers and > > upstream senders." > > > > I'm inclined to agree with what George said in SF: this is a hole in RFC3209. > > If we turn to RFC2205 for a definition of Policy Control Failure we find in > > Appendix B... > > " o Error Code = 02: Policy Control failure > > > > Reservation or path message has been rejected for administrative > > reasons, for example, required credentials not submitted, > > insufficient quota or balance, or administrative preemption. > > This Error Code may appear in a PathErr or ResvErr message. > > > > Contents of the Error Value field are to be determined in the > > future." > > > > Nowhere here do I see anything that says that the LSP is torn down, but rather > > that the traffic becomes best effort (which is what you want in your draft). > > Perhaps the main issue is that nearly all the references to PathErr in RFC3209 > > relate to errors during the LSP setup procedure. But surely PathErr messages > > that happen after the LSP has been established inherit their behavior from > > RFC2205 if there is nothing else described in RFC3209. > > > > Section 3.5 or RFC2205 says > > " There are two RSVP error messages, ResvErr and PathErr. PathErr > > messages are very simple; they are simply sent upstream to the > > sender that created the error, and they do not change path state > > in the nodes though which they pass. There are only a few > > possible causes of path errors." > > > > > > Note that there is already a suitable error code defined in RFC 2205. > > > > " o Error Code = 12: Service preempted > > > > The service request defined by the STYLE object and the flow > > descriptor has been administratively preempted. > > > > For this Error Code, the 16 bits of the Error Value field are: > > ssur cccc cccc cccc > > > > Here the high-order bits ssur are as defined under Error Code > > 01. The globally-defined sub-codes that may appear in the low- > > order 12 bits when ssur = 0000 are to be defined in the future." > > > > This tends to imply that the Error Code is only available for use on a ResvErr > > (since that is where the flow descriptor is). > > > > Alternatively, you could either define a new Error Value for the "Policy Control > > failure" Error Code, or perhaps you would rather move the condition to the > > "Notify" Error Code. For consistency, one might assign the new Error Value > > using the ssur cccc cccc cccc format, setting the u-bit to 1 to show that this > > represents a state update that should be passed onwards, although RFC3209 > > doesn't bother with the u-bit and says > > " For the Notify Error Code, the 16 bits of the Error Value field are: > > ss00 cccc cccc cccc" From owner-mpls@UU.NET Mon May 26 09:51: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 JAA12066 for ; Mon, 26 May 2003 09:51: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 QQoqix16179 for ; Mon, 26 May 2003 13:51: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 QQoqix15516; Mon, 26 May 2003 13:51:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQoqiv28521 for mpls-outgoing; Mon, 26 May 2003 13:20: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 QQoqiv28516 for ; Mon, 26 May 2003 13:20:17 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 QQoqiv27418 for ; Mon, 26 May 2003 13:20: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 QQoqiv24764 for ; Mon, 26 May 2003 13:20: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 QQoqiv24742 for ; Mon, 26 May 2003 13:20: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 h4QDK2FV017374 for ; Mon, 26 May 2003 09:20: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 JAA16215 for ; Mon, 26 May 2003 09:20:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4QDK1E00642 for mpls@uu.net; Mon, 26 May 2003 09:20:01 -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 QQoqiv28218 for ; Mon, 26 May 2003 13:16:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoqiv21585 for ; Mon, 26 May 2003 13:16: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 QQoqiv18183 for ; Mon, 26 May 2003 13:16:11 GMT Received: from xpfonsd by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [195.39.176.3]) id QQoqiv17945 for ; Mon, 26 May 2003 13:16:03 GMT Message-Id: From: Terminate Your DEBT To: Subject: Terminate your unsecured debt qf Date: Mon, 26 May 2003 22:32:38 -0400 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5keHZqcmdham51c25vbWFtZ2hha2l2dm5vdndoZWth aGx4cWRmc3B1bjwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIj4N CjxwPjxhIGhyZWY9Imh0dHA6Ly93d3cubXBsc0B0ZXJtaW5hdGUteW91ci1kZWJ0LmNvbS9k ZWJ0Lz9lPW1wbHNAdXUubmV0Ij48aW1nIHNyYz0iaHR0cDovL21wbHNANjYuMTUxLjU5LjE1 My9vbmxvYWQvNDI1eDUwMF9hZHMuanBnIiBib3JkZXI9MCB3aWR0aD00MjUgaGVpZ2h0PTUw MD48L2E+DQo8cD48YSBocmVmPSJodHRwOi8vd3d3LmR4dmpyZ2FqbnVzbm9tYW1naGFraXZ2 bm92d2hla2FobHhxZGZzcHVuQHRlcm1pbmF0ZS15b3VyLWRlYnQuY29tL3JlLyI+PGltZyBz cmM9Imh0dHA6Ly82Ni4xNTEuNTkuMTUzL29ubG9hZC9yZS5naWYiIGJvcmRlcj0wIHdpZHRo PTIwOSBoZWlnaHQ9MjA+PC9hPg0KPHA+Jm5ic3A7PC9wPg0KPHA+Jm5ic3A7PC9wPg0KPGZv bnQgZmFjZT1WZXJkYW5hIHNpemU9MT5gWWVzLCcgc2FpZCBBcnRodXIsIGB5ZXMgSSBkaWQu IEl0IHdhcyBvbiBkaXNwbGF5IGluIHRoZSBib3R0b20gb2YgYSBsb2NrZWQgZmlsaW5nIGNh YmluZXQgc3R1Y2sgaW4gYSBkaXN1c2VkIGxhdmF0b3J5IHdpdGggYSBzaWduIG9uIHRoZSBk b29yIHNheWluZyAiQmV3YXJlIG9mIFRoZSBMZW9wYXJkIi4nIjwvZm9udD4NCjwvYm9keT4N CjwvaHRtbD4NCg== From owner-mpls@UU.NET Thu May 29 08:07: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 IAA29725 for ; Thu, 29 May 2003 08:07: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 QQoqts27432 for ; Thu, 29 May 2003 12:07: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 QQoqts27365; Thu, 29 May 2003 12:07:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQoqtp07694 for mpls-outgoing; Thu, 29 May 2003 11:24: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 QQoqtp07674 for ; Thu, 29 May 2003 11:23:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoqtp18801 for ; Thu, 29 May 2003 11:23: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 QQoqtp11669 for ; Thu, 29 May 2003 11:23:07 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 QQoqtp11648 for ; Thu, 29 May 2003 11:23:06 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 h4TBN3FV002354 for ; Thu, 29 May 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 HAA17724 for ; Thu, 29 May 2003 07:23:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4TBN2o00203 for mpls@uu.net; Thu, 29 May 2003 07:23: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 QQoqtp07591 for ; Thu, 29 May 2003 11:21:42 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 QQoqtp13784 for ; Thu, 29 May 2003 11:20:19 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 QQoqtp05976 for ; Thu, 29 May 2003 11:20:19 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 QQoqtp05967 for ; Thu, 29 May 2003 11:20: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 HAA26929; Thu, 29 May 2003 07:20:18 -0400 (EDT) Message-Id: <200305291120.HAA26929@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET, te-wg@ops.ietf.org, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt Date: Thu, 29 May 2003 07:20: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 : Multiprotocol Label Switching (MPLS) Management Overview Author(s) : T. Nadeau, C. Srinivasan, A. Farrel Filename : draft-ietf-mpls-mgmt-overview-05.txt Pages : 28 Date : 2003-5-28 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-05.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-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-29072815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-mgmt-overview-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29072815.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 29 09:46: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 JAA03380 for ; Thu, 29 May 2003 09:46: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 QQoqtz16401 for ; Thu, 29 May 2003 13:46: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 QQoqtz16348; Thu, 29 May 2003 13:46:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQoqtx24640 for mpls-outgoing; Thu, 29 May 2003 13:16: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 QQoqtx24635 for ; Thu, 29 May 2003 13:16: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 QQoqtx06810 for ; Thu, 29 May 2003 13:15: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 QQoqtx18289 for ; Thu, 29 May 2003 13:15:33 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 QQoqtx18280 for ; Thu, 29 May 2003 13:15:33 GMT Received: from BLIULAPTOP (unknown [172.16.24.104]) by jera.movaz.com (Postfix) with ESMTP id 954C01483; Thu, 29 May 2003 09:15:32 -0400 (EDT) Message-ID: <028801c325e4$622fb210$681810ac@movaz.com> From: "Adrian Farrel" To: , , References: <200305291120.HAA26929@ietf.org> Subject: Re: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt Date: Thu, 29 May 2003 09:15:32 -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 FYI, Changes are minor nits and synchronization of new (final?) versions of the MIB drafts that have come out. Adrian ----- Original Message ----- From: To: Cc: ; ; Sent: Thursday, May 29, 2003 7:20 AM Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.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 > Filename : draft-ietf-mpls-mgmt-overview-05.txt > Pages : 28 > Date : 2003-5-28 > > 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-05.txt > From owner-mpls@UU.NET Thu May 29 09:48: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 JAA03470 for ; Thu, 29 May 2003 09:48:15 -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 QQoqtz19508 for ; Thu, 29 May 2003 13:48: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 QQoqtz19373; Thu, 29 May 2003 13:48:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQoqtw23639 for mpls-outgoing; Thu, 29 May 2003 13:11: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 QQoqtw23586 for ; Thu, 29 May 2003 13:11:04 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 QQoqtw29536 for ; Thu, 29 May 2003 13:10: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 QQoqtw10761 for ; Thu, 29 May 2003 13:10:53 GMT Received: from mail2.hyperchip.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.hyperchip.com [216.94.112.4]) id QQoqtw10744 for ; Thu, 29 May 2003 13:10:52 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 19LNBE-0000ry-00 for mpls@uu.net; Thu, 29 May 2003 09:10:52 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 May 2003 09:10:17 -0400 Message-ID: <8812A03F65CDD511AE98006008F5E8710677DC7C@hermes.hyperchip.com> From: Philip Matthews To: mpls@UU.NET Subject: Test for hop-limit in draft-ietf-mpls-rsvp-lsp-fastreroute-02 ? Date: Thu, 29 May 2003 09:10:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C325E3.A612A6F0" 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_01C325E3.A612A6F0 Content-Type: text/plain; charset="iso-8859-1" I have a question about the test for hop-limit in the draft-ietf-mpls-rsvp-lsp-fastreroute that I hope one of the authors will answer. The draft states (in section 4.1): Hop-limit The maximum number of extra hops the backup path is allowed to take, from current node (a PLR) to a MP, with PLR and MP excluded in counting. For example, hop-limit of 0 means only direct links between PLR and MP can be considered. The word "extra" in the first sentence leads me to believe that the test is: (number of hops along backup path from PLR to MP) - (number of hops along protected path from PLR to MP) <= hop-limit However, the example in the second sentence seems to indicate that the test is: (number of hops along the backup path from PLR to MP) - 1 <= hop-limit Which test is correct? Also, I would like to note that, according to the text, the limit applies to the "backup path". In the Facility Backup method, I assume that what is really meant is path of the (outer) bypass tunnel, and not the path of the (inner) backup LSP. Note that the path of the latter might be viewed as consisting of just a single hop (depending on how you view tunnel hops). Thanks in advance, - Philip ------_=_NextPart_001_01C325E3.A612A6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Test for hop-limit in draft-ietf-mpls-rsvp-lsp-fastreroute-02 = ?

I have a question about the test for hop-limit = in
the draft-ietf-mpls-rsvp-lsp-fastreroute
that I hope one of the authors will answer.

The draft states (in section 4.1):

       Hop-limit

       The maximum = number of extra hops the backup path is allowed
       to take, from = current node (a PLR) to a MP, with PLR and MP
       excluded in = counting.  For example, hop-limit of 0 means only
       direct links = between PLR and MP can be considered.

The word "extra" in the first sentence = leads me to believe that the test is:
       (number of hops = along backup path from PLR to MP)
          &nb= sp;   - (number of hops along protected path from PLR to = MP)
       <=3D = hop-limit

However, the example in the second sentence seems to = indicate that the
test is:
      (number of hops along = the backup path from PLR to MP) - 1
      <=3D = hop-limit

Which test is correct?

Also, I would like to note that, according to the = text, the limit applies
to the "backup path". In the Facility = Backup method, I assume that what
is really meant is path of the (outer) bypass = tunnel, and not the path
of the (inner) backup LSP. Note that the path of the = latter might be viewed
as consisting of just a single hop (depending on how = you view tunnel hops).

Thanks in advance,

- Philip

------_=_NextPart_001_01C325E3.A612A6F0-- From owner-mpls@UU.NET Thu May 29 17:54: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 RAA22049 for ; Thu, 29 May 2003 17:54:29 -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 QQoqvf28608 for ; Thu, 29 May 2003 21:54: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 QQoqvf28028; Thu, 29 May 2003 21:54:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQoqva08625 for mpls-outgoing; Thu, 29 May 2003 20:39: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 QQoqva08618 for ; Thu, 29 May 2003 20:39:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoqva08466 for ; Thu, 29 May 2003 20:39:03 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 QQoqva25745 for ; Thu, 29 May 2003 20:39:02 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 QQoqva25721 for ; Thu, 29 May 2003 20:39:01 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 h4TKcwXg008572 for ; Thu, 29 May 2003 16:38:58 -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 QAA05113 for ; Thu, 29 May 2003 16:38:58 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4TKcwv28228 for mpls@uu.net; Thu, 29 May 2003 16:38:58 -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 QQoqva08298 for ; Thu, 29 May 2003 20:34: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 QQoqva14300 for ; Thu, 29 May 2003 20:34:00 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 QQoqva11301 for ; Thu, 29 May 2003 20:33:59 GMT Received: from fep03-mail.bloor.is.net.cable.rogers.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) id QQoqva11285 for ; Thu, 29 May 2003 20:33:59 GMT Received: from dune ([24.103.66.219]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030529202637.WYWO6336.fep03-mail.bloor.is.net.cable.rogers.com@dune>; Thu, 29 May 2003 16:26:37 -0400 Message-ID: <010c01c32620$64b50620$2202a8c0@flfrd.phub.net.cable.rogers.com> From: "Martin Dubuc" To: , "Bert Wijnen" Cc: "Sudheer Dharanikota" , "Thomas Nadeau" , Subject: draft-ietf-mpls-telink-mib-02.txt Date: Thu, 29 May 2003 16:25:06 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01C325FE.DD4F79C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.66.219] using ID at Thu, 29 May 2003 16:26:37 -0400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0109_01C325FE.DD4F79C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have submitted a new version of TE link MIB to address Bert's = comments. Here is my response to Bert's comments that outlines that = changes that have been done to the latest version. * * * From: "Wijnen, Bert (Bert)" To: Martin Dubuc , mpls@UU.NET Subject: AD review of: draft-ietf-mpls-telink-mib-01.txt Date: Fri, 9 May 2003 16:35:35 +0200=20 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=3D"iso-8859-1" Lots of good changes have been made. This is what I still find. I have now checked the example in section 7. It does start off with a disclaimer that it does not show all nuances of the MIB module. But ... - When you do a createAndGo, then all row objects that do not have a DEFVAL need to be provided. So the way things are=20 described will cause SNMP errors. If you do not want to list all the details, then at least I'd suggest to make a statement aka: appropriate values for all row objects must be passed for every row createAndGo action. [Martin] I have defined all rows explicitly. - two rows are created with createAndWait.=20 I do not see they ever get activated. Was the assumption that they would get activted automagically, or is this an ommission? [Martin] There is no reason to use createAndWait here. Have fixed it. May I suggest that you make the names of your TCs start with TeLink or some such? This to show that they are basically local TCs.=20 It will avoid potential future name clashes if someone wants to define a Generic TC for a similar (or even same) concept. Suggesteion: Priority -> TeLinkPriority LinkProtection -> TeLinkProtection SwitchingCapability -> TeLinkSwitchingCapability LinkEncodingType -> TeLinkEncodingType This is also recommended in the = draft-ietf-ops-mib-review-guidelines-01.txt [Martin] Done. On page 33, please remove: -- The mandatory groups have to be implemented -- by all devices supporting TE links. However, they may all -- be supported as read-only objects in the case where automatic -- configuration is supported. This is not correct for the FullCompliance. It is OK on page 36 (for the ReadOnlyCompliance). [Martin] Removed. Further comments inline (removed things where I am happy): > -----Original Message----- > From: Martin Dubuc [mailto:m.dubuc@rogers.com] > Sent: woensdag 30 april 2003 20:09 > To: mpls@UU.NET > Subject: RE: I-D ACTION:draft-ietf-mpls-telink-mib-00.txt >=20 >=20 > This is my response to Bert's email which explains how I have=20 > addressed Bert's comments in draft-ietf-mpls-telink-mib-01.txt > that was submitted this morining to IETF. My comments are > embedded in the original mail (prefixed with [Martin]). >=20 > Martin >=20 > * * * >=20 > Here is my review: > - linelegth checker: > $ /bin/checkpage.awk=20 > Long line at 770 with 77 chars > Long line at 771 with 76 chars > Long line at 1268 with 73 chars > -: 3 lines longer than 72 characters, max 77 >=20 > [Martin] Fixed. >=20 Mmm... I still se: $ /bin/checkpage.awk - I have not yet checked sect 7. >=20 See above > - sect 8.1 under ifType you refernece [IanaFamily]. > I think the reference should be to the ianaiftype.mib=20 >=20 > [Martin] You are right. Fixed. >=20 Well... the reference in the reference section is incorrect. Check the link. It should be=20 http://www.iana.org/assignments/ianaiftype-mib instead of: http://www.iana.org/assignments/ianatype-mib [Martin] Fixed. > - for my understanding, the figure in sect 8.2, can you=20 > explain which layers > in the stack are bundle(s), telink or component link. In=20 > fact it might be > good to add that explanantion to the text, so that people=20 > can read it too. >=20 > [Martin] Actually the example is not very clear and your=20 > comment has triggered a flurry of mails between the authors. > We have updated the example to make it easier for readers > to understand. opticalTrans are component links. MUCH MUCH better now. If you added the ifIndex number in the boxes in teh fugures as well, that would improve it even more. and I wonder, if it makes sense to use the same ifIndex numbers in section 7 and then also point to the figure. That allows people to better link between objects and a=20 visual picture of it. Just a thought. [Martin] ifIndex have been added to figure in Section 8.2. Examples in Section 7 and Section 8.2 use the same identifiers. > - May I recommend that=20 > teLinkIpAddrType InetAddressType, > teLinkIpAddr InetAddress, > teLinkRemoteIpAddr InetAddress, > Be renamed to: > teLinkAddressType InetAddressType, > teLinkLocalAddress InetAddress, > teLinkRemoteAddress InetAddress, > First of all, there can be an unnumbered addresstype (unknown), so = then > it is not an IpAddress.=20 > Second, I think that the first address is the local address (that is = on > the device where the instance of the object lives, no?=20 >=20 > Further I wonder.. if it is an unnumbered link, it has an identifier = somehow > does it not. Why would we not put that identifier in the address in = that case > and describe what it looks like. In fact I wonder if instead of the > InetAddress.... TCs would it not be better to use TeHopAddres... TCs = from the > MPLS-TC-MIB? It allows for TeHopAddressUnnum as an address >=20 > In any event, I would not write: > teLinkIpAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "For IPv4 and IPv6 numbered links, this object represents the > IP address type associated with the TE link. For > unnumbered links, a value of unknown(0) must be used." > But rather something aka: > teLinkAddressType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The type of Internet address for the TE link. Only IPv4 and > IPv6 and unknown (for unnumbered links) need to be = supported." > =20 > Then forther in the Address itself I would do something aka (not = that > the first sentence is REQUIRED as per RFC3291): > teLinkLocalAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The local Internet address for the TE link. The type of this=20 > address is determined by the value of the teLinkAddressType > object. For an unnumbered TE link, the address represents an > unnumbered interface in this format: >=20 > octets contents encoding > 1-4 unnumbered interface network-byte order > " > I stole some of the text from MPLS-TC-MIB for now >=20 > [Martin] I have changed the name teLinkIpAddrType to teLinkAddressType = per > your recommendation. However, I have not changed teLinkIpAddr and > teLinkRemoteIpAddr because these fields are really meant to be IP = addresses. > If address type is unnumbered, then these fields should not be used = (the > teLinkIncomingIfId and teLinkOutgoingIfId fields should be used = instead). > It looks like this is not clear enough in the MIB, so > I have added text to clarify this point. >=20 Mmm... I see. So I still would change the definition to something as follows (the 2nd sentence is manadatory according to RFC3291, and it is also important to indicate what the value of this object is (zero length string) in case of unnumberd (i.e. unknown type) link): teLinkLocalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Local Internet Address for numbered links. The type of this address is determined by the value of the teLinkAddressType object.=20 For IPv4 and IPv6 numbered links, this object represents the local IP address associated with the TE link. For an unnumbered link, the local address is of type unknown and this this object=20 is set to the zero length string and the teLinkOutgoingIfId object then identifies the unnumbered 'address'." ::=3D { teLinkEntry 2 } [Martin] Updated accordingly. Have also updated teLinkRemoteIpAddr. > - Would it make sense to elaborate a bit in the DESCRIPTION clause of > teLinkProtectionType and explain what the values exactly mean? > Or if they are explained in that GMPLS-OSPF doc that you=20 > refernce, then at least make that statement. >=20 > [Martin] The values are specified in GMPLS-OSPF, but are actually = described in > GMPLS-ROUTING. I have added this statement (and the new reference). >=20 Mmm... might have better been added to the TC now that you made it a TC. [Martin] It is not a TC. Only used in one place. > - When I see a table like this: > teLinkDescriptorTable > TeLinkDescriptorEntry ::=3D SEQUENCE { > teLinkDescriptorId Unsigned32, > teLinkEncodingType INTEGER, > teLinkDescrPriority Unsigned32, > teLinkMinReservableBandwidth Unsigned32, > teLinkMaxReservableBandwidth Unsigned32, =20 > teLinkDescrRowStatus RowStatus, > teLinkDescrStorageType StorageType > Then I always wonder if we cannot make it easier for people to see = which > objects are indeed in that table. The first object name = teLinkDescriptorId > clealrly is in this table. Then we have one teLinkEncodingType that = is not > so clear. Then we have one that is not as clear as the 1st one, but = still > gives some clue. Then we have 2 that give not clue, then we have 2 = more > that give some clue. How about naming them: > TeLinkDescriptorEntry ::=3D SEQUENCE { > teLinkDescriptorId Unsigned32, > teLinkDescrEncodingType INTEGER, > teLinkDescrPriority Unsigned32, > teLinkDescrMinReservableBandwidth Unsigned32, > teLinkDescrMaxReservableBandwidth Unsigned32, =20 > teLinkDescrRowStatus RowStatus, > teLinkDescrStorageType StorageType > If you can agree with that, then pls check you other tables. The = same=20 > issue/concern comes back in a few other tables. > In fact our mib guidelines document does discuss this issue. >=20 > [Martin] Although it is not obvious why some entries do not have the = same table > prefix, some others have been shortened because of the 32 character = limit > warning for identifiers reported by smilint. I have changed the > identifiers so that they have the same prefix but stayed within > limit of 32 characters. >=20 Mmm... the 32 limit is "recommended", but not a hard limit (that is why = smilint gives a warning and not an error). The hard limit is 64. And we have in = fact=20 relaxed quite a bit over the last year or so on this. Again, this is = clearly described in the mib guidelines document. I would really like the teSrlgTable to have prefixes that start with teSrlg instead of just srlg. That will avoid future possible name=20 conflicts much easier. [Martin] Added 'te' prefixes to srlg rows. > - Your teLinkNotifEnable would be better named:=20 > teLinkNotificationsEnabled >=20 > [Martin] Changed. >=20 Thanks > - I worry about the number of notifications that can get generated per = minute > or per second? Can you say something about it? Do we need an abject = that=20 > lets an NMS configure how many notification an agent can send at = most per > minute? >=20 > [Martin] is only one type of notification in the TE link MIB module. > This notification can only occur if the provider uses bundled link and = will > be generated only when there is a mismatch in a link bundle. Since = link bundles > and TE links are provisioned by users and not on a regular basis, and = since > mismatches are not likely to be common, the number of notifications = should be > extremely small. I do not think there is a need to throttle=20 > these notifications. >=20 If possible, might want to add some text to DESCRIPTION clause. Will = help people understand it better. [Martin] See below. > - linkBundleMismatch > I do not understand the DESCRIPTION clause at all. Specifically, if = an error > is found and the notification is sent, then the 1 second later, the = same=20 > situation probably still exists. Is another notification sent? > Should such a problem not be detected when someone creates an antry = in > a table and should create operation not be prevented from = succeeding? >=20 > [Martin] I expected that the notification would be sent only when the > mismatch was detected. We could prevent a create to succeed if we > detect a mismatch, but it may be easier to just flag the error. > I don't know how others feel about this. >=20 In general it is better to return an error on an SNMP SET when someone tries to do somthing bad instead of letting it pass and generate a notification. Note that the error would go back to the offender, while you have no idea where the notification goes.=20 [Martin] I don't have a strong case for this notification. I agree that it is better to flag the error as it appears. Furthermore, if we keep this notification, we need another one to notify when condition is = cleared. This becomes a bit too involved. For this reason, I have decided to = remove this notification. > I wonder if you do not need ipv4z and/or ipv6z. As long as you = have > evaluated this (with the WG) and decide that you do not need it, = then > fine. >=20 > [Martin] The issue of what to do with ipv4z and ipv6z has not been = raised > by the WG or by the 3 implementations that we know of the MIB. >=20 So maybe the WG SHOULD wonder about this. The question is not so much about if it has already been implemented or not. The question is if Traffic Engineered links can be created over Link Local or Site Local. interfaces/links. (By the way I know that site local is being abandoned by IPv6 WG). [Martin] I have raised this issue on the MPLS mailing list. > - 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." >=20 > 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=20 > notInService may not be needed either. (I am assuming here that I=20 > did understand your intent... which I am not sure of). In that case > something like the following example from RFC3289 would be better: >=20 > OBJECT diffServClfrStatus > SYNTAX RowStatus { active(1) } > WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } > DESCRIPTION > "Support for createAndWait and notInService is not required." >=20 > [Martin] The notInService is required since it is one of the state = that > allows writes (see explanation a few points above). notReady=20 > and createAndWait are not required. For read-only, only active is > required. I have updated text in this respect. >=20 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. > - I have trouble with: > OBJECT teLinkStorageType > SYNTAX INTEGER { other(1) } > DESCRIPTION > "Only other(1) needs to be supported." >=20 > I think I could live with a volatile only, but the 'other' value > is completely unspecified and seems to make no sense to me at all. > What is you intention here? >=20 > [Martin] I picked this from the LSR MIB. I don't think there is a good > reason to limit to one single value. I have removed this conformance > statement. >=20 I hope LSR MIB will remove it too!! > - In security considerations... > - Do All tables have the same considerations? If so you may want > to make that explicit. >=20 > [Martin] Yes, they all have the same considerations. All info in this > MIB module are used for routing purposes. To me, they have the > same sensitivity. Except for IP addresses, which may actually be used > in some sort of attack if known. This is why I have a separate clause > regarding IP addresses. >=20 > - In general, our security ADs probably want some more specificity. > A statement like "all tables ....." sounds as if you are=20 > opting for an easy out. >=20 > [Martin] It may sounds like I am opting for an easy out, but the fact = of > the matter is, all tables have the same considerations. >=20 If you make an EXPLICIT statement that they ALL have the same=20 security considerations, then you show that you have thought about it and have made a conscious decision (or so I think). E.g. something like "All the tables in this MIB module have routing information in them and so they all have the same security attributes." [Martin] Made this explicit. > - On th eread-only objects... are there no issues with bandwith = info? > Or priorities? On protection?=20 > would that not reveal info that people don't want to loose? >=20 > [Martin] The problem here is where you draw the line. Every MIB object > is vulnerable and may reveal info that would be better kept secret. I = have > read the security guidelines thoroughly and my interpretation is that = we > should uncover anything that is sensitive to exposure of end-user > personal information or may lead to potential disruption of service. > There isn't anything in TE link MIB that relates to end-user personal > information. There is potential for disruption of service if someone > changes attributes in any table of the MIB because this affects = routing > (this is my first statement) and there may be disruption of service if = the > IP address are used in some form of spoofing or attack (this is my = second > statement). I don't know that there is much else to say according to = the > spirit of the security guidelines. >=20 I am just trying to help here. I know Security ADs are often picky these days. We'll see what they say when it gets to IESG. You can also send and email to them beforehand and check if they are OK with what you = have. Feel free to copy this discussion. Bert ------=_NextPart_000_0109_01C325FE.DD4F79C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have submitted a new version of TE link MIB to = address=20 Bert's comments. Here is my response to Bert's comments that outlines = that=20 changes that have been done to the latest version.
* * *
 
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: = Martin Dubuc=20 <m.dubuc@rogers.com>, mpls@UU.NET
Subject: AD review of:=20 draft-ietf-mpls-telink-mib-01.txt
Date: Fri, 9 May 2003 16:35:35 = +0200=20
MIME-Version: 1.0
X-Mailer: Internet Mail Service=20 (5.5.2653.19)
Content-Type:=20 text/plain;
 charset=3D"iso-8859-1"
 
Lots of good changes have been made. This is what I = still=20 find.
 
I have now checked the example in section = 7.
 
It does start off with a disclaimer that it does not = show
all nuances of the MIB module. But ...
 
- When you do a createAndGo, then all row objects = that do=20 not
  have a DEFVAL need to be provided. So the way things are=20
  described will cause SNMP errors. If you do not want to=20 list
  all the details, then at least I'd suggest to make a=20 statement
  aka: appropriate values for all row objects must be=20 passed
  for every row createAndGo action.
 
[Martin] I have defined all rows = explicitly.
 
- two rows are created with createAndWait. =
  I do not=20 see they ever get activated. Was the assumption that
  they = would get=20 activted automagically, or is this an ommission?
 
[Martin] There is no reason to use createAndWait = here. Have=20 fixed it.
 
May I suggest that you make the names of your TCs = start with=20 TeLink
or some such? This to show that they are basically local TCs. =
It=20 will avoid potential future name clashes if someone wants to
define a = Generic=20 TC for a similar (or even same) concept.
Suggesteion:
   = Priority           = ; =20 -> TeLinkPriority
  =20 LinkProtection       ->=20 TeLinkProtection
   SwitchingCapability  ->=20 TeLinkSwitchingCapability
  =20 LinkEncodingType     -> = TeLinkEncodingType
This is=20 also recommended in the = draft-ietf-ops-mib-review-guidelines-01.txt
 
[Martin] Done.
 
On page 33, please = remove:
     =20 -- The mandatory groups have to be = implemented
     =20 -- by all devices supporting TE links. However, they may=20 all
      -- be supported as read-only = objects in=20 the case where automatic
      -- = configuration is=20 supported.
This is not correct for the FullCompliance.
It is OK on = page 36=20 (for the ReadOnlyCompliance).
 
[Martin] Removed.
 
Further comments inline (removed things where I am=20 happy):
 
> -----Original Message-----
> From: Martin = Dubuc=20 [mailto:m.dubuc@rogers.com]
> Sent: woensdag 30 april 2003 = 20:09
>=20 To: mpls@UU.NET
> Subject: RE: = I-D=20 ACTION:draft-ietf-mpls-telink-mib-00.txt
>
>
> This = is my=20 response to Bert's email which explains how I have
> addressed = Bert's=20 comments in draft-ietf-mpls-telink-mib-01.txt
> that was submitted = this=20 morining to IETF. My comments are
> embedded in the original mail=20 (prefixed with [Martin]).
>
> Martin
>
> * * = *
>=20
> Here is my review:
> - linelegth=20 checker:
>    $ /bin/checkpage.awk
>=20 <home/ietf/drafts/draft-ietf-mpls-telink-mib-01.txt
>  = ; =20 Long line at 770 with 77 chars
>    Long line at = 771 with=20 76 chars
>    Long line at 1268 with 73=20 chars
>    -: 3 lines longer than 72 characters, = max=20 77
>
> [Martin] Fixed.
>
Mmm... I still se:
$=20 /bin/checkpage.awk <draft-ietf-mpls-telink-mib-01.txt
Long line at = 720=20 with 77 chars
Long line at 721 with 76 chars
Long line at 741 with = 73=20 chars
-: 3 lines longer than 72 characters, max 77
 
[Martin] Fixed.
 
> - I have not yet checked sect 7.
> =
See=20 above
 
> - sect 8.1 under ifType you refernece=20 [IanaFamily].
>   I think the reference should be to the = ianaiftype.mib
>
> [Martin] You are right. Fixed.
>=20
Well... the reference in the reference section is = incorrect.
Check the=20 link. It should be
   http://www.iana.o= rg/assignments/ianaiftype-mib
instead=20 of:
   http://www.iana.org= /assignments/ianatype-mib
 
[Martin] Fixed.
 
> - for my understanding, the figure in sect 8.2, = can you=20
> explain which layers
>   in the stack are = bundle(s),=20 telink or component link. In
> fact it might = be
>   good=20 to add that explanantion to the text, so that people
> can read = it=20 too.
>
> [Martin] Actually the example is not very clear = and your=20
> comment has triggered a flurry of mails between the = authors.
> We=20 have updated the example to make it easier for readers
> to = understand.=20 opticalTrans are component links.
 
MUCH MUCH better now. If you added the ifIndex = number in=20 the
boxes in teh fugures as well, that would improve it even = more.
and I=20 wonder, if it makes sense to use the same ifIndex
numbers in section = 7 and=20 then also point to the figure.
That allows people to better link = between=20 objects and a
visual picture of it. Just a thought.
 
[Martin] ifIndex have been added to figure in = Section=20 8.2.
Examples in Section 7 and Section 8.2 use the same=20 identifiers.
 
> - May I recommend that=20
>     =20 teLinkIpAddrType         &nb= sp;  =20 InetAddressType,
>     =20 teLinkIpAddr          &= nbsp;     =20 InetAddress,
>     =20 teLinkRemoteIpAddr         &= nbsp;=20 InetAddress,
>   Be renamed=20 to:
>     =20 teLinkAddressType         &n= bsp;  =20 InetAddressType,
>     =20 teLinkLocalAddress         &= nbsp; =20 InetAddress,
>     =20 teLinkRemoteAddress         =  =20 InetAddress,
>   First of all, there can be an = unnumbered=20 addresstype (unknown), so then
>   it is not an = IpAddress.=20
>   Second, I think that the first address is the local = address=20 (that is on
>   the device where the instance of the = object=20 lives, no?
>
>   Further I wonder.. if it is an=20 unnumbered link, it has an identifier somehow
>   does = it not.=20 Why would we not put that identifier in the address in that=20 case
>   and describe what it looks like. In fact I = wonder if=20 instead of  the
>   InetAddress.... TCs would it = not be=20 better to use TeHopAddres... TCs from the
>   = MPLS-TC-MIB? It=20 allows for TeHopAddressUnnum as an address
>
>   = In any=20 event, I would not write:
>     = teLinkIpAddrType=20 OBJECT-TYPE
>      =20 SYNTAX       =20 InetAddressType
>      =20 MAX-ACCESS   =20 read-create
>      =20 STATUS       =20 current
>      =20 DESCRIPTION
>         "For = IPv4=20 and IPv6 numbered links, this object represents=20 the
>          IP = address=20 type associated with the TE link.=20 For
>          = unnumbered=20 links, a value of unknown(0) must be used."
>   But = rather=20 something aka:
>     teLinkAddressType=20 OBJECT-TYPE
>      =20 SYNTAX       =20 InetAddressType
>      =20 MAX-ACCESS   =20 read-create
>      =20 STATUS       =20 current
>      =20 DESCRIPTION
>         "The = type of=20 Internet address for the TE link. Only IPv4=20 and
>          IPv6 = and=20 unknown (for unnumbered links) need to be = supported."
>  =20
>   Then forther in the Address itself I would do = something aka=20 (not that
>   the first sentence is REQUIRED as per=20 RFC3291):
>     teLinkLocalAddress=20 OBJECT-TYPE
>      =20 SYNTAX       =20 InetAddress
>      =20 MAX-ACCESS   =20 read-create
>      =20 STATUS       =20 current
>      =20 DESCRIPTION
>         "The = local=20 Internet address for the TE link. The type of this=20
>          address = is=20 determined by the value of the=20 teLinkAddressType
>        =  =20 object. For an unnumbered TE link, the address represents=20 an
>          = unnumbered=20 interface in this format:
>=20
>           = ;   =20 octets  =20 contents           = ;   =20 encoding
>         &nb= sp;    =20 1-4      unnumbered interface   = network-byte=20 order
>        =20 "
>   I stole some of the text from MPLS-TC-MIB for = now
>=20
> [Martin] I have changed the name teLinkIpAddrType to = teLinkAddressType=20 per
> your recommendation. However, I have not changed = teLinkIpAddr=20 and
> teLinkRemoteIpAddr because these fields are really meant to = be IP=20 addresses.
> If address type is unnumbered, then these fields = should not=20 be used (the
> teLinkIncomingIfId and teLinkOutgoingIfId fields = should be=20 used instead).
> It looks like this is not clear enough in the = MIB,=20 so
> I have added text to clarify this point.
>
Mmm... I = see. So=20 I still would change the definition to something
as follows (the 2nd = sentence=20 is manadatory according to RFC3291,
and it is also important to = indicate what=20 the value of this object is
(zero length string) in case of unnumberd = (i.e.=20 unknown type) link):
 
teLinkLocalIpAddr OBJECT-TYPE
  =20 SYNTAX        = InetAddress
  =20 MAX-ACCESS    read-create
  =20 STATUS        current
   = DESCRIPTION
       "The Local Internet = Address=20 for numbered links. The type of=20 this
        address is determined = by the=20 value of the = teLinkAddressType
       =20 object.
 
        For IPv4 = and IPv6=20 numbered links, this object represents=20 the
        local IP address = associated=20 with the TE link. For an=20 unnumbered
        link, the local = address=20 is of type unknown and this this object=20
        is set to the zero length = string=20 and the teLinkOutgoingIfId
        = object=20 then identifies the unnumbered 'address'."
   ::=3D { = teLinkEntry 2=20 }
 
[Martin] Updated accordingly. Have also updated=20 teLinkRemoteIpAddr.
 
> - Would it make sense to elaborate a bit in the = DESCRIPTION clause of
>   teLinkProtectionType and = explain what=20 the values exactly mean?
>   Or if they are explained in = that=20 GMPLS-OSPF doc that you
>   refernce, then at least = make that=20 statement.
>
> [Martin] The values are specified in = GMPLS-OSPF, but=20 are actually described in
> GMPLS-ROUTING. I have added this = statement=20 (and the new reference).
>
Mmm... might have better been added = to the=20 TC now that you made it a TC.
 
[Martin] It is not a TC. Only used in one = place.
 
> - When I see a table like = this:
>   =20 teLinkDescriptorTable
>    TeLinkDescriptorEntry = ::=3D=20 SEQUENCE {
>      =20 teLinkDescriptorId         &= nbsp;=20 Unsigned32,
>      =20 teLinkEncodingType         &= nbsp;=20 INTEGER,
>      =20 teLinkDescrPriority         = =20 Unsigned32,
>      =20 teLinkMinReservableBandwidth=20 Unsigned32,
>      =20 teLinkMaxReservableBandwidth Unsigned32,  =20
>      =20 teLinkDescrRowStatus        =20 RowStatus,
>      =20 teLinkDescrStorageType      =20 StorageType
>   Then I always wonder if we cannot make = it easier=20 for people to see which
>   objects are indeed in that = table.=20 The first object name teLinkDescriptorId
>   clealrly is = in this=20 table. Then we have one teLinkEncodingType that is = not
>   so=20 clear. Then we have one that is not as clear as the 1st one, but=20 still
>   gives some clue. Then we have 2 that give not = clue,=20 then we have 2 more
>   that give some clue. How about = naming=20 them:
>    TeLinkDescriptorEntry ::=3D SEQUENCE=20 {
>      =20 teLinkDescriptorId         &= nbsp;     =20 Unsigned32,
>      =20 teLinkDescrEncodingType        &n= bsp; =20 INTEGER,
>      =20 teLinkDescrPriority         =      =20 Unsigned32,
>      =20 teLinkDescrMinReservableBandwidth=20 Unsigned32,
>      =20 teLinkDescrMaxReservableBandwidth Unsigned32,  =20
>      =20 teLinkDescrRowStatus         = ;    =20 RowStatus,
>      =20 teLinkDescrStorageType        &nb= sp;  =20 StorageType
>   If you can agree with that, then pls = check you=20 other tables. The same
>   issue/concern comes back in = a few=20 other tables.
>   In fact our mib guidelines document = does=20 discuss this issue.
>
> [Martin] Although it is not obvious = why=20 some entries do not have the same table
> prefix, some others have = been=20 shortened because of the 32 character limit
> warning for = identifiers=20 reported by smilint. I have changed the
> identifiers so that they = have=20 the same prefix but stayed within
> limit of 32 = characters.
>=20
Mmm... the 32 limit is "recommended", but not a hard limit (that is = why=20 smilint
gives a warning and not an error). The hard limit is 64. And = we have=20 in fact
relaxed quite a bit over the last year or so on this. Again, = this is=20 clearly
described in the mib guidelines document.
 
I would really like the teSrlgTable to have prefixes = that=20 start with
teSrlg instead of just srlg. That will avoid future = possible name=20
conflicts much easier.
 
[Martin] Added 'te' prefixes to srlg = rows.
 
> - Your teLinkNotifEnable would be better named: =
>=20 teLinkNotificationsEnabled
>
> [Martin] Changed.
>=20
Thanks
 
> - I worry about the number of notifications = that can get=20 generated per minute
>   or per second? Can you say = something=20 about it? Do we need an abject that
>   lets an NMS = configure=20 how many notification an agent can send at most per
>  =20 minute?
>
> [Martin] is only one type of notification in = the TE=20 link MIB module.
> This notification can only occur if the = provider uses=20 bundled link and will
> be generated only when there is a mismatch = in a=20 link bundle. Since link bundles
> and TE links are provisioned by = users=20 and not on a regular basis, and since
> mismatches are not likely = to be=20 common, the number of notifications should be
> extremely small. I = do not=20 think there is a need to throttle
> these notifications.
> =
If=20 possible, might want to add some text to DESCRIPTION clause. Will = help
people=20 understand it better.
 
[Martin] See below.
 
> - linkBundleMismatch
>   I do = not=20 understand the DESCRIPTION clause at all. Specifically, if an=20 error
>   is found and the notification is sent, then = the 1=20 second later, the same
>   situation probably still = exists. Is=20 another notification sent?
>   Should such a problem not = be=20 detected when someone creates an antry in
>   a table = and should=20 create operation not be prevented from succeeding?
>
> = [Martin] I=20 expected that the notification would be sent only when the
> = mismatch was=20 detected. We could prevent a create to succeed if we
> detect a = mismatch,=20 but it may be easier to just flag the error.
> I don't know how = others=20 feel about this.
>
In general it is better to return an error = on an=20 SNMP SET when someone
tries to do somthing bad instead of letting it = pass and=20 generate a
notification. Note that the error would go back to the = offender,=20 while
you have no idea where the notification goes.
 
[Martin] I don't have a strong case for this = notification. I=20 agree that
it is better to flag the error as it appears. Furthermore, = if we=20 keep
this notification, we need another one to notify when condition = is=20 cleared.
This becomes a bit too involved. For this reason, I have = decided to=20 remove
this notification.
 
>    I wonder if you do not need = ipv4z=20 and/or ipv6z.  As long as you have
>    = evaluated this=20 (with the WG) and decide that you do not need it, = then
>   =20 fine.
>
> [Martin] The issue of what to do with ipv4z and = ipv6z has=20 not been raised
> by the WG or by the 3 implementations that we = know of=20 the MIB.
>
So maybe the WG SHOULD wonder about this. The = question is=20 not so much
about if it has already been implemented or not. The = question is=20 if
Traffic Engineered links can be created over Link Local or Site=20 Local.
interfaces/links. (By the way I know that site local is=20 being
abandoned by IPv6 WG).
 
[Martin] I have raised this issue on the MPLS = mailing=20 list.
 
> - I have trouble=20 with:
>      =20 OBJECT     =20 teLinkRowStatus
>      =20 SYNTAX      INTEGER { active(1),=20 notInService(2),
>        &= nbsp;           &n= bsp;       =20 createAndGo(4), destroy(6) }
>       = DESCRIPTION
>         =  =20 "The notReady(3) state need not be supported."
> =
>   I=20 think what you want to specify is that createAndWait is not=20 needed.
>   Since you allow all objects to be changed in = 'active' mode, the
>   notInService may not be needed = either.=20 (I am assuming here that I
>   did understand your = intent...=20 which I am not sure of). In that case
>   something like = the=20 following example from RFC3289 would be better:
>=20
>     OBJECT=20 diffServClfrStatus
>     SYNTAX RowStatus { = active(1)=20 }
>     WRITE-SYNTAX RowStatus { = createAndGo(4),=20 destroy(6) }
>    =20 DESCRIPTION
>        "Support = for=20 createAndWait and notInService is not required."
>
> = [Martin] The=20 notInService is required since it is one of the state that
> = allows writes=20 (see explanation a few points above). notReady
> and = createAndWait are=20 not required. For read-only, only active is
> required. I have = updated=20 text in this respect.
>
Mmm... in the example in section 7, = you DO=20 show that you would do a
createAndWait for the teLinkTable, don't = you?
So=20 this COMPLIANCE statement seems to be in conflict with that.
So pls = decide=20 what it is or should be and then we need to
make a proper = specification that=20 is in sync with that.
 
It seems to me, that for your teLinkRowStatus in the = rev 01=20 document
(assuming you do want createAndWait as per section 7) that=20 the
statement on teLinkRowStatus should be removed.
If indeed you = do not=20 want/need createAndWait (but then sect 7 needs
an update), then it = could be=20 changed to:
 
     = OBJECT     =20 teLinkRowStatus
     = SYNTAX     =20 INTEGER { active(1), notInService(2) }
     = WRITE-SYNTAX=20 RowStatus { notInService(2),=20 createAndGo(4),
         =             &= nbsp;       =20 destroy(6) }
    =20 DESCRIPTION
         "The = notReady(3)=20 and createAndWait(5) states=20 need
          not be=20 supported."
 
[Martin] No createAndWait is required. See = above.
 
> - I have trouble=20 with:
>      =20 OBJECT     =20 teLinkStorageType
>      =20 SYNTAX      INTEGER { other(1)=20 }
>      =20 DESCRIPTION
>         =  =20 "Only other(1) needs to be supported."
>
>   I = think I=20 could live with a volatile only, but the 'other' = value
>   is=20 completely unspecified and seems to make no sense to me at=20 all.
>   What is you intention here?
>
> = [Martin] I=20 picked this from the LSR MIB. I don't think there is a good
> = reason to=20 limit to one single value. I have removed this conformance
>=20 statement.
>
I hope LSR MIB will remove it too!!
 
> - In security = considerations...
>   - Do=20 All tables have the same considerations? If so you may=20 want
>     to make that explicit.
> =
>=20 [Martin] Yes, they all have the same considerations. All info in = this
>=20 MIB module are used for routing purposes. To me, they have the
> = same=20 sensitivity. Except for IP addresses, which may actually be used
> = in some=20 sort of attack if known. This is why I have a separate clause
> = regarding=20 IP addresses.
>
>   - In general, our security = ADs=20 probably want some more specificity.
>     A = statement=20 like "all tables ....." sounds as if you are =
>    =20 opting for an easy out.
>
> [Martin] It may sounds like I = am opting=20 for an easy out, but the fact of
> the matter is, all tables have = the same=20 considerations.
>
If you make an EXPLICIT statement that they = ALL have=20 the same
security considerations, then you show that you have = thought=20 about
it and have made a conscious decision (or so I think). E.g.=20 something
like "All the tables in this MIB module have routing = information=20 in
them and so they all have the same security = attributes."
 
[Martin] Made this explicit.
 
>   - On th eread-only objects... are = there no=20 issues with bandwith info?
>     Or = priorities? On=20 protection?
>     would that not reveal info = that=20 people don't want to loose?
>
> [Martin] The problem here = is where=20 you draw the line. Every MIB object
> is vulnerable and may reveal = info=20 that would be better kept secret. I have
> read the security = guidelines=20 thoroughly and my interpretation is that we
> should uncover = anything that=20 is sensitive to exposure of end-user
> personal information or may = lead to=20 potential disruption of service.
> There isn't anything in TE link = MIB=20 that relates to end-user personal
> information. There is = potential for=20 disruption of service if someone
> changes attributes in any table = of the=20 MIB because this affects routing
> (this is my first statement) = and there=20 may be disruption of service if the
> IP address are used in some = form of=20 spoofing or attack (this is my second
> statement). I don't know = that=20 there is much else to say according to the
> spirit of the = security=20 guidelines.
>
I am just trying to help here. I know Security = ADs are=20 often picky these
days. We'll see what they say when it gets to IESG. = You can=20 also send
and email to them beforehand and check if they are OK with = what you=20 have.
Feel free to copy this discussion.
 
Bert
------=_NextPart_000_0109_01C325FE.DD4F79C0-- From owner-mpls@UU.NET Fri May 30 15: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 PAA25041 for ; Fri, 30 May 2003 15: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 QQoqyp03945 for ; Fri, 30 May 2003 19:51: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 QQoqyp03145; Fri, 30 May 2003 19:50:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQoqxv20529 for mpls-outgoing; Fri, 30 May 2003 14:46: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 QQoqxv20457 for ; Fri, 30 May 2003 14:46:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoqxv17121 for ; Fri, 30 May 2003 14:46: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 QQoqxv22735 for ; Fri, 30 May 2003 14:46:22 GMT Received: from ns.ft.solteria.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.ft.solteria.net [210.142.173.164]) id QQoqxv22195 for ; Fri, 30 May 2003 14:46:06 GMT Received: from SATORUVAIO.hikami.net (localhost [127.0.0.1]) by ns.ft.solteria.net (Postfix) with ESMTP id C8DC238712 for ; Fri, 30 May 2003 23:46:00 +0900 (JST) Message-Id: <4.3.2-J.20030530234455.03f91640@localhost> X-Sender: satoru@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Fri, 30 May 2003 23:45:10 +0900 To: mpls@UU.NET From: Satoru Subject: Short comment for draft-ietf-mpls-lsp-ping-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, One comment. From section "5.3. Procedures at the ingress LSR" described following: > If X does not receive an Resv message from the egress LSR that > contains an LSP_ECHO object within some period of time, it declares > the LSP as "down". At this point, the ingress LSR may apply the > necessary procedures to fix the LSP. These may include generating a > message to network management, tearing-down and re-building the LSP, > and/or rerouting user traffic to a backup LSP. I agree that rebuilding LSP and rerouting to other or backup LSP when primary LSP was defected. But I think that the ingress LSR should not tearing-down defected LSP because localizing point of failure will be difficult. -- Satoru Matsushima, Japan Telecom From owner-mpls@UU.NET Fri May 30 17:30:30 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 RAA29276 for ; Fri, 30 May 2003 17:30:29 -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 QQoqyw07870 for ; Fri, 30 May 2003 21:30:30 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 QQoqyw07379; Fri, 30 May 2003 21:30:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQoqxw03034 for mpls-outgoing; Fri, 30 May 2003 15:02: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 QQoqxw02652 for ; Fri, 30 May 2003 15:02:34 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 QQoqxw26135 for ; Fri, 30 May 2003 15:02:04 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 QQoqxw16581 for ; Fri, 30 May 2003 15:02:03 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 QQoqxw16558 for ; Fri, 30 May 2003 15:02:02 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 h4UF1xXg021862 for ; Fri, 30 May 2003 11:01:59 -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 LAA08046 for ; Fri, 30 May 2003 11:01:59 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4UF1wH18779 for mpls@uu.net; Fri, 30 May 2003 11:01:58 -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 QQoqva08298 for ; Thu, 29 May 2003 20:34: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 QQoqva14300 for ; Thu, 29 May 2003 20:34:00 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 QQoqva11301 for ; Thu, 29 May 2003 20:33:59 GMT Received: from fep03-mail.bloor.is.net.cable.rogers.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) id QQoqva11285 for ; Thu, 29 May 2003 20:33:59 GMT Received: from dune ([24.103.66.219]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030529202637.WYWO6336.fep03-mail.bloor.is.net.cable.rogers.com@dune>; Thu, 29 May 2003 16:26:37 -0400 Message-ID: <010c01c32620$64b50620$2202a8c0@flfrd.phub.net.cable.rogers.com> From: "Martin Dubuc" To: , "Bert Wijnen" Cc: "Sudheer Dharanikota" , "Thomas Nadeau" , Subject: draft-ietf-mpls-telink-mib-02.txt Date: Thu, 29 May 2003 16:25:06 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01C325FE.DD4F79C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.66.219] using ID at Thu, 29 May 2003 16:26:37 -0400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0109_01C325FE.DD4F79C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have submitted a new version of TE link MIB to address Bert's = comments. Here is my response to Bert's comments that outlines that = changes that have been done to the latest version. * * * From: "Wijnen, Bert (Bert)" To: Martin Dubuc , mpls@UU.NET Subject: AD review of: draft-ietf-mpls-telink-mib-01.txt Date: Fri, 9 May 2003 16:35:35 +0200=20 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=3D"iso-8859-1" Lots of good changes have been made. This is what I still find. I have now checked the example in section 7. It does start off with a disclaimer that it does not show all nuances of the MIB module. But ... - When you do a createAndGo, then all row objects that do not have a DEFVAL need to be provided. So the way things are=20 described will cause SNMP errors. If you do not want to list all the details, then at least I'd suggest to make a statement aka: appropriate values for all row objects must be passed for every row createAndGo action. [Martin] I have defined all rows explicitly. - two rows are created with createAndWait.=20 I do not see they ever get activated. Was the assumption that they would get activted automagically, or is this an ommission? [Martin] There is no reason to use createAndWait here. Have fixed it. May I suggest that you make the names of your TCs start with TeLink or some such? This to show that they are basically local TCs.=20 It will avoid potential future name clashes if someone wants to define a Generic TC for a similar (or even same) concept. Suggesteion: Priority -> TeLinkPriority LinkProtection -> TeLinkProtection SwitchingCapability -> TeLinkSwitchingCapability LinkEncodingType -> TeLinkEncodingType This is also recommended in the = draft-ietf-ops-mib-review-guidelines-01.txt [Martin] Done. On page 33, please remove: -- The mandatory groups have to be implemented -- by all devices supporting TE links. However, they may all -- be supported as read-only objects in the case where automatic -- configuration is supported. This is not correct for the FullCompliance. It is OK on page 36 (for the ReadOnlyCompliance). [Martin] Removed. Further comments inline (removed things where I am happy): > -----Original Message----- > From: Martin Dubuc [mailto:m.dubuc@rogers.com] > Sent: woensdag 30 april 2003 20:09 > To: mpls@UU.NET > Subject: RE: I-D ACTION:draft-ietf-mpls-telink-mib-00.txt >=20 >=20 > This is my response to Bert's email which explains how I have=20 > addressed Bert's comments in draft-ietf-mpls-telink-mib-01.txt > that was submitted this morining to IETF. My comments are > embedded in the original mail (prefixed with [Martin]). >=20 > Martin >=20 > * * * >=20 > Here is my review: > - linelegth checker: > $ /bin/checkpage.awk=20 > Long line at 770 with 77 chars > Long line at 771 with 76 chars > Long line at 1268 with 73 chars > -: 3 lines longer than 72 characters, max 77 >=20 > [Martin] Fixed. >=20 Mmm... I still se: $ /bin/checkpage.awk - I have not yet checked sect 7. >=20 See above > - sect 8.1 under ifType you refernece [IanaFamily]. > I think the reference should be to the ianaiftype.mib=20 >=20 > [Martin] You are right. Fixed. >=20 Well... the reference in the reference section is incorrect. Check the link. It should be=20 http://www.iana.org/assignments/ianaiftype-mib instead of: http://www.iana.org/assignments/ianatype-mib [Martin] Fixed. > - for my understanding, the figure in sect 8.2, can you=20 > explain which layers > in the stack are bundle(s), telink or component link. In=20 > fact it might be > good to add that explanantion to the text, so that people=20 > can read it too. >=20 > [Martin] Actually the example is not very clear and your=20 > comment has triggered a flurry of mails between the authors. > We have updated the example to make it easier for readers > to understand. opticalTrans are component links. MUCH MUCH better now. If you added the ifIndex number in the boxes in teh fugures as well, that would improve it even more. and I wonder, if it makes sense to use the same ifIndex numbers in section 7 and then also point to the figure. That allows people to better link between objects and a=20 visual picture of it. Just a thought. [Martin] ifIndex have been added to figure in Section 8.2. Examples in Section 7 and Section 8.2 use the same identifiers. > - May I recommend that=20 > teLinkIpAddrType InetAddressType, > teLinkIpAddr InetAddress, > teLinkRemoteIpAddr InetAddress, > Be renamed to: > teLinkAddressType InetAddressType, > teLinkLocalAddress InetAddress, > teLinkRemoteAddress InetAddress, > First of all, there can be an unnumbered addresstype (unknown), so = then > it is not an IpAddress.=20 > Second, I think that the first address is the local address (that is = on > the device where the instance of the object lives, no?=20 >=20 > Further I wonder.. if it is an unnumbered link, it has an identifier = somehow > does it not. Why would we not put that identifier in the address in = that case > and describe what it looks like. In fact I wonder if instead of the > InetAddress.... TCs would it not be better to use TeHopAddres... TCs = from the > MPLS-TC-MIB? It allows for TeHopAddressUnnum as an address >=20 > In any event, I would not write: > teLinkIpAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "For IPv4 and IPv6 numbered links, this object represents the > IP address type associated with the TE link. For > unnumbered links, a value of unknown(0) must be used." > But rather something aka: > teLinkAddressType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The type of Internet address for the TE link. Only IPv4 and > IPv6 and unknown (for unnumbered links) need to be = supported." > =20 > Then forther in the Address itself I would do something aka (not = that > the first sentence is REQUIRED as per RFC3291): > teLinkLocalAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The local Internet address for the TE link. The type of this=20 > address is determined by the value of the teLinkAddressType > object. For an unnumbered TE link, the address represents an > unnumbered interface in this format: >=20 > octets contents encoding > 1-4 unnumbered interface network-byte order > " > I stole some of the text from MPLS-TC-MIB for now >=20 > [Martin] I have changed the name teLinkIpAddrType to teLinkAddressType = per > your recommendation. However, I have not changed teLinkIpAddr and > teLinkRemoteIpAddr because these fields are really meant to be IP = addresses. > If address type is unnumbered, then these fields should not be used = (the > teLinkIncomingIfId and teLinkOutgoingIfId fields should be used = instead). > It looks like this is not clear enough in the MIB, so > I have added text to clarify this point. >=20 Mmm... I see. So I still would change the definition to something as follows (the 2nd sentence is manadatory according to RFC3291, and it is also important to indicate what the value of this object is (zero length string) in case of unnumberd (i.e. unknown type) link): teLinkLocalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Local Internet Address for numbered links. The type of this address is determined by the value of the teLinkAddressType object.=20 For IPv4 and IPv6 numbered links, this object represents the local IP address associated with the TE link. For an unnumbered link, the local address is of type unknown and this this object=20 is set to the zero length string and the teLinkOutgoingIfId object then identifies the unnumbered 'address'." ::=3D { teLinkEntry 2 } [Martin] Updated accordingly. Have also updated teLinkRemoteIpAddr. > - Would it make sense to elaborate a bit in the DESCRIPTION clause of > teLinkProtectionType and explain what the values exactly mean? > Or if they are explained in that GMPLS-OSPF doc that you=20 > refernce, then at least make that statement. >=20 > [Martin] The values are specified in GMPLS-OSPF, but are actually = described in > GMPLS-ROUTING. I have added this statement (and the new reference). >=20 Mmm... might have better been added to the TC now that you made it a TC. [Martin] It is not a TC. Only used in one place. > - When I see a table like this: > teLinkDescriptorTable > TeLinkDescriptorEntry ::=3D SEQUENCE { > teLinkDescriptorId Unsigned32, > teLinkEncodingType INTEGER, > teLinkDescrPriority Unsigned32, > teLinkMinReservableBandwidth Unsigned32, > teLinkMaxReservableBandwidth Unsigned32, =20 > teLinkDescrRowStatus RowStatus, > teLinkDescrStorageType StorageType > Then I always wonder if we cannot make it easier for people to see = which > objects are indeed in that table. The first object name = teLinkDescriptorId > clealrly is in this table. Then we have one teLinkEncodingType that = is not > so clear. Then we have one that is not as clear as the 1st one, but = still > gives some clue. Then we have 2 that give not clue, then we have 2 = more > that give some clue. How about naming them: > TeLinkDescriptorEntry ::=3D SEQUENCE { > teLinkDescriptorId Unsigned32, > teLinkDescrEncodingType INTEGER, > teLinkDescrPriority Unsigned32, > teLinkDescrMinReservableBandwidth Unsigned32, > teLinkDescrMaxReservableBandwidth Unsigned32, =20 > teLinkDescrRowStatus RowStatus, > teLinkDescrStorageType StorageType > If you can agree with that, then pls check you other tables. The = same=20 > issue/concern comes back in a few other tables. > In fact our mib guidelines document does discuss this issue. >=20 > [Martin] Although it is not obvious why some entries do not have the = same table > prefix, some others have been shortened because of the 32 character = limit > warning for identifiers reported by smilint. I have changed the > identifiers so that they have the same prefix but stayed within > limit of 32 characters. >=20 Mmm... the 32 limit is "recommended", but not a hard limit (that is why = smilint gives a warning and not an error). The hard limit is 64. And we have in = fact=20 relaxed quite a bit over the last year or so on this. Again, this is = clearly described in the mib guidelines document. I would really like the teSrlgTable to have prefixes that start with teSrlg instead of just srlg. That will avoid future possible name=20 conflicts much easier. [Martin] Added 'te' prefixes to srlg rows. > - Your teLinkNotifEnable would be better named:=20 > teLinkNotificationsEnabled >=20 > [Martin] Changed. >=20 Thanks > - I worry about the number of notifications that can get generated per = minute > or per second? Can you say something about it? Do we need an abject = that=20 > lets an NMS configure how many notification an agent can send at = most per > minute? >=20 > [Martin] is only one type of notification in the TE link MIB module. > This notification can only occur if the provider uses bundled link and = will > be generated only when there is a mismatch in a link bundle. Since = link bundles > and TE links are provisioned by users and not on a regular basis, and = since > mismatches are not likely to be common, the number of notifications = should be > extremely small. I do not think there is a need to throttle=20 > these notifications. >=20 If possible, might want to add some text to DESCRIPTION clause. Will = help people understand it better. [Martin] See below. > - linkBundleMismatch > I do not understand the DESCRIPTION clause at all. Specifically, if = an error > is found and the notification is sent, then the 1 second later, the = same=20 > situation probably still exists. Is another notification sent? > Should such a problem not be detected when someone creates an antry = in > a table and should create operation not be prevented from = succeeding? >=20 > [Martin] I expected that the notification would be sent only when the > mismatch was detected. We could prevent a create to succeed if we > detect a mismatch, but it may be easier to just flag the error. > I don't know how others feel about this. >=20 In general it is better to return an error on an SNMP SET when someone tries to do somthing bad instead of letting it pass and generate a notification. Note that the error would go back to the offender, while you have no idea where the notification goes.=20 [Martin] I don't have a strong case for this notification. I agree that it is better to flag the error as it appears. Furthermore, if we keep this notification, we need another one to notify when condition is = cleared. This becomes a bit too involved. For this reason, I have decided to = remove this notification. > I wonder if you do not need ipv4z and/or ipv6z. As long as you = have > evaluated this (with the WG) and decide that you do not need it, = then > fine. >=20 > [Martin] The issue of what to do with ipv4z and ipv6z has not been = raised > by the WG or by the 3 implementations that we know of the MIB. >=20 So maybe the WG SHOULD wonder about this. The question is not so much about if it has already been implemented or not. The question is if Traffic Engineered links can be created over Link Local or Site Local. interfaces/links. (By the way I know that site local is being abandoned by IPv6 WG). [Martin] I have raised this issue on the MPLS mailing list. > - 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." >=20 > 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=20 > notInService may not be needed either. (I am assuming here that I=20 > did understand your intent... which I am not sure of). In that case > something like the following example from RFC3289 would be better: >=20 > OBJECT diffServClfrStatus > SYNTAX RowStatus { active(1) } > WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } > DESCRIPTION > "Support for createAndWait and notInService is not required." >=20 > [Martin] The notInService is required since it is one of the state = that > allows writes (see explanation a few points above). notReady=20 > and createAndWait are not required. For read-only, only active is > required. I have updated text in this respect. >=20 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. > - I have trouble with: > OBJECT teLinkStorageType > SYNTAX INTEGER { other(1) } > DESCRIPTION > "Only other(1) needs to be supported." >=20 > I think I could live with a volatile only, but the 'other' value > is completely unspecified and seems to make no sense to me at all. > What is you intention here? >=20 > [Martin] I picked this from the LSR MIB. I don't think there is a good > reason to limit to one single value. I have removed this conformance > statement. >=20 I hope LSR MIB will remove it too!! > - In security considerations... > - Do All tables have the same considerations? If so you may want > to make that explicit. >=20 > [Martin] Yes, they all have the same considerations. All info in this > MIB module are used for routing purposes. To me, they have the > same sensitivity. Except for IP addresses, which may actually be used > in some sort of attack if known. This is why I have a separate clause > regarding IP addresses. >=20 > - In general, our security ADs probably want some more specificity. > A statement like "all tables ....." sounds as if you are=20 > opting for an easy out. >=20 > [Martin] It may sounds like I am opting for an easy out, but the fact = of > the matter is, all tables have the same considerations. >=20 If you make an EXPLICIT statement that they ALL have the same=20 security considerations, then you show that you have thought about it and have made a conscious decision (or so I think). E.g. something like "All the tables in this MIB module have routing information in them and so they all have the same security attributes." [Martin] Made this explicit. > - On th eread-only objects... are there no issues with bandwith = info? > Or priorities? On protection?=20 > would that not reveal info that people don't want to loose? >=20 > [Martin] The problem here is where you draw the line. Every MIB object > is vulnerable and may reveal info that would be better kept secret. I = have > read the security guidelines thoroughly and my interpretation is that = we > should uncover anything that is sensitive to exposure of end-user > personal information or may lead to potential disruption of service. > There isn't anything in TE link MIB that relates to end-user personal > information. There is potential for disruption of service if someone > changes attributes in any table of the MIB because this affects = routing > (this is my first statement) and there may be disruption of service if = the > IP address are used in some form of spoofing or attack (this is my = second > statement). I don't know that there is much else to say according to = the > spirit of the security guidelines. >=20 I am just trying to help here. I know Security ADs are often picky these days. We'll see what they say when it gets to IESG. You can also send and email to them beforehand and check if they are OK with what you = have. Feel free to copy this discussion. Bert ------=_NextPart_000_0109_01C325FE.DD4F79C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have submitted a new version of TE link MIB to = address=20 Bert's comments. Here is my response to Bert's comments that outlines = that=20 changes that have been done to the latest version.
* * *
 
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: = Martin Dubuc=20 <m.dubuc@rogers.com>, mpls@UU.NET
Subject: AD review of:=20 draft-ietf-mpls-telink-mib-01.txt
Date: Fri, 9 May 2003 16:35:35 = +0200=20
MIME-Version: 1.0
X-Mailer: Internet Mail Service=20 (5.5.2653.19)
Content-Type:=20 text/plain;
 charset=3D"iso-8859-1"
 
Lots of good changes have been made. This is what I = still=20 find.
 
I have now checked the example in section = 7.
 
It does start off with a disclaimer that it does not = show
all nuances of the MIB module. But ...
 
- When you do a createAndGo, then all row objects = that do=20 not
  have a DEFVAL need to be provided. So the way things are=20
  described will cause SNMP errors. If you do not want to=20 list
  all the details, then at least I'd suggest to make a=20 statement
  aka: appropriate values for all row objects must be=20 passed
  for every row createAndGo action.
 
[Martin] I have defined all rows = explicitly.
 
- two rows are created with createAndWait. =
  I do not=20 see they ever get activated. Was the assumption that
  they = would get=20 activted automagically, or is this an ommission?
 
[Martin] There is no reason to use createAndWait = here. Have=20 fixed it.
 
May I suggest that you make the names of your TCs = start with=20 TeLink
or some such? This to show that they are basically local TCs. =
It=20 will avoid potential future name clashes if someone wants to
define a = Generic=20 TC for a similar (or even same) concept.
Suggesteion:
   = Priority           = ; =20 -> TeLinkPriority
  =20 LinkProtection       ->=20 TeLinkProtection
   SwitchingCapability  ->=20 TeLinkSwitchingCapability
  =20 LinkEncodingType     -> = TeLinkEncodingType
This is=20 also recommended in the = draft-ietf-ops-mib-review-guidelines-01.txt
 
[Martin] Done.
 
On page 33, please = remove:
     =20 -- The mandatory groups have to be = implemented
     =20 -- by all devices supporting TE links. However, they may=20 all
      -- be supported as read-only = objects in=20 the case where automatic
      -- = configuration is=20 supported.
This is not correct for the FullCompliance.
It is OK on = page 36=20 (for the ReadOnlyCompliance).
 
[Martin] Removed.
 
Further comments inline (removed things where I am=20 happy):
 
> -----Original Message-----
> From: Martin = Dubuc=20 [mailto:m.dubuc@rogers.com]
> Sent: woensdag 30 april 2003 = 20:09
>=20 To: mpls@UU.NET
> Subject: RE: = I-D=20 ACTION:draft-ietf-mpls-telink-mib-00.txt
>
>
> This = is my=20 response to Bert's email which explains how I have
> addressed = Bert's=20 comments in draft-ietf-mpls-telink-mib-01.txt
> that was submitted = this=20 morining to IETF. My comments are
> embedded in the original mail=20 (prefixed with [Martin]).
>
> Martin
>
> * * = *
>=20
> Here is my review:
> - linelegth=20 checker:
>    $ /bin/checkpage.awk
>=20 <home/ietf/drafts/draft-ietf-mpls-telink-mib-01.txt
>  = ; =20 Long line at 770 with 77 chars
>    Long line at = 771 with=20 76 chars
>    Long line at 1268 with 73=20 chars
>    -: 3 lines longer than 72 characters, = max=20 77
>
> [Martin] Fixed.
>
Mmm... I still se:
$=20 /bin/checkpage.awk <draft-ietf-mpls-telink-mib-01.txt
Long line at = 720=20 with 77 chars
Long line at 721 with 76 chars
Long line at 741 with = 73=20 chars
-: 3 lines longer than 72 characters, max 77
 
[Martin] Fixed.
 
> - I have not yet checked sect 7.
> =
See=20 above
 
> - sect 8.1 under ifType you refernece=20 [IanaFamily].
>   I think the reference should be to the = ianaiftype.mib
>
> [Martin] You are right. Fixed.
>=20
Well... the reference in the reference section is = incorrect.
Check the=20 link. It should be
   http://www.iana.o= rg/assignments/ianaiftype-mib
instead=20 of:
   http://www.iana.org= /assignments/ianatype-mib
 
[Martin] Fixed.
 
> - for my understanding, the figure in sect 8.2, = can you=20
> explain which layers
>   in the stack are = bundle(s),=20 telink or component link. In
> fact it might = be
>   good=20 to add that explanantion to the text, so that people
> can read = it=20 too.
>
> [Martin] Actually the example is not very clear = and your=20
> comment has triggered a flurry of mails between the = authors.
> We=20 have updated the example to make it easier for readers
> to = understand.=20 opticalTrans are component links.
 
MUCH MUCH better now. If you added the ifIndex = number in=20 the
boxes in teh fugures as well, that would improve it even = more.
and I=20 wonder, if it makes sense to use the same ifIndex
numbers in section = 7 and=20 then also point to the figure.
That allows people to better link = between=20 objects and a
visual picture of it. Just a thought.
 
[Martin] ifIndex have been added to figure in = Section=20 8.2.
Examples in Section 7 and Section 8.2 use the same=20 identifiers.
 
> - May I recommend that=20
>     =20 teLinkIpAddrType         &nb= sp;  =20 InetAddressType,
>     =20 teLinkIpAddr          &= nbsp;     =20 InetAddress,
>     =20 teLinkRemoteIpAddr         &= nbsp;=20 InetAddress,
>   Be renamed=20 to:
>     =20 teLinkAddressType         &n= bsp;  =20 InetAddressType,
>     =20 teLinkLocalAddress         &= nbsp; =20 InetAddress,
>     =20 teLinkRemoteAddress         =  =20 InetAddress,
>   First of all, there can be an = unnumbered=20 addresstype (unknown), so then
>   it is not an = IpAddress.=20
>   Second, I think that the first address is the local = address=20 (that is on
>   the device where the instance of the = object=20 lives, no?
>
>   Further I wonder.. if it is an=20 unnumbered link, it has an identifier somehow
>   does = it not.=20 Why would we not put that identifier in the address in that=20 case
>   and describe what it looks like. In fact I = wonder if=20 instead of  the
>   InetAddress.... TCs would it = not be=20 better to use TeHopAddres... TCs from the
>   = MPLS-TC-MIB? It=20 allows for TeHopAddressUnnum as an address
>
>   = In any=20 event, I would not write:
>     = teLinkIpAddrType=20 OBJECT-TYPE
>      =20 SYNTAX       =20 InetAddressType
>      =20 MAX-ACCESS   =20 read-create
>      =20 STATUS       =20 current
>      =20 DESCRIPTION
>         "For = IPv4=20 and IPv6 numbered links, this object represents=20 the
>          IP = address=20 type associated with the TE link.=20 For
>          = unnumbered=20 links, a value of unknown(0) must be used."
>   But = rather=20 something aka:
>     teLinkAddressType=20 OBJECT-TYPE
>      =20 SYNTAX       =20 InetAddressType
>      =20 MAX-ACCESS   =20 read-create
>      =20 STATUS       =20 current
>      =20 DESCRIPTION
>         "The = type of=20 Internet address for the TE link. Only IPv4=20 and
>          IPv6 = and=20 unknown (for unnumbered links) need to be = supported."
>  =20
>   Then forther in the Address itself I would do = something aka=20 (not that
>   the first sentence is REQUIRED as per=20 RFC3291):
>     teLinkLocalAddress=20 OBJECT-TYPE
>      =20 SYNTAX       =20 InetAddress
>      =20 MAX-ACCESS   =20 read-create
>      =20 STATUS       =20 current
>      =20 DESCRIPTION
>         "The = local=20 Internet address for the TE link. The type of this=20
>          address = is=20 determined by the value of the=20 teLinkAddressType
>        =  =20 object. For an unnumbered TE link, the address represents=20 an
>          = unnumbered=20 interface in this format:
>=20
>           = ;   =20 octets  =20 contents           = ;   =20 encoding
>         &nb= sp;    =20 1-4      unnumbered interface   = network-byte=20 order
>        =20 "
>   I stole some of the text from MPLS-TC-MIB for = now
>=20
> [Martin] I have changed the name teLinkIpAddrType to = teLinkAddressType=20 per
> your recommendation. However, I have not changed = teLinkIpAddr=20 and
> teLinkRemoteIpAddr because these fields are really meant to = be IP=20 addresses.
> If address type is unnumbered, then these fields = should not=20 be used (the
> teLinkIncomingIfId and teLinkOutgoingIfId fields = should be=20 used instead).
> It looks like this is not clear enough in the = MIB,=20 so
> I have added text to clarify this point.
>
Mmm... I = see. So=20 I still would change the definition to something
as follows (the 2nd = sentence=20 is manadatory according to RFC3291,
and it is also important to = indicate what=20 the value of this object is
(zero length string) in case of unnumberd = (i.e.=20 unknown type) link):
 
teLinkLocalIpAddr OBJECT-TYPE
  =20 SYNTAX        = InetAddress
  =20 MAX-ACCESS    read-create
  =20 STATUS        current
   = DESCRIPTION
       "The Local Internet = Address=20 for numbered links. The type of=20 this
        address is determined = by the=20 value of the = teLinkAddressType
       =20 object.
 
        For IPv4 = and IPv6=20 numbered links, this object represents=20 the
        local IP address = associated=20 with the TE link. For an=20 unnumbered
        link, the local = address=20 is of type unknown and this this object=20
        is set to the zero length = string=20 and the teLinkOutgoingIfId
        = object=20 then identifies the unnumbered 'address'."
   ::=3D { = teLinkEntry 2=20 }
 
[Martin] Updated accordingly. Have also updated=20 teLinkRemoteIpAddr.
 
> - Would it make sense to elaborate a bit in the = DESCRIPTION clause of
>   teLinkProtectionType and = explain what=20 the values exactly mean?
>   Or if they are explained in = that=20 GMPLS-OSPF doc that you
>   refernce, then at least = make that=20 statement.
>
> [Martin] The values are specified in = GMPLS-OSPF, but=20 are actually described in
> GMPLS-ROUTING. I have added this = statement=20 (and the new reference).
>
Mmm... might have better been added = to the=20 TC now that you made it a TC.
 
[Martin] It is not a TC. Only used in one = place.
 
> - When I see a table like = this:
>   =20 teLinkDescriptorTable
>    TeLinkDescriptorEntry = ::=3D=20 SEQUENCE {
>      =20 teLinkDescriptorId         &= nbsp;=20 Unsigned32,
>      =20 teLinkEncodingType         &= nbsp;=20 INTEGER,
>      =20 teLinkDescrPriority         = =20 Unsigned32,
>      =20 teLinkMinReservableBandwidth=20 Unsigned32,
>      =20 teLinkMaxReservableBandwidth Unsigned32,  =20
>      =20 teLinkDescrRowStatus        =20 RowStatus,
>      =20 teLinkDescrStorageType      =20 StorageType
>   Then I always wonder if we cannot make = it easier=20 for people to see which
>   objects are indeed in that = table.=20 The first object name teLinkDescriptorId
>   clealrly is = in this=20 table. Then we have one teLinkEncodingType that is = not
>   so=20 clear. Then we have one that is not as clear as the 1st one, but=20 still
>   gives some clue. Then we have 2 that give not = clue,=20 then we have 2 more
>   that give some clue. How about = naming=20 them:
>    TeLinkDescriptorEntry ::=3D SEQUENCE=20 {
>      =20 teLinkDescriptorId         &= nbsp;     =20 Unsigned32,
>      =20 teLinkDescrEncodingType        &n= bsp; =20 INTEGER,
>      =20 teLinkDescrPriority         =      =20 Unsigned32,
>      =20 teLinkDescrMinReservableBandwidth=20 Unsigned32,
>      =20 teLinkDescrMaxReservableBandwidth Unsigned32,  =20
>      =20 teLinkDescrRowStatus         = ;    =20 RowStatus,
>      =20 teLinkDescrStorageType        &nb= sp;  =20 StorageType
>   If you can agree with that, then pls = check you=20 other tables. The same
>   issue/concern comes back in = a few=20 other tables.
>   In fact our mib guidelines document = does=20 discuss this issue.
>
> [Martin] Although it is not obvious = why=20 some entries do not have the same table
> prefix, some others have = been=20 shortened because of the 32 character limit
> warning for = identifiers=20 reported by smilint. I have changed the
> identifiers so that they = have=20 the same prefix but stayed within
> limit of 32 = characters.
>=20
Mmm... the 32 limit is "recommended", but not a hard limit (that is = why=20 smilint
gives a warning and not an error). The hard limit is 64. And = we have=20 in fact
relaxed quite a bit over the last year or so on this. Again, = this is=20 clearly
described in the mib guidelines document.
 
I would really like the teSrlgTable to have prefixes = that=20 start with
teSrlg instead of just srlg. That will avoid future = possible name=20
conflicts much easier.
 
[Martin] Added 'te' prefixes to srlg = rows.
 
> - Your teLinkNotifEnable would be better named: =
>=20 teLinkNotificationsEnabled
>
> [Martin] Changed.
>=20
Thanks
 
> - I worry about the number of notifications = that can get=20 generated per minute
>   or per second? Can you say = something=20 about it? Do we need an abject that
>   lets an NMS = configure=20 how many notification an agent can send at most per
>  =20 minute?
>
> [Martin] is only one type of notification in = the TE=20 link MIB module.
> This notification can only occur if the = provider uses=20 bundled link and will
> be generated only when there is a mismatch = in a=20 link bundle. Since link bundles
> and TE links are provisioned by = users=20 and not on a regular basis, and since
> mismatches are not likely = to be=20 common, the number of notifications should be
> extremely small. I = do not=20 think there is a need to throttle
> these notifications.
> =
If=20 possible, might want to add some text to DESCRIPTION clause. Will = help
people=20 understand it better.
 
[Martin] See below.
 
> - linkBundleMismatch
>   I do = not=20 understand the DESCRIPTION clause at all. Specifically, if an=20 error
>   is found and the notification is sent, then = the 1=20 second later, the same
>   situation probably still = exists. Is=20 another notification sent?
>   Should such a problem not = be=20 detected when someone creates an antry in
>   a table = and should=20 create operation not be prevented from succeeding?
>
> = [Martin] I=20 expected that the notification would be sent only when the
> = mismatch was=20 detected. We could prevent a create to succeed if we
> detect a = mismatch,=20 but it may be easier to just flag the error.
> I don't know how = others=20 feel about this.
>
In general it is better to return an error = on an=20 SNMP SET when someone
tries to do somthing bad instead of letting it = pass and=20 generate a
notification. Note that the error would go back to the = offender,=20 while
you have no idea where the notification goes.
 
[Martin] I don't have a strong case for this = notification. I=20 agree that
it is better to flag the error as it appears. Furthermore, = if we=20 keep
this notification, we need another one to notify when condition = is=20 cleared.
This becomes a bit too involved. For this reason, I have = decided to=20 remove
this notification.
 
>    I wonder if you do not need = ipv4z=20 and/or ipv6z.  As long as you have
>    = evaluated this=20 (with the WG) and decide that you do not need it, = then
>   =20 fine.
>
> [Martin] The issue of what to do with ipv4z and = ipv6z has=20 not been raised
> by the WG or by the 3 implementations that we = know of=20 the MIB.
>
So maybe the WG SHOULD wonder about this. The = question is=20 not so much
about if it has already been implemented or not. The = question is=20 if
Traffic Engineered links can be created over Link Local or Site=20 Local.
interfaces/links. (By the way I know that site local is=20 being
abandoned by IPv6 WG).
 
[Martin] I have raised this issue on the MPLS = mailing=20 list.
 
> - I have trouble=20 with:
>      =20 OBJECT     =20 teLinkRowStatus
>      =20 SYNTAX      INTEGER { active(1),=20 notInService(2),
>        &= nbsp;           &n= bsp;       =20 createAndGo(4), destroy(6) }
>       = DESCRIPTION
>         =  =20 "The notReady(3) state need not be supported."
> =
>   I=20 think what you want to specify is that createAndWait is not=20 needed.
>   Since you allow all objects to be changed in = 'active' mode, the
>   notInService may not be needed = either.=20 (I am assuming here that I
>   did understand your = intent...=20 which I am not sure of). In that case
>   something like = the=20 following example from RFC3289 would be better:
>=20
>     OBJECT=20 diffServClfrStatus
>     SYNTAX RowStatus { = active(1)=20 }
>     WRITE-SYNTAX RowStatus { = createAndGo(4),=20 destroy(6) }
>    =20 DESCRIPTION
>        "Support = for=20 createAndWait and notInService is not required."
>
> = [Martin] The=20 notInService is required since it is one of the state that
> = allows writes=20 (see explanation a few points above). notReady
> and = createAndWait are=20 not required. For read-only, only active is
> required. I have = updated=20 text in this respect.
>
Mmm... in the example in section 7, = you DO=20 show that you would do a
createAndWait for the teLinkTable, don't = you?
So=20 this COMPLIANCE statement seems to be in conflict with that.
So pls = decide=20 what it is or should be and then we need to
make a proper = specification that=20 is in sync with that.
 
It seems to me, that for your teLinkRowStatus in the = rev 01=20 document
(assuming you do want createAndWait as per section 7) that=20 the
statement on teLinkRowStatus should be removed.
If indeed you = do not=20 want/need createAndWait (but then sect 7 needs
an update), then it = could be=20 changed to:
 
     = OBJECT     =20 teLinkRowStatus
     = SYNTAX     =20 INTEGER { active(1), notInService(2) }
     = WRITE-SYNTAX=20 RowStatus { notInService(2),=20 createAndGo(4),
         =             &= nbsp;       =20 destroy(6) }
    =20 DESCRIPTION
         "The = notReady(3)=20 and createAndWait(5) states=20 need
          not be=20 supported."
 
[Martin] No createAndWait is required. See = above.
 
> - I have trouble=20 with:
>      =20 OBJECT     =20 teLinkStorageType
>      =20 SYNTAX      INTEGER { other(1)=20 }
>      =20 DESCRIPTION
>         =  =20 "Only other(1) needs to be supported."
>
>   I = think I=20 could live with a volatile only, but the 'other' = value
>   is=20 completely unspecified and seems to make no sense to me at=20 all.
>   What is you intention here?
>
> = [Martin] I=20 picked this from the LSR MIB. I don't think there is a good
> = reason to=20 limit to one single value. I have removed this conformance
>=20 statement.
>
I hope LSR MIB will remove it too!!
 
> - In security = considerations...
>   - Do=20 All tables have the same considerations? If so you may=20 want
>     to make that explicit.
> =
>=20 [Martin] Yes, they all have the same considerations. All info in = this
>=20 MIB module are used for routing purposes. To me, they have the
> = same=20 sensitivity. Except for IP addresses, which may actually be used
> = in some=20 sort of attack if known. This is why I have a separate clause
> = regarding=20 IP addresses.
>
>   - In general, our security = ADs=20 probably want some more specificity.
>     A = statement=20 like "all tables ....." sounds as if you are =
>    =20 opting for an easy out.
>
> [Martin] It may sounds like I = am opting=20 for an easy out, but the fact of
> the matter is, all tables have = the same=20 considerations.
>
If you make an EXPLICIT statement that they = ALL have=20 the same
security considerations, then you show that you have = thought=20 about
it and have made a conscious decision (or so I think). E.g.=20 something
like "All the tables in this MIB module have routing = information=20 in
them and so they all have the same security = attributes."
 
[Martin] Made this explicit.
 
>   - On th eread-only objects... are = there no=20 issues with bandwith info?
>     Or = priorities? On=20 protection?
>     would that not reveal info = that=20 people don't want to loose?
>
> [Martin] The problem here = is where=20 you draw the line. Every MIB object
> is vulnerable and may reveal = info=20 that would be better kept secret. I have
> read the security = guidelines=20 thoroughly and my interpretation is that we
> should uncover = anything that=20 is sensitive to exposure of end-user
> personal information or may = lead to=20 potential disruption of service.
> There isn't anything in TE link = MIB=20 that relates to end-user personal
> information. There is = potential for=20 disruption of service if someone
> changes attributes in any table = of the=20 MIB because this affects routing
> (this is my first statement) = and there=20 may be disruption of service if the
> IP address are used in some = form of=20 spoofing or attack (this is my second
> statement). I don't know = that=20 there is much else to say according to the
> spirit of the = security=20 guidelines.
>
I am just trying to help here. I know Security = ADs are=20 often picky these
days. We'll see what they say when it gets to IESG. = You can=20 also send
and email to them beforehand and check if they are OK with = what you=20 have.
Feel free to copy this discussion.
 
Bert
------=_NextPart_000_0109_01C325FE.DD4F79C0-- From owner-mpls@UU.NET Sat May 31 00:36: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 AAA11231 for ; Sat, 31 May 2003 00:36: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 QQoqzy12122 for ; Sat, 31 May 2003 04:36: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 QQoqzy11284; Sat, 31 May 2003 04:36:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQoqxw04968 for mpls-outgoing; Fri, 30 May 2003 15:03: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 QQoqxw03328 for ; Fri, 30 May 2003 15:03:00 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 QQoqxw28019 for ; Fri, 30 May 2003 15:02:30 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 QQoqxw17286 for ; Fri, 30 May 2003 15:02:28 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 QQoqxw17264 for ; Fri, 30 May 2003 15:02:27 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 h4UF2PXg021891 for ; Fri, 30 May 2003 11:02:25 -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 LAA08087 for ; Fri, 30 May 2003 11:02:24 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h4UF2O118868 for mpls@uu.net; Fri, 30 May 2003 11:02:24 -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 QQoqxn29983 for ; Fri, 30 May 2003 12:50:20 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 QQoqxn19139 for ; Fri, 30 May 2003 12:48: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 QQoqxn09851 for ; Fri, 30 May 2003 12:48:36 GMT Received: from ns.ft.solteria.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.ft.solteria.net [210.142.173.164]) id QQoqxn09832 for ; Fri, 30 May 2003 12:48:35 GMT Received: from SATORUVAIO.ft.solteria.net (satoru [143.90.135.195]) by ns.ft.solteria.net (Postfix) with ESMTP id 4393638712 for ; Fri, 30 May 2003 21:48:30 +0900 (JST) Message-Id: <4.3.2-J.20030530213350.02066bf0@ns.ft.solteria.net> X-Sender: satoru@ns.ft.solteria.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Fri, 30 May 2003 21:47:43 +0900 To: mpls@UU.NET From: "S.Matsushima" Subject: Short comment for draft-ietf-mpls-lsp-ping-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, One comment. From section "5.3. Procedures at the ingress LSR" described following: > If X does not receive an Resv message from the egress LSR that > contains an LSP_ECHO object within some period of time, it declares > the LSP as "down". At this point, the ingress LSR may apply the > necessary procedures to fix the LSP. These may include generating a > message to network management, tearing-down and re-building the LSP, > and/or rerouting user traffic to a backup LSP. I agree that rebuilding LSP and rerouting to other or backup LSP when primary LSP was defected. But I think that the ingress LSR should not tearing-down defected LSP because localizing point of failure will be difficult. -- Satoru Matsushima, Japan Telecom