From mailman-admin@ietf.org Fri Aug 1 09:27:01 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 JAA09772 for ; Fri, 1 Aug 2003 09:02:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZXW-0001jQ-FQ for idr-archive@ietf.org; Fri, 01 Aug 2003 09:01:46 -0400 Date: Fri, 01 Aug 2003 09:01:46 -0400 Message-ID: <20030801130146.29120.48427.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 idr-admin@ietf.org Fri Aug 1 10:06: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 KAA22254; Fri, 1 Aug 2003 10:06:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iaYH-0002fa-00; Fri, 01 Aug 2003 10:06:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iaYG-0002fW-00; Fri, 01 Aug 2003 10:06:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaXi-0004oV-OS; Fri, 01 Aug 2003 10: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 19iaXd-0004oF-Ms for idr@optimus.ietf.org; Fri, 01 Aug 2003 10:05:57 -0400 Received: from pc7 (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 KAA22111 for ; Fri, 1 Aug 2003 10:05:50 -0400 (EDT) From: lotterysl@netscape.net Message-Id: <200308011405.KAA22111@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: lotterysl@netscape.net X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] WINNING 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: Fri, 1 Aug 2003 16:06:26 +0200 LOTTERY LA PRIMITIVA. C/GUZMAN EL BUENO,137 MADRID - ESPANA. TEL:0034 696 026 500 FROM: THE DESK 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 announcement, of winners of the LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMMES held on 6 June,2003. Your name is attached to ticket number 004-05117963-198, with serial number 99375 drew the lucky numbers 05-07-11-12-13-27, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of EUROS 647,828,87 Thousand in cash credited to file No:LP/26510460037/03.This is from total prize money of EUROS 80,400,000.00 shared among the twenty two international winners in this category. All participants were selected through a computer ballot system drawn from 25,000 names from Australia,New Zealand, America,Europe, North America and Asia as part of International Promotions Programme, which is conducted annually. CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes Euros 1.1 billion International Lottery. To begin your claim, please contact ESPAOL CREDITO SEGURIDAD, MADRID-SPAIN ,PHONE NUMBER (+34 608 701 649) MR JUAN CARLOS REDONDO, FOREIGN OPERATION MANAGERS, Email;(lottery-primitiva@winning.com). For due processing and remittance of your prize money to a designated account . Remember, all prize money must be claimed not later than 10 September 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 one of your correspondences with the security company . Furthermore, should there be any change of your address,do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programme. Sincerely, FERNANDO TORRES RODRIGUEZ. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Aug 1 10:07: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 KAA22361 for ; Fri, 1 Aug 2003 10:07: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 19iaYK-0004rI-8N for idr-archive@odin.ietf.org; Fri, 01 Aug 2003 10:06:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71E6eh2018676 for idr-archive@odin.ietf.org; Fri, 1 Aug 2003 10:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaYK-0004r9-5K for idr-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 10:06:40 -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 KAA22254; Fri, 1 Aug 2003 10:06:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iaYH-0002fa-00; Fri, 01 Aug 2003 10:06:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iaYG-0002fW-00; Fri, 01 Aug 2003 10:06:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaXi-0004oV-OS; Fri, 01 Aug 2003 10: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 19iaXd-0004oF-Ms for idr@optimus.ietf.org; Fri, 01 Aug 2003 10:05:57 -0400 Received: from pc7 (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 KAA22111 for ; Fri, 1 Aug 2003 10:05:50 -0400 (EDT) From: lotterysl@netscape.net Message-Id: <200308011405.KAA22111@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: lotterysl@netscape.net X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] WINNING 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: Fri, 1 Aug 2003 16:06:26 +0200 LOTTERY LA PRIMITIVA. C/GUZMAN EL BUENO,137 MADRID - ESPANA. TEL:0034 696 026 500 FROM: THE DESK 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 announcement, of winners of the LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMMES held on 6 June,2003. Your name is attached to ticket number 004-05117963-198, with serial number 99375 drew the lucky numbers 05-07-11-12-13-27, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of EUROS 647,828,87 Thousand in cash credited to file No:LP/26510460037/03.This is from total prize money of EUROS 80,400,000.00 shared among the twenty two international winners in this category. All participants were selected through a computer ballot system drawn from 25,000 names from Australia,New Zealand, America,Europe, North America and Asia as part of International Promotions Programme, which is conducted annually. CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes Euros 1.1 billion International Lottery. To begin your claim, please contact ESPAOL CREDITO SEGURIDAD, MADRID-SPAIN ,PHONE NUMBER (+34 608 701 649) MR JUAN CARLOS REDONDO, FOREIGN OPERATION MANAGERS, Email;(lottery-primitiva@winning.com). For due processing and remittance of your prize money to a designated account . Remember, all prize money must be claimed not later than 10 September 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 one of your correspondences with the security company . Furthermore, should there be any change of your address,do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programme. Sincerely, FERNANDO TORRES RODRIGUEZ. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Aug 1 10:10: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 KAA23080 for ; Fri, 1 Aug 2003 10:10:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iac3-0005GL-3t for idr-archive@odin.ietf.org; Fri, 01 Aug 2003 10:10:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71EAVt7020223 for idr-archive@odin.ietf.org; Fri, 1 Aug 2003 10:10:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iac2-0005Fl-VV for idr-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 10:10:31 -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 JAA18653 for ; Fri, 1 Aug 2003 09:38:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iZqP-0006ZM-00 for idr-web-archive@ietf.org; Fri, 01 Aug 2003 09:21:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iZmo-0005pG-00 for idr-web-archive@ietf.org; Fri, 01 Aug 2003 09:17:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZba-00088d-12 for idr-web-archive@ietf.org; Fri, 01 Aug 2003 09:05:58 -0400 Date: Fri, 01 Aug 2003 09:05:58 -0400 Message-ID: <20030801130558.29120.63124.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 idr-admin@ietf.org Sat Aug 2 06:23:08 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 GAA10332; Sat, 2 Aug 2003 06:23:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19itXc-0002oQ-00; Sat, 02 Aug 2003 06:23:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19itXb-0002oN-00; Sat, 02 Aug 2003 06:23:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19itXR-0000YT-RT; Sat, 02 Aug 2003 06:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19itXH-0000YC-6k for idr@optimus.ietf.org; Sat, 02 Aug 2003 06:22:51 -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 GAA10321 for ; Sat, 2 Aug 2003 06:22:42 -0400 (EDT) From: fredricktaylor00@netscape.net Message-Id: <200308021022.GAA10321@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: fredricktaylor00@netscape.net X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] KIND ATTENTION !! 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, 2 Aug 2003 12:22:48 +0200 EXTREMELY CONFIDENTIAL. ATTENTION: THE PRESIDENT/CHAIRMAN. First, may I solicit your confidentiality in this transaction, this by virtue of its nature I am Fredrick Taylor, a cousin to the president Charles Taylor of Liberia. As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes (containing cash of $39.8m)secured in a diplomatic custody in madrid-spain and these diplomatic agents are not aware of the contents of this consignment. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out that the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this funds will be use in capital investments or you advice us on any lucrative project to put the funds into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project. Upon receipt of your positive response, I will suggest we meet possible in madrid-spain for us to work out modalities concerning the investment of the money and/or the ratio you will receive after the collection of the boxes from these diplomatic agents in madrid-spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address.I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Best Regards, F . Taylor. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Sat Aug 2 06:23:40 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 GAA10360 for ; Sat, 2 Aug 2003 06:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19itXg-0000az-JG for idr-archive@odin.ietf.org; Sat, 02 Aug 2003 06:23:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h72ANGFR002290 for idr-archive@odin.ietf.org; Sat, 2 Aug 2003 06:23:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19itXg-0000ar-BC for idr-web-archive@optimus.ietf.org; Sat, 02 Aug 2003 06:23: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 GAA10332; Sat, 2 Aug 2003 06:23:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19itXc-0002oQ-00; Sat, 02 Aug 2003 06:23:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19itXb-0002oN-00; Sat, 02 Aug 2003 06:23:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19itXR-0000YT-RT; Sat, 02 Aug 2003 06:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19itXH-0000YC-6k for idr@optimus.ietf.org; Sat, 02 Aug 2003 06:22:51 -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 GAA10321 for ; Sat, 2 Aug 2003 06:22:42 -0400 (EDT) From: fredricktaylor00@netscape.net Message-Id: <200308021022.GAA10321@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: fredricktaylor00@netscape.net X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] KIND ATTENTION !! 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, 2 Aug 2003 12:22:48 +0200 EXTREMELY CONFIDENTIAL. ATTENTION: THE PRESIDENT/CHAIRMAN. First, may I solicit your confidentiality in this transaction, this by virtue of its nature I am Fredrick Taylor, a cousin to the president Charles Taylor of Liberia. As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes (containing cash of $39.8m)secured in a diplomatic custody in madrid-spain and these diplomatic agents are not aware of the contents of this consignment. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out that the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this funds will be use in capital investments or you advice us on any lucrative project to put the funds into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project. Upon receipt of your positive response, I will suggest we meet possible in madrid-spain for us to work out modalities concerning the investment of the money and/or the ratio you will receive after the collection of the boxes from these diplomatic agents in madrid-spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address.I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Best Regards, F . Taylor. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Aug 4 14:05:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05862; Mon, 4 Aug 2003 14:05:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jji0-0004PA-00; Mon, 04 Aug 2003 14:05:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jji0-0004P5-00; Mon, 04 Aug 2003 14:05:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjhd-0007iq-BR; Mon, 04 Aug 2003 14:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjgv-0007iE-68 for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05837 for ; Mon, 4 Aug 2003 14:04:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjgs-0004Ow-00 for idr@ietf.org; Mon, 04 Aug 2003 14:04:14 -0400 Received: from sea1-f140.sea1.hotmail.com ([207.68.163.140] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19jjgr-0004OY-00 for idr@ietf.org; Mon, 04 Aug 2003 14:04:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Aug 2003 11:03:41 -0700 Received: from 65.198.24.91 by sea1fd.sea1.hotmail.msn.com with HTTP; Mon, 04 Aug 2003 18:03:41 GMT X-Originating-IP: [65.198.24.91] X-Originating-Email: [jaiharil@hotmail.com] From: "jai hari" To: idr@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Aug 2003 18:03:41.0269 (UTC) FILETIME=[BCADC850:01C35AB2] Subject: [Idr] Route refresh/ capability 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, 04 Aug 2003 18:03:41 +0000 Hi, I have a list of basic questions in RFC 2918/3392. Please let me know if these have already been answered in the mail-archives. 1. Is an implementation allowed to support route refresh capability without supporting Multiprotocol capability? RFC 2918 states "If a BGP speaker receives from its peer a ROUTE-REFRESH message with the that the speaker didn't advertise to the peer ". What is the peer advertising if it did not support Multiprotocol capability? 2. RFC 3392 states: "If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer," What about the case where the local speaker receives a capability it does not understand/support.? Should it send a notification - unsupported capability? 3. Are capabilities encoded as a single open optional parameter or multiple open optional parameters? Does the standard require it to be either way? 4. Is restarting hold timer for the session accepted upon receiving a route refresh request? 5. What should be the action ( ignore? ) if route refresh request is received from a peer that did not advertise this capability at all? 6. Is Open message optional parameter length really required to parse the message? ( Is header length not sufficient? ) 7. How should errors in capability length field that does not agree with header length ( or optional parameter length ) be handled? (What is the notification code? Is it open messag errorcode with subcode unspecified? ) 8. Does the standard care how to handle a route refresh request while one is already pending? (Can we just abort and restart the previous adj-rib-out update? ) Thanks, -Jaihari _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Aug 4 14:05:53 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 SMTP id OAA05884 for ; Mon, 4 Aug 2003 14:05:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jji3-0007lM-ML for idr-archive@odin.ietf.org; Mon, 04 Aug 2003 14:05:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74I5Rhu029836 for idr-archive@odin.ietf.org; Mon, 4 Aug 2003 14:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jji3-0007l9-Jh for idr-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 14:05:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05862; Mon, 4 Aug 2003 14:05:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jji0-0004PA-00; Mon, 04 Aug 2003 14:05:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jji0-0004P5-00; Mon, 04 Aug 2003 14:05:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjhd-0007iq-BR; Mon, 04 Aug 2003 14:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjgv-0007iE-68 for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05837 for ; Mon, 4 Aug 2003 14:04:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjgs-0004Ow-00 for idr@ietf.org; Mon, 04 Aug 2003 14:04:14 -0400 Received: from sea1-f140.sea1.hotmail.com ([207.68.163.140] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19jjgr-0004OY-00 for idr@ietf.org; Mon, 04 Aug 2003 14:04:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Aug 2003 11:03:41 -0700 Received: from 65.198.24.91 by sea1fd.sea1.hotmail.msn.com with HTTP; Mon, 04 Aug 2003 18:03:41 GMT X-Originating-IP: [65.198.24.91] X-Originating-Email: [jaiharil@hotmail.com] From: "jai hari" To: idr@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Aug 2003 18:03:41.0269 (UTC) FILETIME=[BCADC850:01C35AB2] Subject: [Idr] Route refresh/ capability 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, 04 Aug 2003 18:03:41 +0000 Hi, I have a list of basic questions in RFC 2918/3392. Please let me know if these have already been answered in the mail-archives. 1. Is an implementation allowed to support route refresh capability without supporting Multiprotocol capability? RFC 2918 states "If a BGP speaker receives from its peer a ROUTE-REFRESH message with the that the speaker didn't advertise to the peer ". What is the peer advertising if it did not support Multiprotocol capability? 2. RFC 3392 states: "If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer," What about the case where the local speaker receives a capability it does not understand/support.? Should it send a notification - unsupported capability? 3. Are capabilities encoded as a single open optional parameter or multiple open optional parameters? Does the standard require it to be either way? 4. Is restarting hold timer for the session accepted upon receiving a route refresh request? 5. What should be the action ( ignore? ) if route refresh request is received from a peer that did not advertise this capability at all? 6. Is Open message optional parameter length really required to parse the message? ( Is header length not sufficient? ) 7. How should errors in capability length field that does not agree with header length ( or optional parameter length ) be handled? (What is the notification code? Is it open messag errorcode with subcode unspecified? ) 8. Does the standard care how to handle a route refresh request while one is already pending? (Can we just abort and restart the previous adj-rib-out update? ) Thanks, -Jaihari _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Aug 4 14:41:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07272; Mon, 4 Aug 2003 14:41:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkGX-0004m8-00; Mon, 04 Aug 2003 14:41:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jkGX-0004m5-00; Mon, 04 Aug 2003 14:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkGT-00011A-5c; Mon, 04 Aug 2003 14:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkFe-00010h-Ga for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07263 for ; Mon, 4 Aug 2003 14:40:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkFb-0004lq-00 for idr@ietf.org; Mon, 04 Aug 2003 14:40:07 -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 19jkFb-0004ln-00 for idr@ietf.org; Mon, 04 Aug 2003 14:40:07 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2003 11:39:37 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h74IdY7F001143; Mon, 4 Aug 2003 11:39:35 -0700 (PDT) Received: from [64.101.214.208] (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 OAA05082; Mon, 4 Aug 2003 14:39:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: "jai hari" From: "John G. Scudder" Subject: Re: [Idr] Route refresh/ capability 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: Mon, 4 Aug 2003 14:39:31 -0400 At 6:03 PM +0000 8/4/03, jai hari wrote: >2. RFC 3392 states: "If a BGP speaker that supports a certain >capability determines that > its peer doesn't support this capability, the speaker MAY send a > NOTIFICATION message to the peer," > What about the case where the local speaker receives a capability >it does not understand/support.? > Should it send a notification - unsupported capability? No, it should not. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Aug 4 14:41: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 SMTP id OAA07295 for ; Mon, 4 Aug 2003 14:41: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 19jkGb-00013Y-5s for idr-archive@odin.ietf.org; Mon, 04 Aug 2003 14:41:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74If9Vl004054 for idr-archive@odin.ietf.org; Mon, 4 Aug 2003 14:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkGb-00013J-2J for idr-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 14:41:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07272; Mon, 4 Aug 2003 14:41:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkGX-0004m8-00; Mon, 04 Aug 2003 14:41:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jkGX-0004m5-00; Mon, 04 Aug 2003 14:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkGT-00011A-5c; Mon, 04 Aug 2003 14:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkFe-00010h-Ga for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07263 for ; Mon, 4 Aug 2003 14:40:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkFb-0004lq-00 for idr@ietf.org; Mon, 04 Aug 2003 14:40:07 -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 19jkFb-0004ln-00 for idr@ietf.org; Mon, 04 Aug 2003 14:40:07 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2003 11:39:37 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h74IdY7F001143; Mon, 4 Aug 2003 11:39:35 -0700 (PDT) Received: from [64.101.214.208] (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 OAA05082; Mon, 4 Aug 2003 14:39:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: "jai hari" From: "John G. Scudder" Subject: Re: [Idr] Route refresh/ capability 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: Mon, 4 Aug 2003 14:39:31 -0400 At 6:03 PM +0000 8/4/03, jai hari wrote: >2. RFC 3392 states: "If a BGP speaker that supports a certain >capability determines that > its peer doesn't support this capability, the speaker MAY send a > NOTIFICATION message to the peer," > What about the case where the local speaker receives a capability >it does not understand/support.? > Should it send a notification - unsupported capability? No, it should not. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Aug 4 14:48:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07477; Mon, 4 Aug 2003 14:48:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkOD-0004qB-00; Mon, 04 Aug 2003 14:49:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jkOC-0004q8-00; Mon, 04 Aug 2003 14:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkOD-0001D3-IC; Mon, 04 Aug 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkO0-0001Ci-Iy for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07456 for ; Mon, 4 Aug 2003 14:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkNx-0004pC-00 for idr@ietf.org; Mon, 04 Aug 2003 14:48:45 -0400 Received: from [205.219.34.104] (helo=exch-srv.CoronaNetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19jkNu-0004oV-00 for idr@ietf.org; Mon, 04 Aug 2003 14:48:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Idr] Route refresh/ capability Message-ID: Thread-Topic: [Idr] Route refresh/ capability Thread-Index: AcNasoN338mO+hooRwe9YdnTovl+PAABX6m9 From: "Ankur Goyal" To: "jai hari" , Content-Transfer-Encoding: base64 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, 4 Aug 2003 11:44:40 -0700 Content-Transfer-Encoding: base64 PiAzLiBBcmUgY2FwYWJpbGl0aWVzIGVuY29kZWQgYXMgYSBzaW5nbGUgb3BlbiBvcHRpb25hbCBw YXJhbWV0ZXIgb3IgbXVsdGlwbGUNCj4gb3BlbiBvcHRpb25hbCBwYXJhbWV0ZXJzPw0KPiBEb2Vz IHRoZSBzdGFuZGFyZCByZXF1aXJlIGl0IHRvIGJlIGVpdGhlciB3YXk/DQoNCg0KVGhlIHN0YW5k YXJkIGFsbG93cyBpdCB0byBiZSBlaXRoZXIgd2F5LiAgDQoNCg0KLS1Bbmt1cg0KDQo= _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Aug 4 14:49: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 SMTP id OAA07507 for ; Mon, 4 Aug 2003 14:49: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 19jkOG-0001FQ-Lk for idr-archive@odin.ietf.org; Mon, 04 Aug 2003 14:49:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74In4pV004790 for idr-archive@odin.ietf.org; Mon, 4 Aug 2003 14:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkOG-0001FB-HE for idr-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 14:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07477; Mon, 4 Aug 2003 14:48:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkOD-0004qB-00; Mon, 04 Aug 2003 14:49:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jkOC-0004q8-00; Mon, 04 Aug 2003 14:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkOD-0001D3-IC; Mon, 04 Aug 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkO0-0001Ci-Iy for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07456 for ; Mon, 4 Aug 2003 14:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkNx-0004pC-00 for idr@ietf.org; Mon, 04 Aug 2003 14:48:45 -0400 Received: from [205.219.34.104] (helo=exch-srv.CoronaNetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19jkNu-0004oV-00 for idr@ietf.org; Mon, 04 Aug 2003 14:48:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Idr] Route refresh/ capability Message-ID: Thread-Topic: [Idr] Route refresh/ capability Thread-Index: AcNasoN338mO+hooRwe9YdnTovl+PAABX6m9 From: "Ankur Goyal" To: "jai hari" , Content-Transfer-Encoding: base64 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, 4 Aug 2003 11:44:40 -0700 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiAzLiBBcmUgY2FwYWJpbGl0aWVzIGVuY29kZWQgYXMgYSBzaW5nbGUgb3BlbiBvcHRpb25hbCBw YXJhbWV0ZXIgb3IgbXVsdGlwbGUNCj4gb3BlbiBvcHRpb25hbCBwYXJhbWV0ZXJzPw0KPiBEb2Vz IHRoZSBzdGFuZGFyZCByZXF1aXJlIGl0IHRvIGJlIGVpdGhlciB3YXk/DQoNCg0KVGhlIHN0YW5k YXJkIGFsbG93cyBpdCB0byBiZSBlaXRoZXIgd2F5LiAgDQoNCg0KLS1Bbmt1cg0KDQo= _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Aug 5 00:55:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20052; Tue, 5 Aug 2003 00:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jtqo-0007Xq-00; Tue, 05 Aug 2003 00:55:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jtqo-0007Xn-00; Tue, 05 Aug 2003 00:55:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jtqf-0008KY-AZ; Tue, 05 Aug 2003 00:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jtq9-0008KB-9B for idr@optimus.ietf.org; Tue, 05 Aug 2003 00:54:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20049 for ; Tue, 5 Aug 2003 00:54:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jtq6-0007Xi-00 for idr@ietf.org; Tue, 05 Aug 2003 00:54:26 -0400 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19jtq4-0007XU-00 for idr@ietf.org; Tue, 05 Aug 2003 00:54:24 -0400 Received: (qmail 325 invoked by uid 510); 5 Aug 2003 04:55:16 -0000 Message-ID: <20030805045516.324.qmail@webmail31.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 aug 2003 04:55:16 -0000 MIME-Version: 1.0 From: "naresh paliwal" Reply-To: "naresh paliwal" To: "John G.Scudder" Cc: idr@ietf.org, "jai hari" Subject: Re: Re: [Idr] Route refresh/ capability Content-type: text/plain; format=flowed Content-Disposition: inline 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: 5 Aug 2003 04:55:16 -0000 Yeah!! john is right, unless the mib variable strict capabily match is set.. Otherwise notification is needed.. -Naresh On Tue, 05 Aug 2003 John G. Scudder wrote : >At 6:03 PM +0000 8/4/03, jai hari wrote: >>2. RFC 3392 states: "If a BGP speaker that supports a certain >>capability determines that >> its peer doesn't support this capability, the speaker MAY >>send a >> NOTIFICATION message to the peer," >> What about the case where the local speaker receives a >>capability it does not understand/support.? >> Should it send a notification - unsupported capability? > >No, it should not. > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Aug 5 00:55: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 SMTP id AAA20075 for ; Tue, 5 Aug 2003 00:55: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 19jtqr-0008Mx-Th for idr-archive@odin.ietf.org; Tue, 05 Aug 2003 00:55:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h754tDPr032165 for idr-archive@odin.ietf.org; Tue, 5 Aug 2003 00:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jtqr-0008Mi-PB for idr-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 00:55:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20052; Tue, 5 Aug 2003 00:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jtqo-0007Xq-00; Tue, 05 Aug 2003 00:55:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jtqo-0007Xn-00; Tue, 05 Aug 2003 00:55:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jtqf-0008KY-AZ; Tue, 05 Aug 2003 00:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jtq9-0008KB-9B for idr@optimus.ietf.org; Tue, 05 Aug 2003 00:54:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20049 for ; Tue, 5 Aug 2003 00:54:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jtq6-0007Xi-00 for idr@ietf.org; Tue, 05 Aug 2003 00:54:26 -0400 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19jtq4-0007XU-00 for idr@ietf.org; Tue, 05 Aug 2003 00:54:24 -0400 Received: (qmail 325 invoked by uid 510); 5 Aug 2003 04:55:16 -0000 Message-ID: <20030805045516.324.qmail@webmail31.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 aug 2003 04:55:16 -0000 MIME-Version: 1.0 From: "naresh paliwal" Reply-To: "naresh paliwal" To: "John G.Scudder" Cc: idr@ietf.org, "jai hari" Subject: Re: Re: [Idr] Route refresh/ capability Content-type: text/plain; format=flowed Content-Disposition: inline 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: 5 Aug 2003 04:55:16 -0000 Yeah!! john is right, unless the mib variable strict capabily match is set.. Otherwise notification is needed.. -Naresh On Tue, 05 Aug 2003 John G. Scudder wrote : >At 6:03 PM +0000 8/4/03, jai hari wrote: >>2. RFC 3392 states: "If a BGP speaker that supports a certain >>capability determines that >> its peer doesn't support this capability, the speaker MAY >>send a >> NOTIFICATION message to the peer," >> What about the case where the local speaker receives a >>capability it does not understand/support.? >> Should it send a notification - unsupported capability? > >No, it should not. > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Aug 5 01:10:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20286; Tue, 5 Aug 2003 01:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ju5B-0007bW-00; Tue, 05 Aug 2003 01:10:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ju5B-0007bT-00; Tue, 05 Aug 2003 01:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ju5B-0000Rf-Q8; Tue, 05 Aug 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 19ju4O-0000R6-Ob for idr@optimus.ietf.org; Tue, 05 Aug 2003 01:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20270 for ; Tue, 5 Aug 2003 01:09:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ju4L-0007b8-00 for idr@ietf.org; Tue, 05 Aug 2003 01:09:09 -0400 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19ju4J-0007am-00 for idr@ietf.org; Tue, 05 Aug 2003 01:09:09 -0400 Received: (qmail 20156 invoked by uid 510); 5 Aug 2003 05:10:01 -0000 Message-ID: <20030805051001.20153.qmail@webmail31.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 aug 2003 05:10:00 -0000 MIME-Version: 1.0 From: "naresh paliwal" Reply-To: "naresh paliwal" To: "jai hari" Cc: idr@ietf.org Subject: Re: [Idr] Route refresh/ capability Content-type: text/plain; format=flowed Content-Disposition: inline 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: 5 Aug 2003 05:10:01 -0000 >1. Is an implementation allowed to support route refresh >capability without supporting Multiprotocol > capability? RFC 2918 states "If a BGP speaker receives from >its peer a ROUTE-REFRESH message with > the that the speaker didn't advertise to the peer >". What is the peer advertising if > it did not support Multiprotocol capability? Need not, As is supported anyway.. >4. Is restarting hold timer for the session accepted upon >receiving a route refresh request? It make sense to restart Hold timer and keep alive timer. >5. What should be the action ( ignore? ) if route refresh request >is received from a peer that did > not advertise this capability at all? It an error >6. Is Open message optional parameter length really required to >parse the message? ( Is header length > not sufficient? ) But then header length need to be redefined for open message, as message length.. Doesnt make sense to me. -Naresh ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Aug 5 01:10:31 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 SMTP id BAA20311 for ; Tue, 5 Aug 2003 01:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ju5F-0000U2-3U for idr-archive@odin.ietf.org; Tue, 05 Aug 2003 01:10:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h755A5JI001852 for idr-archive@odin.ietf.org; Tue, 5 Aug 2003 01:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ju5E-0000Tn-V7 for idr-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 01:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20286; Tue, 5 Aug 2003 01:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ju5B-0007bW-00; Tue, 05 Aug 2003 01:10:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ju5B-0007bT-00; Tue, 05 Aug 2003 01:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ju5B-0000Rf-Q8; Tue, 05 Aug 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 19ju4O-0000R6-Ob for idr@optimus.ietf.org; Tue, 05 Aug 2003 01:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20270 for ; Tue, 5 Aug 2003 01:09:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ju4L-0007b8-00 for idr@ietf.org; Tue, 05 Aug 2003 01:09:09 -0400 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19ju4J-0007am-00 for idr@ietf.org; Tue, 05 Aug 2003 01:09:09 -0400 Received: (qmail 20156 invoked by uid 510); 5 Aug 2003 05:10:01 -0000 Message-ID: <20030805051001.20153.qmail@webmail31.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 aug 2003 05:10:00 -0000 MIME-Version: 1.0 From: "naresh paliwal" Reply-To: "naresh paliwal" To: "jai hari" Cc: idr@ietf.org Subject: Re: [Idr] Route refresh/ capability Content-type: text/plain; format=flowed Content-Disposition: inline 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: 5 Aug 2003 05:10:01 -0000 >1. Is an implementation allowed to support route refresh >capability without supporting Multiprotocol > capability? RFC 2918 states "If a BGP speaker receives from >its peer a ROUTE-REFRESH message with > the that the speaker didn't advertise to the peer >". What is the peer advertising if > it did not support Multiprotocol capability? Need not, As is supported anyway.. >4. Is restarting hold timer for the session accepted upon >receiving a route refresh request? It make sense to restart Hold timer and keep alive timer. >5. What should be the action ( ignore? ) if route refresh request >is received from a peer that did > not advertise this capability at all? It an error >6. Is Open message optional parameter length really required to >parse the message? ( Is header length > not sufficient? ) But then header length need to be redefined for open message, as message length.. Doesnt make sense to me. -Naresh ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Aug 5 09:12:27 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 JAA09406; Tue, 5 Aug 2003 09:12:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k1c6-0001jy-00; Tue, 05 Aug 2003 09:12:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k1c6-0001jv-00; Tue, 05 Aug 2003 09:12:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k1ag-00062e-DI; Tue, 05 Aug 2003 09:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k1aO-00062E-LF for idr@optimus.ietf.org; Tue, 05 Aug 2003 09:10: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 JAA09361 for ; Tue, 5 Aug 2003 09:10:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k1aN-0001jK-00 for idr@ietf.org; Tue, 05 Aug 2003 09:10:43 -0400 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19k1aL-0001jC-00 for idr@ietf.org; Tue, 05 Aug 2003 09:10:42 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HJ500L01DWN8K@mailout1.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:59 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HJ500M9RDWMRJ@mailout1.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:59 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HJ5009CXDWK0G@mmp2.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:58 +0900 (KST) From: Manav Bhatia Subject: Re: [Idr] Route refresh/ capability To: jai hari Cc: idr@ietf.org Reply-to: Manav Bhatia Message-id: <05b101c35b52$01a96370$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: Tue, 05 Aug 2003 18:33:45 +0530 Content-Transfer-Encoding: 7BIT Jai, > 7. How should errors in capability length field that does not agree with > header length ( or optional parameter length ) be handled? (What is the > notification code? Is it open messag errorcode with subcode unspecified? ) You send a NOTIFICATION message with the Cease (6) Error Code. > > 8. Does the standard care how to handle a route refresh request while one is > already pending? (Can we > just abort and restart the previous adj-rib-out update? ) No. ~Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Aug 5 09:12:59 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 JAA09454 for ; Tue, 5 Aug 2003 09:12:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k1c8-0006B7-U8 for idr-archive@odin.ietf.org; Tue, 05 Aug 2003 09:12:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75DCWaR023743 for idr-archive@odin.ietf.org; Tue, 5 Aug 2003 09:12:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k1c8-0006As-QC for idr-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 09:12: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 JAA09406; Tue, 5 Aug 2003 09:12:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k1c6-0001jy-00; Tue, 05 Aug 2003 09:12:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k1c6-0001jv-00; Tue, 05 Aug 2003 09:12:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k1ag-00062e-DI; Tue, 05 Aug 2003 09:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k1aO-00062E-LF for idr@optimus.ietf.org; Tue, 05 Aug 2003 09:10: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 JAA09361 for ; Tue, 5 Aug 2003 09:10:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k1aN-0001jK-00 for idr@ietf.org; Tue, 05 Aug 2003 09:10:43 -0400 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19k1aL-0001jC-00 for idr@ietf.org; Tue, 05 Aug 2003 09:10:42 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HJ500L01DWN8K@mailout1.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:59 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HJ500M9RDWMRJ@mailout1.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:59 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HJ5009CXDWK0G@mmp2.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:58 +0900 (KST) From: Manav Bhatia Subject: Re: [Idr] Route refresh/ capability To: jai hari Cc: idr@ietf.org Reply-to: Manav Bhatia Message-id: <05b101c35b52$01a96370$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: Tue, 05 Aug 2003 18:33:45 +0530 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Jai, > 7. How should errors in capability length field that does not agree with > header length ( or optional parameter length ) be handled? (What is the > notification code? Is it open messag errorcode with subcode unspecified? ) You send a NOTIFICATION message with the Cease (6) Error Code. > > 8. Does the standard care how to handle a route refresh request while one is > already pending? (Can we > just abort and restart the previous adj-rib-out update? ) No. ~Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From owner-idr@merit.edu Wed Aug 6 07:49: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 HAA12734 for ; Wed, 6 Aug 2003 07:49:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMn1-00024Y-00 for idr-archive@ietf.org; Wed, 06 Aug 2003 07:49:11 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19kMn0-00024G-00 for idr-archive@ietf.org; Wed, 06 Aug 2003 07:49:10 -0400 Received: by trapdoor.merit.edu (Postfix) id D2C5E9127D; Wed, 6 Aug 2003 07:48:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C7B49127F; Wed, 6 Aug 2003 07:48:57 -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 AED8D9127D for ; Wed, 6 Aug 2003 07:47:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BEE55DDCE; Wed, 6 Aug 2003 07:47:51 -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 DDECD5DDAA for ; Wed, 6 Aug 2003 07:47:50 -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 HAA12677; Wed, 6 Aug 2003 07:47:48 -0400 (EDT) Message-Id: <200308061147.HAA12677@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-03.txt Date: Wed, 06 Aug 2003 07:47:47 -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-03.txt Pages : 4 Date : 2003-8-5 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-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-cease-subcode-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-cease-subcode-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-8-5125925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5125925.I-D@ietf.org> --OtherAccess-- --NextPart-- From idr-admin@ietf.org Fri Aug 8 10:01:33 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 KAA11170; Fri, 8 Aug 2003 10:01:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7oH-0000ta-00; Fri, 08 Aug 2003 10:01:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l7oG-0000tQ-00; Fri, 08 Aug 2003 10:01:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7nh-0005W0-BL; Fri, 08 Aug 2003 10: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 19l7mq-0005Se-3N for idr@optimus.ietf.org; Fri, 08 Aug 2003 10:00: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 KAA11057 for ; Fri, 8 Aug 2003 10:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7mo-0000s9-00 for idr@ietf.org; Fri, 08 Aug 2003 10:00:06 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7mn-0000rX-00 for idr@ietf.org; Fri, 08 Aug 2003 10:00:05 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78DxZp5078670 for idr@ietf.org; Fri, 8 Aug 2003 09:59:35 -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 h78DxPLu078645 for ; Fri, 8 Aug 2003 09:59:25 -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 Message-ID: Thread-Topic: idr minutes Thread-Index: AcNQgyv2/pHP9RtzR1+X9u4fP9bqRwNMg16Q From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: quoted-printable Subject: [Idr] FW: idr minutes 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, 8 Aug 2003 09:59:20 -0400 Content-Transfer-Encoding: quoted-printable IETF 57 IDR Minutes Chairs: Yakov Rekhter, Sue Hares ID Document Status (chairs) ------------------ - Base Spec done! Will post -21 after IETF. - See slides Avoid BGP Best Path Transition From one External to Another draft-chen-bgp-avoid-transition-00.txt ----------------------------------------------------------- - BGP identifier used in last phases of BGP routes selection - Appear random - Subject to change - Reduces stability - Proposed solution: Don't eliminate either path due to BGP ID during = path selection - Exception: AS Confederations; parallel sessions - Advantages: stability, reduce iBGP oscillation - Request to adopt as WG draft, but WG is in closed status until base = doc is approved Advertising Equal Cost Multipath Routes in BGP draft-bhatia-ecmp-routes-in-bgp-00 ------------------------------------------------- - Route reflector only advertises route that it installs - May not be optimal for all RR clients or external peers - May lead to route oscillation - Advertise two paths to destination - Proposal: ECMP-NEXT-HOP attribute If specified, second advertisement is not CHEN: I don't think that this is adequate to prevent route oscillation. Bhatia: It will because multiple paths are advertised CHEN: How is this different from last presentation Bhatia: Don't need to change encoding CHEN: Advertising best external route also solves oscillation problem. Without changing spec. Marques: Draft should be named "How to advertise multiple paths in BGP". Look at Alvero's draft. Yakov: Also look at how MP-BGP addresses this BGPv4 SAFI-Specific Attribute draft-kapoor-nalawade-idr-bgp-ssa-00 The Tunnel SAFI draft-nalawade-kapoor-tunnel-safi-00 -------------------------------------- - Exchange tunnel endpoint information - avoid o(n^2) configuration problem - Proposal: Use BGP to advertise tunnel endpoints - SAFI specific Attribute carries tunnel attributes - SAFI specific attribute value contains TLVs - TLV context determined by type field - Negotiated capability Hares: Whats the cookie for kapoor: Its defined in l2tpv3. Yakov: Need discussion on mailing list. Unbundle SAFI discussion from discussion of whether we need a new attribute. Yakov: How do we control type codes? Kapoor: Options - IANA, WG consensus; we can talk about it Yakov: Do you have concept of transitive or non-transitive TLV Kapoor: Attribute is transitive. All TLV inherit. Multiprotocol Next Hop Attribute draft-lefaucheur-mp-nh-00 -------------------------------------------- - need to advertise next hop different from AF of NLRI - may need to advertise multiple next-hops for a prefix - may need to advertise next-hop specific parameters (e.g., label per = nh). Yakov: Motivations; load balancing, v4 over v6. There are existing apps where encoding of NLRI and Next hop are different. Gargi: If we wanted to load balance across two next hops of different type, we could not. iBGP Auto Mesh draft-raszuk-idr-ibgp-auto-mesh-00 ----------------------- - motivation: Autodiscover iBGP peers - flood BGP config via IGP bgp autodiscover TLV flooded in IGP - no change to BGP machinery Dave Ward: What happens during graceful restart? Robert: We don't reflood if configuration is not changing Chen: Does it help much if iBGP congig is not big How will you carry MD5 key. Robert: MD5 keys will be same for all speakers. Chen: How does this work for RR clients Robert: cluster id on client Parantap: We do static config. If you miss one, it really bad. We don't = need this. We don't encourage you to touch ISIS. Signalling tunneling Encaps --------------------------- draft-raggarwa-ppvpn-tunnel-encap-sig-01 - Mechanism for signaling PE tunnel encap capabilities. - Motivations: o Blackhole Avoidance o Co-existing MPLS & IP encap -BGP Tunnel Capability SAFI -LDP Tunnel Encap Capabilities (may not be necessary per BGP)IANA Considerations Alex: The BGP specific part needs to belong in IDR Dave: You will work together with Gargi Rahul: Yes =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "If a man marches out of step with his fellows it may be that he hears the sound of a different drummer or, perhaps that he has a poor sense of rhythm." -- Henry David Thoreau _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Aug 8 10:02:04 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 KAA11228 for ; Fri, 8 Aug 2003 10:02: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 19l7oK-0005om-2z for idr-archive@odin.ietf.org; Fri, 08 Aug 2003 10:01:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78E1eFi022360 for idr-archive@odin.ietf.org; Fri, 8 Aug 2003 10:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7oJ-0005oZ-WA for idr-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 10:01:40 -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 KAA11170; Fri, 8 Aug 2003 10:01:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7oH-0000ta-00; Fri, 08 Aug 2003 10:01:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l7oG-0000tQ-00; Fri, 08 Aug 2003 10:01:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7nh-0005W0-BL; Fri, 08 Aug 2003 10: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 19l7mq-0005Se-3N for idr@optimus.ietf.org; Fri, 08 Aug 2003 10:00: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 KAA11057 for ; Fri, 8 Aug 2003 10:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7mo-0000s9-00 for idr@ietf.org; Fri, 08 Aug 2003 10:00:06 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7mn-0000rX-00 for idr@ietf.org; Fri, 08 Aug 2003 10:00:05 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78DxZp5078670 for idr@ietf.org; Fri, 8 Aug 2003 09:59:35 -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 h78DxPLu078645 for ; Fri, 8 Aug 2003 09:59:25 -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 Message-ID: Thread-Topic: idr minutes Thread-Index: AcNQgyv2/pHP9RtzR1+X9u4fP9bqRwNMg16Q From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: quoted-printable Subject: [Idr] FW: idr minutes 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, 8 Aug 2003 09:59:20 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable IETF 57 IDR Minutes Chairs: Yakov Rekhter, Sue Hares ID Document Status (chairs) ------------------ - Base Spec done! Will post -21 after IETF. - See slides Avoid BGP Best Path Transition From one External to Another draft-chen-bgp-avoid-transition-00.txt ----------------------------------------------------------- - BGP identifier used in last phases of BGP routes selection - Appear random - Subject to change - Reduces stability - Proposed solution: Don't eliminate either path due to BGP ID during = path selection - Exception: AS Confederations; parallel sessions - Advantages: stability, reduce iBGP oscillation - Request to adopt as WG draft, but WG is in closed status until base = doc is approved Advertising Equal Cost Multipath Routes in BGP draft-bhatia-ecmp-routes-in-bgp-00 ------------------------------------------------- - Route reflector only advertises route that it installs - May not be optimal for all RR clients or external peers - May lead to route oscillation - Advertise two paths to destination - Proposal: ECMP-NEXT-HOP attribute If specified, second advertisement is not CHEN: I don't think that this is adequate to prevent route oscillation. Bhatia: It will because multiple paths are advertised CHEN: How is this different from last presentation Bhatia: Don't need to change encoding CHEN: Advertising best external route also solves oscillation problem. Without changing spec. Marques: Draft should be named "How to advertise multiple paths in BGP". Look at Alvero's draft. Yakov: Also look at how MP-BGP addresses this BGPv4 SAFI-Specific Attribute draft-kapoor-nalawade-idr-bgp-ssa-00 The Tunnel SAFI draft-nalawade-kapoor-tunnel-safi-00 -------------------------------------- - Exchange tunnel endpoint information - avoid o(n^2) configuration problem - Proposal: Use BGP to advertise tunnel endpoints - SAFI specific Attribute carries tunnel attributes - SAFI specific attribute value contains TLVs - TLV context determined by type field - Negotiated capability Hares: Whats the cookie for kapoor: Its defined in l2tpv3. Yakov: Need discussion on mailing list. Unbundle SAFI discussion from discussion of whether we need a new attribute. Yakov: How do we control type codes? Kapoor: Options - IANA, WG consensus; we can talk about it Yakov: Do you have concept of transitive or non-transitive TLV Kapoor: Attribute is transitive. All TLV inherit. Multiprotocol Next Hop Attribute draft-lefaucheur-mp-nh-00 -------------------------------------------- - need to advertise next hop different from AF of NLRI - may need to advertise multiple next-hops for a prefix - may need to advertise next-hop specific parameters (e.g., label per = nh). Yakov: Motivations; load balancing, v4 over v6. There are existing apps where encoding of NLRI and Next hop are different. Gargi: If we wanted to load balance across two next hops of different type, we could not. iBGP Auto Mesh draft-raszuk-idr-ibgp-auto-mesh-00 ----------------------- - motivation: Autodiscover iBGP peers - flood BGP config via IGP bgp autodiscover TLV flooded in IGP - no change to BGP machinery Dave Ward: What happens during graceful restart? Robert: We don't reflood if configuration is not changing Chen: Does it help much if iBGP congig is not big How will you carry MD5 key. Robert: MD5 keys will be same for all speakers. Chen: How does this work for RR clients Robert: cluster id on client Parantap: We do static config. If you miss one, it really bad. We don't = need this. We don't encourage you to touch ISIS. Signalling tunneling Encaps --------------------------- draft-raggarwa-ppvpn-tunnel-encap-sig-01 - Mechanism for signaling PE tunnel encap capabilities. - Motivations: o Blackhole Avoidance o Co-existing MPLS & IP encap -BGP Tunnel Capability SAFI -LDP Tunnel Encap Capabilities (may not be necessary per BGP)IANA Considerations Alex: The BGP specific part needs to belong in IDR Dave: You will work together with Gargi Rahul: Yes =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "If a man marches out of step with his fellows it may be that he hears the sound of a different drummer or, perhaps that he has a poor sense of rhythm." -- Henry David Thoreau _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Aug 13 07:59: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 HAA16513; Wed, 13 Aug 2003 07:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19muHg-0000fc-00; Wed, 13 Aug 2003 07:59:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19muHg-0000fX-00; Wed, 13 Aug 2003 07:59:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19muHN-0003q4-ER; Wed, 13 Aug 2003 07: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 19muH8-0003nO-1G for idr@optimus.ietf.org; Wed, 13 Aug 2003 07:58: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 HAA16486 for ; Wed, 13 Aug 2003 07:58:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19muH6-0000ep-00 for idr@ietf.org; Wed, 13 Aug 2003 07:58:44 -0400 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19muH6-0000eZ-00 for idr@ietf.org; Wed, 13 Aug 2003 07:58:44 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HJK004013WVY6@mailout3.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:07 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HJK00K123WUG7@mailout3.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:06 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HJK0012F3WSBB@mmp2.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:06 +0900 (KST) From: Manav Bhatia Subject: Re: [Idr] FW: idr minutes To: Susan Hares Cc: idr@ietf.org Reply-to: Manav Bhatia Message-id: <021d01c36191$4289b8a0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: Wed, 13 Aug 2003 17:21:39 +0530 Content-Transfer-Encoding: 7BIT Checking mails after some gap .. > CHEN: How is this different from last presentation > Bhatia: Don't need to change encoding I thought he was talking of Alvaro's draft and hence i said "No need to change the encoding". This proposal is very different from the previous presentation. In the previous there isnt any way to advertise multiple paths. The central idea being that the tie breaking should never reach the point where the RIDs are compared. > CHEN: Advertising best external route also solves oscillation problem. > Without changing spec. > Marques: Draft should be named "How to advertise multiple paths in BGP". > Look at Alvero's draft. > Yakov: Also look at how MP-BGP addresses this The ECMP_NEXT_HOP attribute already has the AFI field. Just need to add a SAFI field. All subsequent UPDATEs with the ECMP_NEXT_HOP attribute carrying the will not be treated as implicit withdrawals and will instead be appended to the existing RIB. There is thus no special treatment required for MP-BGP. Regards, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Aug 13 07:59: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 HAA16546 for ; Wed, 13 Aug 2003 07:59: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 19muHi-0003vi-4l for idr-archive@odin.ietf.org; Wed, 13 Aug 2003 07:59:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DBxM4l015101 for idr-archive@odin.ietf.org; Wed, 13 Aug 2003 07:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19muHi-0003vU-1V for idr-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 07:59: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 HAA16513; Wed, 13 Aug 2003 07:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19muHg-0000fc-00; Wed, 13 Aug 2003 07:59:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19muHg-0000fX-00; Wed, 13 Aug 2003 07:59:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19muHN-0003q4-ER; Wed, 13 Aug 2003 07: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 19muH8-0003nO-1G for idr@optimus.ietf.org; Wed, 13 Aug 2003 07:58: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 HAA16486 for ; Wed, 13 Aug 2003 07:58:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19muH6-0000ep-00 for idr@ietf.org; Wed, 13 Aug 2003 07:58:44 -0400 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19muH6-0000eZ-00 for idr@ietf.org; Wed, 13 Aug 2003 07:58:44 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HJK004013WVY6@mailout3.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:07 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HJK00K123WUG7@mailout3.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:06 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HJK0012F3WSBB@mmp2.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:06 +0900 (KST) From: Manav Bhatia Subject: Re: [Idr] FW: idr minutes To: Susan Hares Cc: idr@ietf.org Reply-to: Manav Bhatia Message-id: <021d01c36191$4289b8a0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: Wed, 13 Aug 2003 17:21:39 +0530 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Checking mails after some gap .. > CHEN: How is this different from last presentation > Bhatia: Don't need to change encoding I thought he was talking of Alvaro's draft and hence i said "No need to change the encoding". This proposal is very different from the previous presentation. In the previous there isnt any way to advertise multiple paths. The central idea being that the tie breaking should never reach the point where the RIDs are compared. > CHEN: Advertising best external route also solves oscillation problem. > Without changing spec. > Marques: Draft should be named "How to advertise multiple paths in BGP". > Look at Alvero's draft. > Yakov: Also look at how MP-BGP addresses this The ECMP_NEXT_HOP attribute already has the AFI field. Just need to add a SAFI field. All subsequent UPDATEs with the ECMP_NEXT_HOP attribute carrying the will not be treated as implicit withdrawals and will instead be appended to the existing RIB. There is thus no special treatment required for MP-BGP. Regards, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From owner-idr@merit.edu Fri Aug 15 12:56: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 MAA03669 for ; Fri, 15 Aug 2003 12:56:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nhsp-0003uq-00 for idr-archive@ietf.org; Fri, 15 Aug 2003 12:56:59 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19nhso-0003ui-00 for idr-archive@ietf.org; Fri, 15 Aug 2003 12:56:58 -0400 Received: by trapdoor.merit.edu (Postfix) id D076B9123C; Fri, 15 Aug 2003 12:52:10 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E104991233; Fri, 15 Aug 2003 12:51:18 -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 BA1C291228 for ; Fri, 15 Aug 2003 12:50:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D79F5DDAD; Fri, 15 Aug 2003 12:50:55 -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 F29EE5DD9E for ; Fri, 15 Aug 2003 12:50:54 -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 MAA03172; Fri, 15 Aug 2003 12:50:49 -0400 (EDT) Message-Id: <200308151650.MAA03172@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-dynamic-cap-04.txt Date: Fri, 15 Aug 2003 12:50:49 -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 : Dynamic Capability for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-dynamic-cap-04.txt Pages : 6 Date : 2003-8-15 This document defines a new BGP capability termed 'Dynamic Capability', which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-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-dynamic-cap-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-dynamic-cap-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-8-15123949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-dynamic-cap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-dynamic-cap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15123949.I-D@ietf.org> --OtherAccess-- --NextPart-- From idr-admin@ietf.org Fri Aug 15 16:26: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 QAA12292; Fri, 15 Aug 2003 16:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlA3-0005n1-00; Fri, 15 Aug 2003 16:26:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nlA2-0005mx-00; Fri, 15 Aug 2003 16:26:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl96-00014f-FN; Fri, 15 Aug 2003 16:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl8A-00010p-6Z for idr@optimus.ietf.org; Fri, 15 Aug 2003 16:25: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 QAA12203 for ; Fri, 15 Aug 2003 16:24:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl88-0005ll-00 for idr@ietf.org; Fri, 15 Aug 2003 16:25:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19nl87-0005lh-00 for idr@ietf.org; Fri, 15 Aug 2003 16:24:59 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19nl86-0000Kf-H6 for idr@ietf.org; Fri, 15 Aug 2003 20:24:58 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1653510017.20030815132434@psg.com> To: idr@ietf.org In-Reply-To: <96615458792.20030814180213@psg.com> References: <96615458792.20030814180213@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Fwd: Last Call on draft-gill-gtsh-00.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: Fri, 15 Aug 2003 13:24:34 -0700 Content-Transfer-Encoding: 7bit FYI below. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: Date: Thursday, August 14, 2003, 6:02:13 PM Subject: Last Call on draft-gill-gtsh-00.txt ===8<==============Original message text=============== Folks- The IESG received a request to progress draft-gill-gtsh-00.txt as an individual contribution towards the EXPERIMENTAL RFC status. The concept described in the document (as well as the original document known as draft-gill-btsh) has been widely discussed in the community, and I would like to start a 4-week Last Call on the Routing Area mailing list to encourage review and gauge the consensus on the document before taking it to the IESG. Please read the document and indicate if you support it going forward (do send a message if you support). The last call ends on September 12th, 2003. This message will be forwarded as an FYI to certain individual WGs. However, please send your comments to routing-discussion@ietf.org -- Alex Zinin IETF Routing Area Co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Aug 15 16:27: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 QAA12317 for ; Fri, 15 Aug 2003 16:27: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 19nlA5-0001DW-SH for idr-archive@odin.ietf.org; Fri, 15 Aug 2003 16:27:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKR158004676 for idr-archive@odin.ietf.org; Fri, 15 Aug 2003 16: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 19nlA5-0001DJ-PN for idr-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:27: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 QAA12292; Fri, 15 Aug 2003 16:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlA3-0005n1-00; Fri, 15 Aug 2003 16:26:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nlA2-0005mx-00; Fri, 15 Aug 2003 16:26:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl96-00014f-FN; Fri, 15 Aug 2003 16:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl8A-00010p-6Z for idr@optimus.ietf.org; Fri, 15 Aug 2003 16:25: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 QAA12203 for ; Fri, 15 Aug 2003 16:24:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl88-0005ll-00 for idr@ietf.org; Fri, 15 Aug 2003 16:25:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19nl87-0005lh-00 for idr@ietf.org; Fri, 15 Aug 2003 16:24:59 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19nl86-0000Kf-H6 for idr@ietf.org; Fri, 15 Aug 2003 20:24:58 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1653510017.20030815132434@psg.com> To: idr@ietf.org In-Reply-To: <96615458792.20030814180213@psg.com> References: <96615458792.20030814180213@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Fwd: Last Call on draft-gill-gtsh-00.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: Fri, 15 Aug 2003 13:24:34 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit FYI below. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: Date: Thursday, August 14, 2003, 6:02:13 PM Subject: Last Call on draft-gill-gtsh-00.txt ===8<==============Original message text=============== Folks- The IESG received a request to progress draft-gill-gtsh-00.txt as an individual contribution towards the EXPERIMENTAL RFC status. The concept described in the document (as well as the original document known as draft-gill-btsh) has been widely discussed in the community, and I would like to start a 4-week Last Call on the Routing Area mailing list to encourage review and gauge the consensus on the document before taking it to the IESG. Please read the document and indicate if you support it going forward (do send a message if you support). The last call ends on September 12th, 2003. This message will be forwarded as an FYI to certain individual WGs. However, please send your comments to routing-discussion@ietf.org -- Alex Zinin IETF Routing Area Co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Aug 18 21:50:25 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 VAA11828; Mon, 18 Aug 2003 21:50:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovdj-00043d-00; Mon, 18 Aug 2003 21:50:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ovdi-00043Y-00; Mon, 18 Aug 2003 21:50:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovdJ-0006Sr-M1; Mon, 18 Aug 2003 21:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovcg-0006PT-86 for idr@optimus.ietf.org; Mon, 18 Aug 2003 21:49: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 VAA11818 for ; Mon, 18 Aug 2003 21:49:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovcd-00043R-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:19 -0400 Received: from [4.17.150.130] (helo=soln-sro156.solutionip.com) by ietf-mx with esmtp (Exim 4.12) id 19ovcc-00043N-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:18 -0400 Received: from [172.18.240.184] (helo=tcb.net) by soln-sro156.solutionip.com with esmtp (Exim 3.34 #1) id 19ovcd-0007l9-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:19 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Danny McPherson To: idr@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Idr] draft-ietf-idr-bgp4-experience-00.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, 18 Aug 2003 19:49:17 -0600 Content-Transfer-Encoding: 7bit Folks, Inline is an updated version of the BGP "experience" draft. I posted it to internet-drafts@ietf.org a little while ago so it should be showing up on the ftp server sometime this week. We've received comments from several of you and have incorporated most. If you've got additional comments please send them to us ASAP as we'd like to update appropriately and WG LC within a couple of weeks. Note that we do realize a few sections still need some work and will get it in the next revision. Comments, text and corrections are welcome. Thanks! -danny ------------------ INTERNET-DRAFT Danny McPherson draft-ietf-idr-bgp4-experience-00.txt Arbor Networks Keyur Patel Cisco Systems Category Informational Expires: February 2004 August 2003 Experience with the BGP-4 Protocol Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. This document is a product of an individual. Comments are solicited and should be addressed to the author(s). Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. McPherson, Patel [Page 1] INTERNET-DRAFT Expires: February 2004 August 2003 Abstract 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. McPherson, Patel [Page 2] INTERNET-DRAFT Expires: February 2004 August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4 2.2. BGP version 2 . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. BGP version 3 . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. BGP version 4 . . . . . . . . . . . . . . . . . . . . . . . 6 3. Management Information Base (MIB). . . . . . . . . . . . . . . 7 4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 7 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 8 6. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 9 6.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 10 6.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 10 6.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 10 7. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 11 9. Internet Dynamics. . . . . . . . . . . . . . . . . . . . . . . 12 10. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 12 11. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 13 12. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13 13. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14 14. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 14 15. Control over Version Negotiation. . . . . . . . . . . . . . . 14 16. Reciept of Non-Transitive Attributes from eBGP Peer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 15 17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 15 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 16 17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 16 17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17 17.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17 18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18 19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19 20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19 McPherson, Patel [Page 3] INTERNET-DRAFT Expires: February 2004 August 2003 1. Introduction 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. 2. BGP-4 Overview BGP is an inter-autonomous system routing protocol designed for TCP/IP internets. The primary function of BGP is to exchange network reachability information with other BGP systems. This information is sufficient to construct a graph of loop-free AS connectivity and policy decisions at the AS level may be enforced. The initial version of the BGP protocol was published in RFC 1105. Since then BGP Versions 2, 3, and 4 have been developed and are specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively. Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in Appendix N of [BGP4]. 2.1. A Border Gateway Protocol The Initial Version of BGP [RFC 1105] Appendix D of [BGP4]; Comparison with 1105: o Changes to FSM to accommdate BSD 4.3 TCP UI. o Notion of Up/Down/Horizontal relations have been removed. o Message format changes: - Hold Timer removed from BGP Header and added to OPEN Message - Version field removed from BGP Header and added to OPEN Message - Link Type field removed from OPEN Message - OPEN CONFIRM message deprecated and replaced with implicit confirmation provided by KEEPALIVE message. McPherson, Patel Section 2.1. [Page 4] INTERNET-DRAFT Expires: February 2004 August 2003 - UPDATE Message format changed. New fields were added to support multiple path attributes. - The Marker field was expanded and its role broadened to support authentication 2.2. BGP version 2 The Second Version of BGPv2 [RFC 1163] Appendix C of [BGP4] Comparison with RFC 1163 o BGP Identifier introduced to deal with collision detection. o Removed restriction that border router of NEXT_HOP path attribute had to be part of same AS. o Optimized and simplified exchange of information about reachable routes. BGP version 2 removed from the protocol the concept of "up", "down", and "horizontal" relations between autonomous systems that were present in version 1. BGP version 2 introduced the concept of path attributes. In addition, BGP version 2 clarified parts of the protocol that were "under-specified". 2.3. BGP version 3 BGPv3 [RFC 1267] Appendix B of [BGP4] Comparison with RFC 1267: o Set of destination via single IP prefix. Concept of network classes, or subnetting is foreign to BGP-4. To accommodate these capabilities BGP-4 changes the semantics and encoding associated with the AS_PATH attribute. New text has been added to define semantics associated with IP Prefixes. These abilities allow BGP to support the proposed supernetting scheme [RFC 1518] (BGP4 Draft reference to [9] needs to be fixed). o LOCAL_PREF intrduced to facilitate route selection procedures. o INTER_AS_METRIC renamed to MULTI_EXIT_DISC o ATOMIC_AGGREGATE introduced to ensure that certain aggregates are not deaggregated. o Introduced AGGREGATOR. McPherson, Patel Section 2.3. [Page 5] INTERNET-DRAFT Expires: February 2004 August 2003 o Holdtimer neogtiation per-connection for symmetry. Lower value used. Hold Times of zero now supported. BGP version 3 lifted some of the restrictions on the use of the NEXT_HOP path attribute, and added the BGP Identifier field to the BGP OPEN message. It also clarifies the procedure for distributing BGP routes between the BGP speakers within an autonomous system. 2.4. BGP version 4 BGP v4 [RFC 1771] [BGP4] Appendix A of [BGP4] Comparison with RFC 1771: o Changes to reflect use of the TCP MD5 Signature Option, Route Reflectors, AS Confederations for BGP and BGP Route Refresh. o Clarified use of BGP Identifier in AGGREGATOR Attribute o Procedures for imposing upper bound of prefixes a speaker will accept from a peer. o Ability to include more than one instance of it's own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. o Clarified various types of NEXT_HOPS o Claried use of ATOMIC_AGGREGATE attribute o Discussed relationship be BGP NEXT_HOP attribute and immediate next hop. o Clarified tie-breaking procedures o Clarified route advertisement frequency text. o Deprecated Optional Parameter Type 1 (Authentication Information) o UPDATE Message Error subcode 7 (AS Routing Loop) deprecated. o Use of Marker field for authentication has been deprecated. BGP version 4 redefines the (previously defined class-based) network layer reachability portion of the updates to specify prefixes of arbitrary length in order to represent multiple classful networks in a single entry as discussed in [RFC 1519]. BGP version 4 has also modified the AS_PATH attribute so that sets of autonomous systems, as well as individual ASs may be described. BGP version 4 has redescribed the INTER-AS METRIC attribute as the MULTI_EXIT_DISC and added new LOCAL_PREF and AGGREGATOR attributes. BGP version 4 defines procedures for imposing an upper bound on the number of prefixes that a BGP speaker may accept from its peer. BGP version 4 has modifed the AS_PATH attribute to have an ability to McPherson, Patel Section 2.4. [Page 6] INTERNET-DRAFT Expires: February 2004 August 2003 include more than one instance of its own AS for the purpose of inter-AS traffic engineering. BGP version 4 deprecates the use of OPTIONAL PARAMETER Type 1 (Authentication Information). BGP version 4 also deprecates the use of UPDATE MESSAGE Error subcode 7 (AS Routing Loop). BGP version 4 provides clarifications on use of BGP Identifier in the AGGREGATOR attribute and use of the ATOMIC_AGGREGATOR attribute. BGP version 4 also provides clarifications on various types of NEXT_HOPs, BGP tie-breaking procedures and frequency of route announcements in BGP. Possible applications of BGP in the Internet are documented in [RFC 1772]. The BGP protocol was developed by the IDR Working Group of the Internet Engineering Task Force. This Working Group had a mailing list, idr@merit.edu, where discussions of protocol features and operation are held. The IDR Working Group meets regularly during the Internet Engineering Task Force meetings. Reports of these meetings are published in the IETF's Proceedings. 3. Management Information Base (MIB) The BGP-4 Management Information Base (MIB) has been published [BGP- MIB]. The MIB was updated from previous versions documented in [RFC 1657] and [RFC 1269], respectively. Apart from a few system variables, the BGP MIB is broken into two tables: the BGP Peer Table and the BGP Received Path Attribute Table. The Peer Table reflects information about BGP peer connections, such as their state and current activity. The Received Path Attribute Table contains all attributes received from all peers before local routing policy has been applied. The actual attributes used in determining a route are a subset of the received attribute table. 4. Implementations There are numerous independent interoperable implementations of BGP McPherson, Patel Section 4. [Page 7] INTERNET-DRAFT Expires: February 2004 August 2003 currently available. Although the previous version of this report provided an overview of the implementations currently used in the operational Internet, at this time it has been suggested that a separate BGP Implementation Report [BGP-IMPL] be generated. It should be noted that implementation experience with Cisco's BGP-4 implementation was documented as part of [RFC 1656]. For all additional implementation information please reference [BGP- IMPL]. 5. Operational Experience This section discusses operational experience with BGP and BGP-4. BGP has been used in the production environment since 1989, BGP-4 since 1993. Production use of BGP includes utilization of all significant features of the protocol. The present production environment, where BGP is used as the inter-autonomous system routing protocol, is highly heterogeneous. In terms of the link bandwidth it varies from 56 Kbps to 10 Gbps. In terms of the actual routers that run BGP it ranges from a relatively slow performance PC/RT to a very high performance RISC-based CPUs, and includes both the special purpose routers and the general purpose workstations running various UNIX derivatives and other operating systems. In terms of the actual topologies it varies from very sparse to quite dense. The requirement for full-mesh IBGP topologies has been largely remedied by BGP Route Reflection, Autonomous System Confederations for BGP, and perhaps some mix of the two.. BGP Route Reflection was initially defined in [RFC 1966] and subsequently updated in [RFC 2796]. Autonomous System Confederations for BGP were initially defined in [RFC 1965] and subsequently updated in [RFC 3065]. At the time of this writing BGP-4 is used as an inter-autonomous system routing protocol between ALL Internet-attached autonomous systems, with nearly 15k active autonomous systems in the global Internet routing table. BGP is used both for the exchange of routing information between a transit and a stub autonomous system, and for the exchange of routing information between multiple transit autonomous systems. There is no protocol distinction between sites historically considered "backbones" versus "regional" or "edge" networks. McPherson, Patel Section 5. [Page 8] INTERNET-DRAFT Expires: February 2004 August 2003 The full set of exterior routes that is carried by BGP is well over 120,000 aggregate entries, representing several times that number of connected networks. The number of active paths in some service provider core routers exceeds 2.5 million. Native AS_PATH lengths are as long as 10 for some routes, and "padded" path lengths of 25 or more ASs exist. 6. Metrics This section discusses different metrics used within the BGP protocol. BGP has a seperate metric parameter for IBGP and EBGP. This allows policy based metrics to overwrite the distance based metrics; allowing each autonomous systems to define their independent policies in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED) is used as a metric by EBGP peers while BGP Local Preference is used by IBGP peers. 6.1. MULTI_EXIT_DISC (MED) BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_ DISC (MED). This value may be used in the tie-breaking process when selecting a preferred path to a given address space, and provides BGP speakers with the capability to convey to a peer AS the optimal entry point into the local AS. Although the MED was meant to only be used when comparing paths received from different external peers in the same AS, many implementations provide the capability to compare MEDs between different ASs as well. The MED was purposely designed to be a "weak" metric that would only be used late in the best-path decision process. The BGP working group was concerned that any metric specified by a remote operator would only affect routing in a local AS if no other preference was specified. A paramount goal of the design of the MED was ensure that peers could not "shed" or "absorb" traffic for networks that they advertise. McPherson, Patel Section 6.1. [Page 9] INTERNET-DRAFT Expires: February 2004 August 2003 6.1.1. Sending MEDs to BGP Peers [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to be passed to its IBGP peers. Although advertising MEDs to IBGP peers is not a required behavior, it is a common default. MEDs received from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP peers. 6.1.2. MED of Zero Versus No MED An implementation MUST provide a mechanism that allows for MED to be removed. Previously, implementations did not consider a missing MED value to be the same as a MED of zero. No MED value should now be equal to a value of zero. 6.1.3. MEDs and Temporal Route Selection Some implementations have hooks to apply temporal behavior in MED- based best path selection. That is, all other things being equal up to MED consideration, preference would be applied to the "oldest" path, without preferring the lower MED value. The reasoning for this is that "older" paths are presumably more stable, and thus more preferable. However, temporal behavior in route slection results in non-deterministic behavior, and as such, is often undesirable. 7. LOCAL_PREF The LOCAL_PREF attribute was added so a network operator could easily configure a policy that overrode the standard best path determination mechanism without independently configuring local preference policy on each router. One shortcoming in the BGP-4 specification was a suggestion for a default value of LOCAL-PREF to be assumed if none was provided. Defaults of 0 or the maximum value each have range limitations, so a common default would aid in the interoperation of multi-vendor routers in the same AS (since LOCAL_PREF is a local administration knob, there is no interoperability drawback across AS boundaries). McPherson, Patel Section 7. [Page 10] INTERNET-DRAFT Expires: February 2004 August 2003 The LOCAL_PREF MUST be sent to IBGP Peers. The LOCAL_PREF Attribute MUST NOT be sent to EBGP Peers. Although no default value for LOCAL_PREF is defined, the common default value is 100. Another area where more exploration is required is a method whereby an originating AS may influence the best path selection process. For example, a dual-connected site may select one AS as a primary transit service provider and have one as a backup. /---- transit B ----\ end-customer transit A---- /---- transit C ----\ In a topology where the two transit service providers connect to a third provider, the real decision is performed by the third provider and there is no mechanism for indicating a preference should the third provider wish to respect that preference. A general purpose suggestion that has been brought up is the possibility of carrying an optional vector corresponding to the AS- PATH where each transit AS may indicate a preference value for a given route. Cooperating ASs may then chose traffic based upon comparison of "interesting" portions of this vector according to routing policy. While protecting a given ASs routing policy is of paramount concern, avoiding extensive hand configuration of routing policies needs to be examined more carefully in future BGP-like protocols. 8. Internal BGP In Large Autonomous Systems While not strictly a protocol issue, one other concern has been raised by network operators who need to maintain autonomous systems with a large number of peers. Each speaker peering with an external router is responsible for propagating reachability and path information to all other transit and border routers within that AS. This is typically done by establishing internal BGP connections to all transit and border routers in the local AS. In a large AS, this leads to a full mesh of TCP connections (n * (n-1)) and some method of configuring and maintaining those connections. BGP does not specify how this information is to be propagated, so alternatives, such as injecting BGP attribute McPherson, Patel Section 8. [Page 11] INTERNET-DRAFT Expires: February 2004 August 2003 information into the local IGP have been suggested. Also, there is effort underway to develop internal BGP "route reflectors" or a reliable multicast transport of IBGP information which would reduce configuration, memory and CPU requirements of conveying information to all other internal BGP peers. BGP "Route Reflector" extensions has been defined in RFC 1966 to alleviate the the need for "full mesh" IBGP. 9. Internet Dynamics As discussed in [BGP4-ANALYSIS], the driving force in CPU and bandwidth utilization is the dynamic nature of routing in the Internet. As the net has grown, the number of route changes per second has increased. We automatically get some level of damping when more specific NLRI is aggregated into larger blocks, however this isn't sufficient. In Appendix F of [BGP4] are descriptions of damping techniques that should be applied to advertisements. In future specifications of BGP-like protocols, damping methods should be considered for mandatory inclusion in compliant implementations. Route changes are announced using BGP UPDATE messages. The greatest overhead in advertising UPDATE messages happens whenever route changes to be announced are inefficiently packed.Announcing routing changes sharing common attributes in a single BGP UPDATE message [13.1] also helps save considerable bandwidth. Persistent BGP errors may cause BGP peers to flap persistently if peer dampening is not implemented. This would result in significant CPU utilization. Implementors may find it useful to implement peer dampening to avoid such persistent peer flapping [BGP4]. 10. BGP Routing Information Bases (RIBs) [BGP4] states "Any local policy which results in routes being added to an Adj-RIB-Out without also being added to the local BGP speaker's forwarding table, is outside the scope of this document". However, several well-known implementations do not confirm that Loc- RIB entries were used to populate the forwarding table before McPherson, Patel Section 10. [Page 12] INTERNET-DRAFT Expires: February 2004 August 2003 installing them in the Adj-RIB-Out. The most common occurrence of this is when routes for a given prefix are presented by more than one protocol and the preferences for the BGP learned route is lower than that of another protocol. As such, the route learned via the other protocol is used to populate the forwarding table. It may be desirable for an implementation to provide a knob that permits advertisement of "inactive" BGP routes. It may be also desirable for an implementation to provide a knob that allows a BGP speaker to advertise BGP routes that were not selected by descision process. 11. Update Packing The BGP4 protocol permits advertisement of multiple prefixes with a common set of path attributes to be advertised in a single update message, this is commonly referred to as "update packing". When possible, update packing is recommended as it provides a mechanism for more efficient behavior in a number of areas, to include: o Reduction in system overhead due to generation or receipt of fewer Update messages. o Reduction in network overhead as a result of less packets and lower bandwidth consumption. o Allows you to process path attributes and look for matching sets in your AS_PATH database (if you have one) less frequently. Consistent ordering of the path attributes allows for ease of matching in the database as you don't have different representations of the same data. The BGP protocol suggests that withdrawal information should be packed in the begining of Update message along with information about more or less specific reachable routes in a single UPDATE message. This would help alleviate excessive route flapping in BGP. 12. Limit Rate Updates The BGP protocol defines different mechanisms to rate limit the Updates. The BGP protocol defines MinRouteAdvertisementInterval McPherson, Patel Section 12. [Page 13] INTERNET-DRAFT Expires: February 2004 August 2003 parameter that determines the minimum time that must be elsape between the advertisement of routes to a particular destination from a single BGP speaker. This value is set on a per BGP peer basis. 13. Ordering of Path Attributes The BGP protocol suggests that BGP speakers sending multiple prefixes per an UPDATE message should sort and order path attributes according to Type Codes. This would help their peers to quickly identify sets of attributes from different update messages which are semantically different. Implementers may find it useful to order path attributes according to Type Code so that sets of attributes with identical semantics can be more quickly identified. 14. AS_SET Sorting AS_SETs are commonly used in BGP route aggregation. They reduce the size of AS_PATH information by listing AS numbers only once regardless of any number of times it might appear in process of aggregation. AS_SETs are usually sorted in increasing order to facilitate efficient lookups of AS numbers within them. This optimization is entirely optional. 15. Control over Version Negotiation Because pre-BGP-4 route aggregation can't be supported by earlier version of BGP, an implementation that supports versions in addition to BGP-4 should provide the version support on a per-peer basis. 16. Reciept of Non-Transitive Attributes from eBGP Peer E.g., LOCAL_PREF, RR or confed, etc.. McPherson, Patel Section 16. [Page 14] INTERNET-DRAFT Expires: February 2004 August 2003 NEEDS MORE WORK 17. Security Considerations BGP provides flexible and extendable mechanism for authentication and security. The mechanism allows to support schemes with various degree of complexity. BGP sessions are authenticated based on the IP address of a peer. In addition, all BGP sessions are authenticated based on the autonomous system number advertised by a peer. Since BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP. 17.1. TCP MD5 Signature Option RFC 2385 defines a way in which the TCP MD5 signature option can be used to valid information transmitted between two peers. This method prevents any third party from injecting information (e.g., a TCP RST) into the datastream, or modifying the routing information carried between two BGP peers. RFC ???? provides suggestions for choosing passwords to be used with MD5. TCP MD5 is not ubiquitously deployed at the moment, especially in inter- domain scenarios, largely because of key distribution issues. Most key distribution mechanisms are considered to be too "heavy" at this point. 17.2. BGP Over IPSEC BGP can run over IPSEC, either in a tunnel, or in transport mode, where the TCP portion of the IP packet is encrypted. This not only prevents random insertion of information into the data stream between two BGP peers, it also prevents an attacker from learning the data which is being exchanged between the peers. IPSEC does, however, offer several options for exchanging session McPherson, Patel Section 17.2. [Page 15] INTERNET-DRAFT Expires: February 2004 August 2003 keys, which may be useful on inter-domain configurations. These options are being explored in many deployments, although no definitive solution has been reach on the issue of key exchange for BGP in IPSEC. It should be noted that since BGP runs over TCP and IP, BGP is vulnerable to the same denial of service or authentication attacks that are present in any other TCP based protocol. 17.3. Miscellaneous Another issue any routing protocol faces is providing evidence of the validity and authority of the routing information carried within the routing system. This is currently the focus of several efforts at the moment, including efforts to define the threats which can be used against this routing information in BGP [draft-murphy, attack tree], and efforts at developing a means to provide validation and authority for routing information carried within BGP [SBGP] [soBGP]. In addition, the Routing Protocol Security Requirements (RPSEC) working group has been chartered within the Routing Area of the IETF in order to discuss and assist in addressing issues surrounding routing protocol security. It is the intent that this work within RPSEC will result in feedback to BGPv4 and future enhancements to the protocol where appropriate. 17.4. PTOMAINE and GROW The Prefix Taxonomy (PTOMAINE) working group, recently replaced by the Global Routing Operations (GROW) working group, is chartered to consider and measure the problem of routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, GROW will also document the operational aspects of measurement, policy, security and VPN infrastructures. It is the intent that this work within GROW will result in feedback to BGPv4 and future enhancements to the protocol as necessary. One thing that I think you might want to add is something about aggregation and the inability to aggregate over multiple provider McPherson, Patel Section 17.4. [Page 16] INTERNET-DRAFT Expires: February 2004 August 2003 boundaries due to inadequate provider coordination. If you want you can cite the ptomaine work if anything came of it or just mention that the WG was created to address problems in this area. If you want something on the PRD to IRR and RPSL I can put together a few paragraphs. 17.5. Internet Routing Registries (IRRs) Many organizations register their routing policy and prefix origination in the various distributed databases of the Internet Routing Registry. These databases provide access to the information using the RPSL language as defined in [RFC 2622]. While registered information may be maintained and correct for certain providers, the lack of timely or correct data in the various IRR databases has prevented wide-spread use of this resource. 17.6. Acknowledgements We would like to thank Paul Traina and Yakov Rekhter for authoring previous versions of this document. We would also like to acknowledge Russ White, Jeffrey Haas and Curtis Villamizar for valuable feedback on this document. McPherson, Patel Section 17.6. [Page 17] INTERNET-DRAFT Expires: February 2004 August 2003 18. References [RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol BGP", RFC 1105, June 1989. [RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol BGP", RFC 1105, June 1990. [RFC 1264] Hinden, R., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991. [RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3 (BGP-3)", RFC 1105, October 1991. [RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, July 1994. [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995. [RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC 1773, March 1995. [RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification Language", RFC 2622, June 1999. [RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous System Confederations for BGP", RFC 3065, Febuary 2001. [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP Persistent Route Oscillation Condition", RFC 3345, August 2002. [BGP4-ANALYSIS] Work in Progress. [BGP4-IMPL] Work in Progress. McPherson, Patel Section 18. [Page 18] INTERNET-DRAFT Expires: February 2004 August 2003 [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. 19. Authors' Addresses Danny McPherson Arbor Networks Email: danny@arbor.net Keyur Patel Cisco Systems Email: keyupate@cisco.com 20. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McPherson, Patel Section 20. [Page 19] _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Aug 18 21:50:56 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 VAA11846 for ; Mon, 18 Aug 2003 21:50:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovdm-0006VF-To for idr-archive@odin.ietf.org; Mon, 18 Aug 2003 21:50:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J1oUNS024996 for idr-archive@odin.ietf.org; Mon, 18 Aug 2003 21:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovdm-0006V5-Ji for idr-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 21:50: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 VAA11828; Mon, 18 Aug 2003 21:50:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovdj-00043d-00; Mon, 18 Aug 2003 21:50:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ovdi-00043Y-00; Mon, 18 Aug 2003 21:50:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovdJ-0006Sr-M1; Mon, 18 Aug 2003 21:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovcg-0006PT-86 for idr@optimus.ietf.org; Mon, 18 Aug 2003 21:49: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 VAA11818 for ; Mon, 18 Aug 2003 21:49:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovcd-00043R-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:19 -0400 Received: from [4.17.150.130] (helo=soln-sro156.solutionip.com) by ietf-mx with esmtp (Exim 4.12) id 19ovcc-00043N-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:18 -0400 Received: from [172.18.240.184] (helo=tcb.net) by soln-sro156.solutionip.com with esmtp (Exim 3.34 #1) id 19ovcd-0007l9-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:19 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Danny McPherson To: idr@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Idr] draft-ietf-idr-bgp4-experience-00.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, 18 Aug 2003 19:49:17 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Inline is an updated version of the BGP "experience" draft. I posted it to internet-drafts@ietf.org a little while ago so it should be showing up on the ftp server sometime this week. We've received comments from several of you and have incorporated most. If you've got additional comments please send them to us ASAP as we'd like to update appropriately and WG LC within a couple of weeks. Note that we do realize a few sections still need some work and will get it in the next revision. Comments, text and corrections are welcome. Thanks! -danny ------------------ INTERNET-DRAFT Danny McPherson draft-ietf-idr-bgp4-experience-00.txt Arbor Networks Keyur Patel Cisco Systems Category Informational Expires: February 2004 August 2003 Experience with the BGP-4 Protocol Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. This document is a product of an individual. Comments are solicited and should be addressed to the author(s). Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. McPherson, Patel [Page 1] INTERNET-DRAFT Expires: February 2004 August 2003 Abstract 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. McPherson, Patel [Page 2] INTERNET-DRAFT Expires: February 2004 August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4 2.2. BGP version 2 . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. BGP version 3 . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. BGP version 4 . . . . . . . . . . . . . . . . . . . . . . . 6 3. Management Information Base (MIB). . . . . . . . . . . . . . . 7 4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 7 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 8 6. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 9 6.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 10 6.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 10 6.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 10 7. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 11 9. Internet Dynamics. . . . . . . . . . . . . . . . . . . . . . . 12 10. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 12 11. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 13 12. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13 13. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14 14. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 14 15. Control over Version Negotiation. . . . . . . . . . . . . . . 14 16. Reciept of Non-Transitive Attributes from eBGP Peer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 15 17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 15 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 16 17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 16 17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17 17.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17 18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18 19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19 20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19 McPherson, Patel [Page 3] INTERNET-DRAFT Expires: February 2004 August 2003 1. Introduction 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. 2. BGP-4 Overview BGP is an inter-autonomous system routing protocol designed for TCP/IP internets. The primary function of BGP is to exchange network reachability information with other BGP systems. This information is sufficient to construct a graph of loop-free AS connectivity and policy decisions at the AS level may be enforced. The initial version of the BGP protocol was published in RFC 1105. Since then BGP Versions 2, 3, and 4 have been developed and are specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively. Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in Appendix N of [BGP4]. 2.1. A Border Gateway Protocol The Initial Version of BGP [RFC 1105] Appendix D of [BGP4]; Comparison with 1105: o Changes to FSM to accommdate BSD 4.3 TCP UI. o Notion of Up/Down/Horizontal relations have been removed. o Message format changes: - Hold Timer removed from BGP Header and added to OPEN Message - Version field removed from BGP Header and added to OPEN Message - Link Type field removed from OPEN Message - OPEN CONFIRM message deprecated and replaced with implicit confirmation provided by KEEPALIVE message. McPherson, Patel Section 2.1. [Page 4] INTERNET-DRAFT Expires: February 2004 August 2003 - UPDATE Message format changed. New fields were added to support multiple path attributes. - The Marker field was expanded and its role broadened to support authentication 2.2. BGP version 2 The Second Version of BGPv2 [RFC 1163] Appendix C of [BGP4] Comparison with RFC 1163 o BGP Identifier introduced to deal with collision detection. o Removed restriction that border router of NEXT_HOP path attribute had to be part of same AS. o Optimized and simplified exchange of information about reachable routes. BGP version 2 removed from the protocol the concept of "up", "down", and "horizontal" relations between autonomous systems that were present in version 1. BGP version 2 introduced the concept of path attributes. In addition, BGP version 2 clarified parts of the protocol that were "under-specified". 2.3. BGP version 3 BGPv3 [RFC 1267] Appendix B of [BGP4] Comparison with RFC 1267: o Set of destination via single IP prefix. Concept of network classes, or subnetting is foreign to BGP-4. To accommodate these capabilities BGP-4 changes the semantics and encoding associated with the AS_PATH attribute. New text has been added to define semantics associated with IP Prefixes. These abilities allow BGP to support the proposed supernetting scheme [RFC 1518] (BGP4 Draft reference to [9] needs to be fixed). o LOCAL_PREF intrduced to facilitate route selection procedures. o INTER_AS_METRIC renamed to MULTI_EXIT_DISC o ATOMIC_AGGREGATE introduced to ensure that certain aggregates are not deaggregated. o Introduced AGGREGATOR. McPherson, Patel Section 2.3. [Page 5] INTERNET-DRAFT Expires: February 2004 August 2003 o Holdtimer neogtiation per-connection for symmetry. Lower value used. Hold Times of zero now supported. BGP version 3 lifted some of the restrictions on the use of the NEXT_HOP path attribute, and added the BGP Identifier field to the BGP OPEN message. It also clarifies the procedure for distributing BGP routes between the BGP speakers within an autonomous system. 2.4. BGP version 4 BGP v4 [RFC 1771] [BGP4] Appendix A of [BGP4] Comparison with RFC 1771: o Changes to reflect use of the TCP MD5 Signature Option, Route Reflectors, AS Confederations for BGP and BGP Route Refresh. o Clarified use of BGP Identifier in AGGREGATOR Attribute o Procedures for imposing upper bound of prefixes a speaker will accept from a peer. o Ability to include more than one instance of it's own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. o Clarified various types of NEXT_HOPS o Claried use of ATOMIC_AGGREGATE attribute o Discussed relationship be BGP NEXT_HOP attribute and immediate next hop. o Clarified tie-breaking procedures o Clarified route advertisement frequency text. o Deprecated Optional Parameter Type 1 (Authentication Information) o UPDATE Message Error subcode 7 (AS Routing Loop) deprecated. o Use of Marker field for authentication has been deprecated. BGP version 4 redefines the (previously defined class-based) network layer reachability portion of the updates to specify prefixes of arbitrary length in order to represent multiple classful networks in a single entry as discussed in [RFC 1519]. BGP version 4 has also modified the AS_PATH attribute so that sets of autonomous systems, as well as individual ASs may be described. BGP version 4 has redescribed the INTER-AS METRIC attribute as the MULTI_EXIT_DISC and added new LOCAL_PREF and AGGREGATOR attributes. BGP version 4 defines procedures for imposing an upper bound on the number of prefixes that a BGP speaker may accept from its peer. BGP version 4 has modifed the AS_PATH attribute to have an ability to McPherson, Patel Section 2.4. [Page 6] INTERNET-DRAFT Expires: February 2004 August 2003 include more than one instance of its own AS for the purpose of inter-AS traffic engineering. BGP version 4 deprecates the use of OPTIONAL PARAMETER Type 1 (Authentication Information). BGP version 4 also deprecates the use of UPDATE MESSAGE Error subcode 7 (AS Routing Loop). BGP version 4 provides clarifications on use of BGP Identifier in the AGGREGATOR attribute and use of the ATOMIC_AGGREGATOR attribute. BGP version 4 also provides clarifications on various types of NEXT_HOPs, BGP tie-breaking procedures and frequency of route announcements in BGP. Possible applications of BGP in the Internet are documented in [RFC 1772]. The BGP protocol was developed by the IDR Working Group of the Internet Engineering Task Force. This Working Group had a mailing list, idr@merit.edu, where discussions of protocol features and operation are held. The IDR Working Group meets regularly during the Internet Engineering Task Force meetings. Reports of these meetings are published in the IETF's Proceedings. 3. Management Information Base (MIB) The BGP-4 Management Information Base (MIB) has been published [BGP- MIB]. The MIB was updated from previous versions documented in [RFC 1657] and [RFC 1269], respectively. Apart from a few system variables, the BGP MIB is broken into two tables: the BGP Peer Table and the BGP Received Path Attribute Table. The Peer Table reflects information about BGP peer connections, such as their state and current activity. The Received Path Attribute Table contains all attributes received from all peers before local routing policy has been applied. The actual attributes used in determining a route are a subset of the received attribute table. 4. Implementations There are numerous independent interoperable implementations of BGP McPherson, Patel Section 4. [Page 7] INTERNET-DRAFT Expires: February 2004 August 2003 currently available. Although the previous version of this report provided an overview of the implementations currently used in the operational Internet, at this time it has been suggested that a separate BGP Implementation Report [BGP-IMPL] be generated. It should be noted that implementation experience with Cisco's BGP-4 implementation was documented as part of [RFC 1656]. For all additional implementation information please reference [BGP- IMPL]. 5. Operational Experience This section discusses operational experience with BGP and BGP-4. BGP has been used in the production environment since 1989, BGP-4 since 1993. Production use of BGP includes utilization of all significant features of the protocol. The present production environment, where BGP is used as the inter-autonomous system routing protocol, is highly heterogeneous. In terms of the link bandwidth it varies from 56 Kbps to 10 Gbps. In terms of the actual routers that run BGP it ranges from a relatively slow performance PC/RT to a very high performance RISC-based CPUs, and includes both the special purpose routers and the general purpose workstations running various UNIX derivatives and other operating systems. In terms of the actual topologies it varies from very sparse to quite dense. The requirement for full-mesh IBGP topologies has been largely remedied by BGP Route Reflection, Autonomous System Confederations for BGP, and perhaps some mix of the two.. BGP Route Reflection was initially defined in [RFC 1966] and subsequently updated in [RFC 2796]. Autonomous System Confederations for BGP were initially defined in [RFC 1965] and subsequently updated in [RFC 3065]. At the time of this writing BGP-4 is used as an inter-autonomous system routing protocol between ALL Internet-attached autonomous systems, with nearly 15k active autonomous systems in the global Internet routing table. BGP is used both for the exchange of routing information between a transit and a stub autonomous system, and for the exchange of routing information between multiple transit autonomous systems. There is no protocol distinction between sites historically considered "backbones" versus "regional" or "edge" networks. McPherson, Patel Section 5. [Page 8] INTERNET-DRAFT Expires: February 2004 August 2003 The full set of exterior routes that is carried by BGP is well over 120,000 aggregate entries, representing several times that number of connected networks. The number of active paths in some service provider core routers exceeds 2.5 million. Native AS_PATH lengths are as long as 10 for some routes, and "padded" path lengths of 25 or more ASs exist. 6. Metrics This section discusses different metrics used within the BGP protocol. BGP has a seperate metric parameter for IBGP and EBGP. This allows policy based metrics to overwrite the distance based metrics; allowing each autonomous systems to define their independent policies in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED) is used as a metric by EBGP peers while BGP Local Preference is used by IBGP peers. 6.1. MULTI_EXIT_DISC (MED) BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_ DISC (MED). This value may be used in the tie-breaking process when selecting a preferred path to a given address space, and provides BGP speakers with the capability to convey to a peer AS the optimal entry point into the local AS. Although the MED was meant to only be used when comparing paths received from different external peers in the same AS, many implementations provide the capability to compare MEDs between different ASs as well. The MED was purposely designed to be a "weak" metric that would only be used late in the best-path decision process. The BGP working group was concerned that any metric specified by a remote operator would only affect routing in a local AS if no other preference was specified. A paramount goal of the design of the MED was ensure that peers could not "shed" or "absorb" traffic for networks that they advertise. McPherson, Patel Section 6.1. [Page 9] INTERNET-DRAFT Expires: February 2004 August 2003 6.1.1. Sending MEDs to BGP Peers [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to be passed to its IBGP peers. Although advertising MEDs to IBGP peers is not a required behavior, it is a common default. MEDs received from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP peers. 6.1.2. MED of Zero Versus No MED An implementation MUST provide a mechanism that allows for MED to be removed. Previously, implementations did not consider a missing MED value to be the same as a MED of zero. No MED value should now be equal to a value of zero. 6.1.3. MEDs and Temporal Route Selection Some implementations have hooks to apply temporal behavior in MED- based best path selection. That is, all other things being equal up to MED consideration, preference would be applied to the "oldest" path, without preferring the lower MED value. The reasoning for this is that "older" paths are presumably more stable, and thus more preferable. However, temporal behavior in route slection results in non-deterministic behavior, and as such, is often undesirable. 7. LOCAL_PREF The LOCAL_PREF attribute was added so a network operator could easily configure a policy that overrode the standard best path determination mechanism without independently configuring local preference policy on each router. One shortcoming in the BGP-4 specification was a suggestion for a default value of LOCAL-PREF to be assumed if none was provided. Defaults of 0 or the maximum value each have range limitations, so a common default would aid in the interoperation of multi-vendor routers in the same AS (since LOCAL_PREF is a local administration knob, there is no interoperability drawback across AS boundaries). McPherson, Patel Section 7. [Page 10] INTERNET-DRAFT Expires: February 2004 August 2003 The LOCAL_PREF MUST be sent to IBGP Peers. The LOCAL_PREF Attribute MUST NOT be sent to EBGP Peers. Although no default value for LOCAL_PREF is defined, the common default value is 100. Another area where more exploration is required is a method whereby an originating AS may influence the best path selection process. For example, a dual-connected site may select one AS as a primary transit service provider and have one as a backup. /---- transit B ----\ end-customer transit A---- /---- transit C ----\ In a topology where the two transit service providers connect to a third provider, the real decision is performed by the third provider and there is no mechanism for indicating a preference should the third provider wish to respect that preference. A general purpose suggestion that has been brought up is the possibility of carrying an optional vector corresponding to the AS- PATH where each transit AS may indicate a preference value for a given route. Cooperating ASs may then chose traffic based upon comparison of "interesting" portions of this vector according to routing policy. While protecting a given ASs routing policy is of paramount concern, avoiding extensive hand configuration of routing policies needs to be examined more carefully in future BGP-like protocols. 8. Internal BGP In Large Autonomous Systems While not strictly a protocol issue, one other concern has been raised by network operators who need to maintain autonomous systems with a large number of peers. Each speaker peering with an external router is responsible for propagating reachability and path information to all other transit and border routers within that AS. This is typically done by establishing internal BGP connections to all transit and border routers in the local AS. In a large AS, this leads to a full mesh of TCP connections (n * (n-1)) and some method of configuring and maintaining those connections. BGP does not specify how this information is to be propagated, so alternatives, such as injecting BGP attribute McPherson, Patel Section 8. [Page 11] INTERNET-DRAFT Expires: February 2004 August 2003 information into the local IGP have been suggested. Also, there is effort underway to develop internal BGP "route reflectors" or a reliable multicast transport of IBGP information which would reduce configuration, memory and CPU requirements of conveying information to all other internal BGP peers. BGP "Route Reflector" extensions has been defined in RFC 1966 to alleviate the the need for "full mesh" IBGP. 9. Internet Dynamics As discussed in [BGP4-ANALYSIS], the driving force in CPU and bandwidth utilization is the dynamic nature of routing in the Internet. As the net has grown, the number of route changes per second has increased. We automatically get some level of damping when more specific NLRI is aggregated into larger blocks, however this isn't sufficient. In Appendix F of [BGP4] are descriptions of damping techniques that should be applied to advertisements. In future specifications of BGP-like protocols, damping methods should be considered for mandatory inclusion in compliant implementations. Route changes are announced using BGP UPDATE messages. The greatest overhead in advertising UPDATE messages happens whenever route changes to be announced are inefficiently packed.Announcing routing changes sharing common attributes in a single BGP UPDATE message [13.1] also helps save considerable bandwidth. Persistent BGP errors may cause BGP peers to flap persistently if peer dampening is not implemented. This would result in significant CPU utilization. Implementors may find it useful to implement peer dampening to avoid such persistent peer flapping [BGP4]. 10. BGP Routing Information Bases (RIBs) [BGP4] states "Any local policy which results in routes being added to an Adj-RIB-Out without also being added to the local BGP speaker's forwarding table, is outside the scope of this document". However, several well-known implementations do not confirm that Loc- RIB entries were used to populate the forwarding table before McPherson, Patel Section 10. [Page 12] INTERNET-DRAFT Expires: February 2004 August 2003 installing them in the Adj-RIB-Out. The most common occurrence of this is when routes for a given prefix are presented by more than one protocol and the preferences for the BGP learned route is lower than that of another protocol. As such, the route learned via the other protocol is used to populate the forwarding table. It may be desirable for an implementation to provide a knob that permits advertisement of "inactive" BGP routes. It may be also desirable for an implementation to provide a knob that allows a BGP speaker to advertise BGP routes that were not selected by descision process. 11. Update Packing The BGP4 protocol permits advertisement of multiple prefixes with a common set of path attributes to be advertised in a single update message, this is commonly referred to as "update packing". When possible, update packing is recommended as it provides a mechanism for more efficient behavior in a number of areas, to include: o Reduction in system overhead due to generation or receipt of fewer Update messages. o Reduction in network overhead as a result of less packets and lower bandwidth consumption. o Allows you to process path attributes and look for matching sets in your AS_PATH database (if you have one) less frequently. Consistent ordering of the path attributes allows for ease of matching in the database as you don't have different representations of the same data. The BGP protocol suggests that withdrawal information should be packed in the begining of Update message along with information about more or less specific reachable routes in a single UPDATE message. This would help alleviate excessive route flapping in BGP. 12. Limit Rate Updates The BGP protocol defines different mechanisms to rate limit the Updates. The BGP protocol defines MinRouteAdvertisementInterval McPherson, Patel Section 12. [Page 13] INTERNET-DRAFT Expires: February 2004 August 2003 parameter that determines the minimum time that must be elsape between the advertisement of routes to a particular destination from a single BGP speaker. This value is set on a per BGP peer basis. 13. Ordering of Path Attributes The BGP protocol suggests that BGP speakers sending multiple prefixes per an UPDATE message should sort and order path attributes according to Type Codes. This would help their peers to quickly identify sets of attributes from different update messages which are semantically different. Implementers may find it useful to order path attributes according to Type Code so that sets of attributes with identical semantics can be more quickly identified. 14. AS_SET Sorting AS_SETs are commonly used in BGP route aggregation. They reduce the size of AS_PATH information by listing AS numbers only once regardless of any number of times it might appear in process of aggregation. AS_SETs are usually sorted in increasing order to facilitate efficient lookups of AS numbers within them. This optimization is entirely optional. 15. Control over Version Negotiation Because pre-BGP-4 route aggregation can't be supported by earlier version of BGP, an implementation that supports versions in addition to BGP-4 should provide the version support on a per-peer basis. 16. Reciept of Non-Transitive Attributes from eBGP Peer E.g., LOCAL_PREF, RR or confed, etc.. McPherson, Patel Section 16. [Page 14] INTERNET-DRAFT Expires: February 2004 August 2003 NEEDS MORE WORK 17. Security Considerations BGP provides flexible and extendable mechanism for authentication and security. The mechanism allows to support schemes with various degree of complexity. BGP sessions are authenticated based on the IP address of a peer. In addition, all BGP sessions are authenticated based on the autonomous system number advertised by a peer. Since BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP. 17.1. TCP MD5 Signature Option RFC 2385 defines a way in which the TCP MD5 signature option can be used to valid information transmitted between two peers. This method prevents any third party from injecting information (e.g., a TCP RST) into the datastream, or modifying the routing information carried between two BGP peers. RFC ???? provides suggestions for choosing passwords to be used with MD5. TCP MD5 is not ubiquitously deployed at the moment, especially in inter- domain scenarios, largely because of key distribution issues. Most key distribution mechanisms are considered to be too "heavy" at this point. 17.2. BGP Over IPSEC BGP can run over IPSEC, either in a tunnel, or in transport mode, where the TCP portion of the IP packet is encrypted. This not only prevents random insertion of information into the data stream between two BGP peers, it also prevents an attacker from learning the data which is being exchanged between the peers. IPSEC does, however, offer several options for exchanging session McPherson, Patel Section 17.2. [Page 15] INTERNET-DRAFT Expires: February 2004 August 2003 keys, which may be useful on inter-domain configurations. These options are being explored in many deployments, although no definitive solution has been reach on the issue of key exchange for BGP in IPSEC. It should be noted that since BGP runs over TCP and IP, BGP is vulnerable to the same denial of service or authentication attacks that are present in any other TCP based protocol. 17.3. Miscellaneous Another issue any routing protocol faces is providing evidence of the validity and authority of the routing information carried within the routing system. This is currently the focus of several efforts at the moment, including efforts to define the threats which can be used against this routing information in BGP [draft-murphy, attack tree], and efforts at developing a means to provide validation and authority for routing information carried within BGP [SBGP] [soBGP]. In addition, the Routing Protocol Security Requirements (RPSEC) working group has been chartered within the Routing Area of the IETF in order to discuss and assist in addressing issues surrounding routing protocol security. It is the intent that this work within RPSEC will result in feedback to BGPv4 and future enhancements to the protocol where appropriate. 17.4. PTOMAINE and GROW The Prefix Taxonomy (PTOMAINE) working group, recently replaced by the Global Routing Operations (GROW) working group, is chartered to consider and measure the problem of routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, GROW will also document the operational aspects of measurement, policy, security and VPN infrastructures. It is the intent that this work within GROW will result in feedback to BGPv4 and future enhancements to the protocol as necessary. One thing that I think you might want to add is something about aggregation and the inability to aggregate over multiple provider McPherson, Patel Section 17.4. [Page 16] INTERNET-DRAFT Expires: February 2004 August 2003 boundaries due to inadequate provider coordination. If you want you can cite the ptomaine work if anything came of it or just mention that the WG was created to address problems in this area. If you want something on the PRD to IRR and RPSL I can put together a few paragraphs. 17.5. Internet Routing Registries (IRRs) Many organizations register their routing policy and prefix origination in the various distributed databases of the Internet Routing Registry. These databases provide access to the information using the RPSL language as defined in [RFC 2622]. While registered information may be maintained and correct for certain providers, the lack of timely or correct data in the various IRR databases has prevented wide-spread use of this resource. 17.6. Acknowledgements We would like to thank Paul Traina and Yakov Rekhter for authoring previous versions of this document. We would also like to acknowledge Russ White, Jeffrey Haas and Curtis Villamizar for valuable feedback on this document. McPherson, Patel Section 17.6. [Page 17] INTERNET-DRAFT Expires: February 2004 August 2003 18. References [RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol BGP", RFC 1105, June 1989. [RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol BGP", RFC 1105, June 1990. [RFC 1264] Hinden, R., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991. [RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3 (BGP-3)", RFC 1105, October 1991. [RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, July 1994. [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995. [RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC 1773, March 1995. [RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification Language", RFC 2622, June 1999. [RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous System Confederations for BGP", RFC 3065, Febuary 2001. [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP Persistent Route Oscillation Condition", RFC 3345, August 2002. [BGP4-ANALYSIS] Work in Progress. [BGP4-IMPL] Work in Progress. McPherson, Patel Section 18. [Page 18] INTERNET-DRAFT Expires: February 2004 August 2003 [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. 19. Authors' Addresses Danny McPherson Arbor Networks Email: danny@arbor.net Keyur Patel Cisco Systems Email: keyupate@cisco.com 20. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McPherson, Patel Section 20. [Page 19] _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From owner-idr@merit.edu Tue Aug 19 10:08: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 KAA11863 for ; Tue, 19 Aug 2003 10:08:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p79p-0000ZW-00 for idr-archive@ietf.org; Tue, 19 Aug 2003 10:08:21 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19p79o-0000ZL-00 for idr-archive@ietf.org; Tue, 19 Aug 2003 10:08:20 -0400 Received: by trapdoor.merit.edu (Postfix) id D1D409122A; Tue, 19 Aug 2003 10:08:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AEFE9122B; Tue, 19 Aug 2003 10:08:05 -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 620179122A for ; Tue, 19 Aug 2003 10:08:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FAEB5DDA3; Tue, 19 Aug 2003 10:08:04 -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 640E05DDC1 for ; Tue, 19 Aug 2003 10:07:58 -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 KAA11771; Tue, 19 Aug 2003 10:07:50 -0400 (EDT) Message-Id: <200308191407.KAA11771@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-00.txt Date: Tue, 19 Aug 2003 10:07:49 -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-00.txt Pages : 19 Date : 2003-8-19 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19101446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19101446.I-D@ietf.org> --OtherAccess-- --NextPart-- From idr-admin@ietf.org Tue Aug 19 10:17: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 KAA12977; Tue, 19 Aug 2003 10:17:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p7Iq-0000fX-00; Tue, 19 Aug 2003 10:17:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p7Iq-0000fU-00; Tue, 19 Aug 2003 10:17:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p7IC-0006zq-U6; Tue, 19 Aug 2003 10:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p7I2-0006zP-5U for idr@optimus.ietf.org; Tue, 19 Aug 2003 10:16:50 -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 KAA12885 for ; Tue, 19 Aug 2003 10:16:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p7Hx-0000ez-00 for idr@ietf.org; Tue, 19 Aug 2003 10:16:45 -0400 Received: from mailhost.jlc.net ([199.201.159.9] helo=verdi.jlc.net) by ietf-mx with esmtp (Exim 4.12) id 19p7Hw-0000eu-00 for idr@ietf.org; Tue, 19 Aug 2003 10:16:44 -0400 Received: by verdi.jlc.net (Postfix, from userid 104) id 1116E33C7A; Tue, 19 Aug 2003 10:06:27 -0400 (EDT) From: John Leslie To: Danny McPherson Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt Message-ID: <20030819100626.I14782@verdi> References: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net>; from danny@tcb.net on Mon, Aug 18, 2003 at 07:49:17PM -0600 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, 19 Aug 2003 10:06:26 -0400 Danny McPherson wrote: > > Inline is an updated version of the BGP "experience" > draft. I posted it to internet-drafts@ietf.org a little > while ago so it should be showing up on the ftp server > sometime this week. > > We've received comments from several of you and have > incorporated most. If you've got additional comments > please send them to us ASAP as we'd like to update > appropriately and WG LC within a couple of weeks. Well done! Two notes: 1) in section 2.4, I think it would be good to note that the mailing-list was recently changed to . 2) in section 11: > > The BGP protocol suggests that withdrawal information should be > packed in the begining of Update message along with information about > more or less specific reachable routes in a single UPDATE message. > This would help alleviate excessive route flapping in BGP. I believe withdrawn routes MUST be listed first in any individual UPDATE message. This language casts doubt on that. I suspect your intent is to state that the alternate route(s) used MAY be packed into the same UPDATE message (in hopes of minimizing packet loss during the transition). Alas, your intent is not all that clear... -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Aug 19 10:18:09 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 KAA13027 for ; Tue, 19 Aug 2003 10:18: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 19p7It-000733-RY for idr-archive@odin.ietf.org; Tue, 19 Aug 2003 10:17:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JEHhX8027087 for idr-archive@odin.ietf.org; Tue, 19 Aug 2003 10:17:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p7It-00072o-Aj for idr-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 10:17: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 KAA12977; Tue, 19 Aug 2003 10:17:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p7Iq-0000fX-00; Tue, 19 Aug 2003 10:17:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p7Iq-0000fU-00; Tue, 19 Aug 2003 10:17:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p7IC-0006zq-U6; Tue, 19 Aug 2003 10:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p7I2-0006zP-5U for idr@optimus.ietf.org; Tue, 19 Aug 2003 10:16:50 -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 KAA12885 for ; Tue, 19 Aug 2003 10:16:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p7Hx-0000ez-00 for idr@ietf.org; Tue, 19 Aug 2003 10:16:45 -0400 Received: from mailhost.jlc.net ([199.201.159.9] helo=verdi.jlc.net) by ietf-mx with esmtp (Exim 4.12) id 19p7Hw-0000eu-00 for idr@ietf.org; Tue, 19 Aug 2003 10:16:44 -0400 Received: by verdi.jlc.net (Postfix, from userid 104) id 1116E33C7A; Tue, 19 Aug 2003 10:06:27 -0400 (EDT) From: John Leslie To: Danny McPherson Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt Message-ID: <20030819100626.I14782@verdi> References: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net>; from danny@tcb.net on Mon, Aug 18, 2003 at 07:49:17PM -0600 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, 19 Aug 2003 10:06:26 -0400 Danny McPherson wrote: > > Inline is an updated version of the BGP "experience" > draft. I posted it to internet-drafts@ietf.org a little > while ago so it should be showing up on the ftp server > sometime this week. > > We've received comments from several of you and have > incorporated most. If you've got additional comments > please send them to us ASAP as we'd like to update > appropriately and WG LC within a couple of weeks. Well done! Two notes: 1) in section 2.4, I think it would be good to note that the mailing-list was recently changed to . 2) in section 11: > > The BGP protocol suggests that withdrawal information should be > packed in the begining of Update message along with information about > more or less specific reachable routes in a single UPDATE message. > This would help alleviate excessive route flapping in BGP. I believe withdrawn routes MUST be listed first in any individual UPDATE message. This language casts doubt on that. I suspect your intent is to state that the alternate route(s) used MAY be packed into the same UPDATE message (in hopes of minimizing packet loss during the transition). Alas, your intent is not all that clear... -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From owner-idr@merit.edu Tue Aug 19 10:36: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 KAA15124 for ; Tue, 19 Aug 2003 10:36:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p7an-0001Gs-00 for idr-archive@ietf.org; Tue, 19 Aug 2003 10:36:13 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19p7al-0001Gb-00 for idr-archive@ietf.org; Tue, 19 Aug 2003 10:36:12 -0400 Received: by trapdoor.merit.edu (Postfix) id 214B19122B; Tue, 19 Aug 2003 10:34:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6ADFB91235; Tue, 19 Aug 2003 10:34:50 -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 CFAC49122F for ; Tue, 19 Aug 2003 10:33:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B924C5DDB1; Tue, 19 Aug 2003 10:33:10 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by segue.merit.edu (Postfix) with ESMTP id 6A4275DDA3 for ; Tue, 19 Aug 2003 10:33:10 -0400 (EDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 0F86C206607 for ; Tue, 19 Aug 2003 10:31:29 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19p7AX-0008Q8-7W for ietf-announce-list@asgard.ietf.org; Tue, 19 Aug 2003 10:09:05 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19p79Y-00088Z-DS for all-ietf@asgard.ietf.org; Tue, 19 Aug 2003 10:08:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11771; Tue, 19 Aug 2003 10:07:50 -0400 (EDT) Message-Id: <200308191407.KAA11771@ietf.org> 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-00.txt Date: Tue, 19 Aug 2003 10:07:49 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+36067_31070151965611_77445525115" Sender: owner-idr@merit.edu Precedence: bulk --MIMEStream=_0+36067_31070151965611_77445525115 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-00.txt Pages : 19 Date : 2003-8-19 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+36067_31070151965611_77445525115 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+184825_6986936563488_42310645858" --MIMEStream=_1+184825_6986936563488_42310645858 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19101446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-00.txt --MIMEStream=_1+184825_6986936563488_42310645858 Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19101446.I-D@ietf.org> --MIMEStream=_1+184825_6986936563488_42310645858-- --MIMEStream=_0+36067_31070151965611_77445525115-- From idr-admin@ietf.org Tue Aug 19 12:16: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 MAA20899; Tue, 19 Aug 2003 12:16:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p99Y-0002vR-00; Tue, 19 Aug 2003 12:16:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p99Y-0002vO-00; Tue, 19 Aug 2003 12:16:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p99N-0004cF-47; Tue, 19 Aug 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p98h-0004ae-BB for idr@optimus.ietf.org; Tue, 19 Aug 2003 12:15:19 -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 MAA20843 for ; Tue, 19 Aug 2003 12:15:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p98f-0002tt-00 for idr@ietf.org; Tue, 19 Aug 2003 12:15:17 -0400 Received: from cactus.cisco.com ([64.101.140.220]) by ietf-mx with esmtp (Exim 4.12) id 19p98e-0002t9-00 for idr@ietf.org; Tue, 19 Aug 2003 12:15:16 -0400 Received: from ranzhang-w2k01.cisco.com (ranzhang-w2k01.cisco.com [64.101.135.139]) by cactus.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h7JGEi825220; Tue, 19 Aug 2003 11:14:44 -0500 (CDT) Message-Id: <5.0.2.1.2.20030819103943.03f6b1e8@cactus.cisco.com> X-Sender: ranzhang@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 To: Danny McPherson From: Randy Zhang Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt Cc: idr@ietf.org In-Reply-To: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> Mime-Version: 1.0 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, 19 Aug 2003 11:14:59 -0500 Danny, A few comments for your consideration: Section 6.1: >>>A paramount goal of the design of the MED was ensure that peers could not "shed" or "absorb" traffic for networks that they advertise.<<< missing "to" before "ensure" Section 6.1.1: Understand this is not IOS specific but note IOS allows "set metric- internal", perhaps expand the discussion? Section 6.1.2 Understand this is not IOS specific but note IOS allows "missing-as-worst", perhaps expand the discussion? Section 8: >>>Also, there is effort underway to develop internal BGP "route reflectors" <<< RRs are already defined in RFC 1966 and updated in RFC 2796, as you indicated in section 5. So the wording of "underway" is misleading. Additionally the use of quotes for route reflectors implies the term is not popular. Also should it be "an effort" instead of "effort"? :-) >>>BGP "Route Reflector" extensions has been defined in RFC 1966<<<< You use the quotes again here, but you also have RRs with initials capitalized. They should be consistently lower cased. Also the RFC 2796 is not mentioned here. Good work! Regards, Randy At 07:49 PM 8/18/2003 -0600, Danny McPherson wrote: >Folks, >Inline is an updated version of the BGP "experience" >draft. I posted it to internet-drafts@ietf.org a little >while ago so it should be showing up on the ftp server >sometime this week. > >We've received comments from several of you and have >incorporated most. If you've got additional comments >please send them to us ASAP as we'd like to update >appropriately and WG LC within a couple of weeks. > >Note that we do realize a few sections still need >some work and will get it in the next revision. Comments, >text and corrections are welcome. Thanks! > >-danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Aug 19 12:16:40 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 MAA20946 for ; Tue, 19 Aug 2003 12:16:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p99a-0004f3-Ql for idr-archive@odin.ietf.org; Tue, 19 Aug 2003 12:16:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JGGEPw017912 for idr-archive@odin.ietf.org; Tue, 19 Aug 2003 12:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p99a-0004ep-Nl for idr-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 12:16: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 MAA20899; Tue, 19 Aug 2003 12:16:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p99Y-0002vR-00; Tue, 19 Aug 2003 12:16:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p99Y-0002vO-00; Tue, 19 Aug 2003 12:16:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p99N-0004cF-47; Tue, 19 Aug 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p98h-0004ae-BB for idr@optimus.ietf.org; Tue, 19 Aug 2003 12:15:19 -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 MAA20843 for ; Tue, 19 Aug 2003 12:15:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p98f-0002tt-00 for idr@ietf.org; Tue, 19 Aug 2003 12:15:17 -0400 Received: from cactus.cisco.com ([64.101.140.220]) by ietf-mx with esmtp (Exim 4.12) id 19p98e-0002t9-00 for idr@ietf.org; Tue, 19 Aug 2003 12:15:16 -0400 Received: from ranzhang-w2k01.cisco.com (ranzhang-w2k01.cisco.com [64.101.135.139]) by cactus.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h7JGEi825220; Tue, 19 Aug 2003 11:14:44 -0500 (CDT) Message-Id: <5.0.2.1.2.20030819103943.03f6b1e8@cactus.cisco.com> X-Sender: ranzhang@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 To: Danny McPherson From: Randy Zhang Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt Cc: idr@ietf.org In-Reply-To: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> Mime-Version: 1.0 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, 19 Aug 2003 11:14:59 -0500 Danny, A few comments for your consideration: Section 6.1: >>>A paramount goal of the design of the MED was ensure that peers could not "shed" or "absorb" traffic for networks that they advertise.<<< missing "to" before "ensure" Section 6.1.1: Understand this is not IOS specific but note IOS allows "set metric- internal", perhaps expand the discussion? Section 6.1.2 Understand this is not IOS specific but note IOS allows "missing-as-worst", perhaps expand the discussion? Section 8: >>>Also, there is effort underway to develop internal BGP "route reflectors" <<< RRs are already defined in RFC 1966 and updated in RFC 2796, as you indicated in section 5. So the wording of "underway" is misleading. Additionally the use of quotes for route reflectors implies the term is not popular. Also should it be "an effort" instead of "effort"? :-) >>>BGP "Route Reflector" extensions has been defined in RFC 1966<<<< You use the quotes again here, but you also have RRs with initials capitalized. They should be consistently lower cased. Also the RFC 2796 is not mentioned here. Good work! Regards, Randy At 07:49 PM 8/18/2003 -0600, Danny McPherson wrote: >Folks, >Inline is an updated version of the BGP "experience" >draft. I posted it to internet-drafts@ietf.org a little >while ago so it should be showing up on the ftp server >sometime this week. > >We've received comments from several of you and have >incorporated most. If you've got additional comments >please send them to us ASAP as we'd like to update >appropriately and WG LC within a couple of weeks. > >Note that we do realize a few sections still need >some work and will get it in the next revision. Comments, >text and corrections are welcome. Thanks! > >-danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Aug 19 13:28: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 NAA24872; Tue, 19 Aug 2003 13:28:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAHM-00048C-00; Tue, 19 Aug 2003 13:28:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pAHL-000489-00; Tue, 19 Aug 2003 13:28:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pAH3-00089l-Jp; Tue, 19 Aug 2003 13: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 19pAGC-00088z-DP for idr@optimus.ietf.org; Tue, 19 Aug 2003 13:27: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 NAA24826 for ; Tue, 19 Aug 2003 13:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAGA-00046z-00 for idr@ietf.org; Tue, 19 Aug 2003 13:27:06 -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 19pAG9-00046A-00 for idr@ietf.org; Tue, 19 Aug 2003 13:27:05 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2003 10:34:20 -0700 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7JHQXAi012341; Tue, 19 Aug 2003 10:26:33 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-72.cisco.com [128.107.163.72]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJR06776; Tue, 19 Aug 2003 10:32:25 -0700 (PDT) Message-ID: <3F425DC9.4080904@cisco.com> From: Keyur Patel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Zhang CC: Danny McPherson , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt References: <5.0.2.1.2.20030819103943.03f6b1e8@cactus.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 19 Aug 2003 10:26:33 -0700 Content-Transfer-Encoding: 7bit Randy: Thanks for the feedback. We will incorporate them. -Keyur Randy Zhang wrote: > Danny, > > A few comments for your consideration: > > Section 6.1: > >>>A paramount goal of the design of the MED was ensure that > peers could not "shed" or "absorb" traffic for networks that they > advertise.<<< > missing "to" before "ensure" > > Section 6.1.1: > Understand this is not IOS specific but note IOS allows "set metric- > internal", perhaps expand the discussion? > > Section 6.1.2 > Understand this is not IOS specific but note IOS allows > "missing-as-worst", perhaps expand the discussion? > > Section 8: > >>>Also, there is effort underway to develop internal BGP "route > reflectors" <<< > RRs are already defined in RFC 1966 and updated in RFC 2796, as you > indicated in section 5. So the wording of "underway" is misleading. > Additionally the use of quotes for route reflectors implies the term > is not popular. > Also should it be "an effort" instead of "effort"? :-) > > >>>BGP "Route Reflector" extensions has been defined in RFC 1966<<<< > You use the quotes again here, but you also have RRs with initials > capitalized. They should be consistently lower cased. > Also the RFC 2796 is not mentioned here. > > Good work! > > Regards, > Randy > > At 07:49 PM 8/18/2003 -0600, Danny McPherson wrote: > >> Folks, >> Inline is an updated version of the BGP "experience" >> draft. I posted it to internet-drafts@ietf.org a little >> while ago so it should be showing up on the ftp server >> sometime this week. >> >> We've received comments from several of you and have >> incorporated most. If you've got additional comments >> please send them to us ASAP as we'd like to update >> appropriately and WG LC within a couple of weeks. >> >> Note that we do realize a few sections still need >> some work and will get it in the next revision. Comments, >> text and corrections are welcome. Thanks! >> >> -danny > > > > _______________________________________________ > 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 Aug 19 13:28: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 NAA24928 for ; Tue, 19 Aug 2003 13:28: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 19pAHO-0008CY-SY for idr-archive@odin.ietf.org; Tue, 19 Aug 2003 13:28:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JHSMNm031522 for idr-archive@odin.ietf.org; Tue, 19 Aug 2003 13:28:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pAHO-0008CL-Pi for idr-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 13:28: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 NAA24872; Tue, 19 Aug 2003 13:28:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAHM-00048C-00; Tue, 19 Aug 2003 13:28:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pAHL-000489-00; Tue, 19 Aug 2003 13:28:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pAH3-00089l-Jp; Tue, 19 Aug 2003 13: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 19pAGC-00088z-DP for idr@optimus.ietf.org; Tue, 19 Aug 2003 13:27: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 NAA24826 for ; Tue, 19 Aug 2003 13:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAGA-00046z-00 for idr@ietf.org; Tue, 19 Aug 2003 13:27:06 -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 19pAG9-00046A-00 for idr@ietf.org; Tue, 19 Aug 2003 13:27:05 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2003 10:34:20 -0700 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7JHQXAi012341; Tue, 19 Aug 2003 10:26:33 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-72.cisco.com [128.107.163.72]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJR06776; Tue, 19 Aug 2003 10:32:25 -0700 (PDT) Message-ID: <3F425DC9.4080904@cisco.com> From: Keyur Patel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Zhang CC: Danny McPherson , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt References: <5.0.2.1.2.20030819103943.03f6b1e8@cactus.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 19 Aug 2003 10:26:33 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randy: Thanks for the feedback. We will incorporate them. -Keyur Randy Zhang wrote: > Danny, > > A few comments for your consideration: > > Section 6.1: > >>>A paramount goal of the design of the MED was ensure that > peers could not "shed" or "absorb" traffic for networks that they > advertise.<<< > missing "to" before "ensure" > > Section 6.1.1: > Understand this is not IOS specific but note IOS allows "set metric- > internal", perhaps expand the discussion? > > Section 6.1.2 > Understand this is not IOS specific but note IOS allows > "missing-as-worst", perhaps expand the discussion? > > Section 8: > >>>Also, there is effort underway to develop internal BGP "route > reflectors" <<< > RRs are already defined in RFC 1966 and updated in RFC 2796, as you > indicated in section 5. So the wording of "underway" is misleading. > Additionally the use of quotes for route reflectors implies the term > is not popular. > Also should it be "an effort" instead of "effort"? :-) > > >>>BGP "Route Reflector" extensions has been defined in RFC 1966<<<< > You use the quotes again here, but you also have RRs with initials > capitalized. They should be consistently lower cased. > Also the RFC 2796 is not mentioned here. > > Good work! > > Regards, > Randy > > At 07:49 PM 8/18/2003 -0600, Danny McPherson wrote: > >> Folks, >> Inline is an updated version of the BGP "experience" >> draft. I posted it to internet-drafts@ietf.org a little >> while ago so it should be showing up on the ftp server >> sometime this week. >> >> We've received comments from several of you and have >> incorporated most. If you've got additional comments >> please send them to us ASAP as we'd like to update >> appropriately and WG LC within a couple of weeks. >> >> Note that we do realize a few sections still need >> some work and will get it in the next revision. Comments, >> text and corrections are welcome. Thanks! >> >> -danny > > > > _______________________________________________ > 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 owner-idr@merit.edu Tue Aug 19 15:36:24 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 PAA03961 for ; Tue, 19 Aug 2003 15:36:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCHL-0006UC-00 for idr-archive@ietf.org; Tue, 19 Aug 2003 15:36:27 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19pCHK-0006U5-00 for idr-archive@ietf.org; Tue, 19 Aug 2003 15:36:26 -0400 Received: by trapdoor.merit.edu (Postfix) id 978AB9123E; Tue, 19 Aug 2003 15:35:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D76DB9123A; Tue, 19 Aug 2003 15:34:57 -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 1D73C91247 for ; Tue, 19 Aug 2003 15:34:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E90365DDA1; Tue, 19 Aug 2003 15:34:25 -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 3865B5DD99 for ; Tue, 19 Aug 2003 15:34:25 -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 PAA03611; Tue, 19 Aug 2003 15:34:20 -0400 (EDT) Message-Id: <200308191934.PAA03611@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-11.txt Date: Tue, 19 Aug 2003 15:34:20 -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-11.txt Pages : 35 Date : 2003-8-19 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-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19104753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19104753.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Tue Aug 19 16:03: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 QAA06136 for ; Tue, 19 Aug 2003 16:03:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCh7-00079s-00 for idr-archive@ietf.org; Tue, 19 Aug 2003 16:03:05 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19pCh7-000797-00 for idr-archive@ietf.org; Tue, 19 Aug 2003 16:03:05 -0400 Received: by trapdoor.merit.edu (Postfix) id 2BCD691258; Tue, 19 Aug 2003 16:00:55 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBD5E9125A; Tue, 19 Aug 2003 16:00:53 -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 CE43B91252 for ; Tue, 19 Aug 2003 16:00:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B69FA5DD99; Tue, 19 Aug 2003 16:00:47 -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 35DF65DD94 for ; Tue, 19 Aug 2003 16:00:47 -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 h7JK0kZ61522 for ; Tue, 19 Aug 2003 13:00:46 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308192000.h7JK0kZ61522@merlot.juniper.net> To: idr@merit.edu Subject: WG Last Call on BGP MIB MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31568.1061323246.1@juniper.net> Date: Tue, 19 Aug 2003 13:00:46 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start the WG Last Call on advancing draft-ietf-idr-bgp4-mib-11.txt to a Proposed Standard. The Last Call ends Sep 2, 2003. Yakov. From owner-idr@merit.edu Wed Aug 20 11:46:47 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 LAA15914 for ; Wed, 20 Aug 2003 11:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVAi-0002Wh-00 for idr-archive@ietf.org; Wed, 20 Aug 2003 11:46:52 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19pVAh-0002Wc-00 for idr-archive@ietf.org; Wed, 20 Aug 2003 11:46:52 -0400 Received: by trapdoor.merit.edu (Postfix) id DFAA89121D; Wed, 20 Aug 2003 11:44:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A292691218; Wed, 20 Aug 2003 11:44:05 -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 90B5D9121F for ; Wed, 20 Aug 2003 11:43:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7AE4B5DD9F; Wed, 20 Aug 2003 11:43:13 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 403B85DD98 for ; Wed, 20 Aug 2003 11:43:13 -0400 (EDT) Received: from tom3 (1Cust28.tnt30.lnd3.gbr.da.uu.net [62.188.122.28]) by shockwave.systems.pipex.net (Postfix) with SMTP id BDE2D1600035C; Wed, 20 Aug 2003 16:43:11 +0100 (BST) Message-ID: <002401c36731$7ddb7a60$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: , "Yakov Rekhter" Subject: Re: WG Last Call on BGP MIB - normalised names Date: Wed, 20 Aug 2003 16:39:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Normalised names - um. Now we have normalised names in the base bgp spec - good, great, why didn't I think of that? - they are ideal for SNMP ( adding a 'bgp' prefix). Except we already have some names in the MIB and they are different; for me this means we should not be last calling the MIB until we are last calling the base spec. A simple change to the MIB is to specify ManualStart and ManualStop in bgpPeerAdminStatus. A change we should not make is to bring the states in line (eg opensent as opposed to OpenSent). But it is the timers that make me think we must wait. We will need a reference from MIB to optional attribute names as defined in the FSM and I don't think we are yet agreed enough on the latter to make those references. Tom Petch, -----Original Message----- From: Yakov Rekhter To: idr@merit.edu Date: 19 August 2003 21:02 Subject: WG Last Call on BGP MIB >Folks, > >This is to start the WG Last Call on advancing draft-ietf-idr-bgp4-mib-11.txt >to a Proposed Standard. The Last Call ends Sep 2, 2003. > >Yakov. From owner-idr@merit.edu Wed Aug 20 11:47: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 LAA15972 for ; Wed, 20 Aug 2003 11:47:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVBd-0002XI-00 for idr-archive@ietf.org; Wed, 20 Aug 2003 11:47:49 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19pVBY-0002XE-00 for idr-archive@ietf.org; Wed, 20 Aug 2003 11:47:48 -0400 Received: by trapdoor.merit.edu (Postfix) id F22CA9121E; Wed, 20 Aug 2003 11:44:08 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90AA79121F; Wed, 20 Aug 2003 11:44:07 -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 F0A729121E for ; Wed, 20 Aug 2003 11:43:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D5D335DD9F; Wed, 20 Aug 2003 11:43:12 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 513A65DD98 for ; Wed, 20 Aug 2003 11:43:12 -0400 (EDT) Received: from tom3 (1Cust28.tnt30.lnd3.gbr.da.uu.net [62.188.122.28]) by shockwave.systems.pipex.net (Postfix) with SMTP id B3C6716000349; Wed, 20 Aug 2003 16:43:09 +0100 (BST) Message-ID: <002301c36731$7d08e820$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: , "Yakov Rekhter" Subject: Re: WG Last Call on BGP MIB - SMI` Date: Wed, 20 Aug 2003 16:30:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The compliance looks a little odd ie bgp4MIBGroups 6 is defined as bgp4MIBNotificationGroup which obsoletes bgp4MIBNotificationGroup (sic) and this object does not appear in any compliance group. Nor does bgp4MIBNewNotificationGroup which appears in the description of bgp4MIBTrapGroup but is not even defined anywhere. bgpBackwardTransition has a status of current but the description says it is deprecated. Tom Petch -----Original Message----- From: Yakov Rekhter To: idr@merit.edu Date: 19 August 2003 21:02 Subject: WG Last Call on BGP MIB >Folks, > >This is to start the WG Last Call on advancing draft-ietf-idr-bgp4-mib-11.txt >to a Proposed Standard. The Last Call ends Sep 2, 2003. > >Yakov. From idr-admin@ietf.org Wed Aug 20 12:45: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 MAA18837; Wed, 20 Aug 2003 12:45:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pW56-0003Q1-00; Wed, 20 Aug 2003 12:45:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pW56-0003Px-00; Wed, 20 Aug 2003 12:45:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW41-0006PD-UQ; Wed, 20 Aug 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW39-0006N5-MO for idr@optimus.ietf.org; Wed, 20 Aug 2003 12:43: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 MAA18757 for ; Wed, 20 Aug 2003 12:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pW36-0003O2-00 for idr@ietf.org; Wed, 20 Aug 2003 12:43:04 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pW36-0003Nl-00 for idr@ietf.org; Wed, 20 Aug 2003 12:43:04 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KGgTP7080429; Wed, 20 Aug 2003 12:42:29 -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 h7KGgPAg080422; Wed, 20 Aug 2003 12:42:25 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KGgJf04933; Wed, 20 Aug 2003 12:42:19 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Message-ID: <20030820124219.B2996@nexthop.com> References: <002401c36731$7ddb7a60$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002401c36731$7ddb7a60$0301a8c0@tom3>; from nwnetworks@dial.pipex.com on Wed, Aug 20, 2003 at 04:39:34PM +0100 X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] Re: WG Last Call on BGP MIB - normalised names 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, 20 Aug 2003 12:42:19 -0400 On Wed, Aug 20, 2003 at 04:39:34PM +0100, Tom Petch wrote: > Normalised names - um. Now we have normalised names in the base bgp > spec - good, great, why didn't I think of that? - they are ideal for > SNMP ( adding a 'bgp' prefix). > > Except we already have some names in the MIB and they are different; > for me this means we should not be last calling the MIB until we are > last calling the base spec. > > A simple change to the MIB is to specify ManualStart and ManualStop in > bgpPeerAdminStatus. I don't believe we're allowed to change the names of enumerated values. I will check on this. > A change we should not make is to bring the states in line (eg > opensent as opposed to OpenSent). Ditto. > But it is the timers that make me think we must wait. We will need a > reference from MIB to optional attribute names as defined in the FSM > and I don't think we are yet agreed enough on the latter to make those > references. The v2MIB is intended to reflect all of the details of the updated BGP specification. This draft is largely intended to fix up the previously published MIB, note some obvious changes and to fix a problem with the traps. So, don't expect to see any sweeping changes reflected here. Generally, the idea is to not disrupt operator's lives any more than is necessary. Unfortunately, the "fix" to the traps/notifications will do that. (More on that in a later email.) > Tom Petch, -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Aug 20 12:45: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 MAA18891 for ; Wed, 20 Aug 2003 12:45: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 19pW59-0006XS-5Z for idr-archive@odin.ietf.org; Wed, 20 Aug 2003 12:45:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KGjBAA025130 for idr-archive@odin.ietf.org; Wed, 20 Aug 2003 12:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW59-0006XE-28 for idr-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 12:45:11 -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 MAA18837; Wed, 20 Aug 2003 12:45:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pW56-0003Q1-00; Wed, 20 Aug 2003 12:45:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pW56-0003Px-00; Wed, 20 Aug 2003 12:45:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW41-0006PD-UQ; Wed, 20 Aug 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW39-0006N5-MO for idr@optimus.ietf.org; Wed, 20 Aug 2003 12:43: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 MAA18757 for ; Wed, 20 Aug 2003 12:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pW36-0003O2-00 for idr@ietf.org; Wed, 20 Aug 2003 12:43:04 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pW36-0003Nl-00 for idr@ietf.org; Wed, 20 Aug 2003 12:43:04 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KGgTP7080429; Wed, 20 Aug 2003 12:42:29 -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 h7KGgPAg080422; Wed, 20 Aug 2003 12:42:25 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KGgJf04933; Wed, 20 Aug 2003 12:42:19 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Message-ID: <20030820124219.B2996@nexthop.com> References: <002401c36731$7ddb7a60$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002401c36731$7ddb7a60$0301a8c0@tom3>; from nwnetworks@dial.pipex.com on Wed, Aug 20, 2003 at 04:39:34PM +0100 X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] Re: WG Last Call on BGP MIB - normalised names 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, 20 Aug 2003 12:42:19 -0400 On Wed, Aug 20, 2003 at 04:39:34PM +0100, Tom Petch wrote: > Normalised names - um. Now we have normalised names in the base bgp > spec - good, great, why didn't I think of that? - they are ideal for > SNMP ( adding a 'bgp' prefix). > > Except we already have some names in the MIB and they are different; > for me this means we should not be last calling the MIB until we are > last calling the base spec. > > A simple change to the MIB is to specify ManualStart and ManualStop in > bgpPeerAdminStatus. I don't believe we're allowed to change the names of enumerated values. I will check on this. > A change we should not make is to bring the states in line (eg > opensent as opposed to OpenSent). Ditto. > But it is the timers that make me think we must wait. We will need a > reference from MIB to optional attribute names as defined in the FSM > and I don't think we are yet agreed enough on the latter to make those > references. The v2MIB is intended to reflect all of the details of the updated BGP specification. This draft is largely intended to fix up the previously published MIB, note some obvious changes and to fix a problem with the traps. So, don't expect to see any sweeping changes reflected here. Generally, the idea is to not disrupt operator's lives any more than is necessary. Unfortunately, the "fix" to the traps/notifications will do that. (More on that in a later email.) > Tom Petch, -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Aug 20 13:04:01 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 NAA19971; Wed, 20 Aug 2003 13:04:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWNT-0003hK-00; Wed, 20 Aug 2003 13:04:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pWNS-0003hH-00; Wed, 20 Aug 2003 13:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWNM-0007BU-Oc; Wed, 20 Aug 2003 13:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWNH-0007B1-1p for idr@optimus.ietf.org; Wed, 20 Aug 2003 13:03:55 -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 NAA19950 for ; Wed, 20 Aug 2003 13:03:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWNF-0003gr-00 for idr@ietf.org; Wed, 20 Aug 2003 13:03:53 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pWNE-0003gO-00 for idr@ietf.org; Wed, 20 Aug 2003 13:03:52 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KH3Lim081100; Wed, 20 Aug 2003 13:03:21 -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 h7KH3GAg081093; Wed, 20 Aug 2003 13:03:16 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KH3BX05323; Wed, 20 Aug 2003 13:03:11 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Message-ID: <20030820130311.C2996@nexthop.com> References: <002301c36731$7d08e820$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002301c36731$7d08e820$0301a8c0@tom3>; from nwnetworks@dial.pipex.com on Wed, Aug 20, 2003 at 04:30:51PM +0100 X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] Re: WG Last Call on BGP MIB - SMI` 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, 20 Aug 2003 13:03:11 -0400 On Wed, Aug 20, 2003 at 04:30:51PM +0100, Tom Petch wrote: > The compliance looks a little odd ie > > bgp4MIBGroups 6 is defined as bgp4MIBNotificationGroup which obsoletes > bgp4MIBNotificationGroup (sic) and this object does not appear in any > compliance group. As I've been given to understand it, not listing it in a compliance makes it completely optional to implement. I'll verify that. It may be proper to not list it in a group if that is the case. > Nor does bgp4MIBNewNotificationGroup which appears > in the description of bgp4MIBTrapGroup but is not even defined > anywhere. Typo from a previous rev, fixed. > bgpBackwardTransition has a status of current but the description says > it is deprecated. Fixed. Thanks! -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Aug 20 13:04: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 NAA20004 for ; Wed, 20 Aug 2003 13:04: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 19pWNV-0007E7-L9 for idr-archive@odin.ietf.org; Wed, 20 Aug 2003 13:04:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KH49Uw027773 for idr-archive@odin.ietf.org; Wed, 20 Aug 2003 13:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWNV-0007Ds-Hu for idr-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 13:04:09 -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 NAA19971; Wed, 20 Aug 2003 13:04:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWNT-0003hK-00; Wed, 20 Aug 2003 13:04:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pWNS-0003hH-00; Wed, 20 Aug 2003 13:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWNM-0007BU-Oc; Wed, 20 Aug 2003 13:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWNH-0007B1-1p for idr@optimus.ietf.org; Wed, 20 Aug 2003 13:03:55 -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 NAA19950 for ; Wed, 20 Aug 2003 13:03:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWNF-0003gr-00 for idr@ietf.org; Wed, 20 Aug 2003 13:03:53 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pWNE-0003gO-00 for idr@ietf.org; Wed, 20 Aug 2003 13:03:52 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KH3Lim081100; Wed, 20 Aug 2003 13:03:21 -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 h7KH3GAg081093; Wed, 20 Aug 2003 13:03:16 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KH3BX05323; Wed, 20 Aug 2003 13:03:11 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Message-ID: <20030820130311.C2996@nexthop.com> References: <002301c36731$7d08e820$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002301c36731$7d08e820$0301a8c0@tom3>; from nwnetworks@dial.pipex.com on Wed, Aug 20, 2003 at 04:30:51PM +0100 X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] Re: WG Last Call on BGP MIB - SMI` 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, 20 Aug 2003 13:03:11 -0400 On Wed, Aug 20, 2003 at 04:30:51PM +0100, Tom Petch wrote: > The compliance looks a little odd ie > > bgp4MIBGroups 6 is defined as bgp4MIBNotificationGroup which obsoletes > bgp4MIBNotificationGroup (sic) and this object does not appear in any > compliance group. As I've been given to understand it, not listing it in a compliance makes it completely optional to implement. I'll verify that. It may be proper to not list it in a group if that is the case. > Nor does bgp4MIBNewNotificationGroup which appears > in the description of bgp4MIBTrapGroup but is not even defined > anywhere. Typo from a previous rev, fixed. > bgpBackwardTransition has a status of current but the description says > it is deprecated. Fixed. Thanks! -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Aug 20 13:32:05 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 NAA21331; Wed, 20 Aug 2003 13:32:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWob-000459-00; Wed, 20 Aug 2003 13:32:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pWoa-000456-00; Wed, 20 Aug 2003 13:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWoT-0008Iz-6f; Wed, 20 Aug 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWo1-0008IY-3V for idr@optimus.ietf.org; Wed, 20 Aug 2003 13:31: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 NAA21302 for ; Wed, 20 Aug 2003 13:31:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWnz-00044j-00 for idr@ietf.org; Wed, 20 Aug 2003 13:31:31 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pWnx-000447-00 for idr@ietf.org; Wed, 20 Aug 2003 13:31:30 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KHUvsH081984; Wed, 20 Aug 2003 13:30:57 -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 h7KHUrAg081977; Wed, 20 Aug 2003 13:30:53 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KHUmu05627; Wed, 20 Aug 2003 13:30:48 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Subject: Re: [Idr] Re: WG Last Call on BGP MIB - normalised names Message-ID: <20030820133048.G2996@nexthop.com> References: <002401c36731$7ddb7a60$0301a8c0@tom3> <20030820124219.B2996@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030820124219.B2996@nexthop.com>; from jhaas@nexthop.com on Wed, Aug 20, 2003 at 12:42:19PM -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: Wed, 20 Aug 2003 13:30:48 -0400 On Wed, Aug 20, 2003 at 12:42:19PM -0400, Jeffrey Haas wrote: > I don't believe we're allowed to change the names of enumerated values. > I will check on this. Survey says: bzzt! We can't do this. We can do what we like in the v2 MIB for names, but they must be lowercase as the first letter. This means the mapping can't be 1:1 exactly for the FSM states as currently documented. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Aug 20 13:32:37 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 NAA21360 for ; Wed, 20 Aug 2003 13:32:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWod-0008Lq-S2 for idr-archive@odin.ietf.org; Wed, 20 Aug 2003 13:32:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KHWBvT032096 for idr-archive@odin.ietf.org; Wed, 20 Aug 2003 13:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWod-0008Lb-OG for idr-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 13:32:11 -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 NAA21331; Wed, 20 Aug 2003 13:32:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWob-000459-00; Wed, 20 Aug 2003 13:32:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pWoa-000456-00; Wed, 20 Aug 2003 13:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWoT-0008Iz-6f; Wed, 20 Aug 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWo1-0008IY-3V for idr@optimus.ietf.org; Wed, 20 Aug 2003 13:31: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 NAA21302 for ; Wed, 20 Aug 2003 13:31:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWnz-00044j-00 for idr@ietf.org; Wed, 20 Aug 2003 13:31:31 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pWnx-000447-00 for idr@ietf.org; Wed, 20 Aug 2003 13:31:30 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KHUvsH081984; Wed, 20 Aug 2003 13:30:57 -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 h7KHUrAg081977; Wed, 20 Aug 2003 13:30:53 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KHUmu05627; Wed, 20 Aug 2003 13:30:48 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Subject: Re: [Idr] Re: WG Last Call on BGP MIB - normalised names Message-ID: <20030820133048.G2996@nexthop.com> References: <002401c36731$7ddb7a60$0301a8c0@tom3> <20030820124219.B2996@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030820124219.B2996@nexthop.com>; from jhaas@nexthop.com on Wed, Aug 20, 2003 at 12:42:19PM -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: Wed, 20 Aug 2003 13:30:48 -0400 On Wed, Aug 20, 2003 at 12:42:19PM -0400, Jeffrey Haas wrote: > I don't believe we're allowed to change the names of enumerated values. > I will check on this. Survey says: bzzt! We can't do this. We can do what we like in the v2 MIB for names, but they must be lowercase as the first letter. This means the mapping can't be 1:1 exactly for the FSM states as currently documented. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Aug 20 14:54: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 OAA29582; Wed, 20 Aug 2003 14:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pY5u-0005SB-00; Wed, 20 Aug 2003 14:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pY5t-0005S8-00; Wed, 20 Aug 2003 14:54:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pY5o-0005ro-Jn; Wed, 20 Aug 2003 14:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pY56-0005qt-1q for idr@optimus.ietf.org; Wed, 20 Aug 2003 14:53: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 OAA29572 for ; Wed, 20 Aug 2003 14:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pY53-0005Rp-00 for idr@ietf.org; Wed, 20 Aug 2003 14:53:13 -0400 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 19pY52-0005RC-00 for idr@ietf.org; Wed, 20 Aug 2003 14:53:12 -0400 Received: from tom3 (1Cust218.tnt13.lnd4.gbr.da.uu.net [62.188.142.218]) by shockwave.systems.pipex.net (Postfix) with SMTP id 909E516000093; Wed, 20 Aug 2003 19:52:39 +0100 (BST) Message-ID: <009c01c3674b$f6077d80$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Jeffrey Haas" Cc: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Subject: [Idr] Re: WG Last Call on BGP MIB - normalised names 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, 20 Aug 2003 19:48:52 +0100 Content-Transfer-Encoding: 7bit Agreed, we must not change the names of the enumerations or objects; what I was suggesting was that in the description, where it refers to stop and start, that is now ambiguous as we have multiple stops and starts and so the description should include Manual.... as per the normalised event names in the base spec for events 1 and 2. The base has normalised names for the timers and here is where there might be confusion since the names are or may be different and so I think the MIB needs a cross reference. I have pushed for the terms KeepaliveTime, HoldTime, IdleHoldTime, DelayOpenTime ;-) etc to be explicitly the initial value to which the corresponding Timer is set. The MIB refers to some of these but uses a different name - hence the need for a mapping for those present in the current MIB. eg 'bgpPeerKeepAlive corresponds to the KeepaliveTime session attribute as defined in [BGP4]' The mapping of OpenSent to opensent I think obvious enough not to need explanation. Tom Petch ----Original Message----- From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Date: 20 August 2003 17:42 Subject: Re: WG Last Call on BGP MIB - normalised names >On Wed, Aug 20, 2003 at 04:39:34PM +0100, Tom Petch wrote: >> Normalised names - um. Now we have normalised names in the base bgp >> spec - good, great, why didn't I think of that? - they are ideal for >> SNMP ( adding a 'bgp' prefix). >> >> Except we already have some names in the MIB and they are different; >> for me this means we should not be last calling the MIB until we are >> last calling the base spec. >> >> A simple change to the MIB is to specify ManualStart and ManualStop in >> bgpPeerAdminStatus. > >I don't believe we're allowed to change the names of enumerated values. >I will check on this. > >> A change we should not make is to bring the states in line (eg >> opensent as opposed to OpenSent). > >Ditto. > >> But it is the timers that make me think we must wait. We will need a >> reference from MIB to optional attribute names as defined in the FSM >> and I don't think we are yet agreed enough on the latter to make those >> references. > >The v2MIB is intended to reflect all of the details of the updated >BGP specification. This draft is largely intended to fix up the >previously published MIB, note some obvious changes and to fix >a problem with the traps. So, don't expect to see any sweeping changes >reflected here. > >Generally, the idea is to not disrupt operator's lives any more than >is necessary. Unfortunately, the "fix" to the traps/notifications >will do that. > >(More on that in a later email.) > >> Tom Petch, > >-- >Jeff Haas >NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Aug 20 14:54: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 OAA29607 for ; Wed, 20 Aug 2003 14:54: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 19pY5x-0005vn-SK for idr-archive@odin.ietf.org; Wed, 20 Aug 2003 14:54:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KIs9XG022793 for idr-archive@odin.ietf.org; Wed, 20 Aug 2003 14:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pY5x-0005vY-Nv for idr-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 14:54:09 -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 OAA29582; Wed, 20 Aug 2003 14:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pY5u-0005SB-00; Wed, 20 Aug 2003 14:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pY5t-0005S8-00; Wed, 20 Aug 2003 14:54:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pY5o-0005ro-Jn; Wed, 20 Aug 2003 14:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pY56-0005qt-1q for idr@optimus.ietf.org; Wed, 20 Aug 2003 14:53: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 OAA29572 for ; Wed, 20 Aug 2003 14:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pY53-0005Rp-00 for idr@ietf.org; Wed, 20 Aug 2003 14:53:13 -0400 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 19pY52-0005RC-00 for idr@ietf.org; Wed, 20 Aug 2003 14:53:12 -0400 Received: from tom3 (1Cust218.tnt13.lnd4.gbr.da.uu.net [62.188.142.218]) by shockwave.systems.pipex.net (Postfix) with SMTP id 909E516000093; Wed, 20 Aug 2003 19:52:39 +0100 (BST) Message-ID: <009c01c3674b$f6077d80$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Jeffrey Haas" Cc: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Subject: [Idr] Re: WG Last Call on BGP MIB - normalised names 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, 20 Aug 2003 19:48:52 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Agreed, we must not change the names of the enumerations or objects; what I was suggesting was that in the description, where it refers to stop and start, that is now ambiguous as we have multiple stops and starts and so the description should include Manual.... as per the normalised event names in the base spec for events 1 and 2. The base has normalised names for the timers and here is where there might be confusion since the names are or may be different and so I think the MIB needs a cross reference. I have pushed for the terms KeepaliveTime, HoldTime, IdleHoldTime, DelayOpenTime ;-) etc to be explicitly the initial value to which the corresponding Timer is set. The MIB refers to some of these but uses a different name - hence the need for a mapping for those present in the current MIB. eg 'bgpPeerKeepAlive corresponds to the KeepaliveTime session attribute as defined in [BGP4]' The mapping of OpenSent to opensent I think obvious enough not to need explanation. Tom Petch ----Original Message----- From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Date: 20 August 2003 17:42 Subject: Re: WG Last Call on BGP MIB - normalised names >On Wed, Aug 20, 2003 at 04:39:34PM +0100, Tom Petch wrote: >> Normalised names - um. Now we have normalised names in the base bgp >> spec - good, great, why didn't I think of that? - they are ideal for >> SNMP ( adding a 'bgp' prefix). >> >> Except we already have some names in the MIB and they are different; >> for me this means we should not be last calling the MIB until we are >> last calling the base spec. >> >> A simple change to the MIB is to specify ManualStart and ManualStop in >> bgpPeerAdminStatus. > >I don't believe we're allowed to change the names of enumerated values. >I will check on this. > >> A change we should not make is to bring the states in line (eg >> opensent as opposed to OpenSent). > >Ditto. > >> But it is the timers that make me think we must wait. We will need a >> reference from MIB to optional attribute names as defined in the FSM >> and I don't think we are yet agreed enough on the latter to make those >> references. > >The v2MIB is intended to reflect all of the details of the updated >BGP specification. This draft is largely intended to fix up the >previously published MIB, note some obvious changes and to fix >a problem with the traps. So, don't expect to see any sweeping changes >reflected here. > >Generally, the idea is to not disrupt operator's lives any more than >is necessary. Unfortunately, the "fix" to the traps/notifications >will do that. > >(More on that in a later email.) > >> Tom Petch, > >-- >Jeff Haas >NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Sun Aug 24 17:20:24 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 RAA25246; Sun, 24 Aug 2003 17:20:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r2Hl-0003vn-00; Sun, 24 Aug 2003 17:20:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19r2Hk-0003vi-00; Sun, 24 Aug 2003 17:20:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r2HL-0007dk-Rc; Sun, 24 Aug 2003 17:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r2Gq-0007cr-GO for idr@optimus.ietf.org; Sun, 24 Aug 2003 17:19: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 RAA25189 for ; Sun, 24 Aug 2003 17:19:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r2Go-0003uM-00 for idr@ietf.org; Sun, 24 Aug 2003 17:19:30 -0400 Received: from sj-inbound-3.cisco.com ([128.107.250.144]) by ietf-mx with esmtp (Exim 4.12) id 19r2Gm-0003tb-00 for idr@ietf.org; Sun, 24 Aug 2003 17:19:28 -0400 Received: from localhost (localhost) by sj-inbound-3.cisco.com (8.12.8p1/8.11.2) id h7OLJ6xN019052; Sun, 24 Aug 2003 14:19:06 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <200308242119.h7OLJ6xN019052@sj-inbound-3.cisco.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com" Auto-Submitted: auto-generated (failure) Subject: [Idr] Returned mail: see transcript for details 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: Sun, 24 Aug 2003 14:19:06 -0700 (PDT) This is a MIME-encapsulated message --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_SOBIG.F in file details.pif The uncleanable file details.pif is moved to /etc/iscan/virus/virPNA96aGKC. --------------------------------------------------------- --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com The original message was received at Sun, 24 Aug 2003 14:17:38 -0700 (PDT) from 226.Red-80-33-226.pooles.rima-tde.net [80.33.226.226] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 ... User unknown) (expanded from: ) ----- Transcript of session follows ----- ... while talking to sj-core-2.cisco.com.: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: message/delivery-status Reporting-MTA: dns; sj-inbound-3.cisco.com Received-From-MTA: DNS; 226.Red-80-33-226.pooles.rima-tde.net Arrival-Date: Sun, 24 Aug 2003 14:17:38 -0700 (PDT) Final-Recipient: RFC822; nmenta@cisco.com X-Actual-Recipient: RFC822; nmenta@sj-core.cisco.com Action: failed Status: 5.1.1 Remote-MTA: DNS; sj-core-2.cisco.com Diagnostic-Code: SMTP; 550 5.1.1 ... User unknown Last-Attempt-Date: Sun, 24 Aug 2003 14:19:06 -0700 (PDT) --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: message/rfc822 Return-Path: Received: from PC1 (226.Red-80-33-226.pooles.rima-tde.net [80.33.226.226]) by sj-inbound-3.cisco.com (8.12.8p1/8.11.2) with ESMTP id h7OLHQxN017984 for ; Sun, 24 Aug 2003 14:17:38 -0700 (PDT) Message-Id: <200308242117.h7OLHQxN017984@sj-inbound-3.cisco.com> From: To: Subject: Re: Thank you! Date: Sun, 24 Aug 2003 23:17:21 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_018C1C2B" This is a multipart message in MIME format --_NextPart_000_018C1C2B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_018C1C2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) details.pif is removed from here because it contains a virus. --------------------------------------------------------- --_NextPart_000_018C1C2B-- --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Sun Aug 24 17:20:55 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 RAA25304 for ; Sun, 24 Aug 2003 17:20:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r2Ho-0007gr-3S for idr-archive@odin.ietf.org; Sun, 24 Aug 2003 17:20:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OLKWd3029555 for idr-archive@odin.ietf.org; Sun, 24 Aug 2003 17:20:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r2Ho-0007gc-02 for idr-web-archive@optimus.ietf.org; Sun, 24 Aug 2003 17: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 RAA25246; Sun, 24 Aug 2003 17:20:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r2Hl-0003vn-00; Sun, 24 Aug 2003 17:20:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19r2Hk-0003vi-00; Sun, 24 Aug 2003 17:20:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r2HL-0007dk-Rc; Sun, 24 Aug 2003 17:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r2Gq-0007cr-GO for idr@optimus.ietf.org; Sun, 24 Aug 2003 17:19: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 RAA25189 for ; Sun, 24 Aug 2003 17:19:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r2Go-0003uM-00 for idr@ietf.org; Sun, 24 Aug 2003 17:19:30 -0400 Received: from sj-inbound-3.cisco.com ([128.107.250.144]) by ietf-mx with esmtp (Exim 4.12) id 19r2Gm-0003tb-00 for idr@ietf.org; Sun, 24 Aug 2003 17:19:28 -0400 Received: from localhost (localhost) by sj-inbound-3.cisco.com (8.12.8p1/8.11.2) id h7OLJ6xN019052; Sun, 24 Aug 2003 14:19:06 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <200308242119.h7OLJ6xN019052@sj-inbound-3.cisco.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com" Auto-Submitted: auto-generated (failure) Subject: [Idr] Returned mail: see transcript for details 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: Sun, 24 Aug 2003 14:19:06 -0700 (PDT) This is a MIME-encapsulated message --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_SOBIG.F in file details.pif The uncleanable file details.pif is moved to /etc/iscan/virus/virPNA96aGKC. --------------------------------------------------------- --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com The original message was received at Sun, 24 Aug 2003 14:17:38 -0700 (PDT) from 226.Red-80-33-226.pooles.rima-tde.net [80.33.226.226] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 ... User unknown) (expanded from: ) ----- Transcript of session follows ----- ... while talking to sj-core-2.cisco.com.: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: message/delivery-status Reporting-MTA: dns; sj-inbound-3.cisco.com Received-From-MTA: DNS; 226.Red-80-33-226.pooles.rima-tde.net Arrival-Date: Sun, 24 Aug 2003 14:17:38 -0700 (PDT) Final-Recipient: RFC822; nmenta@cisco.com X-Actual-Recipient: RFC822; nmenta@sj-core.cisco.com Action: failed Status: 5.1.1 Remote-MTA: DNS; sj-core-2.cisco.com Diagnostic-Code: SMTP; 550 5.1.1 ... User unknown Last-Attempt-Date: Sun, 24 Aug 2003 14:19:06 -0700 (PDT) --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: message/rfc822 Return-Path: Received: from PC1 (226.Red-80-33-226.pooles.rima-tde.net [80.33.226.226]) by sj-inbound-3.cisco.com (8.12.8p1/8.11.2) with ESMTP id h7OLHQxN017984 for ; Sun, 24 Aug 2003 14:17:38 -0700 (PDT) Message-Id: <200308242117.h7OLHQxN017984@sj-inbound-3.cisco.com> From: To: Subject: Re: Thank you! Date: Sun, 24 Aug 2003 23:17:21 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_018C1C2B" This is a multipart message in MIME format --_NextPart_000_018C1C2B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_018C1C2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) details.pif is removed from here because it contains a virus. --------------------------------------------------------- --_NextPart_000_018C1C2B-- --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Sun Aug 24 18:48: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 SAA29820; Sun, 24 Aug 2003 18:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r3ed-000565-00; Sun, 24 Aug 2003 18:48:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19r3ec-000562-00; Sun, 24 Aug 2003 18:48:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3eT-0001rI-Nr; Sun, 24 Aug 2003 18:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3dc-0001qz-7G for idr@optimus.ietf.org; Sun, 24 Aug 2003 18:47: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 SAA29774 for ; Sun, 24 Aug 2003 18:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r3dZ-00055X-00 for idr@ietf.org; Sun, 24 Aug 2003 18:47:05 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19r3dY-00055G-00 for idr@ietf.org; Sun, 24 Aug 2003 18:47:04 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7OMkY73022016 for idr@ietf.org; Sun, 24 Aug 2003 18:46:34 -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 h7OMkMAg021992 for ; Sun, 24 Aug 2003 18:46:22 -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 Message-ID: Thread-Topic: FSM Text for section 8.1.2 Thread-Index: AcNqkYqqU3VSlgUsQBG+n0V9PoNoyw== From: "Susan Hares" To: Cc: , X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: quoted-printable Subject: [Idr] FSM Text for section 8.1.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: Sun, 24 Aug 2003 18:46:22 -0400 Content-Transfer-Encoding: quoted-printable Implementors and BGP FSM geeks:=20 What should happen if the optional attributes are not set as they should for Events 1-8. In the current text, I have the local system only issuing a warning. Should a stronger tact be taken? Sue =3D=3D=3D=3D=3D=3D=3D=3D 8.1.2 Administrative Events An administrative event is an event in which the operator interface and BGP Policy engine signal the BGP finite state machine to start=20 or stop the BGP state machine. The basic start and stop indication are augmented by optional connection attributes to signal a certain type of start or stop mechanism to the BGP FSM. An example of this=20 combination is event 5: AutomaticStart_with_PassiveTcpEstablishment. With this event, the BGP implementatin signals to the BGP FSM that the implementation is using an Automatic Start with option to use a Passive TCP Establishment. The Passive TCP establishment signals that this BGP FSM will wait for the remote side to start the TCP establishment.=20 || Please note that only Event 1 (ManualStart) and Event 2 (ManualStop) are mandatory administrative events. All other administrative events are optional (Events 3-8). Each event below has a name, definition, status (mandatory or optional), and what optional session attributes SHOULD be set at each stage. When generating Event1=20 through Event8 for the BGP FSM, conditions specified in the=20 Optional Attribute Status section are verified. If=20 || any of them is not satisfied, then the local system should log a FSM || error. =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Sun Aug 24 18:48: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 SAA29850 for ; Sun, 24 Aug 2003 18:48: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 19r3eh-0001tx-1c for idr-archive@odin.ietf.org; Sun, 24 Aug 2003 18:48:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7OMmFfI007303 for idr-archive@odin.ietf.org; Sun, 24 Aug 2003 18:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3eg-0001ti-UY for idr-web-archive@optimus.ietf.org; Sun, 24 Aug 2003 18:48: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 SAA29820; Sun, 24 Aug 2003 18:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r3ed-000565-00; Sun, 24 Aug 2003 18:48:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19r3ec-000562-00; Sun, 24 Aug 2003 18:48:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3eT-0001rI-Nr; Sun, 24 Aug 2003 18:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3dc-0001qz-7G for idr@optimus.ietf.org; Sun, 24 Aug 2003 18:47: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 SAA29774 for ; Sun, 24 Aug 2003 18:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r3dZ-00055X-00 for idr@ietf.org; Sun, 24 Aug 2003 18:47:05 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19r3dY-00055G-00 for idr@ietf.org; Sun, 24 Aug 2003 18:47:04 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7OMkY73022016 for idr@ietf.org; Sun, 24 Aug 2003 18:46:34 -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 h7OMkMAg021992 for ; Sun, 24 Aug 2003 18:46:22 -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 Message-ID: Thread-Topic: FSM Text for section 8.1.2 Thread-Index: AcNqkYqqU3VSlgUsQBG+n0V9PoNoyw== From: "Susan Hares" To: Cc: , X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: quoted-printable Subject: [Idr] FSM Text for section 8.1.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: Sun, 24 Aug 2003 18:46:22 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Implementors and BGP FSM geeks:=20 What should happen if the optional attributes are not set as they should for Events 1-8. In the current text, I have the local system only issuing a warning. Should a stronger tact be taken? Sue =3D=3D=3D=3D=3D=3D=3D=3D 8.1.2 Administrative Events An administrative event is an event in which the operator interface and BGP Policy engine signal the BGP finite state machine to start=20 or stop the BGP state machine. The basic start and stop indication are augmented by optional connection attributes to signal a certain type of start or stop mechanism to the BGP FSM. An example of this=20 combination is event 5: AutomaticStart_with_PassiveTcpEstablishment. With this event, the BGP implementatin signals to the BGP FSM that the implementation is using an Automatic Start with option to use a Passive TCP Establishment. The Passive TCP establishment signals that this BGP FSM will wait for the remote side to start the TCP establishment.=20 || Please note that only Event 1 (ManualStart) and Event 2 (ManualStop) are mandatory administrative events. All other administrative events are optional (Events 3-8). Each event below has a name, definition, status (mandatory or optional), and what optional session attributes SHOULD be set at each stage. When generating Event1=20 through Event8 for the BGP FSM, conditions specified in the=20 Optional Attribute Status section are verified. If=20 || any of them is not satisfied, then the local system should log a FSM || error. =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From owner-idr@merit.edu Mon Aug 25 12:31: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 MAA27222 for ; Mon, 25 Aug 2003 12:31:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rKG1-0003Du-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 12:31:53 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19rKG0-0003Dr-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 12:31:52 -0400 Received: by trapdoor.merit.edu (Postfix) id 428EE91227; Mon, 25 Aug 2003 12:31:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E6B291212; Mon, 25 Aug 2003 12:31:06 -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 0BCFD91213 for ; Mon, 25 Aug 2003 12:31:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD0CB5DD9B; Mon, 25 Aug 2003 12:31:03 -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 11D735DD8C for ; Mon, 25 Aug 2003 12:31:03 -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 MAA26979; Mon, 25 Aug 2003 12:30:56 -0400 (EDT) Message-Id: <200308251630.MAA26979@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-bgp-ext-communities-06.txt Date: Mon, 25 Aug 2003 12:30:56 -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 : BGP Extended Communities Attribute Author(s) : S. Sangli, D. Tappan, Y. Rekhter Filename : draft-ietf-idr-bgp-ext-communities-06.txt Pages : 11 Date : 2003-8-25 This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-ext-communities-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-ext-communities-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124222.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Aug 25 12:34:21 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 MAA27359 for ; Mon, 25 Aug 2003 12:34:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rKIU-0003Eu-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 12:34:26 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19rKIT-0003Ek-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 12:34:25 -0400 Received: by trapdoor.merit.edu (Postfix) id B2A4491213; Mon, 25 Aug 2003 12:33:52 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B86F9122D; Mon, 25 Aug 2003 12:32:34 -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 B010091210 for ; Mon, 25 Aug 2003 12:31:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E0D05DD9E; Mon, 25 Aug 2003 12:31:18 -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 CC5F15DD9B for ; Mon, 25 Aug 2003 12:31:17 -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 MAA27060; Mon, 25 Aug 2003 12:31:11 -0400 (EDT) Message-Id: <200308251631.MAA27060@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-restart-07.txt Date: Mon, 25 Aug 2003 12:31:11 -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 : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, Y. Rekhter Filename : draft-ietf-idr-restart-07.txt Pages : 10 Date : 2003-8-25 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-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124257.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Aug 25 12:34:36 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 MAA27386 for ; Mon, 25 Aug 2003 12:34:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rKIj-0003F5-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 12:34:41 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19rKIi-0003F0-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 12:34:41 -0400 Received: by trapdoor.merit.edu (Postfix) id 79E93912FB; Mon, 25 Aug 2003 12:34:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F155912F4; Mon, 25 Aug 2003 12:32: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 60EF39122D for ; Mon, 25 Aug 2003 12:31:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47A005DD9F; Mon, 25 Aug 2003 12:31:14 -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 9A1405DD9B for ; Mon, 25 Aug 2003 12:31:13 -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 MAA27040; Mon, 25 Aug 2003 12:31:07 -0400 (EDT) Message-Id: <200308251631.MAA27040@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-route-filter-09.txt Date: Mon, 25 Aug 2003 12:31:06 -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 : Cooperative Route Filtering Capability for BGP-4 Author(s) : Y. Rekhter Filename : draft-ietf-idr-route-filter-09.txt Pages : 11 Date : 2003-8-25 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.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-route-filter-09.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-route-filter-09.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-25124243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124243.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Aug 25 12:34: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 MAA27433 for ; Mon, 25 Aug 2003 12:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rKJ2-0003Fb-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 12:35:00 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19rKJ1-0003FU-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 12:35:00 -0400 Received: by trapdoor.merit.edu (Postfix) id 320819122D; Mon, 25 Aug 2003 12:34:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B62B0912F6; Mon, 25 Aug 2003 12:32:16 -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 0212391212 for ; Mon, 25 Aug 2003 12:31:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5C9C5DD9C; Mon, 25 Aug 2003 12:31:08 -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 ED0D35DD9B for ; Mon, 25 Aug 2003 12:31:07 -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 MAA27008; Mon, 25 Aug 2003 12:31:01 -0400 (EDT) Message-Id: <200308251631.MAA27008@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-as4bytes-07.txt Date: Mon, 25 Aug 2003 12:31:00 -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 : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-07.txt Pages : 7 Date : 2003-8-25 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124233.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Aug 25 13:16: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 NAA00859 for ; Mon, 25 Aug 2003 13:16:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rKxi-00044A-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 13:17:02 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19rKxg-000444-00 for idr-archive@ietf.org; Mon, 25 Aug 2003 13:17:01 -0400 Received: by trapdoor.merit.edu (Postfix) id 937809124C; Mon, 25 Aug 2003 13:15:03 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04CB0912A0; Mon, 25 Aug 2003 13:15: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 B799B9124C for ; Mon, 25 Aug 2003 13:14:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A41375DE1E; Mon, 25 Aug 2003 13:14:56 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by segue.merit.edu (Postfix) with ESMTP id 8AEA85DDF7 for ; Mon, 25 Aug 2003 13:14:56 -0400 (EDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 62944206612 for ; Mon, 25 Aug 2003 13:13:13 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19rKGY-00054m-Vt for ietf-announce-list@asgard.ietf.org; Mon, 25 Aug 2003 12:32:26 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19rKFI-00050N-Vq for all-ietf@asgard.ietf.org; Mon, 25 Aug 2003 12:31:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27008; Mon, 25 Aug 2003 12:31:01 -0400 (EDT) Message-Id: <200308251631.MAA27008@ietf.org> 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-as4bytes-07.txt Date: Mon, 25 Aug 2003 12:31:00 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+262543_1626997315243_04064103429" Sender: owner-idr@merit.edu Precedence: bulk --MIMEStream=_0+262543_1626997315243_04064103429 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 support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-07.txt Pages : 7 Date : 2003-8-25 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+262543_1626997315243_04064103429 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+222605_9095457151103_89977243142" --MIMEStream=_1+222605_9095457151103_89977243142 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-07.txt --MIMEStream=_1+222605_9095457151103_89977243142 Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124233.I-D@ietf.org> --MIMEStream=_1+222605_9095457151103_89977243142-- --MIMEStream=_0+262543_1626997315243_04064103429-- From owner-idr@merit.edu Tue Aug 26 09:09: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 JAA02436 for ; Tue, 26 Aug 2003 09:09:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rdZf-0000Sl-00 for idr-archive@ietf.org; Tue, 26 Aug 2003 09:09:27 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19rdZe-0000Sg-00 for idr-archive@ietf.org; Tue, 26 Aug 2003 09:09:26 -0400 Received: by trapdoor.merit.edu (Postfix) id 5E7E891234; Tue, 26 Aug 2003 09:09:11 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2234591251; Tue, 26 Aug 2003 09:09:11 -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 F1BA491234 for ; Tue, 26 Aug 2003 09:09:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6E015DD91; Tue, 26 Aug 2003 09:09:09 -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 5A68F5DD8C for ; Tue, 26 Aug 2003 09:09:09 -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 h7QD94Y72171; Tue, 26 Aug 2003 06:09:04 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308261309.h7QD94Y72171@merlot.juniper.net> To: idr@merit.edu Cc: Sandy Murphy , skh@nexthop.com Subject: draft-ietf-idr-bgp-vuln-00.txt to Informational MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64422.1061903344.1@juniper.net> Date: Tue, 26 Aug 2003 06:09:04 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-bgp-vuln-00.txt to an Informational RFC. The Last Call ends Sep 11, 2003. Yakov. From owner-idr@merit.edu Tue Aug 26 10:06: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 KAA04920 for ; Tue, 26 Aug 2003 10:05:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19reSR-0000yI-00 for idr-archive@ietf.org; Tue, 26 Aug 2003 10:06:03 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19reSQ-0000y8-00 for idr-archive@ietf.org; Tue, 26 Aug 2003 10:06:02 -0400 Received: by trapdoor.merit.edu (Postfix) id 28DB291267; Tue, 26 Aug 2003 10:05:44 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA9E091268; Tue, 26 Aug 2003 10:05:43 -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 A7CB791267 for ; Tue, 26 Aug 2003 10:05:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 91DD65DD94; Tue, 26 Aug 2003 10:05:42 -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 F13415DD8E for ; Tue, 26 Aug 2003 10:05:41 -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 KAA04798; Tue, 26 Aug 2003 10:05:37 -0400 (EDT) Message-Id: <200308261405.KAA04798@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-aspath-orf-05.txt Date: Tue, 26 Aug 2003 10:05:36 -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 : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-05.txt Pages : 0 Date : 2003-8-26 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-26102416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-26102416.I-D@ietf.org> --OtherAccess-- --NextPart-- From idr-admin@ietf.org Tue Aug 26 15:00:03 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 PAA22037; Tue, 26 Aug 2003 15:00: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 19rj0U-0004Gj-3Q; Tue, 26 Aug 2003 14:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rNZY-0007yF-8x for idr@optimus.ietf.org; Mon, 25 Aug 2003 16:04: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 QAA13551 for ; Mon, 25 Aug 2003 16:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rNZW-0006nq-00 for idr@ietf.org; Mon, 25 Aug 2003 16:04:14 -0400 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 19rNZV-0006nY-00 for idr@ietf.org; Mon, 25 Aug 2003 16:04:14 -0400 Received: from tom3 (1Cust187.tnt6.lnd4.gbr.da.uu.net [62.188.135.187]) by colossus.systems.pipex.net (Postfix) with SMTP id F0D971600004D for ; Mon, 25 Aug 2003 21:03:41 +0100 (BST) Message-ID: <003801c36b43$b2be4260$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "idr" Subject: Re: [Idr] FSM Text for section 8.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 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, 25 Aug 2003 21:00:29 +0100 Content-Transfer-Encoding: 7bit I am happy content with the action as described. Linked with this, I have assumed, and looking again at the FSM perhaps this is my invention, that if an optional aspect is not implemented, then the associated values are always set to FALSE so I see them as always set, TRUE or FALSE, as opposed to having a not set state. For me this is simpler than eihter considering three states (TRUE, FALSE, not set) or an ambiguity as to whether not set means FALSE (as opposed to a third state). Tom Petch -----Original Message----- From: Susan Hares To: idr@ietf.org Cc: yakov@juniper.net ; zinin@psg.org Date: 24 August 2003 23:48 Subject: [Idr] FSM Text for section 8.1.2 Implementors and BGP FSM geeks: What should happen if the optional attributes are not set as they should for Events 1-8. In the current text, I have the local system only issuing a warning. Should a stronger tact be taken? Sue ======== 8.1.2 Administrative Events An administrative event is an event in which the operator interface and BGP Policy engine signal the BGP finite state machine to start or stop the BGP state machine. The basic start and stop indication are augmented by optional connection attributes to signal a certain type of start or stop mechanism to the BGP FSM. An example of this combination is event 5: AutomaticStart_with_PassiveTcpEstablishment. With this event, the BGP implementatin signals to the BGP FSM that the implementation is using an Automatic Start with option to use a Passive TCP Establishment. The Passive TCP establishment signals that this BGP FSM will wait for the remote side to start the TCP establishment. || Please note that only Event 1 (ManualStart) and Event 2 (ManualStop) are mandatory administrative events. All other administrative events are optional (Events 3-8). Each event below has a name, definition, status (mandatory or optional), and what optional session attributes SHOULD be set at each stage. When generating Event1 through Event8 for the BGP FSM, conditions specified in the Optional Attribute Status section are verified. If || any of them is not satisfied, then the local system should log a FSM || error. _______________________________________________ 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 Aug 26 15: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 PAA22103 for ; Tue, 26 Aug 2003 15: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 19rj35-0005Rd-OB for idr-archive@odin.ietf.org; Tue, 26 Aug 2003 15:00:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJ0Boo020929 for idr-archive@odin.ietf.org; Tue, 26 Aug 2003 15:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj35-0005RU-LM for idr-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 15:00:11 -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 PAA22037; Tue, 26 Aug 2003 15:00: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 19rj0U-0004Gj-3Q; Tue, 26 Aug 2003 14:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rNZY-0007yF-8x for idr@optimus.ietf.org; Mon, 25 Aug 2003 16:04: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 QAA13551 for ; Mon, 25 Aug 2003 16:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rNZW-0006nq-00 for idr@ietf.org; Mon, 25 Aug 2003 16:04:14 -0400 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 19rNZV-0006nY-00 for idr@ietf.org; Mon, 25 Aug 2003 16:04:14 -0400 Received: from tom3 (1Cust187.tnt6.lnd4.gbr.da.uu.net [62.188.135.187]) by colossus.systems.pipex.net (Postfix) with SMTP id F0D971600004D for ; Mon, 25 Aug 2003 21:03:41 +0100 (BST) Message-ID: <003801c36b43$b2be4260$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "idr" Subject: Re: [Idr] FSM Text for section 8.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 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, 25 Aug 2003 21:00:29 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am happy content with the action as described. Linked with this, I have assumed, and looking again at the FSM perhaps this is my invention, that if an optional aspect is not implemented, then the associated values are always set to FALSE so I see them as always set, TRUE or FALSE, as opposed to having a not set state. For me this is simpler than eihter considering three states (TRUE, FALSE, not set) or an ambiguity as to whether not set means FALSE (as opposed to a third state). Tom Petch -----Original Message----- From: Susan Hares To: idr@ietf.org Cc: yakov@juniper.net ; zinin@psg.org Date: 24 August 2003 23:48 Subject: [Idr] FSM Text for section 8.1.2 Implementors and BGP FSM geeks: What should happen if the optional attributes are not set as they should for Events 1-8. In the current text, I have the local system only issuing a warning. Should a stronger tact be taken? Sue ======== 8.1.2 Administrative Events An administrative event is an event in which the operator interface and BGP Policy engine signal the BGP finite state machine to start or stop the BGP state machine. The basic start and stop indication are augmented by optional connection attributes to signal a certain type of start or stop mechanism to the BGP FSM. An example of this combination is event 5: AutomaticStart_with_PassiveTcpEstablishment. With this event, the BGP implementatin signals to the BGP FSM that the implementation is using an Automatic Start with option to use a Passive TCP Establishment. The Passive TCP establishment signals that this BGP FSM will wait for the remote side to start the TCP establishment. || Please note that only Event 1 (ManualStart) and Event 2 (ManualStop) are mandatory administrative events. All other administrative events are optional (Events 3-8). Each event below has a name, definition, status (mandatory or optional), and what optional session attributes SHOULD be set at each stage. When generating Event1 through Event8 for the BGP FSM, conditions specified in the Optional Attribute Status section are verified. If || any of them is not satisfied, then the local system should log a FSM || error. _______________________________________________ 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 Aug 26 22:18:08 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 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 owner-idr@merit.edu Wed Aug 27 10:27: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 KAA01765 for ; Wed, 27 Aug 2003 10:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1Gr-00071Z-00 for idr-archive@ietf.org; Wed, 27 Aug 2003 10:27:37 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19s1Gp-00071P-00 for idr-archive@ietf.org; Wed, 27 Aug 2003 10:27:35 -0400 Received: by trapdoor.merit.edu (Postfix) id 7B4E891290; Wed, 27 Aug 2003 10:27:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 264E691292; Wed, 27 Aug 2003 10:27:18 -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 DBC4491290 for ; Wed, 27 Aug 2003 10:27:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9CCC5DDE8; Wed, 27 Aug 2003 10:27:16 -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 445775DD91 for ; Wed, 27 Aug 2003 10:27: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 KAA01660; Wed, 27 Aug 2003 10:27:11 -0400 (EDT) Message-Id: <200308271427.KAA01660@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-01.txt Date: Wed, 27 Aug 2003 10:27:11 -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-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-- From owner-idr@merit.edu Wed Aug 27 10:28: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 KAA01831 for ; Wed, 27 Aug 2003 10:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1HL-000722-00 for idr-archive@ietf.org; Wed, 27 Aug 2003 10:28:07 -0400 Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19s1HJ-00071e-00 for idr-archive@ietf.org; Wed, 27 Aug 2003 10:28:05 -0400 Received: by trapdoor.merit.edu (Postfix) id 3CD3B91293; Wed, 27 Aug 2003 10:27:21 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E215791292; Wed, 27 Aug 2003 10:27:20 -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 364F691293 for ; Wed, 27 Aug 2003 10:27:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F9655DDE8; Wed, 27 Aug 2003 10:27:18 -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 99B365DDE4 for ; Wed, 27 Aug 2003 10:27:12 -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 KAA01627; Wed, 27 Aug 2003 10:27:06 -0400 (EDT) Message-Id: <200308271427.KAA01627@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-rfc3065bis-00.txt Date: Wed, 27 Aug 2003 10:27:05 -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 : Autonomous System Confederations for BGP Author(s) : P. Traina et al. Filename : draft-ietf-idr-rfc3065bis-00.txt Pages : 16 Date : 2003-8-27 The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the 'full mesh' requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-rfc3065bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-rfc3065bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-27103549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc3065bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc3065bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-27103549.I-D@ietf.org> --OtherAccess-- --NextPart-- From idr-admin@ietf.org Wed Aug 27 16:36:39 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 QAA06602; Wed, 27 Aug 2003 16:36:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s71z-000045-00; Wed, 27 Aug 2003 16:36:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s71z-000042-00; Wed, 27 Aug 2003 16:36:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qt-0002bb-Eb; Wed, 27 Aug 2003 14:54:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s1Vw-00066H-4P for idr@optimus.ietf.org; Wed, 27 Aug 2003 10:43:12 -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 KAA02955 for ; Wed, 27 Aug 2003 10:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1Vt-0007EK-00 for idr@ietf.org; Wed, 27 Aug 2003 10:43:09 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19s1Vr-0007D8-00 for idr@ietf.org; Wed, 27 Aug 2003 10:43:08 -0400 Received: from arbor.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 4CAD820298 for ; Wed, 27 Aug 2003 14:46:46 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; 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-rfc3065bis-00.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, 27 Aug 2003 08:42:30 -0600 Content-Transfer-Encoding: 7bit Folks, There are quite a few changes (relatively speaking) in this version. Some to do with attribute handling, some error handling, some basic terminology cleanup, and a few miscellaneous other things. I believe I've incorporated all feedback from the last version of the draft. Also, we had one change that didn't make it into this cut, here's a diff of what's currently there and what'll be in the next revision: danny@rambler% diff ../draft-ietf-idr-rfc3065bis-00/draft-ietf-idr-rfc3065bis-00.txt draft-ietf-idr-rfc3065bis-01.txt 493d492 < In addition, the following rules SHALL be applied: 495,496c494,496 < 1) If the AS_PATH is internal to the local confederation (i.e., there < are only AS_CONFED_* segments) consider the neighbor AS to be the --- > In addition, the following rules SHOULD be applied: > > 1) If the AS_PATH begins with an AS_CONFED_SEQUENCE, consider the 505c505 < leftmost AS_CONFED_SEQUENCE AS. --- > neighbor AS to be the leftmost AS_CONFED_SEQUENCE AS. 507,509c507,509 < 2) If the AS_PATH is external to the local confederation (i.e., there < are one or more non-AS_CONFED_* segments) consider the neighbor AS < to be the leftmost AS_SEQUENCE AS. --- > 2) Otherwise, if the first segment in the path which is not an > AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider > the neighbor AS to be the leftmost AS_CONFED_SEQUENCE AS. Comments and feedback welcome. Thanks! -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed Aug 27, 2003 8:27:05 AM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-rfc3065bis-00.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 : Autonomous System Confederations for BGP > Author(s) : P. Traina et al. > Filename : draft-ietf-idr-rfc3065bis-00.txt > Pages : 16 > Date : 2003-8-27 > > The Border Gateway Protocol (BGP) is an inter-autonomous system > routing protocol designed for Transmission Control Protocol/Internet > Protocol (TCP/IP) networks. BGP requires that all BGP speakers > within a single autonomous system (AS) must be fully meshed. This > represents a serious scaling problem that has been well documented in > a number of proposals. > This document describes an extension to BGP which may be used to > create a confederation of autonomous systems that is represented as a > single autonomous system to BGP peers external to the confederation, > thereby removing the 'full mesh' requirement. The intention of this > extension is to aid in policy administration and reduce the > management complexity of maintaining a large autonomous system. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-idr-rfc3065bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-idr-rfc3065bis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-8-27103549.I-D@ietf.org> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Aug 27 16:38:47 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 QAA06766; Wed, 27 Aug 2003 16:38:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s747-00006H-00; Wed, 27 Aug 2003 16:38:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s746-00006D-00; Wed, 27 Aug 2003 16:38:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s46c-0005N1-Bb; Wed, 27 Aug 2003 13:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rq1s-0006AK-NO for idr@optimus.ietf.org; Tue, 26 Aug 2003 22:27: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 WAA07273 for ; Tue, 26 Aug 2003 22:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rq1p-0001Da-00 for idr@ietf.org; Tue, 26 Aug 2003 22:27:21 -0400 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 19rq1o-0001DR-00 for idr@ietf.org; Tue, 26 Aug 2003 22:27:20 -0400 Received: (qmail 27546 invoked from network); 27 Aug 2003 02:27:04 -0000 Received: from localhost (HELO challah.msrl.com) (127.0.0.1) by localhost with SMTP; 27 Aug 2003 02:27:04 -0000 To: Jeffrey Haas Cc: idr@ietf.org Subject: Re: [Idr] BGP-MIBv1 - counter issues References: <20030826115007.B8307@nexthop.com> From: Vijay Gill Organization: vgill global logistics Original-Sender: vgill@vijaygill.com In-Reply-To: <20030826115007.B8307@nexthop.com> Message-ID: <7mad9v6dje.fsf@challah.msrl.com> Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) 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: 27 Aug 2003 02:27:01 +0000 Jeffrey Haas writes: > 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? > What value should they have in your opinion given the following: 1) cold start of router 2) bgp session established with a new AS (new config) 3) bgp session established but was reset either manually or by circuit flap, etc. 4) bgp was established, config was accidently removed and then reinserted from backup /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Aug 27 17:01: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 RAA08272; Wed, 27 Aug 2003 17:01:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s7QJ-0000TE-00; Wed, 27 Aug 2003 17:01:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s7QI-0000TB-00; Wed, 27 Aug 2003 17:01:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qo-0002Zv-Fm; Wed, 27 Aug 2003 14:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s1Xm-0006BG-UK for idr@optimus.ietf.org; Wed, 27 Aug 2003 10:45: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 KAA03302 for ; Wed, 27 Aug 2003 10:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1Xj-0007LQ-00 for idr@ietf.org; Wed, 27 Aug 2003 10:45:03 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19s1Xh-0007Ka-00 for idr@ietf.org; Wed, 27 Aug 2003 10:45:01 -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 D696E20298 for ; Wed, 27 Aug 2003 14:48:45 -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-01.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, 27 Aug 2003 08:44:30 -0600 Content-Transfer-Encoding: 7bit I think we've incorporated all the feedback to date. We're planning to Last Call this RSN so please provide feedback, text, corrections or other ASAP if you would. Thanks! -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed Aug 27, 2003 8:27:11 AM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-01.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-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. > Content-Type: text/plain > Content-ID: <2003-8-27103600.I-D@ietf.org> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Aug 28 03:21:28 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 DAA11044 for ; Thu, 28 Aug 2003 03: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 19sCaX-0001jN-Vh for idr-archive@odin.ietf.org; Wed, 27 Aug 2003 22:32:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2Wf8E006645 for idr-archive@odin.ietf.org; Wed, 27 Aug 2003 22:32:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s725-0006yA-SZ for idr-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 16:36: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 QAA06602; Wed, 27 Aug 2003 16:36:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s71z-000045-00; Wed, 27 Aug 2003 16:36:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s71z-000042-00; Wed, 27 Aug 2003 16:36:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qt-0002bb-Eb; Wed, 27 Aug 2003 14:54:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s1Vw-00066H-4P for idr@optimus.ietf.org; Wed, 27 Aug 2003 10:43:12 -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 KAA02955 for ; Wed, 27 Aug 2003 10:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1Vt-0007EK-00 for idr@ietf.org; Wed, 27 Aug 2003 10:43:09 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19s1Vr-0007D8-00 for idr@ietf.org; Wed, 27 Aug 2003 10:43:08 -0400 Received: from arbor.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 4CAD820298 for ; Wed, 27 Aug 2003 14:46:46 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; 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-rfc3065bis-00.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, 27 Aug 2003 08:42:30 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, There are quite a few changes (relatively speaking) in this version. Some to do with attribute handling, some error handling, some basic terminology cleanup, and a few miscellaneous other things. I believe I've incorporated all feedback from the last version of the draft. Also, we had one change that didn't make it into this cut, here's a diff of what's currently there and what'll be in the next revision: danny@rambler% diff ../draft-ietf-idr-rfc3065bis-00/draft-ietf-idr-rfc3065bis-00.txt draft-ietf-idr-rfc3065bis-01.txt 493d492 < In addition, the following rules SHALL be applied: 495,496c494,496 < 1) If the AS_PATH is internal to the local confederation (i.e., there < are only AS_CONFED_* segments) consider the neighbor AS to be the --- > In addition, the following rules SHOULD be applied: > > 1) If the AS_PATH begins with an AS_CONFED_SEQUENCE, consider the 505c505 < leftmost AS_CONFED_SEQUENCE AS. --- > neighbor AS to be the leftmost AS_CONFED_SEQUENCE AS. 507,509c507,509 < 2) If the AS_PATH is external to the local confederation (i.e., there < are one or more non-AS_CONFED_* segments) consider the neighbor AS < to be the leftmost AS_SEQUENCE AS. --- > 2) Otherwise, if the first segment in the path which is not an > AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider > the neighbor AS to be the leftmost AS_CONFED_SEQUENCE AS. Comments and feedback welcome. Thanks! -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed Aug 27, 2003 8:27:05 AM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-rfc3065bis-00.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 : Autonomous System Confederations for BGP > Author(s) : P. Traina et al. > Filename : draft-ietf-idr-rfc3065bis-00.txt > Pages : 16 > Date : 2003-8-27 > > The Border Gateway Protocol (BGP) is an inter-autonomous system > routing protocol designed for Transmission Control Protocol/Internet > Protocol (TCP/IP) networks. BGP requires that all BGP speakers > within a single autonomous system (AS) must be fully meshed. This > represents a serious scaling problem that has been well documented in > a number of proposals. > This document describes an extension to BGP which may be used to > create a confederation of autonomous systems that is represented as a > single autonomous system to BGP peers external to the confederation, > thereby removing the 'full mesh' requirement. The intention of this > extension is to aid in policy administration and reduce the > management complexity of maintaining a large autonomous system. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-idr-rfc3065bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-idr-rfc3065bis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-8-27103549.I-D@ietf.org> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Aug 28 03:31:40 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 DAA11798 for ; Thu, 28 Aug 2003 03:31:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCyi-00046a-8j for idr-archive@odin.ietf.org; Wed, 27 Aug 2003 22:57:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2ve48015770 for idr-archive@odin.ietf.org; Wed, 27 Aug 2003 22:57:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s749-0007Hp-VI for idr-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 16:38:53 -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 QAA06766; Wed, 27 Aug 2003 16:38:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s747-00006H-00; Wed, 27 Aug 2003 16:38:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s746-00006D-00; Wed, 27 Aug 2003 16:38:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s46c-0005N1-Bb; Wed, 27 Aug 2003 13:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rq1s-0006AK-NO for idr@optimus.ietf.org; Tue, 26 Aug 2003 22:27: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 WAA07273 for ; Tue, 26 Aug 2003 22:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rq1p-0001Da-00 for idr@ietf.org; Tue, 26 Aug 2003 22:27:21 -0400 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 19rq1o-0001DR-00 for idr@ietf.org; Tue, 26 Aug 2003 22:27:20 -0400 Received: (qmail 27546 invoked from network); 27 Aug 2003 02:27:04 -0000 Received: from localhost (HELO challah.msrl.com) (127.0.0.1) by localhost with SMTP; 27 Aug 2003 02:27:04 -0000 To: Jeffrey Haas Cc: idr@ietf.org Subject: Re: [Idr] BGP-MIBv1 - counter issues References: <20030826115007.B8307@nexthop.com> From: Vijay Gill Organization: vgill global logistics Original-Sender: vgill@vijaygill.com In-Reply-To: <20030826115007.B8307@nexthop.com> Message-ID: <7mad9v6dje.fsf@challah.msrl.com> Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) 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: 27 Aug 2003 02:27:01 +0000 Jeffrey Haas writes: > 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? > What value should they have in your opinion given the following: 1) cold start of router 2) bgp session established with a new AS (new config) 3) bgp session established but was reset either manually or by circuit flap, etc. 4) bgp was established, config was accidently removed and then reinserted from backup /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Aug 28 04:13:17 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 EAA15300 for ; Thu, 28 Aug 2003 04:13: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 19sCo7-0003Lc-Qe for idr-archive@odin.ietf.org; Wed, 27 Aug 2003 22:46:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2khuI012859 for idr-archive@odin.ietf.org; Wed, 27 Aug 2003 22:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s7QL-0008I8-U9 for idr-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 17:01:49 -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 RAA08272; Wed, 27 Aug 2003 17:01:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s7QJ-0000TE-00; Wed, 27 Aug 2003 17:01:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s7QI-0000TB-00; Wed, 27 Aug 2003 17:01:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qo-0002Zv-Fm; Wed, 27 Aug 2003 14:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s1Xm-0006BG-UK for idr@optimus.ietf.org; Wed, 27 Aug 2003 10:45: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 KAA03302 for ; Wed, 27 Aug 2003 10:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1Xj-0007LQ-00 for idr@ietf.org; Wed, 27 Aug 2003 10:45:03 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19s1Xh-0007Ka-00 for idr@ietf.org; Wed, 27 Aug 2003 10:45:01 -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 D696E20298 for ; Wed, 27 Aug 2003 14:48:45 -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-01.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, 27 Aug 2003 08:44:30 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think we've incorporated all the feedback to date. We're planning to Last Call this RSN so please provide feedback, text, corrections or other ASAP if you would. Thanks! -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed Aug 27, 2003 8:27:11 AM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-01.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-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. > Content-Type: text/plain > Content-ID: <2003-8-27103600.I-D@ietf.org> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Aug 28 18:45: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 SAA26896; Thu, 28 Aug 2003 18:45:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sVVq-0000li-00; Thu, 28 Aug 2003 18:45:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sVVq-0000ld-00; Thu, 28 Aug 2003 18:45:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSFV-0008O8-KC; Thu, 28 Aug 2003 15:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPdb-0008Nc-3T for idr@optimus.ietf.org; Thu, 28 Aug 2003 12:28: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 MAA28081 for ; Thu, 28 Aug 2003 12:28:37 -0400 (EDT) From: ono@slab.ntt.co.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sPdZ-0002IF-00 for idr@ietf.org; Thu, 28 Aug 2003 12:28:41 -0400 Received: from 226.red-80-33-226.pooles.rima-tde.net ([80.33.226.226] helo=PC1) by ietf-mx with esmtp (Exim 4.12) id 19sPcZ-0002FZ-00 for idr@ietf.org; Thu, 28 Aug 2003 12:27:45 -0400 To: X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_01929DC4" Message-Id: Subject: [Idr] Thank you! 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, 28 Aug 2003 18:27:23 +0200 This is a multipart message in MIME format --_NextPart_000_01929DC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_01929DC4 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: thank_you.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_01929DC4-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Aug 28 22:59:04 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 WAA15859 for ; Thu, 28 Aug 2003 22:59: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 19sWhJ-0003pR-Eq for idr-archive@odin.ietf.org; Thu, 28 Aug 2003 20:01:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T011Fa014708 for idr-archive@odin.ietf.org; Thu, 28 Aug 2003 20: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 19sVVu-00010N-0b for idr-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 18:45:10 -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 SAA26896; Thu, 28 Aug 2003 18:45:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sVVq-0000li-00; Thu, 28 Aug 2003 18:45:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sVVq-0000ld-00; Thu, 28 Aug 2003 18:45:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSFV-0008O8-KC; Thu, 28 Aug 2003 15:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPdb-0008Nc-3T for idr@optimus.ietf.org; Thu, 28 Aug 2003 12:28: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 MAA28081 for ; Thu, 28 Aug 2003 12:28:37 -0400 (EDT) From: ono@slab.ntt.co.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sPdZ-0002IF-00 for idr@ietf.org; Thu, 28 Aug 2003 12:28:41 -0400 Received: from 226.red-80-33-226.pooles.rima-tde.net ([80.33.226.226] helo=PC1) by ietf-mx with esmtp (Exim 4.12) id 19sPcZ-0002FZ-00 for idr@ietf.org; Thu, 28 Aug 2003 12:27:45 -0400 To: X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_01929DC4" Message-Id: Subject: [Idr] Thank you! 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, 28 Aug 2003 18:27:23 +0200 This is a multipart message in MIME format --_NextPart_000_01929DC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_01929DC4 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: thank_you.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_01929DC4-- _______________________________________________ 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 QAA12995 for ; Thu, 28 Aug 2003 16:25:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSFV-0008OA-M5; Thu, 28 Aug 2003 15:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPdb-0008Nc-3T for idr@optimus.ietf.org; Thu, 28 Aug 2003 12:28: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 MAA28081 for ; Thu, 28 Aug 2003 12:28:37 -0400 (EDT) From: ono@slab.ntt.co.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sPdZ-0002IF-00 for idr@ietf.org; Thu, 28 Aug 2003 12:28:41 -0400 Received: from 226.red-80-33-226.pooles.rima-tde.net ([80.33.226.226] helo=PC1) by ietf-mx with esmtp (Exim 4.12) id 19sPcZ-0002FZ-00 for idr@ietf.org; Thu, 28 Aug 2003 12:27:45 -0400 To: X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_01929DC4" Message-Id: Subject: [Idr] Thank you! 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, 28 Aug 2003 18:27:23 +0200 This is a multipart message in MIME format --_NextPart_000_01929DC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_01929DC4 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: thank_you.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_01929DC4-- _______________________________________________ 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 RAA25395 for ; Wed, 27 Aug 2003 17:01: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 19s5Qo-0002Zx-Ie; Wed, 27 Aug 2003 14:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s1Xm-0006BG-UK for idr@optimus.ietf.org; Wed, 27 Aug 2003 10:45: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 KAA03302 for ; Wed, 27 Aug 2003 10:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1Xj-0007LQ-00 for idr@ietf.org; Wed, 27 Aug 2003 10:45:03 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19s1Xh-0007Ka-00 for idr@ietf.org; Wed, 27 Aug 2003 10:45:01 -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 D696E20298 for ; Wed, 27 Aug 2003 14:48:45 -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-01.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, 27 Aug 2003 08:44:30 -0600 I think we've incorporated all the feedback to date. We're planning to Last Call this RSN so please provide feedback, text, corrections or other ASAP if you would. Thanks! -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed Aug 27, 2003 8:27:11 AM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-01.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-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. > Content-Type: text/plain > Content-ID: <2003-8-27103600.I-D@ietf.org> _______________________________________________ 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 QAA25141 for ; Wed, 27 Aug 2003 16:55: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 19s46c-0005N3-Da; Wed, 27 Aug 2003 13:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rq1s-0006AK-NO for idr@optimus.ietf.org; Tue, 26 Aug 2003 22:27: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 WAA07273 for ; Tue, 26 Aug 2003 22:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rq1p-0001Da-00 for idr@ietf.org; Tue, 26 Aug 2003 22:27:21 -0400 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 19rq1o-0001DR-00 for idr@ietf.org; Tue, 26 Aug 2003 22:27:20 -0400 Received: (qmail 27546 invoked from network); 27 Aug 2003 02:27:04 -0000 Received: from localhost (HELO challah.msrl.com) (127.0.0.1) by localhost with SMTP; 27 Aug 2003 02:27:04 -0000 To: Jeffrey Haas Cc: idr@ietf.org Subject: Re: [Idr] BGP-MIBv1 - counter issues References: <20030826115007.B8307@nexthop.com> From: Vijay Gill Organization: vgill global logistics Original-Sender: vgill@vijaygill.com In-Reply-To: <20030826115007.B8307@nexthop.com> Message-ID: <7mad9v6dje.fsf@challah.msrl.com> Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) 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: 27 Aug 2003 02:27:01 +0000 Jeffrey Haas writes: > 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? > What value should they have in your opinion given the following: 1) cold start of router 2) bgp session established with a new AS (new config) 3) bgp session established but was reset either manually or by circuit flap, etc. 4) bgp was established, config was accidently removed and then reinserted from backup /vijay _______________________________________________ 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 QAA24499 for ; Wed, 27 Aug 2003 16:35: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 19s5Qt-0002bd-Gy; Wed, 27 Aug 2003 14:54:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s1Vw-00066H-4P for idr@optimus.ietf.org; Wed, 27 Aug 2003 10:43:12 -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 KAA02955 for ; Wed, 27 Aug 2003 10:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1Vt-0007EK-00 for idr@ietf.org; Wed, 27 Aug 2003 10:43:09 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19s1Vr-0007D8-00 for idr@ietf.org; Wed, 27 Aug 2003 10:43:08 -0400 Received: from arbor.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 4CAD820298 for ; Wed, 27 Aug 2003 14:46:46 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; 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-rfc3065bis-00.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, 27 Aug 2003 08:42:30 -0600 Folks, There are quite a few changes (relatively speaking) in this version. Some to do with attribute handling, some error handling, some basic terminology cleanup, and a few miscellaneous other things. I believe I've incorporated all feedback from the last version of the draft. Also, we had one change that didn't make it into this cut, here's a diff of what's currently there and what'll be in the next revision: danny@rambler% diff ../draft-ietf-idr-rfc3065bis-00/draft-ietf-idr-rfc3065bis-00.txt draft-ietf-idr-rfc3065bis-01.txt 493d492 < In addition, the following rules SHALL be applied: 495,496c494,496 < 1) If the AS_PATH is internal to the local confederation (i.e., there < are only AS_CONFED_* segments) consider the neighbor AS to be the --- > In addition, the following rules SHOULD be applied: > > 1) If the AS_PATH begins with an AS_CONFED_SEQUENCE, consider the 505c505 < leftmost AS_CONFED_SEQUENCE AS. --- > neighbor AS to be the leftmost AS_CONFED_SEQUENCE AS. 507,509c507,509 < 2) If the AS_PATH is external to the local confederation (i.e., there < are one or more non-AS_CONFED_* segments) consider the neighbor AS < to be the leftmost AS_SEQUENCE AS. --- > 2) Otherwise, if the first segment in the path which is not an > AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider > the neighbor AS to be the leftmost AS_CONFED_SEQUENCE AS. Comments and feedback welcome. Thanks! -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed Aug 27, 2003 8:27:05 AM America/Denver > To: IETF-Announce: ; > Cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-rfc3065bis-00.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 : Autonomous System Confederations for BGP > Author(s) : P. Traina et al. > Filename : draft-ietf-idr-rfc3065bis-00.txt > Pages : 16 > Date : 2003-8-27 > > The Border Gateway Protocol (BGP) is an inter-autonomous system > routing protocol designed for Transmission Control Protocol/Internet > Protocol (TCP/IP) networks. BGP requires that all BGP speakers > within a single autonomous system (AS) must be fully meshed. This > represents a serious scaling problem that has been well documented in > a number of proposals. > This document describes an extension to BGP which may be used to > create a confederation of autonomous systems that is represented as a > single autonomous system to BGP peers external to the confederation, > thereby removing the 'full mesh' requirement. The intention of this > extension is to aid in policy administration and reduce the > management complexity of maintaining a large autonomous system. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-idr-rfc3065bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-idr-rfc3065bis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2003-8-27103549.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 KAA12101 for ; Wed, 27 Aug 2003 10:28:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3CD3B91293; Wed, 27 Aug 2003 10:27:21 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E215791292; Wed, 27 Aug 2003 10:27:20 -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 364F691293 for ; Wed, 27 Aug 2003 10:27:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F9655DDE8; Wed, 27 Aug 2003 10:27:18 -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 99B365DDE4 for ; Wed, 27 Aug 2003 10:27:12 -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 KAA01627; Wed, 27 Aug 2003 10:27:06 -0400 (EDT) Message-Id: <200308271427.KAA01627@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-rfc3065bis-00.txt Date: Wed, 27 Aug 2003 10:27:05 -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 : Autonomous System Confederations for BGP Author(s) : P. Traina et al. Filename : draft-ietf-idr-rfc3065bis-00.txt Pages : 16 Date : 2003-8-27 The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the 'full mesh' requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-rfc3065bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-rfc3065bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-27103549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc3065bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc3065bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-27103549.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 KAA12079 for ; Wed, 27 Aug 2003 10:27:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B4E891290; Wed, 27 Aug 2003 10:27:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 264E691292; Wed, 27 Aug 2003 10:27:18 -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 DBC4491290 for ; Wed, 27 Aug 2003 10:27:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9CCC5DDE8; Wed, 27 Aug 2003 10:27:16 -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 445775DD91 for ; Wed, 27 Aug 2003 10:27: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 KAA01660; Wed, 27 Aug 2003 10:27:11 -0400 (EDT) Message-Id: <200308271427.KAA01660@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-01.txt Date: Wed, 27 Aug 2003 10:27:11 -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-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-- 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 WAA16913 for ; Tue, 26 Aug 2003 22:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmzD-000613-5o; 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 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 OAA00945 for ; Tue, 26 Aug 2003 14:57: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 19rj0U-0004Gl-5A; Tue, 26 Aug 2003 14:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rNZY-0007yF-8x for idr@optimus.ietf.org; Mon, 25 Aug 2003 16:04: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 QAA13551 for ; Mon, 25 Aug 2003 16:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rNZW-0006nq-00 for idr@ietf.org; Mon, 25 Aug 2003 16:04:14 -0400 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 19rNZV-0006nY-00 for idr@ietf.org; Mon, 25 Aug 2003 16:04:14 -0400 Received: from tom3 (1Cust187.tnt6.lnd4.gbr.da.uu.net [62.188.135.187]) by colossus.systems.pipex.net (Postfix) with SMTP id F0D971600004D for ; Mon, 25 Aug 2003 21:03:41 +0100 (BST) Message-ID: <003801c36b43$b2be4260$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "idr" Subject: Re: [Idr] FSM Text for section 8.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 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, 25 Aug 2003 21:00:29 +0100 I am happy content with the action as described. Linked with this, I have assumed, and looking again at the FSM perhaps this is my invention, that if an optional aspect is not implemented, then the associated values are always set to FALSE so I see them as always set, TRUE or FALSE, as opposed to having a not set state. For me this is simpler than eihter considering three states (TRUE, FALSE, not set) or an ambiguity as to whether not set means FALSE (as opposed to a third state). Tom Petch -----Original Message----- From: Susan Hares To: idr@ietf.org Cc: yakov@juniper.net ; zinin@psg.org Date: 24 August 2003 23:48 Subject: [Idr] FSM Text for section 8.1.2 Implementors and BGP FSM geeks: What should happen if the optional attributes are not set as they should for Events 1-8. In the current text, I have the local system only issuing a warning. Should a stronger tact be taken? Sue ======== 8.1.2 Administrative Events An administrative event is an event in which the operator interface and BGP Policy engine signal the BGP finite state machine to start or stop the BGP state machine. The basic start and stop indication are augmented by optional connection attributes to signal a certain type of start or stop mechanism to the BGP FSM. An example of this combination is event 5: AutomaticStart_with_PassiveTcpEstablishment. With this event, the BGP implementatin signals to the BGP FSM that the implementation is using an Automatic Start with option to use a Passive TCP Establishment. The Passive TCP establishment signals that this BGP FSM will wait for the remote side to start the TCP establishment. || Please note that only Event 1 (ManualStart) and Event 2 (ManualStop) are mandatory administrative events. All other administrative events are optional (Events 3-8). Each event below has a name, definition, status (mandatory or optional), and what optional session attributes SHOULD be set at each stage. When generating Event1 through Event8 for the BGP FSM, conditions specified in the Optional Attribute Status section are verified. If || any of them is not satisfied, then the local system should log a FSM || error. _______________________________________________ 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 trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA20934 for ; Tue, 26 Aug 2003 10:06:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28DB291267; Tue, 26 Aug 2003 10:05:44 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA9E091268; Tue, 26 Aug 2003 10:05:43 -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 A7CB791267 for ; Tue, 26 Aug 2003 10:05:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 91DD65DD94; Tue, 26 Aug 2003 10:05:42 -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 F13415DD8E for ; Tue, 26 Aug 2003 10:05:41 -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 KAA04798; Tue, 26 Aug 2003 10:05:37 -0400 (EDT) Message-Id: <200308261405.KAA04798@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-aspath-orf-05.txt Date: Tue, 26 Aug 2003 10:05:36 -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 : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-05.txt Pages : 0 Date : 2003-8-26 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-26102416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-26102416.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 JAA18959 for ; Tue, 26 Aug 2003 09:09:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E7E891234; Tue, 26 Aug 2003 09:09:11 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2234591251; Tue, 26 Aug 2003 09:09:11 -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 F1BA491234 for ; Tue, 26 Aug 2003 09:09:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6E015DD91; Tue, 26 Aug 2003 09:09:09 -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 5A68F5DD8C for ; Tue, 26 Aug 2003 09:09:09 -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 h7QD94Y72171; Tue, 26 Aug 2003 06:09:04 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308261309.h7QD94Y72171@merlot.juniper.net> To: idr@merit.edu Cc: Sandy Murphy , skh@nexthop.com Subject: draft-ietf-idr-bgp-vuln-00.txt to Informational MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64422.1061903344.1@juniper.net> Date: Tue, 26 Aug 2003 06:09:04 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-bgp-vuln-00.txt to an Informational RFC. The Last Call ends Sep 11, 2003. Yakov. 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 NAA08554 for ; Mon, 25 Aug 2003 13:17:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 937809124C; Mon, 25 Aug 2003 13:15:03 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04CB0912A0; Mon, 25 Aug 2003 13:15: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 B799B9124C for ; Mon, 25 Aug 2003 13:14:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A41375DE1E; Mon, 25 Aug 2003 13:14:56 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by segue.merit.edu (Postfix) with ESMTP id 8AEA85DDF7 for ; Mon, 25 Aug 2003 13:14:56 -0400 (EDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 62944206612 for ; Mon, 25 Aug 2003 13:13:13 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19rKGY-00054m-Vt for ietf-announce-list@asgard.ietf.org; Mon, 25 Aug 2003 12:32:26 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19rKFI-00050N-Vq for all-ietf@asgard.ietf.org; Mon, 25 Aug 2003 12:31:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27008; Mon, 25 Aug 2003 12:31:01 -0400 (EDT) Message-Id: <200308251631.MAA27008@ietf.org> 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-as4bytes-07.txt Date: Mon, 25 Aug 2003 12:31:00 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+262543_1626997315243_04064103429" Sender: owner-idr@merit.edu Precedence: bulk --MIMEStream=_0+262543_1626997315243_04064103429 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 support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-07.txt Pages : 7 Date : 2003-8-25 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+262543_1626997315243_04064103429 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+222605_9095457151103_89977243142" --MIMEStream=_1+222605_9095457151103_89977243142 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-07.txt --MIMEStream=_1+222605_9095457151103_89977243142 Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124233.I-D@ietf.org> --MIMEStream=_1+222605_9095457151103_89977243142-- --MIMEStream=_0+262543_1626997315243_04064103429-- 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 MAA07159 for ; Mon, 25 Aug 2003 12:35:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 320819122D; Mon, 25 Aug 2003 12:34:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B62B0912F6; Mon, 25 Aug 2003 12:32:16 -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 0212391212 for ; Mon, 25 Aug 2003 12:31:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5C9C5DD9C; Mon, 25 Aug 2003 12:31:08 -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 ED0D35DD9B for ; Mon, 25 Aug 2003 12:31:07 -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 MAA27008; Mon, 25 Aug 2003 12:31:01 -0400 (EDT) Message-Id: <200308251631.MAA27008@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-as4bytes-07.txt Date: Mon, 25 Aug 2003 12:31:00 -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 : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-07.txt Pages : 7 Date : 2003-8-25 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124233.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA07149 for ; Mon, 25 Aug 2003 12:35:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79E93912FB; Mon, 25 Aug 2003 12:34:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F155912F4; Mon, 25 Aug 2003 12:32: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 60EF39122D for ; Mon, 25 Aug 2003 12:31:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47A005DD9F; Mon, 25 Aug 2003 12:31:14 -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 9A1405DD9B for ; Mon, 25 Aug 2003 12:31:13 -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 MAA27040; Mon, 25 Aug 2003 12:31:07 -0400 (EDT) Message-Id: <200308251631.MAA27040@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-route-filter-09.txt Date: Mon, 25 Aug 2003 12:31:06 -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 : Cooperative Route Filtering Capability for BGP-4 Author(s) : Y. Rekhter Filename : draft-ietf-idr-route-filter-09.txt Pages : 11 Date : 2003-8-25 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.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-route-filter-09.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-route-filter-09.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-25124243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124243.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 MAA07132 for ; Mon, 25 Aug 2003 12:34:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B2A4491213; Mon, 25 Aug 2003 12:33:52 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B86F9122D; Mon, 25 Aug 2003 12:32:34 -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 B010091210 for ; Mon, 25 Aug 2003 12:31:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E0D05DD9E; Mon, 25 Aug 2003 12:31:18 -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 CC5F15DD9B for ; Mon, 25 Aug 2003 12:31:17 -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 MAA27060; Mon, 25 Aug 2003 12:31:11 -0400 (EDT) Message-Id: <200308251631.MAA27060@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-restart-07.txt Date: Mon, 25 Aug 2003 12:31:11 -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 : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, Y. Rekhter Filename : draft-ietf-idr-restart-07.txt Pages : 10 Date : 2003-8-25 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-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124257.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 MAA07045 for ; Mon, 25 Aug 2003 12:32:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 428EE91227; Mon, 25 Aug 2003 12:31:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E6B291212; Mon, 25 Aug 2003 12:31:06 -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 0BCFD91213 for ; Mon, 25 Aug 2003 12:31:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD0CB5DD9B; Mon, 25 Aug 2003 12:31:03 -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 11D735DD8C for ; Mon, 25 Aug 2003 12:31:03 -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 MAA26979; Mon, 25 Aug 2003 12:30:56 -0400 (EDT) Message-Id: <200308251630.MAA26979@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-bgp-ext-communities-06.txt Date: Mon, 25 Aug 2003 12:30:56 -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 : BGP Extended Communities Attribute Author(s) : S. Sangli, D. Tappan, Y. Rekhter Filename : draft-ietf-idr-bgp-ext-communities-06.txt Pages : 11 Date : 2003-8-25 This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-ext-communities-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-ext-communities-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124222.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 SAA01227 for ; Sun, 24 Aug 2003 18:48: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 19r3eT-0001rK-PQ; Sun, 24 Aug 2003 18:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r3dc-0001qz-7G for idr@optimus.ietf.org; Sun, 24 Aug 2003 18:47: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 SAA29774 for ; Sun, 24 Aug 2003 18:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r3dZ-00055X-00 for idr@ietf.org; Sun, 24 Aug 2003 18:47:05 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19r3dY-00055G-00 for idr@ietf.org; Sun, 24 Aug 2003 18:47:04 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7OMkY73022016 for idr@ietf.org; Sun, 24 Aug 2003 18:46:34 -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 h7OMkMAg021992 for ; Sun, 24 Aug 2003 18:46:22 -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 Message-ID: Thread-Topic: FSM Text for section 8.1.2 Thread-Index: AcNqkYqqU3VSlgUsQBG+n0V9PoNoyw== From: "Susan Hares" To: Cc: , X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] FSM Text for section 8.1.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: Sun, 24 Aug 2003 18:46:22 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id SAA01227 Implementors and BGP FSM geeks: What should happen if the optional attributes are not set as they should for Events 1-8. In the current text, I have the local system only issuing a warning. Should a stronger tact be taken? Sue ======== 8.1.2 Administrative Events An administrative event is an event in which the operator interface and BGP Policy engine signal the BGP finite state machine to start or stop the BGP state machine. The basic start and stop indication are augmented by optional connection attributes to signal a certain type of start or stop mechanism to the BGP FSM. An example of this combination is event 5: AutomaticStart_with_PassiveTcpEstablishment. With this event, the BGP implementatin signals to the BGP FSM that the implementation is using an Automatic Start with option to use a Passive TCP Establishment. The Passive TCP establishment signals that this BGP FSM will wait for the remote side to start the TCP establishment. || Please note that only Event 1 (ManualStart) and Event 2 (ManualStop) are mandatory administrative events. All other administrative events are optional (Events 3-8). Each event below has a name, definition, status (mandatory or optional), and what optional session attributes SHOULD be set at each stage. When generating Event1 through Event8 for the BGP FSM, conditions specified in the Optional Attribute Status section are verified. If || any of them is not satisfied, then the local system should log a FSM || error. _______________________________________________ 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 RAA28281 for ; Sun, 24 Aug 2003 17:20: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 19r2HL-0007dp-Uz; Sun, 24 Aug 2003 17:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19r2Gq-0007cr-GO for idr@optimus.ietf.org; Sun, 24 Aug 2003 17:19: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 RAA25189 for ; Sun, 24 Aug 2003 17:19:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r2Go-0003uM-00 for idr@ietf.org; Sun, 24 Aug 2003 17:19:30 -0400 Received: from sj-inbound-3.cisco.com ([128.107.250.144]) by ietf-mx with esmtp (Exim 4.12) id 19r2Gm-0003tb-00 for idr@ietf.org; Sun, 24 Aug 2003 17:19:28 -0400 Received: from localhost (localhost) by sj-inbound-3.cisco.com (8.12.8p1/8.11.2) id h7OLJ6xN019052; Sun, 24 Aug 2003 14:19:06 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <200308242119.h7OLJ6xN019052@sj-inbound-3.cisco.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com" Auto-Submitted: auto-generated (failure) Subject: [Idr] Returned mail: see transcript for details 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: Sun, 24 Aug 2003 14:19:06 -0700 (PDT) This is a MIME-encapsulated message --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_SOBIG.F in file details.pif The uncleanable file details.pif is moved to /etc/iscan/virus/virPNA96aGKC. --------------------------------------------------------- --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com The original message was received at Sun, 24 Aug 2003 14:17:38 -0700 (PDT) from 226.Red-80-33-226.pooles.rima-tde.net [80.33.226.226] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 ... User unknown) (expanded from: ) ----- Transcript of session follows ----- ... while talking to sj-core-2.cisco.com.: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: message/delivery-status Reporting-MTA: dns; sj-inbound-3.cisco.com Received-From-MTA: DNS; 226.Red-80-33-226.pooles.rima-tde.net Arrival-Date: Sun, 24 Aug 2003 14:17:38 -0700 (PDT) Final-Recipient: RFC822; nmenta@cisco.com X-Actual-Recipient: RFC822; nmenta@sj-core.cisco.com Action: failed Status: 5.1.1 Remote-MTA: DNS; sj-core-2.cisco.com Diagnostic-Code: SMTP; 550 5.1.1 ... User unknown Last-Attempt-Date: Sun, 24 Aug 2003 14:19:06 -0700 (PDT) --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com Content-Type: message/rfc822 Return-Path: Received: from PC1 (226.Red-80-33-226.pooles.rima-tde.net [80.33.226.226]) by sj-inbound-3.cisco.com (8.12.8p1/8.11.2) with ESMTP id h7OLHQxN017984 for ; Sun, 24 Aug 2003 14:17:38 -0700 (PDT) Message-Id: <200308242117.h7OLHQxN017984@sj-inbound-3.cisco.com> From: To: Subject: Re: Thank you! Date: Sun, 24 Aug 2003 23:17:21 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_018C1C2B" This is a multipart message in MIME format --_NextPart_000_018C1C2B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_018C1C2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) details.pif is removed from here because it contains a virus. --------------------------------------------------------- --_NextPart_000_018C1C2B-- --h7OLJ6xN019052.1061759946/sj-inbound-3.cisco.com-- _______________________________________________ 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 OAA07831 for ; Wed, 20 Aug 2003 14:54: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 19pY5o-0005rq-LK; Wed, 20 Aug 2003 14:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pY56-0005qt-1q for idr@optimus.ietf.org; Wed, 20 Aug 2003 14:53: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 OAA29572 for ; Wed, 20 Aug 2003 14:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pY53-0005Rp-00 for idr@ietf.org; Wed, 20 Aug 2003 14:53:13 -0400 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 19pY52-0005RC-00 for idr@ietf.org; Wed, 20 Aug 2003 14:53:12 -0400 Received: from tom3 (1Cust218.tnt13.lnd4.gbr.da.uu.net [62.188.142.218]) by shockwave.systems.pipex.net (Postfix) with SMTP id 909E516000093; Wed, 20 Aug 2003 19:52:39 +0100 (BST) Message-ID: <009c01c3674b$f6077d80$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Jeffrey Haas" Cc: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Subject: [Idr] Re: WG Last Call on BGP MIB - normalised names 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, 20 Aug 2003 19:48:52 +0100 Agreed, we must not change the names of the enumerations or objects; what I was suggesting was that in the description, where it refers to stop and start, that is now ambiguous as we have multiple stops and starts and so the description should include Manual.... as per the normalised event names in the base spec for events 1 and 2. The base has normalised names for the timers and here is where there might be confusion since the names are or may be different and so I think the MIB needs a cross reference. I have pushed for the terms KeepaliveTime, HoldTime, IdleHoldTime, DelayOpenTime ;-) etc to be explicitly the initial value to which the corresponding Timer is set. The MIB refers to some of these but uses a different name - hence the need for a mapping for those present in the current MIB. eg 'bgpPeerKeepAlive corresponds to the KeepaliveTime session attribute as defined in [BGP4]' The mapping of OpenSent to opensent I think obvious enough not to need explanation. Tom Petch ----Original Message----- From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Date: 20 August 2003 17:42 Subject: Re: WG Last Call on BGP MIB - normalised names >On Wed, Aug 20, 2003 at 04:39:34PM +0100, Tom Petch wrote: >> Normalised names - um. Now we have normalised names in the base bgp >> spec - good, great, why didn't I think of that? - they are ideal for >> SNMP ( adding a 'bgp' prefix). >> >> Except we already have some names in the MIB and they are different; >> for me this means we should not be last calling the MIB until we are >> last calling the base spec. >> >> A simple change to the MIB is to specify ManualStart and ManualStop in >> bgpPeerAdminStatus. > >I don't believe we're allowed to change the names of enumerated values. >I will check on this. > >> A change we should not make is to bring the states in line (eg >> opensent as opposed to OpenSent). > >Ditto. > >> But it is the timers that make me think we must wait. We will need a >> reference from MIB to optional attribute names as defined in the FSM >> and I don't think we are yet agreed enough on the latter to make those >> references. > >The v2MIB is intended to reflect all of the details of the updated >BGP specification. This draft is largely intended to fix up the >previously published MIB, note some obvious changes and to fix >a problem with the traps. So, don't expect to see any sweeping changes >reflected here. > >Generally, the idea is to not disrupt operator's lives any more than >is necessary. Unfortunately, the "fix" to the traps/notifications >will do that. > >(More on that in a later email.) > >> Tom Petch, > >-- >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 NAA03180 for ; Wed, 20 Aug 2003 13:32: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 19pWoT-0008J1-7w; Wed, 20 Aug 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWo1-0008IY-3V for idr@optimus.ietf.org; Wed, 20 Aug 2003 13:31: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 NAA21302 for ; Wed, 20 Aug 2003 13:31:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWnz-00044j-00 for idr@ietf.org; Wed, 20 Aug 2003 13:31:31 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pWnx-000447-00 for idr@ietf.org; Wed, 20 Aug 2003 13:31:30 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KHUvsH081984; Wed, 20 Aug 2003 13:30:57 -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 h7KHUrAg081977; Wed, 20 Aug 2003 13:30:53 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KHUmu05627; Wed, 20 Aug 2003 13:30:48 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Subject: Re: [Idr] Re: WG Last Call on BGP MIB - normalised names Message-ID: <20030820133048.G2996@nexthop.com> References: <002401c36731$7ddb7a60$0301a8c0@tom3> <20030820124219.B2996@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030820124219.B2996@nexthop.com>; from jhaas@nexthop.com on Wed, Aug 20, 2003 at 12:42:19PM -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: Wed, 20 Aug 2003 13:30:48 -0400 On Wed, Aug 20, 2003 at 12:42:19PM -0400, Jeffrey Haas wrote: > I don't believe we're allowed to change the names of enumerated values. > I will check on this. Survey says: bzzt! We can't do this. We can do what we like in the v2 MIB for names, but they must be lowercase as the first letter. This means the mapping can't be 1:1 exactly for the FSM states as currently documented. -- 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 NAA01578 for ; Wed, 20 Aug 2003 13:04: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 19pWNM-0007BW-Pz; Wed, 20 Aug 2003 13:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWNH-0007B1-1p for idr@optimus.ietf.org; Wed, 20 Aug 2003 13:03:55 -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 NAA19950 for ; Wed, 20 Aug 2003 13:03:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWNF-0003gr-00 for idr@ietf.org; Wed, 20 Aug 2003 13:03:53 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pWNE-0003gO-00 for idr@ietf.org; Wed, 20 Aug 2003 13:03:52 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KH3Lim081100; Wed, 20 Aug 2003 13:03:21 -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 h7KH3GAg081093; Wed, 20 Aug 2003 13:03:16 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KH3BX05323; Wed, 20 Aug 2003 13:03:11 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Message-ID: <20030820130311.C2996@nexthop.com> References: <002301c36731$7d08e820$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002301c36731$7d08e820$0301a8c0@tom3>; from nwnetworks@dial.pipex.com on Wed, Aug 20, 2003 at 04:30:51PM +0100 X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] Re: WG Last Call on BGP MIB - SMI` 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, 20 Aug 2003 13:03:11 -0400 On Wed, Aug 20, 2003 at 04:30:51PM +0100, Tom Petch wrote: > The compliance looks a little odd ie > > bgp4MIBGroups 6 is defined as bgp4MIBNotificationGroup which obsoletes > bgp4MIBNotificationGroup (sic) and this object does not appear in any > compliance group. As I've been given to understand it, not listing it in a compliance makes it completely optional to implement. I'll verify that. It may be proper to not list it in a group if that is the case. > Nor does bgp4MIBNewNotificationGroup which appears > in the description of bgp4MIBTrapGroup but is not even defined > anywhere. Typo from a previous rev, fixed. > bgpBackwardTransition has a status of current but the description says > it is deprecated. Fixed. Thanks! -- 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 MAA00422 for ; Wed, 20 Aug 2003 12:44: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 19pW42-0006PF-06; Wed, 20 Aug 2003 12:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW39-0006N5-MO for idr@optimus.ietf.org; Wed, 20 Aug 2003 12:43: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 MAA18757 for ; Wed, 20 Aug 2003 12:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pW36-0003O2-00 for idr@ietf.org; Wed, 20 Aug 2003 12:43:04 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19pW36-0003Nl-00 for idr@ietf.org; Wed, 20 Aug 2003 12:43:04 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7KGgTP7080429; Wed, 20 Aug 2003 12:42:29 -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 h7KGgPAg080422; Wed, 20 Aug 2003 12:42:25 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7KGgJf04933; Wed, 20 Aug 2003 12:42:19 -0400 (EDT) From: Jeffrey Haas To: Tom Petch Cc: idr@ietf.org Message-ID: <20030820124219.B2996@nexthop.com> References: <002401c36731$7ddb7a60$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002401c36731$7ddb7a60$0301a8c0@tom3>; from nwnetworks@dial.pipex.com on Wed, Aug 20, 2003 at 04:39:34PM +0100 X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] Re: WG Last Call on BGP MIB - normalised names 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, 20 Aug 2003 12:42:19 -0400 On Wed, Aug 20, 2003 at 04:39:34PM +0100, Tom Petch wrote: > Normalised names - um. Now we have normalised names in the base bgp > spec - good, great, why didn't I think of that? - they are ideal for > SNMP ( adding a 'bgp' prefix). > > Except we already have some names in the MIB and they are different; > for me this means we should not be last calling the MIB until we are > last calling the base spec. > > A simple change to the MIB is to specify ManualStart and ManualStop in > bgpPeerAdminStatus. I don't believe we're allowed to change the names of enumerated values. I will check on this. > A change we should not make is to bring the states in line (eg > opensent as opposed to OpenSent). Ditto. > But it is the timers that make me think we must wait. We will need a > reference from MIB to optional attribute names as defined in the FSM > and I don't think we are yet agreed enough on the latter to make those > references. The v2MIB is intended to reflect all of the details of the updated BGP specification. This draft is largely intended to fix up the previously published MIB, note some obvious changes and to fix a problem with the traps. So, don't expect to see any sweeping changes reflected here. Generally, the idea is to not disrupt operator's lives any more than is necessary. Unfortunately, the "fix" to the traps/notifications will do that. (More on that in a later email.) > Tom Petch, -- Jeff Haas NextHop Technologies _______________________________________________ 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 LAA27318 for ; Wed, 20 Aug 2003 11:48:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F22CA9121E; Wed, 20 Aug 2003 11:44:08 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90AA79121F; Wed, 20 Aug 2003 11:44:07 -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 F0A729121E for ; Wed, 20 Aug 2003 11:43:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D5D335DD9F; Wed, 20 Aug 2003 11:43:12 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 513A65DD98 for ; Wed, 20 Aug 2003 11:43:12 -0400 (EDT) Received: from tom3 (1Cust28.tnt30.lnd3.gbr.da.uu.net [62.188.122.28]) by shockwave.systems.pipex.net (Postfix) with SMTP id B3C6716000349; Wed, 20 Aug 2003 16:43:09 +0100 (BST) Message-ID: <002301c36731$7d08e820$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: , "Yakov Rekhter" Subject: Re: WG Last Call on BGP MIB - SMI` Date: Wed, 20 Aug 2003 16:30:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-idr@merit.edu Precedence: bulk The compliance looks a little odd ie bgp4MIBGroups 6 is defined as bgp4MIBNotificationGroup which obsoletes bgp4MIBNotificationGroup (sic) and this object does not appear in any compliance group. Nor does bgp4MIBNewNotificationGroup which appears in the description of bgp4MIBTrapGroup but is not even defined anywhere. bgpBackwardTransition has a status of current but the description says it is deprecated. Tom Petch -----Original Message----- From: Yakov Rekhter To: idr@merit.edu Date: 19 August 2003 21:02 Subject: WG Last Call on BGP MIB >Folks, > >This is to start the WG Last Call on advancing draft-ietf-idr-bgp4-mib-11.txt >to a Proposed Standard. The Last Call ends Sep 2, 2003. > >Yakov. 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 LAA27267 for ; Wed, 20 Aug 2003 11:47:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFAA89121D; Wed, 20 Aug 2003 11:44:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A292691218; Wed, 20 Aug 2003 11:44:05 -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 90B5D9121F for ; Wed, 20 Aug 2003 11:43:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7AE4B5DD9F; Wed, 20 Aug 2003 11:43:13 -0400 (EDT) Delivered-To: idr@merit.edu Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 403B85DD98 for ; Wed, 20 Aug 2003 11:43:13 -0400 (EDT) Received: from tom3 (1Cust28.tnt30.lnd3.gbr.da.uu.net [62.188.122.28]) by shockwave.systems.pipex.net (Postfix) with SMTP id BDE2D1600035C; Wed, 20 Aug 2003 16:43:11 +0100 (BST) Message-ID: <002401c36731$7ddb7a60$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: , "Yakov Rekhter" Subject: Re: WG Last Call on BGP MIB - normalised names Date: Wed, 20 Aug 2003 16:39:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-idr@merit.edu Precedence: bulk Normalised names - um. Now we have normalised names in the base bgp spec - good, great, why didn't I think of that? - they are ideal for SNMP ( adding a 'bgp' prefix). Except we already have some names in the MIB and they are different; for me this means we should not be last calling the MIB until we are last calling the base spec. A simple change to the MIB is to specify ManualStart and ManualStop in bgpPeerAdminStatus. A change we should not make is to bring the states in line (eg opensent as opposed to OpenSent). But it is the timers that make me think we must wait. We will need a reference from MIB to optional attribute names as defined in the FSM and I don't think we are yet agreed enough on the latter to make those references. Tom Petch, -----Original Message----- From: Yakov Rekhter To: idr@merit.edu Date: 19 August 2003 21:02 Subject: WG Last Call on BGP MIB >Folks, > >This is to start the WG Last Call on advancing draft-ietf-idr-bgp4-mib-11.txt >to a Proposed Standard. The Last Call ends Sep 2, 2003. > >Yakov. 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 QAA23319 for ; Tue, 19 Aug 2003 16:03:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BCD691258; Tue, 19 Aug 2003 16:00:55 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBD5E9125A; Tue, 19 Aug 2003 16:00:53 -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 CE43B91252 for ; Tue, 19 Aug 2003 16:00:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B69FA5DD99; Tue, 19 Aug 2003 16:00:47 -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 35DF65DD94 for ; Tue, 19 Aug 2003 16:00:47 -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 h7JK0kZ61522 for ; Tue, 19 Aug 2003 13:00:46 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308192000.h7JK0kZ61522@merlot.juniper.net> To: idr@merit.edu Subject: WG Last Call on BGP MIB MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31568.1061323246.1@juniper.net> Date: Tue, 19 Aug 2003 13:00:46 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start the WG Last Call on advancing draft-ietf-idr-bgp4-mib-11.txt to a Proposed Standard. The Last Call ends Sep 2, 2003. Yakov. 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 PAA21819 for ; Tue, 19 Aug 2003 15:36:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 978AB9123E; Tue, 19 Aug 2003 15:35:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D76DB9123A; Tue, 19 Aug 2003 15:34:57 -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 1D73C91247 for ; Tue, 19 Aug 2003 15:34:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E90365DDA1; Tue, 19 Aug 2003 15:34:25 -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 3865B5DD99 for ; Tue, 19 Aug 2003 15:34:25 -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 PAA03611; Tue, 19 Aug 2003 15:34:20 -0400 (EDT) Message-Id: <200308191934.PAA03611@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-11.txt Date: Tue, 19 Aug 2003 15:34:20 -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-11.txt Pages : 35 Date : 2003-8-19 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-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19104753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19104753.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 NAA14593 for ; Tue, 19 Aug 2003 13:28: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 19pAH3-00089n-LL; Tue, 19 Aug 2003 13: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 19pAGC-00088z-DP for idr@optimus.ietf.org; Tue, 19 Aug 2003 13:27: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 NAA24826 for ; Tue, 19 Aug 2003 13:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAGA-00046z-00 for idr@ietf.org; Tue, 19 Aug 2003 13:27:06 -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 19pAG9-00046A-00 for idr@ietf.org; Tue, 19 Aug 2003 13:27:05 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2003 10:34:20 -0700 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7JHQXAi012341; Tue, 19 Aug 2003 10:26:33 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-72.cisco.com [128.107.163.72]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJR06776; Tue, 19 Aug 2003 10:32:25 -0700 (PDT) Message-ID: <3F425DC9.4080904@cisco.com> From: Keyur Patel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Zhang CC: Danny McPherson , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt References: <5.0.2.1.2.20030819103943.03f6b1e8@cactus.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 19 Aug 2003 10:26:33 -0700 Randy: Thanks for the feedback. We will incorporate them. -Keyur Randy Zhang wrote: > Danny, > > A few comments for your consideration: > > Section 6.1: > >>>A paramount goal of the design of the MED was ensure that > peers could not "shed" or "absorb" traffic for networks that they > advertise.<<< > missing "to" before "ensure" > > Section 6.1.1: > Understand this is not IOS specific but note IOS allows "set metric- > internal", perhaps expand the discussion? > > Section 6.1.2 > Understand this is not IOS specific but note IOS allows > "missing-as-worst", perhaps expand the discussion? > > Section 8: > >>>Also, there is effort underway to develop internal BGP "route > reflectors" <<< > RRs are already defined in RFC 1966 and updated in RFC 2796, as you > indicated in section 5. So the wording of "underway" is misleading. > Additionally the use of quotes for route reflectors implies the term > is not popular. > Also should it be "an effort" instead of "effort"? :-) > > >>>BGP "Route Reflector" extensions has been defined in RFC 1966<<<< > You use the quotes again here, but you also have RRs with initials > capitalized. They should be consistently lower cased. > Also the RFC 2796 is not mentioned here. > > Good work! > > Regards, > Randy > > At 07:49 PM 8/18/2003 -0600, Danny McPherson wrote: > >> Folks, >> Inline is an updated version of the BGP "experience" >> draft. I posted it to internet-drafts@ietf.org a little >> while ago so it should be showing up on the ftp server >> sometime this week. >> >> We've received comments from several of you and have >> incorporated most. If you've got additional comments >> please send them to us ASAP as we'd like to update >> appropriately and WG LC within a couple of weeks. >> >> Note that we do realize a few sections still need >> some work and will get it in the next revision. Comments, >> text and corrections are welcome. Thanks! >> >> -danny > > > > _______________________________________________ > 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 MAA10482 for ; Tue, 19 Aug 2003 12:16: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 19p99N-0004cH-6T; Tue, 19 Aug 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p98h-0004ae-BB for idr@optimus.ietf.org; Tue, 19 Aug 2003 12:15:19 -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 MAA20843 for ; Tue, 19 Aug 2003 12:15:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p98f-0002tt-00 for idr@ietf.org; Tue, 19 Aug 2003 12:15:17 -0400 Received: from cactus.cisco.com ([64.101.140.220]) by ietf-mx with esmtp (Exim 4.12) id 19p98e-0002t9-00 for idr@ietf.org; Tue, 19 Aug 2003 12:15:16 -0400 Received: from ranzhang-w2k01.cisco.com (ranzhang-w2k01.cisco.com [64.101.135.139]) by cactus.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h7JGEi825220; Tue, 19 Aug 2003 11:14:44 -0500 (CDT) Message-Id: <5.0.2.1.2.20030819103943.03f6b1e8@cactus.cisco.com> X-Sender: ranzhang@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 To: Danny McPherson From: Randy Zhang Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt Cc: idr@ietf.org In-Reply-To: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> Mime-Version: 1.0 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, 19 Aug 2003 11:14:59 -0500 Danny, A few comments for your consideration: Section 6.1: >>>A paramount goal of the design of the MED was ensure that peers could not "shed" or "absorb" traffic for networks that they advertise.<<< missing "to" before "ensure" Section 6.1.1: Understand this is not IOS specific but note IOS allows "set metric- internal", perhaps expand the discussion? Section 6.1.2 Understand this is not IOS specific but note IOS allows "missing-as-worst", perhaps expand the discussion? Section 8: >>>Also, there is effort underway to develop internal BGP "route reflectors" <<< RRs are already defined in RFC 1966 and updated in RFC 2796, as you indicated in section 5. So the wording of "underway" is misleading. Additionally the use of quotes for route reflectors implies the term is not popular. Also should it be "an effort" instead of "effort"? :-) >>>BGP "Route Reflector" extensions has been defined in RFC 1966<<<< You use the quotes again here, but you also have RRs with initials capitalized. They should be consistently lower cased. Also the RFC 2796 is not mentioned here. Good work! Regards, Randy At 07:49 PM 8/18/2003 -0600, Danny McPherson wrote: >Folks, >Inline is an updated version of the BGP "experience" >draft. I posted it to internet-drafts@ietf.org a little >while ago so it should be showing up on the ftp server >sometime this week. > >We've received comments from several of you and have >incorporated most. If you've got additional comments >please send them to us ASAP as we'd like to update >appropriately and WG LC within a couple of weeks. > >Note that we do realize a few sections still need >some work and will get it in the next revision. Comments, >text and corrections are welcome. Thanks! > >-danny _______________________________________________ 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 KAA05028 for ; Tue, 19 Aug 2003 10:36:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 214B19122B; Tue, 19 Aug 2003 10:34:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6ADFB91235; Tue, 19 Aug 2003 10:34:50 -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 CFAC49122F for ; Tue, 19 Aug 2003 10:33:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B924C5DDB1; Tue, 19 Aug 2003 10:33:10 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by segue.merit.edu (Postfix) with ESMTP id 6A4275DDA3 for ; Tue, 19 Aug 2003 10:33:10 -0400 (EDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 0F86C206607 for ; Tue, 19 Aug 2003 10:31:29 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19p7AX-0008Q8-7W for ietf-announce-list@asgard.ietf.org; Tue, 19 Aug 2003 10:09:05 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19p79Y-00088Z-DS for all-ietf@asgard.ietf.org; Tue, 19 Aug 2003 10:08:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11771; Tue, 19 Aug 2003 10:07:50 -0400 (EDT) Message-Id: <200308191407.KAA11771@ietf.org> 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-00.txt Date: Tue, 19 Aug 2003 10:07:49 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+36067_31070151965611_77445525115" Sender: owner-idr@merit.edu Precedence: bulk --MIMEStream=_0+36067_31070151965611_77445525115 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-00.txt Pages : 19 Date : 2003-8-19 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+36067_31070151965611_77445525115 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+184825_6986936563488_42310645858" --MIMEStream=_1+184825_6986936563488_42310645858 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19101446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-00.txt --MIMEStream=_1+184825_6986936563488_42310645858 Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19101446.I-D@ietf.org> --MIMEStream=_1+184825_6986936563488_42310645858-- --MIMEStream=_0+36067_31070151965611_77445525115-- 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 KAA03922 for ; Tue, 19 Aug 2003 10:17: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 19p7IC-0006zs-VZ; Tue, 19 Aug 2003 10:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p7I2-0006zP-5U for idr@optimus.ietf.org; Tue, 19 Aug 2003 10:16:50 -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 KAA12885 for ; Tue, 19 Aug 2003 10:16:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p7Hx-0000ez-00 for idr@ietf.org; Tue, 19 Aug 2003 10:16:45 -0400 Received: from mailhost.jlc.net ([199.201.159.9] helo=verdi.jlc.net) by ietf-mx with esmtp (Exim 4.12) id 19p7Hw-0000eu-00 for idr@ietf.org; Tue, 19 Aug 2003 10:16:44 -0400 Received: by verdi.jlc.net (Postfix, from userid 104) id 1116E33C7A; Tue, 19 Aug 2003 10:06:27 -0400 (EDT) From: John Leslie To: Danny McPherson Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp4-experience-00.txt Message-ID: <20030819100626.I14782@verdi> References: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net>; from danny@tcb.net on Mon, Aug 18, 2003 at 07:49:17PM -0600 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, 19 Aug 2003 10:06:26 -0400 Danny McPherson wrote: > > Inline is an updated version of the BGP "experience" > draft. I posted it to internet-drafts@ietf.org a little > while ago so it should be showing up on the ftp server > sometime this week. > > We've received comments from several of you and have > incorporated most. If you've got additional comments > please send them to us ASAP as we'd like to update > appropriately and WG LC within a couple of weeks. Well done! Two notes: 1) in section 2.4, I think it would be good to note that the mailing-list was recently changed to . 2) in section 11: > > The BGP protocol suggests that withdrawal information should be > packed in the begining of Update message along with information about > more or less specific reachable routes in a single UPDATE message. > This would help alleviate excessive route flapping in BGP. I believe withdrawn routes MUST be listed first in any individual UPDATE message. This language casts doubt on that. I suspect your intent is to state that the alternate route(s) used MAY be packed into the same UPDATE message (in hopes of minimizing packet loss during the transition). Alas, your intent is not all that clear... -- John Leslie _______________________________________________ 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 KAA03306 for ; Tue, 19 Aug 2003 10:08:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D1D409122A; Tue, 19 Aug 2003 10:08:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AEFE9122B; Tue, 19 Aug 2003 10:08:05 -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 620179122A for ; Tue, 19 Aug 2003 10:08:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FAEB5DDA3; Tue, 19 Aug 2003 10:08:04 -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 640E05DDC1 for ; Tue, 19 Aug 2003 10:07:58 -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 KAA11771; Tue, 19 Aug 2003 10:07:50 -0400 (EDT) Message-Id: <200308191407.KAA11771@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-00.txt Date: Tue, 19 Aug 2003 10:07:49 -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-00.txt Pages : 19 Date : 2003-8-19 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-experience-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19101446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-experience-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19101446.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 VAA23531 for ; Mon, 18 Aug 2003 21:50: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 19ovdJ-0006St-OD; Mon, 18 Aug 2003 21:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ovcg-0006PT-86 for idr@optimus.ietf.org; Mon, 18 Aug 2003 21:49: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 VAA11818 for ; Mon, 18 Aug 2003 21:49:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ovcd-00043R-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:19 -0400 Received: from [4.17.150.130] (helo=soln-sro156.solutionip.com) by ietf-mx with esmtp (Exim 4.12) id 19ovcc-00043N-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:18 -0400 Received: from [172.18.240.184] (helo=tcb.net) by soln-sro156.solutionip.com with esmtp (Exim 3.34 #1) id 19ovcd-0007l9-00 for idr@ietf.org; Mon, 18 Aug 2003 21:49:19 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Danny McPherson To: idr@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <581CE0C4-D1E7-11D7-9FC2-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Idr] draft-ietf-idr-bgp4-experience-00.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, 18 Aug 2003 19:49:17 -0600 Folks, Inline is an updated version of the BGP "experience" draft. I posted it to internet-drafts@ietf.org a little while ago so it should be showing up on the ftp server sometime this week. We've received comments from several of you and have incorporated most. If you've got additional comments please send them to us ASAP as we'd like to update appropriately and WG LC within a couple of weeks. Note that we do realize a few sections still need some work and will get it in the next revision. Comments, text and corrections are welcome. Thanks! -danny ------------------ INTERNET-DRAFT Danny McPherson draft-ietf-idr-bgp4-experience-00.txt Arbor Networks Keyur Patel Cisco Systems Category Informational Expires: February 2004 August 2003 Experience with the BGP-4 Protocol Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. This document is a product of an individual. Comments are solicited and should be addressed to the author(s). Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. McPherson, Patel [Page 1] INTERNET-DRAFT Expires: February 2004 August 2003 Abstract 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. McPherson, Patel [Page 2] INTERNET-DRAFT Expires: February 2004 August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4 2.2. BGP version 2 . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. BGP version 3 . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. BGP version 4 . . . . . . . . . . . . . . . . . . . . . . . 6 3. Management Information Base (MIB). . . . . . . . . . . . . . . 7 4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 7 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 8 6. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 9 6.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 10 6.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 10 6.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 10 7. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 11 9. Internet Dynamics. . . . . . . . . . . . . . . . . . . . . . . 12 10. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 12 11. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 13 12. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13 13. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14 14. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 14 15. Control over Version Negotiation. . . . . . . . . . . . . . . 14 16. Reciept of Non-Transitive Attributes from eBGP Peer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 15 17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 15 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 16 17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 16 17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17 17.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17 18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18 19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19 20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19 McPherson, Patel [Page 3] INTERNET-DRAFT Expires: February 2004 August 2003 1. Introduction 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. 2. BGP-4 Overview BGP is an inter-autonomous system routing protocol designed for TCP/IP internets. The primary function of BGP is to exchange network reachability information with other BGP systems. This information is sufficient to construct a graph of loop-free AS connectivity and policy decisions at the AS level may be enforced. The initial version of the BGP protocol was published in RFC 1105. Since then BGP Versions 2, 3, and 4 have been developed and are specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively. Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in Appendix N of [BGP4]. 2.1. A Border Gateway Protocol The Initial Version of BGP [RFC 1105] Appendix D of [BGP4]; Comparison with 1105: o Changes to FSM to accommdate BSD 4.3 TCP UI. o Notion of Up/Down/Horizontal relations have been removed. o Message format changes: - Hold Timer removed from BGP Header and added to OPEN Message - Version field removed from BGP Header and added to OPEN Message - Link Type field removed from OPEN Message - OPEN CONFIRM message deprecated and replaced with implicit confirmation provided by KEEPALIVE message. McPherson, Patel Section 2.1. [Page 4] INTERNET-DRAFT Expires: February 2004 August 2003 - UPDATE Message format changed. New fields were added to support multiple path attributes. - The Marker field was expanded and its role broadened to support authentication 2.2. BGP version 2 The Second Version of BGPv2 [RFC 1163] Appendix C of [BGP4] Comparison with RFC 1163 o BGP Identifier introduced to deal with collision detection. o Removed restriction that border router of NEXT_HOP path attribute had to be part of same AS. o Optimized and simplified exchange of information about reachable routes. BGP version 2 removed from the protocol the concept of "up", "down", and "horizontal" relations between autonomous systems that were present in version 1. BGP version 2 introduced the concept of path attributes. In addition, BGP version 2 clarified parts of the protocol that were "under-specified". 2.3. BGP version 3 BGPv3 [RFC 1267] Appendix B of [BGP4] Comparison with RFC 1267: o Set of destination via single IP prefix. Concept of network classes, or subnetting is foreign to BGP-4. To accommodate these capabilities BGP-4 changes the semantics and encoding associated with the AS_PATH attribute. New text has been added to define semantics associated with IP Prefixes. These abilities allow BGP to support the proposed supernetting scheme [RFC 1518] (BGP4 Draft reference to [9] needs to be fixed). o LOCAL_PREF intrduced to facilitate route selection procedures. o INTER_AS_METRIC renamed to MULTI_EXIT_DISC o ATOMIC_AGGREGATE introduced to ensure that certain aggregates are not deaggregated. o Introduced AGGREGATOR. McPherson, Patel Section 2.3. [Page 5] INTERNET-DRAFT Expires: February 2004 August 2003 o Holdtimer neogtiation per-connection for symmetry. Lower value used. Hold Times of zero now supported. BGP version 3 lifted some of the restrictions on the use of the NEXT_HOP path attribute, and added the BGP Identifier field to the BGP OPEN message. It also clarifies the procedure for distributing BGP routes between the BGP speakers within an autonomous system. 2.4. BGP version 4 BGP v4 [RFC 1771] [BGP4] Appendix A of [BGP4] Comparison with RFC 1771: o Changes to reflect use of the TCP MD5 Signature Option, Route Reflectors, AS Confederations for BGP and BGP Route Refresh. o Clarified use of BGP Identifier in AGGREGATOR Attribute o Procedures for imposing upper bound of prefixes a speaker will accept from a peer. o Ability to include more than one instance of it's own AS in the AS_PATH attribute for the purpose of inter-AS traffic engineering. o Clarified various types of NEXT_HOPS o Claried use of ATOMIC_AGGREGATE attribute o Discussed relationship be BGP NEXT_HOP attribute and immediate next hop. o Clarified tie-breaking procedures o Clarified route advertisement frequency text. o Deprecated Optional Parameter Type 1 (Authentication Information) o UPDATE Message Error subcode 7 (AS Routing Loop) deprecated. o Use of Marker field for authentication has been deprecated. BGP version 4 redefines the (previously defined class-based) network layer reachability portion of the updates to specify prefixes of arbitrary length in order to represent multiple classful networks in a single entry as discussed in [RFC 1519]. BGP version 4 has also modified the AS_PATH attribute so that sets of autonomous systems, as well as individual ASs may be described. BGP version 4 has redescribed the INTER-AS METRIC attribute as the MULTI_EXIT_DISC and added new LOCAL_PREF and AGGREGATOR attributes. BGP version 4 defines procedures for imposing an upper bound on the number of prefixes that a BGP speaker may accept from its peer. BGP version 4 has modifed the AS_PATH attribute to have an ability to McPherson, Patel Section 2.4. [Page 6] INTERNET-DRAFT Expires: February 2004 August 2003 include more than one instance of its own AS for the purpose of inter-AS traffic engineering. BGP version 4 deprecates the use of OPTIONAL PARAMETER Type 1 (Authentication Information). BGP version 4 also deprecates the use of UPDATE MESSAGE Error subcode 7 (AS Routing Loop). BGP version 4 provides clarifications on use of BGP Identifier in the AGGREGATOR attribute and use of the ATOMIC_AGGREGATOR attribute. BGP version 4 also provides clarifications on various types of NEXT_HOPs, BGP tie-breaking procedures and frequency of route announcements in BGP. Possible applications of BGP in the Internet are documented in [RFC 1772]. The BGP protocol was developed by the IDR Working Group of the Internet Engineering Task Force. This Working Group had a mailing list, idr@merit.edu, where discussions of protocol features and operation are held. The IDR Working Group meets regularly during the Internet Engineering Task Force meetings. Reports of these meetings are published in the IETF's Proceedings. 3. Management Information Base (MIB) The BGP-4 Management Information Base (MIB) has been published [BGP- MIB]. The MIB was updated from previous versions documented in [RFC 1657] and [RFC 1269], respectively. Apart from a few system variables, the BGP MIB is broken into two tables: the BGP Peer Table and the BGP Received Path Attribute Table. The Peer Table reflects information about BGP peer connections, such as their state and current activity. The Received Path Attribute Table contains all attributes received from all peers before local routing policy has been applied. The actual attributes used in determining a route are a subset of the received attribute table. 4. Implementations There are numerous independent interoperable implementations of BGP McPherson, Patel Section 4. [Page 7] INTERNET-DRAFT Expires: February 2004 August 2003 currently available. Although the previous version of this report provided an overview of the implementations currently used in the operational Internet, at this time it has been suggested that a separate BGP Implementation Report [BGP-IMPL] be generated. It should be noted that implementation experience with Cisco's BGP-4 implementation was documented as part of [RFC 1656]. For all additional implementation information please reference [BGP- IMPL]. 5. Operational Experience This section discusses operational experience with BGP and BGP-4. BGP has been used in the production environment since 1989, BGP-4 since 1993. Production use of BGP includes utilization of all significant features of the protocol. The present production environment, where BGP is used as the inter-autonomous system routing protocol, is highly heterogeneous. In terms of the link bandwidth it varies from 56 Kbps to 10 Gbps. In terms of the actual routers that run BGP it ranges from a relatively slow performance PC/RT to a very high performance RISC-based CPUs, and includes both the special purpose routers and the general purpose workstations running various UNIX derivatives and other operating systems. In terms of the actual topologies it varies from very sparse to quite dense. The requirement for full-mesh IBGP topologies has been largely remedied by BGP Route Reflection, Autonomous System Confederations for BGP, and perhaps some mix of the two.. BGP Route Reflection was initially defined in [RFC 1966] and subsequently updated in [RFC 2796]. Autonomous System Confederations for BGP were initially defined in [RFC 1965] and subsequently updated in [RFC 3065]. At the time of this writing BGP-4 is used as an inter-autonomous system routing protocol between ALL Internet-attached autonomous systems, with nearly 15k active autonomous systems in the global Internet routing table. BGP is used both for the exchange of routing information between a transit and a stub autonomous system, and for the exchange of routing information between multiple transit autonomous systems. There is no protocol distinction between sites historically considered "backbones" versus "regional" or "edge" networks. McPherson, Patel Section 5. [Page 8] INTERNET-DRAFT Expires: February 2004 August 2003 The full set of exterior routes that is carried by BGP is well over 120,000 aggregate entries, representing several times that number of connected networks. The number of active paths in some service provider core routers exceeds 2.5 million. Native AS_PATH lengths are as long as 10 for some routes, and "padded" path lengths of 25 or more ASs exist. 6. Metrics This section discusses different metrics used within the BGP protocol. BGP has a seperate metric parameter for IBGP and EBGP. This allows policy based metrics to overwrite the distance based metrics; allowing each autonomous systems to define their independent policies in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED) is used as a metric by EBGP peers while BGP Local Preference is used by IBGP peers. 6.1. MULTI_EXIT_DISC (MED) BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_ DISC (MED). This value may be used in the tie-breaking process when selecting a preferred path to a given address space, and provides BGP speakers with the capability to convey to a peer AS the optimal entry point into the local AS. Although the MED was meant to only be used when comparing paths received from different external peers in the same AS, many implementations provide the capability to compare MEDs between different ASs as well. The MED was purposely designed to be a "weak" metric that would only be used late in the best-path decision process. The BGP working group was concerned that any metric specified by a remote operator would only affect routing in a local AS if no other preference was specified. A paramount goal of the design of the MED was ensure that peers could not "shed" or "absorb" traffic for networks that they advertise. McPherson, Patel Section 6.1. [Page 9] INTERNET-DRAFT Expires: February 2004 August 2003 6.1.1. Sending MEDs to BGP Peers [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to be passed to its IBGP peers. Although advertising MEDs to IBGP peers is not a required behavior, it is a common default. MEDs received from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP peers. 6.1.2. MED of Zero Versus No MED An implementation MUST provide a mechanism that allows for MED to be removed. Previously, implementations did not consider a missing MED value to be the same as a MED of zero. No MED value should now be equal to a value of zero. 6.1.3. MEDs and Temporal Route Selection Some implementations have hooks to apply temporal behavior in MED- based best path selection. That is, all other things being equal up to MED consideration, preference would be applied to the "oldest" path, without preferring the lower MED value. The reasoning for this is that "older" paths are presumably more stable, and thus more preferable. However, temporal behavior in route slection results in non-deterministic behavior, and as such, is often undesirable. 7. LOCAL_PREF The LOCAL_PREF attribute was added so a network operator could easily configure a policy that overrode the standard best path determination mechanism without independently configuring local preference policy on each router. One shortcoming in the BGP-4 specification was a suggestion for a default value of LOCAL-PREF to be assumed if none was provided. Defaults of 0 or the maximum value each have range limitations, so a common default would aid in the interoperation of multi-vendor routers in the same AS (since LOCAL_PREF is a local administration knob, there is no interoperability drawback across AS boundaries). McPherson, Patel Section 7. [Page 10] INTERNET-DRAFT Expires: February 2004 August 2003 The LOCAL_PREF MUST be sent to IBGP Peers. The LOCAL_PREF Attribute MUST NOT be sent to EBGP Peers. Although no default value for LOCAL_PREF is defined, the common default value is 100. Another area where more exploration is required is a method whereby an originating AS may influence the best path selection process. For example, a dual-connected site may select one AS as a primary transit service provider and have one as a backup. /---- transit B ----\ end-customer transit A---- /---- transit C ----\ In a topology where the two transit service providers connect to a third provider, the real decision is performed by the third provider and there is no mechanism for indicating a preference should the third provider wish to respect that preference. A general purpose suggestion that has been brought up is the possibility of carrying an optional vector corresponding to the AS- PATH where each transit AS may indicate a preference value for a given route. Cooperating ASs may then chose traffic based upon comparison of "interesting" portions of this vector according to routing policy. While protecting a given ASs routing policy is of paramount concern, avoiding extensive hand configuration of routing policies needs to be examined more carefully in future BGP-like protocols. 8. Internal BGP In Large Autonomous Systems While not strictly a protocol issue, one other concern has been raised by network operators who need to maintain autonomous systems with a large number of peers. Each speaker peering with an external router is responsible for propagating reachability and path information to all other transit and border routers within that AS. This is typically done by establishing internal BGP connections to all transit and border routers in the local AS. In a large AS, this leads to a full mesh of TCP connections (n * (n-1)) and some method of configuring and maintaining those connections. BGP does not specify how this information is to be propagated, so alternatives, such as injecting BGP attribute McPherson, Patel Section 8. [Page 11] INTERNET-DRAFT Expires: February 2004 August 2003 information into the local IGP have been suggested. Also, there is effort underway to develop internal BGP "route reflectors" or a reliable multicast transport of IBGP information which would reduce configuration, memory and CPU requirements of conveying information to all other internal BGP peers. BGP "Route Reflector" extensions has been defined in RFC 1966 to alleviate the the need for "full mesh" IBGP. 9. Internet Dynamics As discussed in [BGP4-ANALYSIS], the driving force in CPU and bandwidth utilization is the dynamic nature of routing in the Internet. As the net has grown, the number of route changes per second has increased. We automatically get some level of damping when more specific NLRI is aggregated into larger blocks, however this isn't sufficient. In Appendix F of [BGP4] are descriptions of damping techniques that should be applied to advertisements. In future specifications of BGP-like protocols, damping methods should be considered for mandatory inclusion in compliant implementations. Route changes are announced using BGP UPDATE messages. The greatest overhead in advertising UPDATE messages happens whenever route changes to be announced are inefficiently packed.Announcing routing changes sharing common attributes in a single BGP UPDATE message [13.1] also helps save considerable bandwidth. Persistent BGP errors may cause BGP peers to flap persistently if peer dampening is not implemented. This would result in significant CPU utilization. Implementors may find it useful to implement peer dampening to avoid such persistent peer flapping [BGP4]. 10. BGP Routing Information Bases (RIBs) [BGP4] states "Any local policy which results in routes being added to an Adj-RIB-Out without also being added to the local BGP speaker's forwarding table, is outside the scope of this document". However, several well-known implementations do not confirm that Loc- RIB entries were used to populate the forwarding table before McPherson, Patel Section 10. [Page 12] INTERNET-DRAFT Expires: February 2004 August 2003 installing them in the Adj-RIB-Out. The most common occurrence of this is when routes for a given prefix are presented by more than one protocol and the preferences for the BGP learned route is lower than that of another protocol. As such, the route learned via the other protocol is used to populate the forwarding table. It may be desirable for an implementation to provide a knob that permits advertisement of "inactive" BGP routes. It may be also desirable for an implementation to provide a knob that allows a BGP speaker to advertise BGP routes that were not selected by descision process. 11. Update Packing The BGP4 protocol permits advertisement of multiple prefixes with a common set of path attributes to be advertised in a single update message, this is commonly referred to as "update packing". When possible, update packing is recommended as it provides a mechanism for more efficient behavior in a number of areas, to include: o Reduction in system overhead due to generation or receipt of fewer Update messages. o Reduction in network overhead as a result of less packets and lower bandwidth consumption. o Allows you to process path attributes and look for matching sets in your AS_PATH database (if you have one) less frequently. Consistent ordering of the path attributes allows for ease of matching in the database as you don't have different representations of the same data. The BGP protocol suggests that withdrawal information should be packed in the begining of Update message along with information about more or less specific reachable routes in a single UPDATE message. This would help alleviate excessive route flapping in BGP. 12. Limit Rate Updates The BGP protocol defines different mechanisms to rate limit the Updates. The BGP protocol defines MinRouteAdvertisementInterval McPherson, Patel Section 12. [Page 13] INTERNET-DRAFT Expires: February 2004 August 2003 parameter that determines the minimum time that must be elsape between the advertisement of routes to a particular destination from a single BGP speaker. This value is set on a per BGP peer basis. 13. Ordering of Path Attributes The BGP protocol suggests that BGP speakers sending multiple prefixes per an UPDATE message should sort and order path attributes according to Type Codes. This would help their peers to quickly identify sets of attributes from different update messages which are semantically different. Implementers may find it useful to order path attributes according to Type Code so that sets of attributes with identical semantics can be more quickly identified. 14. AS_SET Sorting AS_SETs are commonly used in BGP route aggregation. They reduce the size of AS_PATH information by listing AS numbers only once regardless of any number of times it might appear in process of aggregation. AS_SETs are usually sorted in increasing order to facilitate efficient lookups of AS numbers within them. This optimization is entirely optional. 15. Control over Version Negotiation Because pre-BGP-4 route aggregation can't be supported by earlier version of BGP, an implementation that supports versions in addition to BGP-4 should provide the version support on a per-peer basis. 16. Reciept of Non-Transitive Attributes from eBGP Peer E.g., LOCAL_PREF, RR or confed, etc.. McPherson, Patel Section 16. [Page 14] INTERNET-DRAFT Expires: February 2004 August 2003 NEEDS MORE WORK 17. Security Considerations BGP provides flexible and extendable mechanism for authentication and security. The mechanism allows to support schemes with various degree of complexity. BGP sessions are authenticated based on the IP address of a peer. In addition, all BGP sessions are authenticated based on the autonomous system number advertised by a peer. Since BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP. 17.1. TCP MD5 Signature Option RFC 2385 defines a way in which the TCP MD5 signature option can be used to valid information transmitted between two peers. This method prevents any third party from injecting information (e.g., a TCP RST) into the datastream, or modifying the routing information carried between two BGP peers. RFC ???? provides suggestions for choosing passwords to be used with MD5. TCP MD5 is not ubiquitously deployed at the moment, especially in inter- domain scenarios, largely because of key distribution issues. Most key distribution mechanisms are considered to be too "heavy" at this point. 17.2. BGP Over IPSEC BGP can run over IPSEC, either in a tunnel, or in transport mode, where the TCP portion of the IP packet is encrypted. This not only prevents random insertion of information into the data stream between two BGP peers, it also prevents an attacker from learning the data which is being exchanged between the peers. IPSEC does, however, offer several options for exchanging session McPherson, Patel Section 17.2. [Page 15] INTERNET-DRAFT Expires: February 2004 August 2003 keys, which may be useful on inter-domain configurations. These options are being explored in many deployments, although no definitive solution has been reach on the issue of key exchange for BGP in IPSEC. It should be noted that since BGP runs over TCP and IP, BGP is vulnerable to the same denial of service or authentication attacks that are present in any other TCP based protocol. 17.3. Miscellaneous Another issue any routing protocol faces is providing evidence of the validity and authority of the routing information carried within the routing system. This is currently the focus of several efforts at the moment, including efforts to define the threats which can be used against this routing information in BGP [draft-murphy, attack tree], and efforts at developing a means to provide validation and authority for routing information carried within BGP [SBGP] [soBGP]. In addition, the Routing Protocol Security Requirements (RPSEC) working group has been chartered within the Routing Area of the IETF in order to discuss and assist in addressing issues surrounding routing protocol security. It is the intent that this work within RPSEC will result in feedback to BGPv4 and future enhancements to the protocol where appropriate. 17.4. PTOMAINE and GROW The Prefix Taxonomy (PTOMAINE) working group, recently replaced by the Global Routing Operations (GROW) working group, is chartered to consider and measure the problem of routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, GROW will also document the operational aspects of measurement, policy, security and VPN infrastructures. It is the intent that this work within GROW will result in feedback to BGPv4 and future enhancements to the protocol as necessary. One thing that I think you might want to add is something about aggregation and the inability to aggregate over multiple provider McPherson, Patel Section 17.4. [Page 16] INTERNET-DRAFT Expires: February 2004 August 2003 boundaries due to inadequate provider coordination. If you want you can cite the ptomaine work if anything came of it or just mention that the WG was created to address problems in this area. If you want something on the PRD to IRR and RPSL I can put together a few paragraphs. 17.5. Internet Routing Registries (IRRs) Many organizations register their routing policy and prefix origination in the various distributed databases of the Internet Routing Registry. These databases provide access to the information using the RPSL language as defined in [RFC 2622]. While registered information may be maintained and correct for certain providers, the lack of timely or correct data in the various IRR databases has prevented wide-spread use of this resource. 17.6. Acknowledgements We would like to thank Paul Traina and Yakov Rekhter for authoring previous versions of this document. We would also like to acknowledge Russ White, Jeffrey Haas and Curtis Villamizar for valuable feedback on this document. McPherson, Patel Section 17.6. [Page 17] INTERNET-DRAFT Expires: February 2004 August 2003 18. References [RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol BGP", RFC 1105, June 1989. [RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol BGP", RFC 1105, June 1990. [RFC 1264] Hinden, R., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991. [RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3 (BGP-3)", RFC 1105, October 1991. [RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, July 1994. [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995. [RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC 1773, March 1995. [RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification Language", RFC 2622, June 1999. [RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous System Confederations for BGP", RFC 3065, Febuary 2001. [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP Persistent Route Oscillation Condition", RFC 3345, August 2002. [BGP4-ANALYSIS] Work in Progress. [BGP4-IMPL] Work in Progress. McPherson, Patel Section 18. [Page 18] INTERNET-DRAFT Expires: February 2004 August 2003 [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. 19. Authors' Addresses Danny McPherson Arbor Networks Email: danny@arbor.net Keyur Patel Cisco Systems Email: keyupate@cisco.com 20. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McPherson, Patel Section 20. [Page 19] _______________________________________________ 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 QAA13330 for ; Fri, 15 Aug 2003 16:26: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 19nl96-00014h-Gs; Fri, 15 Aug 2003 16:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl8A-00010p-6Z for idr@optimus.ietf.org; Fri, 15 Aug 2003 16:25: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 QAA12203 for ; Fri, 15 Aug 2003 16:24:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl88-0005ll-00 for idr@ietf.org; Fri, 15 Aug 2003 16:25:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19nl87-0005lh-00 for idr@ietf.org; Fri, 15 Aug 2003 16:24:59 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19nl86-0000Kf-H6 for idr@ietf.org; Fri, 15 Aug 2003 20:24:58 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1653510017.20030815132434@psg.com> To: idr@ietf.org In-Reply-To: <96615458792.20030814180213@psg.com> References: <96615458792.20030814180213@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Fwd: Last Call on draft-gill-gtsh-00.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: Fri, 15 Aug 2003 13:24:34 -0700 FYI below. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: Date: Thursday, August 14, 2003, 6:02:13 PM Subject: Last Call on draft-gill-gtsh-00.txt ===8<==============Original message text=============== Folks- The IESG received a request to progress draft-gill-gtsh-00.txt as an individual contribution towards the EXPERIMENTAL RFC status. The concept described in the document (as well as the original document known as draft-gill-btsh) has been widely discussed in the community, and I would like to start a 4-week Last Call on the Routing Area mailing list to encourage review and gauge the consensus on the document before taking it to the IESG. Please read the document and indicate if you support it going forward (do send a message if you support). The last call ends on September 12th, 2003. This message will be forwarded as an FYI to certain individual WGs. However, please send your comments to routing-discussion@ietf.org -- Alex Zinin IETF Routing Area Co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== _______________________________________________ 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 MAA01585 for ; Fri, 15 Aug 2003 12:57:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D076B9123C; Fri, 15 Aug 2003 12:52:10 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E104991233; Fri, 15 Aug 2003 12:51:18 -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 BA1C291228 for ; Fri, 15 Aug 2003 12:50:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D79F5DDAD; Fri, 15 Aug 2003 12:50:55 -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 F29EE5DD9E for ; Fri, 15 Aug 2003 12:50:54 -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 MAA03172; Fri, 15 Aug 2003 12:50:49 -0400 (EDT) Message-Id: <200308151650.MAA03172@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-dynamic-cap-04.txt Date: Fri, 15 Aug 2003 12:50:49 -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 : Dynamic Capability for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-dynamic-cap-04.txt Pages : 6 Date : 2003-8-15 This document defines a new BGP capability termed 'Dynamic Capability', which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-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-dynamic-cap-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-dynamic-cap-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-8-15123949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-dynamic-cap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-dynamic-cap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15123949.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 HAA04549 for ; Wed, 13 Aug 2003 07:59: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 19muHN-0003q6-GI; Wed, 13 Aug 2003 07: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 19muH8-0003nO-1G for idr@optimus.ietf.org; Wed, 13 Aug 2003 07:58: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 HAA16486 for ; Wed, 13 Aug 2003 07:58:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19muH6-0000ep-00 for idr@ietf.org; Wed, 13 Aug 2003 07:58:44 -0400 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19muH6-0000eZ-00 for idr@ietf.org; Wed, 13 Aug 2003 07:58:44 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HJK004013WVY6@mailout3.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:07 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HJK00K123WUG7@mailout3.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:06 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HJK0012F3WSBB@mmp2.samsung.com> for idr@ietf.org; Wed, 13 Aug 2003 20:58:06 +0900 (KST) From: Manav Bhatia Subject: Re: [Idr] FW: idr minutes To: Susan Hares Cc: idr@ietf.org Reply-to: Manav Bhatia Message-id: <021d01c36191$4289b8a0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: Wed, 13 Aug 2003 17:21:39 +0530 Checking mails after some gap .. > CHEN: How is this different from last presentation > Bhatia: Don't need to change encoding I thought he was talking of Alvaro's draft and hence i said "No need to change the encoding". This proposal is very different from the previous presentation. In the previous there isnt any way to advertise multiple paths. The central idea being that the tie breaking should never reach the point where the RIDs are compared. > CHEN: Advertising best external route also solves oscillation problem. > Without changing spec. > Marques: Draft should be named "How to advertise multiple paths in BGP". > Look at Alvero's draft. > Yakov: Also look at how MP-BGP addresses this The ECMP_NEXT_HOP attribute already has the AFI field. Just need to add a SAFI field. All subsequent UPDATEs with the ECMP_NEXT_HOP attribute carrying the will not be treated as implicit withdrawals and will instead be appended to the existing RIB. There is thus no special treatment required for MP-BGP. Regards, Manav _______________________________________________ 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 KAA08228 for ; Fri, 8 Aug 2003 10:01: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 19l7nh-0005W2-Cw; Fri, 08 Aug 2003 10: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 19l7mq-0005Se-3N for idr@optimus.ietf.org; Fri, 08 Aug 2003 10:00: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 KAA11057 for ; Fri, 8 Aug 2003 10:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7mo-0000s9-00 for idr@ietf.org; Fri, 08 Aug 2003 10:00:06 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7mn-0000rX-00 for idr@ietf.org; Fri, 08 Aug 2003 10:00:05 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78DxZp5078670 for idr@ietf.org; Fri, 8 Aug 2003 09:59:35 -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 h78DxPLu078645 for ; Fri, 8 Aug 2003 09:59:25 -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 Message-ID: Thread-Topic: idr minutes Thread-Index: AcNQgyv2/pHP9RtzR1+X9u4fP9bqRwNMg16Q From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Subject: [Idr] FW: idr minutes 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, 8 Aug 2003 09:59:20 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id KAA08228 IETF 57 IDR Minutes Chairs: Yakov Rekhter, Sue Hares ID Document Status (chairs) ------------------ - Base Spec done! Will post -21 after IETF. - See slides Avoid BGP Best Path Transition From one External to Another draft-chen-bgp-avoid-transition-00.txt ----------------------------------------------------------- - BGP identifier used in last phases of BGP routes selection - Appear random - Subject to change - Reduces stability - Proposed solution: Don't eliminate either path due to BGP ID during path selection - Exception: AS Confederations; parallel sessions - Advantages: stability, reduce iBGP oscillation - Request to adopt as WG draft, but WG is in closed status until base doc is approved Advertising Equal Cost Multipath Routes in BGP draft-bhatia-ecmp-routes-in-bgp-00 ------------------------------------------------- - Route reflector only advertises route that it installs - May not be optimal for all RR clients or external peers - May lead to route oscillation - Advertise two paths to destination - Proposal: ECMP-NEXT-HOP attribute If specified, second advertisement is not CHEN: I don't think that this is adequate to prevent route oscillation. Bhatia: It will because multiple paths are advertised CHEN: How is this different from last presentation Bhatia: Don't need to change encoding CHEN: Advertising best external route also solves oscillation problem. Without changing spec. Marques: Draft should be named "How to advertise multiple paths in BGP". Look at Alvero's draft. Yakov: Also look at how MP-BGP addresses this BGPv4 SAFI-Specific Attribute draft-kapoor-nalawade-idr-bgp-ssa-00 The Tunnel SAFI draft-nalawade-kapoor-tunnel-safi-00 -------------------------------------- - Exchange tunnel endpoint information - avoid o(n^2) configuration problem - Proposal: Use BGP to advertise tunnel endpoints - SAFI specific Attribute carries tunnel attributes - SAFI specific attribute value contains TLVs - TLV context determined by type field - Negotiated capability Hares: Whats the cookie for kapoor: Its defined in l2tpv3. Yakov: Need discussion on mailing list. Unbundle SAFI discussion from discussion of whether we need a new attribute. Yakov: How do we control type codes? Kapoor: Options - IANA, WG consensus; we can talk about it Yakov: Do you have concept of transitive or non-transitive TLV Kapoor: Attribute is transitive. All TLV inherit. Multiprotocol Next Hop Attribute draft-lefaucheur-mp-nh-00 -------------------------------------------- - need to advertise next hop different from AF of NLRI - may need to advertise multiple next-hops for a prefix - may need to advertise next-hop specific parameters (e.g., label per nh). Yakov: Motivations; load balancing, v4 over v6. There are existing apps where encoding of NLRI and Next hop are different. Gargi: If we wanted to load balance across two next hops of different type, we could not. iBGP Auto Mesh draft-raszuk-idr-ibgp-auto-mesh-00 ----------------------- - motivation: Autodiscover iBGP peers - flood BGP config via IGP bgp autodiscover TLV flooded in IGP - no change to BGP machinery Dave Ward: What happens during graceful restart? Robert: We don't reflood if configuration is not changing Chen: Does it help much if iBGP congig is not big How will you carry MD5 key. Robert: MD5 keys will be same for all speakers. Chen: How does this work for RR clients Robert: cluster id on client Parantap: We do static config. If you miss one, it really bad. We don't need this. We don't encourage you to touch ISIS. Signalling tunneling Encaps --------------------------- draft-raggarwa-ppvpn-tunnel-encap-sig-01 - Mechanism for signaling PE tunnel encap capabilities. - Motivations: o Blackhole Avoidance o Co-existing MPLS & IP encap -BGP Tunnel Capability SAFI -LDP Tunnel Encap Capabilities (may not be necessary per BGP)IANA Considerations Alex: The BGP specific part needs to belong in IDR Dave: You will work together with Gargi Rahul: Yes =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "If a man marches out of step with his fellows it may be that he hears the sound of a different drummer or, perhaps that he has a poor sense of rhythm." -- Henry David Thoreau _______________________________________________ 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 HAA12575 for ; Wed, 6 Aug 2003 07:49:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2C5E9127D; Wed, 6 Aug 2003 07:48:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C7B49127F; Wed, 6 Aug 2003 07:48:57 -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 AED8D9127D for ; Wed, 6 Aug 2003 07:47:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BEE55DDCE; Wed, 6 Aug 2003 07:47:51 -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 DDECD5DDAA for ; Wed, 6 Aug 2003 07:47:50 -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 HAA12677; Wed, 6 Aug 2003 07:47:48 -0400 (EDT) Message-Id: <200308061147.HAA12677@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-03.txt Date: Wed, 06 Aug 2003 07:47:47 -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-03.txt Pages : 4 Date : 2003-8-5 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-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-cease-subcode-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-cease-subcode-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-8-5125925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5125925.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 JAA19417 for ; Tue, 5 Aug 2003 09:11: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 19k1ag-00062g-Es; Tue, 05 Aug 2003 09:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k1aO-00062E-LF for idr@optimus.ietf.org; Tue, 05 Aug 2003 09:10: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 JAA09361 for ; Tue, 5 Aug 2003 09:10:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k1aN-0001jK-00 for idr@ietf.org; Tue, 05 Aug 2003 09:10:43 -0400 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19k1aL-0001jC-00 for idr@ietf.org; Tue, 05 Aug 2003 09:10:42 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HJ500L01DWN8K@mailout1.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:59 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HJ500M9RDWMRJ@mailout1.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:59 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HJ5009CXDWK0G@mmp2.samsung.com> for idr@ietf.org; Tue, 05 Aug 2003 22:09:58 +0900 (KST) From: Manav Bhatia Subject: Re: [Idr] Route refresh/ capability To: jai hari Cc: idr@ietf.org Reply-to: Manav Bhatia Message-id: <05b101c35b52$01a96370$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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: Tue, 05 Aug 2003 18:33:45 +0530 Jai, > 7. How should errors in capability length field that does not agree with > header length ( or optional parameter length ) be handled? (What is the > notification code? Is it open messag errorcode with subcode unspecified? ) You send a NOTIFICATION message with the Cease (6) Error Code. > > 8. Does the standard care how to handle a route refresh request while one is > already pending? (Can we > just abort and restart the previous adj-rib-out update? ) No. ~Manav _______________________________________________ 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 BAA28510 for ; Tue, 5 Aug 2003 01:10: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 19ju5B-0000Rh-SU; Tue, 05 Aug 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 19ju4O-0000R6-Ob for idr@optimus.ietf.org; Tue, 05 Aug 2003 01:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20270 for ; Tue, 5 Aug 2003 01:09:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ju4L-0007b8-00 for idr@ietf.org; Tue, 05 Aug 2003 01:09:09 -0400 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19ju4J-0007am-00 for idr@ietf.org; Tue, 05 Aug 2003 01:09:09 -0400 Received: (qmail 20156 invoked by uid 510); 5 Aug 2003 05:10:01 -0000 Message-ID: <20030805051001.20153.qmail@webmail31.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 aug 2003 05:10:00 -0000 MIME-Version: 1.0 From: "naresh paliwal" Reply-To: "naresh paliwal" To: "jai hari" Cc: idr@ietf.org Subject: Re: [Idr] Route refresh/ capability Content-type: text/plain; format=flowed Content-Disposition: inline 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: 5 Aug 2003 05:10:01 -0000 >1. Is an implementation allowed to support route refresh >capability without supporting Multiprotocol > capability? RFC 2918 states "If a BGP speaker receives from >its peer a ROUTE-REFRESH message with > the that the speaker didn't advertise to the peer >". What is the peer advertising if > it did not support Multiprotocol capability? Need not, As is supported anyway.. >4. Is restarting hold timer for the session accepted upon >receiving a route refresh request? It make sense to restart Hold timer and keep alive timer. >5. What should be the action ( ignore? ) if route refresh request >is received from a peer that did > not advertise this capability at all? It an error >6. Is Open message optional parameter length really required to >parse the message? ( Is header length > not sufficient? ) But then header length need to be redefined for open message, as message length.. Doesnt make sense to me. -Naresh ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl _______________________________________________ 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 AAA27951 for ; Tue, 5 Aug 2003 00:55: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 19jtqf-0008Ka-C8; Tue, 05 Aug 2003 00:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jtq9-0008KB-9B for idr@optimus.ietf.org; Tue, 05 Aug 2003 00:54:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20049 for ; Tue, 5 Aug 2003 00:54:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jtq6-0007Xi-00 for idr@ietf.org; Tue, 05 Aug 2003 00:54:26 -0400 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19jtq4-0007XU-00 for idr@ietf.org; Tue, 05 Aug 2003 00:54:24 -0400 Received: (qmail 325 invoked by uid 510); 5 Aug 2003 04:55:16 -0000 Message-ID: <20030805045516.324.qmail@webmail31.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 aug 2003 04:55:16 -0000 MIME-Version: 1.0 From: "naresh paliwal" Reply-To: "naresh paliwal" To: "John G.Scudder" Cc: idr@ietf.org, "jai hari" Subject: Re: Re: [Idr] Route refresh/ capability Content-type: text/plain; format=flowed Content-Disposition: inline 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: 5 Aug 2003 04:55:16 -0000 Yeah!! john is right, unless the mib variable strict capabily match is set.. Otherwise notification is needed.. -Naresh On Tue, 05 Aug 2003 John G. Scudder wrote : >At 6:03 PM +0000 8/4/03, jai hari wrote: >>2. RFC 3392 states: "If a BGP speaker that supports a certain >>capability determines that >> its peer doesn't support this capability, the speaker MAY >>send a >> NOTIFICATION message to the peer," >> What about the case where the local speaker receives a >>capability it does not understand/support.? >> Should it send a notification - unsupported capability? > >No, it should not. > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl _______________________________________________ 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 OAA07386 for ; Mon, 4 Aug 2003 14:49: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 19jkOD-0001D5-Ji; Mon, 04 Aug 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkO0-0001Ci-Iy for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07456 for ; Mon, 4 Aug 2003 14:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkNx-0004pC-00 for idr@ietf.org; Mon, 04 Aug 2003 14:48:45 -0400 Received: from [205.219.34.104] (helo=exch-srv.CoronaNetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19jkNu-0004oV-00 for idr@ietf.org; Mon, 04 Aug 2003 14:48:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [Idr] Route refresh/ capability Message-ID: Thread-Topic: [Idr] Route refresh/ capability Thread-Index: AcNasoN338mO+hooRwe9YdnTovl+PAABX6m9 From: "Ankur Goyal" To: "jai hari" , 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, 4 Aug 2003 11:44:40 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nic.merit.edu id OAA07386 > 3. Are capabilities encoded as a single open optional parameter or multiple > open optional parameters? > Does the standard require it to be either way? The standard allows it to be either way. --Ankur vXXk'+m 0j)fjb? 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 OAA07136 for ; Mon, 4 Aug 2003 14:41: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 19jkGT-00011D-8I; Mon, 04 Aug 2003 14:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkFe-00010h-Ga for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07263 for ; Mon, 4 Aug 2003 14:40:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkFb-0004lq-00 for idr@ietf.org; Mon, 04 Aug 2003 14:40:07 -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 19jkFb-0004ln-00 for idr@ietf.org; Mon, 04 Aug 2003 14:40:07 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2003 11:39:37 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h74IdY7F001143; Mon, 4 Aug 2003 11:39:35 -0700 (PDT) Received: from [64.101.214.208] (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 OAA05082; Mon, 4 Aug 2003 14:39:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: "jai hari" From: "John G. Scudder" Subject: Re: [Idr] Route refresh/ capability 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: Mon, 4 Aug 2003 14:39:31 -0400 At 6:03 PM +0000 8/4/03, jai hari wrote: >2. RFC 3392 states: "If a BGP speaker that supports a certain >capability determines that > its peer doesn't support this capability, the speaker MAY send a > NOTIFICATION message to the peer," > What about the case where the local speaker receives a capability >it does not understand/support.? > Should it send a notification - unsupported capability? No, it should not. --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 OAA05889 for ; Mon, 4 Aug 2003 14:05: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 19jjhd-0007it-DZ; Mon, 04 Aug 2003 14:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjgv-0007iE-68 for idr@optimus.ietf.org; Mon, 04 Aug 2003 14:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05837 for ; Mon, 4 Aug 2003 14:04:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjgs-0004Ow-00 for idr@ietf.org; Mon, 04 Aug 2003 14:04:14 -0400 Received: from sea1-f140.sea1.hotmail.com ([207.68.163.140] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19jjgr-0004OY-00 for idr@ietf.org; Mon, 04 Aug 2003 14:04:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Aug 2003 11:03:41 -0700 Received: from 65.198.24.91 by sea1fd.sea1.hotmail.msn.com with HTTP; Mon, 04 Aug 2003 18:03:41 GMT X-Originating-IP: [65.198.24.91] X-Originating-Email: [jaiharil@hotmail.com] From: "jai hari" To: idr@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Aug 2003 18:03:41.0269 (UTC) FILETIME=[BCADC850:01C35AB2] Subject: [Idr] Route refresh/ capability 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, 04 Aug 2003 18:03:41 +0000 Hi, I have a list of basic questions in RFC 2918/3392. Please let me know if these have already been answered in the mail-archives. 1. Is an implementation allowed to support route refresh capability without supporting Multiprotocol capability? RFC 2918 states "If a BGP speaker receives from its peer a ROUTE-REFRESH message with the that the speaker didn't advertise to the peer ". What is the peer advertising if it did not support Multiprotocol capability? 2. RFC 3392 states: "If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer," What about the case where the local speaker receives a capability it does not understand/support.? Should it send a notification - unsupported capability? 3. Are capabilities encoded as a single open optional parameter or multiple open optional parameters? Does the standard require it to be either way? 4. Is restarting hold timer for the session accepted upon receiving a route refresh request? 5. What should be the action ( ignore? ) if route refresh request is received from a peer that did not advertise this capability at all? 6. Is Open message optional parameter length really required to parse the message? ( Is header length not sufficient? ) 7. How should errors in capability length field that does not agree with header length ( or optional parameter length ) be handled? (What is the notification code? Is it open messag errorcode with subcode unspecified? ) 8. Does the standard care how to handle a route refresh request while one is already pending? (Can we just abort and restart the previous adj-rib-out update? ) Thanks, -Jaihari _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ 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 GAA11571 for ; Sat, 2 Aug 2003 06:23: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 19itXR-0000YV-T1; Sat, 02 Aug 2003 06:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19itXH-0000YC-6k for idr@optimus.ietf.org; Sat, 02 Aug 2003 06:22:51 -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 GAA10321 for ; Sat, 2 Aug 2003 06:22:42 -0400 (EDT) From: fredricktaylor00@netscape.net Message-Id: <200308021022.GAA10321@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: fredricktaylor00@netscape.net X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] KIND ATTENTION !! 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, 2 Aug 2003 12:22:48 +0200 EXTREMELY CONFIDENTIAL. ATTENTION: THE PRESIDENT/CHAIRMAN. First, may I solicit your confidentiality in this transaction, this by virtue of its nature I am Fredrick Taylor, a cousin to the president Charles Taylor of Liberia. As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes (containing cash of $39.8m)secured in a diplomatic custody in madrid-spain and these diplomatic agents are not aware of the contents of this consignment. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out that the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this funds will be use in capital investments or you advice us on any lucrative project to put the funds into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project. Upon receipt of your positive response, I will suggest we meet possible in madrid-spain for us to work out modalities concerning the investment of the money and/or the ratio you will receive after the collection of the boxes from these diplomatic agents in madrid-spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address.I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Best Regards, F . Taylor. _______________________________________________ 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 OAA00640 for ; Fri, 1 Aug 2003 14:50: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 19ieyX-0007Mj-Oh; Fri, 01 Aug 2003 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieyQ-0007MF-W6 for idr@optimus.ietf.org; Fri, 01 Aug 2003 14:49:55 -0400 Received: from mail1.artmarket.com (mail1.artmarket.com [194.242.43.185]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04011 for ; Fri, 1 Aug 2003 14:49:45 -0400 (EDT) Message-Id: <200308011849.OAA04011@ietf.org> From: Fine Art Directory To: MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA04027 Subject: [Idr] [ADV] For Artists, Galleries, museums, Art centers 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, 1 Aug 2003 14:49:45 -0400 (EDT) All the fine art on line "> =20
=20 =20 =20 =20 =20 =20 =20
A L L
T H E
F I N E
A R T
O N
L I N E
=20
=20
=20
&nb= sp;by=20 =20  art-online ©1995  1987
 ©Thierry Ehrmann









=20 =20
To remove = your email: idr@ietf.org
please click below:
http://list.artists-server.com/?m=3Didr@ietf.org
In case the above link does not work you can go to
http://list.artists-server.com/
or reply to this message as it is.
Please allow us 72 H for your e-mail to be removed.
Thank you for your= co-operation. 		Pour d=E9sinscr= ire votre email : idr@ietf.org
cliquez ci-dessous :
http://list.a= rtists-server.com/?m=3Didr@ietf.org
Si le lien ci-dessus ne fonctionne pas, vous pouvez aller sur :
http://list.artists-server.com/
ou r=E9pondez svp =E0 ce message sans en modifier le contenu.
Votre d=E9sinscription sera effective dans les 72 H.
Merci de votre co= op=E9ration.
En conformité a= vec la loi=20 78-17 du 6/1/78 (CNIL), vous pouvez demander à ne plus figurer sur= notre=20 fichier de routage.
=20 F.A.
Artprice.co= m - Domaine=20 de la Source BP 69 - F-69270 St Romain au Mont D'or - RCS : 411 309 198

 

_______________________________________________ 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 KAA20714 for ; Fri, 1 Aug 2003 10:06: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 19iaXi-0004oX-Q3; Fri, 01 Aug 2003 10: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 19iaXd-0004oF-Ms for idr@optimus.ietf.org; Fri, 01 Aug 2003 10:05:57 -0400 Received: from pc7 (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 KAA22111 for ; Fri, 1 Aug 2003 10:05:50 -0400 (EDT) From: lotterysl@netscape.net Message-Id: <200308011405.KAA22111@ietf.org> To: idr@ietf.org Content-Type: text/plain; charset="US-ASCII" Reply-To: lotterysl@netscape.net X-Priority: 3 X-Library: Indy 9.0.3-B X-Mailer: Foxmail Subject: [Idr] WINNING 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: Fri, 1 Aug 2003 16:06:26 +0200 LOTTERY LA PRIMITIVA. C/GUZMAN EL BUENO,137 MADRID - ESPANA. TEL:0034 696 026 500 FROM: THE DESK 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 announcement, of winners of the LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMMES held on 6 June,2003. Your name is attached to ticket number 004-05117963-198, with serial number 99375 drew the lucky numbers 05-07-11-12-13-27, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of EUROS 647,828,87 Thousand in cash credited to file No:LP/26510460037/03.This is from total prize money of EUROS 80,400,000.00 shared among the twenty two international winners in this category. All participants were selected through a computer ballot system drawn from 25,000 names from Australia,New Zealand, America,Europe, North America and Asia as part of International Promotions Programme, which is conducted annually. CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes Euros 1.1 billion International Lottery. To begin your claim, please contact ESPAOL CREDITO SEGURIDAD, MADRID-SPAIN ,PHONE NUMBER (+34 608 701 649) MR JUAN CARLOS REDONDO, FOREIGN OPERATION MANAGERS, Email;(lottery-primitiva@winning.com). For due processing and remittance of your prize money to a designated account . Remember, all prize money must be claimed not later than 10 September 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 one of your correspondences with the security company . Furthermore, should there be any change of your address,do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programme. Sincerely, FERNANDO TORRES RODRIGUEZ. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr