Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id XAA19369 for ; Fri, 30 Jan 1998 23:17:22 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA26202 for idr-outgoing; Fri, 30 Jan 1998 23:12:14 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id XAA26198 for ; Fri, 30 Jan 1998 23:12:10 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id XAA14246; Fri, 30 Jan 1998 23:12:10 -0500 (EST) Message-Id: <199801310412.XAA14246@brookfield.ans.net> To: idr@merit.edu cc: curtis@ans.net Reply-To: curtis@ans.net Subject: draft-ietf-idr-bgp4-06.txt Date: Fri, 30 Jan 1998 23:12:09 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk draft-ietf-idr-bgp4-06.txt is about to expire. Does that concern anyone? What happenned to updating BGP-4? Curtis Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA16072 for ; Thu, 22 Jan 1998 14:35:34 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA19851 for idr-outgoing; Thu, 22 Jan 1998 14:31:36 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA19846 for ; Thu, 22 Jan 1998 14:31:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA15565; Thu, 22 Jan 1998 14:31:25 -0500 (EST) Message-Id: <199801221931.OAA15565@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Document Action: Using a Dedicated AS for Sites Homed to a Single Provider to Informational Date: Thu, 22 Jan 1998 14:31:25 -0500 Sender: owner-idr@merit.edu Precedence: bulk The IESG has approved the Internet-Draft 'Using a Dedicated AS for Sites Homed to a Single Provider' as a Informational. This document is the product of the Inter-Domain Routing Working Group. The IESG contact person is Joel Halpern. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id QAA24582 for ; Tue, 20 Jan 1998 16:50:28 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA08946 for idr-outgoing; Tue, 20 Jan 1998 16:46:23 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA08942 for ; Tue, 20 Jan 1998 16:46:18 -0500 (EST) Received: from aqua.preferred-mail.net (ns1.preferred-mail.net [209.116.179.11]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id QAA23131 for ; Tue, 20 Jan 1998 16:46:15 -0500 (EST) Received: ok X-Sender: 3dgrafx@crystal3d.com X-Advertisement: Click here to be removed. Date: Tue, 20 Jan 1998 15:29:32 -0500 From: Email Submission <3dgrafx@crystal3d.com> Reply-To: Email Submission <3dgrafx@crystal3d.com> To: friend@bulkmailer Subject: Ad: TAIM Certified E-mail FREE 3D Animation Software Demo X-Mailer: AK-Mail 3.0b [eng] (unregistered) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Sender: owner-idr@merit.edu Precedence: bulk Download a FREE trial version of the world's easiest-to-use 3D animation software, Crystal 3D IMPACT! Pro. Now it's a snap for web developers, video enthusiasts and others to add the impact of extraordinary 3D titles, logos, objects, buttons and pictures to web pages, e-mail messages, banner ads, videos and presentations. This newly released software (for Windows 95 or NT) can be downloaded at http://www.crystalgraphics.com/weblink1.3dimpact.html. Crystal 3D IMPACT! Pro is a breakthrough in ease of use and lets you start creating eye-catching, animated 3D graphics immediately with the program's friendly wizards. There are also many time saving features like an Auto-Outline tool that lets you easily and accurately trace your complicated designs and company logos. Crystal 3D IMPACT! Pro is the only 3D program that lets you automatically import your images as 2D objects then animate them in 3D with a single click. Crystal 3D IMPACT! Pro (released November 18, 1997) is the latest 3D product from CrystalGraphics, a leading developer of award-winning 3D software for over 10 years. Here's what others say about this hot new product: "I was in awe of the simplicity of the interface! You gotta try it out!" -- Bruce Beard, Web Designer "The awesome speed, quality and power are the best I've ever seen in any product of its class!" -- Mark Wacholtz, Web Developer "The effects are dazzling; the images almost seem to jump off the screen. Now anybody can make 3D animations look as if they came out of a high-end production house." -- Greg Carroll, TV Marketing Executive TOP TEN REASONS TO DOWNLOAD CRYSTAL 3D IMPACT! PRO: 1. The trial version is FREE! 2. It will make your web pages, banner ads, videos and presentations stand out! 3. It is incredibly easy-to-use, much easier than any other 3D product! 4. It lets you easily add 3D titles, logos, objects, buttons and pictures to your work! 5. It has a wizard which walks you through the 5 basic steps of creating 3D title animations! 6. It is extremely powerful and lets you control professional-level rendering effects like soft-edged shadows, ray-traced refractions, video backgrounds, object reflections and much more! 7. Its photorealistic output will impress everyone! 8. It renders up to 5 times faster than the competition! 9. It includes over 145 high-quality, pre-built 3D "clipart" objects, with more free each month at our web site! 10. It is fully compatible with popular web authoring, digital video editing and presentation software! Again, here is where you can find your FREE trial version of Crystal 3D IMPACT! Pro: http://www.crystalgraphics.com/weblink1.3dimpact.html. Thank you, Your Friends at CrystalGraphics 408-496-6175 If you don't want to receive future e-mail messages about CrystalGraphics products, please reply to this message with "REMOVE" in the subject field. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id LAA26100 for ; Thu, 15 Jan 1998 11:58:18 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA04390 for idr-outgoing; Thu, 15 Jan 1998 11:54:48 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA04386 for ; Thu, 15 Jan 1998 11:54:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA03615; Thu, 15 Jan 1998 11:54:26 -0500 (EST) Message-Id: <199801151654.LAA03615@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-02.txt Date: Thu, 15 Jan 1998 11:54:25 -0500 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multiprotocol Extensions for BGP-4 Author(s) : D. Katz, Y. Rekhter, T. Bates, R. Chandra Filename : draft-ietf-idr-bgp4-multiprotocol-02.txt Pages : 9 Date : 14-Jan-98 Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. Internet-Drafts are 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-idr-bgp4-multiprotocol-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19980115112845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-multiprotocol-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980115112845.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA24888 for ; Thu, 15 Jan 1998 10:10:42 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA02233 for idr-outgoing; Thu, 15 Jan 1998 10:06:29 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA02217 for ; Thu, 15 Jan 1998 10:06:21 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id KAA03203 for ; Thu, 15 Jan 1998 10:06:20 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id HAA01889; Thu, 15 Jan 1998 07:05:47 -0800 Message-Id: <199801151505.HAA01889@puli.cisco.com> To: jhalpern@newbridge.com cc: bgp@ans.net Subject: draft-ietf-idr-route-damp-01.txt Date: Thu, 15 Jan 98 07:05:47 PST From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Joel, The IDR WG would like to ask the IESG to advance draft-ietf-idr-route-damp-01.txt to a Proposed Standard. Yakov. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA24882 for ; Thu, 15 Jan 1998 10:10:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA02265 for idr-outgoing; Thu, 15 Jan 1998 10:07:57 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA02260 for ; Thu, 15 Jan 1998 10:07:52 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id KAA03375 for ; Thu, 15 Jan 1998 10:07:51 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id HAA01917; Thu, 15 Jan 1998 07:07:19 -0800 Message-Id: <199801151507.HAA01917@puli.cisco.com> To: jhalpern@newbridge.com cc: bgp@ans.net Subject: draft-heffernan-bgp-tcp-md5-00.txt Date: Thu, 15 Jan 98 07:07:19 PST From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Joel, The IDR WG would like to ask the IESG to advance draft-heffernan-bgp-tcp-md5-00.txt to a Proposed Standard. Yakov. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA12167 for ; Wed, 14 Jan 1998 10:02:03 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA17212 for idr-outgoing; Wed, 14 Jan 1998 09:53:14 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA17208 for ; Wed, 14 Jan 1998 09:53:10 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26251; Wed, 14 Jan 1998 09:53:06 -0500 (EST) Message-Id: <199801141453.JAA26251@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-01.txt,.ps Date: Wed, 14 Jan 1998 09:53:05 -0500 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-01.txt,.ps Pages : 30 Date : 13-Jan-98 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are 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-idr-route-damp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-route-damp-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19980113144706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980113144706.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id IAA29278 for ; Tue, 13 Jan 1998 08:02:20 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA26573 for idr-outgoing; Tue, 13 Jan 1998 07:55:54 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA26569 for ; Tue, 13 Jan 1998 07:55:48 -0500 (EST) Received: from door2inet.boehm.priv.at (mcp.vbs.at [194.152.163.128]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id HAA22177 for ; Tue, 13 Jan 1998 07:55:38 -0500 (EST) Received: (from hannes@localhost) by door2inet.boehm.priv.at (8.8.5/8.8.5) id NAA24423; Tue, 13 Jan 1998 13:48:09 +0100 Message-ID: <19980113134809.56205@boehm.org> Date: Tue, 13 Jan 1998 13:48:09 +0100 From: "Hannes R. Boehm" To: Project account - Bombay gate Cc: bgp@ans.net Subject: Re: Community Attributes References: Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="fUYQa+Pmc3FrFX/N" X-Mailer: Mutt 0.88 In-Reply-To: ; from Project account - Bombay gate on Tue, Jan 13, 1998 at 11:00:49AM -0530 Sender: owner-idr@merit.edu Precedence: bulk --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 13, 1998 at 11:00:49AM -0530, Project account - Bombay gate wro= te: > Hi > In Examples section of RFC 1997 it is mentioned that=20 > "It is often useful to advertise both an aggregate prefix and the=20 > component more specific prefixes that were used to form the aggregate to= =20 > optimize the 'next hop' routing". > My doubt is =20 > 1. What is this optimization of 'next hop' routing based on the more=20 > specific prefixes when both the aggregate prefix and the more specific=20 > prefixes are advertised. > 2. When it is useful to advertise both aggregate prefix and the=20 > contributing prefixes.=20 2) I can give you a simple example: =20 Consider a AS that is multihomed to a single provider.=20 ---------------------------------------------- | AS2 | |--------------------------------------------- | Link 1 | Link 2 | 20.10.0.0/22 | 20.10.0.0/22 | 20.10.0.0/23 no_export | 20.10.2.0/23 no_export | | ---------------------------------------------- | AS1 | | 20.10.0.0-20.10.4. | |--------------------------------------------- AS1 announces the aggregate (20.10.0.0/22) on both Links, 20.10.0.0/23 with= the community noexprt on Link1 and 20.10.2.0/23 with noexport on Link2. What happens? AS2 is not allowed to announce the more specific routes (20.10.0.0/23 and 2= 0.10.2.0/23) -> the global routing table contains only the aggregate 20.10.0.0/22 (Path:= ^.*_2 1$) BUT: AS2 has more specific routes -> it routes the net 20.10.0.0/23 via Lin= k1 and 20.10.2.0/23 via Link2. What happens if Link1 fails ? AS2 looses the route for 20.10.0.0/23 -> the aggregated route (20.10.0.0/22) is used for packets to 20.10.0.0/23 = (via Link2) Of course this does not only work for community no_export. -> The community has more detailed routing information than the global rout= ing table. 1) This is some kind of optimisation, isn=B4t it ? :) CU,=20 Hannes Boehm --=20 -- "The nice thing about standards is that there's so many to choose from."=20 -- Andrew S. Tannenbaum !------------------------------------------------------------------! Hannes R. Boehm email : hannes@boehm.org www : http://hannes.boehm.org PGP-key : http://hannes.boehm.org/hannes-pgp.asc !------------------------------------------------------------------! --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 13, 1998 at 11:00:49AM -0530, Project account - Bombay gate wro= te: > Hi > In Examples section of RFC 1997 it is mentioned that=20 > "It is often useful to advertise both an aggregate prefix and the=20 > component more specific prefixes that were used to form the aggregate to= =20 > optimize the 'next hop' routing". > My doubt is =20 > 1. What is this optimization of 'next hop' routing based on the more=20 > specific prefixes when both the aggregate prefix and the more specific=20 > prefixes are advertised. > 2. When it is useful to advertise both aggregate prefix and the=20 > contributing prefixes.=20 2) I can give you a simple example: =20 Consider a AS that is multihomed to a single provider.=20 ---------------------------------------------- | AS2 | |--------------------------------------------- | Link 1 | Link 2 | 20.10.0.0/22 | 20.10.0.0/22 | 20.10.0.0/23 no_export | 20.10.2.0/23 no_export | | ---------------------------------------------- | AS1 | | 20.10.0.0-20.10.4. | |--------------------------------------------- AS1 announces the aggregate (20.10.0.0/22) on both Links, 20.10.0.0/23 with= the community noexprt on Link1 and 20.10.2.0/23 with noexport on Link2. What happens? AS2 is not allowed to announce the more specific routes (20.10.0.0/23 and 2= 0.10.2.0/23) -> the global routing table contains only the aggregate 20.10.0.0/22 (Path:= ^.*_2 1$) BUT: AS2 has more specific routes -> it routes the net 20.10.0.0/23 via Lin= k1 and 20.10.2.0/23 via Link2. What happens if Link1 fails ? AS2 looses the route for 20.10.0.0/23 -> the aggregated route (20.10.0.0/22) is used for packets to 20.10.0.0/23 = (via Link2) Of course this does not only work for community no_export. -> The community has more detailed routing information than the global rout= ing table. 1) This is some kind of optimisation, isn=B4t it ? :) CU,=20 Hannes Boehm --=20 -- "The nice thing about standards is that there's so many to choose from."=20 -- Andrew S. Tannenbaum !------------------------------------------------------------------! Hannes R. Boehm email : hannes@boehm.org www : http://hannes.boehm.org PGP-key : http://hannes.boehm.org/hannes-pgp.asc !------------------------------------------------------------------! --fUYQa+Pmc3FrFX/N-- Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id EAA27796 for ; Tue, 13 Jan 1998 04:13:51 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA25631 for idr-outgoing; Tue, 13 Jan 1998 04:09:41 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA25626 for ; Tue, 13 Jan 1998 04:09:36 -0500 (EST) Received: from teil.soft.net (teil.soft.net [164.164.10.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id EAA07536 for ; Tue, 13 Jan 1998 04:09:19 -0500 (EST) Received: by teil.soft.net (940816.SGI.8.6.9/940406.SGI) id OAA01705; Tue, 13 Jan 1998 14:40:03 -0530 Date: Tue, 13 Jan 1998 14:30:41 -0530 (IST) From: Project account - Bombay gate Subject: AS CONFEDERATIONS To: bgp@ans.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Hello The AS_PATH modification rules section of the RFC 1965 states that "When a given BGP speaker advertises the route to another BGP speaker located in a neighboring autonomous system that is a member of the local autonomous system confederation, then the advertising speaker shall update the AS_PATH attribute as follows. 2) If the first path segment of the AS_PATH is not of type AS_CONFED_SEQUENCE the local system shall prepend a new path segment of type AS_CONFED_SEQUENCE to the AS_PATH, including its own confederation identifier in that segment" But it is suppose prepend its own AS number and not the confederation identifier. Any thoughts on this issue. Regards Sridhar Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id CAA26968 for ; Tue, 13 Jan 1998 02:38:55 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA25007 for idr-outgoing; Tue, 13 Jan 1998 02:36:46 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA25003 for ; Tue, 13 Jan 1998 02:36:42 -0500 (EST) Received: from teil.soft.net (teil.soft.net [164.164.10.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id CAA01453 for ; Tue, 13 Jan 1998 02:36:22 -0500 (EST) Received: by teil.soft.net (940816.SGI.8.6.9/940406.SGI) for bgp@ans.net id NAA26241; Tue, 13 Jan 1998 13:07:33 -0530 From: tebombay@teil.soft.net (Project account - Bombay gate) Message-Id: <199801131837.NAA26241@teil.soft.net> Subject: Clarification about SNPAs To: bgp@ans.net Date: Tue, 13 Jan 1998 13:07:33 -0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Hi, Is SNPA field present in the MP_REACH_NLRI attribute similar to LLC-SNAP encapsulation for demultiplexing in NBMA type media or just provided for a IP to MAC address resolution. Kindly throw more light on its usage regards mouli Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA26254 for ; Tue, 13 Jan 1998 00:33:22 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA24091 for idr-outgoing; Tue, 13 Jan 1998 00:30:34 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA24085 for ; Tue, 13 Jan 1998 00:30:30 -0500 (EST) Received: from teil.soft.net (teil.soft.net [164.164.10.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id AAA23668 for ; Tue, 13 Jan 1998 00:30:24 -0500 (EST) Received: by teil.soft.net (940816.SGI.8.6.9/940406.SGI) id LAA19921; Tue, 13 Jan 1998 11:01:58 -0530 Date: Tue, 13 Jan 1998 11:00:49 -0530 (IST) From: Project account - Bombay gate Subject: Community Attributes To: bgp@ans.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Hi In Examples section of RFC 1997 it is mentioned that "It is often useful to advertise both an aggregate prefix and the component more specific prefixes that were used to form the aggregate to optimize the 'next hop' routing". My doubt is 1. What is this optimization of 'next hop' routing based on the more specific prefixes when both the aggregate prefix and the more specific prefixes are advertised. 2. When it is useful to advertise both aggregate prefix and the contributing prefixes. Regards Sridhar Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id VAA24935 for ; Mon, 12 Jan 1998 21:53:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA22611 for idr-outgoing; Mon, 12 Jan 1998 21:51:07 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA22603 for ; Mon, 12 Jan 1998 21:50:46 -0500 (EST) Received: from aqua.preferred-mail.net (ns1.preferred-mail.net [209.116.179.11]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id VAA12647 for ; Mon, 12 Jan 1998 21:50:40 -0500 (EST) Received: ok X-Sender: 3dgrafx@crystal3d.com X-Advertisement: Click here to be removed. Date: Mon, 12 Jan 1998 19:43:14 -0500 From: Email Submission <3dgrafx@crystal3d.com> Reply-To: Email Submission <3dgrafx@crystal3d.com> To: friend@bulkmailer Subject: Ad: TAIM Certified E-mail FREE 3D Animation Software Demo! X-Mailer: AK-Mail 3.0b [eng] (unregistered) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Sender: owner-idr@merit.edu Precedence: bulk FREE 3D Animation Software Demo! Download a FREE trial version of the world's easiest-to-use 3D animation software, Crystal 3D IMPACT! Pro. Now it's a snap for web developers, video enthusiasts and others to add the impact of extraordinary 3D titles, logos, objects, buttons and pictures to web pages, e-mail messages, banner ads, videos and presentations. This newly released software (for Windows 95 or NT) can be downloaded at http://www.crystalgraphics.com/weblink1.3dimpact.html. Crystal 3D IMPACT! Pro is a breakthrough in ease of use and lets you start creating eye-catching, animated 3D graphics immediately with the program's friendly wizards. There are also many time saving features like an Auto-Outline tool that lets you easily and accurately trace your complicated designs and company logos. Crystal 3D IMPACT! Pro is the only 3D program that lets you automatically import your images as 2D objects then animate them in 3D with a single click. Crystal 3D IMPACT! Pro (released November 18, 1997) is the latest 3D product from CrystalGraphics, a leading developer of award-winning 3D software for over 10 years. Here's what others say about this hot new product: "I was in awe of the simplicity of the interface! You gotta try it out!" -- Bruce Beard, Web Designer "The awesome speed, quality and power are the best I've ever seen in any product of its class!" -- Mark Wacholtz, Web Developer "The effects are dazzling; the images almost seem to jump off the screen. Now anybody can make 3D animations look as if they came out of a high-end production house." -- Greg Carroll, TV Marketing Executive TOP TEN REASONS TO DOWNLOAD CRYSTAL 3D IMPACT! PRO: 1. The trial version is FREE! 2. It will make your web pages, banner ads, videos and presentations stand out! 3. It is incredibly easy-to-use, much easier than any other 3D product! 4. It lets you easily add 3D titles, logos, objects, buttons and pictures to your work! 5. It has a wizard which walks you through the 5 basic steps of creating 3D title animations! 6. It is extremely powerful and lets you control professional-level rendering effects like soft-edged shadows, ray-traced refractions, video backgrounds, object reflections and much more! 7. Its photorealistic output will impress everyone! 8. It renders up to 5 times faster than the competition! 9. It includes over 145 high-quality, pre-built 3D "clipart" objects, with more free each month at our web site! 10. It is fully compatible with popular web authoring, digital video editing and presentation software! Again, here is where you can find your FREE trial version of Crystal 3D IMPACT! Pro: http://www.crystalgraphics.com/weblink1.3dimpact.html. Thank you, Your Friends at CrystalGraphics 408-496-6175 If you don't want to receive future e-mail messages about CrystalGraphics products, please reply to this message with "REMOVE" in the subject field. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id IAA17366 for ; Mon, 12 Jan 1998 08:34:00 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA06454 for idr-outgoing; Mon, 12 Jan 1998 08:24:49 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA06450 for ; Mon, 12 Jan 1998 08:24:45 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA15811; Mon, 12 Jan 1998 08:23:17 -0500 (EST) Message-Id: <199801121323.IAA15811@ns.ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 12 Jan 1998 08:23:17 -0500 Sender: owner-idr@merit.edu Precedence: bulk The IESG has received a request from the Inter-Domain Routing Working Group to consider Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 26, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id FAA05929 for ; Sun, 11 Jan 1998 05:08:48 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA28115 for idr-outgoing; Sun, 11 Jan 1998 05:05:20 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA28111 for ; Sun, 11 Jan 1998 05:05:16 -0500 (EST) Received: from mail.earth1.net ([208.157.7.9]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id FAA16947 for ; Sun, 11 Jan 1998 05:05:15 -0500 (EST) Date: Sun, 11 Jan 1998 05:05:15 -0500 (EST) Received: from [205.197.57.135] by mail.earth1.net (NTMail 3.03.0014/4c.aejn) with ESMTP id fa035781 for ; Sun, 11 Jan 1998 04:59:32 -0500 From: wwqq11 To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, January 2nd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, December 31st, 1997 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, December 29th, 1997 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, December 28th, 1997 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, January 3rd, 1998 Reply-To: wwqq11@qorldnet.att.net Sender: owner-idr@merit.edu Precedence: bulk Authenticated sender is Subject: Year Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 11 Jan 1998 04:59:29 -0500 EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id EAA05639 for ; Sun, 11 Jan 1998 04:01:39 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA27785 for idr-outgoing; Sun, 11 Jan 1998 03:57:52 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA27781 for ; Sun, 11 Jan 1998 03:57:49 -0500 (EST) Received: from mail.nxs.net (mail.nxs.net [207.65.168.60]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id DAA15241 for ; Sun, 11 Jan 1998 03:57:48 -0500 (EST) Date: Sun, 11 Jan 1998 03:57:48 -0500 (EST) Received: from jj3dw3.q3q3665f.com (205.197.57.135) by mail.nxs.net (Rockliffe SMTPRA 1.2.2) with SMTP id ; Sun, 11 Jan 1998 03:58:28 -0500 From: zz444q To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, January 2nd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, December 31st, 1997 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, December 29th, 1997 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, December 28th, 1997 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, January 3rd, 1998 Reply-To: zz444q@ix.netcom.com Sender: owner-idr@merit.edu Precedence: bulk Authenticated sender is Subject: Monday Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id EAA05637 for ; Sun, 11 Jan 1998 04:01:38 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA27774 for idr-outgoing; Sun, 11 Jan 1998 03:56:52 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA27770 for ; Sun, 11 Jan 1998 03:56:47 -0500 (EST) Received: from server1.softdisk.com (server1.softdisk.com [206.28.109.1]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id DAA15229 for ; Sun, 11 Jan 1998 03:56:46 -0500 (EST) Received: from default (user-36sae3e.dialup.mindspring.com [205.197.56.110]) by server1.softdisk.com (8.7.5/8.7.3) with SMTP id DAA14261; Sun, 11 Jan 1998 03:01:06 -0600 (CST) Date: Sun, 11 Jan 1998 03:01:06 -0600 (CST) From: jhjh71 To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Sunday, January 11th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Friday, January 9th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Wednesday, January 7th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Tuesday, January 6th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Monday, January 12th, 1998 Reply-To: jhjh71@ix.netcom.com Sender: owner-idr@merit.edu Precedence: bulk Authenticated sender is Subject: January Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id IAA28345 for ; Fri, 9 Jan 1998 08:51:23 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA08471 for idr-outgoing; Fri, 9 Jan 1998 08:46:47 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA08465 for ; Fri, 9 Jan 1998 08:46:43 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id FAA23190; Fri, 9 Jan 1998 05:45:41 -0800 Message-Id: <199801091345.FAA23190@puli.cisco.com> To: curtis@ans.net cc: idr@merit.edu Subject: Re: Route Flap Damping - changes since last call In-reply-to: Your message of "Thu, 08 Jan 98 21:08:26 EST." <199801090208.VAA21986@brookfield.ans.net> Date: Fri, 09 Jan 98 05:45:41 PST From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Curtis, > There is a revised I-D http://engr.ans.net/route-damp/ along with > complete diffs against the latex source (to avoid having to reread the > whole thing). > > The changes were in response to comments and are: > > Numerous wording changes and small nits. Spell checked. > > New subsection named "Per Route State" providing a clarification on > what can be considered a "route" for the purpose of damping. This > contains a few words on the implications of including some of the > BGP attributes that are stated as optional for the purpose of route > damping. > > A few words of clarification intended to make it more clear that the > "reuse lists" are used both to identify the reachable routes that > are reusable after a waiting time and the unreachable routes that > can be completely disposed of after a waiting time. > > A number of paragraphs were added to the "Implementation Experience" > section to reflect the experiences and recommendations of the RIPE > routing-wg and the case provided by Alan Barrett on the IEPG mailing > list. > > The "Acknowledgements" section was updated, though I can't list > everyone who has provided implementation feedback in the last two > years without missing individuals from so I just listed the groups > (RIPE routing, IEPG, NANOG, IDR) where discussions occurred. > > Because of the added paragraphs it might be worth repeating WG last > call just in case there are comments about the additions before > bothering the IESG. I leave that decision to the WG chairs. I would propose we'll have an "abbreviated" WG Last Call till next Friday (Jan 16). In the absence of any objections to the revised version of your document, on Jan 16 we'll ask the IESG to advance the document to a Proposed Standard. Yakov. Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id VAA23234 for ; Thu, 8 Jan 1998 21:11:24 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA03098 for idr-outgoing; Thu, 8 Jan 1998 21:08:31 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA03094 for ; Thu, 8 Jan 1998 21:08:27 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id VAA21986; Thu, 8 Jan 1998 21:08:26 -0500 (EST) Message-Id: <199801090208.VAA21986@brookfield.ans.net> To: idr@merit.edu cc: curtis@ans.net Reply-To: curtis@ans.net Subject: Route Flap Damping - changes since last call Date: Thu, 08 Jan 1998 21:08:26 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk There were a few comments in the last call for the Route Flap Damping draft, draft-ietf-idr-route-damp-00.txt. I've made revisions and will submit the revised draft (-01) to the rfc editor. There is a revised I-D http://engr.ans.net/route-damp/ along with complete diffs against the latex source (to avoid having to reread the whole thing). The changes were in response to comments and are: Numerous wording changes and small nits. Spell checked. New subsection named "Per Route State" providing a clarification on what can be considered a "route" for the purpose of damping. This contains a few words on the implications of including some of the BGP attributes that are stated as optional for the purpose of route damping. A few words of clarification intended to make it more clear that the "reuse lists" are used both to identify the reachable routes that are reusable after a waiting time and the unreachable routes that can be completely disposed of after a waiting time. A number of paragraphs were added to the "Implementation Experience" section to reflect the experiences and recommendations of the RIPE routing-wg and the case provided by Alan Barrett on the IEPG mailing list. The "Acknowledgements" section was updated, though I can't list everyone who has provided implementation feedback in the last two years without missing individuals from so I just listed the groups (RIPE routing, IEPG, NANOG, IDR) where discussions occurred. Because of the added paragraphs it might be worth repeating WG last call just in case there are comments about the additions before bothering the IESG. I leave that decision to the WG chairs. Curtis ps- the direct URLs are: http://engr.ans.net/route-damp introductory text, diffs, pointers http://engr.ans.net/route-damp/route-damp.html http://engr.ans.net/route-damp/route-damp.txt http://engr.ans.net/route-damp/route-damp.ps ftp://engr.ans.net/pub/internet-drafts/draft-ietf-idr-route-damp-01.txt ftp://engr.ans.net/pub/internet-drafts/draft-ietf-idr-route-damp-01.ps Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA19089 for ; Thu, 8 Jan 1998 14:11:27 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA23452 for idr-outgoing; Thu, 8 Jan 1998 14:09:41 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA23443 for ; Thu, 8 Jan 1998 14:09:34 -0500 (EST) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id OAA07370 for ; Thu, 8 Jan 1998 14:09:22 -0500 (EST) Received: by relay.hq.tis.com; id OAA03209; Thu, 8 Jan 1998 14:07:51 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma003205; Thu, 8 Jan 98 14:07:45 -0500 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id OAA08219; Thu, 8 Jan 1998 14:08:33 -0500 (EST) Date: Thu, 8 Jan 1998 14:08:33 -0500 (EST) From: Sandy Murphy Message-Id: <199801081908.OAA08219@clipper.hq.tis.com> To: prz@dnrc.bell-labs.com Subject: Re: WG Last Call Cc: bgp@ans.net, sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk >Sandy, we know MD5 to be vulnerable and the scheme does not support multiple key >s >either >which is prerequisite for meaningfull security. >If you don't consider those security deficiencies then I don't think we can have >a meaningfull >discussion here ... There are more things but I think the draft points out mos >t >of those accurately >itself. Yes, Curtis pointed out that you were talking about the suspect assurance of MD5, vs HMAC-MD5 or such. I thought you were talking about fundamental problems with the approach - like vulnerabilities through TCP that remain even though the packet is crypto-hashed. I'm relieved. WIthout the ability to reference the specific key out of a set of multiple keys, this technique would require that re-keying be accomplished while the BGP sessions were down. If you need to change keys, you must bring the BGP peerings down, re-key, reestablish peering. I don't know how long peering sessions ususally last, but my uninformed opinion is that they would not last long enough to outlast the key lifetimes for MD5 keys. Right? You are right that algorithm stength, key strength, implementation strength, etc., etc., etc., (Ran Atkinson has a good list that he's put in several of his security documents) all have to be considered when deciding how much assurance you get. I was worried because I thought you were talking about deficiencies in the assurance provided by the protocol itself. --Sandy Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA19027 for ; Thu, 8 Jan 1998 14:05:07 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA23341 for idr-outgoing; Thu, 8 Jan 1998 14:03:01 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA23335 for ; Thu, 8 Jan 1998 14:02:57 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id OAA06673; Thu, 8 Jan 1998 14:02:56 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id LAA23571; Thu, 8 Jan 1998 11:02:16 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id LAA20795; Thu, 8 Jan 1998 11:02:15 -0800 (PST) Date: Thu, 8 Jan 1998 11:02:15 -0800 (PST) Message-Id: <199801081902.LAA20795@chimp.juniper.net> From: Tony Li To: prz@dnrc.bell-labs.com CC: sandy@tis.com, curtis@ans.net, bgp@ans.net, tli@juniper.net In-reply-to: <34B51DFE.4BA8CE89@dnrc.bell-labs.com> (message from Antoni Przygienda on Thu, 08 Jan 1998 13:42:06 -0500) Subject: Re: WG Last Call Sender: owner-idr@merit.edu Precedence: bulk | Sandy, we know MD5 to be vulnerable !?!? I've heard rumors as such, but documentation please? This has major implications in many places. | and the scheme does not support multiple keys either | which is prerequisite for meaningfull security. Given that this is extremely ad hoc and always pair-wise, I don't see this as an issue. Tony Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id NAA18860 for ; Thu, 8 Jan 1998 13:50:56 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA23004 for idr-outgoing; Thu, 8 Jan 1998 13:48:10 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA23000 for ; Thu, 8 Jan 1998 13:48:05 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id NAA05305; Thu, 8 Jan 1998 13:48:02 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jan 8 13:46:47 EST 1998 Received: from dnrc.bell-labs.com (root@prz-laptop [135.180.130.120]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id NAA10582; Thu, 8 Jan 1998 13:46:46 -0500 (EST) Message-ID: <34B51DFE.4BA8CE89@dnrc.bell-labs.com> Date: Thu, 08 Jan 1998 13:42:06 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) MIME-Version: 1.0 To: Sandy Murphy CC: curtis@ans.net, bgp@ans.net, tli@juniper.net Subject: Re: WG Last Call References: <199801081419.JAA03637@clipper.hq.tis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sandy Murphy wrote: > >Message is OK, I don't see necessarily that something with known deficiencies > >should go > >into PS to increase its value > > "known deficiencies"??!!! Could you please explain this further? I don't > recall deficiencies in this mechanism being mentioned yet. If you know > of some, please speak up. As soon as possible. Or point me to the right > message. > > --Sandy Sandy, we know MD5 to be vulnerable and the scheme does not support multiple keys either which is prerequisite for meaningfull security. If you don't consider those security deficiencies then I don't think we can have a meaningfull discussion here ... There are more things but I think the draft points out most of those accurately itself. To prevent wild flaming let me tell here again that I'm not against the scheme. I'm not saying that it's not a fine thing to do as a solution and deployed implementations have their charme (actually a lot of charme). However, I don't think that it matters that much whether it's BCP or PS but making it PS to increase its value somehow defeats my logic. thank you, Sandy --- tny Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA17937 for ; Thu, 8 Jan 1998 12:11:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA21635 for idr-outgoing; Thu, 8 Jan 1998 12:09:13 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA21631 for ; Thu, 8 Jan 1998 12:09:04 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id MAA27453; Thu, 8 Jan 1998 12:09:02 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id MAA20548; Thu, 8 Jan 1998 12:09:00 -0500 (EST) Message-Id: <199801081709.MAA20548@brookfield.ans.net> To: Tony Li cc: curtis@ans.net, prz@dnrc.bell-labs.com, bgp@ans.net Reply-To: curtis@ans.net Subject: Re: WG Last Call In-reply-to: Your message of "Wed, 07 Jan 1998 17:56:23 PST." <199801080156.RAA15885@chimp.juniper.net> Date: Thu, 08 Jan 1998 12:08:59 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199801080156.RAA15885@chimp.juniper.net>, Tony Li writes: > > | We're sending it to the IESG because it is a protocol spec and we > | think it should be implemented. That's sort of the implied message to > | vendors in sending any protocol spec to the IESG. If IPSEC seriously > | flounders maybe it will be around long enough to go from PS to DS. > | > | You've made your point clear that the IESG is not a message passing > | system. Was that the limit of your point, or are you also arguing > | against sending the draft to IESG for consideration as PS? > > Both points. I see we will have to disagree. The IESG is not even an > implied message passing system. > > I'll also point out that BCP makes _much_ more sense that PS. > > Tony I think we can all see reasons to got with BCP or PS and we talked about this at the WG meeting in DC. We ended up with PS though no one felt extremely strongly about it either way. If you feel strongly enough that it should be BCP rather than PS please tell the WG chairs you want them to override the decision made at the WG meeting that you were at. Either way is OK with me though I'd prefer to stick with what we agreed to do. Over and out, Curtis Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id JAA15876 for ; Thu, 8 Jan 1998 09:24:45 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA17139 for idr-outgoing; Thu, 8 Jan 1998 09:20:20 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA17135 for ; Thu, 8 Jan 1998 09:20:16 -0500 (EST) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id JAA12780; Thu, 8 Jan 1998 09:20:13 -0500 (EST) Received: by relay.hq.tis.com; id JAA16476; Thu, 8 Jan 1998 09:18:42 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma016460; Thu, 8 Jan 98 09:18:34 -0500 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id JAA03637; Thu, 8 Jan 1998 09:19:19 -0500 (EST) Date: Thu, 8 Jan 1998 09:19:19 -0500 (EST) From: Sandy Murphy Message-Id: <199801081419.JAA03637@clipper.hq.tis.com> To: curtis@ans.net, prz@dnrc.bell-labs.com Subject: Re: WG Last Call Cc: bgp@ans.net, sandy@tis.com, tli@juniper.net Sender: owner-idr@merit.edu Precedence: bulk >Message is OK, I don't see necessarily that something with known deficiencies >should go >into PS to increase its value "known deficiencies"??!!! Could you please explain this further? I don't recall deficiencies in this mechanism being mentioned yet. If you know of some, please speak up. As soon as possible. Or point me to the right message. --Sandy Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id VAA10374 for ; Wed, 7 Jan 1998 21:06:43 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA09871 for idr-outgoing; Wed, 7 Jan 1998 21:04:47 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA09867 for ; Wed, 7 Jan 1998 21:04:40 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id VAA29145; Wed, 7 Jan 1998 21:04:01 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jan 7 21:03:03 EST 1998 Received: from dnrc.bell-labs.com (root@prz-laptop [135.180.130.120]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA27157; Wed, 7 Jan 1998 21:02:59 -0500 (EST) Message-ID: <34B432B8.DED17065@dnrc.bell-labs.com> Date: Wed, 07 Jan 1998 20:58:16 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) MIME-Version: 1.0 To: curtis@ans.net CC: Tony Li , bgp@ans.net Subject: Re: WG Last Call References: <199801080027.TAA16693@brookfield.ans.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Curtis Villamizar wrote: > In message <34B3CE78.13117CC7@dnrc.bell-labs.com>, Antoni Przygienda writes: > > Tony Li wrote: > > > > > curtis@brookfield.ans.net (Curtis Villamizar) writes: > > > > > > > IMO: Making it PS sends the right message to router vendors. YOU NEED > > > > TO IMPLEMENT THIS! Making it informational carries no weight. > > > > > > If you want to send a message, use Federal Express. > > > > > > You want to convince vendors? Use your dollars. > > > > > > Anyone who still thinks that a PS has any weight with a vendor is stuck > > > living in 1990. An RFC, regardless of its 'standard' status, is a > > > reference document. Nothing more. The IETF is a publishing house that > > > also has a lot of irrelevant political and marketing dog and pony shows. > > > > on the same note ;-) > > > > I remember the IETF T-shirt saying "We despise kings, .... " and so on. > > Making something > > PS to "force" router vendors to do stuff smells like a benevolent > > dictatorship ;-) > > > > thank you > > > > --- tony > > I said "sends the right message". I didn't claim you could force > anybody to do anything. > Curtis, I always sense some force when people jam the caps lock in their mails ;-) but technically yes, you didn't say it, I'll be forgiven ... > Are you (both Tonys) 1) disagreeing that this is the right message, 2) > disagreeing that we should send as strong a message as this feeble > IETF WG can, 3) making some other point, or 4) adding to the noise? > > Yes I see the smiley and I'm not offended and you shouldn't be either. > :-) > Message is OK, I don't see necessarily that something with known deficiencies should go into PS to increase its value, BCP would be probably just fine and generally at this point I don't think the discussion is worth having .... I'll be excused. thank you --- tony Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id UAA10317 for ; Wed, 7 Jan 1998 20:58:56 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA09770 for idr-outgoing; Wed, 7 Jan 1998 20:57:19 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA09766 for ; Wed, 7 Jan 1998 20:57:14 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id UAA28530; Wed, 7 Jan 1998 20:57:00 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA09764; Wed, 7 Jan 1998 17:56:23 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id RAA15885; Wed, 7 Jan 1998 17:56:23 -0800 (PST) Date: Wed, 7 Jan 1998 17:56:23 -0800 (PST) Message-Id: <199801080156.RAA15885@chimp.juniper.net> From: Tony Li To: curtis@ans.net CC: curtis@ans.net, prz@dnrc.bell-labs.com, bgp@ans.net In-reply-to: <199801080150.UAA17314@brookfield.ans.net> (message from Curtis Villamizar on Wed, 07 Jan 1998 20:50:46 -0500) Subject: Re: WG Last Call Sender: owner-idr@merit.edu Precedence: bulk | We're sending it to the IESG because it is a protocol spec and we | think it should be implemented. That's sort of the implied message to | vendors in sending any protocol spec to the IESG. If IPSEC seriously | flounders maybe it will be around long enough to go from PS to DS. | | You've made your point clear that the IESG is not a message passing | system. Was that the limit of your point, or are you also arguing | against sending the draft to IESG for consideration as PS? Both points. I see we will have to disagree. The IESG is not even an implied message passing system. I'll also point out that BCP makes _much_ more sense that PS. Tony Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id UAA10294 for ; Wed, 7 Jan 1998 20:53:17 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA09679 for idr-outgoing; Wed, 7 Jan 1998 20:50:57 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA09674 for ; Wed, 7 Jan 1998 20:50:52 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id UAA28380; Wed, 7 Jan 1998 20:50:51 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id UAA17314; Wed, 7 Jan 1998 20:50:46 -0500 (EST) Message-Id: <199801080150.UAA17314@brookfield.ans.net> To: Tony Li cc: curtis@ans.net, prz@dnrc.bell-labs.com, bgp@ans.net Reply-To: curtis@ans.net Subject: Re: WG Last Call In-reply-to: Your message of "Wed, 07 Jan 1998 16:31:20 PST." <199801080031.QAA15169@chimp.juniper.net> Date: Wed, 07 Jan 1998 20:50:46 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199801080031.QAA15169@chimp.juniper.net>, Tony Li writes: > > | Are you (both Tonys) 1) disagreeing that this is the right message, 2) > | disagreeing that we should send as strong a message as this feeble > | IETF WG can, 3) making some other point, or 4) adding to the noise? > > I'm trying to make the point that making the document PS is wholly > orthogonal to sending a message. Thus, if that's your reason for making it > PS, it's misguided and you're wasting people's time (e.g., the IESG's for > reviewing it) for no purpose. > > Tony Tony, We're sending it to the IESG because it is a protocol spec and we think it should be implemented. That's sort of the implied message to vendors in sending any protocol spec to the IESG. If IPSEC seriously flounders maybe it will be around long enough to go from PS to DS. You've made your point clear that the IESG is not a message passing system. Was that the limit of your point, or are you also arguing against sending the draft to IESG for consideration as PS? Curtis Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id TAA09648 for ; Wed, 7 Jan 1998 19:34:34 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA08387 for idr-outgoing; Wed, 7 Jan 1998 19:32:55 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA08372 for ; Wed, 7 Jan 1998 19:32:42 -0500 (EST) Received: from red.juniper.net ([208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id TAA23491; Wed, 7 Jan 1998 19:32:33 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA07939; Wed, 7 Jan 1998 16:31:20 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id QAA15169; Wed, 7 Jan 1998 16:31:20 -0800 (PST) Date: Wed, 7 Jan 1998 16:31:20 -0800 (PST) Message-Id: <199801080031.QAA15169@chimp.juniper.net> From: Tony Li To: curtis@ans.net CC: prz@dnrc.bell-labs.com, tli@juniper.net, curtis@ans.net, bgp@ans.net In-reply-to: <199801080027.TAA16693@brookfield.ans.net> (message from Curtis Villamizar on Wed, 07 Jan 1998 19:27:52 -0500) Subject: Re: WG Last Call Sender: owner-idr@merit.edu Precedence: bulk | Are you (both Tonys) 1) disagreeing that this is the right message, 2) | disagreeing that we should send as strong a message as this feeble | IETF WG can, 3) making some other point, or 4) adding to the noise? I'm trying to make the point that making the document PS is wholly orthogonal to sending a message. Thus, if that's your reason for making it PS, it's misguided and you're wasting people's time (e.g., the IESG's for reviewing it) for no purpose. Tony Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id TAA09606 for ; Wed, 7 Jan 1998 19:30:46 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA08249 for idr-outgoing; Wed, 7 Jan 1998 19:28:15 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA08245 for ; Wed, 7 Jan 1998 19:28:10 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id TAA23206; Wed, 7 Jan 1998 19:28:09 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id TAA16693; Wed, 7 Jan 1998 19:27:53 -0500 (EST) Message-Id: <199801080027.TAA16693@brookfield.ans.net> To: Antoni Przygienda cc: Tony Li , curtis@ans.net, bgp@ans.net Reply-To: curtis@ans.net Subject: Re: WG Last Call In-reply-to: Your message of "Wed, 07 Jan 1998 13:50:32 EST." <34B3CE78.13117CC7@dnrc.bell-labs.com> Date: Wed, 07 Jan 1998 19:27:52 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <34B3CE78.13117CC7@dnrc.bell-labs.com>, Antoni Przygienda writes: > Tony Li wrote: > > > curtis@brookfield.ans.net (Curtis Villamizar) writes: > > > > > IMO: Making it PS sends the right message to router vendors. YOU NEED > > > TO IMPLEMENT THIS! Making it informational carries no weight. > > > > If you want to send a message, use Federal Express. > > > > You want to convince vendors? Use your dollars. > > > > Anyone who still thinks that a PS has any weight with a vendor is stuck > > living in 1990. An RFC, regardless of its 'standard' status, is a > > reference document. Nothing more. The IETF is a publishing house that > > also has a lot of irrelevant political and marketing dog and pony shows. > > on the same note ;-) > > I remember the IETF T-shirt saying "We despise kings, .... " and so on. > Making something > PS to "force" router vendors to do stuff smells like a benevolent > dictatorship ;-) > > thank you > > --- tony I said "sends the right message". I didn't claim you could force anybody to do anything. Are you (both Tonys) 1) disagreeing that this is the right message, 2) disagreeing that we should send as strong a message as this feeble IETF WG can, 3) making some other point, or 4) adding to the noise? Yes I see the smiley and I'm not offended and you shouldn't be either. :-) Curtis Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id RAA08244 for ; Wed, 7 Jan 1998 17:22:52 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA05905 for idr-outgoing; Wed, 7 Jan 1998 17:19:07 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA05901 for ; Wed, 7 Jan 1998 17:18:48 -0500 (EST) Received: from botafogo.ci.rnp.br (botafogo.ci.rnp.br [200.17.63.107]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id RAA14314 for ; Wed, 7 Jan 1998 17:18:42 -0500 (EST) Received: from botafogo (botafogo [200.17.63.107]) by botafogo.ci.rnp.br (8.8.7/8.8.7) with SMTP id UAA11664 for ; Wed, 7 Jan 1998 20:19:01 -0200 (EDT) Date: Wed, 7 Jan 1998 20:19:00 -0200 (EDT) From: Reinaldo Penno Filho X-Sender: reinaldo@botafogo To: bgp@ans.net Subject: Re: How is a "route" defined? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by merit.edu id RAA05902 Sender: owner-idr@merit.edu Precedence: bulk On Thu, 11 Dec 1997, Ken Rosenfeld wrote: vc>In the context of route dampening, how is a "route" defined? vc> vc> states (p. 13): vc> "A route here is considered to be a tuple containing at least vc> NLRI prefix, next hop, and AS path." vc> Hi, Sorry if this is a newbie question but I´m having a hard time understanding the difference between a Route, NLRI and their relation to UPDATE messages. In the is said: --> For purposes of this protocol a route is defined as a unit of information that pairs **a** destination with the attributes of a path that destination: <-- -->An UPDATE message is used to advertise a *single* feasible route<-- Does "a destination" means one AS or NLRI<->path attribute information? Cause if a destination is one NLRI seems to me that a UPDATE message can advertise several routes.. Or.. Does this mean that a collection of NLRIs and their path attributes is a *single* route, even tough some NLRI<-> path attributes tuples advertise different destinations (networks)? Something like this... NLRI 1 --\ \ NLRI 2 ---- Path Attributes / NLRI 3 --/ (NLRI 1, Path At.) (NLRI 2, Path At.) (NLRI 3, Path At.) A many to one relationship. So another update message to the same AS with the same NLRI but other path attribute is another route? Sorry for the long and possible intricate message... Best Regards, Reinaldo ---------------------------------------------------------------------------- Brazilian Reserch Network http://www.rnp.br reinaldo@co.rnp.br ---------------------------------------------------------------------------- Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id PAA07077 for ; Wed, 7 Jan 1998 15:14:24 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA02980 for idr-outgoing; Wed, 7 Jan 1998 15:09:28 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA02975 for ; Wed, 7 Jan 1998 15:09:21 -0500 (EST) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id OAA01858 for ; Wed, 7 Jan 1998 14:54:41 -0500 (EST) Received: by relay.hq.tis.com; id OAA22767; Wed, 7 Jan 1998 14:53:11 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma022724; Wed, 7 Jan 98 14:52:16 -0500 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id OAA14647; Wed, 7 Jan 1998 14:53:01 -0500 (EST) Date: Wed, 7 Jan 1998 14:53:01 -0500 (EST) From: Sandy Murphy Message-Id: <199801071953.OAA14647@clipper.hq.tis.com> To: prz@dnrc.bell-labs.com Subject: Re: WG Last Call Cc: bgp@ans.net, sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk >> > IMO: Making it PS sends the right message to router vendors. YOU NEED >> > TO IMPLEMENT THIS! Making it informational carries no weight. >... >Making something >PS to "force" router vendors to do stuff smells like a benevolent >dictatorship ;-) I don't hear any hint of force in "sends the right message" and "YOU NEED TO IMPLEMENT THIS". Sounds more like good advice or strong suggestion than force. --Sandy Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA06073 for ; Wed, 7 Jan 1998 14:03:12 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA01826 for idr-outgoing; Wed, 7 Jan 1998 13:57:49 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA01822 for ; Wed, 7 Jan 1998 13:57:32 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id NAA27079; Wed, 7 Jan 1998 13:56:01 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jan 7 13:55:11 EST 1998 Received: from dnrc.bell-labs.com (root@prz-laptop [135.180.130.120]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id NAA13091; Wed, 7 Jan 1998 13:55:10 -0500 (EST) Message-ID: <34B3CE78.13117CC7@dnrc.bell-labs.com> Date: Wed, 07 Jan 1998 13:50:32 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) MIME-Version: 1.0 To: Tony Li CC: curtis@ans.net, bgp@ans.net Subject: Re: WG Last Call References: <199801061708.MAA11030@brookfield.ans.net> <821zyky44u.fsf@chimp.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Tony Li wrote: > curtis@brookfield.ans.net (Curtis Villamizar) writes: > > > IMO: Making it PS sends the right message to router vendors. YOU NEED > > TO IMPLEMENT THIS! Making it informational carries no weight. > > If you want to send a message, use Federal Express. > > You want to convince vendors? Use your dollars. > > Anyone who still thinks that a PS has any weight with a vendor is stuck > living in 1990. An RFC, regardless of its 'standard' status, is a > reference document. Nothing more. The IETF is a publishing house that > also has a lot of irrelevant political and marketing dog and pony shows. on the same note ;-) I remember the IETF T-shirt saying "We despise kings, .... " and so on. Making something PS to "force" router vendors to do stuff smells like a benevolent dictatorship ;-) thank you --- tony Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id IAA02779 for ; Wed, 7 Jan 1998 08:19:53 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA25443 for idr-outgoing; Wed, 7 Jan 1998 08:17:48 -0500 (EST) Received: from botafogo.ci.rnp.br (botafogo.ci.rnp.br [200.17.63.107]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA25420 for ; Wed, 7 Jan 1998 08:14:25 -0500 (EST) Received: from botafogo (botafogo [200.17.63.107]) by botafogo.ci.rnp.br (8.8.7/8.8.7) with SMTP id LAA09445; Wed, 7 Jan 1998 11:14:18 -0200 (EDT) Date: Wed, 7 Jan 1998 11:14:18 -0200 (EDT) From: Reinaldo Penno Filho X-Sender: reinaldo@botafogo To: idr@merit.edu cc: Alexandre Subject: Re: How is a "route" defined? In-Reply-To: <9712111632.ZM17141@ptcmtls1.montreal.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by merit.edu id IAA25438 Sender: owner-idr@merit.edu Precedence: bulk On Thu, 11 Dec 1997, Ken Rosenfeld wrote: vc>In the context of route dampening, how is a "route" defined? vc> vc> states (p. 13): vc> "A route here is considered to be a tuple containing at least vc> NLRI prefix, next hop, and AS path." vc> Hi, Sorry if this is a newbie question but I´m having a hard time understanding the difference between a Route, NLRI and their relation to UPDATE messages. In the is said: --> For purposes of this protocol a route is defined as a unit of information that pairs **a** destination with the attributes of a path that destination: <-- -->An UPDATE message is used to advertise a *single* feasible route<-- Does "a destination" means one AS or NLRI<->path attribute information? Cause if a destination is one NLRI seems to me that a UPDATE message can advertise several routes.. Or.. Does this mean that a collection of NLRIs and their path attributes is a *single* route, even tough some NLRI<-> path attributes tuples advertise different destinations (networks)? Something like this... NLRI 1 --\ \ NLRI 2 ---- Path Attributes / NLRI 3 --/ (NLRI 1, Path At.) (NLRI 2, Path At.) (NLRI 3, Path At.) A many to one relationship. So another update message to the same AS with the same NLRI but other path attribute is another route? Sorry for the long and possible intricate message... Best Regards, Reinaldo ---------------------------------------------------------------------------- Brazilian Reserch Network http://www.rnp.br reinaldo@co.rnp.br ---------------------------------------------------------------------------- Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id FAA01715 for ; Wed, 7 Jan 1998 05:31:07 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA24302 for idr-outgoing; Wed, 7 Jan 1998 05:23:49 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA24298 for ; Wed, 7 Jan 1998 05:23:45 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id FAA24733; Wed, 7 Jan 1998 05:23:43 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id CAA21185; Wed, 7 Jan 1998 02:23:12 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id CAA13500; Wed, 7 Jan 1998 02:23:13 -0800 (PST) To: curtis@ans.net cc: bgp@ans.net Subject: Re: WG Last Call References: <199801061708.MAA11030@brookfield.ans.net> From: Tony Li Date: 07 Jan 1998 02:23:13 -0800 In-Reply-To: curtis@brookfield.ans.net's message of 6 Jan 98 17:08:02 GMT Message-ID: <821zyky44u.fsf@chimp.juniper.net> Lines: 16 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-idr@merit.edu Precedence: bulk curtis@brookfield.ans.net (Curtis Villamizar) writes: > IMO: Making it PS sends the right message to router vendors. YOU NEED > TO IMPLEMENT THIS! Making it informational carries no weight. If you want to send a message, use Federal Express. You want to convince vendors? Use your dollars. Anyone who still thinks that a PS has any weight with a vendor is stuck living in 1990. An RFC, regardless of its 'standard' status, is a reference document. Nothing more. The IETF is a publishing house that also has a lot of irrelevant political and marketing dog and pony shows. Cynically yours, Tony Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA23082 for ; Tue, 6 Jan 1998 12:11:46 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA08338 for idr-outgoing; Tue, 6 Jan 1998 12:08:16 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA08332 for ; Tue, 6 Jan 1998 12:08:10 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id MAA25939 for ; Tue, 6 Jan 1998 12:08:08 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id MAA11030; Tue, 6 Jan 1998 12:08:02 -0500 (EST) Message-Id: <199801061708.MAA11030@brookfield.ans.net> To: Joel Halpern cc: Yakov Rekhter , bgp@ans.net Reply-To: curtis@ans.net Subject: Re: WG Last Call In-reply-to: Your message of "Tue, 23 Dec 1997 11:36:13 EST." Date: Tue, 06 Jan 1998 12:08:02 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message , Joel Halpern writ es: > I have a question for the working group about this advancement. > First, let me state that I understand that what is described here is in > use and works. > > On the other hand, judging from other factors, the desired direction would > be to support IPsec, when that is deployed (deployable? take your pick). > > Clearly, document this (MD5 TCP Shim) is a good thing, and we should have > it. > The question I see is whether proposed standard is the correct status for > this document. Given that it works, "Experimental" is wrong since that > would imply that it might not work. > However, Informational would seem a better general category. One might > object that in fact we want a stronger imprimature than informational. > Would BCP be suitable? Would an Informational document with a BCP > applicability statement be better? > Or can someone make a good case for proposed status? If we accept that > IPsec is the long term way to go, then we do not expect to advance this up > the standards track. Making a PS with the hope of making it historic > seems odd to me. Joel, IMO: Making it PS sends the right message to router vendors. YOU NEED TO IMPLEMENT THIS! Making it informational carries no weight. It was agreed at the WG meeting that PS to historic did make sense due to the importance of doing something immediately to protect against attacks such as TCP RST and then later doing IPSEC when IPSEC is widely deployed and going to historic when IPSEC is ubiquitous. Curtis Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA10748 for ; Mon, 5 Jan 1998 10:56:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA16307 for idr-outgoing; Mon, 5 Jan 1998 10:50:52 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA16303 for ; Mon, 5 Jan 1998 10:50:45 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id KAA06638 for ; Mon, 5 Jan 1998 10:50:44 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id HAA16921; Mon, 5 Jan 1998 07:49:54 -0800 Message-Id: <199801051549.HAA16921@puli.cisco.com> To: jhalpern@newbridge.com cc: bgp@ans.net Subject: draft-ietf-idr-bgp4-ipv6-00.txt Date: Mon, 05 Jan 98 07:49:54 PST From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Joel, The IDR WG would like to ask the IESG to advance draft-ietf-idr-bgp4-ipv6-00.txt to a Proposed Standard. Yakov.