From mailman-admin@ietf.org Mon Sep 1 23:02:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05588 for ; Mon, 1 Sep 2003 23:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1Rd-00064N-00 for idr-archive@ietf.org; Mon, 01 Sep 2003 23:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u1RL-000675-00 for idr-archive@ietf.org; Mon, 01 Sep 2003 23:02:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toJc-0007Fo-Jw for idr-archive@ietf.org; Mon, 01 Sep 2003 09:01:52 -0400 Date: Mon, 01 Sep 2003 09:01:52 -0400 Message-ID: <20030901130152.21711.51433.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: idr-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, idr-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for idr-archive@ietf.org: List Password // URL ---- -------- idr@ietf.org omkeeh https://www1.ietf.org/mailman/options/idr/idr-archive%40ietf.org From exim@www1.ietf.org Tue Sep 2 09:42:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25168 for ; Tue, 2 Sep 2003 09:42:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u67e-0007Fb-Jv for idr-archive@odin.ietf.org; Tue, 02 Sep 2003 04:02:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8282gDt027859 for idr-archive@odin.ietf.org; Tue, 2 Sep 2003 04:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u0mW-0008IW-LG for idr-web-archive@optimus.ietf.org; Mon, 01 Sep 2003 22:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24231 for ; Mon, 1 Sep 2003 22:20:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u0dW-00057r-00 for idr-web-archive@ietf.org; Mon, 01 Sep 2003 22:11:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19twTA-0005fm-00 for idr-web-archive@ietf.org; Mon, 01 Sep 2003 17:44:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toQe-00032D-Nf for idr-web-archive@ietf.org; Mon, 01 Sep 2003 09:09:08 -0400 Date: Mon, 01 Sep 2003 09:09:08 -0400 Message-ID: <20030901130908.21711.20222.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: idr-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, idr-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for idr-web-archive@ietf.org: List Password // URL ---- -------- idr@ietf.org ginaip https://www1.ietf.org/mailman/options/idr/idr-web-archive%40ietf.org From owner-idr@merit.edu Tue Sep 2 11:26:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07261 for ; Tue, 2 Sep 2003 11:26:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uD3Q-0004vW-00 for idr-archive@ietf.org; Tue, 02 Sep 2003 11:26:48 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19uD3P-0004uz-00 for idr-archive@ietf.org; Tue, 02 Sep 2003 11:26:47 -0400 Received: by trapdoor.merit.edu (Postfix) id 6BB339126B; Tue, 2 Sep 2003 11:26:32 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B6679126D; Tue, 2 Sep 2003 11:26:31 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70D2C9126B for ; Tue, 2 Sep 2003 11:26:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 534535DDE2; Tue, 2 Sep 2003 11:26:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint2.juniper.net [207.17.136.150]) by segue.merit.edu (Postfix) with ESMTP id C6E185DD8C for ; Tue, 2 Sep 2003 11:26:29 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h82FQTY90754 for ; Tue, 2 Sep 2003 08:26:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309021526.h82FQTY90754@merlot.juniper.net> To: idr@merit.edu Subject: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51613.1062516389.1@juniper.net> Date: Tue, 02 Sep 2003 08:26:29 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start the WG Last Call on advacing draft-ietf-idr-bgp4-experience-protocol-01.txt to an Informational RFC. The Last Call ends Sep 16, 2003. Yakov. ------- Forwarded Message Date: Wed, 27 Aug 2003 10:27:11 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-01.txt - --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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-01.txt Pages : 18 Date : 2003-8-27 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-01. txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-27103600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-01.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-27103600.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-idr@merit.edu Thu Sep 4 11:36:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02906 for ; Thu, 4 Sep 2003 11:36:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uw9i-0006Bw-00 for idr-archive@ietf.org; Thu, 04 Sep 2003 11:36:18 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19uw9h-0006BW-00 for idr-archive@ietf.org; Thu, 04 Sep 2003 11:36:17 -0400 Received: by trapdoor.merit.edu (Postfix) id A54DD912DA; Thu, 4 Sep 2003 11:33:20 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB3E0912E7; Thu, 4 Sep 2003 11:33:17 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4051912DA for ; Thu, 4 Sep 2003 11:31:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A3F25DD8E; Thu, 4 Sep 2003 11:31:17 -0400 (EDT) Delivered-To: idr@merit.edu Received: from state.arbornetworks.com (state.arbornetworks.com [204.181.64.20]) by segue.merit.edu (Postfix) with ESMTP id AFA125DDF2 for ; Thu, 4 Sep 2003 11:31:16 -0400 (EDT) Received: from tcb.net (bedford.lex.arbor.net [204.118.128.2]) by state.arbornetworks.com (Arbor Networks mail relay) with ESMTP id C75E0633DA; Thu, 4 Sep 2003 11:31:15 -0400 (EDT) Date: Thu, 4 Sep 2003 09:31:13 -0600 Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: idr@merit.edu To: Erblichs From: Danny McPherson In-Reply-To: <3F5663C3.1C96E741@earthlink.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, September 3, 2003, at 03:57 PM, Erblichs wrote: 1-5: fixed! > 6) 8. Internal BGP in Large ... > > "with a large number of peers" > > Should this be specified? with the number of peers > greater than "X" I'm not sure X can be defined, as it's relative. I think it's probably OK as is. > > RFC 2065 not in References Should have been 3065. 7-12: fixed! > ------------------ > > B) Non-nits > 1-4: Added some text to address each of these, it should be sufficient. Great feedback, thanks! -danny From owner-idr@merit.edu Thu Sep 4 11:48:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03622 for ; Thu, 4 Sep 2003 11:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uwLB-0006Rx-00 for idr-archive@ietf.org; Thu, 04 Sep 2003 11:48:09 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19uwLA-0006RY-00 for idr-archive@ietf.org; Thu, 04 Sep 2003 11:48:08 -0400 Received: by trapdoor.merit.edu (Postfix) id E0675912D8; Thu, 4 Sep 2003 11:45:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29B8291312; Thu, 4 Sep 2003 11:45:45 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A0459131C for ; Thu, 4 Sep 2003 11:45:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1777A5DDC3; Thu, 4 Sep 2003 11:45:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.avici.com (unknown [12.38.212.174]) by segue.merit.edu (Postfix) with ESMTP id 8EF995DDBE for ; Thu, 4 Sep 2003 11:45:39 -0400 (EDT) Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h84FjBmO031633; Thu, 4 Sep 2003 11:45:12 -0400 Message-Id: <200309041545.h84FjBmO031633@mail.avici.com> To: Danny McPherson Cc: Erblichs , idr@merit.edu Reply-To: curtis@fictitious.org Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt In-reply-to: Your message of "Thu, 04 Sep 2003 09:31:13 MDT." Date: Thu, 04 Sep 2003 11:48:39 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message , Danny McPherson writ es: > > > 6) 8. Internal BGP in Large ... > > > > "with a large number of peers" > > > > Should this be specified? with the number of peers > > greater than "X" > > I'm not sure X can be defined, as it's relative. I think it's > probably OK as is. The value of X varies with implementation but there is always some practical limit. You could put a sentence in stating that. Curtis From owner-idr@merit.edu Thu Sep 4 11:59:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04301 for ; Thu, 4 Sep 2003 11:59:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uwVl-0006hM-00 for idr-archive@ietf.org; Thu, 04 Sep 2003 11:59:05 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19uwVk-0006gz-00 for idr-archive@ietf.org; Thu, 04 Sep 2003 11:59:04 -0400 Received: by trapdoor.merit.edu (Postfix) id EEB6C91216; Thu, 4 Sep 2003 11:58:52 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA9A3912CF; Thu, 4 Sep 2003 11:58:51 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C296891216 for ; Thu, 4 Sep 2003 11:58:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B0FB15DDEA; Thu, 4 Sep 2003 11:58:50 -0400 (EDT) Delivered-To: idr@merit.edu Received: from state.arbornetworks.com (state.arbornetworks.com [204.181.64.20]) by segue.merit.edu (Postfix) with ESMTP id 8BF6C5DDC3 for ; Thu, 4 Sep 2003 11:58:50 -0400 (EDT) Received: from tcb.net (bedford.lex.arbor.net [204.118.128.2]) by state.arbornetworks.com (Arbor Networks mail relay) with ESMTP id C5D766354F for ; Thu, 4 Sep 2003 11:58:49 -0400 (EDT) Date: Thu, 4 Sep 2003 09:58:48 -0600 Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: idr@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200309041545.h84FjBmO031633@mail.avici.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > The value of X varies with implementation but there is always some > practical limit. You could put a sentence in stating that. OK, I'll add something to that effect.. -danny From owner-idr@merit.edu Mon Sep 8 06:53:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09907 for ; Mon, 8 Sep 2003 06:53:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wJe1-00057z-00 for idr-archive@ietf.org; Mon, 08 Sep 2003 06:53:17 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19wJe0-000572-00 for idr-archive@ietf.org; Mon, 08 Sep 2003 06:53:17 -0400 Received: by trapdoor.merit.edu (Postfix) id 2E9C391257; Mon, 8 Sep 2003 06:53:03 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E850C91258; Mon, 8 Sep 2003 06:53:02 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD8ED91257 for ; Mon, 8 Sep 2003 06:53:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96B855DDE1; Mon, 8 Sep 2003 06:53:01 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 25CED5DDD0 for ; Mon, 8 Sep 2003 06:52:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09884; Mon, 8 Sep 2003 06:52:49 -0400 (EDT) Message-Id: <200309081052.GAA09884@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Date: Mon, 08 Sep 2003 06:52:48 -0400 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 : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : J. Haas, S. Hares Filename : draft-ietf-idr-bgp4-mib-12.txt Pages : 35 Date : 2003-9-5 This memo is an extension to the SNMP MIB. The origin of this memo is from RFC 1269 'Definitions of Managed Objects for the Border Gateway Protocol (Version 3)', which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB was converted to use the SNMPv2 SMI, as well as updates references to the current SNMP framework documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-mib-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-5130848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-5130848.I-D@ietf.org> --OtherAccess-- --NextPart-- From idr-admin@ietf.org Mon Sep 8 18:02:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24034; Mon, 8 Sep 2003 18:02:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wU5T-0001Eb-00; Mon, 08 Sep 2003 18:02:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wU5S-0001EV-00; Mon, 08 Sep 2003 18:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wU4Q-0008WV-5p; Mon, 08 Sep 2003 18:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wU43-0008VE-8q for idr@optimus.ietf.org; Mon, 08 Sep 2003 18:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23954 for ; Mon, 8 Sep 2003 18:00:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wU40-0001DG-00 for idr@ietf.org; Mon, 08 Sep 2003 18:00:48 -0400 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 19wU3z-0001DD-00 for idr@ietf.org; Mon, 08 Sep 2003 18:00:47 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h88M0hr09919 for ; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) Received: from coors.torrentnet.com (coors.torrentnet.com [4.21.152.11]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h88M0h689918 for ; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) Received: (from kaarthik@localhost) by coors.torrentnet.com (8.11.2/8.11.2) id h88M0hR33090; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) X-Authentication-Warning: coors.torrentnet.com: kaarthik set sender to kaarthik@torrentnet.com using -f To: IDR mailing list From: Kaarthik Sivakumar Message-ID: <1iy8wzhrec.fsf@coors.torrentnet.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.1 (Channel Islands, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Idr] graceful restart vs flap dampening Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Sep 2003 18:00:43 -0400 I am interested in how route flap dampening would interact with graceful restart. Should stale routes be considered flapping and the figure of merit appropriately increased? Should this be done when the peer goes down or when the peer comes back up and doesnt readvertise one of the stale routes, thus forcing the route to be withdrawn from the listening speaker's forwarding? The graceful restart draft doesnt refer to this interaction. In my view, the figure of merit for the route should only be affected when the restarting speaker comes up and doesnt readvertise the stale route. Maybe this is clear from the draft and the route flap dampening rfc and I just missed it. If so, let me know what I am missing. Otherwise I would suggest some text in the graceful restart draft about this interaction. Thanks.. kaarthik _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 9 00:40:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07203; Tue, 9 Sep 2003 00:40:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waHN-00035q-Im; Tue, 09 Sep 2003 00:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waGc-00035J-Am for idr@optimus.ietf.org; Tue, 09 Sep 2003 00:38:14 -0400 Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07148 for ; Tue, 9 Sep 2003 00:38:00 -0400 (EDT) Received: from tcb.net (dhcp64-134-59-85.wgb.bos.wayport.net [64.134.59.85]) by dog.tcb.net (Postfix) with ESMTP id 3CCAB20299 for ; Mon, 8 Sep 2003 22:36:52 -0600 (MDT) Subject: Re: [Idr] graceful restart vs flap dampening Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: IDR mailing list Content-Transfer-Encoding: 7bit In-Reply-To: <1iy8wzhrec.fsf@coors.torrentnet.com> Message-Id: <3BCC1452-E27F-11D7-86AC-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Sep 2003 22:36:52 -0600 Content-Transfer-Encoding: 7bit On Monday, September 8, 2003, at 04:00 PM, Kaarthik Sivakumar wrote: > I am interested in how route flap dampening would interact with > graceful restart. Should stale routes be considered flapping and the > figure of merit appropriately increased? Should this be done when the > peer goes down or when the peer comes back up and doesnt readvertise > one of the stale routes, Only the latter (as usual), IMO. Else you scope the usefulness of graceful restart. > thus forcing the route to be withdrawn from > the listening speaker's forwarding? The graceful restart draft doesnt > refer to this interaction. I don't believe it should, as the functionality is clearly orthogonal. > In my view, the figure of merit for the route should only be affected > when the restarting speaker comes up and doesnt readvertise the stale > route. Maybe this is clear from the draft and the route flap dampening > rfc and I just missed it. If so, let me know what I am missing. > Otherwise I would suggest some text in the graceful restart draft > about this interaction. I don't believe you're missing anything, this is implied behavior. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 9 00:42:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07285 for ; Tue, 9 Sep 2003 00:42:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waKH-0003Fy-01 for idr-archive@odin.ietf.org; Tue, 09 Sep 2003 00:42:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h894g0vY012512 for idr-archive@odin.ietf.org; Tue, 9 Sep 2003 00:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waKG-0003Fi-Rd for idr-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 00:42:00 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07203; Tue, 9 Sep 2003 00:40:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waHN-00035q-Im; Tue, 09 Sep 2003 00:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waGc-00035J-Am for idr@optimus.ietf.org; Tue, 09 Sep 2003 00:38:14 -0400 Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07148 for ; Tue, 9 Sep 2003 00:38:00 -0400 (EDT) Received: from tcb.net (dhcp64-134-59-85.wgb.bos.wayport.net [64.134.59.85]) by dog.tcb.net (Postfix) with ESMTP id 3CCAB20299 for ; Mon, 8 Sep 2003 22:36:52 -0600 (MDT) Subject: Re: [Idr] graceful restart vs flap dampening Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: IDR mailing list Content-Transfer-Encoding: 7bit In-Reply-To: <1iy8wzhrec.fsf@coors.torrentnet.com> Message-Id: <3BCC1452-E27F-11D7-86AC-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Sep 2003 22:36:52 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday, September 8, 2003, at 04:00 PM, Kaarthik Sivakumar wrote: > I am interested in how route flap dampening would interact with > graceful restart. Should stale routes be considered flapping and the > figure of merit appropriately increased? Should this be done when the > peer goes down or when the peer comes back up and doesnt readvertise > one of the stale routes, Only the latter (as usual), IMO. Else you scope the usefulness of graceful restart. > thus forcing the route to be withdrawn from > the listening speaker's forwarding? The graceful restart draft doesnt > refer to this interaction. I don't believe it should, as the functionality is clearly orthogonal. > In my view, the figure of merit for the route should only be affected > when the restarting speaker comes up and doesnt readvertise the stale > route. Maybe this is clear from the draft and the route flap dampening > rfc and I just missed it. If so, let me know what I am missing. > Otherwise I would suggest some text in the graceful restart draft > about this interaction. I don't believe you're missing anything, this is implied behavior. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 9 11:00:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15343; Tue, 9 Sep 2003 11:00:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjyT-00050F-00; Tue, 09 Sep 2003 11:00:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wjyS-00050B-00; Tue, 09 Sep 2003 11:00:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjxN-0002Eo-8p; Tue, 09 Sep 2003 10:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjwo-0002EC-CR for idr@optimus.ietf.org; Tue, 09 Sep 2003 10:58:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15172 for ; Tue, 9 Sep 2003 10:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjwZ-0004xf-00 for idr@ietf.org; Tue, 09 Sep 2003 10:58:11 -0400 Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx with esmtp (Exim 4.12) id 19wjwY-0004xU-00 for idr@ietf.org; Tue, 09 Sep 2003 10:58:11 -0400 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h89F0Yhs020036 for ; Tue, 9 Sep 2003 08:00:34 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h89Ew4o00340 for ; Tue, 9 Sep 2003 07:58:04 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs X-Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h88JBxm08630; Mon, 8 Sep 2003 12:11:59 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Jeffrey Haas cc: IDR WG , "Wijnen, Bert (Bert)" In-Reply-To: <200309081052.GAA09884@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Tue, 9 Sep 2003 07:58:01 -0700 (PDT) ReSent-From: "C. M. Heard" ReSent-To: idr@ietf.org ReSent-Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt ReSent-Message-ID: Subject: [Idr] Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Sep 2003 12:11:57 -0700 (PDT) Resent-Date: Tue, 09 Sep 2003 10:59:01 -0400 Greetings, I noticed the I-D announcement and would like to make a few MIB doctor comments on this draft (but please note that this is the result of a spot check ... I have NOT done a full MIB doctor review of this document). 1.) My understanding from reading the draft and from previous e-mail messages is that this document is supposed to obsolete RFCs 1657 and 1269. If that understanding is correct, an explicit statement to that effect, such as This memo obsoletes RFC 1657 and RFC 1269. must be added both to the Abstract and to the Introduction. 2.) I also understand from reading the draft and from previous e-mail messages that the main purpose of this document is to provide a clean MIB module that documents the behaviour of deployed implementations, and that a new MIB module to overcome numerous shortcomings is under development and will in due course be submitted for standards-track consideration. Under the circumstances it may be appropriate to submit this document as an Informational RFC rather than for the standards track, as indicated in the WG last call: if a replacement is under development, there is no reason to progress this document along the standards track, and submitting it for Proposed Standard implies such an intent. 3.) In reviewing the smidiff report between the MIB module in this draft and the one in RFC 1657 I noticed a couple of questionable things: (a) There are no REVISION/DESCRIPTION pairs for the previous incarnations of the MIB module. This gives rise to the following error message: RFC1657-MIB.my:25 [3] {revision-removed} revision `1994-05-05 00:00' removed This can be easily fixed by the following change to the MIB module at the end of the REVISION/DESCRIPTION pair now present: OLD: bgpPeerInTotalMessages, bgpPeerOutTotalMessages" NEW: bgpPeerInTotalMessages, bgpPeerOutTotalMessages. Published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "199405050000Z" DESCRIPTION "Translated to SMIv2 and published as RFC 1657." REVISION "199110261839Z" DESCRIPTION "Initial version, published as RFC 1269." Note that "199405050000Z is copied from the LAST-UPDATED clause in the MIB module in RFC 1657, which is standard practice. Since that MIB module did not contain a REVISION/DESCRIPTION pair for the RFC 1269 version, and since RFC 1269 was an SMIv1 module and so has no LAST-UPDATED or REVISION clause, the date "199110261839Z" is synthesized from the UTC time stamp Oct 26 18:39:09 1991 on http://www.rfc-editor.org/rfc/rfc1269.txt In my opinion, this is a "must-do" change. (b) The smidiff report indicates that several objects that RFC 1657 declared as 'obsolete' have been promoted to a status of 'deprecated', in violation of SMIv2 revision rules: BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpRcvdPathAttrTable' BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrEntry' BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrPeer' BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrDestNetwork' BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrOrigin' BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrASPath' BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrNextHop' BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrInterASMetric' BGP4-MIB.my:803 [2] {status-change} status change from `deprecated' to `current' for `bgpEstablished' BGP4-MIB.my:812 [2] {status-change} status change from `deprecated' to `current' for `bgpBackwardTransition' Unless the WG had a specific reason for making this change, I would be inclined to recommend that the status of these definitions be changed back to 'obsolete'. 4.) In the DESCRIPTION clause of bgp4MIBNotificationGroup there is a typo. Here is the fix: OLD: Obsoletes bgp4MIBNotificationGroup." NEW: Obsoletes bgp4MIBTrapGroup." In my opinion, this is also another "must-do" change. Regards, Mike Heard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 9 11:00:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15412 for ; Tue, 9 Sep 2003 11:00:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjyX-0002Nh-IS for idr-archive@odin.ietf.org; Tue, 09 Sep 2003 11:00:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89F0DFH009153 for idr-archive@odin.ietf.org; Tue, 9 Sep 2003 11:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjyX-0002NY-8d for idr-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 11:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15343; Tue, 9 Sep 2003 11:00:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjyT-00050F-00; Tue, 09 Sep 2003 11:00:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wjyS-00050B-00; Tue, 09 Sep 2003 11:00:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjxN-0002Eo-8p; Tue, 09 Sep 2003 10:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjwo-0002EC-CR for idr@optimus.ietf.org; Tue, 09 Sep 2003 10:58:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15172 for ; Tue, 9 Sep 2003 10:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjwZ-0004xf-00 for idr@ietf.org; Tue, 09 Sep 2003 10:58:11 -0400 Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx with esmtp (Exim 4.12) id 19wjwY-0004xU-00 for idr@ietf.org; Tue, 09 Sep 2003 10:58:11 -0400 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h89F0Yhs020036 for ; Tue, 9 Sep 2003 08:00:34 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h89Ew4o00340 for ; Tue, 9 Sep 2003 07:58:04 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs X-Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h88JBxm08630; Mon, 8 Sep 2003 12:11:59 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Jeffrey Haas cc: IDR WG , "Wijnen, Bert (Bert)" In-Reply-To: <200309081052.GAA09884@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Tue, 9 Sep 2003 07:58:01 -0700 (PDT) ReSent-From: "C. M. Heard" ReSent-To: idr@ietf.org ReSent-Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt ReSent-Message-ID: Subject: [Idr] Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Sep 2003 12:11:57 -0700 (PDT) Resent-Date: Tue, 09 Sep 2003 10:59:01 -0400 Greetings, I noticed the I-D announcement and would like to make a few MIB doctor comments on this draft (but please note that this is the result of a spot check ... I have NOT done a full MIB doctor review of this document). 1.) My understanding from reading the draft and from previous e-mail messages is that this document is supposed to obsolete RFCs 1657 and 1269. If that understanding is correct, an explicit statement to that effect, such as This memo obsoletes RFC 1657 and RFC 1269. must be added both to the Abstract and to the Introduction. 2.) I also understand from reading the draft and from previous e-mail messages that the main purpose of this document is to provide a clean MIB module that documents the behaviour of deployed implementations, and that a new MIB module to overcome numerous shortcomings is under development and will in due course be submitted for standards-track consideration. Under the circumstances it may be appropriate to submit this document as an Informational RFC rather than for the standards track, as indicated in the WG last call: if a replacement is under development, there is no reason to progress this document along the standards track, and submitting it for Proposed Standard implies such an intent. 3.) In reviewing the smidiff report between the MIB module in this draft and the one in RFC 1657 I noticed a couple of questionable things: (a) There are no REVISION/DESCRIPTION pairs for the previous incarnations of the MIB module. This gives rise to the following error message: RFC1657-MIB.my:25 [3] {revision-removed} revision `1994-05-05 00:00' removed This can be easily fixed by the following change to the MIB module at the end of the REVISION/DESCRIPTION pair now present: OLD: bgpPeerInTotalMessages, bgpPeerOutTotalMessages" NEW: bgpPeerInTotalMessages, bgpPeerOutTotalMessages. Published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "199405050000Z" DESCRIPTION "Translated to SMIv2 and published as RFC 1657." REVISION "199110261839Z" DESCRIPTION "Initial version, published as RFC 1269." Note that "199405050000Z is copied from the LAST-UPDATED clause in the MIB module in RFC 1657, which is standard practice. Since that MIB module did not contain a REVISION/DESCRIPTION pair for the RFC 1269 version, and since RFC 1269 was an SMIv1 module and so has no LAST-UPDATED or REVISION clause, the date "199110261839Z" is synthesized from the UTC time stamp Oct 26 18:39:09 1991 on http://www.rfc-editor.org/rfc/rfc1269.txt In my opinion, this is a "must-do" change. (b) The smidiff report indicates that several objects that RFC 1657 declared as 'obsolete' have been promoted to a status of 'deprecated', in violation of SMIv2 revision rules: BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpRcvdPathAttrTable' BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrEntry' BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrPeer' BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrDestNetwork' BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrOrigin' BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrASPath' BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrNextHop' BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrInterASMetric' BGP4-MIB.my:803 [2] {status-change} status change from `deprecated' to `current' for `bgpEstablished' BGP4-MIB.my:812 [2] {status-change} status change from `deprecated' to `current' for `bgpBackwardTransition' Unless the WG had a specific reason for making this change, I would be inclined to recommend that the status of these definitions be changed back to 'obsolete'. 4.) In the DESCRIPTION clause of bgp4MIBNotificationGroup there is a typo. Here is the fix: OLD: Obsoletes bgp4MIBNotificationGroup." NEW: Obsoletes bgp4MIBTrapGroup." In my opinion, this is also another "must-do" change. Regards, Mike Heard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Sep 10 08:01:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26733; Wed, 10 Sep 2003 08:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x3fc-0003Ea-00; Wed, 10 Sep 2003 08:02:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x3fb-0003EV-00; Wed, 10 Sep 2003 08:01:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x3eh-0001hU-GA; Wed, 10 Sep 2003 08:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x3ec-0001g7-Of for idr@optimus.ietf.org; Wed, 10 Sep 2003 08:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26673 for ; Wed, 10 Sep 2003 08:00:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x3eb-0003Ds-00 for idr@ietf.org; Wed, 10 Sep 2003 08:00:57 -0400 Received: from web41808.mail.yahoo.com ([66.218.93.142]) by ietf-mx with smtp (Exim 4.12) id 19x3eb-0003Dg-00 for idr@ietf.org; Wed, 10 Sep 2003 08:00:57 -0400 Message-ID: <20030910120026.69193.qmail@web41808.mail.yahoo.com> Received: from [203.200.20.226] by web41808.mail.yahoo.com via HTTP; Wed, 10 Sep 2003 13:00:26 BST From: =?iso-8859-1?q?John=20Smith?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Slides Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 13:00:26 +0100 (BST) Content-Transfer-Encoding: 8bit Hi, Can we concerned authorities please upload the slides and the meeting minutes on the ietf web page for the 57th meeting. John ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Sep 10 08:02:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26782 for ; Wed, 10 Sep 2003 08:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x3fd-0001t8-NS for idr-archive@odin.ietf.org; Wed, 10 Sep 2003 08:02:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8AC21Vs007252 for idr-archive@odin.ietf.org; Wed, 10 Sep 2003 08:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x3fd-0001st-K5 for idr-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 08:02:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26733; Wed, 10 Sep 2003 08:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x3fc-0003Ea-00; Wed, 10 Sep 2003 08:02:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x3fb-0003EV-00; Wed, 10 Sep 2003 08:01:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x3eh-0001hU-GA; Wed, 10 Sep 2003 08:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x3ec-0001g7-Of for idr@optimus.ietf.org; Wed, 10 Sep 2003 08:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26673 for ; Wed, 10 Sep 2003 08:00:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x3eb-0003Ds-00 for idr@ietf.org; Wed, 10 Sep 2003 08:00:57 -0400 Received: from web41808.mail.yahoo.com ([66.218.93.142]) by ietf-mx with smtp (Exim 4.12) id 19x3eb-0003Dg-00 for idr@ietf.org; Wed, 10 Sep 2003 08:00:57 -0400 Message-ID: <20030910120026.69193.qmail@web41808.mail.yahoo.com> Received: from [203.200.20.226] by web41808.mail.yahoo.com via HTTP; Wed, 10 Sep 2003 13:00:26 BST From: =?iso-8859-1?q?John=20Smith?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Slides Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 13:00:26 +0100 (BST) Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Can we concerned authorities please upload the slides and the meeting minutes on the ietf web page for the 57th meeting. John ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From owner-idr@merit.edu Wed Sep 10 09:04:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28304 for ; Wed, 10 Sep 2003 09:04:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x4eR-0003ey-00 for idr-archive@ietf.org; Wed, 10 Sep 2003 09:04:51 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19x4eQ-0003ev-00 for idr-archive@ietf.org; Wed, 10 Sep 2003 09:04:50 -0400 Received: by trapdoor.merit.edu (Postfix) id 148B291222; Wed, 10 Sep 2003 09:04:32 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D893B91223; Wed, 10 Sep 2003 09:04:31 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C431391222 for ; Wed, 10 Sep 2003 09:04:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD5D35DDBB; Wed, 10 Sep 2003 09:04:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [65.247.36.216]) by segue.merit.edu (Postfix) with ESMTP id 504A25DD9F for ; Wed, 10 Sep 2003 09:04:30 -0400 (EDT) Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8AD4NCn017019; Wed, 10 Sep 2003 09:04:23 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8AD4I1X017009; Wed, 10 Sep 2003 09:04:18 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8AD4DE28233; Wed, 10 Sep 2003 09:04:13 -0400 (EDT) Date: Wed, 10 Sep 2003 09:04:13 -0400 From: Jeffrey Haas To: "Wijnen, Bert (Bert)" Cc: "C. M. Heard" , IDR WG Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Message-ID: <20030910090412.A28220@nexthop.com> References: <7D5D48D2CAA3D84C813F5B154F43B155026F6E83@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155026F6E83@nl0006exch001u.nl.lucent.com>; from bwijnen@lucent.com on Wed, Sep 10, 2003 at 09:14:46AM +0200 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Wed, Sep 10, 2003 at 09:14:46AM +0200, Wijnen, Bert (Bert) wrote: > Thanks for the (partial) review Mike. > I am sure it will be helpfull... I have not read it in detail > yet... hope to do so later this week. > > I assume author and WG will respond with fixes and or > answers. I accept all of the suggested changes unless there is further feedback from the WG. Meanwhile, I'll hold off issuing another version of the draft pending your review. -- Jeff Haas NextHop Technologies From idr-admin@ietf.org Wed Sep 10 11:33:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04529; Wed, 10 Sep 2003 11:33:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6yk-0004qZ-00; Wed, 10 Sep 2003 11:33:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x6yk-0004qW-00; Wed, 10 Sep 2003 11:33:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6xp-0000Ow-9u; Wed, 10 Sep 2003 11:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6xI-0000OH-Ip for idr@optimus.ietf.org; Wed, 10 Sep 2003 11:32:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04275 for ; Wed, 10 Sep 2003 11:32:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6xH-0004oo-00 for idr@ietf.org; Wed, 10 Sep 2003 11:32:27 -0400 Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx with esmtp (Exim 4.12) id 19x6xH-0004ol-00 for idr@ietf.org; Wed, 10 Sep 2003 11:32:27 -0400 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h8AFZ5hs019089; Wed, 10 Sep 2003 08:35:05 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h8AFWPk03437; Wed, 10 Sep 2003 08:32:25 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Jeffrey Haas cc: "Wijnen, Bert (Bert)" , IDR WG In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155026F6E83@nl0006exch001u.nl.lucent.com> <20030910090412.A28220@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Idr] Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 08:32:24 -0700 (PDT) [ list address changed to . plz update charter page. ] On Wed, 10 Sep 2003, Jeffrey Haas wrote: > On Wed, Sep 10, 2003 at 09:14:46AM +0200, Wijnen, Bert (Bert) wrote: > > Thanks for the (partial) review Mike. > > I am sure it will be helpfull... I have not read it in detail > > yet... hope to do so later this week. > > > > I assume author and WG will respond with fixes and or > > answers. > > I accept all of the suggested changes unless there is further feedback > from the WG. Meanwhile, I'll hold off issuing another version of > the draft pending your review. Allow me to add some clarifications regarding this: > (b) The smidiff report indicates that several objects that RFC 1657 > declared as 'obsolete' have been promoted to a status of > 'deprecated', in violation of SMIv2 revision rules: > > BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpRcvdPathAttrTable' > BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrEntry' > BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrPeer' > BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrDestNetwork' > BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrOrigin' > BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrASPath' > BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrNextHop' > BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrInterASMetric' > BGP4-MIB.my:803 [2] {status-change} status change from `deprecated' > to `current' for `bgpEstablished' > BGP4-MIB.my:812 [2] {status-change} status change from `deprecated' > to `current' for `bgpBackwardTransition' > > Unless the WG had a specific reason for making this change, I would > be inclined to recommend that the status of these definitions be > changed back to 'obsolete'. - First, the status-change messages for bgpEstablished and bgpBackwardTransition are wrong (the change was from current to deprecated) and should be ignored. I will file a bug report with the smidiff maintainers. - Second, the group bgp4MIBRcvdPathAttrGroup, which contains all of the accessible columns in the bgpRcvdPathAttrTable, has a status of 'deprecated'. That is legal, even though the contained objects themselves have a status of 'obsolete', but the WG may prefer for bgp4MIBRcvdPathAttrGroup have a status of 'obsolete'. If its status is changed be sure to update the DESCRIPTION clause to match. Thanks, Mike Heard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Sep 10 11:34:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04595 for ; Wed, 10 Sep 2003 11:34:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6ym-0000bC-Ab for idr-archive@odin.ietf.org; Wed, 10 Sep 2003 11:34:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8AFY0Qm002301 for idr-archive@odin.ietf.org; Wed, 10 Sep 2003 11:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6ym-0000b2-3Z for idr-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 11:34:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04529; Wed, 10 Sep 2003 11:33:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6yk-0004qZ-00; Wed, 10 Sep 2003 11:33:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19x6yk-0004qW-00; Wed, 10 Sep 2003 11:33:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6xp-0000Ow-9u; Wed, 10 Sep 2003 11:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6xI-0000OH-Ip for idr@optimus.ietf.org; Wed, 10 Sep 2003 11:32:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04275 for ; Wed, 10 Sep 2003 11:32:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6xH-0004oo-00 for idr@ietf.org; Wed, 10 Sep 2003 11:32:27 -0400 Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx with esmtp (Exim 4.12) id 19x6xH-0004ol-00 for idr@ietf.org; Wed, 10 Sep 2003 11:32:27 -0400 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h8AFZ5hs019089; Wed, 10 Sep 2003 08:35:05 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h8AFWPk03437; Wed, 10 Sep 2003 08:32:25 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Jeffrey Haas cc: "Wijnen, Bert (Bert)" , IDR WG In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155026F6E83@nl0006exch001u.nl.lucent.com> <20030910090412.A28220@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Idr] Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 08:32:24 -0700 (PDT) [ list address changed to . plz update charter page. ] On Wed, 10 Sep 2003, Jeffrey Haas wrote: > On Wed, Sep 10, 2003 at 09:14:46AM +0200, Wijnen, Bert (Bert) wrote: > > Thanks for the (partial) review Mike. > > I am sure it will be helpfull... I have not read it in detail > > yet... hope to do so later this week. > > > > I assume author and WG will respond with fixes and or > > answers. > > I accept all of the suggested changes unless there is further feedback > from the WG. Meanwhile, I'll hold off issuing another version of > the draft pending your review. Allow me to add some clarifications regarding this: > (b) The smidiff report indicates that several objects that RFC 1657 > declared as 'obsolete' have been promoted to a status of > 'deprecated', in violation of SMIv2 revision rules: > > BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpRcvdPathAttrTable' > BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrEntry' > BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrPeer' > BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrDestNetwork' > BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrOrigin' > BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrASPath' > BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrNextHop' > BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrInterASMetric' > BGP4-MIB.my:803 [2] {status-change} status change from `deprecated' > to `current' for `bgpEstablished' > BGP4-MIB.my:812 [2] {status-change} status change from `deprecated' > to `current' for `bgpBackwardTransition' > > Unless the WG had a specific reason for making this change, I would > be inclined to recommend that the status of these definitions be > changed back to 'obsolete'. - First, the status-change messages for bgpEstablished and bgpBackwardTransition are wrong (the change was from current to deprecated) and should be ignored. I will file a bug report with the smidiff maintainers. - Second, the group bgp4MIBRcvdPathAttrGroup, which contains all of the accessible columns in the bgpRcvdPathAttrTable, has a status of 'deprecated'. That is legal, even though the contained objects themselves have a status of 'obsolete', but the WG may prefer for bgp4MIBRcvdPathAttrGroup have a status of 'obsolete'. If its status is changed be sure to update the DESCRIPTION clause to match. Thanks, Mike Heard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From owner-idr@merit.edu Thu Sep 11 18:01:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15323 for ; Thu, 11 Sep 2003 18:01:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xZVI-0006lV-00 for idr-archive@ietf.org; Thu, 11 Sep 2003 18:01:28 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19xZVH-0006lM-00 for idr-archive@ietf.org; Thu, 11 Sep 2003 18:01:27 -0400 Received: by trapdoor.merit.edu (Postfix) id 7AA549128B; Thu, 11 Sep 2003 18:01:12 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A2ED9128D; Thu, 11 Sep 2003 18:01:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40D2C9128B for ; Thu, 11 Sep 2003 18:01:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 205645E020; Thu, 11 Sep 2003 18:01:10 -0400 (EDT) Delivered-To: idr@merit.edu Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by segue.merit.edu (Postfix) with ESMTP id AFE2D5E00E for ; Thu, 11 Sep 2003 18:01:09 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8BM12Bx006302; Thu, 11 Sep 2003 17:01:08 -0500 (CDT) Message-ID: <3F60F09E.9060806@alcatel.com> Date: Thu, 11 Sep 2003 15:01:02 -0700 From: Andrew Lange Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: enke@redback.com, idr@merit.edu, vgi@opentransit.net Cc: "Don Goodspeed" Subject: Cease Subcode Draft - Suggestion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Don Goodspeed pointed out a couple of error conditions that would be useful to add to the cease subcodes draft. We worked up some proposed text to add to draft-ietf-idr-cease-subcode-03.txt: 4. Subcode Definition Subcode Symbolic Name 0 Other Condition ... ... 8 Out of Resources 5. Subcode Usage If a BGP speaker decides to shutdown the session for a reason that is not covered in the other subcodes defined in this document, then the speaker should send a NOTIFICATION message with the Error Code Cease, and the Error Subcode "Other Condition". If a BGP speaker decides to shut down a session because it is out of resources, such as memory, then the speaker should send a NOTIFICATION message with the Error Code Cease, and the Error Subcode "Out of Resources". ... It is recommended that a BGP speaker implement a backoff mechanism in re-trying a BGP connection after the speaker receives a Cease NOPTIFICATION message with the subcode of ... "Out of Resources". Andrew From owner-idr@merit.edu Thu Sep 11 21:03:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21082 for ; Thu, 11 Sep 2003 21:03:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xcLH-0000Mg-00 for idr-archive@ietf.org; Thu, 11 Sep 2003 21:03:19 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19xcLG-0000MW-00 for idr-archive@ietf.org; Thu, 11 Sep 2003 21:03:18 -0400 Received: by trapdoor.merit.edu (Postfix) id BA36391249; Thu, 11 Sep 2003 21:03:01 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DF3591296; Thu, 11 Sep 2003 21:03:01 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81E6891249 for ; Thu, 11 Sep 2003 21:03:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D1A35DED3; Thu, 11 Sep 2003 21:03:00 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id E5B5E5DE41 for ; Thu, 11 Sep 2003 21:02:59 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 68A77369000; Thu, 11 Sep 2003 18:02:59 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 2636B15D3C1; Thu, 11 Sep 2003 18:02:57 -0700 (PDT) To: Andrew Lange Cc: idr@merit.edu, vgi@opentransit.net, "Don Goodspeed" , enke@redback.com Subject: Re: Cease Subcode Draft - Suggestion In-Reply-To: Message from Andrew Lange of "Thu, 11 Sep 2003 15:01:02 PDT." <3F60F09E.9060806@alcatel.com> Date: Thu, 11 Sep 2003 18:02:57 -0700 From: Enke Chen Message-Id: <20030912010258.2636B15D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Andrew and Don: > Message-ID: <3F60F09E.9060806@alcatel.com> > Date: Thu, 11 Sep 2003 15:01:02 -0700 > From: Andrew Lange > Organization: Alcatel USA > To: enke@redback.com, idr@merit.edu, vgi@opentransit.net > Cc: "Don Goodspeed" > Subject: Cease Subcode Draft - Suggestion > > Hello, > > Don Goodspeed pointed out a couple of error conditions that would be > useful to add to the cease subcodes draft. We worked up some proposed > text to add to draft-ietf-idr-cease-subcode-03.txt: > > 4. Subcode Definition > > Subcode Symbolic Name > 0 Other Condition I do not think this is necessary as the BGP spec has already defined Subcode 0 for "Unspecific". See the following text from the latest draft: ---------------------------------- 4.5 NOTIFICATION Message Format Error subcode: This 1-octet unsigned integer provides more specific informa- tion about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field. ---------------------------------- > ... ... > 8 Out of Resources Assuming the message can still be sent :-) I would like to hear some comments on this one. -- Enke > > 5. Subcode Usage > > If a BGP speaker decides to shutdown the session for a reason that > is not covered in the other subcodes defined in this document, then > the speaker should send a NOTIFICATION message with the Error Code > Cease, and the Error Subcode "Other Condition". > > If a BGP speaker decides to shut down a session because it is out of > resources, such as memory, then the speaker should send a > NOTIFICATION message with the Error Code Cease, and the Error > Subcode "Out of Resources". > > ... > > It is recommended that a BGP speaker implement a backoff mechanism > in re-trying a BGP connection after the speaker receives a Cease > NOPTIFICATION message with the subcode of ... "Out of Resources". > > > Andrew > From owner-idr@merit.edu Tue Sep 16 10:20:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16440 for ; Tue, 16 Sep 2003 10:20:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zGh5-0002XU-00 for idr-archive@ietf.org; Tue, 16 Sep 2003 10:20:39 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19zGh5-0002XO-00 for idr-archive@ietf.org; Tue, 16 Sep 2003 10:20:39 -0400 Received: by trapdoor.merit.edu (Postfix) id DFFDD9123A; Tue, 16 Sep 2003 10:20:23 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFDEA9123B; Tue, 16 Sep 2003 10:20:23 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79C939123A for ; Tue, 16 Sep 2003 10:20:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 067565DD95; Tue, 16 Sep 2003 10:20:22 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 71B775DD8E for ; Tue, 16 Sep 2003 10:20:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16340; Tue, 16 Sep 2003 10:20:09 -0400 (EDT) Message-Id: <200309161420.KAA16340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-cease-subcode-04.txt Date: Tue, 16 Sep 2003 10:20:08 -0400 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 : Subcodes for BGP Cease Notification Message Author(s) : E. Chen, V. Gillet Filename : draft-ietf-idr-cease-subcode-04.txt Pages : 4 Date : 2003-9-16 This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in co-relating network events and diagnosing BGP peering issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-cease-subcode-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-cease-subcode-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16103804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16103804.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Tue Sep 16 14:53:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01830 for ; Tue, 16 Sep 2003 14:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKxV-0007cp-00 for idr-archive@ietf.org; Tue, 16 Sep 2003 14:53:53 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19zKxU-0007ca-00 for idr-archive@ietf.org; Tue, 16 Sep 2003 14:53:52 -0400 Received: by trapdoor.merit.edu (Postfix) id 245C3912CE; Tue, 16 Sep 2003 14:53:34 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5D9B912D3; Tue, 16 Sep 2003 14:53:33 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E3CF912CE for ; Tue, 16 Sep 2003 14:53:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EFED5DDCB; Tue, 16 Sep 2003 14:53:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 3456D5DDB5 for ; Tue, 16 Sep 2003 14:53:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01741; Tue, 16 Sep 2003 14:53:22 -0400 (EDT) Message-Id: <200309161853.OAA01741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt Date: Tue, 16 Sep 2003 14:53:22 -0400 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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt Pages : 20 Date : 2003-9-16 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16115400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16115400.I-D@ietf.org> --OtherAccess-- --NextPart-- From idr-admin@ietf.org Tue Sep 16 15:07:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03052; Tue, 16 Sep 2003 15:07:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLAT-00006N-00; Tue, 16 Sep 2003 15:07:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zLAS-00006I-00; Tue, 16 Sep 2003 15:07:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL9G-0004Gt-Cz; Tue, 16 Sep 2003 15:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL8z-0004Gd-1Y for idr@optimus.ietf.org; Tue, 16 Sep 2003 15:05:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02776 for ; Tue, 16 Sep 2003 15:05:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zL8v-00002W-00 for idr@ietf.org; Tue, 16 Sep 2003 15:05:41 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19zL8v-00001h-00 for idr@ietf.org; Tue, 16 Sep 2003 15:05:41 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 255C92029B for ; Tue, 16 Sep 2003 13:05:04 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Danny McPherson To: idr@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Idr] Fwd: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 13:05:03 -0600 Content-Transfer-Encoding: 7bit Note that all comments received to date (within the WG LC window that ends today) have been incorporated into this version of the draft. -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Tue Sep 16, 2003 12:53:22 PM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt > Reply-To: Internet-Drafts@ietf.org > > 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 : Experience with the BGP-4 Protocol > Author(s) : D. McPherson, K. Patel > Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt > Pages : 20 > Date : 2003-9-16 > > The purpose of this memo is to document how the requirements for > advancing a routing protocol from Draft Standard to full Standard > have been satisfied by Border Gateway Protocol version 4 (BGP-4). > This report satisfies the requirement for 'the second report', as > described in Section 6.0 of RFC 1264. In order to fulfill the > requirement, this report augments RFC 1773 and describes additional > knowledge and understanding gained in the time between when the > protocol was made a Draft Standard and when it was submitted for > Standard. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience- > protocol-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-idr-bgp4-experience-protocol-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-9-16115400.I-D@ietf.org> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 16 15:07:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03167 for ; Tue, 16 Sep 2003 15:07:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLAY-0004U0-Au for idr-archive@odin.ietf.org; Tue, 16 Sep 2003 15:07:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GJ7M4s017221 for idr-archive@odin.ietf.org; Tue, 16 Sep 2003 15:07:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLAW-0004TC-H0 for idr-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 15:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03052; Tue, 16 Sep 2003 15:07:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLAT-00006N-00; Tue, 16 Sep 2003 15:07:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zLAS-00006I-00; Tue, 16 Sep 2003 15:07:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL9G-0004Gt-Cz; Tue, 16 Sep 2003 15:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL8z-0004Gd-1Y for idr@optimus.ietf.org; Tue, 16 Sep 2003 15:05:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02776 for ; Tue, 16 Sep 2003 15:05:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zL8v-00002W-00 for idr@ietf.org; Tue, 16 Sep 2003 15:05:41 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19zL8v-00001h-00 for idr@ietf.org; Tue, 16 Sep 2003 15:05:41 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 255C92029B for ; Tue, 16 Sep 2003 13:05:04 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Danny McPherson To: idr@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Idr] Fwd: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 13:05:03 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Note that all comments received to date (within the WG LC window that ends today) have been incorporated into this version of the draft. -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Tue Sep 16, 2003 12:53:22 PM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt > Reply-To: Internet-Drafts@ietf.org > > 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 : Experience with the BGP-4 Protocol > Author(s) : D. McPherson, K. Patel > Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt > Pages : 20 > Date : 2003-9-16 > > The purpose of this memo is to document how the requirements for > advancing a routing protocol from Draft Standard to full Standard > have been satisfied by Border Gateway Protocol version 4 (BGP-4). > This report satisfies the requirement for 'the second report', as > described in Section 6.0 of RFC 1264. In order to fulfill the > requirement, this report augments RFC 1773 and describes additional > knowledge and understanding gained in the time between when the > protocol was made a Draft Standard and when it was submitted for > Standard. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience- > protocol-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-idr-bgp4-experience-protocol-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-9-16115400.I-D@ietf.org> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From owner-idr@merit.edu Tue Sep 16 15:47:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05674 for ; Tue, 16 Sep 2003 15:47:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLnH-0000gF-00 for idr-archive@ietf.org; Tue, 16 Sep 2003 15:47:23 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19zLnH-0000g7-00 for idr-archive@ietf.org; Tue, 16 Sep 2003 15:47:23 -0400 Received: by trapdoor.merit.edu (Postfix) id 5DB60912DA; Tue, 16 Sep 2003 15:47:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E523912DB; Tue, 16 Sep 2003 15:47:08 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68339912DA for ; Tue, 16 Sep 2003 15:47:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FBC35DDAA; Tue, 16 Sep 2003 15:47:06 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail13-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by segue.merit.edu (Postfix) with ESMTP id 10E015DD94 for ; Tue, 16 Sep 2003 15:47:06 -0400 (EDT) Received: from mail13-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail13-kan-R.bigfish.com (Postfix) with ESMTP id DAA1DB1C14 for ; Tue, 16 Sep 2003 19:47:04 +0000 (UCT) Received: by mail13-kan (MessageSwitch) id 1063741624817916_321; Tue, 16 Sep 2003 19:47:04 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail13-kan.bigfish.com (Postfix) with ESMTP id A37E1B1DE4 for ; Tue, 16 Sep 2003 19:47:04 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8GJl4v7029071 for ; Tue, 16 Sep 2003 14:47:04 -0500 (CDT) Received: from PKDWG02A.ad.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GJl4t05160 for ; Tue, 16 Sep 2003 14:47:04 -0500 (CDT) Received: from mail pickup service by PKDWG02A.ad.sprint.com with Microsoft SMTPSVC; Tue, 16 Sep 2003 14:47:02 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.56]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Sep 2003 14:32:15 -0500 Received: from smtpgw5.sprintspectrum.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GJWA701472 for ; Tue, 16 Sep 2003 14:32:11 -0500 (CDT) Received: from mail5-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8GJWAv7015999 for ; Tue, 16 Sep 2003 14:32:10 -0500 (CDT) Received: from mail5-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail5-kan-R.bigfish.com (Postfix) with ESMTP id 39E3D201EB0 for ; Tue, 16 Sep 2003 19:03:26 +0000 (UCT) Received: by mail5-kan (MessageSwitch) id 1063739003453639_12564; Tue, 16 Sep 2003 19:03:23 +0000 (UCT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail5-kan.bigfish.com (Postfix) with ESMTP id 39059201E61; Tue, 16 Sep 2003 19:02:52 +0000 (UCT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19zKxP-00089D-5X for ietf-announce-list@asgard.ietf.org; Tue, 16 Sep 2003 14:53:47 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19zKx8-000831-9x for all-ietf@asgard.ietf.org; Tue, 16 Sep 2003 14:53:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01741; Tue, 16 Sep 2003 14:53:22 -0400 (EDT) Message-Id: <200309161853.OAA01741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt Date: Tue, 16 Sep 2003 14:53:22 -0400 X-BigFish: cs-64(z60di60eiz14c3M13bfI122eHzz2cfRzz1033ILz1IV)v X-OriginalArrivalTime: 16 Sep 2003 19:32:16.0718 (UTC) FILETIME=[3CB22EE0:01C37C89] 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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt Pages : 20 Date : 2003-9-16 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16115400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16115400.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Wed Sep 17 10:44:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15591 for ; Wed, 17 Sep 2003 10:44:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zdY2-00079S-00 for idr-archive@ietf.org; Wed, 17 Sep 2003 10:44:50 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx with esmtp (Exim 4.12) id 19zdY2-000799-00 for idr-archive@ietf.org; Wed, 17 Sep 2003 10:44:50 -0400 Received: by trapdoor.merit.edu (Postfix) id 70814913B2; Wed, 17 Sep 2003 10:42:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44070913AD; Wed, 17 Sep 2003 10:42:15 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE8939139C for ; Wed, 17 Sep 2003 10:40:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 91A115DDB2; Wed, 17 Sep 2003 10:40:08 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.avici.com (unknown [12.38.212.174]) by segue.merit.edu (Postfix) with ESMTP id 4A98F5DDA9 for ; Wed, 17 Sep 2003 10:40:08 -0400 (EDT) Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8HEc2Yf001216; Wed, 17 Sep 2003 10:38:03 -0400 Message-Id: <200309171438.h8HEc2Yf001216@mail.avici.com> To: idr@merit.edu Cc: curtis@fictitious.org Reply-To: curtis@fictitious.org Subject: some comments on draft-ietf-idr-bgp4-experience-protocol-02.txt Date: Wed, 17 Sep 2003 10:38:08 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk ref: Title : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt Danny, This looks to be in good shape. If you do another version of the draft here are some suggestions. None of this is essential to the draft but it might be helpful. Curtis In the MED section you might want to describe the common "hot potatoe / cold potatoe" usage. Here is some suggested text. In a situation where traffic flows between a pair of destinations, each connected to two transit networks, each of the transit networks has the choice of either sending the traffic to the closest peering to other transit provider or passing traffic to the peering which advertises the least cost through the other provider. The former method is called "hot potatoe routing" because like a hot potatoe held in bare hands, whoever has it tries to get rid of it quickly. Hot potatoe routing is accomplished by not passing the EGBP learned MED into IBGP. This minimizes transit traffic for the provider routing the traffic. Far less common is "cold potatoe routing" where the transit provider uses their own transit capacity to get the traffic to the point in the adjacent transit provider advertised as being closest to the destination. Cold potatoe routing is accomplished by passing the EBGP learned MED into IBGP. If one transit provider uses hot potatoe routing and another uses cold potatoe, traffic between the two tends to be symetric. Depending on the business relationships, if one provider has more capacity or a significantly less congested transit network, then that provider may use cold potatoe routing. An example of widespread use of cold potatoe routing was the NSF funded NSFNET backbone and NSF funded regional networks in the mid 1990s. In some cases a provider may use hot potatoe routing for some destinations for a given peer AS and cold potatoe routing for others. An example of this is the different treatment of commercial and research traffic in the NSFNET in the mid 1990s. Optionally add to the last paragraph "This might best be described as 'mashed potatoe routing' a term which reflects the complexity of router configurations in use at the time". :-) Under "Internet Dynamics" I would prefer if you would add: None of the current implementations of BGP Route Flap Damping store route history by unique NRLI and AS Path although it is listed as manditory in RFC 2439. A potential result of failure to consider each AS Path separately is an overly aggressive suppression of destinations in a densely meshed network, with the most severe consequence being suppression of a destination after a single failure. Because the top tier AS in the Internet are densely meshed, these adverse consequences are observed. After "Limit Rate Updates" you might add a section: 13 1/2. Consideration of TCP Characteristics If a TCP receiver is processing input more slowly than the sender or if the TCP connection rate is the limiting factor, a form of backpressure is observed by the TCP sending application. When the TCP buffer fills, the sending application will either block on the write or receive an error on the write. Common errors in either early implementations or an occasional naive new implementation are to either set options to block on the write or set options for non-blocking writes and then treat the errors due to a full buffer as fatal. Having recognized that full write buffers are to be expected additional implementation pitfalls exist. The application should not attempt to store the TCP stream within the application itself. If the receiver or the TCP connection is persistently slow, then the buffer can grow until memory is exhausted. A BGP implementation must send changes to all peers for which the TCP connection is not blocked and must remember to send those changes to the remaining peers when the connection becomes unblocked. If the preferred route for a given NLRI changes multiple times while writes to one or more peer is blocked, only the most recent best route needs to be sent. In this way BGP is work conserving. In times of extremely high route change, a higher volume of route change is sent to those peers which are able to process it more quickly and a lower volume of route change is sent to those peers not able to process the changes as quickly. For implentations which handle differing peer capacity to absorb route change well, if the majority of route change is contributed by a subset of unstable NRLI, the only impact on relatively stable NRLI which make an isolated route change is a slower convergence for which convergence time remains bounded regardless of the amount of instability. From idr-admin@ietf.org Thu Sep 18 05:27:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03715; Thu, 18 Sep 2003 05:27:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zv4w-00036J-00; Thu, 18 Sep 2003 05:27:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zv4w-000368-00; Thu, 18 Sep 2003 05:27:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zv41-0005ek-Nn; Thu, 18 Sep 2003 05:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zv3a-0005co-4x for idr@optimus.ietf.org; Thu, 18 Sep 2003 05:26:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03550 for ; Thu, 18 Sep 2003 05:26:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zv3W-00032U-00 for idr@ietf.org; Thu, 18 Sep 2003 05:26:30 -0400 Received: from node-c-04db.a2000.nl ([62.194.4.219] helo=2mails830.com) by ietf-mx with smtp (Exim 4.12) id 19zv3R-00032K-00 for idr@ietf.org; Thu, 18 Sep 2003 05:26:26 -0400 From: "DR.FRANK EFE" Reply-To: frank.efe77@laposte.net To: idr@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: Content-Transfer-Encoding: quoted-printable Subject: [Idr] PARTNER NEEDED Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 11:25:23 -0700 Content-Transfer-Encoding: quoted-printable CONFIDENTIAL 25 Adewabe Street=2C Ikoyi Island=2C Lagos=2E IFax=3A1775-522-8610 18=2F9=2F2003 ATTN=3ATHE PRESIDENT=2FCEO FROM=3ADR=2EFRANK EFE=2E Dear Sir=2C I would like to firstly send to you the best wishes of good health and success in your pursuits particularly through my proposal as contained in this letter=2E Before going into details of my proposal to you=2C I must first implore you to treat with the utmost confidentiality as this is required for its success and to have faith in this transaction=2Cfor opportunities like this only comes to one once in a life time=2E My colleagues and I are senior officials of the Federal Government of my country's Contracts Review Panel =28CRP=29 who are interested in diverting some funds that are presently loating in the accounts of the Apex Bank of my country=2EIn order to commence this transaction=2C we solicit for your assistance to enable us transfer into your nominated account the said floating funds=2E We are determined to conclude the transfer before the end of this quarter of 2003=2E The source of the funds are as follows=3A During the last military regime in my country=2Cgovernment officials set up companies and awarded themselves contracts that were grossly over-invoiced in various ministries and parastatals=2EThe present civilian government set up the Contract Review Panel=2C which has the mandate to use the instruments of payments made available to it by the decree setting up the panel=2C to review these contracts and if necessary pay those who are being owed outstanding amounts=2E My colleagues and I have identified quite a huge sum of these funds which are presently floating in our =28Apex=29Central Bank ready for disbursement and would like to divert some of it for our own purposes=2E However=2C by virtue of our positions as civil servants and members of this panel=2C we cannot acquire these funds in our names or in the names of companies that are based in my country=2E I have therefore been mandated=2Cas a matter of trust by my colleagues in the panel=2C to look for a reliable overseas partner into whose account we can transfer the sum of U=2ES=2E$20=2C500=2C000=2E00 =28Twenty million=2C five hundred thousand U=2ES=2E dollars=29=2EThat is why I am seeking your assistance=2E We have agreed to share the money to be transferred into your account=2C if you agree with our proposition as follows=3B =28i=2925% to the account owner=28you=29=2E =28ii=2965% for us =28the panel officials=29=2E =28iii=2910% to be used in settling all expenses =28by both you and us=29 incidental to the actualization of this project=2E We wish to invest our share of the proceeds of this project in foreign stock markets and other viable business till we are ready and able to have access to them without raising any eyebrows here at home=2E Please note that this transaction is 100% safe and risk-free=2E We intend to effect the transfer within fourteen =2814=29banking days from the date of receipt of the following information through the ifax number stated above=3AYour company's name=2Caddress=2Ctelephone and fax numbers we will use your company's name to apply for the payment and backdate the award of the contract in favour of your company=2E We are looking forward to doing this transaction with you and we solicit for your utmost confidentiality in this transaction=2E I will bring you into a more detailed picture of this transaction when I hear from you=2EPlease get in touch through my IFAX # 177-552-286-10=2E Best regards=2C DR=2EFRANK EFE=2E _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Sep 18 05:28:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03764 for ; Thu, 18 Sep 2003 05:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zv51-0005o6-Bb for idr-archive@odin.ietf.org; Thu, 18 Sep 2003 05:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I9S3Mn022305 for idr-archive@odin.ietf.org; Thu, 18 Sep 2003 05:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zv50-0005na-TO for idr-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 05:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03715; Thu, 18 Sep 2003 05:27:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zv4w-00036J-00; Thu, 18 Sep 2003 05:27:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zv4w-000368-00; Thu, 18 Sep 2003 05:27:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zv41-0005ek-Nn; Thu, 18 Sep 2003 05:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zv3a-0005co-4x for idr@optimus.ietf.org; Thu, 18 Sep 2003 05:26:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03550 for ; Thu, 18 Sep 2003 05:26:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zv3W-00032U-00 for idr@ietf.org; Thu, 18 Sep 2003 05:26:30 -0400 Received: from node-c-04db.a2000.nl ([62.194.4.219] helo=2mails830.com) by ietf-mx with smtp (Exim 4.12) id 19zv3R-00032K-00 for idr@ietf.org; Thu, 18 Sep 2003 05:26:26 -0400 From: "DR.FRANK EFE" Reply-To: frank.efe77@laposte.net To: idr@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: Content-Transfer-Encoding: quoted-printable Subject: [Idr] PARTNER NEEDED Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 11:25:23 -0700 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable CONFIDENTIAL 25 Adewabe Street=2C Ikoyi Island=2C Lagos=2E IFax=3A1775-522-8610 18=2F9=2F2003 ATTN=3ATHE PRESIDENT=2FCEO FROM=3ADR=2EFRANK EFE=2E Dear Sir=2C I would like to firstly send to you the best wishes of good health and success in your pursuits particularly through my proposal as contained in this letter=2E Before going into details of my proposal to you=2C I must first implore you to treat with the utmost confidentiality as this is required for its success and to have faith in this transaction=2Cfor opportunities like this only comes to one once in a life time=2E My colleagues and I are senior officials of the Federal Government of my country's Contracts Review Panel =28CRP=29 who are interested in diverting some funds that are presently loating in the accounts of the Apex Bank of my country=2EIn order to commence this transaction=2C we solicit for your assistance to enable us transfer into your nominated account the said floating funds=2E We are determined to conclude the transfer before the end of this quarter of 2003=2E The source of the funds are as follows=3A During the last military regime in my country=2Cgovernment officials set up companies and awarded themselves contracts that were grossly over-invoiced in various ministries and parastatals=2EThe present civilian government set up the Contract Review Panel=2C which has the mandate to use the instruments of payments made available to it by the decree setting up the panel=2C to review these contracts and if necessary pay those who are being owed outstanding amounts=2E My colleagues and I have identified quite a huge sum of these funds which are presently floating in our =28Apex=29Central Bank ready for disbursement and would like to divert some of it for our own purposes=2E However=2C by virtue of our positions as civil servants and members of this panel=2C we cannot acquire these funds in our names or in the names of companies that are based in my country=2E I have therefore been mandated=2Cas a matter of trust by my colleagues in the panel=2C to look for a reliable overseas partner into whose account we can transfer the sum of U=2ES=2E$20=2C500=2C000=2E00 =28Twenty million=2C five hundred thousand U=2ES=2E dollars=29=2EThat is why I am seeking your assistance=2E We have agreed to share the money to be transferred into your account=2C if you agree with our proposition as follows=3B =28i=2925% to the account owner=28you=29=2E =28ii=2965% for us =28the panel officials=29=2E =28iii=2910% to be used in settling all expenses =28by both you and us=29 incidental to the actualization of this project=2E We wish to invest our share of the proceeds of this project in foreign stock markets and other viable business till we are ready and able to have access to them without raising any eyebrows here at home=2E Please note that this transaction is 100% safe and risk-free=2E We intend to effect the transfer within fourteen =2814=29banking days from the date of receipt of the following information through the ifax number stated above=3AYour company's name=2Caddress=2Ctelephone and fax numbers we will use your company's name to apply for the payment and backdate the award of the contract in favour of your company=2E We are looking forward to doing this transaction with you and we solicit for your utmost confidentiality in this transaction=2E I will bring you into a more detailed picture of this transaction when I hear from you=2EPlease get in touch through my IFAX # 177-552-286-10=2E Best regards=2C DR=2EFRANK EFE=2E _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Sep 19 22:36:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04304 for ; Fri, 19 Sep 2003 22:36:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhEx020140 for ; Fri, 19 Sep 2003 21:37:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6AGHM003888 for idr-archive@odin.ietf.org; Wed, 27 Aug 2003 02:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rpt2-0005qr-7u for idr-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 22:18:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06231; Tue, 26 Aug 2003 22:18:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rpsx-0000wQ-00; Tue, 26 Aug 2003 22:18:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rpsx-0000wJ-00; Tue, 26 Aug 2003 22:18:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmzD-000611-3y; Tue, 26 Aug 2003 19:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rg5r-0006tp-7B for idr@optimus.ietf.org; Tue, 26 Aug 2003 11:50:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12069 for ; Tue, 26 Aug 2003 11:50:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rg5q-0002s4-00 for idr@ietf.org; Tue, 26 Aug 2003 11:50:50 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19rg5p-0002rb-00 for idr@ietf.org; Tue, 26 Aug 2003 11:50:49 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7QFoIRR012410 for idr@ietf.org; Tue, 26 Aug 2003 11:50:18 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h7QFoDAg012393 for ; Tue, 26 Aug 2003 11:50:13 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7QFo8N09401 for idr@ietf.org; Tue, 26 Aug 2003 11:50:08 -0400 (EDT) From: Jeffrey Haas To: idr@ietf.org Message-ID: <20030826115007.B8307@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] BGP-MIBv1 - counter issues Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 26 Aug 2003 11:50:08 -0400 Last call has closed, thanks for the feedback. I have one issue I would like to seek the guidance of the working group on before issuing the (hopefully) last draft of the MIB: The MIB defines the following four objects: bgpPeerInUpdates bgpPeerOutUpdates bgpPeerInTotalMessages bgpPeerOutTotalMessages Each of these objects has the following clause, and has had it for some time: : This object should be initialized to zero (0) when the connection : is established. Does the working group think this is appropriate behavior? I would appreciate it if you would contact your SNMP guys at your companies/contact your MIB implementors and forward this question to them. While you're at it, you may want to mention that several vendors are known to have a broken implementation of the bgpVersion object. Given the wording, I'm not surprised. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Sep 19 22:36:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04417 for ; Fri, 19 Sep 2003 22:36:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhFR020140 for ; Fri, 19 Sep 2003 21:37:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88M2OFJ000750 for idr-archive@odin.ietf.org; Mon, 8 Sep 2003 18:02:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wU5W-0000C1-G4 for idr-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 18:02:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24034; Mon, 8 Sep 2003 18:02:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wU5T-0001Eb-00; Mon, 08 Sep 2003 18:02:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wU5S-0001EV-00; Mon, 08 Sep 2003 18:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wU4Q-0008WV-5p; Mon, 08 Sep 2003 18:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wU43-0008VE-8q for idr@optimus.ietf.org; Mon, 08 Sep 2003 18:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23954 for ; Mon, 8 Sep 2003 18:00:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wU40-0001DG-00 for idr@ietf.org; Mon, 08 Sep 2003 18:00:48 -0400 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 19wU3z-0001DD-00 for idr@ietf.org; Mon, 08 Sep 2003 18:00:47 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h88M0hr09919 for ; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) Received: from coors.torrentnet.com (coors.torrentnet.com [4.21.152.11]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h88M0h689918 for ; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) Received: (from kaarthik@localhost) by coors.torrentnet.com (8.11.2/8.11.2) id h88M0hR33090; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) X-Authentication-Warning: coors.torrentnet.com: kaarthik set sender to kaarthik@torrentnet.com using -f To: IDR mailing list From: Kaarthik Sivakumar Message-ID: <1iy8wzhrec.fsf@coors.torrentnet.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.1 (Channel Islands, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Idr] graceful restart vs flap dampening Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Sep 2003 18:00:43 -0400 I am interested in how route flap dampening would interact with graceful restart. Should stale routes be considered flapping and the figure of merit appropriately increased? Should this be done when the peer goes down or when the peer comes back up and doesnt readvertise one of the stale routes, thus forcing the route to be withdrawn from the listening speaker's forwarding? The graceful restart draft doesnt refer to this interaction. In my view, the figure of merit for the route should only be affected when the restarting speaker comes up and doesnt readvertise the stale route. Maybe this is clear from the draft and the route flap dampening rfc and I just missed it. If so, let me know what I am missing. Otherwise I would suggest some text in the graceful restart draft about this interaction. Thanks.. kaarthik _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Sat Sep 20 15:42:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21024; Sat, 20 Sep 2003 15:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0ncT-0000SP-00; Sat, 20 Sep 2003 15:42:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0ncO-0000SE-00; Sat, 20 Sep 2003 15:42:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0nbI-00029t-AY; Sat, 20 Sep 2003 15:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0naL-000294-KL for idr@optimus.ietf.org; Sat, 20 Sep 2003 15:40:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20967 for ; Sat, 20 Sep 2003 15:39:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0naK-0000R7-00 for idr@ietf.org; Sat, 20 Sep 2003 15:40:00 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A0na9-0000Qh-00 for idr@ietf.org; Sat, 20 Sep 2003 15:39:49 -0400 Subject: [idr] taxonomy of bogon filtering applied to route servers MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [idr] taxonomy of bogon filtering applied to route servers Thread-Index: AcN4vciAfF18XVnBSQaemUP9e/zWOgG8NEnQ From: "Michel Py" To: Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Sep 2003 12:39:09 -0700 Content-Transfer-Encoding: quoted-printable idr chairs and folks, [I apologize in advance is this off-topic for this list] I was recently looking at the issue of bogon route-servers, and it struck me that there would be little work to adapt BGP Prefix-Based Outbound Route Filtering (ORF) to change it into what is desperately needed for bogons. In a nutshell, the way I understand ORF is that the sending router sends the receiving router a prefix-list (or distribute-list, or as-path list). When the receiving router receives the prefix-list, it applies it outbound towards the peer it received it from. The enhancement that would be needed would be to make the receiving router capable of applying the received prefix-list to other peers, especially inbound. This would likely involve naming the received ORF and making it available to other peers. In other words, my idea is to use the ORF mechanism to propagate prefix-lists to other peers, not for the purpose of filtering the routes sent to a peer and their associated handling but for the purpose of filtering inbound routes coming from other peers of the receiving ORF router. I was wondering what this WG thinks about it. I wrote a little taxonomy about IPv6 bogon filtering; this is very, very crude and I welcome your comments. Best, Michel. Taxonomy of bogon filtering. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D There are five basic ways to handle the bogon filtering issue: 1. Manually configured prefix-lists. 2. BGP feed of "bad" prefix aggregates. 3. BGP feed of anomalies. 4. BGP feed of "good" prefixes. 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). 1. Manually configured prefix-lists. ------------------------------------ This involves one or more volunteers to maintain a prefix-list that is to be configured manually on routers. The issue with this is change management: as we have seen with the 69/8 fiasco not that long ago, some people do _not_ update their filters regularly, and when the bogon prefix-list is modified it can take weeks to be upgraded, which is not good. However, in terms of granularity, this is what gives the finest control. 2. BGP feed of "bad" prefix aggregates. --------------------------------------- This is the mechanism currently used by team cymru's bogon route servers (http://www.cymru.com/BGP/bogon-rs.html). The issue with this is that the domain of applicability is limited to networks that do not receive a full feed. If one gets a full feed, this method does not prevent bad prefixes if they are smaller than the bogon feed, because of the longest match rule. So, this is an option only for networks with private peering only and a default route outside, because a blackhole route is installed to dump all the bogon traffic instead of sending it to the default route. 3. BGP feed of anomalies. ------------------------- A finer version of the previous one. Real-time monitoring of the routing table at different points allows to build a list of bad announcements. Contrary to the previous option, this allows to deal with specific announcements. The issue with this is that it does not prevent the bad announcement to be received, it actually adds another path that will be made preferred to the offending announcement and used to dump the traffic in a blackhole. Compared to the feeding of bad aggregates, this method extends the domain of applicability to defaultless networks, at the expense of aggravating the routing table size issue. 4. BGP feed of "good" prefixes. ------------------------------- This is an IPv6-only topic that was discussed outside of idr. Please don't pay attention to it in this context. 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). ----------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080134a57.html Unfortunately the actual capabilities of this are that the filter-list received from the peer is applied only outbound to the same peer. This is a very promising technique for bogon route servers, but we need to enhance it. Please send comments. Michel. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Sat Sep 20 15:42:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21055 for ; Sat, 20 Sep 2003 15:42:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ncW-0002G9-0w for idr-archive@odin.ietf.org; Sat, 20 Sep 2003 15:42:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KJgGcC008686 for idr-archive@odin.ietf.org; Sat, 20 Sep 2003 15:42:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ncV-0002G1-SM for idr-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 15:42:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21024; Sat, 20 Sep 2003 15:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0ncT-0000SP-00; Sat, 20 Sep 2003 15:42:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0ncO-0000SE-00; Sat, 20 Sep 2003 15:42:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0nbI-00029t-AY; Sat, 20 Sep 2003 15:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0naL-000294-KL for idr@optimus.ietf.org; Sat, 20 Sep 2003 15:40:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20967 for ; Sat, 20 Sep 2003 15:39:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0naK-0000R7-00 for idr@ietf.org; Sat, 20 Sep 2003 15:40:00 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A0na9-0000Qh-00 for idr@ietf.org; Sat, 20 Sep 2003 15:39:49 -0400 Subject: [idr] taxonomy of bogon filtering applied to route servers MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [idr] taxonomy of bogon filtering applied to route servers Thread-Index: AcN4vciAfF18XVnBSQaemUP9e/zWOgG8NEnQ From: "Michel Py" To: Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Sep 2003 12:39:09 -0700 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable idr chairs and folks, [I apologize in advance is this off-topic for this list] I was recently looking at the issue of bogon route-servers, and it struck me that there would be little work to adapt BGP Prefix-Based Outbound Route Filtering (ORF) to change it into what is desperately needed for bogons. In a nutshell, the way I understand ORF is that the sending router sends the receiving router a prefix-list (or distribute-list, or as-path list). When the receiving router receives the prefix-list, it applies it outbound towards the peer it received it from. The enhancement that would be needed would be to make the receiving router capable of applying the received prefix-list to other peers, especially inbound. This would likely involve naming the received ORF and making it available to other peers. In other words, my idea is to use the ORF mechanism to propagate prefix-lists to other peers, not for the purpose of filtering the routes sent to a peer and their associated handling but for the purpose of filtering inbound routes coming from other peers of the receiving ORF router. I was wondering what this WG thinks about it. I wrote a little taxonomy about IPv6 bogon filtering; this is very, very crude and I welcome your comments. Best, Michel. Taxonomy of bogon filtering. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D There are five basic ways to handle the bogon filtering issue: 1. Manually configured prefix-lists. 2. BGP feed of "bad" prefix aggregates. 3. BGP feed of anomalies. 4. BGP feed of "good" prefixes. 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). 1. Manually configured prefix-lists. ------------------------------------ This involves one or more volunteers to maintain a prefix-list that is to be configured manually on routers. The issue with this is change management: as we have seen with the 69/8 fiasco not that long ago, some people do _not_ update their filters regularly, and when the bogon prefix-list is modified it can take weeks to be upgraded, which is not good. However, in terms of granularity, this is what gives the finest control. 2. BGP feed of "bad" prefix aggregates. --------------------------------------- This is the mechanism currently used by team cymru's bogon route servers (http://www.cymru.com/BGP/bogon-rs.html). The issue with this is that the domain of applicability is limited to networks that do not receive a full feed. If one gets a full feed, this method does not prevent bad prefixes if they are smaller than the bogon feed, because of the longest match rule. So, this is an option only for networks with private peering only and a default route outside, because a blackhole route is installed to dump all the bogon traffic instead of sending it to the default route. 3. BGP feed of anomalies. ------------------------- A finer version of the previous one. Real-time monitoring of the routing table at different points allows to build a list of bad announcements. Contrary to the previous option, this allows to deal with specific announcements. The issue with this is that it does not prevent the bad announcement to be received, it actually adds another path that will be made preferred to the offending announcement and used to dump the traffic in a blackhole. Compared to the feeding of bad aggregates, this method extends the domain of applicability to defaultless networks, at the expense of aggravating the routing table size issue. 4. BGP feed of "good" prefixes. ------------------------------- This is an IPv6-only topic that was discussed outside of idr. Please don't pay attention to it in this context. 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). ----------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080134a57.html Unfortunately the actual capabilities of this are that the filter-list received from the peer is applied only outbound to the same peer. This is a very promising technique for bogon route servers, but we need to enhance it. Please send comments. Michel. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Sat Sep 20 18:25:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25264; Sat, 20 Sep 2003 18:25:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0qAH-00020d-00; Sat, 20 Sep 2003 18:25:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0qAC-00020a-00; Sat, 20 Sep 2003 18:25:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0qA1-000429-Lg; Sat, 20 Sep 2003 18:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0q9R-0003vs-31 for idr@optimus.ietf.org; Sat, 20 Sep 2003 18:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25249 for ; Sat, 20 Sep 2003 18:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0q9J-00020K-00 for idr@ietf.org; Sat, 20 Sep 2003 18:24:17 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 1A0q98-0001zg-00 for idr@ietf.org; Sat, 20 Sep 2003 18:24:06 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 1E3A220299 for ; Sat, 20 Sep 2003 16:22:53 -0600 (MDT) Subject: Re: [idr] taxonomy of bogon filtering applied to route servers Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Sep 2003 16:22:53 -0600 Content-Transfer-Encoding: 7bit It would seem to me that this is more of an implementation/ "feature set" issue than protocol issue. With that said, I suppose I see some utility, but as discussed on other lists, it mostly just raises "the lazy bar", IMO. This message is probably better suited for the GROW mailing list, though I suspect the feeling there will be similar (then again, ....). -danny On Saturday, September 20, 2003, at 01:39 PM, Michel Py wrote: > idr chairs and folks, > > [I apologize in advance is this off-topic for this list] > > I was recently looking at the issue of bogon route-servers, and it > struck me that there would be little work to adapt BGP Prefix-Based > Outbound Route Filtering (ORF) to change it into what is desperately > needed for bogons. > > In a nutshell, the way I understand ORF is that the sending router > sends > the receiving router a prefix-list (or distribute-list, or as-path > list). When the receiving router receives the prefix-list, it applies > it > outbound towards the peer it received it from. > > The enhancement that would be needed would be to make the receiving > router capable of applying the received prefix-list to other peers, > especially inbound. This would likely involve naming the received ORF > and making it available to other peers. > > In other words, my idea is to use the ORF mechanism to propagate > prefix-lists to other peers, not for the purpose of filtering the > routes > sent to a peer and their associated handling but for the purpose of > filtering inbound routes coming from other peers of the receiving ORF > router. I was wondering what this WG thinks about it. > > I wrote a little taxonomy about IPv6 bogon filtering; this is very, > very > crude and I welcome your comments. > > Best, > Michel. > > > Taxonomy of bogon filtering. > ============================ > > There are five basic ways to handle the bogon filtering issue: > > 1. Manually configured prefix-lists. > 2. BGP feed of "bad" prefix aggregates. > 3. BGP feed of anomalies. > 4. BGP feed of "good" prefixes. > 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). > > > 1. Manually configured prefix-lists. > ------------------------------------ > > This involves one or more volunteers to maintain a prefix-list that is > to be configured manually on routers. The issue with this is change > management: as we have seen with the 69/8 fiasco not that long ago, > some > people do _not_ update their filters regularly, and when the bogon > prefix-list is modified it can take weeks to be upgraded, which is not > good. However, in terms of granularity, this is what gives the finest > control. > > > 2. BGP feed of "bad" prefix aggregates. > --------------------------------------- > > This is the mechanism currently used by team cymru's bogon route > servers > (http://www.cymru.com/BGP/bogon-rs.html). The issue with this is that > the domain of applicability is limited to networks that do not receive > a > full feed. If one gets a full feed, this method does not prevent bad > prefixes if they are smaller than the bogon feed, because of the > longest > match rule. So, this is an option only for networks with private > peering > only and a default route outside, because a blackhole route is > installed > to dump all the bogon traffic instead of sending it to the default > route. > > > 3. BGP feed of anomalies. > ------------------------- > > A finer version of the previous one. Real-time monitoring of the > routing > table at different points allows to build a list of bad announcements. > Contrary to the previous option, this allows to deal with specific > announcements. The issue with this is that it does not prevent the bad > announcement to be received, it actually adds another path that will be > made preferred to the offending announcement and used to dump the > traffic in a blackhole. Compared to the feeding of bad aggregates, this > method extends the domain of applicability to defaultless networks, at > the expense of aggravating the routing table size issue. > > > 4. BGP feed of "good" prefixes. > ------------------------------- > > This is an IPv6-only topic that was discussed outside of idr. Please > don't pay attention to it in this context. > > > 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). > ----------------------------------------------------------------- > > http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt > http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/ > products_feature_ > guide09186a0080134a57.html > > Unfortunately the actual capabilities of this are that the filter-list > received from the peer is applied only outbound to the same peer. This > is a very promising technique for bogon route servers, but we need to > enhance it. > > Please send comments. > > Michel. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Sat Sep 20 18:25:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25286 for ; Sat, 20 Sep 2003 18:25:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0qAL-00044a-6a for idr-archive@odin.ietf.org; Sat, 20 Sep 2003 18:25:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KMPLWo015657 for idr-archive@odin.ietf.org; Sat, 20 Sep 2003 18:25:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0qAL-00044S-1E for idr-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 18:25:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25264; Sat, 20 Sep 2003 18:25:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0qAH-00020d-00; Sat, 20 Sep 2003 18:25:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0qAC-00020a-00; Sat, 20 Sep 2003 18:25:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0qA1-000429-Lg; Sat, 20 Sep 2003 18:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0q9R-0003vs-31 for idr@optimus.ietf.org; Sat, 20 Sep 2003 18:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25249 for ; Sat, 20 Sep 2003 18:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0q9J-00020K-00 for idr@ietf.org; Sat, 20 Sep 2003 18:24:17 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 1A0q98-0001zg-00 for idr@ietf.org; Sat, 20 Sep 2003 18:24:06 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 1E3A220299 for ; Sat, 20 Sep 2003 16:22:53 -0600 (MDT) Subject: Re: [idr] taxonomy of bogon filtering applied to route servers Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Sep 2003 16:22:53 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It would seem to me that this is more of an implementation/ "feature set" issue than protocol issue. With that said, I suppose I see some utility, but as discussed on other lists, it mostly just raises "the lazy bar", IMO. This message is probably better suited for the GROW mailing list, though I suspect the feeling there will be similar (then again, ....). -danny On Saturday, September 20, 2003, at 01:39 PM, Michel Py wrote: > idr chairs and folks, > > [I apologize in advance is this off-topic for this list] > > I was recently looking at the issue of bogon route-servers, and it > struck me that there would be little work to adapt BGP Prefix-Based > Outbound Route Filtering (ORF) to change it into what is desperately > needed for bogons. > > In a nutshell, the way I understand ORF is that the sending router > sends > the receiving router a prefix-list (or distribute-list, or as-path > list). When the receiving router receives the prefix-list, it applies > it > outbound towards the peer it received it from. > > The enhancement that would be needed would be to make the receiving > router capable of applying the received prefix-list to other peers, > especially inbound. This would likely involve naming the received ORF > and making it available to other peers. > > In other words, my idea is to use the ORF mechanism to propagate > prefix-lists to other peers, not for the purpose of filtering the > routes > sent to a peer and their associated handling but for the purpose of > filtering inbound routes coming from other peers of the receiving ORF > router. I was wondering what this WG thinks about it. > > I wrote a little taxonomy about IPv6 bogon filtering; this is very, > very > crude and I welcome your comments. > > Best, > Michel. > > > Taxonomy of bogon filtering. > ============================ > > There are five basic ways to handle the bogon filtering issue: > > 1. Manually configured prefix-lists. > 2. BGP feed of "bad" prefix aggregates. > 3. BGP feed of anomalies. > 4. BGP feed of "good" prefixes. > 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). > > > 1. Manually configured prefix-lists. > ------------------------------------ > > This involves one or more volunteers to maintain a prefix-list that is > to be configured manually on routers. The issue with this is change > management: as we have seen with the 69/8 fiasco not that long ago, > some > people do _not_ update their filters regularly, and when the bogon > prefix-list is modified it can take weeks to be upgraded, which is not > good. However, in terms of granularity, this is what gives the finest > control. > > > 2. BGP feed of "bad" prefix aggregates. > --------------------------------------- > > This is the mechanism currently used by team cymru's bogon route > servers > (http://www.cymru.com/BGP/bogon-rs.html). The issue with this is that > the domain of applicability is limited to networks that do not receive > a > full feed. If one gets a full feed, this method does not prevent bad > prefixes if they are smaller than the bogon feed, because of the > longest > match rule. So, this is an option only for networks with private > peering > only and a default route outside, because a blackhole route is > installed > to dump all the bogon traffic instead of sending it to the default > route. > > > 3. BGP feed of anomalies. > ------------------------- > > A finer version of the previous one. Real-time monitoring of the > routing > table at different points allows to build a list of bad announcements. > Contrary to the previous option, this allows to deal with specific > announcements. The issue with this is that it does not prevent the bad > announcement to be received, it actually adds another path that will be > made preferred to the offending announcement and used to dump the > traffic in a blackhole. Compared to the feeding of bad aggregates, this > method extends the domain of applicability to defaultless networks, at > the expense of aggravating the routing table size issue. > > > 4. BGP feed of "good" prefixes. > ------------------------------- > > This is an IPv6-only topic that was discussed outside of idr. Please > don't pay attention to it in this context. > > > 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). > ----------------------------------------------------------------- > > http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt > http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/ > products_feature_ > guide09186a0080134a57.html > > Unfortunately the actual capabilities of this are that the filter-list > received from the peer is applied only outbound to the same peer. This > is a very promising technique for bogon route servers, but we need to > enhance it. > > Please send comments. > > Michel. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Sep 22 14:47:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00066; Mon, 22 Sep 2003 14:47:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1VhA-0006Dp-V6; Mon, 22 Sep 2003 14:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Vgh-0006Ap-8t for idr@optimus.ietf.org; Mon, 22 Sep 2003 14:45:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29766; Mon, 22 Sep 2003 14:45:21 -0400 (EDT) Message-Id: <200309221845.OAA29766@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 14:45:21 -0400 --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-4 Protocol Analysis Author(s) : D. Meyer, K. Patel Filename : draft-ietf-idr-bgp-analysis-04.txt Pages : 20 Date : 2003-9-22 The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for'the second report', as described in Section 6.0 of RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP protocol, and analyzes the protocol with respect to scaling and performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-analysis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-analysis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-22132834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-22132834.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Sep 22 14:47:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00168 for ; Mon, 22 Sep 2003 14:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ViK-0006fZ-Tv for idr-archive@odin.ietf.org; Mon, 22 Sep 2003 14:47:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MIlCVI025636 for idr-archive@odin.ietf.org; Mon, 22 Sep 2003 14:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ViK-0006fO-OQ for idr-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 14:47:12 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00066; Mon, 22 Sep 2003 14:47:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1VhA-0006Dp-V6; Mon, 22 Sep 2003 14:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Vgh-0006Ap-8t for idr@optimus.ietf.org; Mon, 22 Sep 2003 14:45:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29766; Mon, 22 Sep 2003 14:45:21 -0400 (EDT) Message-Id: <200309221845.OAA29766@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 14:45:21 -0400 --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-4 Protocol Analysis Author(s) : D. Meyer, K. Patel Filename : draft-ietf-idr-bgp-analysis-04.txt Pages : 20 Date : 2003-9-22 The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for'the second report', as described in Section 6.0 of RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP protocol, and analyzes the protocol with respect to scaling and performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-analysis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-analysis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-22132834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-22132834.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 23 18:54:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11947; Tue, 23 Sep 2003 18:54:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1w35-0000OO-00; Tue, 23 Sep 2003 18:54:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1w35-0000OJ-00; Tue, 23 Sep 2003 18:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w2j-0003kl-1E; Tue, 23 Sep 2003 18:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w1k-0003kK-5G for idr@optimus.ietf.org; Tue, 23 Sep 2003 18:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11898 for ; Tue, 23 Sep 2003 18:52:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1w1g-0000NH-00 for idr@ietf.org; Tue, 23 Sep 2003 18:52:56 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A1w1g-0000N2-00 for idr@ietf.org; Tue, 23 Sep 2003 18:52:56 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8NMqJv24319 for ; Tue, 23 Sep 2003 18:52:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 18:52:20 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540702832B@zcard0k6.ca.nortel.com> From: "Kirk Smith" To: idr@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38225.5819CCB4" Subject: [Idr] Questions about operation of draft-ietf-idr-route-filter-09.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 18:52:19 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38225.5819CCB4 Content-Type: text/plain I have a question about the operation (Section 8) of receiving a route refresh request containing ORFs. In particular, the draft states: "If the When-to-Refresh indicates IMMEDIATE, then after processing all the ORF entries carried in the message the speaker re-advertises to the peer routes from the Adj-RIB-Out associated with the peer that have the same AFI/SAFI as what is carried in the message, and taking into account all the ORF entries received from the peer. However, the routes that have not be affected by the ORF entries carried in the message SHOULT NOT be re-advertised to the peer." I take this to mean, that BGP will advertise those routes which match the ORF entries contained in the UPDATE message being processed (and possibly any previous marked as DEFER), but not those which were already processed and advertised to this peer. For example, say I have 2 BGP speakers, X and Y. X sends a route refresh message to Y containing ORF value A with IMMEDIATE. I assume any routes matching A (and the AFI/SAFI) will be sent to X from Y. Now, say X sends a route refresh message to Y containing ORF value B with IMMEDIATE. I assume only those routes matching B will be sent to X from Y. i.e. the routes matching ORF A will not be readvertised. Is my assumption correct? Thanks, Kirk. ------_=_NextPart_001_01C38225.5819CCB4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Questions about operation of draft-ietf-idr-route-filter-09.txt =

I have a question about the operation = (Section 8) of receiving a route refresh request containing = ORFs.

In particular, the draft = states:
"If the When-to-Refresh = indicates IMMEDIATE, then after processing all the ORF entries carried = in the message the speaker re-advertises to the peer routes from the = Adj-RIB-Out associated with the peer that have the same AFI/SAFI as = what is carried in the message, and taking into account all the ORF = entries received from the peer. However, the routes that have not be = affected by the ORF entries carried in the message SHOULT NOT be = re-advertised to the peer."

  I take this to mean, that BGP = will advertise those routes which match the ORF entries contained in = the UPDATE message being processed (and possibly any previous marked as = DEFER), but not those which were already processed and advertised to = this peer.

For example, say I have 2 BGP = speakers, X and Y.
X sends a route refresh message to Y = containing ORF value A with IMMEDIATE.
I assume any routes matching A (and = the AFI/SAFI) will be sent to X from Y.
Now, say X sends a route refresh = message to Y containing ORF value B with IMMEDIATE.
I assume only those routes matching = B will be sent to X from Y.  i.e. the routes matching ORF A will = not be readvertised.

Is my assumption correct?

Thanks,
  Kirk.

------_=_NextPart_001_01C38225.5819CCB4-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 23 18:54:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11977 for ; Tue, 23 Sep 2003 18:54:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w39-0003o5-Dv for idr-archive@odin.ietf.org; Tue, 23 Sep 2003 18:54:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NMsRV9014627 for idr-archive@odin.ietf.org; Tue, 23 Sep 2003 18:54:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w39-0003nq-AD for idr-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 18:54:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11947; Tue, 23 Sep 2003 18:54:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1w35-0000OO-00; Tue, 23 Sep 2003 18:54:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1w35-0000OJ-00; Tue, 23 Sep 2003 18:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w2j-0003kl-1E; Tue, 23 Sep 2003 18:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w1k-0003kK-5G for idr@optimus.ietf.org; Tue, 23 Sep 2003 18:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11898 for ; Tue, 23 Sep 2003 18:52:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1w1g-0000NH-00 for idr@ietf.org; Tue, 23 Sep 2003 18:52:56 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A1w1g-0000N2-00 for idr@ietf.org; Tue, 23 Sep 2003 18:52:56 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8NMqJv24319 for ; Tue, 23 Sep 2003 18:52:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 18:52:20 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540702832B@zcard0k6.ca.nortel.com> From: "Kirk Smith" To: idr@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38225.5819CCB4" Subject: [Idr] Questions about operation of draft-ietf-idr-route-filter-09.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 18:52:19 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38225.5819CCB4 Content-Type: text/plain I have a question about the operation (Section 8) of receiving a route refresh request containing ORFs. In particular, the draft states: "If the When-to-Refresh indicates IMMEDIATE, then after processing all the ORF entries carried in the message the speaker re-advertises to the peer routes from the Adj-RIB-Out associated with the peer that have the same AFI/SAFI as what is carried in the message, and taking into account all the ORF entries received from the peer. However, the routes that have not be affected by the ORF entries carried in the message SHOULT NOT be re-advertised to the peer." I take this to mean, that BGP will advertise those routes which match the ORF entries contained in the UPDATE message being processed (and possibly any previous marked as DEFER), but not those which were already processed and advertised to this peer. For example, say I have 2 BGP speakers, X and Y. X sends a route refresh message to Y containing ORF value A with IMMEDIATE. I assume any routes matching A (and the AFI/SAFI) will be sent to X from Y. Now, say X sends a route refresh message to Y containing ORF value B with IMMEDIATE. I assume only those routes matching B will be sent to X from Y. i.e. the routes matching ORF A will not be readvertised. Is my assumption correct? Thanks, Kirk. ------_=_NextPart_001_01C38225.5819CCB4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Questions about operation of draft-ietf-idr-route-filter-09.txt =

I have a question about the operation = (Section 8) of receiving a route refresh request containing = ORFs.

In particular, the draft = states:
"If the When-to-Refresh = indicates IMMEDIATE, then after processing all the ORF entries carried = in the message the speaker re-advertises to the peer routes from the = Adj-RIB-Out associated with the peer that have the same AFI/SAFI as = what is carried in the message, and taking into account all the ORF = entries received from the peer. However, the routes that have not be = affected by the ORF entries carried in the message SHOULT NOT be = re-advertised to the peer."

  I take this to mean, that BGP = will advertise those routes which match the ORF entries contained in = the UPDATE message being processed (and possibly any previous marked as = DEFER), but not those which were already processed and advertised to = this peer.

For example, say I have 2 BGP = speakers, X and Y.
X sends a route refresh message to Y = containing ORF value A with IMMEDIATE.
I assume any routes matching A (and = the AFI/SAFI) will be sent to X from Y.
Now, say X sends a route refresh = message to Y containing ORF value B with IMMEDIATE.
I assume only those routes matching = B will be sent to X from Y.  i.e. the routes matching ORF A will = not be readvertised.

Is my assumption correct?

Thanks,
  Kirk.

------_=_NextPart_001_01C38225.5819CCB4-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 23 21:31:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17039; Tue, 23 Sep 2003 21:31:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yUh-0002yc-Je; Tue, 23 Sep 2003 21:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yU7-0002wJ-8h for idr@optimus.ietf.org; Tue, 23 Sep 2003 21:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16933 for ; Tue, 23 Sep 2003 21:30:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yU4-00028P-00 for idr@ietf.org; Tue, 23 Sep 2003 21:30:24 -0400 Received: from [81.199.83.116] (helo=mrson2505.com) by ietf-mx with smtp (Exim 4.12) id 1A1yTz-00027R-00 for idr@ietf.org; Tue, 23 Sep 2003 21:30:22 -0400 From: "Dr Mrs Mariam Abacha" Reply-To: mariam2abacha@gawab.com To: idr@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: Content-Transfer-Encoding: quoted-printable Subject: [Idr] Respond soonest Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 18:30:19 -0700 Content-Transfer-Encoding: quoted-printable Attn=3ASir=2FMa=2C I salute you in the name of Allah=2Cthe most high God=2EI am Mrs=2E Mariam Abacha=2C the widow of the late General Sani Abacha=2C former Nigerian Military head of state who died mysteriously as a result of Cardiac arrest=2ESince my husband died=2C my family has been under restriction of movement and that not withstanding=2C we have been molested and constantly under watch by the seemingly Agent=2C above all our bank accounts here and abroad have been frozen by the Nigerian civilian Government=2E Furthermore=2C my eldest son is in detention by the Nigerian Government for more interrogation about my husband assets and some vital documents=2E Following the recent discovery of my husband's bank account by the Nigerian Government with my son's bank in which a huge some of US$700 million and Dutch Mark 450 million was lodged and f1=2E6 billion belonging to my late husband was seized by the Government of Nigeria=2EI therefore wish to personally appeal to you seriously and religious for your urgent assistance to transfer the sum of US$25=2E5 million into your account in your country where I believe it will be safe=2C since we can not leave the country=2C due to the restriction of the movement imposed on the members of my family by the Nigerian Government=2EYou can contact me through my farmily lawyer's number 234 80333 13642=28barister Buba Mohhamed=29 And he shall arrange with you for a face-to face meeting outside Nigeria inorder to lease with him toward effective completion ofthis transaction=2E However=2C arrangement have been put in place to move this money out of the country=2C in the secret vault through a security Company to any of West African States=2C Europe=2CAmerica as soon as you indicate your interest=2C my Lawyer shall send to you the Security Deposit Certificate and Airway Bill of the luggage and other related documents so that you an claim the luggage=2C which shall be tagged FAMILY TREASUERS=2E Conclusively=2C we have agreed to offer you 30% of the total sum while 70% is to be held on trust by you until we can decide on a suitable business investment in your country subsequent to our free movement by the Nigerian Government=2EPlease=2C reply urgently and treat with absolute confidentiality and sincerity=2E Yours sincerely=2C Mariam Abacha=2E N=2EB=2EYour reponse will determine the transaction and please all information guarantee safety=2E _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 23 21:32:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17100 for ; Tue, 23 Sep 2003 21:32:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yVT-00039C-Ic for idr-archive@odin.ietf.org; Tue, 23 Sep 2003 21:31:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O1VpeD012092 for idr-archive@odin.ietf.org; Tue, 23 Sep 2003 21:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yVT-00038x-FT for idr-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 21:31:51 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17039; Tue, 23 Sep 2003 21:31:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yUh-0002yc-Je; Tue, 23 Sep 2003 21:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yU7-0002wJ-8h for idr@optimus.ietf.org; Tue, 23 Sep 2003 21:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16933 for ; Tue, 23 Sep 2003 21:30:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yU4-00028P-00 for idr@ietf.org; Tue, 23 Sep 2003 21:30:24 -0400 Received: from [81.199.83.116] (helo=mrson2505.com) by ietf-mx with smtp (Exim 4.12) id 1A1yTz-00027R-00 for idr@ietf.org; Tue, 23 Sep 2003 21:30:22 -0400 From: "Dr Mrs Mariam Abacha" Reply-To: mariam2abacha@gawab.com To: idr@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: Content-Transfer-Encoding: quoted-printable Subject: [Idr] Respond soonest Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 18:30:19 -0700 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Attn=3ASir=2FMa=2C I salute you in the name of Allah=2Cthe most high God=2EI am Mrs=2E Mariam Abacha=2C the widow of the late General Sani Abacha=2C former Nigerian Military head of state who died mysteriously as a result of Cardiac arrest=2ESince my husband died=2C my family has been under restriction of movement and that not withstanding=2C we have been molested and constantly under watch by the seemingly Agent=2C above all our bank accounts here and abroad have been frozen by the Nigerian civilian Government=2E Furthermore=2C my eldest son is in detention by the Nigerian Government for more interrogation about my husband assets and some vital documents=2E Following the recent discovery of my husband's bank account by the Nigerian Government with my son's bank in which a huge some of US$700 million and Dutch Mark 450 million was lodged and f1=2E6 billion belonging to my late husband was seized by the Government of Nigeria=2EI therefore wish to personally appeal to you seriously and religious for your urgent assistance to transfer the sum of US$25=2E5 million into your account in your country where I believe it will be safe=2C since we can not leave the country=2C due to the restriction of the movement imposed on the members of my family by the Nigerian Government=2EYou can contact me through my farmily lawyer's number 234 80333 13642=28barister Buba Mohhamed=29 And he shall arrange with you for a face-to face meeting outside Nigeria inorder to lease with him toward effective completion ofthis transaction=2E However=2C arrangement have been put in place to move this money out of the country=2C in the secret vault through a security Company to any of West African States=2C Europe=2CAmerica as soon as you indicate your interest=2C my Lawyer shall send to you the Security Deposit Certificate and Airway Bill of the luggage and other related documents so that you an claim the luggage=2C which shall be tagged FAMILY TREASUERS=2E Conclusively=2C we have agreed to offer you 30% of the total sum while 70% is to be held on trust by you until we can decide on a suitable business investment in your country subsequent to our free movement by the Nigerian Government=2EPlease=2C reply urgently and treat with absolute confidentiality and sincerity=2E Yours sincerely=2C Mariam Abacha=2E N=2EB=2EYour reponse will determine the transaction and please all information guarantee safety=2E _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Sep 24 03:52:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00129; Wed, 24 Sep 2003 03:52:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24RN-0003Hb-OC; Wed, 24 Sep 2003 03:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24QQ-0003G6-Nb for idr@optimus.ietf.org; Wed, 24 Sep 2003 03:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29717 for ; Wed, 24 Sep 2003 03:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A24QO-0007I7-00 for idr@ietf.org; Wed, 24 Sep 2003 03:51:00 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A24QM-0007GO-00 for idr@ietf.org; Wed, 24 Sep 2003 03:50:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8O7oRn08766; Wed, 24 Sep 2003 10:50:28 +0300 From: Pekka Savola To: idr@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Idr] comments on idr-bgp4-20 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 10:50:26 +0300 (EEST) Hi, [note, I'm not subscribed to the idr list] Alex solicited ops-dir for folks to review bgp4-20 spec. After almost half a year, I finally found the time to look at it. Comments below. I tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at least on the quick glance, I didn't find major overlaps. Overview: - the spec is in pretty good shape, but I'm not sure if all the features listed are really full standard material.. it might be better to separate some of them (e.g. anything relating to aggregation) to a separate doc (so that we'd have a much tigher and better real base spec), and recycle it at DS, but that might be much more effort.. not sure if something like that would be worth it. General thoughts on going to full standard: - If we want to go for full standard, I have to question the usefulness of several BGP features: - AS_SET AS_PATH attribute - whole route aggregation concept (nowadays, it seems to be causing more trouble than it's worth -- instead of proper advertisements, just automatically aggregate instead of fixing the advertisements to begin with). Maybe pver 10 years ago it may have been relevant if all the edge BGP routers might not support BGP-4 or CIDR.. - about N++ different cases of third-party nexthop usage. As a general observation from the text: - I skipped section 8 on FSM, as it was really boring, and I'm not sure whehter it's of any use keeping it in the base spec. - I got major headache when trying to read the aggregating rules especially in section 9.2.2.2 (and that was supposed to be the _simple_ rules :-(!!!) and ended up skipping them. substantial ----------- 1) Section 3 on Summary of the Operations, states: In the context of this document we assume that a BGP speaker adver- tises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. this "usability" requirement is in conflict with section 4.3 on UPDATE message format: An UPDATE message is used to advertise feasible routes sharing common path attributes to a peer, [...] ==> in particular note that "feasible" is a superset of "only those routes the router itself uses" (compare to "those routes the router itself _could_ use if they were the most preferred ones"), right? ==> also note that the former definition is (IMHO) operationally unsound. It prevents you from advertising P-t-P addresses and loopbacks (which also reside in IGP) using BGP, because the IGP distance is lower than BGP and "BGP route is never used in forwarding". (depending on how you interpret that). IMHO, this really needs to be changed to be OK. 2) The OPEN message format is confusing. Why on earth do you have those empty bits there? Are they null-padding or just a typographical convention for the clarity of the diagram (the latter)? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==> I strongly recommend to either: 1) go back to standard format, or 2) rephrase the message format similar with UPDATE messages, i.e., drop all the pretense about field lengths, bits 0-31, etc. 3) there is significant confusion on what "locally originated" means. It is not clear whether this refers to "local to the BGP speaker (i.e., the same system)" or "local to the routing domain (i.e., the same AS)". This must be clarified in the text below, and the text should be reviewed. 5.1.3 NEXT_HOP The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the des- tinations listed in the UPDATE message. The NEXT_HOP attribute is calculated as follows. 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. When announcing a locally originated route to an internal peer, the BGP speaker SHOULD use as the NEXT_HOP the interface address of the router through which the announced network is reachable for the speaker; if the route is directly connected to the speaker, or the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, then the BGP speaker SHOULD use for the NEXT_HOP attribute its own IP address (the address of the interface that is used to reach the peer). 4) there appears to have been added some bogosities about inter-AS traffic engineering in section 9.3: - If the local AS appears in the AS path of the new route being considered, then that new route can not be viewed as better than any other route (provided that the speaker is configured to accept such routes). If such a route were ever used, a routing loop could result. and: The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. ==> what do these have to do with base spec? I don't think they're operationally feasible or used. Remove any indication that it's OK to receive your own AS in the routes you receive!! 5) the reasoning for this section is not clear. It seems to be two parts (the second one starting at "These routes..."). It seems partially, at least for the second part, a set of operational guidelines.. which probably don't have anything to do with the BGP spec! 9.4 Originating BGP routes A BGP speaker may originate BGP routes by injecting routing informa- tion acquired by some other means (e.g. via an IGP) into BGP. A BGP speaker that originates BGP routes assigns the degree of preference to these routes by passing them through the Decision Process (see Section 9.1). These routes MAY also be distributed to other BGP speakers within the local AS as part of the update process (see Sec- tion 9.2). The decision whether to distribute non-BGP acquired routes within an AS via BGP or not depends on the environment within the AS (e.g. type of IGP) and SHOULD be controlled via configuration. 6) references; note that as the Security Consideration section is a bit short, the vulnerability analysis should be a *NORMATIVE* reference. However, one must ask here and with RFC2385 as well whether normative references are OK from Full Standard to a lower maturity level. Unless this has already been investigated, it may be worth checking with the ADs that this is OK. BGP vulnerabilities analysis is discussed in [XXX]. Normative References [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC2385, August 1998. Non-normative References [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- ietf-idr-bgp-vuln-00.txt, work in progress semi-substantial ---------------- ==> I'd add "Decision Process", "Routing Table", and "BGP route" in the terminology. (Especially the last one is a bit shady, see more comments later.) Adj-RIB-In Adj-RIBs-In Adj-RIB-Out Adj-RIBs-Out ==> in some places, one seems to use "Adj-RIBs-{In,Out}", in some others, "Adj-RIB-{In,Out}". The plural/singular form should be consistent. BGP speaker A router that implements BGP. ==> uhh, no. Throughout the text "BGP speaker" is used to refer to BGP-*enabled* routers. Implementation is a required but not sufficient condition to that. Consider rewording to something like: BGP speaker A router that implements and has been configured to use BGP. .... BGP Identifier: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. ==> the last sentence is confusing "same for every local interface".. yeah, right, but interfaces are irrelevant here. Also, this ignores the fact that it's perfectly legal to change BGP identifiers after startup but prior to establishing a BGP session. Consider rewording to something like: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined prior to establishing BGP sessions and is the same for every session the BGP speaker. ... Path Attributes: A variable length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple of variable length. ==> should a simple diagram be added here, just like in section 4.2? The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). ==> this and the following descriptions on attributes are out of place if you have not described the remaining categories (because they're used when describing the attributes in the next page), that is, discretionary and mandatory. Consider rewording the above to something like: The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). Well-known attributes can be either mandatory (MUST be included in every UPDATE message that contains NLRI), or discretionary (inclusion not required). ... All well-known attributes MUST be passed along (after proper updat- ing, if necessary) to other BGP peers. ==> LOCAL-PREF is an exception here. I also note that the BGP's definition of "transitive" is different ("unrecognized optional attributes are only passed onward when the transitive bit is set, but recognized optional attributes are always passed onward") from the apparent language ("always passed along"), and might use a bit of clarification. ... b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it is legal to prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. ==> the text here seems confusing because it is not clear whether things are added at the beginning or at the end of the segments, for example: "the _last_ element sequence (put it in the _leftmost_ position)" .. I think this requires more precise language on which end of the segment these values are really inserted. I.e., is it "physically" (in memory) left-to-right (from more recent to more distant), or just interpreted that way? This has significant impact on the last sentence of section 1) in case of overflows and the like. Whenever the modification of the AS_PATH attribute calls for includ- ing or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration. ==> what about prepending/adding someone else's AS? Is this relevant enough to be considered? A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers. ==> the second line seems out-of-place here. I assume it means that the router must not perform automatic de-aggregation, not that the router must not have more specific routes to advertise. In any case, a rewording might be in order, e.g. like: A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that is, generating more specifics by de-aggregating a route is forbidden. (note that this actually makes the statement stronger, and more in line of 9.1.4, that you should not do it even locally.) If the Length field of the message header is less than 19 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 19, or if the Length field of a NOTIFICATION message is less than the mini- mum length of the NOTIFICATION message, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field. ==> convert this to a bulleted list or something, so it's easier to read, please! :-) The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct: a) It MUST NOT be the IP address of the receiving speaker b) In the case of an EBGP where the sender and receiver are one IP hop away from each other, either the IP address in the NEXT_HOP MUST be the sender's IP address (that is used to establish the BGP connection), or the interface associated with the NEXT_HOP IP address MUST share a common subnet with the receiving BGP speaker. ==> what's exactly the case for the first case of b)? Couldn't thid be cleaned a bit (it seems to me that the second case is a superset of the first)? In addition, I'd recommend rewording "one IP hop away" -- that begs the question whether you mean "direct neighbors" or "just one transit router". When thinking of it more, the former seems apparent, but a different wording might flesh this out better. If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. ==> this is confusing, especially the end, beginning from "That is, ..." and should be reworded a bit (does it cover only deaggregation or more specifics in general?), like: If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, one must not generate more specifics of the NLRI of this route. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. However, accepting more specific advertisments which an aggregate route covers is acceptable. ... A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised. ==> and now we get back to the definition of "same BGP route"? Identical prefix carried over BGP? Identical prefix carried over BGP with identical attributes?" I'm assuming the former, otherwise (at least!) the above should be clarified. Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure separately to path attributes of like type and to the Network Layer Reachability Information. ==> the last line sounds really weird; consider: - s/like/the same/ ? - add more text after the NLRI, like "NLRI field" ? typos or other editorials ------------------------- ==> there should not be hyphenation at the linebreaks. This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. ==> s/extention/extension/ (two places) 3.2 Routing Information Bases The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts: ==> the subject is in plural form ("RIBs"), but the text begins as singular ("The RIB"). Consider which one to use? a) ORIGIN (Type Code 1): b) AS_PATH (Type Code 2): ==> kill the extra spaces before ORIGIN and NEXT_HOP. 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). ==> rewrite the last one as: last element of the sequence, putting it in the leftmost position. A BGP speaker MUST IMPLEMENT a mechanism based on local configuration ==> s/IMPLEMENT/implement/ used by a BGP speaker's decision process to discriminate ==> s/decision process/Decision Process/ (similar in a few other places?) attribute needs to be cognizant of the fact that the actual path to ==> s/cognizant/aware/ 6. BGP Error Handling. ==> remove the periods from at the end of section titles, esp. in subctions of section 6. issue a open collision dump [Event 23]. When the local system receives a open collision dump event [Event 23], the ==> s/a open/an open/ (two times) installed in LocRib and will be excluded from the next phase of route ==> s/LocRib/Loc-RIB/ all AS used to form the aggreagate in an AS_SET or add the ==> s/aggreagate/aggregate/ is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be ==> pick either "deaggregate" or "de-aggregate" and stick to that. have the origin attribute with the value EGP. In all other case ==> s/case/cases/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Sep 24 03:53:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00276 for ; Wed, 24 Sep 2003 03:53:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24SC-0003PQ-Pp for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 03:52:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O7qqge013098 for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 03:52:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24SC-0003PB-GF for idr-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 03:52:52 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00129; Wed, 24 Sep 2003 03:52:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24RN-0003Hb-OC; Wed, 24 Sep 2003 03:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24QQ-0003G6-Nb for idr@optimus.ietf.org; Wed, 24 Sep 2003 03:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29717 for ; Wed, 24 Sep 2003 03:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A24QO-0007I7-00 for idr@ietf.org; Wed, 24 Sep 2003 03:51:00 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A24QM-0007GO-00 for idr@ietf.org; Wed, 24 Sep 2003 03:50:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8O7oRn08766; Wed, 24 Sep 2003 10:50:28 +0300 From: Pekka Savola To: idr@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Idr] comments on idr-bgp4-20 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 10:50:26 +0300 (EEST) Hi, [note, I'm not subscribed to the idr list] Alex solicited ops-dir for folks to review bgp4-20 spec. After almost half a year, I finally found the time to look at it. Comments below. I tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at least on the quick glance, I didn't find major overlaps. Overview: - the spec is in pretty good shape, but I'm not sure if all the features listed are really full standard material.. it might be better to separate some of them (e.g. anything relating to aggregation) to a separate doc (so that we'd have a much tigher and better real base spec), and recycle it at DS, but that might be much more effort.. not sure if something like that would be worth it. General thoughts on going to full standard: - If we want to go for full standard, I have to question the usefulness of several BGP features: - AS_SET AS_PATH attribute - whole route aggregation concept (nowadays, it seems to be causing more trouble than it's worth -- instead of proper advertisements, just automatically aggregate instead of fixing the advertisements to begin with). Maybe pver 10 years ago it may have been relevant if all the edge BGP routers might not support BGP-4 or CIDR.. - about N++ different cases of third-party nexthop usage. As a general observation from the text: - I skipped section 8 on FSM, as it was really boring, and I'm not sure whehter it's of any use keeping it in the base spec. - I got major headache when trying to read the aggregating rules especially in section 9.2.2.2 (and that was supposed to be the _simple_ rules :-(!!!) and ended up skipping them. substantial ----------- 1) Section 3 on Summary of the Operations, states: In the context of this document we assume that a BGP speaker adver- tises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. this "usability" requirement is in conflict with section 4.3 on UPDATE message format: An UPDATE message is used to advertise feasible routes sharing common path attributes to a peer, [...] ==> in particular note that "feasible" is a superset of "only those routes the router itself uses" (compare to "those routes the router itself _could_ use if they were the most preferred ones"), right? ==> also note that the former definition is (IMHO) operationally unsound. It prevents you from advertising P-t-P addresses and loopbacks (which also reside in IGP) using BGP, because the IGP distance is lower than BGP and "BGP route is never used in forwarding". (depending on how you interpret that). IMHO, this really needs to be changed to be OK. 2) The OPEN message format is confusing. Why on earth do you have those empty bits there? Are they null-padding or just a typographical convention for the clarity of the diagram (the latter)? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==> I strongly recommend to either: 1) go back to standard format, or 2) rephrase the message format similar with UPDATE messages, i.e., drop all the pretense about field lengths, bits 0-31, etc. 3) there is significant confusion on what "locally originated" means. It is not clear whether this refers to "local to the BGP speaker (i.e., the same system)" or "local to the routing domain (i.e., the same AS)". This must be clarified in the text below, and the text should be reviewed. 5.1.3 NEXT_HOP The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the des- tinations listed in the UPDATE message. The NEXT_HOP attribute is calculated as follows. 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. When announcing a locally originated route to an internal peer, the BGP speaker SHOULD use as the NEXT_HOP the interface address of the router through which the announced network is reachable for the speaker; if the route is directly connected to the speaker, or the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, then the BGP speaker SHOULD use for the NEXT_HOP attribute its own IP address (the address of the interface that is used to reach the peer). 4) there appears to have been added some bogosities about inter-AS traffic engineering in section 9.3: - If the local AS appears in the AS path of the new route being considered, then that new route can not be viewed as better than any other route (provided that the speaker is configured to accept such routes). If such a route were ever used, a routing loop could result. and: The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. ==> what do these have to do with base spec? I don't think they're operationally feasible or used. Remove any indication that it's OK to receive your own AS in the routes you receive!! 5) the reasoning for this section is not clear. It seems to be two parts (the second one starting at "These routes..."). It seems partially, at least for the second part, a set of operational guidelines.. which probably don't have anything to do with the BGP spec! 9.4 Originating BGP routes A BGP speaker may originate BGP routes by injecting routing informa- tion acquired by some other means (e.g. via an IGP) into BGP. A BGP speaker that originates BGP routes assigns the degree of preference to these routes by passing them through the Decision Process (see Section 9.1). These routes MAY also be distributed to other BGP speakers within the local AS as part of the update process (see Sec- tion 9.2). The decision whether to distribute non-BGP acquired routes within an AS via BGP or not depends on the environment within the AS (e.g. type of IGP) and SHOULD be controlled via configuration. 6) references; note that as the Security Consideration section is a bit short, the vulnerability analysis should be a *NORMATIVE* reference. However, one must ask here and with RFC2385 as well whether normative references are OK from Full Standard to a lower maturity level. Unless this has already been investigated, it may be worth checking with the ADs that this is OK. BGP vulnerabilities analysis is discussed in [XXX]. Normative References [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC2385, August 1998. Non-normative References [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- ietf-idr-bgp-vuln-00.txt, work in progress semi-substantial ---------------- ==> I'd add "Decision Process", "Routing Table", and "BGP route" in the terminology. (Especially the last one is a bit shady, see more comments later.) Adj-RIB-In Adj-RIBs-In Adj-RIB-Out Adj-RIBs-Out ==> in some places, one seems to use "Adj-RIBs-{In,Out}", in some others, "Adj-RIB-{In,Out}". The plural/singular form should be consistent. BGP speaker A router that implements BGP. ==> uhh, no. Throughout the text "BGP speaker" is used to refer to BGP-*enabled* routers. Implementation is a required but not sufficient condition to that. Consider rewording to something like: BGP speaker A router that implements and has been configured to use BGP. .... BGP Identifier: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. ==> the last sentence is confusing "same for every local interface".. yeah, right, but interfaces are irrelevant here. Also, this ignores the fact that it's perfectly legal to change BGP identifiers after startup but prior to establishing a BGP session. Consider rewording to something like: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined prior to establishing BGP sessions and is the same for every session the BGP speaker. ... Path Attributes: A variable length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple of variable length. ==> should a simple diagram be added here, just like in section 4.2? The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). ==> this and the following descriptions on attributes are out of place if you have not described the remaining categories (because they're used when describing the attributes in the next page), that is, discretionary and mandatory. Consider rewording the above to something like: The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). Well-known attributes can be either mandatory (MUST be included in every UPDATE message that contains NLRI), or discretionary (inclusion not required). ... All well-known attributes MUST be passed along (after proper updat- ing, if necessary) to other BGP peers. ==> LOCAL-PREF is an exception here. I also note that the BGP's definition of "transitive" is different ("unrecognized optional attributes are only passed onward when the transitive bit is set, but recognized optional attributes are always passed onward") from the apparent language ("always passed along"), and might use a bit of clarification. ... b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it is legal to prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. ==> the text here seems confusing because it is not clear whether things are added at the beginning or at the end of the segments, for example: "the _last_ element sequence (put it in the _leftmost_ position)" .. I think this requires more precise language on which end of the segment these values are really inserted. I.e., is it "physically" (in memory) left-to-right (from more recent to more distant), or just interpreted that way? This has significant impact on the last sentence of section 1) in case of overflows and the like. Whenever the modification of the AS_PATH attribute calls for includ- ing or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration. ==> what about prepending/adding someone else's AS? Is this relevant enough to be considered? A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers. ==> the second line seems out-of-place here. I assume it means that the router must not perform automatic de-aggregation, not that the router must not have more specific routes to advertise. In any case, a rewording might be in order, e.g. like: A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that is, generating more specifics by de-aggregating a route is forbidden. (note that this actually makes the statement stronger, and more in line of 9.1.4, that you should not do it even locally.) If the Length field of the message header is less than 19 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 19, or if the Length field of a NOTIFICATION message is less than the mini- mum length of the NOTIFICATION message, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field. ==> convert this to a bulleted list or something, so it's easier to read, please! :-) The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct: a) It MUST NOT be the IP address of the receiving speaker b) In the case of an EBGP where the sender and receiver are one IP hop away from each other, either the IP address in the NEXT_HOP MUST be the sender's IP address (that is used to establish the BGP connection), or the interface associated with the NEXT_HOP IP address MUST share a common subnet with the receiving BGP speaker. ==> what's exactly the case for the first case of b)? Couldn't thid be cleaned a bit (it seems to me that the second case is a superset of the first)? In addition, I'd recommend rewording "one IP hop away" -- that begs the question whether you mean "direct neighbors" or "just one transit router". When thinking of it more, the former seems apparent, but a different wording might flesh this out better. If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. ==> this is confusing, especially the end, beginning from "That is, ..." and should be reworded a bit (does it cover only deaggregation or more specifics in general?), like: If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, one must not generate more specifics of the NLRI of this route. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. However, accepting more specific advertisments which an aggregate route covers is acceptable. ... A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised. ==> and now we get back to the definition of "same BGP route"? Identical prefix carried over BGP? Identical prefix carried over BGP with identical attributes?" I'm assuming the former, otherwise (at least!) the above should be clarified. Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure separately to path attributes of like type and to the Network Layer Reachability Information. ==> the last line sounds really weird; consider: - s/like/the same/ ? - add more text after the NLRI, like "NLRI field" ? typos or other editorials ------------------------- ==> there should not be hyphenation at the linebreaks. This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. ==> s/extention/extension/ (two places) 3.2 Routing Information Bases The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts: ==> the subject is in plural form ("RIBs"), but the text begins as singular ("The RIB"). Consider which one to use? a) ORIGIN (Type Code 1): b) AS_PATH (Type Code 2): ==> kill the extra spaces before ORIGIN and NEXT_HOP. 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). ==> rewrite the last one as: last element of the sequence, putting it in the leftmost position. A BGP speaker MUST IMPLEMENT a mechanism based on local configuration ==> s/IMPLEMENT/implement/ used by a BGP speaker's decision process to discriminate ==> s/decision process/Decision Process/ (similar in a few other places?) attribute needs to be cognizant of the fact that the actual path to ==> s/cognizant/aware/ 6. BGP Error Handling. ==> remove the periods from at the end of section titles, esp. in subctions of section 6. issue a open collision dump [Event 23]. When the local system receives a open collision dump event [Event 23], the ==> s/a open/an open/ (two times) installed in LocRib and will be excluded from the next phase of route ==> s/LocRib/Loc-RIB/ all AS used to form the aggreagate in an AS_SET or add the ==> s/aggreagate/aggregate/ is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be ==> pick either "deaggregate" or "de-aggregate" and stick to that. have the origin attribute with the value EGP. In all other case ==> s/case/cases/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Sep 24 07:01:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06583; Wed, 24 Sep 2003 07:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27OP-0001kT-00; Wed, 24 Sep 2003 07:01:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A27OO-0001kQ-00; Wed, 24 Sep 2003 07:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27OH-0006Et-E6; Wed, 24 Sep 2003 07:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27NN-0006Am-0b for idr@optimus.ietf.org; Wed, 24 Sep 2003 07:00:05 -0400 Received: from n2now2300.com (80.179.254.186.forward.012.net.il [80.179.254.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06497 for ; Wed, 24 Sep 2003 06:59:44 -0400 (EDT) Message-Id: <200309241059.GAA06497@ietf.org> From: "Dr.Douglas Akpeki" Reply-To: d_akpeki@tiscali.co.uk To: idr@ietf.org X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Idr] INVITATION TO PARTNERSHIP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 11:59:36 +0100 Content-Transfer-Encoding: quoted-printable Dear Sir=2C REQUEST FOR YOUR UNRESERVED ASSISTANCE=2E This letter may come to you as a surprise but it was borne out of my sincere desire to share a mutual business relationship with you=2E First=2C your strictest confidence in this transaction is highly solicited=2E This is by virtue of its nature as being utterly confidential and top secret=2E I am a top government official with a statutory corporation and member of an adhoc committee set up by the Federal Government of Nigeria to review contract awarded by past administration=2E In the course of identifying=2C srcutinising and recommending for the payment of all valid contract executed=2C we discovered a huge sum of money amounting to USD41=2E5M =28Forty One Million five Hundred Thousand US Dollars=29 on grossly over invoiced contract already awarded and exccuted for the Nigerian National Petroleum Corporation=2E Having cleaned the =91AUGEAN STABLE=91 we intend to transfer the balance of USD41=2E5M presently floating in our apex bank of Nigeria to our own benefit and advantage=2E However=2C we request for your unwavering assistance in this regard because as civil servants we are prohibited under the civil service code of conduct bureau from operating a foreign account or running a foreign company unless after retirement in this vain we want you to front for us as partner to enable us lodge the funds speedily into your account=2E Bear in mind that no risk is attached to this project and all logistics are in place and modalities worked out for the smooth conclusion within a stipulated time=2E This is in accordance with the fact that you must never betray the trust already reposed on you=2E We have decided to compensate you with 30% of the total sum for your support=2C 60% for us while 10% for miscellaneous expenses =28local and international=29=2E Please=2C provide your confidential phone and fax number to enable me contact you for further discussion on this matter=2E Please advise in your return mail if any time is confidential enough to call you=2E Looking forward to hearing from you=2E Best regards=2C Dr=2EDouglas Akpeki _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Sep 24 07:01:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06625 for ; Wed, 24 Sep 2003 07:01:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27OU-0006Kf-96 for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 07:01:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OB1EOT024341 for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 07:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27OU-0006KW-5e for idr-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:01:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06583; Wed, 24 Sep 2003 07:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27OP-0001kT-00; Wed, 24 Sep 2003 07:01:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A27OO-0001kQ-00; Wed, 24 Sep 2003 07:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27OH-0006Et-E6; Wed, 24 Sep 2003 07:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27NN-0006Am-0b for idr@optimus.ietf.org; Wed, 24 Sep 2003 07:00:05 -0400 Received: from n2now2300.com (80.179.254.186.forward.012.net.il [80.179.254.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06497 for ; Wed, 24 Sep 2003 06:59:44 -0400 (EDT) Message-Id: <200309241059.GAA06497@ietf.org> From: "Dr.Douglas Akpeki" Reply-To: d_akpeki@tiscali.co.uk To: idr@ietf.org X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Idr] INVITATION TO PARTNERSHIP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 11:59:36 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Sir=2C REQUEST FOR YOUR UNRESERVED ASSISTANCE=2E This letter may come to you as a surprise but it was borne out of my sincere desire to share a mutual business relationship with you=2E First=2C your strictest confidence in this transaction is highly solicited=2E This is by virtue of its nature as being utterly confidential and top secret=2E I am a top government official with a statutory corporation and member of an adhoc committee set up by the Federal Government of Nigeria to review contract awarded by past administration=2E In the course of identifying=2C srcutinising and recommending for the payment of all valid contract executed=2C we discovered a huge sum of money amounting to USD41=2E5M =28Forty One Million five Hundred Thousand US Dollars=29 on grossly over invoiced contract already awarded and exccuted for the Nigerian National Petroleum Corporation=2E Having cleaned the =91AUGEAN STABLE=91 we intend to transfer the balance of USD41=2E5M presently floating in our apex bank of Nigeria to our own benefit and advantage=2E However=2C we request for your unwavering assistance in this regard because as civil servants we are prohibited under the civil service code of conduct bureau from operating a foreign account or running a foreign company unless after retirement in this vain we want you to front for us as partner to enable us lodge the funds speedily into your account=2E Bear in mind that no risk is attached to this project and all logistics are in place and modalities worked out for the smooth conclusion within a stipulated time=2E This is in accordance with the fact that you must never betray the trust already reposed on you=2E We have decided to compensate you with 30% of the total sum for your support=2C 60% for us while 10% for miscellaneous expenses =28local and international=29=2E Please=2C provide your confidential phone and fax number to enable me contact you for further discussion on this matter=2E Please advise in your return mail if any time is confidential enough to call you=2E Looking forward to hearing from you=2E Best regards=2C Dr=2EDouglas Akpeki _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Sep 24 07:33:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07807; Wed, 24 Sep 2003 07:33:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27tL-00029v-00; Wed, 24 Sep 2003 07:33:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A27tL-00029s-00; Wed, 24 Sep 2003 07:33:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27tF-0000V2-Fv; Wed, 24 Sep 2003 07:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27t3-0000Uf-Ng for idr@optimus.ietf.org; Wed, 24 Sep 2003 07:32:49 -0400 Received: from mrson2072.com (80.179.254.186.forward.012.net.il [80.179.254.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07780 for ; Wed, 24 Sep 2003 07:32:22 -0400 (EDT) Message-Id: <200309241132.HAA07780@ietf.org> From: "Dr.Douglas Akpeki" Reply-To: d_akpeki1@tiscali.co.uk To: idr@ietf.org X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Idr] INVITATION TO PARTNERSHIP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 12:32:23 +0100 Content-Transfer-Encoding: quoted-printable Dear Sir=2C REQUEST FOR YOUR UNRESERVED ASSISTANCE=2E This letter may come to you as a surprise but it was borne out of my sincere desire to share a mutual business relationship with you=2E First=2C your strictest confidence in this transaction is highly solicited=2E This is by virtue of its nature as being utterly confidential and top secret=2E I am a top government official with a statutory corporation and member of an adhoc committee set up by the Federal Government of Nigeria to review contract awarded by past administration=2E In the course of identifying=2C srcutinising and recommending for the payment of all valid contract executed=2C we discovered a huge sum of money amounting to USD41=2E5M =28Forty One Million five Hundred Thousand US Dollars=29 on grossly over invoiced contract already awarded and exccuted for the Nigerian National Petroleum Corporation=2E Having cleaned the =91AUGEAN STABLE=91 we intend to transfer the balance of USD41=2E5M presently floating in our apex bank of Nigeria to our own benefit and advantage=2E However=2C we request for your unwavering assistance in this regard because as civil servants we are prohibited under the civil service code of conduct bureau from operating a foreign account or running a foreign company unless after retirement in this vain we want you to front for us as partner to enable us lodge the funds speedily into your account=2E Bear in mind that no risk is attached to this project and all logistics are in place and modalities worked out for the smooth conclusion within a stipulated time=2E This is in accordance with the fact that you must never betray the trust already reposed on you=2E We have decided to compensate you with 30% of the total sum for your support=2C 60% for us while 10% for miscellaneous expenses =28local and international=29=2E Please=2C provide your confidential phone and fax number to enable me contact you for further discussion on this matter=2E Please advise in your return mail if any time is confidential enough to call you=2E Looking forward to hearing from you=2E Best regards=2C Dr=2EDouglas Akpeki _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Sep 24 07:33:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07844 for ; Wed, 24 Sep 2003 07:33:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27tM-0000Yy-SJ for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 07:33:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBX8gf002158 for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 07:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27tM-0000Yj-P6 for idr-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:33:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07807; Wed, 24 Sep 2003 07:33:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27tL-00029v-00; Wed, 24 Sep 2003 07:33:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A27tL-00029s-00; Wed, 24 Sep 2003 07:33:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27tF-0000V2-Fv; Wed, 24 Sep 2003 07:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27t3-0000Uf-Ng for idr@optimus.ietf.org; Wed, 24 Sep 2003 07:32:49 -0400 Received: from mrson2072.com (80.179.254.186.forward.012.net.il [80.179.254.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07780 for ; Wed, 24 Sep 2003 07:32:22 -0400 (EDT) Message-Id: <200309241132.HAA07780@ietf.org> From: "Dr.Douglas Akpeki" Reply-To: d_akpeki1@tiscali.co.uk To: idr@ietf.org X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Idr] INVITATION TO PARTNERSHIP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 12:32:23 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Sir=2C REQUEST FOR YOUR UNRESERVED ASSISTANCE=2E This letter may come to you as a surprise but it was borne out of my sincere desire to share a mutual business relationship with you=2E First=2C your strictest confidence in this transaction is highly solicited=2E This is by virtue of its nature as being utterly confidential and top secret=2E I am a top government official with a statutory corporation and member of an adhoc committee set up by the Federal Government of Nigeria to review contract awarded by past administration=2E In the course of identifying=2C srcutinising and recommending for the payment of all valid contract executed=2C we discovered a huge sum of money amounting to USD41=2E5M =28Forty One Million five Hundred Thousand US Dollars=29 on grossly over invoiced contract already awarded and exccuted for the Nigerian National Petroleum Corporation=2E Having cleaned the =91AUGEAN STABLE=91 we intend to transfer the balance of USD41=2E5M presently floating in our apex bank of Nigeria to our own benefit and advantage=2E However=2C we request for your unwavering assistance in this regard because as civil servants we are prohibited under the civil service code of conduct bureau from operating a foreign account or running a foreign company unless after retirement in this vain we want you to front for us as partner to enable us lodge the funds speedily into your account=2E Bear in mind that no risk is attached to this project and all logistics are in place and modalities worked out for the smooth conclusion within a stipulated time=2E This is in accordance with the fact that you must never betray the trust already reposed on you=2E We have decided to compensate you with 30% of the total sum for your support=2C 60% for us while 10% for miscellaneous expenses =28local and international=29=2E Please=2C provide your confidential phone and fax number to enable me contact you for further discussion on this matter=2E Please advise in your return mail if any time is confidential enough to call you=2E Looking forward to hearing from you=2E Best regards=2C Dr=2EDouglas Akpeki _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Sep 24 11:40:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22586; Wed, 24 Sep 2003 11:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Bku-0006Np-00; Wed, 24 Sep 2003 11:40:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Bku-0006Nm-00; Wed, 24 Sep 2003 11:40:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BkI-0003YG-S5; Wed, 24 Sep 2003 11:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bjv-0003XW-5S for idr@optimus.ietf.org; Wed, 24 Sep 2003 11:39:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22548 for ; Wed, 24 Sep 2003 11:39:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Bjt-0006N1-00 for idr@ietf.org; Wed, 24 Sep 2003 11:39:37 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Bjs-0006MZ-00 for idr@ietf.org; Wed, 24 Sep 2003 11:39:36 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8OFd3F7034389 for idr@ietf.org; Wed, 24 Sep 2003 11:39:03 -0400 (EDT) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([65.247.36.233]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8OFd0Vp034376 for ; Wed, 24 Sep 2003 11:39:00 -0400 (EDT) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] comments on idr-bgp4-20 Message-ID: Thread-Topic: [Idr] comments on idr-bgp4-20 Thread-Index: AcOCcOhxJscqAumcSzO8sxexG3Hr3gAQNQ8Q From: "Susan Hares" To: "Pekka Savola" , X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 11:39:00 -0400 Content-Transfer-Encoding: quoted-printable Pekka: For context on the message, could you tell me are you: 1) Implementor of BGP 2) Operator using BGP 3) Network researcher 4) other=20 Sue Hares -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, September 24, 2003 3:50 AM To: idr@ietf.org Subject: [Idr] comments on idr-bgp4-20 Hi, [note, I'm not subscribed to the idr list] Alex solicited ops-dir for folks to review bgp4-20 spec. After almost half a year, I finally found the time to look at it. Comments below. I tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but = at least on the quick glance, I didn't find major overlaps. Overview: - the spec is in pretty good shape, but I'm not sure if all the = features listed are really full standard material.. it might be better to = separate some of them (e.g. anything relating to aggregation) to a separate doc = (so that we'd have a much tigher and better real base spec), and recycle it = at DS, but that might be much more effort.. not sure if something like that would be worth it. General thoughts on going to full standard: - If we want to go for full standard, I have to question the usefulness = of several BGP features: - AS_SET AS_PATH attribute - whole route aggregation concept (nowadays, it seems to be causing=20 more trouble than it's worth -- instead of proper advertisements, just=20 automatically aggregate instead of fixing the advertisements to begin=20 with). Maybe pver 10 years ago it may have been relevant if all the = edge=20 BGP routers might not support BGP-4 or CIDR.. - about N++ different cases of third-party nexthop usage. As a general observation from the text: - I skipped section 8 on FSM, as it was really boring, and I'm not sure whehter it's of any use keeping it in the base spec. - I got major headache when trying to read the aggregating rules especially in section 9.2.2.2 (and that was supposed to be the _simple_ rules :-(!!!) and ended up skipping them. substantial ----------- 1) Section 3 on Summary of the Operations, states: In the context of this document we assume that a BGP speaker adver- tises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. this "usability" requirement is in conflict with section 4.3 on UPDATE message format: An UPDATE message is used to advertise feasible routes sharing common path attributes to a peer, [...] =3D=3D> in particular note that "feasible" is a superset of "only those = routes the router itself uses" (compare to "those routes the router itself = _could_ use if they were the most preferred ones"), right? =3D=3D> also note that the former definition is (IMHO) operationally = unsound. =20 It prevents you from advertising P-t-P addresses and loopbacks (which = also=20 reside in IGP) using BGP, because the IGP distance is lower than BGP and = "BGP route is never used in forwarding". (depending on how you interpret = that). IMHO, this really needs to be changed to be OK. 2) The OPEN message format is confusing. Why on earth do you have those empty bits there? Are they null-padding or just a typographical = convention for the clarity of the diagram (the latter)? = =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =3D=3D> I strongly recommend to either: 1) go back to standard format, or 2) rephrase the message format similar with UPDATE messages, i.e., drop = all the pretense about field lengths, bits 0-31, etc. 3) there is significant confusion on what "locally originated" means. = It is not clear whether this refers to "local to the BGP speaker (i.e., the = same system)" or "local to the routing domain (i.e., the same AS)". This = must be clarified in the text below, and the text should be reviewed. 5.1.3 NEXT_HOP = =20 The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the des- tinations listed in the UPDATE message. The NEXT_HOP attribute is calculated as follows. = =20 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. When announcing a locally originated route to an internal peer, the BGP speaker SHOULD use as the NEXT_HOP the interface address of the router through which the announced network is reachable for the speaker; if the route is directly connected to the speaker, or the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, then the BGP speaker SHOULD use for the NEXT_HOP attribute its own IP address (the address of the interface that is used to reach the peer). 4) there appears to have been added some bogosities about inter-AS = traffic engineering in section 9.3: - If the local AS appears in the AS path of the new route being considered, then that new route can not be viewed as better than any other route (provided that the speaker is configured to accept such routes). If such a route were ever used, a routing loop could result. and: The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. =3D=3D> what do these have to do with base spec? I don't think they're operationally feasible or used. Remove any indication that it's OK to receive your own AS in the routes you receive!! 5) the reasoning for this section is not clear. It seems to be two = parts (the second one starting at "These routes..."). It seems partially, at least for the second part, a set of operational guidelines.. which = probably don't have anything to do with the BGP spec! 9.4 Originating BGP routes = =20 A BGP speaker may originate BGP routes by injecting routing informa- tion acquired by some other means (e.g. via an IGP) into BGP. A BGP speaker that originates BGP routes assigns the degree of preference to these routes by passing them through the Decision Process (see Section 9.1). These routes MAY also be distributed to other BGP speakers within the local AS as part of the update process (see Sec- tion 9.2). The decision whether to distribute non-BGP acquired routes within an AS via BGP or not depends on the environment within the AS (e.g. type of IGP) and SHOULD be controlled via configuration. 6) references; note that as the Security Consideration section is a bit short, the vulnerability analysis should be a *NORMATIVE* reference.=20 However, one must ask here and with RFC2385 as well whether normative references are OK from Full Standard to a lower maturity level. Unless this has already been investigated, it may be worth checking with the = ADs that this is OK. BGP vulnerabilities analysis is discussed in [XXX]. = =20 Normative References = =20 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC2385, August 1998. = =20 Non-normative References = =20 [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- ietf-idr-bgp-vuln-00.txt, work in progress semi-substantial ---------------- =3D=3D> I'd add "Decision Process", "Routing Table", and "BGP route" in = the terminology. (Especially the last one is a bit shady, see more comments later.) Adj-RIB-In Adj-RIBs-In Adj-RIB-Out Adj-RIBs-Out =3D=3D> in some places, one seems to use "Adj-RIBs-{In,Out}", in some = others, "Adj-RIB-{In,Out}". The plural/singular form should be consistent. BGP speaker A router that implements BGP. =3D=3D> uhh, no. Throughout the text "BGP speaker" is used to refer to BGP-*enabled* routers. Implementation is a required but not sufficient condition to that. Consider rewording to something like: BGP speaker A router that implements and has been configured to use BGP. .... BGP Identifier: = =20 This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. =3D=3D> the last sentence is confusing "same for every local = interface".. yeah, right, but interfaces are irrelevant here. Also, this ignores the fact that it's perfectly legal to change BGP identifiers after startup but = prior to establishing a BGP session. Consider rewording to something like: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined prior to establishing BGP sessions and is the same for every session the BGP speaker. ... Path Attributes: = =20 A variable length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple of variable length. =3D=3D> should a simple diagram be added here, just like in section 4.2? The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). =3D=3D> this and the following descriptions on attributes are out of = place if you have not described the remaining categories (because they're used = when describing the attributes in the next page), that is, discretionary and mandatory. Consider rewording the above to something like: =09 The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). Well-known attributes = can be either mandatory (MUST be included in every UPDATE message = that contains NLRI), or discretionary (inclusion not required). ... All well-known attributes MUST be passed along (after proper updat- ing, if necessary) to other BGP peers. =3D=3D> LOCAL-PREF is an exception here. I also note that the BGP's = definition of "transitive" is different ("unrecognized optional attributes are only passed onward when the transitive bit is set, but recognized optional attributes are always passed onward") from the apparent language = ("always passed along"), and might use a bit of clarification. ... b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: = =20 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it is legal to prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. = =20 2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. = =20 =3D=3D> the text here seems confusing because it is not clear whether = things are added at the beginning or at the end of the segments, for example: "the _last_ element sequence (put it in the _leftmost_ position)" .. I think this requires more precise language on which end of the = segment these values are really inserted. I.e., is it "physically" (in memory) left-to-right (from more recent to more distant), or just interpreted = that way? This has significant impact on the last sentence of section 1) in = case of overflows and the like. =20 Whenever the modification of the AS_PATH attribute calls for includ- ing or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration. =3D=3D> what about prepending/adding someone else's AS? Is this = relevant enough to be considered? A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers. =3D=3D> the second line seems out-of-place here. I assume it means that = the router must not perform automatic de-aggregation, not that the router = must not have more specific routes to advertise. In any case, a rewording = might be in order, e.g. like: A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that = is,=20 generating more specifics by de-aggregating a route is forbidden. (note that this actually makes the statement stronger, and more in line = of 9.1.4, that you should not do it even locally.) If the Length field of the message header is less than 19 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 19, or if the Length field of a NOTIFICATION message is less than the mini- mum length of the NOTIFICATION message, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field. =3D=3D> convert this to a bulleted list or something, so it's easier to = read, please! :-) The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct: = =20 a) It MUST NOT be the IP address of the receiving speaker = =20 b) In the case of an EBGP where the sender and receiver are one IP hop away from each other, either the IP address in the NEXT_HOP MUST be the sender's IP address (that is used to establish the BGP connection), or the interface associated with the NEXT_HOP IP address MUST share a common subnet with the receiving BGP speaker. =3D=3D> what's exactly the case for the first case of b)? Couldn't thid = be cleaned a bit (it seems to me that the second case is a superset of the first)? In addition, I'd recommend rewording "one IP hop away" -- that begs the question whether you mean "direct neighbors" or "just one transit router". When thinking of it more, the former seems apparent, = but a different wording might flesh this out better. If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. =3D=3D> this is confusing, especially the end, beginning from "That is, = ..." and should be reworded a bit (does it cover only deaggregation or more = specifics in general?), like: If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. =20 Routes SHOULD NOT be de-aggregated. A route that carries = ATOMIC_AGGREGATE=20 attribute in particular MUST NOT be de-aggregated. That is, one must = not generate more specifics of the NLRI of this route. Forwarding along=20 such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. However, accepting more specific = advertisments which an aggregate route covers is acceptable. ... A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised. =3D=3D> and now we get back to the definition of "same BGP route"? = Identical prefix carried over BGP? Identical prefix carried over BGP with identical = attributes?" I'm assuming the former, otherwise (at least!) the above should be clarified. Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure separately to path attributes of like type and to the Network Layer Reachability Information. =3D=3D> the last line sounds really weird; consider: - s/like/the same/ ? - add more text after the NLRI, like "NLRI field" ? typos or other editorials ------------------------- =3D=3D> there should not be hyphenation at the linebreaks. This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. =3D=3D> s/extention/extension/ (two places) 3.2 Routing Information Bases = =20 The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts: =3D=3D> the subject is in plural form ("RIBs"), but the text begins as = singular ("The RIB"). Consider which one to use? a) ORIGIN (Type Code 1): = =20 b) AS_PATH (Type Code 2): = =20 =3D=3D> kill the extra spaces before ORIGIN and NEXT_HOP. 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). =20 =3D=3D> rewrite the last one as: last element of the sequence, putting it in the leftmost = position. A BGP speaker MUST IMPLEMENT a mechanism based on local configuration =20 =3D=3D> s/IMPLEMENT/implement/ used by a BGP speaker's decision process to discriminate =20 =3D=3D> s/decision process/Decision Process/ (similar in a few other = places?) attribute needs to be cognizant of the fact that the actual path to =20 =3D=3D> s/cognizant/aware/ 6. BGP Error Handling. = =20 =3D=3D> remove the periods from at the end of section titles, esp. in = subctions of section 6. issue a open collision dump [Event 23]. When the local system receives a open collision dump event [Event 23], the =20 =3D=3D> s/a open/an open/ (two times) installed in LocRib and will be excluded from the next phase of route =20 =3D=3D> s/LocRib/Loc-RIB/ all AS used to form the aggreagate in an AS_SET or add the =20 =3D=3D> s/aggreagate/aggregate/ is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be =20 =3D=3D> pick either "deaggregate" or "de-aggregate" and stick to that. have the origin attribute with the value EGP. In all other case =20 =3D=3D> s/case/cases/ --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Sep 24 11:41:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22632 for ; Wed, 24 Sep 2003 11:41:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bkw-0003bS-Je for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 11:40:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OFeg7X013846 for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 11:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bkw-0003bF-En for idr-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 11:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22586; Wed, 24 Sep 2003 11:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Bku-0006Np-00; Wed, 24 Sep 2003 11:40:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Bku-0006Nm-00; Wed, 24 Sep 2003 11:40:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BkI-0003YG-S5; Wed, 24 Sep 2003 11:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bjv-0003XW-5S for idr@optimus.ietf.org; Wed, 24 Sep 2003 11:39:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22548 for ; Wed, 24 Sep 2003 11:39:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Bjt-0006N1-00 for idr@ietf.org; Wed, 24 Sep 2003 11:39:37 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Bjs-0006MZ-00 for idr@ietf.org; Wed, 24 Sep 2003 11:39:36 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8OFd3F7034389 for idr@ietf.org; Wed, 24 Sep 2003 11:39:03 -0400 (EDT) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([65.247.36.233]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8OFd0Vp034376 for ; Wed, 24 Sep 2003 11:39:00 -0400 (EDT) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] comments on idr-bgp4-20 Message-ID: Thread-Topic: [Idr] comments on idr-bgp4-20 Thread-Index: AcOCcOhxJscqAumcSzO8sxexG3Hr3gAQNQ8Q From: "Susan Hares" To: "Pekka Savola" , X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 11:39:00 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka: For context on the message, could you tell me are you: 1) Implementor of BGP 2) Operator using BGP 3) Network researcher 4) other=20 Sue Hares -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, September 24, 2003 3:50 AM To: idr@ietf.org Subject: [Idr] comments on idr-bgp4-20 Hi, [note, I'm not subscribed to the idr list] Alex solicited ops-dir for folks to review bgp4-20 spec. After almost half a year, I finally found the time to look at it. Comments below. I tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but = at least on the quick glance, I didn't find major overlaps. Overview: - the spec is in pretty good shape, but I'm not sure if all the = features listed are really full standard material.. it might be better to = separate some of them (e.g. anything relating to aggregation) to a separate doc = (so that we'd have a much tigher and better real base spec), and recycle it = at DS, but that might be much more effort.. not sure if something like that would be worth it. General thoughts on going to full standard: - If we want to go for full standard, I have to question the usefulness = of several BGP features: - AS_SET AS_PATH attribute - whole route aggregation concept (nowadays, it seems to be causing=20 more trouble than it's worth -- instead of proper advertisements, just=20 automatically aggregate instead of fixing the advertisements to begin=20 with). Maybe pver 10 years ago it may have been relevant if all the = edge=20 BGP routers might not support BGP-4 or CIDR.. - about N++ different cases of third-party nexthop usage. As a general observation from the text: - I skipped section 8 on FSM, as it was really boring, and I'm not sure whehter it's of any use keeping it in the base spec. - I got major headache when trying to read the aggregating rules especially in section 9.2.2.2 (and that was supposed to be the _simple_ rules :-(!!!) and ended up skipping them. substantial ----------- 1) Section 3 on Summary of the Operations, states: In the context of this document we assume that a BGP speaker adver- tises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. this "usability" requirement is in conflict with section 4.3 on UPDATE message format: An UPDATE message is used to advertise feasible routes sharing common path attributes to a peer, [...] =3D=3D> in particular note that "feasible" is a superset of "only those = routes the router itself uses" (compare to "those routes the router itself = _could_ use if they were the most preferred ones"), right? =3D=3D> also note that the former definition is (IMHO) operationally = unsound. =20 It prevents you from advertising P-t-P addresses and loopbacks (which = also=20 reside in IGP) using BGP, because the IGP distance is lower than BGP and = "BGP route is never used in forwarding". (depending on how you interpret = that). IMHO, this really needs to be changed to be OK. 2) The OPEN message format is confusing. Why on earth do you have those empty bits there? Are they null-padding or just a typographical = convention for the clarity of the diagram (the latter)? = =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =3D=3D> I strongly recommend to either: 1) go back to standard format, or 2) rephrase the message format similar with UPDATE messages, i.e., drop = all the pretense about field lengths, bits 0-31, etc. 3) there is significant confusion on what "locally originated" means. = It is not clear whether this refers to "local to the BGP speaker (i.e., the = same system)" or "local to the routing domain (i.e., the same AS)". This = must be clarified in the text below, and the text should be reviewed. 5.1.3 NEXT_HOP = =20 The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the des- tinations listed in the UPDATE message. The NEXT_HOP attribute is calculated as follows. = =20 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. When announcing a locally originated route to an internal peer, the BGP speaker SHOULD use as the NEXT_HOP the interface address of the router through which the announced network is reachable for the speaker; if the route is directly connected to the speaker, or the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, then the BGP speaker SHOULD use for the NEXT_HOP attribute its own IP address (the address of the interface that is used to reach the peer). 4) there appears to have been added some bogosities about inter-AS = traffic engineering in section 9.3: - If the local AS appears in the AS path of the new route being considered, then that new route can not be viewed as better than any other route (provided that the speaker is configured to accept such routes). If such a route were ever used, a routing loop could result. and: The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. =3D=3D> what do these have to do with base spec? I don't think they're operationally feasible or used. Remove any indication that it's OK to receive your own AS in the routes you receive!! 5) the reasoning for this section is not clear. It seems to be two = parts (the second one starting at "These routes..."). It seems partially, at least for the second part, a set of operational guidelines.. which = probably don't have anything to do with the BGP spec! 9.4 Originating BGP routes = =20 A BGP speaker may originate BGP routes by injecting routing informa- tion acquired by some other means (e.g. via an IGP) into BGP. A BGP speaker that originates BGP routes assigns the degree of preference to these routes by passing them through the Decision Process (see Section 9.1). These routes MAY also be distributed to other BGP speakers within the local AS as part of the update process (see Sec- tion 9.2). The decision whether to distribute non-BGP acquired routes within an AS via BGP or not depends on the environment within the AS (e.g. type of IGP) and SHOULD be controlled via configuration. 6) references; note that as the Security Consideration section is a bit short, the vulnerability analysis should be a *NORMATIVE* reference.=20 However, one must ask here and with RFC2385 as well whether normative references are OK from Full Standard to a lower maturity level. Unless this has already been investigated, it may be worth checking with the = ADs that this is OK. BGP vulnerabilities analysis is discussed in [XXX]. = =20 Normative References = =20 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC2385, August 1998. = =20 Non-normative References = =20 [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- ietf-idr-bgp-vuln-00.txt, work in progress semi-substantial ---------------- =3D=3D> I'd add "Decision Process", "Routing Table", and "BGP route" in = the terminology. (Especially the last one is a bit shady, see more comments later.) Adj-RIB-In Adj-RIBs-In Adj-RIB-Out Adj-RIBs-Out =3D=3D> in some places, one seems to use "Adj-RIBs-{In,Out}", in some = others, "Adj-RIB-{In,Out}". The plural/singular form should be consistent. BGP speaker A router that implements BGP. =3D=3D> uhh, no. Throughout the text "BGP speaker" is used to refer to BGP-*enabled* routers. Implementation is a required but not sufficient condition to that. Consider rewording to something like: BGP speaker A router that implements and has been configured to use BGP. .... BGP Identifier: = =20 This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. =3D=3D> the last sentence is confusing "same for every local = interface".. yeah, right, but interfaces are irrelevant here. Also, this ignores the fact that it's perfectly legal to change BGP identifiers after startup but = prior to establishing a BGP session. Consider rewording to something like: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined prior to establishing BGP sessions and is the same for every session the BGP speaker. ... Path Attributes: = =20 A variable length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple of variable length. =3D=3D> should a simple diagram be added here, just like in section 4.2? The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). =3D=3D> this and the following descriptions on attributes are out of = place if you have not described the remaining categories (because they're used = when describing the attributes in the next page), that is, discretionary and mandatory. Consider rewording the above to something like: =09 The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). Well-known attributes = can be either mandatory (MUST be included in every UPDATE message = that contains NLRI), or discretionary (inclusion not required). ... All well-known attributes MUST be passed along (after proper updat- ing, if necessary) to other BGP peers. =3D=3D> LOCAL-PREF is an exception here. I also note that the BGP's = definition of "transitive" is different ("unrecognized optional attributes are only passed onward when the transitive bit is set, but recognized optional attributes are always passed onward") from the apparent language = ("always passed along"), and might use a bit of clarification. ... b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: = =20 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it is legal to prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. = =20 2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. = =20 =3D=3D> the text here seems confusing because it is not clear whether = things are added at the beginning or at the end of the segments, for example: "the _last_ element sequence (put it in the _leftmost_ position)" .. I think this requires more precise language on which end of the = segment these values are really inserted. I.e., is it "physically" (in memory) left-to-right (from more recent to more distant), or just interpreted = that way? This has significant impact on the last sentence of section 1) in = case of overflows and the like. =20 Whenever the modification of the AS_PATH attribute calls for includ- ing or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration. =3D=3D> what about prepending/adding someone else's AS? Is this = relevant enough to be considered? A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers. =3D=3D> the second line seems out-of-place here. I assume it means that = the router must not perform automatic de-aggregation, not that the router = must not have more specific routes to advertise. In any case, a rewording = might be in order, e.g. like: A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that = is,=20 generating more specifics by de-aggregating a route is forbidden. (note that this actually makes the statement stronger, and more in line = of 9.1.4, that you should not do it even locally.) If the Length field of the message header is less than 19 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 19, or if the Length field of a NOTIFICATION message is less than the mini- mum length of the NOTIFICATION message, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field. =3D=3D> convert this to a bulleted list or something, so it's easier to = read, please! :-) The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct: = =20 a) It MUST NOT be the IP address of the receiving speaker = =20 b) In the case of an EBGP where the sender and receiver are one IP hop away from each other, either the IP address in the NEXT_HOP MUST be the sender's IP address (that is used to establish the BGP connection), or the interface associated with the NEXT_HOP IP address MUST share a common subnet with the receiving BGP speaker. =3D=3D> what's exactly the case for the first case of b)? Couldn't thid = be cleaned a bit (it seems to me that the second case is a superset of the first)? In addition, I'd recommend rewording "one IP hop away" -- that begs the question whether you mean "direct neighbors" or "just one transit router". When thinking of it more, the former seems apparent, = but a different wording might flesh this out better. If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. =3D=3D> this is confusing, especially the end, beginning from "That is, = ..." and should be reworded a bit (does it cover only deaggregation or more = specifics in general?), like: If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. =20 Routes SHOULD NOT be de-aggregated. A route that carries = ATOMIC_AGGREGATE=20 attribute in particular MUST NOT be de-aggregated. That is, one must = not generate more specifics of the NLRI of this route. Forwarding along=20 such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. However, accepting more specific = advertisments which an aggregate route covers is acceptable. ... A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised. =3D=3D> and now we get back to the definition of "same BGP route"? = Identical prefix carried over BGP? Identical prefix carried over BGP with identical = attributes?" I'm assuming the former, otherwise (at least!) the above should be clarified. Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure separately to path attributes of like type and to the Network Layer Reachability Information. =3D=3D> the last line sounds really weird; consider: - s/like/the same/ ? - add more text after the NLRI, like "NLRI field" ? typos or other editorials ------------------------- =3D=3D> there should not be hyphenation at the linebreaks. This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. =3D=3D> s/extention/extension/ (two places) 3.2 Routing Information Bases = =20 The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts: =3D=3D> the subject is in plural form ("RIBs"), but the text begins as = singular ("The RIB"). Consider which one to use? a) ORIGIN (Type Code 1): = =20 b) AS_PATH (Type Code 2): = =20 =3D=3D> kill the extra spaces before ORIGIN and NEXT_HOP. 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). =20 =3D=3D> rewrite the last one as: last element of the sequence, putting it in the leftmost = position. A BGP speaker MUST IMPLEMENT a mechanism based on local configuration =20 =3D=3D> s/IMPLEMENT/implement/ used by a BGP speaker's decision process to discriminate =20 =3D=3D> s/decision process/Decision Process/ (similar in a few other = places?) attribute needs to be cognizant of the fact that the actual path to =20 =3D=3D> s/cognizant/aware/ 6. BGP Error Handling. = =20 =3D=3D> remove the periods from at the end of section titles, esp. in = subctions of section 6. issue a open collision dump [Event 23]. When the local system receives a open collision dump event [Event 23], the =20 =3D=3D> s/a open/an open/ (two times) installed in LocRib and will be excluded from the next phase of route =20 =3D=3D> s/LocRib/Loc-RIB/ all AS used to form the aggreagate in an AS_SET or add the =20 =3D=3D> s/aggreagate/aggregate/ is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be =20 =3D=3D> pick either "deaggregate" or "de-aggregate" and stick to that. have the origin attribute with the value EGP. In all other case =20 =3D=3D> s/case/cases/ --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Sep 24 12:36:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25313; Wed, 24 Sep 2003 12:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ccd-000765-00; Wed, 24 Sep 2003 12:36:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Ccd-000762-00; Wed, 24 Sep 2003 12:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2CcU-00080u-4I; Wed, 24 Sep 2003 12:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Cbh-0007jg-MD for idr@optimus.ietf.org; Wed, 24 Sep 2003 12:35:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25237 for ; Wed, 24 Sep 2003 12:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Cbg-00074B-00 for idr@ietf.org; Wed, 24 Sep 2003 12:35:12 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Cbf-00073m-00 for idr@ietf.org; Wed, 24 Sep 2003 12:35:11 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8OGYcHm001689; Wed, 24 Sep 2003 09:34:39 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA25324; Wed, 24 Sep 2003 12:34:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Pekka Savola From: "John G. Scudder" Subject: Re: [Idr] comments on idr-bgp4-20 Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 12:34:30 -0400 At 10:50 AM +0300 9/24/03, Pekka Savola wrote: >General thoughts on going to full standard: The process the IDR group has been following so far is to try to document the existing protocol rather than to tweak it. In your first few comments you seem to be suggesting that the protocol as currently deployed isn't suitable for full standard and should be tweaked. Is that what you meant to say? > - If we want to go for full standard, I have to question the usefulness of >several BGP features: > - AS_SET AS_PATH attribute I can imagine why you think this; however, given that AS_SET is already part of presumably all BGP implementations, I can't think of a reason to remove it. On the other hand, I can think of various reasons to keep it, including but not limited to "if it ain't broke, don't fix it." > - whole route aggregation concept (nowadays, it seems to be causing >more trouble than it's worth -- instead of proper advertisements, just >automatically aggregate instead of fixing the advertisements to begin >with). Maybe pver 10 years ago it may have been relevant if all the edge >BGP routers might not support BGP-4 or CIDR.. I honestly don't understand the point you're trying to make here. > - about N++ different cases of third-party nexthop usage. Are you suggesting that third-party nexthop should be removed from the spec (and from implementations)? If so, I think more justification will be needed. >4) there appears to have been added some bogosities about inter-AS traffic >engineering in section 9.3: > > - If the local AS appears in the AS path of the new route being > considered, then that new route can not be viewed as better than > any other route (provided that the speaker is configured to accept > such routes). If such a route were ever used, a routing loop could > result. > >and: > > The ability of a BGP speaker to include more than one instance of > its own AS in the AS_PATH attribute for the purpose of inter-AS > traffic engineering. > >==> what do these have to do with base spec? I don't think they're >operationally feasible or used. Remove any indication that it's OK to >receive your own AS in the routes you receive!! I beg to differ. The former is not common practice but is not unknown either (it's historically there to allow a partitioned AS to be healed through an external path). The latter (AS Path padding) is incredibly common. The text should be left as is, except that I wouldn't object to the removal of the clause "for the purpose of inter-AS traffic engineering." > attribute needs to be cognizant of the fact that the actual path to > >==> s/cognizant/aware/ Why? --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Sep 24 12:36:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25363 for ; Wed, 24 Sep 2003 12:36:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ccf-00083O-VZ for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 12:36:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OGaDHF030958 for idr-archive@odin.ietf.org; Wed, 24 Sep 2003 12:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ccf-00083F-RZ for idr-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 12:36:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25313; Wed, 24 Sep 2003 12:36:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ccd-000765-00; Wed, 24 Sep 2003 12:36:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Ccd-000762-00; Wed, 24 Sep 2003 12:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2CcU-00080u-4I; Wed, 24 Sep 2003 12:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Cbh-0007jg-MD for idr@optimus.ietf.org; Wed, 24 Sep 2003 12:35:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25237 for ; Wed, 24 Sep 2003 12:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Cbg-00074B-00 for idr@ietf.org; Wed, 24 Sep 2003 12:35:12 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Cbf-00073m-00 for idr@ietf.org; Wed, 24 Sep 2003 12:35:11 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8OGYcHm001689; Wed, 24 Sep 2003 09:34:39 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA25324; Wed, 24 Sep 2003 12:34:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Pekka Savola From: "John G. Scudder" Subject: Re: [Idr] comments on idr-bgp4-20 Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 12:34:30 -0400 At 10:50 AM +0300 9/24/03, Pekka Savola wrote: >General thoughts on going to full standard: The process the IDR group has been following so far is to try to document the existing protocol rather than to tweak it. In your first few comments you seem to be suggesting that the protocol as currently deployed isn't suitable for full standard and should be tweaked. Is that what you meant to say? > - If we want to go for full standard, I have to question the usefulness of >several BGP features: > - AS_SET AS_PATH attribute I can imagine why you think this; however, given that AS_SET is already part of presumably all BGP implementations, I can't think of a reason to remove it. On the other hand, I can think of various reasons to keep it, including but not limited to "if it ain't broke, don't fix it." > - whole route aggregation concept (nowadays, it seems to be causing >more trouble than it's worth -- instead of proper advertisements, just >automatically aggregate instead of fixing the advertisements to begin >with). Maybe pver 10 years ago it may have been relevant if all the edge >BGP routers might not support BGP-4 or CIDR.. I honestly don't understand the point you're trying to make here. > - about N++ different cases of third-party nexthop usage. Are you suggesting that third-party nexthop should be removed from the spec (and from implementations)? If so, I think more justification will be needed. >4) there appears to have been added some bogosities about inter-AS traffic >engineering in section 9.3: > > - If the local AS appears in the AS path of the new route being > considered, then that new route can not be viewed as better than > any other route (provided that the speaker is configured to accept > such routes). If such a route were ever used, a routing loop could > result. > >and: > > The ability of a BGP speaker to include more than one instance of > its own AS in the AS_PATH attribute for the purpose of inter-AS > traffic engineering. > >==> what do these have to do with base spec? I don't think they're >operationally feasible or used. Remove any indication that it's OK to >receive your own AS in the routes you receive!! I beg to differ. The former is not common practice but is not unknown either (it's historically there to allow a partitioned AS to be healed through an external path). The latter (AS Path padding) is incredibly common. The text should be left as is, except that I wouldn't object to the removal of the clause "for the purpose of inter-AS traffic engineering." > attribute needs to be cognizant of the fact that the actual path to > >==> s/cognizant/aware/ Why? --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Sep 25 01:10:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24946; Thu, 25 Sep 2003 01:10:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2OOl-0000ME-00; Thu, 25 Sep 2003 01:10:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2OOl-0000M7-00; Thu, 25 Sep 2003 01:10:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2OO9-000337-Eo; Thu, 25 Sep 2003 01:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ONc-00032g-BB for idr@optimus.ietf.org; Thu, 25 Sep 2003 01:09:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24903 for ; Thu, 25 Sep 2003 01:09:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ONY-0000LD-00 for idr@ietf.org; Thu, 25 Sep 2003 01:09:24 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ONX-0000L6-00 for idr@ietf.org; Thu, 25 Sep 2003 01:09:23 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8P58gL30140; Thu, 25 Sep 2003 08:08:43 +0300 From: Pekka Savola To: Susan Hares cc: idr@ietf.org Subject: RE: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 08:08:42 +0300 (EEST) On Wed, 24 Sep 2003, Susan Hares wrote: > For context on the message, could you > tell me are you: > > 2) Operator using BGP Operator. > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, September 24, 2003 3:50 AM > To: idr@ietf.org > Subject: [Idr] comments on idr-bgp4-20 > > > Hi, > > [note, I'm not subscribed to the idr list] > > Alex solicited ops-dir for folks to review bgp4-20 spec. After almost > half a year, I finally found the time to look at it. Comments below. I > tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at > least on the quick glance, I didn't find major overlaps. > > Overview: > - the spec is in pretty good shape, but I'm not sure if all the features > listed are really full standard material.. it might be better to separate > some of them (e.g. anything relating to aggregation) to a separate doc (so > that we'd have a much tigher and better real base spec), and recycle it at > DS, but that might be much more effort.. not sure if something like that > would be worth it. > > General thoughts on going to full standard: > - If we want to go for full standard, I have to question the usefulness of > several BGP features: > - AS_SET AS_PATH attribute > - whole route aggregation concept (nowadays, it seems to be causing > more trouble than it's worth -- instead of proper advertisements, just > automatically aggregate instead of fixing the advertisements to begin > with). Maybe pver 10 years ago it may have been relevant if all the edge > BGP routers might not support BGP-4 or CIDR.. > - about N++ different cases of third-party nexthop usage. > > As a general observation from the text: > - I skipped section 8 on FSM, as it was really boring, and I'm not sure > whehter it's of any use keeping it in the base spec. > - I got major headache when trying to read the aggregating rules > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > rules :-(!!!) and ended up skipping them. > > substantial > ----------- > > 1) Section 3 on Summary of the Operations, states: > > In the context of this document we assume that a BGP speaker adver- > tises to its peers only those routes that it itself uses (in this > context a BGP speaker is said to "use" a BGP route if it is the most > preferred BGP route and is used in forwarding). All other cases are > outside the scope of this document. > > this "usability" requirement is in conflict with section 4.3 on UPDATE > message format: > > An UPDATE message is used to advertise feasible routes sharing common > path attributes to a peer, [...] > > ==> in particular note that "feasible" is a superset of "only those routes > the router itself uses" (compare to "those routes the router itself _could_ > use if they were the most preferred ones"), right? > > ==> also note that the former definition is (IMHO) operationally unsound. > It prevents you from advertising P-t-P addresses and loopbacks (which also > reside in IGP) using BGP, because the IGP distance is lower than BGP and > "BGP route is never used in forwarding". (depending on how you interpret > that). IMHO, this really needs to be changed to be OK. > > 2) The OPEN message format is confusing. Why on earth do you have those > empty bits there? Are they null-padding or just a typographical convention > for the clarity of the diagram (the latter)? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | My Autonomous System | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hold Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BGP Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opt Parm Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Optional Parameters (variable) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ==> I strongly recommend to either: > 1) go back to standard format, or > 2) rephrase the message format similar with UPDATE messages, i.e., drop all > the pretense about field lengths, bits 0-31, etc. > > 3) there is significant confusion on what "locally originated" means. It is > not clear whether this refers to "local to the BGP speaker (i.e., the same > system)" or "local to the routing domain (i.e., the same AS)". This must be > clarified in the text below, and the text should be reviewed. > > 5.1.3 NEXT_HOP > > The NEXT_HOP is a well-known mandatory attribute that defines the IP > address of the router that SHOULD be used as the next hop to the des- > tinations listed in the UPDATE message. The NEXT_HOP attribute is > calculated as follows. > > 1) When sending a message to an internal peer, if the route is not > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > attribute, unless it has been explicitly configured to announce > its own IP address as the NEXT_HOP. When announcing a locally > originated route to an internal peer, the BGP speaker SHOULD use > as the NEXT_HOP the interface address of the router through which > the announced network is reachable for the speaker; if the route > is directly connected to the speaker, or the interface address of > the router through which the announced network is reachable for > the speaker is the internal peer's address, then the BGP speaker > SHOULD use for the NEXT_HOP attribute its own IP address (the > address of the interface that is used to reach the peer). > > 4) there appears to have been added some bogosities about inter-AS traffic > engineering in section 9.3: > > - If the local AS appears in the AS path of the new route being > considered, then that new route can not be viewed as better than > any other route (provided that the speaker is configured to accept > such routes). If such a route were ever used, a routing loop could > result. > > and: > > The ability of a BGP speaker to include more than one instance of > its own AS in the AS_PATH attribute for the purpose of inter-AS > traffic engineering. > > ==> what do these have to do with base spec? I don't think they're > operationally feasible or used. Remove any indication that it's OK to > receive your own AS in the routes you receive!! > > 5) the reasoning for this section is not clear. It seems to be two parts > (the second one starting at "These routes..."). It seems partially, at > least for the second part, a set of operational guidelines.. which probably > don't have anything to do with the BGP spec! > > 9.4 Originating BGP routes > > A BGP speaker may originate BGP routes by injecting routing informa- > tion acquired by some other means (e.g. via an IGP) into BGP. A BGP > speaker that originates BGP routes assigns the degree of preference > to these routes by passing them through the Decision Process (see > Section 9.1). These routes MAY also be distributed to other BGP > speakers within the local AS as part of the update process (see Sec- > tion 9.2). The decision whether to distribute non-BGP acquired routes > within an AS via BGP or not depends on the environment within the AS > (e.g. type of IGP) and SHOULD be controlled via configuration. > > 6) references; note that as the Security Consideration section is a bit > short, the vulnerability analysis should be a *NORMATIVE* reference. > However, one must ask here and with RFC2385 as well whether normative > references are OK from Full Standard to a lower maturity level. Unless > this has already been investigated, it may be worth checking with the ADs > that this is OK. > > BGP vulnerabilities analysis is discussed in [XXX]. > > Normative References > > [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 > Signature Option", RFC2385, August 1998. > > Non-normative References > > [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- > ietf-idr-bgp-vuln-00.txt, work in progress > > > semi-substantial > ---------------- > > ==> I'd add "Decision Process", "Routing Table", and "BGP route" in the > terminology. (Especially the last one is a bit shady, see more comments > later.) > > Adj-RIB-In > Adj-RIBs-In > Adj-RIB-Out > Adj-RIBs-Out > > ==> in some places, one seems to use "Adj-RIBs-{In,Out}", in some others, > "Adj-RIB-{In,Out}". The plural/singular form should be consistent. > > BGP speaker > A router that implements BGP. > > ==> uhh, no. Throughout the text "BGP speaker" is used to refer to > BGP-*enabled* routers. Implementation is a required but not sufficient > condition to that. Consider rewording to something like: > > BGP speaker > A router that implements and has been configured to use BGP. > > .... > > BGP Identifier: > > This 4-octet unsigned integer indicates the BGP Identifier of > the sender. A given BGP speaker sets the value of its BGP Iden- > tifier to an IP address assigned to that BGP speaker. The > value of the BGP Identifier is determined on startup and is the > same for every local interface and every BGP peer. > > ==> the last sentence is confusing "same for every local interface".. yeah, > right, but interfaces are irrelevant here. Also, this ignores the fact > that it's perfectly legal to change BGP identifiers after startup but prior > to establishing a BGP session. Consider rewording to something > like: > > This 4-octet unsigned integer indicates the BGP Identifier of > the sender. A given BGP speaker sets the value of its BGP Iden- > tifier to an IP address assigned to that BGP speaker. The > value of the BGP Identifier is determined prior to establishing > BGP sessions and is the same for every session the BGP speaker. > > ... > > Path Attributes: > > A variable length sequence of path attributes is present in > every UPDATE message, except for an UPDATE message that carries > only the withdrawn routes. Each path attribute is a triple > of variable > length. > > ==> should a simple diagram be added here, just like in section 4.2? > > The high-order bit (bit 0) of the Attribute Flags octet is the > Optional bit. It defines whether the attribute is optional (if > set to 1) or well-known (if set to 0). > > ==> this and the following descriptions on attributes are out of place if > you have not described the remaining categories (because they're used when > describing the attributes in the next page), that is, discretionary and > mandatory. Consider rewording the above to something like: > > The high-order bit (bit 0) of the Attribute Flags octet is the > Optional bit. It defines whether the attribute is optional (if > set to 1) or well-known (if set to 0). Well-known attributes can > be either mandatory (MUST be included in every UPDATE message that > contains NLRI), or discretionary (inclusion not required). > > ... > > All well-known attributes MUST be passed along (after proper updat- > ing, if necessary) to other BGP peers. > > ==> LOCAL-PREF is an exception here. I also note that the BGP's definition > of "transitive" is different ("unrecognized optional attributes are only > passed onward when the transitive bit is set, but recognized optional > attributes are always passed onward") from the apparent language ("always passed > along"), and might use a bit of clarification. > > ... > > b) When a given BGP speaker advertises the route to an external > peer, then the advertising speaker updates the AS_PATH attribute > as follows: > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position). > If the act of prepending will cause an overflow in the AS_PATH > segment, i.e. more than 255 ASs, it is legal to prepend a new > segment of type AS_SEQUENCE and prepend its own AS number to > this new segment. > > 2) if the first path segment of the AS_PATH is of type AS_SET, > the local system prepends a new path segment of type > AS_SEQUENCE to the AS_PATH, including its own AS number in that > segment. > > ==> the text here seems confusing because it is not clear whether things are > added at the beginning or at the end of the segments, for example: > > "the _last_ element sequence (put it in the _leftmost_ position)" > > .. I think this requires more precise language on which end of the segment > these values are really inserted. I.e., is it "physically" (in memory) > left-to-right (from more recent to more distant), or just interpreted that > way? This has significant impact on the last sentence of section 1) in case > of overflows and the like. > > Whenever the modification of the AS_PATH attribute calls for includ- > ing or prepending the AS number of the local system, the local system > MAY include/prepend more than one instance of its own AS number in > the AS_PATH attribute. This is controlled via local configuration. > > ==> what about prepending/adding someone else's AS? Is this relevant enough > to be considered? > > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > attribute MUST NOT make any NLRI of that route more specific (as > defined in 9.1.4) when advertising this route to other BGP speakers. > > ==> the second line seems out-of-place here. I assume it means that the > router must not perform automatic de-aggregation, not that the router must > not have more specific routes to advertise. In any case, a rewording might > be in order, e.g. like: > > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that is, > generating more specifics by de-aggregating a route is forbidden. > > (note that this actually makes the statement stronger, and more in line of > 9.1.4, that you should not do it even locally.) > > If the Length field of the message header is less than 19 or greater > than 4096, or if the Length field of an OPEN message is less than the > minimum length of the OPEN message, or if the Length field of an > UPDATE message is less than the minimum length of the UPDATE message, > or if the Length field of a KEEPALIVE message is not equal to 19, or > if the Length field of a NOTIFICATION message is less than the mini- > mum length of the NOTIFICATION message, then the Error Subcode is set > to Bad Message Length. The Data field contains the erroneous Length > field. > > ==> convert this to a bulleted list or something, so it's easier to read, > please! :-) > > The IP address in the NEXT_HOP MUST meet the following criteria to be > considered semantically correct: > > a) It MUST NOT be the IP address of the receiving speaker > > b) In the case of an EBGP where the sender and receiver are one IP > hop away from each other, either the IP address in the NEXT_HOP > MUST be the sender's IP address (that is used to establish the BGP > connection), or the interface associated with the NEXT_HOP IP > address MUST share a common subnet with the receiving BGP speaker. > > > ==> what's exactly the case for the first case of b)? Couldn't thid be > cleaned a bit (it seems to me that the second case is a superset of the > first)? In addition, I'd recommend rewording "one IP hop away" -- > that begs the question whether you mean "direct neighbors" or "just one > transit router". When thinking of it more, the former seems apparent, but a > different wording might flesh this out better. > > If a BGP speaker chooses to aggregate, then it SHOULD either include > all AS used to form the aggreagate in an AS_SET or add the > ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- > marily informational. With the elimination of IP routing protocols > that do not support classless routing and the elimination of router > and host implementations that do not support classless routing, there > is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- > gated. A route that carries ATOMIC_AGGREGATE attribute in particular > MUST NOT be de-aggregated. That is, the NLRI of this route can not be > made more specific. Forwarding along such a route does not guarantee > that IP packets will actually traverse only ASs listed in the AS_PATH > attribute of the route. > > ==> this is confusing, especially the end, beginning from "That is, ..." and > should be reworded a bit (does it cover only deaggregation or more specifics > in general?), like: > > If a BGP speaker chooses to aggregate, then it SHOULD either include > all AS used to form the aggreagate in an AS_SET or add the > ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- > marily informational. With the elimination of IP routing protocols > that do not support classless routing and the elimination of router > and host implementations that do not support classless routing, there > is no longer a need to deaggregate. > > Routes SHOULD NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE > attribute in particular MUST NOT be de-aggregated. That is, one must not > generate more specifics of the NLRI of this route. Forwarding along > such a route does not guarantee > that IP packets will actually traverse only ASs listed in the AS_PATH > attribute of the route. However, accepting more specific advertisments > which an aggregate route covers is acceptable. > > ... > > A BGP speaker SHOULD NOT advertise a given feasible BGP route from > its Adj-RIB-Out if it would produce an UPDATE message containing the > same BGP route as was previously advertised. > > ==> and now we get back to the definition of "same BGP route"? Identical prefix > carried over BGP? Identical prefix carried over BGP with identical attributes?" > I'm assuming the former, otherwise (at least!) the above should be > clarified. > > Aggregation reduces the amount of information that a BGP speaker must > store and exchange with other BGP speakers. Routes can be aggregated > by applying the following procedure separately to path attributes of > like type and to the Network Layer Reachability Information. > > ==> the last line sounds really weird; consider: > - s/like/the same/ ? > - add more text after the NLRI, like "NLRI field" ? > > > > typos or other editorials > ------------------------- > > ==> there should not be hyphenation at the linebreaks. > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > ==> s/extention/extension/ (two places) > > 3.2 Routing Information Bases > > The Routing Information Base (RIB) within a BGP speaker consists of > three distinct parts: > > ==> the subject is in plural form ("RIBs"), but the text begins as singular > ("The RIB"). Consider which one to use? > > a) ORIGIN (Type Code 1): > > b) AS_PATH (Type Code 2): > > ==> kill the extra spaces before ORIGIN and NEXT_HOP. > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position). > > ==> rewrite the last one as: > last element of the sequence, putting it in the leftmost position. > > A BGP speaker MUST IMPLEMENT a mechanism based on local configuration > > ==> s/IMPLEMENT/implement/ > > used by a BGP speaker's decision process to discriminate > > ==> s/decision process/Decision Process/ (similar in a few other places?) > > attribute needs to be cognizant of the fact that the actual path to > > ==> s/cognizant/aware/ > > 6. BGP Error Handling. > > ==> remove the periods from at the end of section titles, esp. in subctions > of section 6. > > issue a open collision dump [Event 23]. When the local > system receives a open collision dump event [Event 23], the > > ==> s/a open/an open/ (two times) > > installed in LocRib and will be excluded from the next phase of route > > ==> s/LocRib/Loc-RIB/ > > all AS used to form the aggreagate in an AS_SET or add the > > ==> s/aggreagate/aggregate/ > > is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- > gated. A route that carries ATOMIC_AGGREGATE attribute in particular > MUST NOT be de-aggregated. That is, the NLRI of this route can not be > > ==> pick either "deaggregate" or "de-aggregate" and stick to that. > > have the origin attribute with the value EGP. In all other case > > ==> s/case/cases/ > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Sep 25 01:11:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24977 for ; Thu, 25 Sep 2003 01:11:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2OOp-0003CT-HG for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 01:10:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8P5AhsT012287 for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 01:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2OOp-0003Bw-BT for idr-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 01:10:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24946; Thu, 25 Sep 2003 01:10:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2OOl-0000ME-00; Thu, 25 Sep 2003 01:10:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2OOl-0000M7-00; Thu, 25 Sep 2003 01:10:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2OO9-000337-Eo; Thu, 25 Sep 2003 01:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ONc-00032g-BB for idr@optimus.ietf.org; Thu, 25 Sep 2003 01:09:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24903 for ; Thu, 25 Sep 2003 01:09:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ONY-0000LD-00 for idr@ietf.org; Thu, 25 Sep 2003 01:09:24 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ONX-0000L6-00 for idr@ietf.org; Thu, 25 Sep 2003 01:09:23 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8P58gL30140; Thu, 25 Sep 2003 08:08:43 +0300 From: Pekka Savola To: Susan Hares cc: idr@ietf.org Subject: RE: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 08:08:42 +0300 (EEST) On Wed, 24 Sep 2003, Susan Hares wrote: > For context on the message, could you > tell me are you: > > 2) Operator using BGP Operator. > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, September 24, 2003 3:50 AM > To: idr@ietf.org > Subject: [Idr] comments on idr-bgp4-20 > > > Hi, > > [note, I'm not subscribed to the idr list] > > Alex solicited ops-dir for folks to review bgp4-20 spec. After almost > half a year, I finally found the time to look at it. Comments below. I > tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at > least on the quick glance, I didn't find major overlaps. > > Overview: > - the spec is in pretty good shape, but I'm not sure if all the features > listed are really full standard material.. it might be better to separate > some of them (e.g. anything relating to aggregation) to a separate doc (so > that we'd have a much tigher and better real base spec), and recycle it at > DS, but that might be much more effort.. not sure if something like that > would be worth it. > > General thoughts on going to full standard: > - If we want to go for full standard, I have to question the usefulness of > several BGP features: > - AS_SET AS_PATH attribute > - whole route aggregation concept (nowadays, it seems to be causing > more trouble than it's worth -- instead of proper advertisements, just > automatically aggregate instead of fixing the advertisements to begin > with). Maybe pver 10 years ago it may have been relevant if all the edge > BGP routers might not support BGP-4 or CIDR.. > - about N++ different cases of third-party nexthop usage. > > As a general observation from the text: > - I skipped section 8 on FSM, as it was really boring, and I'm not sure > whehter it's of any use keeping it in the base spec. > - I got major headache when trying to read the aggregating rules > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > rules :-(!!!) and ended up skipping them. > > substantial > ----------- > > 1) Section 3 on Summary of the Operations, states: > > In the context of this document we assume that a BGP speaker adver- > tises to its peers only those routes that it itself uses (in this > context a BGP speaker is said to "use" a BGP route if it is the most > preferred BGP route and is used in forwarding). All other cases are > outside the scope of this document. > > this "usability" requirement is in conflict with section 4.3 on UPDATE > message format: > > An UPDATE message is used to advertise feasible routes sharing common > path attributes to a peer, [...] > > ==> in particular note that "feasible" is a superset of "only those routes > the router itself uses" (compare to "those routes the router itself _could_ > use if they were the most preferred ones"), right? > > ==> also note that the former definition is (IMHO) operationally unsound. > It prevents you from advertising P-t-P addresses and loopbacks (which also > reside in IGP) using BGP, because the IGP distance is lower than BGP and > "BGP route is never used in forwarding". (depending on how you interpret > that). IMHO, this really needs to be changed to be OK. > > 2) The OPEN message format is confusing. Why on earth do you have those > empty bits there? Are they null-padding or just a typographical convention > for the clarity of the diagram (the latter)? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | My Autonomous System | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hold Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BGP Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opt Parm Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Optional Parameters (variable) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ==> I strongly recommend to either: > 1) go back to standard format, or > 2) rephrase the message format similar with UPDATE messages, i.e., drop all > the pretense about field lengths, bits 0-31, etc. > > 3) there is significant confusion on what "locally originated" means. It is > not clear whether this refers to "local to the BGP speaker (i.e., the same > system)" or "local to the routing domain (i.e., the same AS)". This must be > clarified in the text below, and the text should be reviewed. > > 5.1.3 NEXT_HOP > > The NEXT_HOP is a well-known mandatory attribute that defines the IP > address of the router that SHOULD be used as the next hop to the des- > tinations listed in the UPDATE message. The NEXT_HOP attribute is > calculated as follows. > > 1) When sending a message to an internal peer, if the route is not > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > attribute, unless it has been explicitly configured to announce > its own IP address as the NEXT_HOP. When announcing a locally > originated route to an internal peer, the BGP speaker SHOULD use > as the NEXT_HOP the interface address of the router through which > the announced network is reachable for the speaker; if the route > is directly connected to the speaker, or the interface address of > the router through which the announced network is reachable for > the speaker is the internal peer's address, then the BGP speaker > SHOULD use for the NEXT_HOP attribute its own IP address (the > address of the interface that is used to reach the peer). > > 4) there appears to have been added some bogosities about inter-AS traffic > engineering in section 9.3: > > - If the local AS appears in the AS path of the new route being > considered, then that new route can not be viewed as better than > any other route (provided that the speaker is configured to accept > such routes). If such a route were ever used, a routing loop could > result. > > and: > > The ability of a BGP speaker to include more than one instance of > its own AS in the AS_PATH attribute for the purpose of inter-AS > traffic engineering. > > ==> what do these have to do with base spec? I don't think they're > operationally feasible or used. Remove any indication that it's OK to > receive your own AS in the routes you receive!! > > 5) the reasoning for this section is not clear. It seems to be two parts > (the second one starting at "These routes..."). It seems partially, at > least for the second part, a set of operational guidelines.. which probably > don't have anything to do with the BGP spec! > > 9.4 Originating BGP routes > > A BGP speaker may originate BGP routes by injecting routing informa- > tion acquired by some other means (e.g. via an IGP) into BGP. A BGP > speaker that originates BGP routes assigns the degree of preference > to these routes by passing them through the Decision Process (see > Section 9.1). These routes MAY also be distributed to other BGP > speakers within the local AS as part of the update process (see Sec- > tion 9.2). The decision whether to distribute non-BGP acquired routes > within an AS via BGP or not depends on the environment within the AS > (e.g. type of IGP) and SHOULD be controlled via configuration. > > 6) references; note that as the Security Consideration section is a bit > short, the vulnerability analysis should be a *NORMATIVE* reference. > However, one must ask here and with RFC2385 as well whether normative > references are OK from Full Standard to a lower maturity level. Unless > this has already been investigated, it may be worth checking with the ADs > that this is OK. > > BGP vulnerabilities analysis is discussed in [XXX]. > > Normative References > > [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 > Signature Option", RFC2385, August 1998. > > Non-normative References > > [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- > ietf-idr-bgp-vuln-00.txt, work in progress > > > semi-substantial > ---------------- > > ==> I'd add "Decision Process", "Routing Table", and "BGP route" in the > terminology. (Especially the last one is a bit shady, see more comments > later.) > > Adj-RIB-In > Adj-RIBs-In > Adj-RIB-Out > Adj-RIBs-Out > > ==> in some places, one seems to use "Adj-RIBs-{In,Out}", in some others, > "Adj-RIB-{In,Out}". The plural/singular form should be consistent. > > BGP speaker > A router that implements BGP. > > ==> uhh, no. Throughout the text "BGP speaker" is used to refer to > BGP-*enabled* routers. Implementation is a required but not sufficient > condition to that. Consider rewording to something like: > > BGP speaker > A router that implements and has been configured to use BGP. > > .... > > BGP Identifier: > > This 4-octet unsigned integer indicates the BGP Identifier of > the sender. A given BGP speaker sets the value of its BGP Iden- > tifier to an IP address assigned to that BGP speaker. The > value of the BGP Identifier is determined on startup and is the > same for every local interface and every BGP peer. > > ==> the last sentence is confusing "same for every local interface".. yeah, > right, but interfaces are irrelevant here. Also, this ignores the fact > that it's perfectly legal to change BGP identifiers after startup but prior > to establishing a BGP session. Consider rewording to something > like: > > This 4-octet unsigned integer indicates the BGP Identifier of > the sender. A given BGP speaker sets the value of its BGP Iden- > tifier to an IP address assigned to that BGP speaker. The > value of the BGP Identifier is determined prior to establishing > BGP sessions and is the same for every session the BGP speaker. > > ... > > Path Attributes: > > A variable length sequence of path attributes is present in > every UPDATE message, except for an UPDATE message that carries > only the withdrawn routes. Each path attribute is a triple > of variable > length. > > ==> should a simple diagram be added here, just like in section 4.2? > > The high-order bit (bit 0) of the Attribute Flags octet is the > Optional bit. It defines whether the attribute is optional (if > set to 1) or well-known (if set to 0). > > ==> this and the following descriptions on attributes are out of place if > you have not described the remaining categories (because they're used when > describing the attributes in the next page), that is, discretionary and > mandatory. Consider rewording the above to something like: > > The high-order bit (bit 0) of the Attribute Flags octet is the > Optional bit. It defines whether the attribute is optional (if > set to 1) or well-known (if set to 0). Well-known attributes can > be either mandatory (MUST be included in every UPDATE message that > contains NLRI), or discretionary (inclusion not required). > > ... > > All well-known attributes MUST be passed along (after proper updat- > ing, if necessary) to other BGP peers. > > ==> LOCAL-PREF is an exception here. I also note that the BGP's definition > of "transitive" is different ("unrecognized optional attributes are only > passed onward when the transitive bit is set, but recognized optional > attributes are always passed onward") from the apparent language ("always passed > along"), and might use a bit of clarification. > > ... > > b) When a given BGP speaker advertises the route to an external > peer, then the advertising speaker updates the AS_PATH attribute > as follows: > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position). > If the act of prepending will cause an overflow in the AS_PATH > segment, i.e. more than 255 ASs, it is legal to prepend a new > segment of type AS_SEQUENCE and prepend its own AS number to > this new segment. > > 2) if the first path segment of the AS_PATH is of type AS_SET, > the local system prepends a new path segment of type > AS_SEQUENCE to the AS_PATH, including its own AS number in that > segment. > > ==> the text here seems confusing because it is not clear whether things are > added at the beginning or at the end of the segments, for example: > > "the _last_ element sequence (put it in the _leftmost_ position)" > > .. I think this requires more precise language on which end of the segment > these values are really inserted. I.e., is it "physically" (in memory) > left-to-right (from more recent to more distant), or just interpreted that > way? This has significant impact on the last sentence of section 1) in case > of overflows and the like. > > Whenever the modification of the AS_PATH attribute calls for includ- > ing or prepending the AS number of the local system, the local system > MAY include/prepend more than one instance of its own AS number in > the AS_PATH attribute. This is controlled via local configuration. > > ==> what about prepending/adding someone else's AS? Is this relevant enough > to be considered? > > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > attribute MUST NOT make any NLRI of that route more specific (as > defined in 9.1.4) when advertising this route to other BGP speakers. > > ==> the second line seems out-of-place here. I assume it means that the > router must not perform automatic de-aggregation, not that the router must > not have more specific routes to advertise. In any case, a rewording might > be in order, e.g. like: > > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that is, > generating more specifics by de-aggregating a route is forbidden. > > (note that this actually makes the statement stronger, and more in line of > 9.1.4, that you should not do it even locally.) > > If the Length field of the message header is less than 19 or greater > than 4096, or if the Length field of an OPEN message is less than the > minimum length of the OPEN message, or if the Length field of an > UPDATE message is less than the minimum length of the UPDATE message, > or if the Length field of a KEEPALIVE message is not equal to 19, or > if the Length field of a NOTIFICATION message is less than the mini- > mum length of the NOTIFICATION message, then the Error Subcode is set > to Bad Message Length. The Data field contains the erroneous Length > field. > > ==> convert this to a bulleted list or something, so it's easier to read, > please! :-) > > The IP address in the NEXT_HOP MUST meet the following criteria to be > considered semantically correct: > > a) It MUST NOT be the IP address of the receiving speaker > > b) In the case of an EBGP where the sender and receiver are one IP > hop away from each other, either the IP address in the NEXT_HOP > MUST be the sender's IP address (that is used to establish the BGP > connection), or the interface associated with the NEXT_HOP IP > address MUST share a common subnet with the receiving BGP speaker. > > > ==> what's exactly the case for the first case of b)? Couldn't thid be > cleaned a bit (it seems to me that the second case is a superset of the > first)? In addition, I'd recommend rewording "one IP hop away" -- > that begs the question whether you mean "direct neighbors" or "just one > transit router". When thinking of it more, the former seems apparent, but a > different wording might flesh this out better. > > If a BGP speaker chooses to aggregate, then it SHOULD either include > all AS used to form the aggreagate in an AS_SET or add the > ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- > marily informational. With the elimination of IP routing protocols > that do not support classless routing and the elimination of router > and host implementations that do not support classless routing, there > is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- > gated. A route that carries ATOMIC_AGGREGATE attribute in particular > MUST NOT be de-aggregated. That is, the NLRI of this route can not be > made more specific. Forwarding along such a route does not guarantee > that IP packets will actually traverse only ASs listed in the AS_PATH > attribute of the route. > > ==> this is confusing, especially the end, beginning from "That is, ..." and > should be reworded a bit (does it cover only deaggregation or more specifics > in general?), like: > > If a BGP speaker chooses to aggregate, then it SHOULD either include > all AS used to form the aggreagate in an AS_SET or add the > ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- > marily informational. With the elimination of IP routing protocols > that do not support classless routing and the elimination of router > and host implementations that do not support classless routing, there > is no longer a need to deaggregate. > > Routes SHOULD NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE > attribute in particular MUST NOT be de-aggregated. That is, one must not > generate more specifics of the NLRI of this route. Forwarding along > such a route does not guarantee > that IP packets will actually traverse only ASs listed in the AS_PATH > attribute of the route. However, accepting more specific advertisments > which an aggregate route covers is acceptable. > > ... > > A BGP speaker SHOULD NOT advertise a given feasible BGP route from > its Adj-RIB-Out if it would produce an UPDATE message containing the > same BGP route as was previously advertised. > > ==> and now we get back to the definition of "same BGP route"? Identical prefix > carried over BGP? Identical prefix carried over BGP with identical attributes?" > I'm assuming the former, otherwise (at least!) the above should be > clarified. > > Aggregation reduces the amount of information that a BGP speaker must > store and exchange with other BGP speakers. Routes can be aggregated > by applying the following procedure separately to path attributes of > like type and to the Network Layer Reachability Information. > > ==> the last line sounds really weird; consider: > - s/like/the same/ ? > - add more text after the NLRI, like "NLRI field" ? > > > > typos or other editorials > ------------------------- > > ==> there should not be hyphenation at the linebreaks. > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > ==> s/extention/extension/ (two places) > > 3.2 Routing Information Bases > > The Routing Information Base (RIB) within a BGP speaker consists of > three distinct parts: > > ==> the subject is in plural form ("RIBs"), but the text begins as singular > ("The RIB"). Consider which one to use? > > a) ORIGIN (Type Code 1): > > b) AS_PATH (Type Code 2): > > ==> kill the extra spaces before ORIGIN and NEXT_HOP. > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position). > > ==> rewrite the last one as: > last element of the sequence, putting it in the leftmost position. > > A BGP speaker MUST IMPLEMENT a mechanism based on local configuration > > ==> s/IMPLEMENT/implement/ > > used by a BGP speaker's decision process to discriminate > > ==> s/decision process/Decision Process/ (similar in a few other places?) > > attribute needs to be cognizant of the fact that the actual path to > > ==> s/cognizant/aware/ > > 6. BGP Error Handling. > > ==> remove the periods from at the end of section titles, esp. in subctions > of section 6. > > issue a open collision dump [Event 23]. When the local > system receives a open collision dump event [Event 23], the > > ==> s/a open/an open/ (two times) > > installed in LocRib and will be excluded from the next phase of route > > ==> s/LocRib/Loc-RIB/ > > all AS used to form the aggreagate in an AS_SET or add the > > ==> s/aggreagate/aggregate/ > > is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- > gated. A route that carries ATOMIC_AGGREGATE attribute in particular > MUST NOT be de-aggregated. That is, the NLRI of this route can not be > > ==> pick either "deaggregate" or "de-aggregate" and stick to that. > > have the origin attribute with the value EGP. In all other case > > ==> s/case/cases/ > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Sep 25 03:33:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11624; Thu, 25 Sep 2003 03:33:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Qcp-0001uh-00; Thu, 25 Sep 2003 03:33:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Qcp-0001ue-00; Thu, 25 Sep 2003 03:33:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2QcX-0004JO-Lm; Thu, 25 Sep 2003 03:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Qba-0004IO-7l for idr@optimus.ietf.org; Thu, 25 Sep 2003 03:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11580 for ; Thu, 25 Sep 2003 03:31:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2QbX-0001uE-00 for idr@ietf.org; Thu, 25 Sep 2003 03:31:59 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2QbX-0001tw-00 for idr@ietf.org; Thu, 25 Sep 2003 03:31:59 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8P7VKe31620; Thu, 25 Sep 2003 10:31:20 +0300 From: Pekka Savola To: "John G. Scudder" cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 10:31:20 +0300 (EEST) On Wed, 24 Sep 2003, John G. Scudder wrote: > At 10:50 AM +0300 9/24/03, Pekka Savola wrote: > >General thoughts on going to full standard: > > The process the IDR group has been following so far is to try to > document the existing protocol rather than to tweak it. In your > first few comments you seem to be suggesting that the protocol as > currently deployed isn't suitable for full standard and should be > tweaked. Is that what you meant to say? Yes. And moreover, there are certain aspects of the protocol which we may now consider pretty obsolete. Consider that we'd like to deprecate them in 3 years. Doing that from inside Full Standard could be painful -- in practice, to avoid the confusion, the spec should be re-issued. However, if they are in separate portions it would be easier. What I'm trying to say is that the current base spec is very relevant for most parts, and likely continue to be so. However, I see several parts (esp. relating to aggregation) which are no longer relevant, may get to be even more irrelevant, and may even turn out to be dangerous or harmful later on (considering sBGP/soBGP, for example). To me, it would seem to be useful to be "proactive" before going to full standard, and take out those parts which we think do not have long-term usefullness as a full standard. > > - If we want to go for full standard, I have to question the usefulness of > >several BGP features: > > - AS_SET AS_PATH attribute > > I can imagine why you think this; however, given that AS_SET is > already part of presumably all BGP implementations, I can't think of > a reason to remove it. On the other hand, I can think of various > reasons to keep it, including but not limited to "if it ain't broke, > don't fix it." There are tradeoffs both ways, that's for sure. I don't have a really strong opinion on this. > > - whole route aggregation concept (nowadays, it seems to be causing > >more trouble than it's worth -- instead of proper advertisements, just > >automatically aggregate instead of fixing the advertisements to begin > >with). Maybe pver 10 years ago it may have been relevant if all the edge > >BGP routers might not support BGP-4 or CIDR.. > > I honestly don't understand the point you're trying to make here. See above, in my first comment. Automatic route aggregation *in the protocol* (instead of *operationally*) is a very, very questionable concept. Something we could very well live without... > > - about N++ different cases of third-party nexthop usage. > > Are you suggesting that third-party nexthop should be removed from > the spec (and from implementations)? If so, I think more > justification will be needed. What I say that those scenarios could be moved to a separate spec, and accepting third-party nexthops might not be necessary for those who want plain next-hop behaviour only. The code will probably stay as is for some time at least. > >4) there appears to have been added some bogosities about inter-AS traffic > >engineering in section 9.3: > > > > - If the local AS appears in the AS path of the new route being > > considered, then that new route can not be viewed as better than > > any other route (provided that the speaker is configured to accept > > such routes). If such a route were ever used, a routing loop could > > result. > > [...] > > > >==> what do these have to do with base spec? I don't think they're > >operationally feasible or used. Remove any indication that it's OK to > >receive your own AS in the routes you receive!! > > I beg to differ. The former is not common practice but is not > unknown either (it's historically there to allow a partitioned AS to > be healed through an external path). The whole point of the AS is that it's not partitioned. I don't think this is needed, or useful at all. > The latter (AS Path padding) is > incredibly common. The text should be left as is, except that I > wouldn't object to the removal of the clause "for the purpose of > inter-AS traffic engineering." Sorry, I misread the comment (removed from above in clarity). Prepending your own AS is perfectly fine to me. > > attribute needs to be cognizant of the fact that the actual path to > > > >==> s/cognizant/aware/ > > Why? Why use complex words when simpler ones suit just as well? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Sep 25 03:33:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11650 for ; Thu, 25 Sep 2003 03:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Qcs-0004M6-T3 for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 03:33:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8P7XM1G016740 for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 03:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Qcs-0004Lv-JL for idr-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 03:33:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11624; Thu, 25 Sep 2003 03:33:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Qcp-0001uh-00; Thu, 25 Sep 2003 03:33:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Qcp-0001ue-00; Thu, 25 Sep 2003 03:33:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2QcX-0004JO-Lm; Thu, 25 Sep 2003 03:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Qba-0004IO-7l for idr@optimus.ietf.org; Thu, 25 Sep 2003 03:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11580 for ; Thu, 25 Sep 2003 03:31:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2QbX-0001uE-00 for idr@ietf.org; Thu, 25 Sep 2003 03:31:59 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2QbX-0001tw-00 for idr@ietf.org; Thu, 25 Sep 2003 03:31:59 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8P7VKe31620; Thu, 25 Sep 2003 10:31:20 +0300 From: Pekka Savola To: "John G. Scudder" cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 10:31:20 +0300 (EEST) On Wed, 24 Sep 2003, John G. Scudder wrote: > At 10:50 AM +0300 9/24/03, Pekka Savola wrote: > >General thoughts on going to full standard: > > The process the IDR group has been following so far is to try to > document the existing protocol rather than to tweak it. In your > first few comments you seem to be suggesting that the protocol as > currently deployed isn't suitable for full standard and should be > tweaked. Is that what you meant to say? Yes. And moreover, there are certain aspects of the protocol which we may now consider pretty obsolete. Consider that we'd like to deprecate them in 3 years. Doing that from inside Full Standard could be painful -- in practice, to avoid the confusion, the spec should be re-issued. However, if they are in separate portions it would be easier. What I'm trying to say is that the current base spec is very relevant for most parts, and likely continue to be so. However, I see several parts (esp. relating to aggregation) which are no longer relevant, may get to be even more irrelevant, and may even turn out to be dangerous or harmful later on (considering sBGP/soBGP, for example). To me, it would seem to be useful to be "proactive" before going to full standard, and take out those parts which we think do not have long-term usefullness as a full standard. > > - If we want to go for full standard, I have to question the usefulness of > >several BGP features: > > - AS_SET AS_PATH attribute > > I can imagine why you think this; however, given that AS_SET is > already part of presumably all BGP implementations, I can't think of > a reason to remove it. On the other hand, I can think of various > reasons to keep it, including but not limited to "if it ain't broke, > don't fix it." There are tradeoffs both ways, that's for sure. I don't have a really strong opinion on this. > > - whole route aggregation concept (nowadays, it seems to be causing > >more trouble than it's worth -- instead of proper advertisements, just > >automatically aggregate instead of fixing the advertisements to begin > >with). Maybe pver 10 years ago it may have been relevant if all the edge > >BGP routers might not support BGP-4 or CIDR.. > > I honestly don't understand the point you're trying to make here. See above, in my first comment. Automatic route aggregation *in the protocol* (instead of *operationally*) is a very, very questionable concept. Something we could very well live without... > > - about N++ different cases of third-party nexthop usage. > > Are you suggesting that third-party nexthop should be removed from > the spec (and from implementations)? If so, I think more > justification will be needed. What I say that those scenarios could be moved to a separate spec, and accepting third-party nexthops might not be necessary for those who want plain next-hop behaviour only. The code will probably stay as is for some time at least. > >4) there appears to have been added some bogosities about inter-AS traffic > >engineering in section 9.3: > > > > - If the local AS appears in the AS path of the new route being > > considered, then that new route can not be viewed as better than > > any other route (provided that the speaker is configured to accept > > such routes). If such a route were ever used, a routing loop could > > result. > > [...] > > > >==> what do these have to do with base spec? I don't think they're > >operationally feasible or used. Remove any indication that it's OK to > >receive your own AS in the routes you receive!! > > I beg to differ. The former is not common practice but is not > unknown either (it's historically there to allow a partitioned AS to > be healed through an external path). The whole point of the AS is that it's not partitioned. I don't think this is needed, or useful at all. > The latter (AS Path padding) is > incredibly common. The text should be left as is, except that I > wouldn't object to the removal of the clause "for the purpose of > inter-AS traffic engineering." Sorry, I misread the comment (removed from above in clarity). Prepending your own AS is perfectly fine to me. > > attribute needs to be cognizant of the fact that the actual path to > > > >==> s/cognizant/aware/ > > Why? Why use complex words when simpler ones suit just as well? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Sep 25 11:15:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29805; Thu, 25 Sep 2003 11:15:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xq0-0007XJ-00; Thu, 25 Sep 2003 11:15:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Xq0-0007XG-00; Thu, 25 Sep 2003 11:15:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xpd-0007UW-Or; Thu, 25 Sep 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xof-0007Ax-I1 for idr@optimus.ietf.org; Thu, 25 Sep 2003 11:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29647 for ; Thu, 25 Sep 2003 11:13:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xoe-0007Tl-00 for idr@ietf.org; Thu, 25 Sep 2003 11:14:00 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Xoe-0007Sa-00 for idr@ietf.org; Thu, 25 Sep 2003 11:14:00 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8PFDOS2085829; Thu, 25 Sep 2003 11:13:24 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8PFDFOT085822; Thu, 25 Sep 2003 11:13:15 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8PFDAR14455; Thu, 25 Sep 2003 11:13:10 -0400 (EDT) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 Message-ID: <20030925111310.A14433@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Thu, Sep 25, 2003 at 10:31:20AM +0300 X-Virus-Scanned: by AMaViS perl-11 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 11:13:10 -0400 On Thu, Sep 25, 2003 at 10:31:20AM +0300, Pekka Savola wrote: > See above, in my first comment. Automatic route aggregation *in the > protocol* (instead of *operationally*) is a very, very questionable > concept. Something we could very well live without... Perhaps I am not seeing the same thing, but what "automatic" route aggregation? Every implementation I've worked with requires explicit configuration. The aggregation rules in the spec say what to do when you do this. > > What I say that those scenarios could be moved to a separate spec, and > accepting third-party nexthops might not be necessary for those who want > plain next-hop behaviour only. The code will probably stay as is for some > time at least. First-party nexthops introduce sub-optimal routing. Why would we want to introduce mandatory first party nexthops and optional third-party? > The whole point of the AS is that it's not partitioned. I don't think > this is needed, or useful at all. Consider this rather simplified example: ........ ........ : : : : : AS 1 :---: AS 1 : :......: :......: \ / \ / ( ) ( Internet ) ( ) AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS with a single point of failure between two portions of itself. In the case of failure of the link, it is possible to maintain internal reachability via the Internet by allowing the Internet Border Routers to ignore a looped condition. This is *not* a normal circumstance, this is highly abnormal. However, it can be darned handy. Other mechanisms such as tunneling between the pieces of the partitioned AS have been done as well. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Sep 25 11:15:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29848 for ; Thu, 25 Sep 2003 11:15:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xq1-0007YP-VO for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 11:15:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PFFPVl029036 for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 11:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xq1-0007YF-SJ for idr-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 11:15:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29805; Thu, 25 Sep 2003 11:15:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xq0-0007XJ-00; Thu, 25 Sep 2003 11:15:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Xq0-0007XG-00; Thu, 25 Sep 2003 11:15:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xpd-0007UW-Or; Thu, 25 Sep 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xof-0007Ax-I1 for idr@optimus.ietf.org; Thu, 25 Sep 2003 11:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29647 for ; Thu, 25 Sep 2003 11:13:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xoe-0007Tl-00 for idr@ietf.org; Thu, 25 Sep 2003 11:14:00 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Xoe-0007Sa-00 for idr@ietf.org; Thu, 25 Sep 2003 11:14:00 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8PFDOS2085829; Thu, 25 Sep 2003 11:13:24 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8PFDFOT085822; Thu, 25 Sep 2003 11:13:15 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8PFDAR14455; Thu, 25 Sep 2003 11:13:10 -0400 (EDT) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 Message-ID: <20030925111310.A14433@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Thu, Sep 25, 2003 at 10:31:20AM +0300 X-Virus-Scanned: by AMaViS perl-11 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 11:13:10 -0400 On Thu, Sep 25, 2003 at 10:31:20AM +0300, Pekka Savola wrote: > See above, in my first comment. Automatic route aggregation *in the > protocol* (instead of *operationally*) is a very, very questionable > concept. Something we could very well live without... Perhaps I am not seeing the same thing, but what "automatic" route aggregation? Every implementation I've worked with requires explicit configuration. The aggregation rules in the spec say what to do when you do this. > > What I say that those scenarios could be moved to a separate spec, and > accepting third-party nexthops might not be necessary for those who want > plain next-hop behaviour only. The code will probably stay as is for some > time at least. First-party nexthops introduce sub-optimal routing. Why would we want to introduce mandatory first party nexthops and optional third-party? > The whole point of the AS is that it's not partitioned. I don't think > this is needed, or useful at all. Consider this rather simplified example: ........ ........ : : : : : AS 1 :---: AS 1 : :......: :......: \ / \ / ( ) ( Internet ) ( ) AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS with a single point of failure between two portions of itself. In the case of failure of the link, it is possible to maintain internal reachability via the Internet by allowing the Internet Border Routers to ignore a looped condition. This is *not* a normal circumstance, this is highly abnormal. However, it can be darned handy. Other mechanisms such as tunneling between the pieces of the partitioned AS have been done as well. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Sep 25 12:28:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03595; Thu, 25 Sep 2003 12:28:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2YyW-0000u0-00; Thu, 25 Sep 2003 12:28:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2YyW-0000tx-00; Thu, 25 Sep 2003 12:28:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YyG-000486-W7; Thu, 25 Sep 2003 12:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Yxf-00046J-6g for idr@optimus.ietf.org; Thu, 25 Sep 2003 12:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03571 for ; Thu, 25 Sep 2003 12:27:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yxd-0000tY-00 for idr@ietf.org; Thu, 25 Sep 2003 12:27:21 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yxc-0000tF-00 for idr@ietf.org; Thu, 25 Sep 2003 12:27:20 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8PGQft08409; Thu, 25 Sep 2003 19:26:42 +0300 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <20030925111310.A14433@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 19:26:40 +0300 (EEST) On Thu, 25 Sep 2003, Jeffrey Haas wrote: > On Thu, Sep 25, 2003 at 10:31:20AM +0300, Pekka Savola wrote: > > See above, in my first comment. Automatic route aggregation *in the > > protocol* (instead of *operationally*) is a very, very questionable > > concept. Something we could very well live without... > > Perhaps I am not seeing the same thing, but what "automatic" route > aggregation? Every implementation I've worked with requires > explicit configuration. The aggregation rules in the spec say what > to do when you do this. "auto-summary" (in Cisco terms) has bitten us a couple of times. It's automatic. But then again, I may be misremembering something (and I'm not 100% sure auto-summary is directly related to aggregation, but the concept is similar). The problem with aggregation I see is that more often than not it does nothing to reduce the number of advertisements (or anything useful for that matter). ISPs let through the more specifics in addition to the aggregate (seems to be the default config too). How is this useful? I'm having trouble figuring out real applicability for aggregation. > > What I say that those scenarios could be moved to a separate spec, and > > accepting third-party nexthops might not be necessary for those who want > > plain next-hop behaviour only. The code will probably stay as is for some > > time at least. > > First-party nexthops introduce sub-optimal routing. Why would we want > to introduce mandatory first party nexthops and optional third-party? Note, I'm discussing third-party nexthops in EBGP only (I'm not sure if I mentioned this explicitly, or if there's a need to). Why would you need the optimal routing w/ third-party next-hops and EBGP? You can just go through the BGP speaker, period. (In case if you pass through an Internet Exchange more than once.) > > The whole point of the AS is that it's not partitioned. I don't think > > this is needed, or useful at all. > > Consider this rather simplified example: > > ........ ........ > : : : : > : AS 1 :---: AS 1 : > :......: :......: > \ / > \ / > ( ) > ( Internet ) > ( ) > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS > with a single point of failure between two portions of itself. > In the case of failure of the link, it is possible to maintain > internal reachability via the Internet by allowing the Internet > Border Routers to ignore a looped condition. > > This is *not* a normal circumstance, this is highly abnormal. > However, it can be darned handy. This is a bug, not feature. Your internal connectivity just *isn't* meant to be routed through the Internet. > Other mechanisms such as tunneling between the pieces of the > partitioned AS have been done as well. Right! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Sep 25 12:28:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03621 for ; Thu, 25 Sep 2003 12:28:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YyY-0004CK-Lp for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 12:28:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PGSIJM016130 for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 12:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YyY-0004C5-HL for idr-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 12:28:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03595; Thu, 25 Sep 2003 12:28:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2YyW-0000u0-00; Thu, 25 Sep 2003 12:28:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2YyW-0000tx-00; Thu, 25 Sep 2003 12:28:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YyG-000486-W7; Thu, 25 Sep 2003 12:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Yxf-00046J-6g for idr@optimus.ietf.org; Thu, 25 Sep 2003 12:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03571 for ; Thu, 25 Sep 2003 12:27:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yxd-0000tY-00 for idr@ietf.org; Thu, 25 Sep 2003 12:27:21 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yxc-0000tF-00 for idr@ietf.org; Thu, 25 Sep 2003 12:27:20 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8PGQft08409; Thu, 25 Sep 2003 19:26:42 +0300 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <20030925111310.A14433@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 19:26:40 +0300 (EEST) On Thu, 25 Sep 2003, Jeffrey Haas wrote: > On Thu, Sep 25, 2003 at 10:31:20AM +0300, Pekka Savola wrote: > > See above, in my first comment. Automatic route aggregation *in the > > protocol* (instead of *operationally*) is a very, very questionable > > concept. Something we could very well live without... > > Perhaps I am not seeing the same thing, but what "automatic" route > aggregation? Every implementation I've worked with requires > explicit configuration. The aggregation rules in the spec say what > to do when you do this. "auto-summary" (in Cisco terms) has bitten us a couple of times. It's automatic. But then again, I may be misremembering something (and I'm not 100% sure auto-summary is directly related to aggregation, but the concept is similar). The problem with aggregation I see is that more often than not it does nothing to reduce the number of advertisements (or anything useful for that matter). ISPs let through the more specifics in addition to the aggregate (seems to be the default config too). How is this useful? I'm having trouble figuring out real applicability for aggregation. > > What I say that those scenarios could be moved to a separate spec, and > > accepting third-party nexthops might not be necessary for those who want > > plain next-hop behaviour only. The code will probably stay as is for some > > time at least. > > First-party nexthops introduce sub-optimal routing. Why would we want > to introduce mandatory first party nexthops and optional third-party? Note, I'm discussing third-party nexthops in EBGP only (I'm not sure if I mentioned this explicitly, or if there's a need to). Why would you need the optimal routing w/ third-party next-hops and EBGP? You can just go through the BGP speaker, period. (In case if you pass through an Internet Exchange more than once.) > > The whole point of the AS is that it's not partitioned. I don't think > > this is needed, or useful at all. > > Consider this rather simplified example: > > ........ ........ > : : : : > : AS 1 :---: AS 1 : > :......: :......: > \ / > \ / > ( ) > ( Internet ) > ( ) > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS > with a single point of failure between two portions of itself. > In the case of failure of the link, it is possible to maintain > internal reachability via the Internet by allowing the Internet > Border Routers to ignore a looped condition. > > This is *not* a normal circumstance, this is highly abnormal. > However, it can be darned handy. This is a bug, not feature. Your internal connectivity just *isn't* meant to be routed through the Internet. > Other mechanisms such as tunneling between the pieces of the > partitioned AS have been done as well. Right! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Sep 25 12:44:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04761; Thu, 25 Sep 2003 12:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEn-0001Hl-00; Thu, 25 Sep 2003 12:45:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEn-0001Hi-00; Thu, 25 Sep 2003 12:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZEk-00058b-2H; Thu, 25 Sep 2003 12:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZEG-00057g-AH for idr@optimus.ietf.org; Thu, 25 Sep 2003 12:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04680 for ; Thu, 25 Sep 2003 12:44:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEE-0001Fk-00 for idr@ietf.org; Thu, 25 Sep 2003 12:44:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEE-0001EK-00 for idr@ietf.org; Thu, 25 Sep 2003 12:44:30 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8PGhvwn029193; Thu, 25 Sep 2003 09:43:58 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA16359; Thu, 25 Sep 2003 12:43:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Pekka Savola From: "John G. Scudder" Subject: Re: [Idr] comments on idr-bgp4-20 Cc: Jeffrey Haas , idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 12:43:26 -0400 At 7:26 PM +0300 9/25/03, Pekka Savola wrote: >"auto-summary" (in Cisco terms) has bitten us a couple of times. It's >automatic. But then again, I may be misremembering something (and I'm >not 100% sure auto-summary is directly related to aggregation, but the >concept is similar). > >The problem with aggregation I see is that more often than not it does >nothing to reduce the number of advertisements (or anything useful for >that matter). ISPs let through the more specifics in addition to the >aggregate (seems to be the default config too). How is this useful? I'm >having trouble figuring out real applicability for aggregation. The BGP spec doesn't talk about auto-anything. In the interests of moving the conversation forward, it would help if you cited specific language in the spec that you object to pertaining to aggregation. > > Consider this rather simplified example: > > > > ........ ........ >> : : : : >> : AS 1 :---: AS 1 : > > :......: :......: > > \ / >> \ / > > ( ) >> ( Internet ) >> ( ) > > > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS >> with a single point of failure between two portions of itself. >> In the case of failure of the link, it is possible to maintain >> internal reachability via the Internet by allowing the Internet >> Border Routers to ignore a looped condition. >> >> This is *not* a normal circumstance, this is highly abnormal. >> However, it can be darned handy. > >This is a bug, not feature. Your internal connectivity just *isn't* meant >to be routed through the Internet. You are welcome to arrange your internal connectivity however you like. Not everyone agrees. Since as specified, the behavior doesn't affect BGP's correctness it's not a bug in a formal sense. No BGP implementation I'm aware of allows AS loops by default so it's not a bug in an operational sense either. IMO there is no need to make the proposed change to the protocol. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Sep 25 12:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04862 for ; Thu, 25 Sep 2003 12:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZEq-0005B5-Qz for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 12:45:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PGj8Ti019896 for idr-archive@odin.ietf.org; Thu, 25 Sep 2003 12:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZEq-0005Ap-Nn for idr-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 12:45:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04761; Thu, 25 Sep 2003 12:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEn-0001Hl-00; Thu, 25 Sep 2003 12:45:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEn-0001Hi-00; Thu, 25 Sep 2003 12:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZEk-00058b-2H; Thu, 25 Sep 2003 12:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZEG-00057g-AH for idr@optimus.ietf.org; Thu, 25 Sep 2003 12:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04680 for ; Thu, 25 Sep 2003 12:44:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEE-0001Fk-00 for idr@ietf.org; Thu, 25 Sep 2003 12:44:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEE-0001EK-00 for idr@ietf.org; Thu, 25 Sep 2003 12:44:30 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8PGhvwn029193; Thu, 25 Sep 2003 09:43:58 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA16359; Thu, 25 Sep 2003 12:43:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Pekka Savola From: "John G. Scudder" Subject: Re: [Idr] comments on idr-bgp4-20 Cc: Jeffrey Haas , idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 12:43:26 -0400 At 7:26 PM +0300 9/25/03, Pekka Savola wrote: >"auto-summary" (in Cisco terms) has bitten us a couple of times. It's >automatic. But then again, I may be misremembering something (and I'm >not 100% sure auto-summary is directly related to aggregation, but the >concept is similar). > >The problem with aggregation I see is that more often than not it does >nothing to reduce the number of advertisements (or anything useful for >that matter). ISPs let through the more specifics in addition to the >aggregate (seems to be the default config too). How is this useful? I'm >having trouble figuring out real applicability for aggregation. The BGP spec doesn't talk about auto-anything. In the interests of moving the conversation forward, it would help if you cited specific language in the spec that you object to pertaining to aggregation. > > Consider this rather simplified example: > > > > ........ ........ >> : : : : >> : AS 1 :---: AS 1 : > > :......: :......: > > \ / >> \ / > > ( ) >> ( Internet ) >> ( ) > > > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS >> with a single point of failure between two portions of itself. >> In the case of failure of the link, it is possible to maintain >> internal reachability via the Internet by allowing the Internet >> Border Routers to ignore a looped condition. >> >> This is *not* a normal circumstance, this is highly abnormal. >> However, it can be darned handy. > >This is a bug, not feature. Your internal connectivity just *isn't* meant >to be routed through the Internet. You are welcome to arrange your internal connectivity however you like. Not everyone agrees. Since as specified, the behavior doesn't affect BGP's correctness it's not a bug in a formal sense. No BGP implementation I'm aware of allows AS loops by default so it's not a bug in an operational sense either. IMO there is no need to make the proposed change to the protocol. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Sep 26 05:45:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27941; Fri, 26 Sep 2003 05:45:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2pAf-0006M2-00; Fri, 26 Sep 2003 05:45:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2pAf-0006Lw-00; Fri, 26 Sep 2003 05:45:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2p9q-0001wY-8T; Fri, 26 Sep 2003 05:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2p9m-0001wD-TE for idr@optimus.ietf.org; Fri, 26 Sep 2003 05:44:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27909 for ; Fri, 26 Sep 2003 05:44:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2p9j-0006L3-00 for idr@ietf.org; Fri, 26 Sep 2003 05:44:55 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2p9i-0006Kl-00 for idr@ietf.org; Fri, 26 Sep 2003 05:44:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8Q9i2A24654; Fri, 26 Sep 2003 12:44:02 +0300 From: Pekka Savola To: "John G. Scudder" cc: Jeffrey Haas , Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Sep 2003 12:44:01 +0300 (EEST) On Thu, 25 Sep 2003, John G. Scudder wrote: > At 7:26 PM +0300 9/25/03, Pekka Savola wrote: > >"auto-summary" (in Cisco terms) has bitten us a couple of times. It's > >automatic. But then again, I may be misremembering something (and I'm > >not 100% sure auto-summary is directly related to aggregation, but the > >concept is similar). > > > >The problem with aggregation I see is that more often than not it does > >nothing to reduce the number of advertisements (or anything useful for > >that matter). ISPs let through the more specifics in addition to the > >aggregate (seems to be the default config too). How is this useful? I'm > >having trouble figuring out real applicability for aggregation. > > The BGP spec doesn't talk about auto-anything. In the interests of > moving the conversation forward, it would help if you cited specific > language in the spec that you object to pertaining to aggregation. Most of sections 4.3 g), 5.1.7, and 9.2.2.2. > > > Consider this rather simplified example: > > > > > > ........ ........ > >> : : : : > >> : AS 1 :---: AS 1 : > > > :......: :......: > > > \ / > >> \ / > > > ( ) > >> ( Internet ) > >> ( ) > > > > > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS > >> with a single point of failure between two portions of itself. > >> In the case of failure of the link, it is possible to maintain > >> internal reachability via the Internet by allowing the Internet > >> Border Routers to ignore a looped condition. > >> > >> This is *not* a normal circumstance, this is highly abnormal. > >> However, it can be darned handy. > > > >This is a bug, not feature. Your internal connectivity just *isn't* meant > >to be routed through the Internet. > > You are welcome to arrange your internal connectivity however you > like. Not everyone agrees. Since as specified, the behavior doesn't > affect BGP's correctness it's not a bug in a formal sense. No BGP > implementation I'm aware of allows AS loops by default so it's not a > bug in an operational sense either. > > IMO there is no need to make the proposed change to the protocol. Vendors are also free to implement additional features than those listed in the BGP spec. It is a bug in the specification sense because the spec does not include text that you should do loop prevention by discarding the path when it contains your own AS. Further, there is no need to do anything of this sort if you get default routes from the Internet, or set up a backup (highest protocol distance) route towards the Internet. But this is just one little issue, compared to some others. If no one else feels this is something that shouldn't be in the spec, feel free to ignore the argument. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Sep 26 05:46:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27967 for ; Fri, 26 Sep 2003 05:46:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2pAj-00023S-P6 for idr-archive@odin.ietf.org; Fri, 26 Sep 2003 05:45:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q9jvFX007894 for idr-archive@odin.ietf.org; Fri, 26 Sep 2003 05:45:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2pAj-00023F-Lt for idr-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 05:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27941; Fri, 26 Sep 2003 05:45:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2pAf-0006M2-00; Fri, 26 Sep 2003 05:45:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2pAf-0006Lw-00; Fri, 26 Sep 2003 05:45:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2p9q-0001wY-8T; Fri, 26 Sep 2003 05:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2p9m-0001wD-TE for idr@optimus.ietf.org; Fri, 26 Sep 2003 05:44:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27909 for ; Fri, 26 Sep 2003 05:44:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2p9j-0006L3-00 for idr@ietf.org; Fri, 26 Sep 2003 05:44:55 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2p9i-0006Kl-00 for idr@ietf.org; Fri, 26 Sep 2003 05:44:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8Q9i2A24654; Fri, 26 Sep 2003 12:44:02 +0300 From: Pekka Savola To: "John G. Scudder" cc: Jeffrey Haas , Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Sep 2003 12:44:01 +0300 (EEST) On Thu, 25 Sep 2003, John G. Scudder wrote: > At 7:26 PM +0300 9/25/03, Pekka Savola wrote: > >"auto-summary" (in Cisco terms) has bitten us a couple of times. It's > >automatic. But then again, I may be misremembering something (and I'm > >not 100% sure auto-summary is directly related to aggregation, but the > >concept is similar). > > > >The problem with aggregation I see is that more often than not it does > >nothing to reduce the number of advertisements (or anything useful for > >that matter). ISPs let through the more specifics in addition to the > >aggregate (seems to be the default config too). How is this useful? I'm > >having trouble figuring out real applicability for aggregation. > > The BGP spec doesn't talk about auto-anything. In the interests of > moving the conversation forward, it would help if you cited specific > language in the spec that you object to pertaining to aggregation. Most of sections 4.3 g), 5.1.7, and 9.2.2.2. > > > Consider this rather simplified example: > > > > > > ........ ........ > >> : : : : > >> : AS 1 :---: AS 1 : > > > :......: :......: > > > \ / > >> \ / > > > ( ) > >> ( Internet ) > >> ( ) > > > > > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS > >> with a single point of failure between two portions of itself. > >> In the case of failure of the link, it is possible to maintain > >> internal reachability via the Internet by allowing the Internet > >> Border Routers to ignore a looped condition. > >> > >> This is *not* a normal circumstance, this is highly abnormal. > >> However, it can be darned handy. > > > >This is a bug, not feature. Your internal connectivity just *isn't* meant > >to be routed through the Internet. > > You are welcome to arrange your internal connectivity however you > like. Not everyone agrees. Since as specified, the behavior doesn't > affect BGP's correctness it's not a bug in a formal sense. No BGP > implementation I'm aware of allows AS loops by default so it's not a > bug in an operational sense either. > > IMO there is no need to make the proposed change to the protocol. Vendors are also free to implement additional features than those listed in the BGP spec. It is a bug in the specification sense because the spec does not include text that you should do loop prevention by discarding the path when it contains your own AS. Further, there is no need to do anything of this sort if you get default routes from the Internet, or set up a backup (highest protocol distance) route towards the Internet. But this is just one little issue, compared to some others. If no one else feels this is something that shouldn't be in the spec, feel free to ignore the argument. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Sep 26 18:42:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27896; Fri, 26 Sep 2003 18:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A31I7-0006jB-00; Fri, 26 Sep 2003 18:42:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A31I6-0006j8-00; Fri, 26 Sep 2003 18:42:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A31Hk-0006m8-Ql; Fri, 26 Sep 2003 18:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A31Gs-0006lM-Dd for idr@optimus.ietf.org; Fri, 26 Sep 2003 18:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27862 for ; Fri, 26 Sep 2003 18:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A31Gp-0006ie-00 for idr@ietf.org; Fri, 26 Sep 2003 18:41:03 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A31Go-0006iT-00 for idr@ietf.org; Fri, 26 Sep 2003 18:41:02 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8QMeBj32605; Fri, 26 Sep 2003 15:40:12 -0700 (PDT) (envelope-from dennis@juniper.net) Message-Id: <200309262240.h8QMeBj32605@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: lists/idr To: Pekka Savola cc: "John G. Scudder" , Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-reply-to: Your message of "Fri, 26 Sep 2003 12:44:01 +0300." Mime-Version: 1.0 Content-Type: text/plain From: Dennis Ferguson Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Sep 2003 15:40:11 -0700 > > You are welcome to arrange your internal connectivity however you > > like. Not everyone agrees. Since as specified, the behavior doesn't > > affect BGP's correctness it's not a bug in a formal sense. No BGP > > implementation I'm aware of allows AS loops by default so it's not a > > bug in an operational sense either. > > > > IMO there is no need to make the proposed change to the protocol. > > Vendors are also free to implement additional features than those listed > in the BGP spec. > > It is a bug in the specification sense because the spec does not include > text that you should do loop prevention by discarding the path when it > contains your own AS. The minimal theoretical requirement for loop termination (BGP doesn't prevent loops which occur transiently, just guarantees they'll eventually be stopped) is that you should discard the path when it includes your own AS `N' times, for any `N' you care to choose. While N=1, which you like, will terminate loops, letting N=2 or N=5 or N=12 will terminate them just fine as well (though you are wasting convergence time if you make `N' larger than the number of inter-AS border routers you have, at most). It hence isn't a bug to allow `N' to be set to a value other than 1 in any theoretical sense. > Further, there is no need to do anything of this sort if you get default > routes from the Internet, or set up a backup (highest protocol distance) > route towards the Internet. I'm sure you don't mean that one or the other of those things is always possible to do. It is when neither of those things is possible that you might want to set N>1 instead. Dennis Ferguson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Sep 26 18:42:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27922 for ; Fri, 26 Sep 2003 18:42:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A31IB-0006om-3Q for idr-archive@odin.ietf.org; Fri, 26 Sep 2003 18:42:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QMgRdc026204 for idr-archive@odin.ietf.org; Fri, 26 Sep 2003 18:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A31IA-0006oZ-WE for idr-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 18:42:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27896; Fri, 26 Sep 2003 18:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A31I7-0006jB-00; Fri, 26 Sep 2003 18:42:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A31I6-0006j8-00; Fri, 26 Sep 2003 18:42:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A31Hk-0006m8-Ql; Fri, 26 Sep 2003 18:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A31Gs-0006lM-Dd for idr@optimus.ietf.org; Fri, 26 Sep 2003 18:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27862 for ; Fri, 26 Sep 2003 18:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A31Gp-0006ie-00 for idr@ietf.org; Fri, 26 Sep 2003 18:41:03 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A31Go-0006iT-00 for idr@ietf.org; Fri, 26 Sep 2003 18:41:02 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8QMeBj32605; Fri, 26 Sep 2003 15:40:12 -0700 (PDT) (envelope-from dennis@juniper.net) Message-Id: <200309262240.h8QMeBj32605@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: lists/idr To: Pekka Savola cc: "John G. Scudder" , Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-reply-to: Your message of "Fri, 26 Sep 2003 12:44:01 +0300." Mime-Version: 1.0 Content-Type: text/plain From: Dennis Ferguson Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Sep 2003 15:40:11 -0700 > > You are welcome to arrange your internal connectivity however you > > like. Not everyone agrees. Since as specified, the behavior doesn't > > affect BGP's correctness it's not a bug in a formal sense. No BGP > > implementation I'm aware of allows AS loops by default so it's not a > > bug in an operational sense either. > > > > IMO there is no need to make the proposed change to the protocol. > > Vendors are also free to implement additional features than those listed > in the BGP spec. > > It is a bug in the specification sense because the spec does not include > text that you should do loop prevention by discarding the path when it > contains your own AS. The minimal theoretical requirement for loop termination (BGP doesn't prevent loops which occur transiently, just guarantees they'll eventually be stopped) is that you should discard the path when it includes your own AS `N' times, for any `N' you care to choose. While N=1, which you like, will terminate loops, letting N=2 or N=5 or N=12 will terminate them just fine as well (though you are wasting convergence time if you make `N' larger than the number of inter-AS border routers you have, at most). It hence isn't a bug to allow `N' to be set to a value other than 1 in any theoretical sense. > Further, there is no need to do anything of this sort if you get default > routes from the Internet, or set up a backup (highest protocol distance) > route towards the Internet. I'm sure you don't mean that one or the other of those things is always possible to do. It is when neither of those things is possible that you might want to set N>1 instead. Dennis Ferguson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Sat Sep 27 12:26:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05446; Sat, 27 Sep 2003 12:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Hts-0007HX-00; Sat, 27 Sep 2003 12:26:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3Hts-0007HP-00; Sat, 27 Sep 2003 12:26:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3HtR-0002TJ-Tj; Sat, 27 Sep 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3HtI-0002SW-V7 for idr@optimus.ietf.org; Sat, 27 Sep 2003 12:25:52 -0400 Received: from pc6 (111.Red-80-35-167.pooles.rima-tde.net [80.35.167.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05402 for ; Sat, 27 Sep 2003 12:25:41 -0400 (EDT) From: santaluciaseguros@survivormail.com Message-Id: <200309271625.MAA05402@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: santaluciaseguros@survivormail.com X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] AWARD NOTIFICATION Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 27 Sep 2003 18:25:44 +0200 EL GORDO LAPRIMITIVA C/GUZMAN EL BUENO,137 MADRID - ESPAÑA TEL: +34-660 651 909 FAX:+34 645 440 201 E-mail: elgordo_laprimitiva@yahoo.es FROM: OFFICE OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/03 BATCH: 24/00319/IPD RE: AWARD NOTIFICATION FINAL NOTICE We are pleased to inform you of the release of the ELGORDO LAPRIMITIVA LOTTERY/INTERNATIONAL PROGRAMS held on the 20th of September,2003.Your email address attached to ticket number 025- 1146-4992-750 with serial number 2113-05 drew the lucky numbers 3-18-19-30-32-39, which consequently won the lottery in the 3rd category. You are therefore been approved for the lump sum pay out of €uros 847,828.87 (Eight hundred and fourty seven thousand eight hundred and eighty two .eighty seven cents.) in cash credited to file REF: LP/26510460037/03. This is from a total prize of €uros 10,500,000.00 shared among the seventeen (17) International winners in this category. CONGRATULATIONS!!!!!!!!!!!!!!!!!!!!!. Your fund is now deposited with SANTA LUCIA SEGUROS but due to mix up of some numbers and addresses, we ask that you keep this award a top secret from the public notice until your claim has been processed and your prize money remitted to your account as this is part of our Security protocol to avoid double claiming by participants of this programme. All participants were selected through a computer ballot system drawn from 30,000 addresses from Australia, USA, Europe, Asia ,New Zealand, Middle-East,South-North America and Africa as part of our international promotions program which is conducted annually. We hope with a part of your prize money, you will participate in our end of the year high stakes of €uros 300.000.000.00 Million International Lottery. To being your claim, please contact the claim agent Mr David Manuel, (Foreign Service Manager) for processing and remittance of your prize money to any designated account of your choice.Please call on this # Tel:+34686358621.Email:santaluciaseguros@survivormail.com Please note that all prize money must be claimed before the 20th of October, 2003. After this date, all funds will be returned as unclaimed. Note: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every of your correspondence with your agent. Furthermore, should there be any change of address,do inform your claims agent as soon as possible. Please remember to ask for your prize claim certificate. Congratulations again from all members of our staff. Best regards, MARIA JOSE SANCHEZ. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Sat Sep 27 12:26:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05478 for ; Sat, 27 Sep 2003 12:26:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Htu-0002Vv-KX for idr-archive@odin.ietf.org; Sat, 27 Sep 2003 12:26:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8RGQUDI009663 for idr-archive@odin.ietf.org; Sat, 27 Sep 2003 12:26:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Htu-0002Vm-F8 for idr-web-archive@optimus.ietf.org; Sat, 27 Sep 2003 12:26:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05446; Sat, 27 Sep 2003 12:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Hts-0007HX-00; Sat, 27 Sep 2003 12:26:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3Hts-0007HP-00; Sat, 27 Sep 2003 12:26:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3HtR-0002TJ-Tj; Sat, 27 Sep 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3HtI-0002SW-V7 for idr@optimus.ietf.org; Sat, 27 Sep 2003 12:25:52 -0400 Received: from pc6 (111.Red-80-35-167.pooles.rima-tde.net [80.35.167.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05402 for ; Sat, 27 Sep 2003 12:25:41 -0400 (EDT) From: santaluciaseguros@survivormail.com Message-Id: <200309271625.MAA05402@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: santaluciaseguros@survivormail.com X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] AWARD NOTIFICATION Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 27 Sep 2003 18:25:44 +0200 EL GORDO LAPRIMITIVA C/GUZMAN EL BUENO,137 MADRID - ESPAÑA TEL: +34-660 651 909 FAX:+34 645 440 201 E-mail: elgordo_laprimitiva@yahoo.es FROM: OFFICE OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/03 BATCH: 24/00319/IPD RE: AWARD NOTIFICATION FINAL NOTICE We are pleased to inform you of the release of the ELGORDO LAPRIMITIVA LOTTERY/INTERNATIONAL PROGRAMS held on the 20th of September,2003.Your email address attached to ticket number 025- 1146-4992-750 with serial number 2113-05 drew the lucky numbers 3-18-19-30-32-39, which consequently won the lottery in the 3rd category. You are therefore been approved for the lump sum pay out of €uros 847,828.87 (Eight hundred and fourty seven thousand eight hundred and eighty two .eighty seven cents.) in cash credited to file REF: LP/26510460037/03. This is from a total prize of €uros 10,500,000.00 shared among the seventeen (17) International winners in this category. CONGRATULATIONS!!!!!!!!!!!!!!!!!!!!!. Your fund is now deposited with SANTA LUCIA SEGUROS but due to mix up of some numbers and addresses, we ask that you keep this award a top secret from the public notice until your claim has been processed and your prize money remitted to your account as this is part of our Security protocol to avoid double claiming by participants of this programme. All participants were selected through a computer ballot system drawn from 30,000 addresses from Australia, USA, Europe, Asia ,New Zealand, Middle-East,South-North America and Africa as part of our international promotions program which is conducted annually. We hope with a part of your prize money, you will participate in our end of the year high stakes of €uros 300.000.000.00 Million International Lottery. To being your claim, please contact the claim agent Mr David Manuel, (Foreign Service Manager) for processing and remittance of your prize money to any designated account of your choice.Please call on this # Tel:+34686358621.Email:santaluciaseguros@survivormail.com Please note that all prize money must be claimed before the 20th of October, 2003. After this date, all funds will be returned as unclaimed. Note: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every of your correspondence with your agent. Furthermore, should there be any change of address,do inform your claims agent as soon as possible. Please remember to ask for your prize claim certificate. Congratulations again from all members of our staff. Best regards, MARIA JOSE SANCHEZ. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Sep 29 10:05:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15850; Mon, 29 Sep 2003 10:05:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yeP-0006If-00; Mon, 29 Sep 2003 10:05:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3yeP-0006Ia-00; Mon, 29 Sep 2003 10:05:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ye7-0004Cx-Cf; Mon, 29 Sep 2003 10:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ydv-0004CD-5y for idr@optimus.ietf.org; Mon, 29 Sep 2003 10:04:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15794 for ; Mon, 29 Sep 2003 10:04:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yds-0006I4-00 for idr@ietf.org; Mon, 29 Sep 2003 10:04:48 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A3yds-0006HL-00 for idr@ietf.org; Mon, 29 Sep 2003 10:04:48 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8TE43j92550; Mon, 29 Sep 2003 07:04:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309291404.h8TE43j92550@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Wed, 24 Sep 2003 10:50:26 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <178.1064844243.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 07:04:03 -0700 Pekka, > Hi, > > [note, I'm not subscribed to the idr list] > > Alex solicited ops-dir for folks to review bgp4-20 spec. After almost > half a year, I finally found the time to look at it. Comments below. I > tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at > least on the quick glance, I didn't find major overlaps. I am replying only to the comments that haven't been addressed by other folks who already replied to you. > Overview: > - the spec is in pretty good shape, but I'm not sure if all the features > listed are really full standard material.. it might be better to separate > some of them (e.g. anything relating to aggregation) to a separate doc (so > that we'd have a much tigher and better real base spec), and recycle it at > DS, but that might be much more effort.. not sure if something like that > would be worth it. > > General thoughts on going to full standard: > - If we want to go for full standard, I have to question the usefulness of > several BGP features: At the present moment we are *not* going for full standard - we are going for a draft standard. [clipped..] > As a general observation from the text: > - I skipped section 8 on FSM, as it was really boring, and I'm not sure > whehter it's of any use keeping it in the base spec. Please argue this issue with Routing ADs > - I got major headache when trying to read the aggregating rules > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > rules :-(!!!) and ended up skipping them. > > substantial > ----------- > > 1) Section 3 on Summary of the Operations, states: > > In the context of this document we assume that a BGP speaker adver- > tises to its peers only those routes that it itself uses (in this > context a BGP speaker is said to "use" a BGP route if it is the most > preferred BGP route and is used in forwarding). All other cases are > outside the scope of this document. > > this "usability" requirement is in conflict with section 4.3 on UPDATE > message format: > > An UPDATE message is used to advertise feasible routes sharing common > path attributes to a peer, [...] > > ==> in particular note that "feasible" is a superset of "only those routes > the router itself uses" (compare to "those routes the router itself _could_ > use if they were the most preferred ones"), right? > > ==> also note that the former definition is (IMHO) operationally unsound. > It prevents you from advertising P-t-P addresses and loopbacks (which also > reside in IGP) using BGP, because the IGP distance is lower than BGP and > "BGP route is never used in forwarding". (depending on how you interpret > that). IMHO, this really needs to be changed to be OK. The current text reflects consensus reached by the WG. > 2) The OPEN message format is confusing. Why on earth do you have those > empty bits there? Are they null-padding or just a typographical convention > for the clarity of the diagram (the latter)? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | My Autonomous System | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hold Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BGP Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opt Parm Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Optional Parameters (variable) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ==> I strongly recommend to either: > 1) go back to standard format, or > 2) rephrase the message format similar with UPDATE messages, i.e., drop all > the pretense about field lengths, bits 0-31, etc. This is an editorial comment, and will be handled at the discretion of the editors. > 3) there is significant confusion on what "locally originated" means. It is > not clear whether this refers to "local to the BGP speaker (i.e., the same > system)" or "local to the routing domain (i.e., the same AS)". This must be > clarified in the text below, and the text should be reviewed. What makes you think that "locally originated" means "local to the routing domain" ? [clipped...] > 6) references; note that as the Security Consideration section is a bit > short, the vulnerability analysis should be a *NORMATIVE* reference. > However, one must ask here and with RFC2385 as well whether normative > references are OK from Full Standard to a lower maturity level. Unless > this has already been investigated, it may be worth checking with the ADs > that this is OK. I would leave it up to ADs to decide on this. > > BGP vulnerabilities analysis is discussed in [XXX]. > > Normative References > > [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 > Signature Option", RFC2385, August 1998. > > Non-normative References > > [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- > ietf-idr-bgp-vuln-00.txt, work in progress > > > semi-substantial > ---------------- The rest of the comments are editorial, and will be handled at the discretion of the editors. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Sep 29 10:05:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15943 for ; Mon, 29 Sep 2003 10:05:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yeS-0004Fy-Ov for idr-archive@odin.ietf.org; Mon, 29 Sep 2003 10:05:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TE5OBg016360 for idr-archive@odin.ietf.org; Mon, 29 Sep 2003 10:05:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yeS-0004Fn-LY for idr-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 10:05:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15850; Mon, 29 Sep 2003 10:05:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yeP-0006If-00; Mon, 29 Sep 2003 10:05:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3yeP-0006Ia-00; Mon, 29 Sep 2003 10:05:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ye7-0004Cx-Cf; Mon, 29 Sep 2003 10:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ydv-0004CD-5y for idr@optimus.ietf.org; Mon, 29 Sep 2003 10:04:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15794 for ; Mon, 29 Sep 2003 10:04:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yds-0006I4-00 for idr@ietf.org; Mon, 29 Sep 2003 10:04:48 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A3yds-0006HL-00 for idr@ietf.org; Mon, 29 Sep 2003 10:04:48 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8TE43j92550; Mon, 29 Sep 2003 07:04:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309291404.h8TE43j92550@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Wed, 24 Sep 2003 10:50:26 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <178.1064844243.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 07:04:03 -0700 Pekka, > Hi, > > [note, I'm not subscribed to the idr list] > > Alex solicited ops-dir for folks to review bgp4-20 spec. After almost > half a year, I finally found the time to look at it. Comments below. I > tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at > least on the quick glance, I didn't find major overlaps. I am replying only to the comments that haven't been addressed by other folks who already replied to you. > Overview: > - the spec is in pretty good shape, but I'm not sure if all the features > listed are really full standard material.. it might be better to separate > some of them (e.g. anything relating to aggregation) to a separate doc (so > that we'd have a much tigher and better real base spec), and recycle it at > DS, but that might be much more effort.. not sure if something like that > would be worth it. > > General thoughts on going to full standard: > - If we want to go for full standard, I have to question the usefulness of > several BGP features: At the present moment we are *not* going for full standard - we are going for a draft standard. [clipped..] > As a general observation from the text: > - I skipped section 8 on FSM, as it was really boring, and I'm not sure > whehter it's of any use keeping it in the base spec. Please argue this issue with Routing ADs > - I got major headache when trying to read the aggregating rules > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > rules :-(!!!) and ended up skipping them. > > substantial > ----------- > > 1) Section 3 on Summary of the Operations, states: > > In the context of this document we assume that a BGP speaker adver- > tises to its peers only those routes that it itself uses (in this > context a BGP speaker is said to "use" a BGP route if it is the most > preferred BGP route and is used in forwarding). All other cases are > outside the scope of this document. > > this "usability" requirement is in conflict with section 4.3 on UPDATE > message format: > > An UPDATE message is used to advertise feasible routes sharing common > path attributes to a peer, [...] > > ==> in particular note that "feasible" is a superset of "only those routes > the router itself uses" (compare to "those routes the router itself _could_ > use if they were the most preferred ones"), right? > > ==> also note that the former definition is (IMHO) operationally unsound. > It prevents you from advertising P-t-P addresses and loopbacks (which also > reside in IGP) using BGP, because the IGP distance is lower than BGP and > "BGP route is never used in forwarding". (depending on how you interpret > that). IMHO, this really needs to be changed to be OK. The current text reflects consensus reached by the WG. > 2) The OPEN message format is confusing. Why on earth do you have those > empty bits there? Are they null-padding or just a typographical convention > for the clarity of the diagram (the latter)? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | My Autonomous System | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hold Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BGP Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opt Parm Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Optional Parameters (variable) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ==> I strongly recommend to either: > 1) go back to standard format, or > 2) rephrase the message format similar with UPDATE messages, i.e., drop all > the pretense about field lengths, bits 0-31, etc. This is an editorial comment, and will be handled at the discretion of the editors. > 3) there is significant confusion on what "locally originated" means. It is > not clear whether this refers to "local to the BGP speaker (i.e., the same > system)" or "local to the routing domain (i.e., the same AS)". This must be > clarified in the text below, and the text should be reviewed. What makes you think that "locally originated" means "local to the routing domain" ? [clipped...] > 6) references; note that as the Security Consideration section is a bit > short, the vulnerability analysis should be a *NORMATIVE* reference. > However, one must ask here and with RFC2385 as well whether normative > references are OK from Full Standard to a lower maturity level. Unless > this has already been investigated, it may be worth checking with the ADs > that this is OK. I would leave it up to ADs to decide on this. > > BGP vulnerabilities analysis is discussed in [XXX]. > > Normative References > > [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 > Signature Option", RFC2385, August 1998. > > Non-normative References > > [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- > ietf-idr-bgp-vuln-00.txt, work in progress > > > semi-substantial > ---------------- The rest of the comments are editorial, and will be handled at the discretion of the editors. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Sep 29 12:43:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27915; Mon, 29 Sep 2003 12:43:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A417M-0001bf-00; Mon, 29 Sep 2003 12:43:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A417M-0001bc-00; Mon, 29 Sep 2003 12:43:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A416y-0003xl-MR; Mon, 29 Sep 2003 12:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A416G-0003x2-5J for idr@optimus.ietf.org; Mon, 29 Sep 2003 12:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27867 for ; Mon, 29 Sep 2003 12:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A416E-0001aY-00 for idr@ietf.org; Mon, 29 Sep 2003 12:42:14 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A416D-0001Zq-00 for idr@ietf.org; Mon, 29 Sep 2003 12:42:14 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8TGfhj02349; Mon, 29 Sep 2003 09:41:43 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309291641.h8TGfhj02349@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46727.1064853703.1@juniper.net> From: Yakov Rekhter Subject: [Idr] WG Last Call on draft-ietf-idr-bgp4-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 09:41:43 -0700 Folks, This is to start WG Last Call on advancing draft-ietf-idr-bgp4-analysis-04.txt to an Informational RFC. The Last Call ends Oct 13, 2003. Sue & Yakov _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Sep 29 12:43:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27939 for ; Mon, 29 Sep 2003 12:43:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A417R-00046Y-ON for idr-archive@odin.ietf.org; Mon, 29 Sep 2003 12:43:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TGhTBt015772 for idr-archive@odin.ietf.org; Mon, 29 Sep 2003 12:43:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A417R-00046J-LD for idr-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 12:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27915; Mon, 29 Sep 2003 12:43:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A417M-0001bf-00; Mon, 29 Sep 2003 12:43:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A417M-0001bc-00; Mon, 29 Sep 2003 12:43:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A416y-0003xl-MR; Mon, 29 Sep 2003 12:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A416G-0003x2-5J for idr@optimus.ietf.org; Mon, 29 Sep 2003 12:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27867 for ; Mon, 29 Sep 2003 12:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A416E-0001aY-00 for idr@ietf.org; Mon, 29 Sep 2003 12:42:14 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A416D-0001Zq-00 for idr@ietf.org; Mon, 29 Sep 2003 12:42:14 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8TGfhj02349; Mon, 29 Sep 2003 09:41:43 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309291641.h8TGfhj02349@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46727.1064853703.1@juniper.net> From: Yakov Rekhter Subject: [Idr] WG Last Call on draft-ietf-idr-bgp4-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 09:41:43 -0700 Folks, This is to start WG Last Call on advancing draft-ietf-idr-bgp4-analysis-04.txt to an Informational RFC. The Last Call ends Oct 13, 2003. Sue & Yakov _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Sep 29 15:38:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06582; Mon, 29 Sep 2003 15:38:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A43qe-0003Zw-00; Mon, 29 Sep 2003 15:38:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A43qe-0003Zs-00; Mon, 29 Sep 2003 15:38:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qN-0006Wi-PP; Mon, 29 Sep 2003 15:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qK-0006Vc-B1 for idr@optimus.ietf.org; Mon, 29 Sep 2003 15:38:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06490; Mon, 29 Sep 2003 15:37:52 -0400 (EDT) Message-Id: <200309291937.PAA06490@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-03.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 15:37:52 -0400 --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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-03.txt Pages : 22 Date : 2003-9-29 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29152934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152934.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Sep 29 15:38:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06657 for ; Mon, 29 Sep 2003 15:38:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qi-0006h7-ON for idr-archive@odin.ietf.org; Mon, 29 Sep 2003 15:38:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TJcOpE025723 for idr-archive@odin.ietf.org; Mon, 29 Sep 2003 15:38:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qh-0006gj-Vj for idr-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 15:38:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06581; Mon, 29 Sep 2003 15:38:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A43qe-0003Zz-00; Mon, 29 Sep 2003 15:38:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A43qe-0003Zt-00; Mon, 29 Sep 2003 15:38:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qN-0006WS-1n; Mon, 29 Sep 2003 15:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qF-0006UU-G7 for idr@optimus.ietf.org; Mon, 29 Sep 2003 15:37:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06469; Mon, 29 Sep 2003 15:37:47 -0400 (EDT) Message-Id: <200309291937.PAA06469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-21.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 15:37:47 -0400 --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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter et al. Filename : draft-ietf-idr-bgp4-21.txt Pages : 98 Date : 2003-9-29 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-21.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29152924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152924.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Sep 29 16:26:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06658 for ; Mon, 29 Sep 2003 15:38:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qi-0006hA-Oz for idr-archive@odin.ietf.org; Mon, 29 Sep 2003 15:38:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TJcO9k025724 for idr-archive@odin.ietf.org; Mon, 29 Sep 2003 15:38:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qi-0006gk-47 for idr-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 15:38:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06582; Mon, 29 Sep 2003 15:38:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A43qe-0003Zw-00; Mon, 29 Sep 2003 15:38:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A43qe-0003Zs-00; Mon, 29 Sep 2003 15:38:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qN-0006Wi-PP; Mon, 29 Sep 2003 15:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qK-0006Vc-B1 for idr@optimus.ietf.org; Mon, 29 Sep 2003 15:38:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06490; Mon, 29 Sep 2003 15:37:52 -0400 (EDT) Message-Id: <200309291937.PAA06490@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-03.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 15:37:52 -0400 --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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-03.txt Pages : 22 Date : 2003-9-29 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29152934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152934.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Sep 29 16:26:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06581; Mon, 29 Sep 2003 15:38:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A43qe-0003Zz-00; Mon, 29 Sep 2003 15:38:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A43qe-0003Zt-00; Mon, 29 Sep 2003 15:38:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qN-0006WS-1n; Mon, 29 Sep 2003 15:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qF-0006UU-G7 for idr@optimus.ietf.org; Mon, 29 Sep 2003 15:37:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06469; Mon, 29 Sep 2003 15:37:47 -0400 (EDT) Message-Id: <200309291937.PAA06469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-21.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 15:37:47 -0400 --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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter et al. Filename : draft-ietf-idr-bgp4-21.txt Pages : 98 Date : 2003-9-29 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-21.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29152924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152924.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 02:54:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09754; Tue, 30 Sep 2003 02:54:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EOy-0002vH-00; Tue, 30 Sep 2003 02:54:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4EOx-0002vE-00; Tue, 30 Sep 2003 02:54:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EOX-0004nl-CF; Tue, 30 Sep 2003 02:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ENr-0004kk-SG for idr@optimus.ietf.org; Tue, 30 Sep 2003 02:53:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09741 for ; Tue, 30 Sep 2003 02:53:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ENn-0002uo-00 for idr@ietf.org; Tue, 30 Sep 2003 02:53:15 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ENn-0002uH-00 for idr@ietf.org; Tue, 30 Sep 2003 02:53:15 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8U6q0K01987; Tue, 30 Sep 2003 09:52:03 +0300 From: Pekka Savola To: Dennis Ferguson cc: "John G. Scudder" , Jeffrey Haas , Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309262240.h8QMeBj32605@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 09:52:00 +0300 (EEST) On Fri, 26 Sep 2003, Dennis Ferguson wrote: > > > You are welcome to arrange your internal connectivity however you > > > like. Not everyone agrees. Since as specified, the behavior doesn't > > > affect BGP's correctness it's not a bug in a formal sense. No BGP > > > implementation I'm aware of allows AS loops by default so it's not a > > > bug in an operational sense either. > > > > > > IMO there is no need to make the proposed change to the protocol. > > > > Vendors are also free to implement additional features than those listed > > in the BGP spec. > > > > It is a bug in the specification sense because the spec does not include > > text that you should do loop prevention by discarding the path when it > > contains your own AS. > > The minimal theoretical requirement for loop termination (BGP doesn't > prevent loops which occur transiently, just guarantees they'll eventually > be stopped) is that you should discard the path when it includes your > own AS `N' times, for any `N' you care to choose. While N=1, which you like, > will terminate loops, letting N=2 or N=5 or N=12 will terminate them > just fine as well (though you are wasting convergence time if you make > `N' larger than the number of inter-AS border routers you have, at most). > It hence isn't a bug to allow `N' to be set to a value other than 1 in > any theoretical sense. I wouldn't call such an AS having a coherent routing plan. If you allow AS > 1, you're abusing the term AS. > > Further, there is no need to do anything of this sort if you get default > > routes from the Internet, or set up a backup (highest protocol distance) > > route towards the Internet. > > I'm sure you don't mean that one or the other of those things is always > possible to do. It is when neither of those things is possible that you > might want to set N>1 instead. Can you shown me a couple (or at least _one_) example where other methods are not possible and this is required? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 02:54:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09777 for ; Tue, 30 Sep 2003 02:54:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EP4-0004qd-TR for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 02:54:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U6sYMr018630 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 02:54:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EP3-0004qN-6z for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 02:54:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09754; Tue, 30 Sep 2003 02:54:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EOy-0002vH-00; Tue, 30 Sep 2003 02:54:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4EOx-0002vE-00; Tue, 30 Sep 2003 02:54:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EOX-0004nl-CF; Tue, 30 Sep 2003 02:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ENr-0004kk-SG for idr@optimus.ietf.org; Tue, 30 Sep 2003 02:53:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09741 for ; Tue, 30 Sep 2003 02:53:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ENn-0002uo-00 for idr@ietf.org; Tue, 30 Sep 2003 02:53:15 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ENn-0002uH-00 for idr@ietf.org; Tue, 30 Sep 2003 02:53:15 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8U6q0K01987; Tue, 30 Sep 2003 09:52:03 +0300 From: Pekka Savola To: Dennis Ferguson cc: "John G. Scudder" , Jeffrey Haas , Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309262240.h8QMeBj32605@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 09:52:00 +0300 (EEST) On Fri, 26 Sep 2003, Dennis Ferguson wrote: > > > You are welcome to arrange your internal connectivity however you > > > like. Not everyone agrees. Since as specified, the behavior doesn't > > > affect BGP's correctness it's not a bug in a formal sense. No BGP > > > implementation I'm aware of allows AS loops by default so it's not a > > > bug in an operational sense either. > > > > > > IMO there is no need to make the proposed change to the protocol. > > > > Vendors are also free to implement additional features than those listed > > in the BGP spec. > > > > It is a bug in the specification sense because the spec does not include > > text that you should do loop prevention by discarding the path when it > > contains your own AS. > > The minimal theoretical requirement for loop termination (BGP doesn't > prevent loops which occur transiently, just guarantees they'll eventually > be stopped) is that you should discard the path when it includes your > own AS `N' times, for any `N' you care to choose. While N=1, which you like, > will terminate loops, letting N=2 or N=5 or N=12 will terminate them > just fine as well (though you are wasting convergence time if you make > `N' larger than the number of inter-AS border routers you have, at most). > It hence isn't a bug to allow `N' to be set to a value other than 1 in > any theoretical sense. I wouldn't call such an AS having a coherent routing plan. If you allow AS > 1, you're abusing the term AS. > > Further, there is no need to do anything of this sort if you get default > > routes from the Internet, or set up a backup (highest protocol distance) > > route towards the Internet. > > I'm sure you don't mean that one or the other of those things is always > possible to do. It is when neither of those things is possible that you > might want to set N>1 instead. Can you shown me a couple (or at least _one_) example where other methods are not possible and this is required? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 03:11:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10400; Tue, 30 Sep 2003 03:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Efy-00039a-00; Tue, 30 Sep 2003 03:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Efy-00039X-00; Tue, 30 Sep 2003 03:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Efv-0005ur-Ha; Tue, 30 Sep 2003 03:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EfN-0005uF-Hy for idr@optimus.ietf.org; Tue, 30 Sep 2003 03:11:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10391 for ; Tue, 30 Sep 2003 03:11:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EfJ-00039B-00 for idr@ietf.org; Tue, 30 Sep 2003 03:11:21 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EfI-000396-00 for idr@ietf.org; Tue, 30 Sep 2003 03:11:20 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8U7AnV02216; Tue, 30 Sep 2003 10:10:49 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309291404.h8TE43j92550@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 10:10:49 +0300 (EEST) Responding to two issues which seem may warrant further discussion from me.. On Mon, 29 Sep 2003, Yakov Rekhter wrote: > > - I got major headache when trying to read the aggregating rules > > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > > rules :-(!!!) and ended up skipping them. > > > > substantial > > ----------- > > > > 1) Section 3 on Summary of the Operations, states: > > > > In the context of this document we assume that a BGP speaker adver- > > tises to its peers only those routes that it itself uses (in this > > context a BGP speaker is said to "use" a BGP route if it is the most > > preferred BGP route and is used in forwarding). All other cases are > > outside the scope of this document. > > > > this "usability" requirement is in conflict with section 4.3 on UPDATE > > message format: > > > > An UPDATE message is used to advertise feasible routes sharing common > > path attributes to a peer, [...] > > > > ==> in particular note that "feasible" is a superset of "only those routes > > the router itself uses" (compare to "those routes the router itself _could_ > > use if they were the most preferred ones"), right? > > > > ==> also note that the former definition is (IMHO) operationally unsound. > > It prevents you from advertising P-t-P addresses and loopbacks (which also > > reside in IGP) using BGP, because the IGP distance is lower than BGP and > > "BGP route is never used in forwarding". (depending on how you interpret > > that). IMHO, this really needs to be changed to be OK. > > The current text reflects consensus reached by the WG. Note that there are two issues here: 1) the text is out-of-sync between sections 3 and 4.3, and 2) that the current definition of BGP route used for forwarding is not really useful. I take it that the comment 1) is still valid. Has 2) -- which you were probably referring to -- been raised as an issue in the spec? Any pointers to the issue, discussion, and the conclusion (the answer to the question "Why did the WG decide this way?") I fail to see why such a conclusion would be justified.. and if the relevant points haven't been raised already, I probably want to re-open that debate. > > 3) there is significant confusion on what "locally originated" means. It is > > not clear whether this refers to "local to the BGP speaker (i.e., the same > > system)" or "local to the routing domain (i.e., the same AS)". This must be > > clarified in the text below, and the text should be reviewed. > > What makes you think that "locally originated" means "local to the routing > domain" ? The text: 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. .. because, obviously, you do not _modify_ NEXT_HOP for any routes which you originate. You _set_ it to be something. Further, you use double negative in above, so it's pretty difficult to figure out what's the actual intent there...: - if the route is locally originated the BGP speaker ... a) ? b) SHOULD modify NEXT_HOP (or something else) ? - if the route is not locally originated, the BGP speaker SHOULD NOT modify NEXT_HOP So, I'd suggest rewording the start of that paragraph; perhaps e.g.: 1) When sending a message to an internal peer, and the route is not originated by the BGP speaker, the BGP speaker SHOULD keep the NEXT_HOP attribute intact, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 03:12:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10439 for ; Tue, 30 Sep 2003 03:12:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Eg2-0005xG-IR for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 03:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U7C6vg022889 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 03:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Eg2-0005x6-1t for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 03:12:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10400; Tue, 30 Sep 2003 03:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Efy-00039a-00; Tue, 30 Sep 2003 03:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Efy-00039X-00; Tue, 30 Sep 2003 03:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Efv-0005ur-Ha; Tue, 30 Sep 2003 03:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EfN-0005uF-Hy for idr@optimus.ietf.org; Tue, 30 Sep 2003 03:11:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10391 for ; Tue, 30 Sep 2003 03:11:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EfJ-00039B-00 for idr@ietf.org; Tue, 30 Sep 2003 03:11:21 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EfI-000396-00 for idr@ietf.org; Tue, 30 Sep 2003 03:11:20 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8U7AnV02216; Tue, 30 Sep 2003 10:10:49 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309291404.h8TE43j92550@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 10:10:49 +0300 (EEST) Responding to two issues which seem may warrant further discussion from me.. On Mon, 29 Sep 2003, Yakov Rekhter wrote: > > - I got major headache when trying to read the aggregating rules > > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > > rules :-(!!!) and ended up skipping them. > > > > substantial > > ----------- > > > > 1) Section 3 on Summary of the Operations, states: > > > > In the context of this document we assume that a BGP speaker adver- > > tises to its peers only those routes that it itself uses (in this > > context a BGP speaker is said to "use" a BGP route if it is the most > > preferred BGP route and is used in forwarding). All other cases are > > outside the scope of this document. > > > > this "usability" requirement is in conflict with section 4.3 on UPDATE > > message format: > > > > An UPDATE message is used to advertise feasible routes sharing common > > path attributes to a peer, [...] > > > > ==> in particular note that "feasible" is a superset of "only those routes > > the router itself uses" (compare to "those routes the router itself _could_ > > use if they were the most preferred ones"), right? > > > > ==> also note that the former definition is (IMHO) operationally unsound. > > It prevents you from advertising P-t-P addresses and loopbacks (which also > > reside in IGP) using BGP, because the IGP distance is lower than BGP and > > "BGP route is never used in forwarding". (depending on how you interpret > > that). IMHO, this really needs to be changed to be OK. > > The current text reflects consensus reached by the WG. Note that there are two issues here: 1) the text is out-of-sync between sections 3 and 4.3, and 2) that the current definition of BGP route used for forwarding is not really useful. I take it that the comment 1) is still valid. Has 2) -- which you were probably referring to -- been raised as an issue in the spec? Any pointers to the issue, discussion, and the conclusion (the answer to the question "Why did the WG decide this way?") I fail to see why such a conclusion would be justified.. and if the relevant points haven't been raised already, I probably want to re-open that debate. > > 3) there is significant confusion on what "locally originated" means. It is > > not clear whether this refers to "local to the BGP speaker (i.e., the same > > system)" or "local to the routing domain (i.e., the same AS)". This must be > > clarified in the text below, and the text should be reviewed. > > What makes you think that "locally originated" means "local to the routing > domain" ? The text: 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. .. because, obviously, you do not _modify_ NEXT_HOP for any routes which you originate. You _set_ it to be something. Further, you use double negative in above, so it's pretty difficult to figure out what's the actual intent there...: - if the route is locally originated the BGP speaker ... a) ? b) SHOULD modify NEXT_HOP (or something else) ? - if the route is not locally originated, the BGP speaker SHOULD NOT modify NEXT_HOP So, I'd suggest rewording the start of that paragraph; perhaps e.g.: 1) When sending a message to an internal peer, and the route is not originated by the BGP speaker, the BGP speaker SHOULD keep the NEXT_HOP attribute intact, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 08:57:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19632; Tue, 30 Sep 2003 08:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4K40-0006Ib-00; Tue, 30 Sep 2003 08:57:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4K3z-0006IY-00; Tue, 30 Sep 2003 08:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4K3p-00046B-3P; Tue, 30 Sep 2003 08:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4K3Q-00045n-VP for idr@optimus.ietf.org; Tue, 30 Sep 2003 08:56:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19614 for ; Tue, 30 Sep 2003 08:56:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4K3P-0006I2-00 for idr@ietf.org; Tue, 30 Sep 2003 08:56:35 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4K3O-0006Gr-00 for idr@ietf.org; Tue, 30 Sep 2003 08:56:35 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UCtuj84169; Tue, 30 Sep 2003 05:55:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301255.h8UCtuj84169@merlot.juniper.net> To: Pekka Savola cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Tue, 30 Sep 2003 10:10:49 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19483.1064926556.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 05:55:56 -0700 Pekka, > Responding to two issues which seem may warrant further discussion from > me.. > [clipped...] > > > 3) there is significant confusion on what "locally originated" means. It is > > > not clear whether this refers to "local to the BGP speaker (i.e., the sam e > > > system)" or "local to the routing domain (i.e., the same AS)". This must be > > > clarified in the text below, and the text should be reviewed. > > > > What makes you think that "locally originated" means "local to the routing > > domain" ? > > The text: > > 1) When sending a message to an internal peer, if the route is not > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > attribute, unless it has been explicitly configured to announce > its own IP address as the NEXT_HOP. > > .. because, obviously, you do not _modify_ NEXT_HOP for any routes which > you originate. You _set_ it to be something. Further, you use double > negative in above, so it's pretty difficult to figure out what's the > actual intent there...: > > - if the route is locally originated the BGP speaker ... > a) ? > b) SHOULD modify NEXT_HOP (or something else) ? > - if the route is not locally originated, the BGP speaker SHOULD NOT > modify NEXT_HOP > > So, I'd suggest rewording the start of that paragraph; perhaps e.g.: > > 1) When sending a message to an internal peer, and the route is > not originated by the BGP speaker, the BGP speaker SHOULD keep the > NEXT_HOP attribute intact, unless it has been explicitly configured > to announce its own IP address as the NEXT_HOP. The current text reflects the consensus of the WG (see 2.61 in draft-ietf-idr-bgp-issues-01.txt). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 08:57:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19656 for ; Tue, 30 Sep 2003 08:57:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4K43-00048h-5f for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 08:57:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UCvFAe015905 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 08:57:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4K43-00048S-1z for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 08:57:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19632; Tue, 30 Sep 2003 08:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4K40-0006Ib-00; Tue, 30 Sep 2003 08:57:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4K3z-0006IY-00; Tue, 30 Sep 2003 08:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4K3p-00046B-3P; Tue, 30 Sep 2003 08:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4K3Q-00045n-VP for idr@optimus.ietf.org; Tue, 30 Sep 2003 08:56:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19614 for ; Tue, 30 Sep 2003 08:56:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4K3P-0006I2-00 for idr@ietf.org; Tue, 30 Sep 2003 08:56:35 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4K3O-0006Gr-00 for idr@ietf.org; Tue, 30 Sep 2003 08:56:35 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UCtuj84169; Tue, 30 Sep 2003 05:55:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301255.h8UCtuj84169@merlot.juniper.net> To: Pekka Savola cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Tue, 30 Sep 2003 10:10:49 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19483.1064926556.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 05:55:56 -0700 Pekka, > Responding to two issues which seem may warrant further discussion from > me.. > [clipped...] > > > 3) there is significant confusion on what "locally originated" means. It is > > > not clear whether this refers to "local to the BGP speaker (i.e., the sam e > > > system)" or "local to the routing domain (i.e., the same AS)". This must be > > > clarified in the text below, and the text should be reviewed. > > > > What makes you think that "locally originated" means "local to the routing > > domain" ? > > The text: > > 1) When sending a message to an internal peer, if the route is not > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > attribute, unless it has been explicitly configured to announce > its own IP address as the NEXT_HOP. > > .. because, obviously, you do not _modify_ NEXT_HOP for any routes which > you originate. You _set_ it to be something. Further, you use double > negative in above, so it's pretty difficult to figure out what's the > actual intent there...: > > - if the route is locally originated the BGP speaker ... > a) ? > b) SHOULD modify NEXT_HOP (or something else) ? > - if the route is not locally originated, the BGP speaker SHOULD NOT > modify NEXT_HOP > > So, I'd suggest rewording the start of that paragraph; perhaps e.g.: > > 1) When sending a message to an internal peer, and the route is > not originated by the BGP speaker, the BGP speaker SHOULD keep the > NEXT_HOP attribute intact, unless it has been explicitly configured > to announce its own IP address as the NEXT_HOP. The current text reflects the consensus of the WG (see 2.61 in draft-ietf-idr-bgp-issues-01.txt). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 09:59:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21531; Tue, 30 Sep 2003 09:59:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L1y-0006wq-00; Tue, 30 Sep 2003 09:59:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4L1y-0006wn-00; Tue, 30 Sep 2003 09:59:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L1p-0007R8-P8; Tue, 30 Sep 2003 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L1k-0007Qu-56 for idr@optimus.ietf.org; Tue, 30 Sep 2003 09:58:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21526 for ; Tue, 30 Sep 2003 09:58:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L1i-0006wj-00 for idr@ietf.org; Tue, 30 Sep 2003 09:58:54 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L1h-0006wa-00 for idr@ietf.org; Tue, 30 Sep 2003 09:58:53 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8UDwKZ08120; Tue, 30 Sep 2003 16:58:20 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309301255.h8UCtuj84169@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 16:58:20 +0300 (EEST) On Tue, 30 Sep 2003, Yakov Rekhter wrote: > > > > 3) there is significant confusion on what "locally originated" means. It > is > > > > not clear whether this refers to "local to the BGP speaker (i.e., the sam > e > > > > system)" or "local to the routing domain (i.e., the same AS)". This must > be > > > > clarified in the text below, and the text should be reviewed. > > > > > > What makes you think that "locally originated" means "local to the routing > > > domain" ? > > > > The text: > > > > 1) When sending a message to an internal peer, if the route is not > > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > > attribute, unless it has been explicitly configured to announce > > its own IP address as the NEXT_HOP. > > > > .. because, obviously, you do not _modify_ NEXT_HOP for any routes which > > you originate. You _set_ it to be something. Further, you use double > > negative in above, so it's pretty difficult to figure out what's the > > actual intent there...: > > > > - if the route is locally originated the BGP speaker ... > > a) ? > > b) SHOULD modify NEXT_HOP (or something else) ? > > - if the route is not locally originated, the BGP speaker SHOULD NOT > > modify NEXT_HOP > > > > So, I'd suggest rewording the start of that paragraph; perhaps e.g.: > > > > 1) When sending a message to an internal peer, and the route is > > not originated by the BGP speaker, the BGP speaker SHOULD keep the > > NEXT_HOP attribute intact, unless it has been explicitly configured > > to announce its own IP address as the NEXT_HOP. > > The current text reflects the consensus of the WG (see 2.61 in > draft-ietf-idr-bgp-issues-01.txt). Looking at 2.61, it seems that issue made solely for the _next_ sentences, i.e., for the case of locally originated routes. In both the old and the new text, the text I'd like to change seemed to be unchanged. So, I'm not sure if I see that this proposal is an old, already concensus-achieved issue ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 09:59:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21557 for ; Tue, 30 Sep 2003 09:59:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L21-0007TW-Rv for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 09:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UDxDbi028728 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 09:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L21-0007TH-O3 for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 09:59:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21531; Tue, 30 Sep 2003 09:59:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L1y-0006wq-00; Tue, 30 Sep 2003 09:59:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4L1y-0006wn-00; Tue, 30 Sep 2003 09:59:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L1p-0007R8-P8; Tue, 30 Sep 2003 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L1k-0007Qu-56 for idr@optimus.ietf.org; Tue, 30 Sep 2003 09:58:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21526 for ; Tue, 30 Sep 2003 09:58:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L1i-0006wj-00 for idr@ietf.org; Tue, 30 Sep 2003 09:58:54 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L1h-0006wa-00 for idr@ietf.org; Tue, 30 Sep 2003 09:58:53 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8UDwKZ08120; Tue, 30 Sep 2003 16:58:20 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309301255.h8UCtuj84169@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 16:58:20 +0300 (EEST) On Tue, 30 Sep 2003, Yakov Rekhter wrote: > > > > 3) there is significant confusion on what "locally originated" means. It > is > > > > not clear whether this refers to "local to the BGP speaker (i.e., the sam > e > > > > system)" or "local to the routing domain (i.e., the same AS)". This must > be > > > > clarified in the text below, and the text should be reviewed. > > > > > > What makes you think that "locally originated" means "local to the routing > > > domain" ? > > > > The text: > > > > 1) When sending a message to an internal peer, if the route is not > > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > > attribute, unless it has been explicitly configured to announce > > its own IP address as the NEXT_HOP. > > > > .. because, obviously, you do not _modify_ NEXT_HOP for any routes which > > you originate. You _set_ it to be something. Further, you use double > > negative in above, so it's pretty difficult to figure out what's the > > actual intent there...: > > > > - if the route is locally originated the BGP speaker ... > > a) ? > > b) SHOULD modify NEXT_HOP (or something else) ? > > - if the route is not locally originated, the BGP speaker SHOULD NOT > > modify NEXT_HOP > > > > So, I'd suggest rewording the start of that paragraph; perhaps e.g.: > > > > 1) When sending a message to an internal peer, and the route is > > not originated by the BGP speaker, the BGP speaker SHOULD keep the > > NEXT_HOP attribute intact, unless it has been explicitly configured > > to announce its own IP address as the NEXT_HOP. > > The current text reflects the consensus of the WG (see 2.61 in > draft-ietf-idr-bgp-issues-01.txt). Looking at 2.61, it seems that issue made solely for the _next_ sentences, i.e., for the case of locally originated routes. In both the old and the new text, the text I'd like to change seemed to be unchanged. So, I'm not sure if I see that this proposal is an old, already concensus-achieved issue ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 11:19:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26199; Tue, 30 Sep 2003 11:19:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MHf-00005S-00; Tue, 30 Sep 2003 11:19:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4MHe-00005N-00; Tue, 30 Sep 2003 11:19:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MHG-0004HG-CE; Tue, 30 Sep 2003 11:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MH1-0004GU-MN for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:18:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26092; Tue, 30 Sep 2003 11:18:39 -0400 (EDT) Message-Id: <200309301518.LAA26092@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-08.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:18:38 -0400 --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 : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, Y. Rekhter et al. Filename : draft-ietf-idr-restart-08.txt Pages : 10 Date : 2003-9-30 This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-30112431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-30112431.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 11:19:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26265 for ; Tue, 30 Sep 2003 11:19:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MHg-0004Mx-T0 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 11:19:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UFJSrI016789 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 11:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MHg-0004Mi-PG for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 11:19:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26199; Tue, 30 Sep 2003 11:19:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MHf-00005S-00; Tue, 30 Sep 2003 11:19:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4MHe-00005N-00; Tue, 30 Sep 2003 11:19:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MHG-0004HG-CE; Tue, 30 Sep 2003 11:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MH1-0004GU-MN for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:18:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26092; Tue, 30 Sep 2003 11:18:39 -0400 (EDT) Message-Id: <200309301518.LAA26092@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-08.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:18:38 -0400 --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 : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, Y. Rekhter et al. Filename : draft-ietf-idr-restart-08.txt Pages : 10 Date : 2003-9-30 This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-30112431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-30112431.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 11:20:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26386; Tue, 30 Sep 2003 11:20:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MJD-00008v-00; Tue, 30 Sep 2003 11:21:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4MJC-00008s-00; Tue, 30 Sep 2003 11:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MJB-0004Sd-IU; Tue, 30 Sep 2003 11:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MID-0004Nj-1y for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26289 for ; Tue, 30 Sep 2003 11:19:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MIC-00006c-00 for idr@ietf.org; Tue, 30 Sep 2003 11:20:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4MIB-00005X-00 for idr@ietf.org; Tue, 30 Sep 2003 11:19:59 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Sep 2003 08:18:59 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8UFJQXg016097 for ; Tue, 30 Sep 2003 08:19:27 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-215-142.cisco.com [64.101.215.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA25941 for ; Tue, 30 Sep 2003 11:19:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Idr] Proposed change to 9.1.2.2 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:19:23 -0400 Folks, There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec: c) Remove from consideration routes with less-preferred MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable between routes learned from the same neighboring AS (the neighbor- ing AS is determined from the AS_PATH attribute). Routes which do not have the MULTI_EXIT_DISC attribute are considered to have the lowest possible MULTI_EXIT_DISC value. This is also described in the following procedure: for m = all routes still under consideration for n = all routes still under consideration if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) remove route m from consideration In the pseudo-code above, MED(n) is a function which returns the value of route n's MULTI_EXIT_DISC attribute. If route n has no MULTI_EXIT_DISC attribute, the function returns the lowest possi- ble MULTI_EXIT_DISC value, i.e. 0. Similarly, neighborAS(n) is a function which returns the neighbor AS from which the route was received. If the route is learned via IBGP, and the other IBGP speaker didn't originate the route, it is the neighbor AS from which the other IBGP speaker learned the route. If the route is learned via IBGP, and the other IBGP speaker originated the route, it is the local AS. This text assumes that it is always possible to unambiguously determine a unique neighbor AS for any route. However, in principle this is not the case, as when a border router performs aggregation towards IBGP, leading to a route whose AS path begins with an AS_SET. To correct this I propose that the following paragraph be added immediately following the text quoted above. In some cases it may not be possible to determine an unambiguous, unique neighbor AS, such as when the AS_PATH attribute begins with an AS_SET due to aggregation. If the neighbor AS of a route cannot be determined, the MULTI_EXIT_DISC MUST NOT be compared with the MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- code above, this can be accomplished by considering neighborAS(n) to return a special distinguished "not found" value (which is not equal to any AS value) and MED(n) to return 0 for such routes. I suppose it might also be worth saying (somewhere else, e.g. under the discussion of aggregation) that if you create an aggregated route which has an AS_SET as the first element in its AS_PATH, then you SHOULD strip the MED out. This is just belt and suspenders though, and I don't much care if we do it or not. In reality I doubt this case is ever seen in the wild, but it's good to have the spec right anyway. Regards, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 11:21:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26415 for ; Tue, 30 Sep 2003 11:21:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MJE-0004VJ-MS for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 11:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UFL450017307 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 11:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MJE-0004V4-HQ for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 11:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26386; Tue, 30 Sep 2003 11:20:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MJD-00008v-00; Tue, 30 Sep 2003 11:21:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4MJC-00008s-00; Tue, 30 Sep 2003 11:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MJB-0004Sd-IU; Tue, 30 Sep 2003 11:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MID-0004Nj-1y for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26289 for ; Tue, 30 Sep 2003 11:19:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MIC-00006c-00 for idr@ietf.org; Tue, 30 Sep 2003 11:20:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4MIB-00005X-00 for idr@ietf.org; Tue, 30 Sep 2003 11:19:59 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Sep 2003 08:18:59 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8UFJQXg016097 for ; Tue, 30 Sep 2003 08:19:27 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-215-142.cisco.com [64.101.215.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA25941 for ; Tue, 30 Sep 2003 11:19:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Idr] Proposed change to 9.1.2.2 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:19:23 -0400 Folks, There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec: c) Remove from consideration routes with less-preferred MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable between routes learned from the same neighboring AS (the neighbor- ing AS is determined from the AS_PATH attribute). Routes which do not have the MULTI_EXIT_DISC attribute are considered to have the lowest possible MULTI_EXIT_DISC value. This is also described in the following procedure: for m = all routes still under consideration for n = all routes still under consideration if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) remove route m from consideration In the pseudo-code above, MED(n) is a function which returns the value of route n's MULTI_EXIT_DISC attribute. If route n has no MULTI_EXIT_DISC attribute, the function returns the lowest possi- ble MULTI_EXIT_DISC value, i.e. 0. Similarly, neighborAS(n) is a function which returns the neighbor AS from which the route was received. If the route is learned via IBGP, and the other IBGP speaker didn't originate the route, it is the neighbor AS from which the other IBGP speaker learned the route. If the route is learned via IBGP, and the other IBGP speaker originated the route, it is the local AS. This text assumes that it is always possible to unambiguously determine a unique neighbor AS for any route. However, in principle this is not the case, as when a border router performs aggregation towards IBGP, leading to a route whose AS path begins with an AS_SET. To correct this I propose that the following paragraph be added immediately following the text quoted above. In some cases it may not be possible to determine an unambiguous, unique neighbor AS, such as when the AS_PATH attribute begins with an AS_SET due to aggregation. If the neighbor AS of a route cannot be determined, the MULTI_EXIT_DISC MUST NOT be compared with the MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- code above, this can be accomplished by considering neighborAS(n) to return a special distinguished "not found" value (which is not equal to any AS value) and MED(n) to return 0 for such routes. I suppose it might also be worth saying (somewhere else, e.g. under the discussion of aggregation) that if you create an aggregated route which has an AS_SET as the first element in its AS_PATH, then you SHOULD strip the MED out. This is just belt and suspenders though, and I don't much care if we do it or not. In reality I doubt this case is ever seen in the wild, but it's good to have the spec right anyway. Regards, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 11:33:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26837; Tue, 30 Sep 2003 11:33:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MVo-0000HZ-00; Tue, 30 Sep 2003 11:34:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4MVo-0000HW-00; Tue, 30 Sep 2003 11:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MVl-000573-96; Tue, 30 Sep 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MVM-00055M-Bd for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:33:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26813 for ; Tue, 30 Sep 2003 11:33:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MVL-0000Gz-00 for idr@ietf.org; Tue, 30 Sep 2003 11:33:35 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A4MVK-0000Gg-00 for idr@ietf.org; Tue, 30 Sep 2003 11:33:34 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8UFWs5W084360; Tue, 30 Sep 2003 11:32:54 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8UFWqOT084352; Tue, 30 Sep 2003 11:32:52 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8UFWls24405; Tue, 30 Sep 2003 11:32:47 -0400 (EDT) From: Jeffrey Haas To: "John G. Scudder" Cc: idr@ietf.org Subject: Re: [Idr] Proposed change to 9.1.2.2 Message-ID: <20030930113246.I4801@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jgs@cisco.com on Tue, Sep 30, 2003 at 11:19:23AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:32:47 -0400 On Tue, Sep 30, 2003 at 11:19:23AM -0400, John G. Scudder wrote: > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. Well, this is only important if you're allowing routes to be aggregated regardless of MED value. :-) Good catch though. This makes me wonder if our elders had already though of this particular case and that was what the odd restriction of not aggregating things with different MEDs was really for. If you don't aggregate things with different MEDs, you can simply check the leading set for the presence of the AS. > --John -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 11:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26857 for ; Tue, 30 Sep 2003 11:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MVq-00059T-FG for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 11:34:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UFY6Ii019797 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 11:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MVq-00059E-A8 for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 11:34:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26837; Tue, 30 Sep 2003 11:33:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MVo-0000HZ-00; Tue, 30 Sep 2003 11:34:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4MVo-0000HW-00; Tue, 30 Sep 2003 11:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MVl-000573-96; Tue, 30 Sep 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MVM-00055M-Bd for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:33:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26813 for ; Tue, 30 Sep 2003 11:33:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MVL-0000Gz-00 for idr@ietf.org; Tue, 30 Sep 2003 11:33:35 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A4MVK-0000Gg-00 for idr@ietf.org; Tue, 30 Sep 2003 11:33:34 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8UFWs5W084360; Tue, 30 Sep 2003 11:32:54 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8UFWqOT084352; Tue, 30 Sep 2003 11:32:52 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8UFWls24405; Tue, 30 Sep 2003 11:32:47 -0400 (EDT) From: Jeffrey Haas To: "John G. Scudder" Cc: idr@ietf.org Subject: Re: [Idr] Proposed change to 9.1.2.2 Message-ID: <20030930113246.I4801@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jgs@cisco.com on Tue, Sep 30, 2003 at 11:19:23AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:32:47 -0400 On Tue, Sep 30, 2003 at 11:19:23AM -0400, John G. Scudder wrote: > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. Well, this is only important if you're allowing routes to be aggregated regardless of MED value. :-) Good catch though. This makes me wonder if our elders had already though of this particular case and that was what the odd restriction of not aggregating things with different MEDs was really for. If you don't aggregate things with different MEDs, you can simply check the leading set for the presence of the AS. > --John -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 12:03:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28820; Tue, 30 Sep 2003 12:03:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MyW-0000o8-00; Tue, 30 Sep 2003 12:03:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4MyW-0000o4-00; Tue, 30 Sep 2003 12:03:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Mxq-0007b1-Fo; Tue, 30 Sep 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Mxg-0007aQ-M9 for idr@optimus.ietf.org; Tue, 30 Sep 2003 12:02:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28740 for ; Tue, 30 Sep 2003 12:02:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Mxf-0000mx-00 for idr@ietf.org; Tue, 30 Sep 2003 12:02:51 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1A4MxZ-0000mi-00 for idr@ietf.org; Tue, 30 Sep 2003 12:02:48 -0400 Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 5911C60D0C8; Tue, 30 Sep 2003 09:01:56 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 8682A15D3C1; Tue, 30 Sep 2003 09:01:55 -0700 (PDT) To: "John G. Scudder" Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] Proposed change to 9.1.2.2 In-Reply-To: Message from "John G. Scudder" of "Tue, 30 Sep 2003 11:19:23 EDT." From: Enke Chen Message-Id: <20030930160155.8682A15D3C1@popserv1.redback.com> Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 09:01:55 -0700 John, > Message-Id: > To: idr@ietf.org > From: "John G. Scudder" > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > Subject: [Idr] Proposed change to 9.1.2.2 > Sender: idr-admin@ietf.org > > Folks, > > There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec: > > c) Remove from consideration routes with less-preferred > MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable > between routes learned from the same neighboring AS (the neighbor- > ing AS is determined from the AS_PATH attribute). Routes which do > not have the MULTI_EXIT_DISC attribute are considered to have the > lowest possible MULTI_EXIT_DISC value. > > This is also described in the following procedure: > > for m = all routes still under consideration > for n = all routes still under consideration > if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) > remove route m from consideration > > In the pseudo-code above, MED(n) is a function which returns the > value of route n's MULTI_EXIT_DISC attribute. If route n has no > MULTI_EXIT_DISC attribute, the function returns the lowest possi- > ble MULTI_EXIT_DISC value, i.e. 0. > > Similarly, neighborAS(n) is a function which returns the neighbor > AS from which the route was received. If the route is learned via > IBGP, and the other IBGP speaker didn't originate the route, it is > the neighbor AS from which the other IBGP speaker learned the > route. If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > > This text assumes that it is always possible to unambiguously > determine a unique neighbor AS for any route. However, in principle > this is not the case, as when a border router performs aggregation > towards IBGP, leading to a route whose AS path begins with an AS_SET. I believe that an aggregated route is treated the same as an originated route in this regard by several implementations I am familiar with. Such treatment does make sense - a route is originated when you aggregate. If further clarification is desired in the spec, we could revise it like the following: If the route is learned via IBGP, and the other IBGP speaker originated the route or created the aggregate, ++++++++++++++++++++++++ it is the local AS. Regards, -- Enke > > > To correct this I propose that the following paragraph be added > immediately following the text quoted above. > > In some cases it may not be possible to determine an unambiguous, > unique neighbor AS, such as when the AS_PATH attribute begins with > an AS_SET due to aggregation. If the neighbor AS of a route cannot > be determined, the MULTI_EXIT_DISC MUST NOT be compared with the > MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- > code above, this can be accomplished by considering neighborAS(n) > to return a special distinguished "not found" value (which is not > equal to any AS value) and MED(n) to return 0 for such routes. > > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. This is just belt and suspenders though, > and I don't much care if we do it or not. > > In reality I doubt this case is ever seen in the wild, but it's good > to have the spec right anyway. > > Regards, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 12:04:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28896 for ; Tue, 30 Sep 2003 12:04:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MyY-0007iy-Gi for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 12:03:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UG3ktA029691 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 12:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MyY-0007io-DJ for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 12:03:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28820; Tue, 30 Sep 2003 12:03:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MyW-0000o8-00; Tue, 30 Sep 2003 12:03:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4MyW-0000o4-00; Tue, 30 Sep 2003 12:03:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Mxq-0007b1-Fo; Tue, 30 Sep 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Mxg-0007aQ-M9 for idr@optimus.ietf.org; Tue, 30 Sep 2003 12:02:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28740 for ; Tue, 30 Sep 2003 12:02:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Mxf-0000mx-00 for idr@ietf.org; Tue, 30 Sep 2003 12:02:51 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1A4MxZ-0000mi-00 for idr@ietf.org; Tue, 30 Sep 2003 12:02:48 -0400 Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 5911C60D0C8; Tue, 30 Sep 2003 09:01:56 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 8682A15D3C1; Tue, 30 Sep 2003 09:01:55 -0700 (PDT) To: "John G. Scudder" Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] Proposed change to 9.1.2.2 In-Reply-To: Message from "John G. Scudder" of "Tue, 30 Sep 2003 11:19:23 EDT." From: Enke Chen Message-Id: <20030930160155.8682A15D3C1@popserv1.redback.com> Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 09:01:55 -0700 John, > Message-Id: > To: idr@ietf.org > From: "John G. Scudder" > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > Subject: [Idr] Proposed change to 9.1.2.2 > Sender: idr-admin@ietf.org > > Folks, > > There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec: > > c) Remove from consideration routes with less-preferred > MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable > between routes learned from the same neighboring AS (the neighbor- > ing AS is determined from the AS_PATH attribute). Routes which do > not have the MULTI_EXIT_DISC attribute are considered to have the > lowest possible MULTI_EXIT_DISC value. > > This is also described in the following procedure: > > for m = all routes still under consideration > for n = all routes still under consideration > if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) > remove route m from consideration > > In the pseudo-code above, MED(n) is a function which returns the > value of route n's MULTI_EXIT_DISC attribute. If route n has no > MULTI_EXIT_DISC attribute, the function returns the lowest possi- > ble MULTI_EXIT_DISC value, i.e. 0. > > Similarly, neighborAS(n) is a function which returns the neighbor > AS from which the route was received. If the route is learned via > IBGP, and the other IBGP speaker didn't originate the route, it is > the neighbor AS from which the other IBGP speaker learned the > route. If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > > This text assumes that it is always possible to unambiguously > determine a unique neighbor AS for any route. However, in principle > this is not the case, as when a border router performs aggregation > towards IBGP, leading to a route whose AS path begins with an AS_SET. I believe that an aggregated route is treated the same as an originated route in this regard by several implementations I am familiar with. Such treatment does make sense - a route is originated when you aggregate. If further clarification is desired in the spec, we could revise it like the following: If the route is learned via IBGP, and the other IBGP speaker originated the route or created the aggregate, ++++++++++++++++++++++++ it is the local AS. Regards, -- Enke > > > To correct this I propose that the following paragraph be added > immediately following the text quoted above. > > In some cases it may not be possible to determine an unambiguous, > unique neighbor AS, such as when the AS_PATH attribute begins with > an AS_SET due to aggregation. If the neighbor AS of a route cannot > be determined, the MULTI_EXIT_DISC MUST NOT be compared with the > MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- > code above, this can be accomplished by considering neighborAS(n) > to return a special distinguished "not found" value (which is not > equal to any AS value) and MED(n) to return 0 for such routes. > > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. This is just belt and suspenders though, > and I don't much care if we do it or not. > > In reality I doubt this case is ever seen in the wild, but it's good > to have the spec right anyway. > > Regards, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 13:55:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04538; Tue, 30 Sep 2003 13:55:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Oia-0002Ld-00; Tue, 30 Sep 2003 13:55:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4OiZ-0002La-00; Tue, 30 Sep 2003 13:55:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OiF-0006v0-4P; Tue, 30 Sep 2003 13:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Ohc-0006th-5x for idr@optimus.ietf.org; Tue, 30 Sep 2003 13:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04500 for ; Tue, 30 Sep 2003 13:54:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OhZ-0002L5-00 for idr@ietf.org; Tue, 30 Sep 2003 13:54:21 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4OhZ-0002Km-00 for idr@ietf.org; Tue, 30 Sep 2003 13:54:21 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UHrdj05538; Tue, 30 Sep 2003 10:53:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301753.h8UHrdj05538@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Tue, 30 Sep 2003 10:10:49 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12685.1064944419.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 10:53:39 -0700 Pekka, > Responding to two issues which seem may warrant further discussion from > me.. > > On Mon, 29 Sep 2003, Yakov Rekhter wrote: > > > - I got major headache when trying to read the aggregating rules > > > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > > > rules :-(!!!) and ended up skipping them. > > > > > > substantial > > > ----------- > > > > > > 1) Section 3 on Summary of the Operations, states: > > > > > > In the context of this document we assume that a BGP speaker adver- > > > tises to its peers only those routes that it itself uses (in this > > > context a BGP speaker is said to "use" a BGP route if it is the most > > > preferred BGP route and is used in forwarding). All other cases are > > > outside the scope of this document. > > > > > > this "usability" requirement is in conflict with section 4.3 on UPDATE > > > message format: > > > > > > An UPDATE message is used to advertise feasible routes sharing common > > > path attributes to a peer, [...] > > > > > > ==> in particular note that "feasible" is a superset of "only those route s > > > the router itself uses" (compare to "those routes the router itself _coul d_ > > > use if they were the most preferred ones"), right? Could you point me to the text in the spec that said that "feasible" is a superset of "only those routes that the router itself uses" ? > > > ==> also note that the former definition is (IMHO) operationally unsound. > > > It prevents you from advertising P-t-P addresses and loopbacks (which als o > > > reside in IGP) using BGP, because the IGP distance is lower than BGP and > > > "BGP route is never used in forwarding". (depending on how you interpret > > > that). IMHO, this really needs to be changed to be OK. > > > > The current text reflects consensus reached by the WG. > > Note that there are two issues here: > 1) the text is out-of-sync between sections 3 and 4.3, and > 2) that the current definition of BGP route used for forwarding is not > really useful. > > I take it that the comment 1) is still valid. > > Has 2) -- which you were probably referring to -- been raised as an issue > in the spec? Any pointers to the issue, discussion, and the conclusion > (the answer to the question "Why did the WG decide this way?") I fail to > see why such a conclusion would be justified.. and if the relevant points > haven't been raised already, I probably want to re-open that debate. From draft-ietf-idr-bgp-issues-01.txt: After some additional discussion (in the "issue 11.2" thread), we have come to a consensus on this text: In the context of this document we assume that a BGP speaker advertises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. This issue is at consensus. So, the text in the spec represents consensus of the WG. Also note the last sentence in the above paragraph. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 13:55:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04585 for ; Tue, 30 Sep 2003 13:55:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Oic-0006z8-VY for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 13:55:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UHtQYP026844 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 13:55:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Oic-0006yt-Qx for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 13:55:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04538; Tue, 30 Sep 2003 13:55:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Oia-0002Ld-00; Tue, 30 Sep 2003 13:55:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4OiZ-0002La-00; Tue, 30 Sep 2003 13:55:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OiF-0006v0-4P; Tue, 30 Sep 2003 13:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Ohc-0006th-5x for idr@optimus.ietf.org; Tue, 30 Sep 2003 13:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04500 for ; Tue, 30 Sep 2003 13:54:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OhZ-0002L5-00 for idr@ietf.org; Tue, 30 Sep 2003 13:54:21 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4OhZ-0002Km-00 for idr@ietf.org; Tue, 30 Sep 2003 13:54:21 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UHrdj05538; Tue, 30 Sep 2003 10:53:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301753.h8UHrdj05538@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Tue, 30 Sep 2003 10:10:49 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12685.1064944419.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 10:53:39 -0700 Pekka, > Responding to two issues which seem may warrant further discussion from > me.. > > On Mon, 29 Sep 2003, Yakov Rekhter wrote: > > > - I got major headache when trying to read the aggregating rules > > > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > > > rules :-(!!!) and ended up skipping them. > > > > > > substantial > > > ----------- > > > > > > 1) Section 3 on Summary of the Operations, states: > > > > > > In the context of this document we assume that a BGP speaker adver- > > > tises to its peers only those routes that it itself uses (in this > > > context a BGP speaker is said to "use" a BGP route if it is the most > > > preferred BGP route and is used in forwarding). All other cases are > > > outside the scope of this document. > > > > > > this "usability" requirement is in conflict with section 4.3 on UPDATE > > > message format: > > > > > > An UPDATE message is used to advertise feasible routes sharing common > > > path attributes to a peer, [...] > > > > > > ==> in particular note that "feasible" is a superset of "only those route s > > > the router itself uses" (compare to "those routes the router itself _coul d_ > > > use if they were the most preferred ones"), right? Could you point me to the text in the spec that said that "feasible" is a superset of "only those routes that the router itself uses" ? > > > ==> also note that the former definition is (IMHO) operationally unsound. > > > It prevents you from advertising P-t-P addresses and loopbacks (which als o > > > reside in IGP) using BGP, because the IGP distance is lower than BGP and > > > "BGP route is never used in forwarding". (depending on how you interpret > > > that). IMHO, this really needs to be changed to be OK. > > > > The current text reflects consensus reached by the WG. > > Note that there are two issues here: > 1) the text is out-of-sync between sections 3 and 4.3, and > 2) that the current definition of BGP route used for forwarding is not > really useful. > > I take it that the comment 1) is still valid. > > Has 2) -- which you were probably referring to -- been raised as an issue > in the spec? Any pointers to the issue, discussion, and the conclusion > (the answer to the question "Why did the WG decide this way?") I fail to > see why such a conclusion would be justified.. and if the relevant points > haven't been raised already, I probably want to re-open that debate. From draft-ietf-idr-bgp-issues-01.txt: After some additional discussion (in the "issue 11.2" thread), we have come to a consensus on this text: In the context of this document we assume that a BGP speaker advertises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. This issue is at consensus. So, the text in the spec represents consensus of the WG. Also note the last sentence in the above paragraph. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 14:16:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05595; Tue, 30 Sep 2003 14:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P3Z-0002dZ-00; Tue, 30 Sep 2003 14:17:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4P3Z-0002dW-00; Tue, 30 Sep 2003 14:17:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P3V-0008TD-5o; Tue, 30 Sep 2003 14:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P2y-0008IL-3T for idr@optimus.ietf.org; Tue, 30 Sep 2003 14:16:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05579 for ; Tue, 30 Sep 2003 14:16:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P2v-0002dI-00 for idr@ietf.org; Tue, 30 Sep 2003 14:16:25 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4P2v-0002d0-00 for idr@ietf.org; Tue, 30 Sep 2003 14:16:25 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UIFlj07925; Tue, 30 Sep 2003 11:15:47 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301815.h8UIFlj07925@merlot.juniper.net> To: "John G. Scudder" cc: idr@ietf.org Subject: Re: [Idr] Proposed change to 9.1.2.2 In-Reply-To: Your message of "Tue, 30 Sep 2003 11:19:23 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21398.1064945747.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:15:47 -0700 John, > Folks, > > There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec : > > c) Remove from consideration routes with less-preferred > MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable > between routes learned from the same neighboring AS (the neighbor- > ing AS is determined from the AS_PATH attribute). Routes which do > not have the MULTI_EXIT_DISC attribute are considered to have the > lowest possible MULTI_EXIT_DISC value. > > This is also described in the following procedure: > > for m = all routes still under consideration > for n = all routes still under consideration > if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m) ) > remove route m from consideration > > In the pseudo-code above, MED(n) is a function which returns the > value of route n's MULTI_EXIT_DISC attribute. If route n has no > MULTI_EXIT_DISC attribute, the function returns the lowest possi- > ble MULTI_EXIT_DISC value, i.e. 0. > > Similarly, neighborAS(n) is a function which returns the neighbor > AS from which the route was received. If the route is learned via > IBGP, and the other IBGP speaker didn't originate the route, it is > the neighbor AS from which the other IBGP speaker learned the > route. If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > > This text assumes that it is always possible to unambiguously > determine a unique neighbor AS for any route. However, in principle > this is not the case, as when a border router performs aggregation > towards IBGP, leading to a route whose AS path begins with an AS_SET. > > To correct this I propose that the following paragraph be added > immediately following the text quoted above. > > In some cases it may not be possible to determine an unambiguous, > unique neighbor AS, such as when the AS_PATH attribute begins with > an AS_SET due to aggregation. If the neighbor AS of a route cannot > be determined, the MULTI_EXIT_DISC MUST NOT be compared with the > MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- > code above, this can be accomplished by considering neighborAS(n) > to return a special distinguished "not found" value (which is not > equal to any AS value) and MED(n) to return 0 for such routes. Do you have any objections if instead of the text proposed above we'll follow Enke's suggestion ? Namely, replace If the route is learned via IBGP, and the other IBGP speaker originated the route, it is the local AS. with If the route is learned via IBGP, and the other IBGP speaker originated the route or created the aggregate, it is the local AS. (especially since Enke's text reflects several implementations) > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. This is just belt and suspenders though, > and I don't much care if we do it or not. In the absence of any objections I'll add this to the spec. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 14:17:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05627 for ; Tue, 30 Sep 2003 14:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P3c-0008Vc-IP for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 14:17:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UIH8OC032702 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 14:17:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P3c-0008VN-FJ for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 14:17:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05595; Tue, 30 Sep 2003 14:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P3Z-0002dZ-00; Tue, 30 Sep 2003 14:17:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4P3Z-0002dW-00; Tue, 30 Sep 2003 14:17:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P3V-0008TD-5o; Tue, 30 Sep 2003 14:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P2y-0008IL-3T for idr@optimus.ietf.org; Tue, 30 Sep 2003 14:16:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05579 for ; Tue, 30 Sep 2003 14:16:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P2v-0002dI-00 for idr@ietf.org; Tue, 30 Sep 2003 14:16:25 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4P2v-0002d0-00 for idr@ietf.org; Tue, 30 Sep 2003 14:16:25 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UIFlj07925; Tue, 30 Sep 2003 11:15:47 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301815.h8UIFlj07925@merlot.juniper.net> To: "John G. Scudder" cc: idr@ietf.org Subject: Re: [Idr] Proposed change to 9.1.2.2 In-Reply-To: Your message of "Tue, 30 Sep 2003 11:19:23 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21398.1064945747.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:15:47 -0700 John, > Folks, > > There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec : > > c) Remove from consideration routes with less-preferred > MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable > between routes learned from the same neighboring AS (the neighbor- > ing AS is determined from the AS_PATH attribute). Routes which do > not have the MULTI_EXIT_DISC attribute are considered to have the > lowest possible MULTI_EXIT_DISC value. > > This is also described in the following procedure: > > for m = all routes still under consideration > for n = all routes still under consideration > if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m) ) > remove route m from consideration > > In the pseudo-code above, MED(n) is a function which returns the > value of route n's MULTI_EXIT_DISC attribute. If route n has no > MULTI_EXIT_DISC attribute, the function returns the lowest possi- > ble MULTI_EXIT_DISC value, i.e. 0. > > Similarly, neighborAS(n) is a function which returns the neighbor > AS from which the route was received. If the route is learned via > IBGP, and the other IBGP speaker didn't originate the route, it is > the neighbor AS from which the other IBGP speaker learned the > route. If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > > This text assumes that it is always possible to unambiguously > determine a unique neighbor AS for any route. However, in principle > this is not the case, as when a border router performs aggregation > towards IBGP, leading to a route whose AS path begins with an AS_SET. > > To correct this I propose that the following paragraph be added > immediately following the text quoted above. > > In some cases it may not be possible to determine an unambiguous, > unique neighbor AS, such as when the AS_PATH attribute begins with > an AS_SET due to aggregation. If the neighbor AS of a route cannot > be determined, the MULTI_EXIT_DISC MUST NOT be compared with the > MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- > code above, this can be accomplished by considering neighborAS(n) > to return a special distinguished "not found" value (which is not > equal to any AS value) and MED(n) to return 0 for such routes. Do you have any objections if instead of the text proposed above we'll follow Enke's suggestion ? Namely, replace If the route is learned via IBGP, and the other IBGP speaker originated the route, it is the local AS. with If the route is learned via IBGP, and the other IBGP speaker originated the route or created the aggregate, it is the local AS. (especially since Enke's text reflects several implementations) > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. This is just belt and suspenders though, > and I don't much care if we do it or not. In the absence of any objections I'll add this to the spec. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 14:23:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05905; Tue, 30 Sep 2003 14:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PAH-0002j4-00; Tue, 30 Sep 2003 14:24:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4PAH-0002j1-00; Tue, 30 Sep 2003 14:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PAH-0000Zy-9L; Tue, 30 Sep 2003 14:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P9x-0000Zf-9v for idr@optimus.ietf.org; Tue, 30 Sep 2003 14:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05897 for ; Tue, 30 Sep 2003 14:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P9u-0002iq-00 for idr@ietf.org; Tue, 30 Sep 2003 14:23:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4P9u-0002iV-00 for idr@ietf.org; Tue, 30 Sep 2003 14:23:38 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2003 11:28:13 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8UINIXg024732; Tue, 30 Sep 2003 11:23:18 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-215-142.cisco.com [64.101.215.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA03134; Tue, 30 Sep 2003 14:23:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <200309301815.h8UIFlj07925@merlot.juniper.net> References: <200309301815.h8UIFlj07925@merlot.juniper.net> To: Yakov Rekhter From: "John G. Scudder" Subject: Re: [Idr] Proposed change to 9.1.2.2 Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 14:21:49 -0400 At 11:15 AM -0700 9/30/03, Yakov Rekhter wrote: >Do you have any objections if instead of the text proposed above >we'll follow Enke's suggestion ? Namely, replace > > If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > >with > If the route is learned via IBGP, and the other IBGP > speaker originated the route or created the aggregate, > it is the local AS. > >(especially since Enke's text reflects several implementations) As does mine for that matter, but I am fine with Enke's text. For one thing, it accomplishes the job using fewer words, always a good thing. > > I suppose it might also be worth saying (somewhere else, e.g. under >> the discussion of aggregation) that if you create an aggregated route >> which has an AS_SET as the first element in its AS_PATH, then you >> SHOULD strip the MED out. This is just belt and suspenders though, >> and I don't much care if we do it or not. > >In the absence of any objections I'll add this to the spec. OK. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 14:24:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05927 for ; Tue, 30 Sep 2003 14:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PAK-0000dk-QY for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 14:24:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UIO4Mc002454 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 14:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PAK-0000co-Le for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 14:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05905; Tue, 30 Sep 2003 14:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PAH-0002j4-00; Tue, 30 Sep 2003 14:24:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4PAH-0002j1-00; Tue, 30 Sep 2003 14:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PAH-0000Zy-9L; Tue, 30 Sep 2003 14:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P9x-0000Zf-9v for idr@optimus.ietf.org; Tue, 30 Sep 2003 14:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05897 for ; Tue, 30 Sep 2003 14:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P9u-0002iq-00 for idr@ietf.org; Tue, 30 Sep 2003 14:23:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4P9u-0002iV-00 for idr@ietf.org; Tue, 30 Sep 2003 14:23:38 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2003 11:28:13 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8UINIXg024732; Tue, 30 Sep 2003 11:23:18 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-215-142.cisco.com [64.101.215.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA03134; Tue, 30 Sep 2003 14:23:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <200309301815.h8UIFlj07925@merlot.juniper.net> References: <200309301815.h8UIFlj07925@merlot.juniper.net> To: Yakov Rekhter From: "John G. Scudder" Subject: Re: [Idr] Proposed change to 9.1.2.2 Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 14:21:49 -0400 At 11:15 AM -0700 9/30/03, Yakov Rekhter wrote: >Do you have any objections if instead of the text proposed above >we'll follow Enke's suggestion ? Namely, replace > > If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > >with > If the route is learned via IBGP, and the other IBGP > speaker originated the route or created the aggregate, > it is the local AS. > >(especially since Enke's text reflects several implementations) As does mine for that matter, but I am fine with Enke's text. For one thing, it accomplishes the job using fewer words, always a good thing. > > I suppose it might also be worth saying (somewhere else, e.g. under >> the discussion of aggregation) that if you create an aggregated route >> which has an AS_SET as the first element in its AS_PATH, then you >> SHOULD strip the MED out. This is just belt and suspenders though, >> and I don't much care if we do it or not. > >In the absence of any objections I'll add this to the spec. OK. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Sep 30 15:30:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10712; Tue, 30 Sep 2003 15:30:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QCL-0003k2-00; Tue, 30 Sep 2003 15:30:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4QCK-0003jz-00; Tue, 30 Sep 2003 15:30:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QCA-0007D9-Fk; Tue, 30 Sep 2003 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QBj-0007Ce-6p for idr@optimus.ietf.org; Tue, 30 Sep 2003 15:29:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10687 for ; Tue, 30 Sep 2003 15:29:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QBh-0003jQ-00 for idr@ietf.org; Tue, 30 Sep 2003 15:29:33 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4QBh-0003ix-00 for idr@ietf.org; Tue, 30 Sep 2003 15:29:33 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UJShj14680; Tue, 30 Sep 2003 12:28:43 -0700 (PDT) (envelope-from dennis@juniper.net) Message-Id: <200309301928.h8UJShj14680@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Pekka Savola cc: "John G. Scudder" , Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-reply-to: Your message of "Tue, 30 Sep 2003 09:52:00 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Dennis Ferguson Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 12:28:43 -0700 > > > It is a bug in the specification sense because the spec does not include > > > text that you should do loop prevention by discarding the path when it > > > contains your own AS. > > > > The minimal theoretical requirement for loop termination (BGP doesn't > > prevent loops which occur transiently, just guarantees they'll eventually > > be stopped) is that you should discard the path when it includes your > > own AS `N' times, for any `N' you care to choose. While N=1, which you like, > > will terminate loops, letting N=2 or N=5 or N=12 will terminate them > > just fine as well (though you are wasting convergence time if you make > > `N' larger than the number of inter-AS border routers you have, at most). > > It hence isn't a bug to allow `N' to be set to a value other than 1 in > > any theoretical sense. > > I wouldn't call such an AS having a coherent routing plan. If you allow > AS > 1, you're abusing the term AS. I notice you've changed the subject from one of protocol correctness, i.e. whether routing loops are guaranteed to terminate, to one of policy, i.e. whether, in your opinion, it is a good idea to do this to solve routing problems one might have when using the protocol. As the people who originally responded to you implied, the BGP protocol specification has always tried to limit itself to ensuring protocol correctness while leaving policy to the users of the protocol. I think that's still appropriate. > > > Further, there is no need to do anything of this sort if you get default > > > routes from the Internet, or set up a backup (highest protocol distance) > > > route towards the Internet. > > > > I'm sure you don't mean that one or the other of those things is always > > possible to do. It is when neither of those things is possible that you > > might want to set N>1 instead. > > Can you shown me a couple (or at least _one_) example where other methods > are not possible and this is required? Suppose the operators of two multiply-connected networks agree to provide backup routing to heal each other's partitions without offering transit to the rest of "the Internet". Here you need explicit routing for the destinations being backed up (they may already default traffic to "the Internet" to other providers), and you certainly can't have two guys pointing default routes at each other in any case. Or, suppose three operators have entered into a similar arrangement, with the partitioned guy being allowed to split his load across the other two. You can't have two default routes pointing at different guys (especially if "the Internet" is in some other direction), and you generally need explicit routes to get a predictable load split. Of course these are only problems I can think of, there are likely lots more problems that I can't imagine. The latter is the reason the BGP specification should limit itself to protocol correctness issues, leaving policy issues to the protocol users who actually have the problems to solve. Dennis Ferguson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Sep 30 15:30:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10753 for ; Tue, 30 Sep 2003 15:30:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QCN-0007Fo-IC for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 15:30:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJUFgC027878 for idr-archive@odin.ietf.org; Tue, 30 Sep 2003 15:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QCN-0007FZ-E2 for idr-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 15:30:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10712; Tue, 30 Sep 2003 15:30:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QCL-0003k2-00; Tue, 30 Sep 2003 15:30:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4QCK-0003jz-00; Tue, 30 Sep 2003 15:30:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QCA-0007D9-Fk; Tue, 30 Sep 2003 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QBj-0007Ce-6p for idr@optimus.ietf.org; Tue, 30 Sep 2003 15:29:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10687 for ; Tue, 30 Sep 2003 15:29:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QBh-0003jQ-00 for idr@ietf.org; Tue, 30 Sep 2003 15:29:33 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4QBh-0003ix-00 for idr@ietf.org; Tue, 30 Sep 2003 15:29:33 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UJShj14680; Tue, 30 Sep 2003 12:28:43 -0700 (PDT) (envelope-from dennis@juniper.net) Message-Id: <200309301928.h8UJShj14680@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Pekka Savola cc: "John G. Scudder" , Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-reply-to: Your message of "Tue, 30 Sep 2003 09:52:00 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Dennis Ferguson Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 12:28:43 -0700 > > > It is a bug in the specification sense because the spec does not include > > > text that you should do loop prevention by discarding the path when it > > > contains your own AS. > > > > The minimal theoretical requirement for loop termination (BGP doesn't > > prevent loops which occur transiently, just guarantees they'll eventually > > be stopped) is that you should discard the path when it includes your > > own AS `N' times, for any `N' you care to choose. While N=1, which you like, > > will terminate loops, letting N=2 or N=5 or N=12 will terminate them > > just fine as well (though you are wasting convergence time if you make > > `N' larger than the number of inter-AS border routers you have, at most). > > It hence isn't a bug to allow `N' to be set to a value other than 1 in > > any theoretical sense. > > I wouldn't call such an AS having a coherent routing plan. If you allow > AS > 1, you're abusing the term AS. I notice you've changed the subject from one of protocol correctness, i.e. whether routing loops are guaranteed to terminate, to one of policy, i.e. whether, in your opinion, it is a good idea to do this to solve routing problems one might have when using the protocol. As the people who originally responded to you implied, the BGP protocol specification has always tried to limit itself to ensuring protocol correctness while leaving policy to the users of the protocol. I think that's still appropriate. > > > Further, there is no need to do anything of this sort if you get default > > > routes from the Internet, or set up a backup (highest protocol distance) > > > route towards the Internet. > > > > I'm sure you don't mean that one or the other of those things is always > > possible to do. It is when neither of those things is possible that you > > might want to set N>1 instead. > > Can you shown me a couple (or at least _one_) example where other methods > are not possible and this is required? Suppose the operators of two multiply-connected networks agree to provide backup routing to heal each other's partitions without offering transit to the rest of "the Internet". Here you need explicit routing for the destinations being backed up (they may already default traffic to "the Internet" to other providers), and you certainly can't have two guys pointing default routes at each other in any case. Or, suppose three operators have entered into a similar arrangement, with the partitioned guy being allowed to split his load across the other two. You can't have two default routes pointing at different guys (especially if "the Internet" is in some other direction), and you generally need explicit routes to get a predictable load split. Of course these are only problems I can think of, there are likely lots more problems that I can't imagine. The latter is the reason the BGP specification should limit itself to protocol correctness issues, leaving policy issues to the protocol users who actually have the problems to solve. Dennis Ferguson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA29303 for ; Tue, 30 Sep 2003 15:30:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QCA-0007DD-KN; Tue, 30 Sep 2003 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QBj-0007Ce-6p for idr@optimus.ietf.org; Tue, 30 Sep 2003 15:29:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10687 for ; Tue, 30 Sep 2003 15:29:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QBh-0003jQ-00 for idr@ietf.org; Tue, 30 Sep 2003 15:29:33 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4QBh-0003ix-00 for idr@ietf.org; Tue, 30 Sep 2003 15:29:33 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UJShj14680; Tue, 30 Sep 2003 12:28:43 -0700 (PDT) (envelope-from dennis@juniper.net) Message-Id: <200309301928.h8UJShj14680@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Pekka Savola cc: "John G. Scudder" , Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-reply-to: Your message of "Tue, 30 Sep 2003 09:52:00 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Dennis Ferguson Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 12:28:43 -0700 > > > It is a bug in the specification sense because the spec does not include > > > text that you should do loop prevention by discarding the path when it > > > contains your own AS. > > > > The minimal theoretical requirement for loop termination (BGP doesn't > > prevent loops which occur transiently, just guarantees they'll eventually > > be stopped) is that you should discard the path when it includes your > > own AS `N' times, for any `N' you care to choose. While N=1, which you like, > > will terminate loops, letting N=2 or N=5 or N=12 will terminate them > > just fine as well (though you are wasting convergence time if you make > > `N' larger than the number of inter-AS border routers you have, at most). > > It hence isn't a bug to allow `N' to be set to a value other than 1 in > > any theoretical sense. > > I wouldn't call such an AS having a coherent routing plan. If you allow > AS > 1, you're abusing the term AS. I notice you've changed the subject from one of protocol correctness, i.e. whether routing loops are guaranteed to terminate, to one of policy, i.e. whether, in your opinion, it is a good idea to do this to solve routing problems one might have when using the protocol. As the people who originally responded to you implied, the BGP protocol specification has always tried to limit itself to ensuring protocol correctness while leaving policy to the users of the protocol. I think that's still appropriate. > > > Further, there is no need to do anything of this sort if you get default > > > routes from the Internet, or set up a backup (highest protocol distance) > > > route towards the Internet. > > > > I'm sure you don't mean that one or the other of those things is always > > possible to do. It is when neither of those things is possible that you > > might want to set N>1 instead. > > Can you shown me a couple (or at least _one_) example where other methods > are not possible and this is required? Suppose the operators of two multiply-connected networks agree to provide backup routing to heal each other's partitions without offering transit to the rest of "the Internet". Here you need explicit routing for the destinations being backed up (they may already default traffic to "the Internet" to other providers), and you certainly can't have two guys pointing default routes at each other in any case. Or, suppose three operators have entered into a similar arrangement, with the partitioned guy being allowed to split his load across the other two. You can't have two default routes pointing at different guys (especially if "the Internet" is in some other direction), and you generally need explicit routes to get a predictable load split. Of course these are only problems I can think of, there are likely lots more problems that I can't imagine. The latter is the reason the BGP specification should limit itself to protocol correctness issues, leaving policy issues to the protocol users who actually have the problems to solve. Dennis Ferguson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA25222 for ; Tue, 30 Sep 2003 14:24:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PAH-0000a0-B1; Tue, 30 Sep 2003 14:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P9x-0000Zf-9v for idr@optimus.ietf.org; Tue, 30 Sep 2003 14:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05897 for ; Tue, 30 Sep 2003 14:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P9u-0002iq-00 for idr@ietf.org; Tue, 30 Sep 2003 14:23:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4P9u-0002iV-00 for idr@ietf.org; Tue, 30 Sep 2003 14:23:38 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2003 11:28:13 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8UINIXg024732; Tue, 30 Sep 2003 11:23:18 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-215-142.cisco.com [64.101.215.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA03134; Tue, 30 Sep 2003 14:23:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <200309301815.h8UIFlj07925@merlot.juniper.net> References: <200309301815.h8UIFlj07925@merlot.juniper.net> To: Yakov Rekhter From: "John G. Scudder" Subject: Re: [Idr] Proposed change to 9.1.2.2 Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 14:21:49 -0400 At 11:15 AM -0700 9/30/03, Yakov Rekhter wrote: >Do you have any objections if instead of the text proposed above >we'll follow Enke's suggestion ? Namely, replace > > If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > >with > If the route is learned via IBGP, and the other IBGP > speaker originated the route or created the aggregate, > it is the local AS. > >(especially since Enke's text reflects several implementations) As does mine for that matter, but I am fine with Enke's text. For one thing, it accomplishes the job using fewer words, always a good thing. > > I suppose it might also be worth saying (somewhere else, e.g. under >> the discussion of aggregation) that if you create an aggregated route >> which has an AS_SET as the first element in its AS_PATH, then you >> SHOULD strip the MED out. This is just belt and suspenders though, >> and I don't much care if we do it or not. > >In the absence of any objections I'll add this to the spec. OK. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA24828 for ; Tue, 30 Sep 2003 14:17:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P3V-0008TF-7M; Tue, 30 Sep 2003 14:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4P2y-0008IL-3T for idr@optimus.ietf.org; Tue, 30 Sep 2003 14:16:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05579 for ; Tue, 30 Sep 2003 14:16:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4P2v-0002dI-00 for idr@ietf.org; Tue, 30 Sep 2003 14:16:25 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4P2v-0002d0-00 for idr@ietf.org; Tue, 30 Sep 2003 14:16:25 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UIFlj07925; Tue, 30 Sep 2003 11:15:47 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301815.h8UIFlj07925@merlot.juniper.net> To: "John G. Scudder" cc: idr@ietf.org Subject: Re: [Idr] Proposed change to 9.1.2.2 In-Reply-To: Your message of "Tue, 30 Sep 2003 11:19:23 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21398.1064945747.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:15:47 -0700 John, > Folks, > > There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec : > > c) Remove from consideration routes with less-preferred > MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable > between routes learned from the same neighboring AS (the neighbor- > ing AS is determined from the AS_PATH attribute). Routes which do > not have the MULTI_EXIT_DISC attribute are considered to have the > lowest possible MULTI_EXIT_DISC value. > > This is also described in the following procedure: > > for m = all routes still under consideration > for n = all routes still under consideration > if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m) ) > remove route m from consideration > > In the pseudo-code above, MED(n) is a function which returns the > value of route n's MULTI_EXIT_DISC attribute. If route n has no > MULTI_EXIT_DISC attribute, the function returns the lowest possi- > ble MULTI_EXIT_DISC value, i.e. 0. > > Similarly, neighborAS(n) is a function which returns the neighbor > AS from which the route was received. If the route is learned via > IBGP, and the other IBGP speaker didn't originate the route, it is > the neighbor AS from which the other IBGP speaker learned the > route. If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > > This text assumes that it is always possible to unambiguously > determine a unique neighbor AS for any route. However, in principle > this is not the case, as when a border router performs aggregation > towards IBGP, leading to a route whose AS path begins with an AS_SET. > > To correct this I propose that the following paragraph be added > immediately following the text quoted above. > > In some cases it may not be possible to determine an unambiguous, > unique neighbor AS, such as when the AS_PATH attribute begins with > an AS_SET due to aggregation. If the neighbor AS of a route cannot > be determined, the MULTI_EXIT_DISC MUST NOT be compared with the > MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- > code above, this can be accomplished by considering neighborAS(n) > to return a special distinguished "not found" value (which is not > equal to any AS value) and MED(n) to return 0 for such routes. Do you have any objections if instead of the text proposed above we'll follow Enke's suggestion ? Namely, replace If the route is learned via IBGP, and the other IBGP speaker originated the route, it is the local AS. with If the route is learned via IBGP, and the other IBGP speaker originated the route or created the aggregate, it is the local AS. (especially since Enke's text reflects several implementations) > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. This is just belt and suspenders though, > and I don't much care if we do it or not. In the absence of any objections I'll add this to the spec. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA23525 for ; Tue, 30 Sep 2003 13:55:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OiF-0006v2-6E; Tue, 30 Sep 2003 13:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Ohc-0006th-5x for idr@optimus.ietf.org; Tue, 30 Sep 2003 13:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04500 for ; Tue, 30 Sep 2003 13:54:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OhZ-0002L5-00 for idr@ietf.org; Tue, 30 Sep 2003 13:54:21 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4OhZ-0002Km-00 for idr@ietf.org; Tue, 30 Sep 2003 13:54:21 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UHrdj05538; Tue, 30 Sep 2003 10:53:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301753.h8UHrdj05538@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Tue, 30 Sep 2003 10:10:49 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12685.1064944419.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 10:53:39 -0700 Pekka, > Responding to two issues which seem may warrant further discussion from > me.. > > On Mon, 29 Sep 2003, Yakov Rekhter wrote: > > > - I got major headache when trying to read the aggregating rules > > > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > > > rules :-(!!!) and ended up skipping them. > > > > > > substantial > > > ----------- > > > > > > 1) Section 3 on Summary of the Operations, states: > > > > > > In the context of this document we assume that a BGP speaker adver- > > > tises to its peers only those routes that it itself uses (in this > > > context a BGP speaker is said to "use" a BGP route if it is the most > > > preferred BGP route and is used in forwarding). All other cases are > > > outside the scope of this document. > > > > > > this "usability" requirement is in conflict with section 4.3 on UPDATE > > > message format: > > > > > > An UPDATE message is used to advertise feasible routes sharing common > > > path attributes to a peer, [...] > > > > > > ==> in particular note that "feasible" is a superset of "only those route s > > > the router itself uses" (compare to "those routes the router itself _coul d_ > > > use if they were the most preferred ones"), right? Could you point me to the text in the spec that said that "feasible" is a superset of "only those routes that the router itself uses" ? > > > ==> also note that the former definition is (IMHO) operationally unsound. > > > It prevents you from advertising P-t-P addresses and loopbacks (which als o > > > reside in IGP) using BGP, because the IGP distance is lower than BGP and > > > "BGP route is never used in forwarding". (depending on how you interpret > > > that). IMHO, this really needs to be changed to be OK. > > > > The current text reflects consensus reached by the WG. > > Note that there are two issues here: > 1) the text is out-of-sync between sections 3 and 4.3, and > 2) that the current definition of BGP route used for forwarding is not > really useful. > > I take it that the comment 1) is still valid. > > Has 2) -- which you were probably referring to -- been raised as an issue > in the spec? Any pointers to the issue, discussion, and the conclusion > (the answer to the question "Why did the WG decide this way?") I fail to > see why such a conclusion would be justified.. and if the relevant points > haven't been raised already, I probably want to re-open that debate. >From draft-ietf-idr-bgp-issues-01.txt: After some additional discussion (in the "issue 11.2" thread), we have come to a consensus on this text: In the context of this document we assume that a BGP speaker advertises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. This issue is at consensus. So, the text in the spec represents consensus of the WG. Also note the last sentence in the above paragraph. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA17219 for ; Tue, 30 Sep 2003 12:03:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Mxq-0007b3-HI; Tue, 30 Sep 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Mxg-0007aQ-M9 for idr@optimus.ietf.org; Tue, 30 Sep 2003 12:02:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28740 for ; Tue, 30 Sep 2003 12:02:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Mxf-0000mx-00 for idr@ietf.org; Tue, 30 Sep 2003 12:02:51 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1A4MxZ-0000mi-00 for idr@ietf.org; Tue, 30 Sep 2003 12:02:48 -0400 Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 5911C60D0C8; Tue, 30 Sep 2003 09:01:56 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 8682A15D3C1; Tue, 30 Sep 2003 09:01:55 -0700 (PDT) To: "John G. Scudder" Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] Proposed change to 9.1.2.2 In-Reply-To: Message from "John G. Scudder" of "Tue, 30 Sep 2003 11:19:23 EDT." From: Enke Chen Message-Id: <20030930160155.8682A15D3C1@popserv1.redback.com> Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 09:01:55 -0700 John, > Message-Id: > To: idr@ietf.org > From: "John G. Scudder" > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > Subject: [Idr] Proposed change to 9.1.2.2 > Sender: idr-admin@ietf.org > > Folks, > > There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec: > > c) Remove from consideration routes with less-preferred > MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable > between routes learned from the same neighboring AS (the neighbor- > ing AS is determined from the AS_PATH attribute). Routes which do > not have the MULTI_EXIT_DISC attribute are considered to have the > lowest possible MULTI_EXIT_DISC value. > > This is also described in the following procedure: > > for m = all routes still under consideration > for n = all routes still under consideration > if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) > remove route m from consideration > > In the pseudo-code above, MED(n) is a function which returns the > value of route n's MULTI_EXIT_DISC attribute. If route n has no > MULTI_EXIT_DISC attribute, the function returns the lowest possi- > ble MULTI_EXIT_DISC value, i.e. 0. > > Similarly, neighborAS(n) is a function which returns the neighbor > AS from which the route was received. If the route is learned via > IBGP, and the other IBGP speaker didn't originate the route, it is > the neighbor AS from which the other IBGP speaker learned the > route. If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. > > This text assumes that it is always possible to unambiguously > determine a unique neighbor AS for any route. However, in principle > this is not the case, as when a border router performs aggregation > towards IBGP, leading to a route whose AS path begins with an AS_SET. I believe that an aggregated route is treated the same as an originated route in this regard by several implementations I am familiar with. Such treatment does make sense - a route is originated when you aggregate. If further clarification is desired in the spec, we could revise it like the following: If the route is learned via IBGP, and the other IBGP speaker originated the route or created the aggregate, ++++++++++++++++++++++++ it is the local AS. Regards, -- Enke > > > To correct this I propose that the following paragraph be added > immediately following the text quoted above. > > In some cases it may not be possible to determine an unambiguous, > unique neighbor AS, such as when the AS_PATH attribute begins with > an AS_SET due to aggregation. If the neighbor AS of a route cannot > be determined, the MULTI_EXIT_DISC MUST NOT be compared with the > MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- > code above, this can be accomplished by considering neighborAS(n) > to return a special distinguished "not found" value (which is not > equal to any AS value) and MED(n) to return 0 for such routes. > > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. This is just belt and suspenders though, > and I don't much care if we do it or not. > > In reality I doubt this case is ever seen in the wild, but it's good > to have the spec right anyway. > > Regards, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15870 for ; Tue, 30 Sep 2003 11:34:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MVl-000575-Aj; Tue, 30 Sep 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MVM-00055M-Bd for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:33:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26813 for ; Tue, 30 Sep 2003 11:33:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MVL-0000Gz-00 for idr@ietf.org; Tue, 30 Sep 2003 11:33:35 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A4MVK-0000Gg-00 for idr@ietf.org; Tue, 30 Sep 2003 11:33:34 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8UFWs5W084360; Tue, 30 Sep 2003 11:32:54 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8UFWqOT084352; Tue, 30 Sep 2003 11:32:52 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8UFWls24405; Tue, 30 Sep 2003 11:32:47 -0400 (EDT) From: Jeffrey Haas To: "John G. Scudder" Cc: idr@ietf.org Subject: Re: [Idr] Proposed change to 9.1.2.2 Message-ID: <20030930113246.I4801@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jgs@cisco.com on Tue, Sep 30, 2003 at 11:19:23AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:32:47 -0400 On Tue, Sep 30, 2003 at 11:19:23AM -0400, John G. Scudder wrote: > I suppose it might also be worth saying (somewhere else, e.g. under > the discussion of aggregation) that if you create an aggregated route > which has an AS_SET as the first element in its AS_PATH, then you > SHOULD strip the MED out. Well, this is only important if you're allowing routes to be aggregated regardless of MED value. :-) Good catch though. This makes me wonder if our elders had already though of this particular case and that was what the odd restriction of not aggregating things with different MEDs was really for. If you don't aggregate things with different MEDs, you can simply check the leading set for the presence of the AS. > --John -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15378 for ; Tue, 30 Sep 2003 11:21:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MJB-0004Sf-Kd; Tue, 30 Sep 2003 11:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MID-0004Nj-1y for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26289 for ; Tue, 30 Sep 2003 11:19:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4MIC-00006c-00 for idr@ietf.org; Tue, 30 Sep 2003 11:20:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4MIB-00005X-00 for idr@ietf.org; Tue, 30 Sep 2003 11:19:59 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Sep 2003 08:18:59 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8UFJQXg016097 for ; Tue, 30 Sep 2003 08:19:27 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-215-142.cisco.com [64.101.215.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA25941 for ; Tue, 30 Sep 2003 11:19:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Idr] Proposed change to 9.1.2.2 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:19:23 -0400 Folks, There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec: c) Remove from consideration routes with less-preferred MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable between routes learned from the same neighboring AS (the neighbor- ing AS is determined from the AS_PATH attribute). Routes which do not have the MULTI_EXIT_DISC attribute are considered to have the lowest possible MULTI_EXIT_DISC value. This is also described in the following procedure: for m = all routes still under consideration for n = all routes still under consideration if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) remove route m from consideration In the pseudo-code above, MED(n) is a function which returns the value of route n's MULTI_EXIT_DISC attribute. If route n has no MULTI_EXIT_DISC attribute, the function returns the lowest possi- ble MULTI_EXIT_DISC value, i.e. 0. Similarly, neighborAS(n) is a function which returns the neighbor AS from which the route was received. If the route is learned via IBGP, and the other IBGP speaker didn't originate the route, it is the neighbor AS from which the other IBGP speaker learned the route. If the route is learned via IBGP, and the other IBGP speaker originated the route, it is the local AS. This text assumes that it is always possible to unambiguously determine a unique neighbor AS for any route. However, in principle this is not the case, as when a border router performs aggregation towards IBGP, leading to a route whose AS path begins with an AS_SET. To correct this I propose that the following paragraph be added immediately following the text quoted above. In some cases it may not be possible to determine an unambiguous, unique neighbor AS, such as when the AS_PATH attribute begins with an AS_SET due to aggregation. If the neighbor AS of a route cannot be determined, the MULTI_EXIT_DISC MUST NOT be compared with the MULTI_EXIT_DISC of any other route. For the purposes of the pseudo- code above, this can be accomplished by considering neighborAS(n) to return a special distinguished "not found" value (which is not equal to any AS value) and MED(n) to return 0 for such routes. I suppose it might also be worth saying (somewhere else, e.g. under the discussion of aggregation) that if you create an aggregated route which has an AS_SET as the first element in its AS_PATH, then you SHOULD strip the MED out. This is just belt and suspenders though, and I don't much care if we do it or not. In reality I doubt this case is ever seen in the wild, but it's good to have the spec right anyway. Regards, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15304 for ; Tue, 30 Sep 2003 11:19:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MHG-0004HI-EM; Tue, 30 Sep 2003 11:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4MH1-0004GU-MN for idr@optimus.ietf.org; Tue, 30 Sep 2003 11:18:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26092; Tue, 30 Sep 2003 11:18:39 -0400 (EDT) Message-Id: <200309301518.LAA26092@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-08.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 11:18:38 -0400 --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 : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, Y. Rekhter et al. Filename : draft-ietf-idr-restart-08.txt Pages : 10 Date : 2003-9-30 This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-30112431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-30112431.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA12154 for ; Tue, 30 Sep 2003 09:59:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L1p-0007RA-R3; Tue, 30 Sep 2003 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4L1k-0007Qu-56 for idr@optimus.ietf.org; Tue, 30 Sep 2003 09:58:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21526 for ; Tue, 30 Sep 2003 09:58:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L1i-0006wj-00 for idr@ietf.org; Tue, 30 Sep 2003 09:58:54 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4L1h-0006wa-00 for idr@ietf.org; Tue, 30 Sep 2003 09:58:53 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8UDwKZ08120; Tue, 30 Sep 2003 16:58:20 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309301255.h8UCtuj84169@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 16:58:20 +0300 (EEST) On Tue, 30 Sep 2003, Yakov Rekhter wrote: > > > > 3) there is significant confusion on what "locally originated" means. It > is > > > > not clear whether this refers to "local to the BGP speaker (i.e., the sam > e > > > > system)" or "local to the routing domain (i.e., the same AS)". This must > be > > > > clarified in the text below, and the text should be reviewed. > > > > > > What makes you think that "locally originated" means "local to the routing > > > domain" ? > > > > The text: > > > > 1) When sending a message to an internal peer, if the route is not > > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > > attribute, unless it has been explicitly configured to announce > > its own IP address as the NEXT_HOP. > > > > .. because, obviously, you do not _modify_ NEXT_HOP for any routes which > > you originate. You _set_ it to be something. Further, you use double > > negative in above, so it's pretty difficult to figure out what's the > > actual intent there...: > > > > - if the route is locally originated the BGP speaker ... > > a) ? > > b) SHOULD modify NEXT_HOP (or something else) ? > > - if the route is not locally originated, the BGP speaker SHOULD NOT > > modify NEXT_HOP > > > > So, I'd suggest rewording the start of that paragraph; perhaps e.g.: > > > > 1) When sending a message to an internal peer, and the route is > > not originated by the BGP speaker, the BGP speaker SHOULD keep the > > NEXT_HOP attribute intact, unless it has been explicitly configured > > to announce its own IP address as the NEXT_HOP. > > The current text reflects the consensus of the WG (see 2.61 in > draft-ietf-idr-bgp-issues-01.txt). Looking at 2.61, it seems that issue made solely for the _next_ sentences, i.e., for the case of locally originated routes. In both the old and the new text, the text I'd like to change seemed to be unchanged. So, I'm not sure if I see that this proposal is an old, already concensus-achieved issue ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA10056 for ; Tue, 30 Sep 2003 08:57:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4K3p-00046D-5g; Tue, 30 Sep 2003 08:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4K3Q-00045n-VP for idr@optimus.ietf.org; Tue, 30 Sep 2003 08:56:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19614 for ; Tue, 30 Sep 2003 08:56:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4K3P-0006I2-00 for idr@ietf.org; Tue, 30 Sep 2003 08:56:35 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A4K3O-0006Gr-00 for idr@ietf.org; Tue, 30 Sep 2003 08:56:35 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8UCtuj84169; Tue, 30 Sep 2003 05:55:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309301255.h8UCtuj84169@merlot.juniper.net> To: Pekka Savola cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Tue, 30 Sep 2003 10:10:49 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19483.1064926556.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 05:55:56 -0700 Pekka, > Responding to two issues which seem may warrant further discussion from > me.. > [clipped...] > > > 3) there is significant confusion on what "locally originated" means. It is > > > not clear whether this refers to "local to the BGP speaker (i.e., the sam e > > > system)" or "local to the routing domain (i.e., the same AS)". This must be > > > clarified in the text below, and the text should be reviewed. > > > > What makes you think that "locally originated" means "local to the routing > > domain" ? > > The text: > > 1) When sending a message to an internal peer, if the route is not > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > attribute, unless it has been explicitly configured to announce > its own IP address as the NEXT_HOP. > > .. because, obviously, you do not _modify_ NEXT_HOP for any routes which > you originate. You _set_ it to be something. Further, you use double > negative in above, so it's pretty difficult to figure out what's the > actual intent there...: > > - if the route is locally originated the BGP speaker ... > a) ? > b) SHOULD modify NEXT_HOP (or something else) ? > - if the route is not locally originated, the BGP speaker SHOULD NOT > modify NEXT_HOP > > So, I'd suggest rewording the start of that paragraph; perhaps e.g.: > > 1) When sending a message to an internal peer, and the route is > not originated by the BGP speaker, the BGP speaker SHOULD keep the > NEXT_HOP attribute intact, unless it has been explicitly configured > to announce its own IP address as the NEXT_HOP. The current text reflects the consensus of the WG (see 2.61 in draft-ietf-idr-bgp-issues-01.txt). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA24329 for ; Tue, 30 Sep 2003 03:12:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Efv-0005ut-Jm; Tue, 30 Sep 2003 03:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EfN-0005uF-Hy for idr@optimus.ietf.org; Tue, 30 Sep 2003 03:11:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10391 for ; Tue, 30 Sep 2003 03:11:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EfJ-00039B-00 for idr@ietf.org; Tue, 30 Sep 2003 03:11:21 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EfI-000396-00 for idr@ietf.org; Tue, 30 Sep 2003 03:11:20 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8U7AnV02216; Tue, 30 Sep 2003 10:10:49 +0300 From: Pekka Savola To: Yakov Rekhter cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309291404.h8TE43j92550@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 10:10:49 +0300 (EEST) Responding to two issues which seem may warrant further discussion from me.. On Mon, 29 Sep 2003, Yakov Rekhter wrote: > > - I got major headache when trying to read the aggregating rules > > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > > rules :-(!!!) and ended up skipping them. > > > > substantial > > ----------- > > > > 1) Section 3 on Summary of the Operations, states: > > > > In the context of this document we assume that a BGP speaker adver- > > tises to its peers only those routes that it itself uses (in this > > context a BGP speaker is said to "use" a BGP route if it is the most > > preferred BGP route and is used in forwarding). All other cases are > > outside the scope of this document. > > > > this "usability" requirement is in conflict with section 4.3 on UPDATE > > message format: > > > > An UPDATE message is used to advertise feasible routes sharing common > > path attributes to a peer, [...] > > > > ==> in particular note that "feasible" is a superset of "only those routes > > the router itself uses" (compare to "those routes the router itself _could_ > > use if they were the most preferred ones"), right? > > > > ==> also note that the former definition is (IMHO) operationally unsound. > > It prevents you from advertising P-t-P addresses and loopbacks (which also > > reside in IGP) using BGP, because the IGP distance is lower than BGP and > > "BGP route is never used in forwarding". (depending on how you interpret > > that). IMHO, this really needs to be changed to be OK. > > The current text reflects consensus reached by the WG. Note that there are two issues here: 1) the text is out-of-sync between sections 3 and 4.3, and 2) that the current definition of BGP route used for forwarding is not really useful. I take it that the comment 1) is still valid. Has 2) -- which you were probably referring to -- been raised as an issue in the spec? Any pointers to the issue, discussion, and the conclusion (the answer to the question "Why did the WG decide this way?") I fail to see why such a conclusion would be justified.. and if the relevant points haven't been raised already, I probably want to re-open that debate. > > 3) there is significant confusion on what "locally originated" means. It is > > not clear whether this refers to "local to the BGP speaker (i.e., the same > > system)" or "local to the routing domain (i.e., the same AS)". This must be > > clarified in the text below, and the text should be reviewed. > > What makes you think that "locally originated" means "local to the routing > domain" ? The text: 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. .. because, obviously, you do not _modify_ NEXT_HOP for any routes which you originate. You _set_ it to be something. Further, you use double negative in above, so it's pretty difficult to figure out what's the actual intent there...: - if the route is locally originated the BGP speaker ... a) ? b) SHOULD modify NEXT_HOP (or something else) ? - if the route is not locally originated, the BGP speaker SHOULD NOT modify NEXT_HOP So, I'd suggest rewording the start of that paragraph; perhaps e.g.: 1) When sending a message to an internal peer, and the route is not originated by the BGP speaker, the BGP speaker SHOULD keep the NEXT_HOP attribute intact, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA23255 for ; Tue, 30 Sep 2003 02:54:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EOX-0004nn-Fk; Tue, 30 Sep 2003 02:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ENr-0004kk-SG for idr@optimus.ietf.org; Tue, 30 Sep 2003 02:53:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09741 for ; Tue, 30 Sep 2003 02:53:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ENn-0002uo-00 for idr@ietf.org; Tue, 30 Sep 2003 02:53:15 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ENn-0002uH-00 for idr@ietf.org; Tue, 30 Sep 2003 02:53:15 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8U6q0K01987; Tue, 30 Sep 2003 09:52:03 +0300 From: Pekka Savola To: Dennis Ferguson cc: "John G. Scudder" , Jeffrey Haas , Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <200309262240.h8QMeBj32605@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Sep 2003 09:52:00 +0300 (EEST) On Fri, 26 Sep 2003, Dennis Ferguson wrote: > > > You are welcome to arrange your internal connectivity however you > > > like. Not everyone agrees. Since as specified, the behavior doesn't > > > affect BGP's correctness it's not a bug in a formal sense. No BGP > > > implementation I'm aware of allows AS loops by default so it's not a > > > bug in an operational sense either. > > > > > > IMO there is no need to make the proposed change to the protocol. > > > > Vendors are also free to implement additional features than those listed > > in the BGP spec. > > > > It is a bug in the specification sense because the spec does not include > > text that you should do loop prevention by discarding the path when it > > contains your own AS. > > The minimal theoretical requirement for loop termination (BGP doesn't > prevent loops which occur transiently, just guarantees they'll eventually > be stopped) is that you should discard the path when it includes your > own AS `N' times, for any `N' you care to choose. While N=1, which you like, > will terminate loops, letting N=2 or N=5 or N=12 will terminate them > just fine as well (though you are wasting convergence time if you make > `N' larger than the number of inter-AS border routers you have, at most). > It hence isn't a bug to allow `N' to be set to a value other than 1 in > any theoretical sense. I wouldn't call such an AS having a coherent routing plan. If you allow AS > 1, you're abusing the term AS. > > Further, there is no need to do anything of this sort if you get default > > routes from the Internet, or set up a backup (highest protocol distance) > > route towards the Internet. > > I'm sure you don't mean that one or the other of those things is always > possible to do. It is when neither of those things is possible that you > might want to set N>1 instead. Can you shown me a couple (or at least _one_) example where other methods are not possible and this is required? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA00246 for ; Mon, 29 Sep 2003 15:38:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qN-0006WW-3l; Mon, 29 Sep 2003 15:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qF-0006UU-G7 for idr@optimus.ietf.org; Mon, 29 Sep 2003 15:37:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06469; Mon, 29 Sep 2003 15:37:47 -0400 (EDT) Message-Id: <200309291937.PAA06469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-21.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 15:37:47 -0400 --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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter et al. Filename : draft-ietf-idr-bgp4-21.txt Pages : 98 Date : 2003-9-29 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-21.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29152924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152924.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org ([132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA00245 for ; Mon, 29 Sep 2003 15:38:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qN-0006Wk-Sg; Mon, 29 Sep 2003 15:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qK-0006Vc-B1 for idr@optimus.ietf.org; Mon, 29 Sep 2003 15:38:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06490; Mon, 29 Sep 2003 15:37:52 -0400 (EDT) Message-Id: <200309291937.PAA06490@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-03.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 15:37:52 -0400 --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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-03.txt Pages : 22 Date : 2003-9-29 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29152934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152934.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24021 for ; Mon, 29 Sep 2003 12:43:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A416y-0003xn-O4; Mon, 29 Sep 2003 12:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A416G-0003x2-5J for idr@optimus.ietf.org; Mon, 29 Sep 2003 12:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27867 for ; Mon, 29 Sep 2003 12:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A416E-0001aY-00 for idr@ietf.org; Mon, 29 Sep 2003 12:42:14 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A416D-0001Zq-00 for idr@ietf.org; Mon, 29 Sep 2003 12:42:14 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8TGfhj02349; Mon, 29 Sep 2003 09:41:43 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309291641.h8TGfhj02349@merlot.juniper.net> To: idr@ietf.org cc: skh@nexthop.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46727.1064853703.1@juniper.net> From: Yakov Rekhter Subject: [Idr] WG Last Call on draft-ietf-idr-bgp4-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 09:41:43 -0700 Folks, This is to start WG Last Call on advancing draft-ietf-idr-bgp4-analysis-04.txt to an Informational RFC. The Last Call ends Oct 13, 2003. Sue & Yakov _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA16432 for ; Mon, 29 Sep 2003 10:05:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ye7-0004Cz-ER; Mon, 29 Sep 2003 10:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ydv-0004CD-5y for idr@optimus.ietf.org; Mon, 29 Sep 2003 10:04:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15794 for ; Mon, 29 Sep 2003 10:04:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yds-0006I4-00 for idr@ietf.org; Mon, 29 Sep 2003 10:04:48 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A3yds-0006HL-00 for idr@ietf.org; Mon, 29 Sep 2003 10:04:48 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8TE43j92550; Mon, 29 Sep 2003 07:04:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309291404.h8TE43j92550@merlot.juniper.net> To: Pekka Savola cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Your message of "Wed, 24 Sep 2003 10:50:26 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <178.1064844243.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Sep 2003 07:04:03 -0700 Pekka, > Hi, > > [note, I'm not subscribed to the idr list] > > Alex solicited ops-dir for folks to review bgp4-20 spec. After almost > half a year, I finally found the time to look at it. Comments below. I > tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at > least on the quick glance, I didn't find major overlaps. I am replying only to the comments that haven't been addressed by other folks who already replied to you. > Overview: > - the spec is in pretty good shape, but I'm not sure if all the features > listed are really full standard material.. it might be better to separate > some of them (e.g. anything relating to aggregation) to a separate doc (so > that we'd have a much tigher and better real base spec), and recycle it at > DS, but that might be much more effort.. not sure if something like that > would be worth it. > > General thoughts on going to full standard: > - If we want to go for full standard, I have to question the usefulness of > several BGP features: At the present moment we are *not* going for full standard - we are going for a draft standard. [clipped..] > As a general observation from the text: > - I skipped section 8 on FSM, as it was really boring, and I'm not sure > whehter it's of any use keeping it in the base spec. Please argue this issue with Routing ADs > - I got major headache when trying to read the aggregating rules > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > rules :-(!!!) and ended up skipping them. > > substantial > ----------- > > 1) Section 3 on Summary of the Operations, states: > > In the context of this document we assume that a BGP speaker adver- > tises to its peers only those routes that it itself uses (in this > context a BGP speaker is said to "use" a BGP route if it is the most > preferred BGP route and is used in forwarding). All other cases are > outside the scope of this document. > > this "usability" requirement is in conflict with section 4.3 on UPDATE > message format: > > An UPDATE message is used to advertise feasible routes sharing common > path attributes to a peer, [...] > > ==> in particular note that "feasible" is a superset of "only those routes > the router itself uses" (compare to "those routes the router itself _could_ > use if they were the most preferred ones"), right? > > ==> also note that the former definition is (IMHO) operationally unsound. > It prevents you from advertising P-t-P addresses and loopbacks (which also > reside in IGP) using BGP, because the IGP distance is lower than BGP and > "BGP route is never used in forwarding". (depending on how you interpret > that). IMHO, this really needs to be changed to be OK. The current text reflects consensus reached by the WG. > 2) The OPEN message format is confusing. Why on earth do you have those > empty bits there? Are they null-padding or just a typographical convention > for the clarity of the diagram (the latter)? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | My Autonomous System | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hold Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BGP Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opt Parm Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Optional Parameters (variable) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ==> I strongly recommend to either: > 1) go back to standard format, or > 2) rephrase the message format similar with UPDATE messages, i.e., drop all > the pretense about field lengths, bits 0-31, etc. This is an editorial comment, and will be handled at the discretion of the editors. > 3) there is significant confusion on what "locally originated" means. It is > not clear whether this refers to "local to the BGP speaker (i.e., the same > system)" or "local to the routing domain (i.e., the same AS)". This must be > clarified in the text below, and the text should be reviewed. What makes you think that "locally originated" means "local to the routing domain" ? [clipped...] > 6) references; note that as the Security Consideration section is a bit > short, the vulnerability analysis should be a *NORMATIVE* reference. > However, one must ask here and with RFC2385 as well whether normative > references are OK from Full Standard to a lower maturity level. Unless > this has already been investigated, it may be worth checking with the ADs > that this is OK. I would leave it up to ADs to decide on this. > > BGP vulnerabilities analysis is discussed in [XXX]. > > Normative References > > [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 > Signature Option", RFC2385, August 1998. > > Non-normative References > > [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- > ietf-idr-bgp-vuln-00.txt, work in progress > > > semi-substantial > ---------------- The rest of the comments are editorial, and will be handled at the discretion of the editors. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27716 for ; Sat, 27 Sep 2003 12:26:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3HtR-0002TL-VG; Sat, 27 Sep 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3HtI-0002SW-V7 for idr@optimus.ietf.org; Sat, 27 Sep 2003 12:25:52 -0400 Received: from pc6 (111.Red-80-35-167.pooles.rima-tde.net [80.35.167.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05402 for ; Sat, 27 Sep 2003 12:25:41 -0400 (EDT) From: santaluciaseguros@survivormail.com Message-Id: <200309271625.MAA05402@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: santaluciaseguros@survivormail.com X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] AWARD NOTIFICATION Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 27 Sep 2003 18:25:44 +0200 EL GORDO LAPRIMITIVA C/GUZMAN EL BUENO,137 MADRID - ESPAÑA TEL: +34-660 651 909 FAX:+34 645 440 201 E-mail: elgordo_laprimitiva@yahoo.es FROM: OFFICE OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/03 BATCH: 24/00319/IPD RE: AWARD NOTIFICATION FINAL NOTICE We are pleased to inform you of the release of the ELGORDO LAPRIMITIVA LOTTERY/INTERNATIONAL PROGRAMS held on the 20th of September,2003.Your email address attached to ticket number 025- 1146-4992-750 with serial number 2113-05 drew the lucky numbers 3-18-19-30-32-39, which consequently won the lottery in the 3rd category. You are therefore been approved for the lump sum pay out of €uros 847,828.87 (Eight hundred and fourty seven thousand eight hundred and eighty two .eighty seven cents.) in cash credited to file REF: LP/26510460037/03. This is from a total prize of €uros 10,500,000.00 shared among the seventeen (17) International winners in this category. CONGRATULATIONS!!!!!!!!!!!!!!!!!!!!!. Your fund is now deposited with SANTA LUCIA SEGUROS but due to mix up of some numbers and addresses, we ask that you keep this award a top secret from the public notice until your claim has been processed and your prize money remitted to your account as this is part of our Security protocol to avoid double claiming by participants of this programme. All participants were selected through a computer ballot system drawn from 30,000 addresses from Australia, USA, Europe, Asia ,New Zealand, Middle-East,South-North America and Africa as part of our international promotions program which is conducted annually. We hope with a part of your prize money, you will participate in our end of the year high stakes of €uros 300.000.000.00 Million International Lottery. To being your claim, please contact the claim agent Mr David Manuel, (Foreign Service Manager) for processing and remittance of your prize money to any designated account of your choice.Please call on this # Tel:+34686358621.Email:santaluciaseguros@survivormail.com Please note that all prize money must be claimed before the 20th of October, 2003. After this date, all funds will be returned as unclaimed. Note: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every of your correspondence with your agent. Furthermore, should there be any change of address,do inform your claims agent as soon as possible. Please remember to ask for your prize claim certificate. Congratulations again from all members of our staff. Best regards, MARIA JOSE SANCHEZ. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12701 for ; Fri, 26 Sep 2003 18:42:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A31Hk-0006mA-SO; Fri, 26 Sep 2003 18:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A31Gs-0006lM-Dd for idr@optimus.ietf.org; Fri, 26 Sep 2003 18:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27862 for ; Fri, 26 Sep 2003 18:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A31Gp-0006ie-00 for idr@ietf.org; Fri, 26 Sep 2003 18:41:03 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A31Go-0006iT-00 for idr@ietf.org; Fri, 26 Sep 2003 18:41:02 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8QMeBj32605; Fri, 26 Sep 2003 15:40:12 -0700 (PDT) (envelope-from dennis@juniper.net) Message-Id: <200309262240.h8QMeBj32605@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: lists/idr To: Pekka Savola cc: "John G. Scudder" , Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-reply-to: Your message of "Fri, 26 Sep 2003 12:44:01 +0300." Mime-Version: 1.0 Content-Type: text/plain From: Dennis Ferguson Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Sep 2003 15:40:11 -0700 > > You are welcome to arrange your internal connectivity however you > > like. Not everyone agrees. Since as specified, the behavior doesn't > > affect BGP's correctness it's not a bug in a formal sense. No BGP > > implementation I'm aware of allows AS loops by default so it's not a > > bug in an operational sense either. > > > > IMO there is no need to make the proposed change to the protocol. > > Vendors are also free to implement additional features than those listed > in the BGP spec. > > It is a bug in the specification sense because the spec does not include > text that you should do loop prevention by discarding the path when it > contains your own AS. The minimal theoretical requirement for loop termination (BGP doesn't prevent loops which occur transiently, just guarantees they'll eventually be stopped) is that you should discard the path when it includes your own AS `N' times, for any `N' you care to choose. While N=1, which you like, will terminate loops, letting N=2 or N=5 or N=12 will terminate them just fine as well (though you are wasting convergence time if you make `N' larger than the number of inter-AS border routers you have, at most). It hence isn't a bug to allow `N' to be set to a value other than 1 in any theoretical sense. > Further, there is no need to do anything of this sort if you get default > routes from the Internet, or set up a backup (highest protocol distance) > route towards the Internet. I'm sure you don't mean that one or the other of those things is always possible to do. It is when neither of those things is possible that you might want to set N>1 instead. Dennis Ferguson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA02018 for ; Fri, 26 Sep 2003 05:45:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2p9q-0001wa-B7; Fri, 26 Sep 2003 05:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2p9m-0001wD-TE for idr@optimus.ietf.org; Fri, 26 Sep 2003 05:44:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27909 for ; Fri, 26 Sep 2003 05:44:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2p9j-0006L3-00 for idr@ietf.org; Fri, 26 Sep 2003 05:44:55 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2p9i-0006Kl-00 for idr@ietf.org; Fri, 26 Sep 2003 05:44:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8Q9i2A24654; Fri, 26 Sep 2003 12:44:02 +0300 From: Pekka Savola To: "John G. Scudder" cc: Jeffrey Haas , Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Sep 2003 12:44:01 +0300 (EEST) On Thu, 25 Sep 2003, John G. Scudder wrote: > At 7:26 PM +0300 9/25/03, Pekka Savola wrote: > >"auto-summary" (in Cisco terms) has bitten us a couple of times. It's > >automatic. But then again, I may be misremembering something (and I'm > >not 100% sure auto-summary is directly related to aggregation, but the > >concept is similar). > > > >The problem with aggregation I see is that more often than not it does > >nothing to reduce the number of advertisements (or anything useful for > >that matter). ISPs let through the more specifics in addition to the > >aggregate (seems to be the default config too). How is this useful? I'm > >having trouble figuring out real applicability for aggregation. > > The BGP spec doesn't talk about auto-anything. In the interests of > moving the conversation forward, it would help if you cited specific > language in the spec that you object to pertaining to aggregation. Most of sections 4.3 g), 5.1.7, and 9.2.2.2. > > > Consider this rather simplified example: > > > > > > ........ ........ > >> : : : : > >> : AS 1 :---: AS 1 : > > > :......: :......: > > > \ / > >> \ / > > > ( ) > >> ( Internet ) > >> ( ) > > > > > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS > >> with a single point of failure between two portions of itself. > >> In the case of failure of the link, it is possible to maintain > >> internal reachability via the Internet by allowing the Internet > >> Border Routers to ignore a looped condition. > >> > >> This is *not* a normal circumstance, this is highly abnormal. > >> However, it can be darned handy. > > > >This is a bug, not feature. Your internal connectivity just *isn't* meant > >to be routed through the Internet. > > You are welcome to arrange your internal connectivity however you > like. Not everyone agrees. Since as specified, the behavior doesn't > affect BGP's correctness it's not a bug in a formal sense. No BGP > implementation I'm aware of allows AS loops by default so it's not a > bug in an operational sense either. > > IMO there is no need to make the proposed change to the protocol. Vendors are also free to implement additional features than those listed in the BGP spec. It is a bug in the specification sense because the spec does not include text that you should do loop prevention by discarding the path when it contains your own AS. Further, there is no need to do anything of this sort if you get default routes from the Internet, or set up a backup (highest protocol distance) route towards the Internet. But this is just one little issue, compared to some others. If no one else feels this is something that shouldn't be in the spec, feel free to ignore the argument. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26681 for ; Thu, 25 Sep 2003 12:45:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZEk-00058d-44; Thu, 25 Sep 2003 12:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZEG-00057g-AH for idr@optimus.ietf.org; Thu, 25 Sep 2003 12:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04680 for ; Thu, 25 Sep 2003 12:44:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEE-0001Fk-00 for idr@ietf.org; Thu, 25 Sep 2003 12:44:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2ZEE-0001EK-00 for idr@ietf.org; Thu, 25 Sep 2003 12:44:30 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8PGhvwn029193; Thu, 25 Sep 2003 09:43:58 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA16359; Thu, 25 Sep 2003 12:43:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Pekka Savola From: "John G. Scudder" Subject: Re: [Idr] comments on idr-bgp4-20 Cc: Jeffrey Haas , idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 12:43:26 -0400 At 7:26 PM +0300 9/25/03, Pekka Savola wrote: >"auto-summary" (in Cisco terms) has bitten us a couple of times. It's >automatic. But then again, I may be misremembering something (and I'm >not 100% sure auto-summary is directly related to aggregation, but the >concept is similar). > >The problem with aggregation I see is that more often than not it does >nothing to reduce the number of advertisements (or anything useful for >that matter). ISPs let through the more specifics in addition to the >aggregate (seems to be the default config too). How is this useful? I'm >having trouble figuring out real applicability for aggregation. The BGP spec doesn't talk about auto-anything. In the interests of moving the conversation forward, it would help if you cited specific language in the spec that you object to pertaining to aggregation. > > Consider this rather simplified example: > > > > ........ ........ >> : : : : >> : AS 1 :---: AS 1 : > > :......: :......: > > \ / >> \ / > > ( ) >> ( Internet ) >> ( ) > > > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS >> with a single point of failure between two portions of itself. >> In the case of failure of the link, it is possible to maintain >> internal reachability via the Internet by allowing the Internet >> Border Routers to ignore a looped condition. >> >> This is *not* a normal circumstance, this is highly abnormal. >> However, it can be darned handy. > >This is a bug, not feature. Your internal connectivity just *isn't* meant >to be routed through the Internet. You are welcome to arrange your internal connectivity however you like. Not everyone agrees. Since as specified, the behavior doesn't affect BGP's correctness it's not a bug in a formal sense. No BGP implementation I'm aware of allows AS loops by default so it's not a bug in an operational sense either. IMO there is no need to make the proposed change to the protocol. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26120 for ; Thu, 25 Sep 2003 12:28:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YyH-000489-AF; Thu, 25 Sep 2003 12:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Yxf-00046J-6g for idr@optimus.ietf.org; Thu, 25 Sep 2003 12:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03571 for ; Thu, 25 Sep 2003 12:27:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yxd-0000tY-00 for idr@ietf.org; Thu, 25 Sep 2003 12:27:21 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yxc-0000tF-00 for idr@ietf.org; Thu, 25 Sep 2003 12:27:20 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8PGQft08409; Thu, 25 Sep 2003 19:26:42 +0300 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: <20030925111310.A14433@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 19:26:40 +0300 (EEST) On Thu, 25 Sep 2003, Jeffrey Haas wrote: > On Thu, Sep 25, 2003 at 10:31:20AM +0300, Pekka Savola wrote: > > See above, in my first comment. Automatic route aggregation *in the > > protocol* (instead of *operationally*) is a very, very questionable > > concept. Something we could very well live without... > > Perhaps I am not seeing the same thing, but what "automatic" route > aggregation? Every implementation I've worked with requires > explicit configuration. The aggregation rules in the spec say what > to do when you do this. "auto-summary" (in Cisco terms) has bitten us a couple of times. It's automatic. But then again, I may be misremembering something (and I'm not 100% sure auto-summary is directly related to aggregation, but the concept is similar). The problem with aggregation I see is that more often than not it does nothing to reduce the number of advertisements (or anything useful for that matter). ISPs let through the more specifics in addition to the aggregate (seems to be the default config too). How is this useful? I'm having trouble figuring out real applicability for aggregation. > > What I say that those scenarios could be moved to a separate spec, and > > accepting third-party nexthops might not be necessary for those who want > > plain next-hop behaviour only. The code will probably stay as is for some > > time at least. > > First-party nexthops introduce sub-optimal routing. Why would we want > to introduce mandatory first party nexthops and optional third-party? Note, I'm discussing third-party nexthops in EBGP only (I'm not sure if I mentioned this explicitly, or if there's a need to). Why would you need the optimal routing w/ third-party next-hops and EBGP? You can just go through the BGP speaker, period. (In case if you pass through an Internet Exchange more than once.) > > The whole point of the AS is that it's not partitioned. I don't think > > this is needed, or useful at all. > > Consider this rather simplified example: > > ........ ........ > : : : : > : AS 1 :---: AS 1 : > :......: :......: > \ / > \ / > ( ) > ( Internet ) > ( ) > > AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS > with a single point of failure between two portions of itself. > In the case of failure of the link, it is possible to maintain > internal reachability via the Internet by allowing the Internet > Border Routers to ignore a looped condition. > > This is *not* a normal circumstance, this is highly abnormal. > However, it can be darned handy. This is a bug, not feature. Your internal connectivity just *isn't* meant to be routed through the Internet. > Other mechanisms such as tunneling between the pieces of the > partitioned AS have been done as well. Right! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA23620 for ; Thu, 25 Sep 2003 11:15:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xpd-0007UY-Uh; Thu, 25 Sep 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Xof-0007Ax-I1 for idr@optimus.ietf.org; Thu, 25 Sep 2003 11:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29647 for ; Thu, 25 Sep 2003 11:13:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Xoe-0007Tl-00 for idr@ietf.org; Thu, 25 Sep 2003 11:14:00 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Xoe-0007Sa-00 for idr@ietf.org; Thu, 25 Sep 2003 11:14:00 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8PFDOS2085829; Thu, 25 Sep 2003 11:13:24 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8PFDFOT085822; Thu, 25 Sep 2003 11:13:15 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8PFDAR14455; Thu, 25 Sep 2003 11:13:10 -0400 (EDT) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 Message-ID: <20030925111310.A14433@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Thu, Sep 25, 2003 at 10:31:20AM +0300 X-Virus-Scanned: by AMaViS perl-11 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 11:13:10 -0400 On Thu, Sep 25, 2003 at 10:31:20AM +0300, Pekka Savola wrote: > See above, in my first comment. Automatic route aggregation *in the > protocol* (instead of *operationally*) is a very, very questionable > concept. Something we could very well live without... Perhaps I am not seeing the same thing, but what "automatic" route aggregation? Every implementation I've worked with requires explicit configuration. The aggregation rules in the spec say what to do when you do this. > > What I say that those scenarios could be moved to a separate spec, and > accepting third-party nexthops might not be necessary for those who want > plain next-hop behaviour only. The code will probably stay as is for some > time at least. First-party nexthops introduce sub-optimal routing. Why would we want to introduce mandatory first party nexthops and optional third-party? > The whole point of the AS is that it's not partitioned. I don't think > this is needed, or useful at all. Consider this rather simplified example: ........ ........ : : : : : AS 1 :---: AS 1 : :......: :......: \ / \ / ( ) ( Internet ) ( ) AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS with a single point of failure between two portions of itself. In the case of failure of the link, it is possible to maintain internal reachability via the Internet by allowing the Internet Border Routers to ignore a looped condition. This is *not* a normal circumstance, this is highly abnormal. However, it can be darned handy. Other mechanisms such as tunneling between the pieces of the partitioned AS have been done as well. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA07987 for ; Thu, 25 Sep 2003 03:33:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2QcX-0004JQ-P7; Thu, 25 Sep 2003 03:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Qba-0004IO-7l for idr@optimus.ietf.org; Thu, 25 Sep 2003 03:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11580 for ; Thu, 25 Sep 2003 03:31:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2QbX-0001uE-00 for idr@ietf.org; Thu, 25 Sep 2003 03:31:59 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2QbX-0001tw-00 for idr@ietf.org; Thu, 25 Sep 2003 03:31:59 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8P7VKe31620; Thu, 25 Sep 2003 10:31:20 +0300 From: Pekka Savola To: "John G. Scudder" cc: idr@ietf.org Subject: Re: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 10:31:20 +0300 (EEST) On Wed, 24 Sep 2003, John G. Scudder wrote: > At 10:50 AM +0300 9/24/03, Pekka Savola wrote: > >General thoughts on going to full standard: > > The process the IDR group has been following so far is to try to > document the existing protocol rather than to tweak it. In your > first few comments you seem to be suggesting that the protocol as > currently deployed isn't suitable for full standard and should be > tweaked. Is that what you meant to say? Yes. And moreover, there are certain aspects of the protocol which we may now consider pretty obsolete. Consider that we'd like to deprecate them in 3 years. Doing that from inside Full Standard could be painful -- in practice, to avoid the confusion, the spec should be re-issued. However, if they are in separate portions it would be easier. What I'm trying to say is that the current base spec is very relevant for most parts, and likely continue to be so. However, I see several parts (esp. relating to aggregation) which are no longer relevant, may get to be even more irrelevant, and may even turn out to be dangerous or harmful later on (considering sBGP/soBGP, for example). To me, it would seem to be useful to be "proactive" before going to full standard, and take out those parts which we think do not have long-term usefullness as a full standard. > > - If we want to go for full standard, I have to question the usefulness of > >several BGP features: > > - AS_SET AS_PATH attribute > > I can imagine why you think this; however, given that AS_SET is > already part of presumably all BGP implementations, I can't think of > a reason to remove it. On the other hand, I can think of various > reasons to keep it, including but not limited to "if it ain't broke, > don't fix it." There are tradeoffs both ways, that's for sure. I don't have a really strong opinion on this. > > - whole route aggregation concept (nowadays, it seems to be causing > >more trouble than it's worth -- instead of proper advertisements, just > >automatically aggregate instead of fixing the advertisements to begin > >with). Maybe pver 10 years ago it may have been relevant if all the edge > >BGP routers might not support BGP-4 or CIDR.. > > I honestly don't understand the point you're trying to make here. See above, in my first comment. Automatic route aggregation *in the protocol* (instead of *operationally*) is a very, very questionable concept. Something we could very well live without... > > - about N++ different cases of third-party nexthop usage. > > Are you suggesting that third-party nexthop should be removed from > the spec (and from implementations)? If so, I think more > justification will be needed. What I say that those scenarios could be moved to a separate spec, and accepting third-party nexthops might not be necessary for those who want plain next-hop behaviour only. The code will probably stay as is for some time at least. > >4) there appears to have been added some bogosities about inter-AS traffic > >engineering in section 9.3: > > > > - If the local AS appears in the AS path of the new route being > > considered, then that new route can not be viewed as better than > > any other route (provided that the speaker is configured to accept > > such routes). If such a route were ever used, a routing loop could > > result. > > [...] > > > >==> what do these have to do with base spec? I don't think they're > >operationally feasible or used. Remove any indication that it's OK to > >receive your own AS in the routes you receive!! > > I beg to differ. The former is not common practice but is not > unknown either (it's historically there to allow a partitioned AS to > be healed through an external path). The whole point of the AS is that it's not partitioned. I don't think this is needed, or useful at all. > The latter (AS Path padding) is > incredibly common. The text should be left as is, except that I > wouldn't object to the removal of the clause "for the purpose of > inter-AS traffic engineering." Sorry, I misread the comment (removed from above in clarity). Prepending your own AS is perfectly fine to me. > > attribute needs to be cognizant of the fact that the actual path to > > > >==> s/cognizant/aware/ > > Why? Why use complex words when simpler ones suit just as well? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA03049 for ; Thu, 25 Sep 2003 01:10:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2OO9-000339-Hg; Thu, 25 Sep 2003 01:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ONc-00032g-BB for idr@optimus.ietf.org; Thu, 25 Sep 2003 01:09:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24903 for ; Thu, 25 Sep 2003 01:09:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ONY-0000LD-00 for idr@ietf.org; Thu, 25 Sep 2003 01:09:24 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ONX-0000L6-00 for idr@ietf.org; Thu, 25 Sep 2003 01:09:23 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8P58gL30140; Thu, 25 Sep 2003 08:08:43 +0300 From: Pekka Savola To: Susan Hares cc: idr@ietf.org Subject: RE: [Idr] comments on idr-bgp4-20 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Sep 2003 08:08:42 +0300 (EEST) On Wed, 24 Sep 2003, Susan Hares wrote: > For context on the message, could you > tell me are you: > > 2) Operator using BGP Operator. > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, September 24, 2003 3:50 AM > To: idr@ietf.org > Subject: [Idr] comments on idr-bgp4-20 > > > Hi, > > [note, I'm not subscribed to the idr list] > > Alex solicited ops-dir for folks to review bgp4-20 spec. After almost > half a year, I finally found the time to look at it. Comments below. I > tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at > least on the quick glance, I didn't find major overlaps. > > Overview: > - the spec is in pretty good shape, but I'm not sure if all the features > listed are really full standard material.. it might be better to separate > some of them (e.g. anything relating to aggregation) to a separate doc (so > that we'd have a much tigher and better real base spec), and recycle it at > DS, but that might be much more effort.. not sure if something like that > would be worth it. > > General thoughts on going to full standard: > - If we want to go for full standard, I have to question the usefulness of > several BGP features: > - AS_SET AS_PATH attribute > - whole route aggregation concept (nowadays, it seems to be causing > more trouble than it's worth -- instead of proper advertisements, just > automatically aggregate instead of fixing the advertisements to begin > with). Maybe pver 10 years ago it may have been relevant if all the edge > BGP routers might not support BGP-4 or CIDR.. > - about N++ different cases of third-party nexthop usage. > > As a general observation from the text: > - I skipped section 8 on FSM, as it was really boring, and I'm not sure > whehter it's of any use keeping it in the base spec. > - I got major headache when trying to read the aggregating rules > especially in section 9.2.2.2 (and that was supposed to be the _simple_ > rules :-(!!!) and ended up skipping them. > > substantial > ----------- > > 1) Section 3 on Summary of the Operations, states: > > In the context of this document we assume that a BGP speaker adver- > tises to its peers only those routes that it itself uses (in this > context a BGP speaker is said to "use" a BGP route if it is the most > preferred BGP route and is used in forwarding). All other cases are > outside the scope of this document. > > this "usability" requirement is in conflict with section 4.3 on UPDATE > message format: > > An UPDATE message is used to advertise feasible routes sharing common > path attributes to a peer, [...] > > ==> in particular note that "feasible" is a superset of "only those routes > the router itself uses" (compare to "those routes the router itself _could_ > use if they were the most preferred ones"), right? > > ==> also note that the former definition is (IMHO) operationally unsound. > It prevents you from advertising P-t-P addresses and loopbacks (which also > reside in IGP) using BGP, because the IGP distance is lower than BGP and > "BGP route is never used in forwarding". (depending on how you interpret > that). IMHO, this really needs to be changed to be OK. > > 2) The OPEN message format is confusing. Why on earth do you have those > empty bits there? Are they null-padding or just a typographical convention > for the clarity of the diagram (the latter)? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | My Autonomous System | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hold Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BGP Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opt Parm Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Optional Parameters (variable) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ==> I strongly recommend to either: > 1) go back to standard format, or > 2) rephrase the message format similar with UPDATE messages, i.e., drop all > the pretense about field lengths, bits 0-31, etc. > > 3) there is significant confusion on what "locally originated" means. It is > not clear whether this refers to "local to the BGP speaker (i.e., the same > system)" or "local to the routing domain (i.e., the same AS)". This must be > clarified in the text below, and the text should be reviewed. > > 5.1.3 NEXT_HOP > > The NEXT_HOP is a well-known mandatory attribute that defines the IP > address of the router that SHOULD be used as the next hop to the des- > tinations listed in the UPDATE message. The NEXT_HOP attribute is > calculated as follows. > > 1) When sending a message to an internal peer, if the route is not > locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP > attribute, unless it has been explicitly configured to announce > its own IP address as the NEXT_HOP. When announcing a locally > originated route to an internal peer, the BGP speaker SHOULD use > as the NEXT_HOP the interface address of the router through which > the announced network is reachable for the speaker; if the route > is directly connected to the speaker, or the interface address of > the router through which the announced network is reachable for > the speaker is the internal peer's address, then the BGP speaker > SHOULD use for the NEXT_HOP attribute its own IP address (the > address of the interface that is used to reach the peer). > > 4) there appears to have been added some bogosities about inter-AS traffic > engineering in section 9.3: > > - If the local AS appears in the AS path of the new route being > considered, then that new route can not be viewed as better than > any other route (provided that the speaker is configured to accept > such routes). If such a route were ever used, a routing loop could > result. > > and: > > The ability of a BGP speaker to include more than one instance of > its own AS in the AS_PATH attribute for the purpose of inter-AS > traffic engineering. > > ==> what do these have to do with base spec? I don't think they're > operationally feasible or used. Remove any indication that it's OK to > receive your own AS in the routes you receive!! > > 5) the reasoning for this section is not clear. It seems to be two parts > (the second one starting at "These routes..."). It seems partially, at > least for the second part, a set of operational guidelines.. which probably > don't have anything to do with the BGP spec! > > 9.4 Originating BGP routes > > A BGP speaker may originate BGP routes by injecting routing informa- > tion acquired by some other means (e.g. via an IGP) into BGP. A BGP > speaker that originates BGP routes assigns the degree of preference > to these routes by passing them through the Decision Process (see > Section 9.1). These routes MAY also be distributed to other BGP > speakers within the local AS as part of the update process (see Sec- > tion 9.2). The decision whether to distribute non-BGP acquired routes > within an AS via BGP or not depends on the environment within the AS > (e.g. type of IGP) and SHOULD be controlled via configuration. > > 6) references; note that as the Security Consideration section is a bit > short, the vulnerability analysis should be a *NORMATIVE* reference. > However, one must ask here and with RFC2385 as well whether normative > references are OK from Full Standard to a lower maturity level. Unless > this has already been investigated, it may be worth checking with the ADs > that this is OK. > > BGP vulnerabilities analysis is discussed in [XXX]. > > Normative References > > [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 > Signature Option", RFC2385, August 1998. > > Non-normative References > > [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- > ietf-idr-bgp-vuln-00.txt, work in progress > > > semi-substantial > ---------------- > > ==> I'd add "Decision Process", "Routing Table", and "BGP route" in the > terminology. (Especially the last one is a bit shady, see more comments > later.) > > Adj-RIB-In > Adj-RIBs-In > Adj-RIB-Out > Adj-RIBs-Out > > ==> in some places, one seems to use "Adj-RIBs-{In,Out}", in some others, > "Adj-RIB-{In,Out}". The plural/singular form should be consistent. > > BGP speaker > A router that implements BGP. > > ==> uhh, no. Throughout the text "BGP speaker" is used to refer to > BGP-*enabled* routers. Implementation is a required but not sufficient > condition to that. Consider rewording to something like: > > BGP speaker > A router that implements and has been configured to use BGP. > > .... > > BGP Identifier: > > This 4-octet unsigned integer indicates the BGP Identifier of > the sender. A given BGP speaker sets the value of its BGP Iden- > tifier to an IP address assigned to that BGP speaker. The > value of the BGP Identifier is determined on startup and is the > same for every local interface and every BGP peer. > > ==> the last sentence is confusing "same for every local interface".. yeah, > right, but interfaces are irrelevant here. Also, this ignores the fact > that it's perfectly legal to change BGP identifiers after startup but prior > to establishing a BGP session. Consider rewording to something > like: > > This 4-octet unsigned integer indicates the BGP Identifier of > the sender. A given BGP speaker sets the value of its BGP Iden- > tifier to an IP address assigned to that BGP speaker. The > value of the BGP Identifier is determined prior to establishing > BGP sessions and is the same for every session the BGP speaker. > > ... > > Path Attributes: > > A variable length sequence of path attributes is present in > every UPDATE message, except for an UPDATE message that carries > only the withdrawn routes. Each path attribute is a triple > of variable > length. > > ==> should a simple diagram be added here, just like in section 4.2? > > The high-order bit (bit 0) of the Attribute Flags octet is the > Optional bit. It defines whether the attribute is optional (if > set to 1) or well-known (if set to 0). > > ==> this and the following descriptions on attributes are out of place if > you have not described the remaining categories (because they're used when > describing the attributes in the next page), that is, discretionary and > mandatory. Consider rewording the above to something like: > > The high-order bit (bit 0) of the Attribute Flags octet is the > Optional bit. It defines whether the attribute is optional (if > set to 1) or well-known (if set to 0). Well-known attributes can > be either mandatory (MUST be included in every UPDATE message that > contains NLRI), or discretionary (inclusion not required). > > ... > > All well-known attributes MUST be passed along (after proper updat- > ing, if necessary) to other BGP peers. > > ==> LOCAL-PREF is an exception here. I also note that the BGP's definition > of "transitive" is different ("unrecognized optional attributes are only > passed onward when the transitive bit is set, but recognized optional > attributes are always passed onward") from the apparent language ("always passed > along"), and might use a bit of clarification. > > ... > > b) When a given BGP speaker advertises the route to an external > peer, then the advertising speaker updates the AS_PATH attribute > as follows: > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position). > If the act of prepending will cause an overflow in the AS_PATH > segment, i.e. more than 255 ASs, it is legal to prepend a new > segment of type AS_SEQUENCE and prepend its own AS number to > this new segment. > > 2) if the first path segment of the AS_PATH is of type AS_SET, > the local system prepends a new path segment of type > AS_SEQUENCE to the AS_PATH, including its own AS number in that > segment. > > ==> the text here seems confusing because it is not clear whether things are > added at the beginning or at the end of the segments, for example: > > "the _last_ element sequence (put it in the _leftmost_ position)" > > .. I think this requires more precise language on which end of the segment > these values are really inserted. I.e., is it "physically" (in memory) > left-to-right (from more recent to more distant), or just interpreted that > way? This has significant impact on the last sentence of section 1) in case > of overflows and the like. > > Whenever the modification of the AS_PATH attribute calls for includ- > ing or prepending the AS number of the local system, the local system > MAY include/prepend more than one instance of its own AS number in > the AS_PATH attribute. This is controlled via local configuration. > > ==> what about prepending/adding someone else's AS? Is this relevant enough > to be considered? > > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > attribute MUST NOT make any NLRI of that route more specific (as > defined in 9.1.4) when advertising this route to other BGP speakers. > > ==> the second line seems out-of-place here. I assume it means that the > router must not perform automatic de-aggregation, not that the router must > not have more specific routes to advertise. In any case, a rewording might > be in order, e.g. like: > > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that is, > generating more specifics by de-aggregating a route is forbidden. > > (note that this actually makes the statement stronger, and more in line of > 9.1.4, that you should not do it even locally.) > > If the Length field of the message header is less than 19 or greater > than 4096, or if the Length field of an OPEN message is less than the > minimum length of the OPEN message, or if the Length field of an > UPDATE message is less than the minimum length of the UPDATE message, > or if the Length field of a KEEPALIVE message is not equal to 19, or > if the Length field of a NOTIFICATION message is less than the mini- > mum length of the NOTIFICATION message, then the Error Subcode is set > to Bad Message Length. The Data field contains the erroneous Length > field. > > ==> convert this to a bulleted list or something, so it's easier to read, > please! :-) > > The IP address in the NEXT_HOP MUST meet the following criteria to be > considered semantically correct: > > a) It MUST NOT be the IP address of the receiving speaker > > b) In the case of an EBGP where the sender and receiver are one IP > hop away from each other, either the IP address in the NEXT_HOP > MUST be the sender's IP address (that is used to establish the BGP > connection), or the interface associated with the NEXT_HOP IP > address MUST share a common subnet with the receiving BGP speaker. > > > ==> what's exactly the case for the first case of b)? Couldn't thid be > cleaned a bit (it seems to me that the second case is a superset of the > first)? In addition, I'd recommend rewording "one IP hop away" -- > that begs the question whether you mean "direct neighbors" or "just one > transit router". When thinking of it more, the former seems apparent, but a > different wording might flesh this out better. > > If a BGP speaker chooses to aggregate, then it SHOULD either include > all AS used to form the aggreagate in an AS_SET or add the > ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- > marily informational. With the elimination of IP routing protocols > that do not support classless routing and the elimination of router > and host implementations that do not support classless routing, there > is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- > gated. A route that carries ATOMIC_AGGREGATE attribute in particular > MUST NOT be de-aggregated. That is, the NLRI of this route can not be > made more specific. Forwarding along such a route does not guarantee > that IP packets will actually traverse only ASs listed in the AS_PATH > attribute of the route. > > ==> this is confusing, especially the end, beginning from "That is, ..." and > should be reworded a bit (does it cover only deaggregation or more specifics > in general?), like: > > If a BGP speaker chooses to aggregate, then it SHOULD either include > all AS used to form the aggreagate in an AS_SET or add the > ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- > marily informational. With the elimination of IP routing protocols > that do not support classless routing and the elimination of router > and host implementations that do not support classless routing, there > is no longer a need to deaggregate. > > Routes SHOULD NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE > attribute in particular MUST NOT be de-aggregated. That is, one must not > generate more specifics of the NLRI of this route. Forwarding along > such a route does not guarantee > that IP packets will actually traverse only ASs listed in the AS_PATH > attribute of the route. However, accepting more specific advertisments > which an aggregate route covers is acceptable. > > ... > > A BGP speaker SHOULD NOT advertise a given feasible BGP route from > its Adj-RIB-Out if it would produce an UPDATE message containing the > same BGP route as was previously advertised. > > ==> and now we get back to the definition of "same BGP route"? Identical prefix > carried over BGP? Identical prefix carried over BGP with identical attributes?" > I'm assuming the former, otherwise (at least!) the above should be > clarified. > > Aggregation reduces the amount of information that a BGP speaker must > store and exchange with other BGP speakers. Routes can be aggregated > by applying the following procedure separately to path attributes of > like type and to the Network Layer Reachability Information. > > ==> the last line sounds really weird; consider: > - s/like/the same/ ? > - add more text after the NLRI, like "NLRI field" ? > > > > typos or other editorials > ------------------------- > > ==> there should not be hyphenation at the linebreaks. > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > ==> s/extention/extension/ (two places) > > 3.2 Routing Information Bases > > The Routing Information Base (RIB) within a BGP speaker consists of > three distinct parts: > > ==> the subject is in plural form ("RIBs"), but the text begins as singular > ("The RIB"). Consider which one to use? > > a) ORIGIN (Type Code 1): > > b) AS_PATH (Type Code 2): > > ==> kill the extra spaces before ORIGIN and NEXT_HOP. > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position). > > ==> rewrite the last one as: > last element of the sequence, putting it in the leftmost position. > > A BGP speaker MUST IMPLEMENT a mechanism based on local configuration > > ==> s/IMPLEMENT/implement/ > > used by a BGP speaker's decision process to discriminate > > ==> s/decision process/Decision Process/ (similar in a few other places?) > > attribute needs to be cognizant of the fact that the actual path to > > ==> s/cognizant/aware/ > > 6. BGP Error Handling. > > ==> remove the periods from at the end of section titles, esp. in subctions > of section 6. > > issue a open collision dump [Event 23]. When the local > system receives a open collision dump event [Event 23], the > > ==> s/a open/an open/ (two times) > > installed in LocRib and will be excluded from the next phase of route > > ==> s/LocRib/Loc-RIB/ > > all AS used to form the aggreagate in an AS_SET or add the > > ==> s/aggreagate/aggregate/ > > is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- > gated. A route that carries ATOMIC_AGGREGATE attribute in particular > MUST NOT be de-aggregated. That is, the NLRI of this route can not be > > ==> pick either "deaggregate" or "de-aggregate" and stick to that. > > have the origin attribute with the value EGP. In all other case > > ==> s/case/cases/ > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06898 for ; Wed, 24 Sep 2003 12:36:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2CcU-00080w-5r; Wed, 24 Sep 2003 12:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Cbh-0007jg-MD for idr@optimus.ietf.org; Wed, 24 Sep 2003 12:35:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25237 for ; Wed, 24 Sep 2003 12:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Cbg-00074B-00 for idr@ietf.org; Wed, 24 Sep 2003 12:35:12 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Cbf-00073m-00 for idr@ietf.org; Wed, 24 Sep 2003 12:35:11 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8OGYcHm001689; Wed, 24 Sep 2003 09:34:39 -0700 (PDT) Received: from [192.168.42.3] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA25324; Wed, 24 Sep 2003 12:34:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Pekka Savola From: "John G. Scudder" Subject: Re: [Idr] comments on idr-bgp4-20 Cc: idr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 12:34:30 -0400 At 10:50 AM +0300 9/24/03, Pekka Savola wrote: >General thoughts on going to full standard: The process the IDR group has been following so far is to try to document the existing protocol rather than to tweak it. In your first few comments you seem to be suggesting that the protocol as currently deployed isn't suitable for full standard and should be tweaked. Is that what you meant to say? > - If we want to go for full standard, I have to question the usefulness of >several BGP features: > - AS_SET AS_PATH attribute I can imagine why you think this; however, given that AS_SET is already part of presumably all BGP implementations, I can't think of a reason to remove it. On the other hand, I can think of various reasons to keep it, including but not limited to "if it ain't broke, don't fix it." > - whole route aggregation concept (nowadays, it seems to be causing >more trouble than it's worth -- instead of proper advertisements, just >automatically aggregate instead of fixing the advertisements to begin >with). Maybe pver 10 years ago it may have been relevant if all the edge >BGP routers might not support BGP-4 or CIDR.. I honestly don't understand the point you're trying to make here. > - about N++ different cases of third-party nexthop usage. Are you suggesting that third-party nexthop should be removed from the spec (and from implementations)? If so, I think more justification will be needed. >4) there appears to have been added some bogosities about inter-AS traffic >engineering in section 9.3: > > - If the local AS appears in the AS path of the new route being > considered, then that new route can not be viewed as better than > any other route (provided that the speaker is configured to accept > such routes). If such a route were ever used, a routing loop could > result. > >and: > > The ability of a BGP speaker to include more than one instance of > its own AS in the AS_PATH attribute for the purpose of inter-AS > traffic engineering. > >==> what do these have to do with base spec? I don't think they're >operationally feasible or used. Remove any indication that it's OK to >receive your own AS in the routes you receive!! I beg to differ. The former is not common practice but is not unknown either (it's historically there to allow a partitioned AS to be healed through an external path). The latter (AS Path padding) is incredibly common. The text should be left as is, except that I wouldn't object to the removal of the clause "for the purpose of inter-AS traffic engineering." > attribute needs to be cognizant of the fact that the actual path to > >==> s/cognizant/aware/ Why? --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05114 for ; Wed, 24 Sep 2003 11:40:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BkJ-0003YI-6b; Wed, 24 Sep 2003 11:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bjv-0003XW-5S for idr@optimus.ietf.org; Wed, 24 Sep 2003 11:39:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22548 for ; Wed, 24 Sep 2003 11:39:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Bjt-0006N1-00 for idr@ietf.org; Wed, 24 Sep 2003 11:39:37 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Bjs-0006MZ-00 for idr@ietf.org; Wed, 24 Sep 2003 11:39:36 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8OFd3F7034389 for idr@ietf.org; Wed, 24 Sep 2003 11:39:03 -0400 (EDT) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([65.247.36.233]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8OFd0Vp034376 for ; Wed, 24 Sep 2003 11:39:00 -0400 (EDT) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Idr] comments on idr-bgp4-20 Message-ID: Thread-Topic: [Idr] comments on idr-bgp4-20 Thread-Index: AcOCcOhxJscqAumcSzO8sxexG3Hr3gAQNQ8Q From: "Susan Hares" To: "Pekka Savola" , X-Virus-Scanned: by AMaViS perl-11 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 11:39:00 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA05114 Pekka: For context on the message, could you tell me are you: 1) Implementor of BGP 2) Operator using BGP 3) Network researcher 4) other Sue Hares -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, September 24, 2003 3:50 AM To: idr@ietf.org Subject: [Idr] comments on idr-bgp4-20 Hi, [note, I'm not subscribed to the idr list] Alex solicited ops-dir for folks to review bgp4-20 spec. After almost half a year, I finally found the time to look at it. Comments below. I tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at least on the quick glance, I didn't find major overlaps. Overview: - the spec is in pretty good shape, but I'm not sure if all the features listed are really full standard material.. it might be better to separate some of them (e.g. anything relating to aggregation) to a separate doc (so that we'd have a much tigher and better real base spec), and recycle it at DS, but that might be much more effort.. not sure if something like that would be worth it. General thoughts on going to full standard: - If we want to go for full standard, I have to question the usefulness of several BGP features: - AS_SET AS_PATH attribute - whole route aggregation concept (nowadays, it seems to be causing more trouble than it's worth -- instead of proper advertisements, just automatically aggregate instead of fixing the advertisements to begin with). Maybe pver 10 years ago it may have been relevant if all the edge BGP routers might not support BGP-4 or CIDR.. - about N++ different cases of third-party nexthop usage. As a general observation from the text: - I skipped section 8 on FSM, as it was really boring, and I'm not sure whehter it's of any use keeping it in the base spec. - I got major headache when trying to read the aggregating rules especially in section 9.2.2.2 (and that was supposed to be the _simple_ rules :-(!!!) and ended up skipping them. substantial ----------- 1) Section 3 on Summary of the Operations, states: In the context of this document we assume that a BGP speaker adver- tises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. this "usability" requirement is in conflict with section 4.3 on UPDATE message format: An UPDATE message is used to advertise feasible routes sharing common path attributes to a peer, [...] ==> in particular note that "feasible" is a superset of "only those routes the router itself uses" (compare to "those routes the router itself _could_ use if they were the most preferred ones"), right? ==> also note that the former definition is (IMHO) operationally unsound. It prevents you from advertising P-t-P addresses and loopbacks (which also reside in IGP) using BGP, because the IGP distance is lower than BGP and "BGP route is never used in forwarding". (depending on how you interpret that). IMHO, this really needs to be changed to be OK. 2) The OPEN message format is confusing. Why on earth do you have those empty bits there? Are they null-padding or just a typographical convention for the clarity of the diagram (the latter)? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==> I strongly recommend to either: 1) go back to standard format, or 2) rephrase the message format similar with UPDATE messages, i.e., drop all the pretense about field lengths, bits 0-31, etc. 3) there is significant confusion on what "locally originated" means. It is not clear whether this refers to "local to the BGP speaker (i.e., the same system)" or "local to the routing domain (i.e., the same AS)". This must be clarified in the text below, and the text should be reviewed. 5.1.3 NEXT_HOP The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the des- tinations listed in the UPDATE message. The NEXT_HOP attribute is calculated as follows. 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. When announcing a locally originated route to an internal peer, the BGP speaker SHOULD use as the NEXT_HOP the interface address of the router through which the announced network is reachable for the speaker; if the route is directly connected to the speaker, or the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, then the BGP speaker SHOULD use for the NEXT_HOP attribute its own IP address (the address of the interface that is used to reach the peer). 4) there appears to have been added some bogosities about inter-AS traffic engineering in section 9.3: - If the local AS appears in the AS path of the new route being considered, then that new route can not be viewed as better than any other route (provided that the speaker is configured to accept such routes). If such a route were ever used, a routing loop could result. and: The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. ==> what do these have to do with base spec? I don't think they're operationally feasible or used. Remove any indication that it's OK to receive your own AS in the routes you receive!! 5) the reasoning for this section is not clear. It seems to be two parts (the second one starting at "These routes..."). It seems partially, at least for the second part, a set of operational guidelines.. which probably don't have anything to do with the BGP spec! 9.4 Originating BGP routes A BGP speaker may originate BGP routes by injecting routing informa- tion acquired by some other means (e.g. via an IGP) into BGP. A BGP speaker that originates BGP routes assigns the degree of preference to these routes by passing them through the Decision Process (see Section 9.1). These routes MAY also be distributed to other BGP speakers within the local AS as part of the update process (see Sec- tion 9.2). The decision whether to distribute non-BGP acquired routes within an AS via BGP or not depends on the environment within the AS (e.g. type of IGP) and SHOULD be controlled via configuration. 6) references; note that as the Security Consideration section is a bit short, the vulnerability analysis should be a *NORMATIVE* reference. However, one must ask here and with RFC2385 as well whether normative references are OK from Full Standard to a lower maturity level. Unless this has already been investigated, it may be worth checking with the ADs that this is OK. BGP vulnerabilities analysis is discussed in [XXX]. Normative References [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC2385, August 1998. Non-normative References [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- ietf-idr-bgp-vuln-00.txt, work in progress semi-substantial ---------------- ==> I'd add "Decision Process", "Routing Table", and "BGP route" in the terminology. (Especially the last one is a bit shady, see more comments later.) Adj-RIB-In Adj-RIBs-In Adj-RIB-Out Adj-RIBs-Out ==> in some places, one seems to use "Adj-RIBs-{In,Out}", in some others, "Adj-RIB-{In,Out}". The plural/singular form should be consistent. BGP speaker A router that implements BGP. ==> uhh, no. Throughout the text "BGP speaker" is used to refer to BGP-*enabled* routers. Implementation is a required but not sufficient condition to that. Consider rewording to something like: BGP speaker A router that implements and has been configured to use BGP. .... BGP Identifier: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. ==> the last sentence is confusing "same for every local interface".. yeah, right, but interfaces are irrelevant here. Also, this ignores the fact that it's perfectly legal to change BGP identifiers after startup but prior to establishing a BGP session. Consider rewording to something like: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined prior to establishing BGP sessions and is the same for every session the BGP speaker. ... Path Attributes: A variable length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple of variable length. ==> should a simple diagram be added here, just like in section 4.2? The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). ==> this and the following descriptions on attributes are out of place if you have not described the remaining categories (because they're used when describing the attributes in the next page), that is, discretionary and mandatory. Consider rewording the above to something like: The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). Well-known attributes can be either mandatory (MUST be included in every UPDATE message that contains NLRI), or discretionary (inclusion not required). ... All well-known attributes MUST be passed along (after proper updat- ing, if necessary) to other BGP peers. ==> LOCAL-PREF is an exception here. I also note that the BGP's definition of "transitive" is different ("unrecognized optional attributes are only passed onward when the transitive bit is set, but recognized optional attributes are always passed onward") from the apparent language ("always passed along"), and might use a bit of clarification. ... b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it is legal to prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. ==> the text here seems confusing because it is not clear whether things are added at the beginning or at the end of the segments, for example: "the _last_ element sequence (put it in the _leftmost_ position)" .. I think this requires more precise language on which end of the segment these values are really inserted. I.e., is it "physically" (in memory) left-to-right (from more recent to more distant), or just interpreted that way? This has significant impact on the last sentence of section 1) in case of overflows and the like. Whenever the modification of the AS_PATH attribute calls for includ- ing or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration. ==> what about prepending/adding someone else's AS? Is this relevant enough to be considered? A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers. ==> the second line seems out-of-place here. I assume it means that the router must not perform automatic de-aggregation, not that the router must not have more specific routes to advertise. In any case, a rewording might be in order, e.g. like: A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that is, generating more specifics by de-aggregating a route is forbidden. (note that this actually makes the statement stronger, and more in line of 9.1.4, that you should not do it even locally.) If the Length field of the message header is less than 19 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 19, or if the Length field of a NOTIFICATION message is less than the mini- mum length of the NOTIFICATION message, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field. ==> convert this to a bulleted list or something, so it's easier to read, please! :-) The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct: a) It MUST NOT be the IP address of the receiving speaker b) In the case of an EBGP where the sender and receiver are one IP hop away from each other, either the IP address in the NEXT_HOP MUST be the sender's IP address (that is used to establish the BGP connection), or the interface associated with the NEXT_HOP IP address MUST share a common subnet with the receiving BGP speaker. ==> what's exactly the case for the first case of b)? Couldn't thid be cleaned a bit (it seems to me that the second case is a superset of the first)? In addition, I'd recommend rewording "one IP hop away" -- that begs the question whether you mean "direct neighbors" or "just one transit router". When thinking of it more, the former seems apparent, but a different wording might flesh this out better. If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. ==> this is confusing, especially the end, beginning from "That is, ..." and should be reworded a bit (does it cover only deaggregation or more specifics in general?), like: If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, one must not generate more specifics of the NLRI of this route. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. However, accepting more specific advertisments which an aggregate route covers is acceptable. ... A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised. ==> and now we get back to the definition of "same BGP route"? Identical prefix carried over BGP? Identical prefix carried over BGP with identical attributes?" I'm assuming the former, otherwise (at least!) the above should be clarified. Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure separately to path attributes of like type and to the Network Layer Reachability Information. ==> the last line sounds really weird; consider: - s/like/the same/ ? - add more text after the NLRI, like "NLRI field" ? typos or other editorials ------------------------- ==> there should not be hyphenation at the linebreaks. This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. ==> s/extention/extension/ (two places) 3.2 Routing Information Bases The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts: ==> the subject is in plural form ("RIBs"), but the text begins as singular ("The RIB"). Consider which one to use? a) ORIGIN (Type Code 1): b) AS_PATH (Type Code 2): ==> kill the extra spaces before ORIGIN and NEXT_HOP. 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). ==> rewrite the last one as: last element of the sequence, putting it in the leftmost position. A BGP speaker MUST IMPLEMENT a mechanism based on local configuration ==> s/IMPLEMENT/implement/ used by a BGP speaker's decision process to discriminate ==> s/decision process/Decision Process/ (similar in a few other places?) attribute needs to be cognizant of the fact that the actual path to ==> s/cognizant/aware/ 6. BGP Error Handling. ==> remove the periods from at the end of section titles, esp. in subctions of section 6. issue a open collision dump [Event 23]. When the local system receives a open collision dump event [Event 23], the ==> s/a open/an open/ (two times) installed in LocRib and will be excluded from the next phase of route ==> s/LocRib/Loc-RIB/ all AS used to form the aggreagate in an AS_SET or add the ==> s/aggreagate/aggregate/ is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be ==> pick either "deaggregate" or "de-aggregate" and stick to that. have the origin attribute with the value EGP. In all other case ==> s/case/cases/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA26678 for ; Wed, 24 Sep 2003 07:33:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27tF-0000V4-Hi; Wed, 24 Sep 2003 07:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27t3-0000Uf-Ng for idr@optimus.ietf.org; Wed, 24 Sep 2003 07:32:49 -0400 Received: from mrson2072.com (80.179.254.186.forward.012.net.il [80.179.254.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07780 for ; Wed, 24 Sep 2003 07:32:22 -0400 (EDT) Message-Id: <200309241132.HAA07780@ietf.org> From: "Dr.Douglas Akpeki" Reply-To: d_akpeki1@tiscali.co.uk To: idr@ietf.org X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Idr] INVITATION TO PARTNERSHIP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 12:32:23 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id HAA26678 Dear Sir, REQUEST FOR YOUR UNRESERVED ASSISTANCE. This letter may come to you as a surprise but it was borne out of my sincere desire to share a mutual business relationship with you. First, your strictest confidence in this transaction is highly solicited. This is by virtue of its nature as being utterly confidential and top secret. I am a top government official with a statutory corporation and member of an adhoc committee set up by the Federal Government of Nigeria to review contract awarded by past administration. In the course of identifying, srcutinising and recommending for the payment of all valid contract executed, we discovered a huge sum of money amounting to USD41.5M (Forty One Million five Hundred Thousand US Dollars) on grossly over invoiced contract already awarded and exccuted for the Nigerian National Petroleum Corporation. Having cleaned the ‘AUGEAN STABLE‘ we intend to transfer the balance of USD41.5M presently floating in our apex bank of Nigeria to our own benefit and advantage. However, we request for your unwavering assistance in this regard because as civil servants we are prohibited under the civil service code of conduct bureau from operating a foreign account or running a foreign company unless after retirement in this vain we want you to front for us as partner to enable us lodge the funds speedily into your account. Bear in mind that no risk is attached to this project and all logistics are in place and modalities worked out for the smooth conclusion within a stipulated time. This is in accordance with the fact that you must never betray the trust already reposed on you. We have decided to compensate you with 30% of the total sum for your support, 60% for us while 10% for miscellaneous expenses (local and international). Please, provide your confidential phone and fax number to enable me contact you for further discussion on this matter. Please advise in your return mail if any time is confidential enough to call you. Looking forward to hearing from you. Best regards, Dr.Douglas Akpeki _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA25689 for ; Wed, 24 Sep 2003 07:01:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27OH-0006Ex-Fs; Wed, 24 Sep 2003 07:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A27NN-0006Am-0b for idr@optimus.ietf.org; Wed, 24 Sep 2003 07:00:05 -0400 Received: from n2now2300.com (80.179.254.186.forward.012.net.il [80.179.254.186]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06497 for ; Wed, 24 Sep 2003 06:59:44 -0400 (EDT) Message-Id: <200309241059.GAA06497@ietf.org> From: "Dr.Douglas Akpeki" Reply-To: d_akpeki@tiscali.co.uk To: idr@ietf.org X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Idr] INVITATION TO PARTNERSHIP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 11:59:36 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id HAA25689 Dear Sir, REQUEST FOR YOUR UNRESERVED ASSISTANCE. This letter may come to you as a surprise but it was borne out of my sincere desire to share a mutual business relationship with you. First, your strictest confidence in this transaction is highly solicited. This is by virtue of its nature as being utterly confidential and top secret. I am a top government official with a statutory corporation and member of an adhoc committee set up by the Federal Government of Nigeria to review contract awarded by past administration. In the course of identifying, srcutinising and recommending for the payment of all valid contract executed, we discovered a huge sum of money amounting to USD41.5M (Forty One Million five Hundred Thousand US Dollars) on grossly over invoiced contract already awarded and exccuted for the Nigerian National Petroleum Corporation. Having cleaned the ‘AUGEAN STABLE‘ we intend to transfer the balance of USD41.5M presently floating in our apex bank of Nigeria to our own benefit and advantage. However, we request for your unwavering assistance in this regard because as civil servants we are prohibited under the civil service code of conduct bureau from operating a foreign account or running a foreign company unless after retirement in this vain we want you to front for us as partner to enable us lodge the funds speedily into your account. Bear in mind that no risk is attached to this project and all logistics are in place and modalities worked out for the smooth conclusion within a stipulated time. This is in accordance with the fact that you must never betray the trust already reposed on you. We have decided to compensate you with 30% of the total sum for your support, 60% for us while 10% for miscellaneous expenses (local and international). Please, provide your confidential phone and fax number to enable me contact you for further discussion on this matter. Please advise in your return mail if any time is confidential enough to call you. Looking forward to hearing from you. Best regards, Dr.Douglas Akpeki _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA22758 for ; Wed, 24 Sep 2003 03:52:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24RO-0003Hd-7M; Wed, 24 Sep 2003 03:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A24QQ-0003G6-Nb for idr@optimus.ietf.org; Wed, 24 Sep 2003 03:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29717 for ; Wed, 24 Sep 2003 03:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A24QO-0007I7-00 for idr@ietf.org; Wed, 24 Sep 2003 03:51:00 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1A24QM-0007GO-00 for idr@ietf.org; Wed, 24 Sep 2003 03:50:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8O7oRn08766; Wed, 24 Sep 2003 10:50:28 +0300 From: Pekka Savola To: idr@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Idr] comments on idr-bgp4-20 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Sep 2003 10:50:26 +0300 (EEST) Hi, [note, I'm not subscribed to the idr list] Alex solicited ops-dir for folks to review bgp4-20 spec. After almost half a year, I finally found the time to look at it. Comments below. I tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at least on the quick glance, I didn't find major overlaps. Overview: - the spec is in pretty good shape, but I'm not sure if all the features listed are really full standard material.. it might be better to separate some of them (e.g. anything relating to aggregation) to a separate doc (so that we'd have a much tigher and better real base spec), and recycle it at DS, but that might be much more effort.. not sure if something like that would be worth it. General thoughts on going to full standard: - If we want to go for full standard, I have to question the usefulness of several BGP features: - AS_SET AS_PATH attribute - whole route aggregation concept (nowadays, it seems to be causing more trouble than it's worth -- instead of proper advertisements, just automatically aggregate instead of fixing the advertisements to begin with). Maybe pver 10 years ago it may have been relevant if all the edge BGP routers might not support BGP-4 or CIDR.. - about N++ different cases of third-party nexthop usage. As a general observation from the text: - I skipped section 8 on FSM, as it was really boring, and I'm not sure whehter it's of any use keeping it in the base spec. - I got major headache when trying to read the aggregating rules especially in section 9.2.2.2 (and that was supposed to be the _simple_ rules :-(!!!) and ended up skipping them. substantial ----------- 1) Section 3 on Summary of the Operations, states: In the context of this document we assume that a BGP speaker adver- tises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document. this "usability" requirement is in conflict with section 4.3 on UPDATE message format: An UPDATE message is used to advertise feasible routes sharing common path attributes to a peer, [...] ==> in particular note that "feasible" is a superset of "only those routes the router itself uses" (compare to "those routes the router itself _could_ use if they were the most preferred ones"), right? ==> also note that the former definition is (IMHO) operationally unsound. It prevents you from advertising P-t-P addresses and loopbacks (which also reside in IGP) using BGP, because the IGP distance is lower than BGP and "BGP route is never used in forwarding". (depending on how you interpret that). IMHO, this really needs to be changed to be OK. 2) The OPEN message format is confusing. Why on earth do you have those empty bits there? Are they null-padding or just a typographical convention for the clarity of the diagram (the latter)? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==> I strongly recommend to either: 1) go back to standard format, or 2) rephrase the message format similar with UPDATE messages, i.e., drop all the pretense about field lengths, bits 0-31, etc. 3) there is significant confusion on what "locally originated" means. It is not clear whether this refers to "local to the BGP speaker (i.e., the same system)" or "local to the routing domain (i.e., the same AS)". This must be clarified in the text below, and the text should be reviewed. 5.1.3 NEXT_HOP The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the des- tinations listed in the UPDATE message. The NEXT_HOP attribute is calculated as follows. 1) When sending a message to an internal peer, if the route is not locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP. When announcing a locally originated route to an internal peer, the BGP speaker SHOULD use as the NEXT_HOP the interface address of the router through which the announced network is reachable for the speaker; if the route is directly connected to the speaker, or the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, then the BGP speaker SHOULD use for the NEXT_HOP attribute its own IP address (the address of the interface that is used to reach the peer). 4) there appears to have been added some bogosities about inter-AS traffic engineering in section 9.3: - If the local AS appears in the AS path of the new route being considered, then that new route can not be viewed as better than any other route (provided that the speaker is configured to accept such routes). If such a route were ever used, a routing loop could result. and: The ability of a BGP speaker to include more than one instance of its own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. ==> what do these have to do with base spec? I don't think they're operationally feasible or used. Remove any indication that it's OK to receive your own AS in the routes you receive!! 5) the reasoning for this section is not clear. It seems to be two parts (the second one starting at "These routes..."). It seems partially, at least for the second part, a set of operational guidelines.. which probably don't have anything to do with the BGP spec! 9.4 Originating BGP routes A BGP speaker may originate BGP routes by injecting routing informa- tion acquired by some other means (e.g. via an IGP) into BGP. A BGP speaker that originates BGP routes assigns the degree of preference to these routes by passing them through the Decision Process (see Section 9.1). These routes MAY also be distributed to other BGP speakers within the local AS as part of the update process (see Sec- tion 9.2). The decision whether to distribute non-BGP acquired routes within an AS via BGP or not depends on the environment within the AS (e.g. type of IGP) and SHOULD be controlled via configuration. 6) references; note that as the Security Consideration section is a bit short, the vulnerability analysis should be a *NORMATIVE* reference. However, one must ask here and with RFC2385 as well whether normative references are OK from Full Standard to a lower maturity level. Unless this has already been investigated, it may be worth checking with the ADs that this is OK. BGP vulnerabilities analysis is discussed in [XXX]. Normative References [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC2385, August 1998. Non-normative References [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft- ietf-idr-bgp-vuln-00.txt, work in progress semi-substantial ---------------- ==> I'd add "Decision Process", "Routing Table", and "BGP route" in the terminology. (Especially the last one is a bit shady, see more comments later.) Adj-RIB-In Adj-RIBs-In Adj-RIB-Out Adj-RIBs-Out ==> in some places, one seems to use "Adj-RIBs-{In,Out}", in some others, "Adj-RIB-{In,Out}". The plural/singular form should be consistent. BGP speaker A router that implements BGP. ==> uhh, no. Throughout the text "BGP speaker" is used to refer to BGP-*enabled* routers. Implementation is a required but not sufficient condition to that. Consider rewording to something like: BGP speaker A router that implements and has been configured to use BGP. .... BGP Identifier: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. ==> the last sentence is confusing "same for every local interface".. yeah, right, but interfaces are irrelevant here. Also, this ignores the fact that it's perfectly legal to change BGP identifiers after startup but prior to establishing a BGP session. Consider rewording to something like: This 4-octet unsigned integer indicates the BGP Identifier of the sender. A given BGP speaker sets the value of its BGP Iden- tifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined prior to establishing BGP sessions and is the same for every session the BGP speaker. ... Path Attributes: A variable length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple of variable length. ==> should a simple diagram be added here, just like in section 4.2? The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). ==> this and the following descriptions on attributes are out of place if you have not described the remaining categories (because they're used when describing the attributes in the next page), that is, discretionary and mandatory. Consider rewording the above to something like: The high-order bit (bit 0) of the Attribute Flags octet is the Optional bit. It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). Well-known attributes can be either mandatory (MUST be included in every UPDATE message that contains NLRI), or discretionary (inclusion not required). ... All well-known attributes MUST be passed along (after proper updat- ing, if necessary) to other BGP peers. ==> LOCAL-PREF is an exception here. I also note that the BGP's definition of "transitive" is different ("unrecognized optional attributes are only passed onward when the transitive bit is set, but recognized optional attributes are always passed onward") from the apparent language ("always passed along"), and might use a bit of clarification. ... b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it is legal to prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. ==> the text here seems confusing because it is not clear whether things are added at the beginning or at the end of the segments, for example: "the _last_ element sequence (put it in the _leftmost_ position)" .. I think this requires more precise language on which end of the segment these values are really inserted. I.e., is it "physically" (in memory) left-to-right (from more recent to more distant), or just interpreted that way? This has significant impact on the last sentence of section 1) in case of overflows and the like. Whenever the modification of the AS_PATH attribute calls for includ- ing or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration. ==> what about prepending/adding someone else's AS? Is this relevant enough to be considered? A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers. ==> the second line seems out-of-place here. I assume it means that the router must not perform automatic de-aggregation, not that the router must not have more specific routes to advertise. In any case, a rewording might be in order, e.g. like: A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that is, generating more specifics by de-aggregating a route is forbidden. (note that this actually makes the statement stronger, and more in line of 9.1.4, that you should not do it even locally.) If the Length field of the message header is less than 19 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 19, or if the Length field of a NOTIFICATION message is less than the mini- mum length of the NOTIFICATION message, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field. ==> convert this to a bulleted list or something, so it's easier to read, please! :-) The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct: a) It MUST NOT be the IP address of the receiving speaker b) In the case of an EBGP where the sender and receiver are one IP hop away from each other, either the IP address in the NEXT_HOP MUST be the sender's IP address (that is used to establish the BGP connection), or the interface associated with the NEXT_HOP IP address MUST share a common subnet with the receiving BGP speaker. ==> what's exactly the case for the first case of b)? Couldn't thid be cleaned a bit (it seems to me that the second case is a superset of the first)? In addition, I'd recommend rewording "one IP hop away" -- that begs the question whether you mean "direct neighbors" or "just one transit router". When thinking of it more, the former seems apparent, but a different wording might flesh this out better. If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. ==> this is confusing, especially the end, beginning from "That is, ..." and should be reworded a bit (does it cover only deaggregation or more specifics in general?), like: If a BGP speaker chooses to aggregate, then it SHOULD either include all AS used to form the aggreagate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- marily informational. With the elimination of IP routing protocols that do not support classless routing and the elimination of router and host implementations that do not support classless routing, there is no longer a need to deaggregate. Routes SHOULD NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, one must not generate more specifics of the NLRI of this route. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. However, accepting more specific advertisments which an aggregate route covers is acceptable. ... A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised. ==> and now we get back to the definition of "same BGP route"? Identical prefix carried over BGP? Identical prefix carried over BGP with identical attributes?" I'm assuming the former, otherwise (at least!) the above should be clarified. Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure separately to path attributes of like type and to the Network Layer Reachability Information. ==> the last line sounds really weird; consider: - s/like/the same/ ? - add more text after the NLRI, like "NLRI field" ? typos or other editorials ------------------------- ==> there should not be hyphenation at the linebreaks. This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. ==> s/extention/extension/ (two places) 3.2 Routing Information Bases The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts: ==> the subject is in plural form ("RIBs"), but the text begins as singular ("The RIB"). Consider which one to use? a) ORIGIN (Type Code 1): b) AS_PATH (Type Code 2): ==> kill the extra spaces before ORIGIN and NEXT_HOP. 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position). ==> rewrite the last one as: last element of the sequence, putting it in the leftmost position. A BGP speaker MUST IMPLEMENT a mechanism based on local configuration ==> s/IMPLEMENT/implement/ used by a BGP speaker's decision process to discriminate ==> s/decision process/Decision Process/ (similar in a few other places?) attribute needs to be cognizant of the fact that the actual path to ==> s/cognizant/aware/ 6. BGP Error Handling. ==> remove the periods from at the end of section titles, esp. in subctions of section 6. issue a open collision dump [Event 23]. When the local system receives a open collision dump event [Event 23], the ==> s/a open/an open/ (two times) installed in LocRib and will be excluded from the next phase of route ==> s/LocRib/Loc-RIB/ all AS used to form the aggreagate in an AS_SET or add the ==> s/aggreagate/aggregate/ is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- gated. A route that carries ATOMIC_AGGREGATE attribute in particular MUST NOT be de-aggregated. That is, the NLRI of this route can not be ==> pick either "deaggregate" or "de-aggregate" and stick to that. have the origin attribute with the value EGP. In all other case ==> s/case/cases/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA10865 for ; Tue, 23 Sep 2003 21:31:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yUh-0002zJ-Mz; Tue, 23 Sep 2003 21:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yU7-0002wJ-8h for idr@optimus.ietf.org; Tue, 23 Sep 2003 21:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16933 for ; Tue, 23 Sep 2003 21:30:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yU4-00028P-00 for idr@ietf.org; Tue, 23 Sep 2003 21:30:24 -0400 Received: from [81.199.83.116] (helo=mrson2505.com) by ietf-mx with smtp (Exim 4.12) id 1A1yTz-00027R-00 for idr@ietf.org; Tue, 23 Sep 2003 21:30:22 -0400 From: "Dr Mrs Mariam Abacha" Reply-To: mariam2abacha@gawab.com To: idr@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: Subject: [Idr] Respond soonest Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 18:30:19 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id VAA10865 Attn:Sir/Ma, I salute you in the name of Allah,the most high God.I am Mrs. Mariam Abacha, the widow of the late General Sani Abacha, former Nigerian Military head of state who died mysteriously as a result of Cardiac arrest.Since my husband died, my family has been under restriction of movement and that not withstanding, we have been molested and constantly under watch by the seemingly Agent, above all our bank accounts here and abroad have been frozen by the Nigerian civilian Government. Furthermore, my eldest son is in detention by the Nigerian Government for more interrogation about my husband assets and some vital documents. Following the recent discovery of my husband's bank account by the Nigerian Government with my son's bank in which a huge some of US$700 million and Dutch Mark 450 million was lodged and f1.6 billion belonging to my late husband was seized by the Government of Nigeria.I therefore wish to personally appeal to you seriously and religious for your urgent assistance to transfer the sum of US$25.5 million into your account in your country where I believe it will be safe, since we can not leave the country, due to the restriction of the movement imposed on the members of my family by the Nigerian Government.You can contact me through my farmily lawyer's number 234 80333 13642(barister Buba Mohhamed) And he shall arrange with you for a face-to face meeting outside Nigeria inorder to lease with him toward effective completion ofthis transaction. However, arrangement have been put in place to move this money out of the country, in the secret vault through a security Company to any of West African States, Europe,America as soon as you indicate your interest, my Lawyer shall send to you the Security Deposit Certificate and Airway Bill of the luggage and other related documents so that you an claim the luggage, which shall be tagged FAMILY TREASUERS. Conclusively, we have agreed to offer you 30% of the total sum while 70% is to be held on trust by you until we can decide on a suitable business investment in your country subsequent to our free movement by the Nigerian Government.Please, reply urgently and treat with absolute confidentiality and sincerity. Yours sincerely, Mariam Abacha. N.B.Your reponse will determine the transaction and please all information guarantee safety. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA06066 for ; Tue, 23 Sep 2003 18:54:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w2j-0003kn-30; Tue, 23 Sep 2003 18:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w1k-0003kK-5G for idr@optimus.ietf.org; Tue, 23 Sep 2003 18:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11898 for ; Tue, 23 Sep 2003 18:52:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1w1g-0000NH-00 for idr@ietf.org; Tue, 23 Sep 2003 18:52:56 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A1w1g-0000N2-00 for idr@ietf.org; Tue, 23 Sep 2003 18:52:56 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8NMqJv24319 for ; Tue, 23 Sep 2003 18:52:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 18:52:20 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540702832B@zcard0k6.ca.nortel.com> From: "Kirk Smith" To: idr@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38225.5819CCB4" Subject: [Idr] Questions about operation of draft-ietf-idr-route-filter-09.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Sep 2003 18:52:19 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38225.5819CCB4 Content-Type: text/plain I have a question about the operation (Section 8) of receiving a route refresh request containing ORFs. In particular, the draft states: "If the When-to-Refresh indicates IMMEDIATE, then after processing all the ORF entries carried in the message the speaker re-advertises to the peer routes from the Adj-RIB-Out associated with the peer that have the same AFI/SAFI as what is carried in the message, and taking into account all the ORF entries received from the peer. However, the routes that have not be affected by the ORF entries carried in the message SHOULT NOT be re-advertised to the peer." I take this to mean, that BGP will advertise those routes which match the ORF entries contained in the UPDATE message being processed (and possibly any previous marked as DEFER), but not those which were already processed and advertised to this peer. For example, say I have 2 BGP speakers, X and Y. X sends a route refresh message to Y containing ORF value A with IMMEDIATE. I assume any routes matching A (and the AFI/SAFI) will be sent to X from Y. Now, say X sends a route refresh message to Y containing ORF value B with IMMEDIATE. I assume only those routes matching B will be sent to X from Y. i.e. the routes matching ORF A will not be readvertised. Is my assumption correct? Thanks, Kirk. ------_=_NextPart_001_01C38225.5819CCB4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Questions about operation of draft-ietf-idr-route-filter-09.txt =

I have a question about the operation = (Section 8) of receiving a route refresh request containing = ORFs.

In particular, the draft = states:
"If the When-to-Refresh = indicates IMMEDIATE, then after processing all the ORF entries carried = in the message the speaker re-advertises to the peer routes from the = Adj-RIB-Out associated with the peer that have the same AFI/SAFI as = what is carried in the message, and taking into account all the ORF = entries received from the peer. However, the routes that have not be = affected by the ORF entries carried in the message SHOULT NOT be = re-advertised to the peer."

  I take this to mean, that BGP = will advertise those routes which match the ORF entries contained in = the UPDATE message being processed (and possibly any previous marked as = DEFER), but not those which were already processed and advertised to = this peer.

For example, say I have 2 BGP = speakers, X and Y.
X sends a route refresh message to Y = containing ORF value A with IMMEDIATE.
I assume any routes matching A (and = the AFI/SAFI) will be sent to X from Y.
Now, say X sends a route refresh = message to Y containing ORF value B with IMMEDIATE.
I assume only those routes matching = B will be sent to X from Y.  i.e. the routes matching ORF A will = not be readvertised.

Is my assumption correct?

Thanks,
  Kirk.

------_=_NextPart_001_01C38225.5819CCB4-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA13531 for ; Mon, 22 Sep 2003 14:46:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1VhB-0006Dr-0Y; Mon, 22 Sep 2003 14:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Vgh-0006Ap-8t for idr@optimus.ietf.org; Mon, 22 Sep 2003 14:45:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29766; Mon, 22 Sep 2003 14:45:21 -0400 (EDT) Message-Id: <200309221845.OAA29766@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Sep 2003 14:45:21 -0400 --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-4 Protocol Analysis Author(s) : D. Meyer, K. Patel Filename : draft-ietf-idr-bgp-analysis-04.txt Pages : 20 Date : 2003-9-22 The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for'the second report', as described in Section 6.0 of RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP protocol, and analyzes the protocol with respect to scaling and performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-analysis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-analysis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-22132834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-22132834.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA19839 for ; Sat, 20 Sep 2003 18:25:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0qA1-00042B-NN; Sat, 20 Sep 2003 18:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0q9R-0003vs-31 for idr@optimus.ietf.org; Sat, 20 Sep 2003 18:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25249 for ; Sat, 20 Sep 2003 18:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0q9J-00020K-00 for idr@ietf.org; Sat, 20 Sep 2003 18:24:17 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 1A0q98-0001zg-00 for idr@ietf.org; Sat, 20 Sep 2003 18:24:06 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 1E3A220299 for ; Sat, 20 Sep 2003 16:22:53 -0600 (MDT) Subject: Re: [idr] taxonomy of bogon filtering applied to route servers Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Sep 2003 16:22:53 -0600 It would seem to me that this is more of an implementation/ "feature set" issue than protocol issue. With that said, I suppose I see some utility, but as discussed on other lists, it mostly just raises "the lazy bar", IMO. This message is probably better suited for the GROW mailing list, though I suspect the feeling there will be similar (then again, ....). -danny On Saturday, September 20, 2003, at 01:39 PM, Michel Py wrote: > idr chairs and folks, > > [I apologize in advance is this off-topic for this list] > > I was recently looking at the issue of bogon route-servers, and it > struck me that there would be little work to adapt BGP Prefix-Based > Outbound Route Filtering (ORF) to change it into what is desperately > needed for bogons. > > In a nutshell, the way I understand ORF is that the sending router > sends > the receiving router a prefix-list (or distribute-list, or as-path > list). When the receiving router receives the prefix-list, it applies > it > outbound towards the peer it received it from. > > The enhancement that would be needed would be to make the receiving > router capable of applying the received prefix-list to other peers, > especially inbound. This would likely involve naming the received ORF > and making it available to other peers. > > In other words, my idea is to use the ORF mechanism to propagate > prefix-lists to other peers, not for the purpose of filtering the > routes > sent to a peer and their associated handling but for the purpose of > filtering inbound routes coming from other peers of the receiving ORF > router. I was wondering what this WG thinks about it. > > I wrote a little taxonomy about IPv6 bogon filtering; this is very, > very > crude and I welcome your comments. > > Best, > Michel. > > > Taxonomy of bogon filtering. > ============================ > > There are five basic ways to handle the bogon filtering issue: > > 1. Manually configured prefix-lists. > 2. BGP feed of "bad" prefix aggregates. > 3. BGP feed of anomalies. > 4. BGP feed of "good" prefixes. > 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). > > > 1. Manually configured prefix-lists. > ------------------------------------ > > This involves one or more volunteers to maintain a prefix-list that is > to be configured manually on routers. The issue with this is change > management: as we have seen with the 69/8 fiasco not that long ago, > some > people do _not_ update their filters regularly, and when the bogon > prefix-list is modified it can take weeks to be upgraded, which is not > good. However, in terms of granularity, this is what gives the finest > control. > > > 2. BGP feed of "bad" prefix aggregates. > --------------------------------------- > > This is the mechanism currently used by team cymru's bogon route > servers > (http://www.cymru.com/BGP/bogon-rs.html). The issue with this is that > the domain of applicability is limited to networks that do not receive > a > full feed. If one gets a full feed, this method does not prevent bad > prefixes if they are smaller than the bogon feed, because of the > longest > match rule. So, this is an option only for networks with private > peering > only and a default route outside, because a blackhole route is > installed > to dump all the bogon traffic instead of sending it to the default > route. > > > 3. BGP feed of anomalies. > ------------------------- > > A finer version of the previous one. Real-time monitoring of the > routing > table at different points allows to build a list of bad announcements. > Contrary to the previous option, this allows to deal with specific > announcements. The issue with this is that it does not prevent the bad > announcement to be received, it actually adds another path that will be > made preferred to the offending announcement and used to dump the > traffic in a blackhole. Compared to the feeding of bad aggregates, this > method extends the domain of applicability to defaultless networks, at > the expense of aggravating the routing table size issue. > > > 4. BGP feed of "good" prefixes. > ------------------------------- > > This is an IPv6-only topic that was discussed outside of idr. Please > don't pay attention to it in this context. > > > 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). > ----------------------------------------------------------------- > > http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt > http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/ > products_feature_ > guide09186a0080134a57.html > > Unfortunately the actual capabilities of this are that the filter-list > received from the peer is applied only outbound to the same peer. This > is a very promising technique for bogon route servers, but we need to > enhance it. > > Please send comments. > > Michel. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA14652 for ; Sat, 20 Sep 2003 15:41:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0nbI-00029v-C9; Sat, 20 Sep 2003 15:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0naL-000294-KL for idr@optimus.ietf.org; Sat, 20 Sep 2003 15:40:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20967 for ; Sat, 20 Sep 2003 15:39:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0naK-0000R7-00 for idr@ietf.org; Sat, 20 Sep 2003 15:40:00 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A0na9-0000Qh-00 for idr@ietf.org; Sat, 20 Sep 2003 15:39:49 -0400 Subject: [idr] taxonomy of bogon filtering applied to route servers MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-class: urn:content-classes:message Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [idr] taxonomy of bogon filtering applied to route servers Thread-Index: AcN4vciAfF18XVnBSQaemUP9e/zWOgG8NEnQ From: "Michel Py" To: Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Sep 2003 12:39:09 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA14652 idr chairs and folks, [I apologize in advance is this off-topic for this list] I was recently looking at the issue of bogon route-servers, and it struck me that there would be little work to adapt BGP Prefix-Based Outbound Route Filtering (ORF) to change it into what is desperately needed for bogons. In a nutshell, the way I understand ORF is that the sending router sends the receiving router a prefix-list (or distribute-list, or as-path list). When the receiving router receives the prefix-list, it applies it outbound towards the peer it received it from. The enhancement that would be needed would be to make the receiving router capable of applying the received prefix-list to other peers, especially inbound. This would likely involve naming the received ORF and making it available to other peers. In other words, my idea is to use the ORF mechanism to propagate prefix-lists to other peers, not for the purpose of filtering the routes sent to a peer and their associated handling but for the purpose of filtering inbound routes coming from other peers of the receiving ORF router. I was wondering what this WG thinks about it. I wrote a little taxonomy about IPv6 bogon filtering; this is very, very crude and I welcome your comments. Best, Michel. Taxonomy of bogon filtering. ============================ There are five basic ways to handle the bogon filtering issue: 1. Manually configured prefix-lists. 2. BGP feed of "bad" prefix aggregates. 3. BGP feed of anomalies. 4. BGP feed of "good" prefixes. 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). 1. Manually configured prefix-lists. ------------------------------------ This involves one or more volunteers to maintain a prefix-list that is to be configured manually on routers. The issue with this is change management: as we have seen with the 69/8 fiasco not that long ago, some people do _not_ update their filters regularly, and when the bogon prefix-list is modified it can take weeks to be upgraded, which is not good. However, in terms of granularity, this is what gives the finest control. 2. BGP feed of "bad" prefix aggregates. --------------------------------------- This is the mechanism currently used by team cymru's bogon route servers (http://www.cymru.com/BGP/bogon-rs.html). The issue with this is that the domain of applicability is limited to networks that do not receive a full feed. If one gets a full feed, this method does not prevent bad prefixes if they are smaller than the bogon feed, because of the longest match rule. So, this is an option only for networks with private peering only and a default route outside, because a blackhole route is installed to dump all the bogon traffic instead of sending it to the default route. 3. BGP feed of anomalies. ------------------------- A finer version of the previous one. Real-time monitoring of the routing table at different points allows to build a list of bad announcements. Contrary to the previous option, this allows to deal with specific announcements. The issue with this is that it does not prevent the bad announcement to be received, it actually adds another path that will be made preferred to the offending announcement and used to dump the traffic in a blackhole. Compared to the feeding of bad aggregates, this method extends the domain of applicability to defaultless networks, at the expense of aggravating the routing table size issue. 4. BGP feed of "good" prefixes. ------------------------------- This is an IPv6-only topic that was discussed outside of idr. Please don't pay attention to it in this context. 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). ----------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080134a57.html Unfortunately the actual capabilities of this are that the filter-list received from the peer is applied only outbound to the same peer. This is a very promising technique for bogon route servers, but we need to enhance it. Please send comments. Michel. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA26565 for ; Thu, 18 Sep 2003 05:27:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zv41-0005en-U7; Thu, 18 Sep 2003 05:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zv3a-0005co-4x for idr@optimus.ietf.org; Thu, 18 Sep 2003 05:26:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03550 for ; Thu, 18 Sep 2003 05:26:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zv3W-00032U-00 for idr@ietf.org; Thu, 18 Sep 2003 05:26:30 -0400 Received: from node-c-04db.a2000.nl ([62.194.4.219] helo=2mails830.com) by ietf-mx with smtp (Exim 4.12) id 19zv3R-00032K-00 for idr@ietf.org; Thu, 18 Sep 2003 05:26:26 -0400 From: "DR.FRANK EFE" Reply-To: frank.efe77@laposte.net To: idr@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: Subject: [Idr] PARTNER NEEDED Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 11:25:23 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id FAA26565 CONFIDENTIAL 25 Adewabe Street, Ikoyi Island, Lagos. IFax:1775-522-8610 18/9/2003 ATTN:THE PRESIDENT/CEO FROM:DR.FRANK EFE. Dear Sir, I would like to firstly send to you the best wishes of good health and success in your pursuits particularly through my proposal as contained in this letter. Before going into details of my proposal to you, I must first implore you to treat with the utmost confidentiality as this is required for its success and to have faith in this transaction,for opportunities like this only comes to one once in a life time. My colleagues and I are senior officials of the Federal Government of my country's Contracts Review Panel (CRP) who are interested in diverting some funds that are presently loating in the accounts of the Apex Bank of my country.In order to commence this transaction, we solicit for your assistance to enable us transfer into your nominated account the said floating funds. We are determined to conclude the transfer before the end of this quarter of 2003. The source of the funds are as follows: During the last military regime in my country,government officials set up companies and awarded themselves contracts that were grossly over-invoiced in various ministries and parastatals.The present civilian government set up the Contract Review Panel, which has the mandate to use the instruments of payments made available to it by the decree setting up the panel, to review these contracts and if necessary pay those who are being owed outstanding amounts. My colleagues and I have identified quite a huge sum of these funds which are presently floating in our (Apex)Central Bank ready for disbursement and would like to divert some of it for our own purposes. However, by virtue of our positions as civil servants and members of this panel, we cannot acquire these funds in our names or in the names of companies that are based in my country. I have therefore been mandated,as a matter of trust by my colleagues in the panel, to look for a reliable overseas partner into whose account we can transfer the sum of U.S.$20,500,000.00 (Twenty million, five hundred thousand U.S. dollars).That is why I am seeking your assistance. We have agreed to share the money to be transferred into your account, if you agree with our proposition as follows; (i)25% to the account owner(you). (ii)65% for us (the panel officials). (iii)10% to be used in settling all expenses (by both you and us) incidental to the actualization of this project. We wish to invest our share of the proceeds of this project in foreign stock markets and other viable business till we are ready and able to have access to them without raising any eyebrows here at home. Please note that this transaction is 100% safe and risk-free. We intend to effect the transfer within fourteen (14)banking days from the date of receipt of the following information through the ifax number stated above:Your company's name,address,telephone and fax numbers we will use your company's name to apply for the payment and backdate the award of the contract in favour of your company. We are looking forward to doing this transaction with you and we solicit for your utmost confidentiality in this transaction. I will bring you into a more detailed picture of this transaction when I hear from you.Please get in touch through my IFAX # 177-552-286-10. Best regards, DR.FRANK EFE. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29050 for ; Wed, 17 Sep 2003 10:44:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70814913B2; Wed, 17 Sep 2003 10:42:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44070913AD; Wed, 17 Sep 2003 10:42:15 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE8939139C for ; Wed, 17 Sep 2003 10:40:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 91A115DDB2; Wed, 17 Sep 2003 10:40:08 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.avici.com (unknown [12.38.212.174]) by segue.merit.edu (Postfix) with ESMTP id 4A98F5DDA9 for ; Wed, 17 Sep 2003 10:40:08 -0400 (EDT) Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h8HEc2Yf001216; Wed, 17 Sep 2003 10:38:03 -0400 Message-Id: <200309171438.h8HEc2Yf001216@mail.avici.com> To: idr@merit.edu Cc: curtis@fictitious.org Reply-To: curtis@fictitious.org Subject: some comments on draft-ietf-idr-bgp4-experience-protocol-02.txt Date: Wed, 17 Sep 2003 10:38:08 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk ref: Title : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt Danny, This looks to be in good shape. If you do another version of the draft here are some suggestions. None of this is essential to the draft but it might be helpful. Curtis In the MED section you might want to describe the common "hot potatoe / cold potatoe" usage. Here is some suggested text. In a situation where traffic flows between a pair of destinations, each connected to two transit networks, each of the transit networks has the choice of either sending the traffic to the closest peering to other transit provider or passing traffic to the peering which advertises the least cost through the other provider. The former method is called "hot potatoe routing" because like a hot potatoe held in bare hands, whoever has it tries to get rid of it quickly. Hot potatoe routing is accomplished by not passing the EGBP learned MED into IBGP. This minimizes transit traffic for the provider routing the traffic. Far less common is "cold potatoe routing" where the transit provider uses their own transit capacity to get the traffic to the point in the adjacent transit provider advertised as being closest to the destination. Cold potatoe routing is accomplished by passing the EBGP learned MED into IBGP. If one transit provider uses hot potatoe routing and another uses cold potatoe, traffic between the two tends to be symetric. Depending on the business relationships, if one provider has more capacity or a significantly less congested transit network, then that provider may use cold potatoe routing. An example of widespread use of cold potatoe routing was the NSF funded NSFNET backbone and NSF funded regional networks in the mid 1990s. In some cases a provider may use hot potatoe routing for some destinations for a given peer AS and cold potatoe routing for others. An example of this is the different treatment of commercial and research traffic in the NSFNET in the mid 1990s. Optionally add to the last paragraph "This might best be described as 'mashed potatoe routing' a term which reflects the complexity of router configurations in use at the time". :-) Under "Internet Dynamics" I would prefer if you would add: None of the current implementations of BGP Route Flap Damping store route history by unique NRLI and AS Path although it is listed as manditory in RFC 2439. A potential result of failure to consider each AS Path separately is an overly aggressive suppression of destinations in a densely meshed network, with the most severe consequence being suppression of a destination after a single failure. Because the top tier AS in the Internet are densely meshed, these adverse consequences are observed. After "Limit Rate Updates" you might add a section: 13 1/2. Consideration of TCP Characteristics If a TCP receiver is processing input more slowly than the sender or if the TCP connection rate is the limiting factor, a form of backpressure is observed by the TCP sending application. When the TCP buffer fills, the sending application will either block on the write or receive an error on the write. Common errors in either early implementations or an occasional naive new implementation are to either set options to block on the write or set options for non-blocking writes and then treat the errors due to a full buffer as fatal. Having recognized that full write buffers are to be expected additional implementation pitfalls exist. The application should not attempt to store the TCP stream within the application itself. If the receiver or the TCP connection is persistently slow, then the buffer can grow until memory is exhausted. A BGP implementation must send changes to all peers for which the TCP connection is not blocked and must remember to send those changes to the remaining peers when the connection becomes unblocked. If the preferred route for a given NLRI changes multiple times while writes to one or more peer is blocked, only the most recent best route needs to be sent. In this way BGP is work conserving. In times of extremely high route change, a higher volume of route change is sent to those peers which are able to process it more quickly and a lower volume of route change is sent to those peers not able to process the changes as quickly. For implentations which handle differing peer capacity to absorb route change well, if the majority of route change is contributed by a subset of unstable NRLI, the only impact on relatively stable NRLI which make an isolated route change is a slower convergence for which convergence time remains bounded regardless of the amount of instability. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01191 for ; Tue, 16 Sep 2003 15:47:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5DB60912DA; Tue, 16 Sep 2003 15:47:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E523912DB; Tue, 16 Sep 2003 15:47:08 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68339912DA for ; Tue, 16 Sep 2003 15:47:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FBC35DDAA; Tue, 16 Sep 2003 15:47:06 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail13-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by segue.merit.edu (Postfix) with ESMTP id 10E015DD94 for ; Tue, 16 Sep 2003 15:47:06 -0400 (EDT) Received: from mail13-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail13-kan-R.bigfish.com (Postfix) with ESMTP id DAA1DB1C14 for ; Tue, 16 Sep 2003 19:47:04 +0000 (UCT) Received: by mail13-kan (MessageSwitch) id 1063741624817916_321; Tue, 16 Sep 2003 19:47:04 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail13-kan.bigfish.com (Postfix) with ESMTP id A37E1B1DE4 for ; Tue, 16 Sep 2003 19:47:04 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8GJl4v7029071 for ; Tue, 16 Sep 2003 14:47:04 -0500 (CDT) Received: from PKDWG02A.ad.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GJl4t05160 for ; Tue, 16 Sep 2003 14:47:04 -0500 (CDT) Received: from mail pickup service by PKDWG02A.ad.sprint.com with Microsoft SMTPSVC; Tue, 16 Sep 2003 14:47:02 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.56]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Sep 2003 14:32:15 -0500 Received: from smtpgw5.sprintspectrum.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GJWA701472 for ; Tue, 16 Sep 2003 14:32:11 -0500 (CDT) Received: from mail5-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8GJWAv7015999 for ; Tue, 16 Sep 2003 14:32:10 -0500 (CDT) Received: from mail5-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail5-kan-R.bigfish.com (Postfix) with ESMTP id 39E3D201EB0 for ; Tue, 16 Sep 2003 19:03:26 +0000 (UCT) Received: by mail5-kan (MessageSwitch) id 1063739003453639_12564; Tue, 16 Sep 2003 19:03:23 +0000 (UCT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail5-kan.bigfish.com (Postfix) with ESMTP id 39059201E61; Tue, 16 Sep 2003 19:02:52 +0000 (UCT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19zKxP-00089D-5X for ietf-announce-list@asgard.ietf.org; Tue, 16 Sep 2003 14:53:47 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19zKx8-000831-9x for all-ietf@asgard.ietf.org; Tue, 16 Sep 2003 14:53:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01741; Tue, 16 Sep 2003 14:53:22 -0400 (EDT) Message-Id: <200309161853.OAA01741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt Date: Tue, 16 Sep 2003 14:53:22 -0400 X-BigFish: cs-64(z60di60eiz14c3M13bfI122eHzz2cfRzz1033ILz1IV)v X-OriginalArrivalTime: 16 Sep 2003 19:32:16.0718 (UTC) FILETIME=[3CB22EE0:01C37C89] 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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt Pages : 20 Date : 2003-9-16 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16115400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16115400.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA28867 for ; Tue, 16 Sep 2003 15:06:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL9G-0004Gv-Ec; Tue, 16 Sep 2003 15:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL8z-0004Gd-1Y for idr@optimus.ietf.org; Tue, 16 Sep 2003 15:05:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02776 for ; Tue, 16 Sep 2003 15:05:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zL8v-00002W-00 for idr@ietf.org; Tue, 16 Sep 2003 15:05:41 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19zL8v-00001h-00 for idr@ietf.org; Tue, 16 Sep 2003 15:05:41 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 255C92029B for ; Tue, 16 Sep 2003 13:05:04 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Danny McPherson To: idr@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Idr] Fwd: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Sep 2003 13:05:03 -0600 Note that all comments received to date (within the WG LC window that ends today) have been incorporated into this version of the draft. -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Tue Sep 16, 2003 12:53:22 PM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt > Reply-To: Internet-Drafts@ietf.org > > 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 : Experience with the BGP-4 Protocol > Author(s) : D. McPherson, K. Patel > Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt > Pages : 20 > Date : 2003-9-16 > > The purpose of this memo is to document how the requirements for > advancing a routing protocol from Draft Standard to full Standard > have been satisfied by Border Gateway Protocol version 4 (BGP-4). > This report satisfies the requirement for 'the second report', as > described in Section 6.0 of RFC 1264. In order to fulfill the > requirement, this report augments RFC 1773 and describes additional > knowledge and understanding gained in the time between when the > protocol was made a Draft Standard and when it was submitted for > Standard. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience- > protocol-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-idr-bgp4-experience-protocol-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-9-16115400.I-D@ietf.org> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA28090 for ; Tue, 16 Sep 2003 14:53:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 245C3912CE; Tue, 16 Sep 2003 14:53:34 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5D9B912D3; Tue, 16 Sep 2003 14:53:33 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E3CF912CE for ; Tue, 16 Sep 2003 14:53:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EFED5DDCB; Tue, 16 Sep 2003 14:53:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 3456D5DDB5 for ; Tue, 16 Sep 2003 14:53:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01741; Tue, 16 Sep 2003 14:53:22 -0400 (EDT) Message-Id: <200309161853.OAA01741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt Date: Tue, 16 Sep 2003 14:53:22 -0400 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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-02.txt Pages : 20 Date : 2003-9-16 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16115400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16115400.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA14421 for ; Tue, 16 Sep 2003 10:20:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFFDD9123A; Tue, 16 Sep 2003 10:20:23 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFDEA9123B; Tue, 16 Sep 2003 10:20:23 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79C939123A for ; Tue, 16 Sep 2003 10:20:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 067565DD95; Tue, 16 Sep 2003 10:20:22 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 71B775DD8E for ; Tue, 16 Sep 2003 10:20:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16340; Tue, 16 Sep 2003 10:20:09 -0400 (EDT) Message-Id: <200309161420.KAA16340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-cease-subcode-04.txt Date: Tue, 16 Sep 2003 10:20:08 -0400 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 : Subcodes for BGP Cease Notification Message Author(s) : E. Chen, V. Gillet Filename : draft-ietf-idr-cease-subcode-04.txt Pages : 4 Date : 2003-9-16 This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in co-relating network events and diagnosing BGP peering issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-cease-subcode-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-cease-subcode-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16103804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16103804.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA10299 for ; Thu, 11 Sep 2003 21:03:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA36391249; Thu, 11 Sep 2003 21:03:01 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DF3591296; Thu, 11 Sep 2003 21:03:01 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81E6891249 for ; Thu, 11 Sep 2003 21:03:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D1A35DED3; Thu, 11 Sep 2003 21:03:00 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id E5B5E5DE41 for ; Thu, 11 Sep 2003 21:02:59 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 68A77369000; Thu, 11 Sep 2003 18:02:59 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 2636B15D3C1; Thu, 11 Sep 2003 18:02:57 -0700 (PDT) To: Andrew Lange Cc: idr@merit.edu, vgi@opentransit.net, "Don Goodspeed" , enke@redback.com Subject: Re: Cease Subcode Draft - Suggestion In-Reply-To: Message from Andrew Lange of "Thu, 11 Sep 2003 15:01:02 PDT." <3F60F09E.9060806@alcatel.com> Date: Thu, 11 Sep 2003 18:02:57 -0700 From: Enke Chen Message-Id: <20030912010258.2636B15D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Andrew and Don: > Message-ID: <3F60F09E.9060806@alcatel.com> > Date: Thu, 11 Sep 2003 15:01:02 -0700 > From: Andrew Lange > Organization: Alcatel USA > To: enke@redback.com, idr@merit.edu, vgi@opentransit.net > Cc: "Don Goodspeed" > Subject: Cease Subcode Draft - Suggestion > > Hello, > > Don Goodspeed pointed out a couple of error conditions that would be > useful to add to the cease subcodes draft. We worked up some proposed > text to add to draft-ietf-idr-cease-subcode-03.txt: > > 4. Subcode Definition > > Subcode Symbolic Name > 0 Other Condition I do not think this is necessary as the BGP spec has already defined Subcode 0 for "Unspecific". See the following text from the latest draft: ---------------------------------- 4.5 NOTIFICATION Message Format Error subcode: This 1-octet unsigned integer provides more specific informa- tion about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field. ---------------------------------- > ... ... > 8 Out of Resources Assuming the message can still be sent :-) I would like to hear some comments on this one. -- Enke > > 5. Subcode Usage > > If a BGP speaker decides to shutdown the session for a reason that > is not covered in the other subcodes defined in this document, then > the speaker should send a NOTIFICATION message with the Error Code > Cease, and the Error Subcode "Other Condition". > > If a BGP speaker decides to shut down a session because it is out of > resources, such as memory, then the speaker should send a > NOTIFICATION message with the Error Code Cease, and the Error > Subcode "Out of Resources". > > ... > > It is recommended that a BGP speaker implement a backoff mechanism > in re-trying a BGP connection after the speaker receives a Cease > NOPTIFICATION message with the subcode of ... "Out of Resources". > > > Andrew > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA29860 for ; Thu, 11 Sep 2003 18:01:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7AA549128B; Thu, 11 Sep 2003 18:01:12 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A2ED9128D; Thu, 11 Sep 2003 18:01:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40D2C9128B for ; Thu, 11 Sep 2003 18:01:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 205645E020; Thu, 11 Sep 2003 18:01:10 -0400 (EDT) Delivered-To: idr@merit.edu Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by segue.merit.edu (Postfix) with ESMTP id AFE2D5E00E for ; Thu, 11 Sep 2003 18:01:09 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8BM12Bx006302; Thu, 11 Sep 2003 17:01:08 -0500 (CDT) Message-ID: <3F60F09E.9060806@alcatel.com> Date: Thu, 11 Sep 2003 15:01:02 -0700 From: Andrew Lange Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: enke@redback.com, idr@merit.edu, vgi@opentransit.net Cc: "Don Goodspeed" Subject: Cease Subcode Draft - Suggestion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Hello, Don Goodspeed pointed out a couple of error conditions that would be useful to add to the cease subcodes draft. We worked up some proposed text to add to draft-ietf-idr-cease-subcode-03.txt: 4. Subcode Definition Subcode Symbolic Name 0 Other Condition ... ... 8 Out of Resources 5. Subcode Usage If a BGP speaker decides to shutdown the session for a reason that is not covered in the other subcodes defined in this document, then the speaker should send a NOTIFICATION message with the Error Code Cease, and the Error Subcode "Other Condition". If a BGP speaker decides to shut down a session because it is out of resources, such as memory, then the speaker should send a NOTIFICATION message with the Error Code Cease, and the Error Subcode "Out of Resources". ... It is recommended that a BGP speaker implement a backoff mechanism in re-trying a BGP connection after the speaker receives a Cease NOPTIFICATION message with the subcode of ... "Out of Resources". Andrew Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19231 for ; Wed, 10 Sep 2003 11:33:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6xp-0000Oy-Bb; Wed, 10 Sep 2003 11:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x6xI-0000OH-Ip for idr@optimus.ietf.org; Wed, 10 Sep 2003 11:32:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04275 for ; Wed, 10 Sep 2003 11:32:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x6xH-0004oo-00 for idr@ietf.org; Wed, 10 Sep 2003 11:32:27 -0400 Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx with esmtp (Exim 4.12) id 19x6xH-0004ol-00 for idr@ietf.org; Wed, 10 Sep 2003 11:32:27 -0400 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h8AFZ5hs019089; Wed, 10 Sep 2003 08:35:05 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h8AFWPk03437; Wed, 10 Sep 2003 08:32:25 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Jeffrey Haas cc: "Wijnen, Bert (Bert)" , IDR WG In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155026F6E83@nl0006exch001u.nl.lucent.com> <20030910090412.A28220@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Idr] Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 08:32:24 -0700 (PDT) [ list address changed to . plz update charter page. ] On Wed, 10 Sep 2003, Jeffrey Haas wrote: > On Wed, Sep 10, 2003 at 09:14:46AM +0200, Wijnen, Bert (Bert) wrote: > > Thanks for the (partial) review Mike. > > I am sure it will be helpfull... I have not read it in detail > > yet... hope to do so later this week. > > > > I assume author and WG will respond with fixes and or > > answers. > > I accept all of the suggested changes unless there is further feedback > from the WG. Meanwhile, I'll hold off issuing another version of > the draft pending your review. Allow me to add some clarifications regarding this: > (b) The smidiff report indicates that several objects that RFC 1657 > declared as 'obsolete' have been promoted to a status of > 'deprecated', in violation of SMIv2 revision rules: > > BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpRcvdPathAttrTable' > BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrEntry' > BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrPeer' > BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrDestNetwork' > BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrOrigin' > BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrASPath' > BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrNextHop' > BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to > `deprecated' for `bgpPathAttrInterASMetric' > BGP4-MIB.my:803 [2] {status-change} status change from `deprecated' > to `current' for `bgpEstablished' > BGP4-MIB.my:812 [2] {status-change} status change from `deprecated' > to `current' for `bgpBackwardTransition' > > Unless the WG had a specific reason for making this change, I would > be inclined to recommend that the status of these definitions be > changed back to 'obsolete'. - First, the status-change messages for bgpEstablished and bgpBackwardTransition are wrong (the change was from current to deprecated) and should be ignored. I will file a bug report with the smidiff maintainers. - Second, the group bgp4MIBRcvdPathAttrGroup, which contains all of the accessible columns in the bgpRcvdPathAttrTable, has a status of 'deprecated'. That is legal, even though the contained objects themselves have a status of 'obsolete', but the WG may prefer for bgp4MIBRcvdPathAttrGroup have a status of 'obsolete'. If its status is changed be sure to update the DESCRIPTION clause to match. Thanks, Mike Heard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA10525 for ; Wed, 10 Sep 2003 09:04:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 148B291222; Wed, 10 Sep 2003 09:04:32 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D893B91223; Wed, 10 Sep 2003 09:04:31 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C431391222 for ; Wed, 10 Sep 2003 09:04:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD5D35DDBB; Wed, 10 Sep 2003 09:04:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [65.247.36.216]) by segue.merit.edu (Postfix) with ESMTP id 504A25DD9F for ; Wed, 10 Sep 2003 09:04:30 -0400 (EDT) Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8AD4NCn017019; Wed, 10 Sep 2003 09:04:23 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8AD4I1X017009; Wed, 10 Sep 2003 09:04:18 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8AD4DE28233; Wed, 10 Sep 2003 09:04:13 -0400 (EDT) Date: Wed, 10 Sep 2003 09:04:13 -0400 From: Jeffrey Haas To: "Wijnen, Bert (Bert)" Cc: "C. M. Heard" , IDR WG Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Message-ID: <20030910090412.A28220@nexthop.com> References: <7D5D48D2CAA3D84C813F5B154F43B155026F6E83@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155026F6E83@nl0006exch001u.nl.lucent.com>; from bwijnen@lucent.com on Wed, Sep 10, 2003 at 09:14:46AM +0200 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Wed, Sep 10, 2003 at 09:14:46AM +0200, Wijnen, Bert (Bert) wrote: > Thanks for the (partial) review Mike. > I am sure it will be helpfull... I have not read it in detail > yet... hope to do so later this week. > > I assume author and WG will respond with fixes and or > answers. I accept all of the suggested changes unless there is further feedback from the WG. Meanwhile, I'll hold off issuing another version of the draft pending your review. -- Jeff Haas NextHop Technologies Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA06974 for ; Wed, 10 Sep 2003 08:01:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x3eh-0001hf-KP; Wed, 10 Sep 2003 08:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x3ec-0001g7-Of for idr@optimus.ietf.org; Wed, 10 Sep 2003 08:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26673 for ; Wed, 10 Sep 2003 08:00:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x3eb-0003Ds-00 for idr@ietf.org; Wed, 10 Sep 2003 08:00:57 -0400 Received: from web41808.mail.yahoo.com ([66.218.93.142]) by ietf-mx with smtp (Exim 4.12) id 19x3eb-0003Dg-00 for idr@ietf.org; Wed, 10 Sep 2003 08:00:57 -0400 Message-ID: <20030910120026.69193.qmail@web41808.mail.yahoo.com> Received: from [203.200.20.226] by web41808.mail.yahoo.com via HTTP; Wed, 10 Sep 2003 13:00:26 BST From: =?iso-8859-1?q?John=20Smith?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Slides Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 13:00:26 +0100 (BST) Hi, Can we concerned authorities please upload the slides and the meeting minutes on the ietf web page for the 57th meeting. John ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15717 for ; Tue, 9 Sep 2003 10:59:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjxN-0002Eq-AT; Tue, 09 Sep 2003 10:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjwo-0002EC-CR for idr@optimus.ietf.org; Tue, 09 Sep 2003 10:58:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15172 for ; Tue, 9 Sep 2003 10:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjwZ-0004xf-00 for idr@ietf.org; Tue, 09 Sep 2003 10:58:11 -0400 Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx with esmtp (Exim 4.12) id 19wjwY-0004xU-00 for idr@ietf.org; Tue, 09 Sep 2003 10:58:11 -0400 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h89F0Yhs020036 for ; Tue, 9 Sep 2003 08:00:34 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h89Ew4o00340 for ; Tue, 9 Sep 2003 07:58:04 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs X-Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h88JBxm08630; Mon, 8 Sep 2003 12:11:59 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Jeffrey Haas cc: IDR WG , "Wijnen, Bert (Bert)" In-Reply-To: <200309081052.GAA09884@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Tue, 9 Sep 2003 07:58:01 -0700 (PDT) ReSent-From: "C. M. Heard" ReSent-To: idr@ietf.org ReSent-Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt ReSent-Message-ID: Subject: [Idr] Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Sep 2003 12:11:57 -0700 (PDT) Resent-Date: Tue, 09 Sep 2003 10:59:01 -0400 Greetings, I noticed the I-D announcement and would like to make a few MIB doctor comments on this draft (but please note that this is the result of a spot check ... I have NOT done a full MIB doctor review of this document). 1.) My understanding from reading the draft and from previous e-mail messages is that this document is supposed to obsolete RFCs 1657 and 1269. If that understanding is correct, an explicit statement to that effect, such as This memo obsoletes RFC 1657 and RFC 1269. must be added both to the Abstract and to the Introduction. 2.) I also understand from reading the draft and from previous e-mail messages that the main purpose of this document is to provide a clean MIB module that documents the behaviour of deployed implementations, and that a new MIB module to overcome numerous shortcomings is under development and will in due course be submitted for standards-track consideration. Under the circumstances it may be appropriate to submit this document as an Informational RFC rather than for the standards track, as indicated in the WG last call: if a replacement is under development, there is no reason to progress this document along the standards track, and submitting it for Proposed Standard implies such an intent. 3.) In reviewing the smidiff report between the MIB module in this draft and the one in RFC 1657 I noticed a couple of questionable things: (a) There are no REVISION/DESCRIPTION pairs for the previous incarnations of the MIB module. This gives rise to the following error message: RFC1657-MIB.my:25 [3] {revision-removed} revision `1994-05-05 00:00' removed This can be easily fixed by the following change to the MIB module at the end of the REVISION/DESCRIPTION pair now present: OLD: bgpPeerInTotalMessages, bgpPeerOutTotalMessages" NEW: bgpPeerInTotalMessages, bgpPeerOutTotalMessages. Published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "199405050000Z" DESCRIPTION "Translated to SMIv2 and published as RFC 1657." REVISION "199110261839Z" DESCRIPTION "Initial version, published as RFC 1269." Note that "199405050000Z is copied from the LAST-UPDATED clause in the MIB module in RFC 1657, which is standard practice. Since that MIB module did not contain a REVISION/DESCRIPTION pair for the RFC 1269 version, and since RFC 1269 was an SMIv1 module and so has no LAST-UPDATED or REVISION clause, the date "199110261839Z" is synthesized from the UTC time stamp Oct 26 18:39:09 1991 on http://www.rfc-editor.org/rfc/rfc1269.txt In my opinion, this is a "must-do" change. (b) The smidiff report indicates that several objects that RFC 1657 declared as 'obsolete' have been promoted to a status of 'deprecated', in violation of SMIv2 revision rules: BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpRcvdPathAttrTable' BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrEntry' BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrPeer' BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrDestNetwork' BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrOrigin' BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrASPath' BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrNextHop' BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to `deprecated' for `bgpPathAttrInterASMetric' BGP4-MIB.my:803 [2] {status-change} status change from `deprecated' to `current' for `bgpEstablished' BGP4-MIB.my:812 [2] {status-change} status change from `deprecated' to `current' for `bgpBackwardTransition' Unless the WG had a specific reason for making this change, I would be inclined to recommend that the status of these definitions be changed back to 'obsolete'. 4.) In the DESCRIPTION clause of bgp4MIBNotificationGroup there is a typo. Here is the fix: OLD: Obsoletes bgp4MIBNotificationGroup." NEW: Obsoletes bgp4MIBTrapGroup." In my opinion, this is also another "must-do" change. Regards, Mike Heard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA16376 for ; Tue, 9 Sep 2003 00:39:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waHN-00035s-Kf; Tue, 09 Sep 2003 00:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19waGc-00035J-Am for idr@optimus.ietf.org; Tue, 09 Sep 2003 00:38:14 -0400 Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07148 for ; Tue, 9 Sep 2003 00:38:00 -0400 (EDT) Received: from tcb.net (dhcp64-134-59-85.wgb.bos.wayport.net [64.134.59.85]) by dog.tcb.net (Postfix) with ESMTP id 3CCAB20299 for ; Mon, 8 Sep 2003 22:36:52 -0600 (MDT) Subject: Re: [Idr] graceful restart vs flap dampening Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: IDR mailing list Content-Transfer-Encoding: 7bit In-Reply-To: <1iy8wzhrec.fsf@coors.torrentnet.com> Message-Id: <3BCC1452-E27F-11D7-86AC-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Sep 2003 22:36:52 -0600 On Monday, September 8, 2003, at 04:00 PM, Kaarthik Sivakumar wrote: > I am interested in how route flap dampening would interact with > graceful restart. Should stale routes be considered flapping and the > figure of merit appropriately increased? Should this be done when the > peer goes down or when the peer comes back up and doesnt readvertise > one of the stale routes, Only the latter (as usual), IMO. Else you scope the usefulness of graceful restart. > thus forcing the route to be withdrawn from > the listening speaker's forwarding? The graceful restart draft doesnt > refer to this interaction. I don't believe it should, as the functionality is clearly orthogonal. > In my view, the figure of merit for the route should only be affected > when the restarting speaker comes up and doesnt readvertise the stale > route. Maybe this is clear from the draft and the route flap dampening > rfc and I just missed it. If so, let me know what I am missing. > Otherwise I would suggest some text in the graceful restart draft > about this interaction. I don't believe you're missing anything, this is implied behavior. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (ietf-ops.ietf.org [132.151.6.20]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA00938 for ; Mon, 8 Sep 2003 18:01:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wU4Q-00004r-8B; Mon, 08 Sep 2003 18:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wU43-0008VE-8q for idr@optimus.ietf.org; Mon, 08 Sep 2003 18:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23954 for ; Mon, 8 Sep 2003 18:00:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wU40-0001DG-00 for idr@ietf.org; Mon, 08 Sep 2003 18:00:48 -0400 Received: from emerson.torrentnet.com ([198.78.51.110]) by ietf-mx with esmtp (Exim 4.12) id 19wU3z-0001DD-00 for idr@ietf.org; Mon, 08 Sep 2003 18:00:47 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h88M0hr09919 for ; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) Received: from coors.torrentnet.com (coors.torrentnet.com [4.21.152.11]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h88M0h689918 for ; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) Received: (from kaarthik@localhost) by coors.torrentnet.com (8.11.2/8.11.2) id h88M0hR33090; Mon, 8 Sep 2003 18:00:43 -0400 (EDT) X-Authentication-Warning: coors.torrentnet.com: kaarthik set sender to kaarthik@torrentnet.com using -f To: IDR mailing list From: Kaarthik Sivakumar Message-ID: <1iy8wzhrec.fsf@coors.torrentnet.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.1 (Channel Islands, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Idr] graceful restart vs flap dampening Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Sep 2003 18:00:43 -0400 I am interested in how route flap dampening would interact with graceful restart. Should stale routes be considered flapping and the figure of merit appropriately increased? Should this be done when the peer goes down or when the peer comes back up and doesnt readvertise one of the stale routes, thus forcing the route to be withdrawn from the listening speaker's forwarding? The graceful restart draft doesnt refer to this interaction. In my view, the figure of merit for the route should only be affected when the restarting speaker comes up and doesnt readvertise the stale route. Maybe this is clear from the draft and the route flap dampening rfc and I just missed it. If so, let me know what I am missing. Otherwise I would suggest some text in the graceful restart draft about this interaction. Thanks.. kaarthik _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA02190 for ; Mon, 8 Sep 2003 06:53:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E9C391257; Mon, 8 Sep 2003 06:53:03 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E850C91258; Mon, 8 Sep 2003 06:53:02 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD8ED91257 for ; Mon, 8 Sep 2003 06:53:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96B855DDE1; Mon, 8 Sep 2003 06:53:01 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 25CED5DDD0 for ; Mon, 8 Sep 2003 06:52:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09884; Mon, 8 Sep 2003 06:52:49 -0400 (EDT) Message-Id: <200309081052.GAA09884@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt Date: Mon, 08 Sep 2003 06:52:48 -0400 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 : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : J. Haas, S. Hares Filename : draft-ietf-idr-bgp4-mib-12.txt Pages : 35 Date : 2003-9-5 This memo is an extension to the SNMP MIB. The origin of this memo is from RFC 1269 'Definitions of Managed Objects for the Border Gateway Protocol (Version 3)', which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB was converted to use the SNMPv2 SMI, as well as updates references to the current SNMP framework documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-mib-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-5130848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-5130848.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03205 for ; Thu, 4 Sep 2003 11:59:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEB6C91216; Thu, 4 Sep 2003 11:58:52 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA9A3912CF; Thu, 4 Sep 2003 11:58:51 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C296891216 for ; Thu, 4 Sep 2003 11:58:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B0FB15DDEA; Thu, 4 Sep 2003 11:58:50 -0400 (EDT) Delivered-To: idr@merit.edu Received: from state.arbornetworks.com (state.arbornetworks.com [204.181.64.20]) by segue.merit.edu (Postfix) with ESMTP id 8BF6C5DDC3 for ; Thu, 4 Sep 2003 11:58:50 -0400 (EDT) Received: from tcb.net (bedford.lex.arbor.net [204.118.128.2]) by state.arbornetworks.com (Arbor Networks mail relay) with ESMTP id C5D766354F for ; Thu, 4 Sep 2003 11:58:49 -0400 (EDT) Date: Thu, 4 Sep 2003 09:58:48 -0600 Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: idr@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200309041545.h84FjBmO031633@mail.avici.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-idr@merit.edu Precedence: bulk > > The value of X varies with implementation but there is always some > practical limit. You could put a sentence in stating that. OK, I'll add something to that effect.. -danny Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02876 for ; Thu, 4 Sep 2003 11:48:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0675912D8; Thu, 4 Sep 2003 11:45:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29B8291312; Thu, 4 Sep 2003 11:45:45 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A0459131C for ; Thu, 4 Sep 2003 11:45:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1777A5DDC3; Thu, 4 Sep 2003 11:45:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.avici.com (unknown [12.38.212.174]) by segue.merit.edu (Postfix) with ESMTP id 8EF995DDBE for ; Thu, 4 Sep 2003 11:45:39 -0400 (EDT) Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mail.avici.com (8.12.8/8.12.8) with ESMTP id h84FjBmO031633; Thu, 4 Sep 2003 11:45:12 -0400 Message-Id: <200309041545.h84FjBmO031633@mail.avici.com> To: Danny McPherson Cc: Erblichs , idr@merit.edu Reply-To: curtis@fictitious.org Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt In-reply-to: Your message of "Thu, 04 Sep 2003 09:31:13 MDT." Date: Thu, 04 Sep 2003 11:48:39 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message , Danny McPherson writ es: > > > 6) 8. Internal BGP in Large ... > > > > "with a large number of peers" > > > > Should this be specified? with the number of peers > > greater than "X" > > I'm not sure X can be defined, as it's relative. I think it's > probably OK as is. The value of X varies with implementation but there is always some practical limit. You could put a sentence in stating that. Curtis Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02456 for ; Thu, 4 Sep 2003 11:36:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A54DD912DA; Thu, 4 Sep 2003 11:33:20 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB3E0912E7; Thu, 4 Sep 2003 11:33:17 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4051912DA for ; Thu, 4 Sep 2003 11:31:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A3F25DD8E; Thu, 4 Sep 2003 11:31:17 -0400 (EDT) Delivered-To: idr@merit.edu Received: from state.arbornetworks.com (state.arbornetworks.com [204.181.64.20]) by segue.merit.edu (Postfix) with ESMTP id AFA125DDF2 for ; Thu, 4 Sep 2003 11:31:16 -0400 (EDT) Received: from tcb.net (bedford.lex.arbor.net [204.118.128.2]) by state.arbornetworks.com (Arbor Networks mail relay) with ESMTP id C75E0633DA; Thu, 4 Sep 2003 11:31:15 -0400 (EDT) Date: Thu, 4 Sep 2003 09:31:13 -0600 Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: idr@merit.edu To: Erblichs From: Danny McPherson In-Reply-To: <3F5663C3.1C96E741@earthlink.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-idr@merit.edu Precedence: bulk On Wednesday, September 3, 2003, at 03:57 PM, Erblichs wrote: 1-5: fixed! > 6) 8. Internal BGP in Large ... > > "with a large number of peers" > > Should this be specified? with the number of peers > greater than "X" I'm not sure X can be defined, as it's relative. I think it's probably OK as is. > > RFC 2065 not in References Should have been 3065. 7-12: fixed! > ------------------ > > B) Non-nits > 1-4: Added some text to address each of these, it should be sufficient. Great feedback, thanks! -danny Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24569 for ; Tue, 2 Sep 2003 11:26:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6BB339126B; Tue, 2 Sep 2003 11:26:32 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B6679126D; Tue, 2 Sep 2003 11:26:31 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70D2C9126B for ; Tue, 2 Sep 2003 11:26:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 534535DDE2; Tue, 2 Sep 2003 11:26:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint2.juniper.net [207.17.136.150]) by segue.merit.edu (Postfix) with ESMTP id C6E185DD8C for ; Tue, 2 Sep 2003 11:26:29 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h82FQTY90754 for ; Tue, 2 Sep 2003 08:26:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200309021526.h82FQTY90754@merlot.juniper.net> To: idr@merit.edu Subject: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51613.1062516389.1@juniper.net> Date: Tue, 02 Sep 2003 08:26:29 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start the WG Last Call on advacing draft-ietf-idr-bgp4-experience-protocol-01.txt to an Informational RFC. The Last Call ends Sep 16, 2003. Yakov. ------- Forwarded Message Date: Wed, 27 Aug 2003 10:27:11 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-01.txt - --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 : Experience with the BGP-4 Protocol Author(s) : D. McPherson, K. Patel Filename : draft-ietf-idr-bgp4-experience-protocol-01.txt Pages : 18 Date : 2003-8-27 The purpose of this memo is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-01. txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-27103600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-01.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-27103600.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message